기업 공격 표면의 패러다임 변화

자율 인공지능 (AI) 에이전트와 동적 실행 계층이 기업용 소프트웨어에 통합되면서 현대 기업의 공격 표면(Attack Surface)이 근본적으로 변화했습니다. 조직이 코드를 즉석에서 생성하고 실행할 수 있는 AI 플랫폼을 배포하면, 사실상 기업의 경계 내에 내부 멀티테넌트(Multi-tenant) 실행 환경을 도입하는 것과 같습니다. 이러한 아키텍처의 보안은 신뢰할 수 없는 AI 생성 코드와 기반 호스트 운영체제(Host Operating System)를 분리하는 경계의 절대적인 무결성에 전적으로 의존합니다. 이 경계가 무너지면 그 결과는 즉각적입니다. 즉, 오케스트레이션 서비스의 권한을 가진 원격 코드 실행 (RCE)이 발생합니다.

저는 보안 팀들이 AI 플랫폼을 표준 웹 애플리케이션으로 취급하여, SQL 인젝션 (SQL Injection)이나 교차 사이트 스크립팅 (XSS)과 같은 전통적인 웹 취약점에 방어 심층 (Defense-in-depth) 전략을 집중하는 경우가 많다는 점을 관찰했습니다. 그러나 LLM 기반 코드 인터프리터 (Code Interpreter)의 배포는 근본적으로 다른 위협 모델을 도입합니다. 이 패러다임에서 애플리케이션은 설계 단계부터 임의의 코드를 실행하도록 설계되었습니다. 주요 보안 통제 수단은 더 이상 입력값 정제 (Input Sanitization)만이 아니라, 강력한 저수준 가상화 (Low-level Virtualization) 및 프로세스 격리 (Process Isolation)입니다.

본 분석에서는 CVE-2026-6875의 아키텍처 패턴을 참조 모델로 사용하여, 기업용 AI 플랫폼 내 샌드박스 탈출 (Sandbox Escape) 취약점의 구조적 메커니즘을 조사합니다. 저는 이러한 경계가 어떻게 우회되는지 해부하고, 다양한 격리 기술의 운영상의 트레이드오프 (Trade-offs)를 평가하며, 런타임 인프라를 강화하기 위한 구체적인 청사진을 제공할 것입니다. 저의 목표는 피상적인 패치 권고를 넘어, 엔지니어링 리더들이 탄력적인 실행 환경을 설계하는 데 필요한 기술적 깊이를 갖추도록 돕는 것입니다.

현재 활발히 악용되고 있는 ServiceNow AI 플랫폼의 심각한 CVSS 9.5 샌드박스 탈출(Sandbox Escape) 취약점인 CVE-2026-6875에 대한 심층적인 기술 분석입니다. AI 실행 계층(AI execution layer)의 메커니즘을 학습하십시오.

🤖 AI 실행 계층(AI Execution Layers)의 아키텍처 분석

샌드박스 탈출(Sandbox Escape)이 어떻게 발생하는지 이해하려면, 먼저 엔터프라이즈 AI 실행 엔진의 전형적인 아키텍처를 분석해야 합니다. 이러한 시스템은 일반적으로 오케스트레이션 계층(Orchestration layer), 통신 브리지(Communication bridge), 그리고 격리된 게스트 런타임(Isolated guest runtime)이라는 세 가지 주요 구성 요소로 이루어져 있습니다.

오케스트레이션 계층 (The Orchestration Layer)

이 구성 요소는 호스트 시스템(Host system)에서 실행되며, 종종 높은 권한을 가집니다. 이는 더 넓은 범위의 엔터프라이즈 애플리케이션과 인터페이스하고, 사용자 세션을 관리하며, LLM(대규모 언어 모델)과 협업합니다. LLM이 특정 작업(데이터 분석, 수학적 계산 또는 파일 파싱 등)에 코드 실행이 필요하다고 판단하면, 오케스트레이션 계층은 생성된 코드 블록을 전달받아 실행 환경을 준비합니다.

통신 브리지 (The Communication Bridge)

호스트가 샌드박스 내부로 코드를 전달하고 실행 결과물을 회수해야 하므로, 반드시 통신 채널(Communication channel)이 존재해야 합니다. 이는 일반적으로 Unix 도메인 소켓(Unix domain sockets), 로컬 루프백 TCP 연결(Local loopback TCP connections), 또는 공유 메모리 세그먼트(Shared memory segments)를 통해 구현됩니다. 샌드박스 내부에서 실행되는 데몬(Daemon)이 이 채널에서 대기하며, 코드를 수신하고 로컬 인터프리터(Python 또는 Node.js 등)를 통해 이를 실행한 뒤, 표준 출력(stdout), 표준 에러(stderr) 및 생성된 파일들을 반환합니다.

격리된 게스트 런타임 (The Isolated Guest Runtime)

이것이 샌드박스(sandbox) 그 자체입니다. 많은 표준 배포 환경에서 이는 runc, Docker 또는 containerd에 의해 관리되는 경량 컨테이너(lightweight container)입니다. 격리는 표준 Linux 커널 기능에 의존합니다: 네임스페이스 (namespaces, 프로세스, 네트워크 인터페이스, 마운트 지점 및 IPC를 격리하기 위함), 제어 그룹 (cgroups, CPU, 메모리 및 I/O를 제한하기 위함), 그리고 seccomp 필터 (seccomp filters, 사용 가능한 시스템 호출(system calls)을 제한하기 위함)입니다.

이 아키텍처에는 내재적인 구조적 긴장 관계가 포함되어 있다는 점을 강조해야 합니다. AI 에이전트는 유용한 작업을 수행하기 위해 라이브러리, 패키지, 때로는 외부 API에 대한 액세스 권한이 필요합니다. 그러나 게스트 런타임(guest runtime)에 부여되는 모든 기능은 가용한 공격 표면(attack surface)을 증가시킵니다. 표준 컨테이너화(containerization)의 경우와 같이 게스트 런타임이 호스트 운영 체제의 커널을 공유한다면, 커널의 시스템 호출 인터페이스에 존재하는 취약점이나 오케스트레이션(orchestration) 계층의 설정 오류를 이용하여 컨테이너를 탈출(escape)할 수 있습니다.

탈출 메커니즘의 해체 (Deconstructing the Escape Mechanics)

샌드박스 탈출에 대한 저의 분석 결과, 실패는 격리된 게스트 런타임 자체 내부에서 발생하는 경우가 드뭅니다. 대신, 시스템의 붕괴는 일반적으로 호스트와 게스트 사이의 인터페이스에서 발생하거나, 공유된 커널 리소스를 악용함으로써 발생합니다. 저는 주요 탈출 벡터(escape vectors)를 네 가지 뚜렷한 운영 패턴으로 분류했습니다.

1. 커널 인터페이스 악용 및 공유 시스템 호출 (Kernel Interface Exploitation and Shared Syscalls)

샌드박싱을 위해 표준 컨테이너가 사용될 때, 게스트 프로세스는 호스트 커널 위에서 직접 실행됩니다. 공격자가 게스트 내부에서 임의의 코드(arbitrary code)를 실행할 수 있다면, 시스템 호출(system calls)을 통해 호스트 커널과 직접 상호작용할 수 있습니다. 만약 호스트 커널에 로컬 권한 상승 (LPE, Local Privilege Escalation) 취약점(예: 메모리 관리 또는 네트워크 네임스페이스 내의 취약점)이 존재한다면, 공격자는 컨테이너 내부에서 이를 악용하여 호스트의 루트(root) 권한을 획득한 후, 결과적으로 컨테이너 네임스페이스를 탈출할 수 있습니다.

2. 오케스트레이션 에이전트 명령 주입 (Orchestration Agent Command Injection)

이는 맞춤형으로 구축된 AI 플랫폼에서 흔히 발생하는 취약점 패턴입니다. 호스트의 오케스트레이션 계층(Orchestration layer)은 종종 샌드박스(Sandbox)의 생명주기를 관리하기 위해 명령줄 유틸리티를 사용합니다 (예: docker run을 통한 컨테이너 생성 또는 docker exec를 통한 컨테이너 내부 명령 실행). 만약 오케스트레이션 계층이 환경 변수(Environment variables), 볼륨 마운트 경로(Volume mount paths), 또는 컨테이너 이름과 같이 이러한 명령에 전달되는 파라미터를 적절히 정제(Sanitize)하지 못할 경우, 공격자는 셸 메타문자(Shell metacharacters)를 주입할 수 있습니다. 이는 결과적으로 호스트 시스템에서의 명령 실행(Command execution)으로 이어져, 샌드박스를 완전히 우회하게 됩니다.

3. 소켓 및 IPC 하이재킹 (Socket and IPC Hijacking)

컨테이너의 상태를 모니터링하거나 파일을 관리하기 위해, 개발자들은 때때로 호스트의 컨테이너 런타임 소켓(예: /var/run/docker.sock)을 샌드박스 내부에 마운트합니다. 이는 최고 수준의 심각성을 가진 아키텍처 안티 패턴(Architectural anti-pattern)입니다. 만약 공격자가 이 소켓에 접근할 수 있는 권한을 가진 채 샌드박스 내부에서 코드 실행(Code execution) 권한을 획득하면, 호스트의 컨테이너 데몬(Container daemon)에 API 명령을 내려 새로운 컨테이너를 생성할 수 있습니다. 이 새로운 컨테이너는 호스트 네임스페이스(Host namespaces), 호스트 네트워크 접근 권한, 그리고 호스트의 루트 디렉터리가 볼륨으로 마운트되도록 설정될 수 있으며, 이를 통해 호스트 시스템에 대한 즉각적이고 완전한 제어권을 얻게 됩니다.

4. 경로 탐색 및 공유 볼륨 조작 (Path Traversal and Shared Volume Manipulation)

파일 입출력을 용이하게 하기 위해, 호스트는 샌드박스와 디렉터리를 공유해야 합니다. 이는 일반적으로 바인드 마운트(Bind mounts)를 통해 이루어집니다. 만약 호스트 측 애플리케이션이 엄격한 검증 없이 이 공유 디렉터리에 기록된 파일을 처리한다면, 여러 취약점이 발생할 수 있습니다. 예를 들어, 게스트 런타임(Guest runtime)이 공유 디렉터리 내에 민감한 호스트 파일(예: /etc/shadow 또는 /root/.ssh/authorized_keys)을 가리키는 심볼릭 링크(Symbolic link)를 생성하고, 호스트 애플리케이션이 해당 링크가 허용된 경계 내에서 해결되는지 확인하지 않고 읽거나 쓰는 경우, 호스트는 의도치 않게 자신의 시스템 파일을 읽거나 덮어쓰게 됩니다.

격리 기술의 운영상 트레이드오프 (Operational Trade-offs of Isolation Technologies)

복구 전략(remediation strategy)을 설계할 때, 엔지니어링 리더는 보안, 성능, 그리고 운영 복잡성(operational complexity) 사이의 균형을 맞추는 격리 기술(isolation technology)을 선택해야 합니다. 저는 현재 운영 환경에서 사용되는 세 가지 주요 패러다임을 평가해 왔습니다.

표준 컨테이너 (Standard Containers: runc / Docker / Kubernetes)

• 메커니즘 (Mechanism): 호스트 커널(host kernel)을 공유하며, 네임스페이스(namespaces)와 cgroups를 통해 격리되는 OS 레벨 가상화(OS-level virtualization).
• 보안 태세 (Security Posture): 낮음. 커널을 공유하는 설계 특성상, 어떠한 커널 취약점이라도 호스트 전체의 침해(host compromise)로 이어질 수 있습니다. 설정 드리프트(configuration drift) 및 설정 오류(misconfigurations)에 매우 취약합니다.
• 성능 (Performance): 우수함. 가상화 오버헤드(virtualization overhead)가 거의 없으며, 1초 미만의 시작 시간을 가집니다.
• 운영 복잡성 (Operational Complexity): 낮음. 표준 도구 및 깊은 생태계 통합이 가능합니다.

유저 스페이스 커널 (User-Space Kernels: gVisor)

• 메커니즘 (Mechanism): 게스트 애플리케이션(guest application)의 시스템 호출(system calls)을 가로채고, 이를 유저 스페이스 커널(Go로 작성됨)을 통해 필터링한 후 제한된 하위 집합만을 호스트 커널에 전달하는 runc 호환 컨테이너 런타임(container runtime).
• 보안 태세 (Security Posture): 중간-높음. 직접적인 시스템 호출을 차단함으로써 호스트 커널의 공격 표면(attack surface)을 획기적으로 줄입니다. 게스트 프로세스가 커널 취약점을 악용하려고 시도하더라도, 시스템 호출이 가로채져 유저 스페이스에서 안전하게 처리됩니다.
• 성능 (Performance): 보통. 시스템 호출 가로채기(interception)로 인해 지연 시간(latency)이 발생하며, 이는 I/O 집약적(I/O-heavy)이거나 시스템 호출이 빈번한 워크로드(system-call-intensive workloads)에 영향을 줄 수 있습니다.
• 운영 복잡성 (Operational Complexity): 보통. Kubernetes와 같은 기존 컨테이너 오케스트레이터(container orchestrators)와 통합되지만, 특정 런타임 클래스(runtime class) 설정이 필요합니다.
• 나의 권장 사항 (My Recommendation): 하드웨어 가상화(hardware virtualization)로 쉽게 전환할 수 없는 기존 Kubernetes 인프라를 보유한 조직에게는 gVisor가 훌륭한 절충안(compromise)이 될 것이라고 권장합니다.

마이크로VM (MicroVMs: AWS Firecracker / Kata Containers)

• 메커니즘 (Mechanism): Linux 커널 기반 가상 머신 (KVM) 하이퍼바이저 (Hypervisor)를 사용하여 자체적인 전용 커널을 가진 매우 가볍고 최소화된 가상 머신을 실행하는 하드웨어 지원 가상화 (Hardware-assisted virtualization) 기술입니다.
• 보안 태세 (Security Posture): 높음. 경계가 하드웨어 수준에서 강제됩니다. 샌드박스 탈출 (Sandbox escape)을 위해서는 하이퍼바이저 자체를 공격해야 하며, 이는 Linux 커널 시스템 콜 (System call) 인터페이스보다 훨씬 더 작고 보안성이 높은 인터페이스입니다.
• 성능 (Performance): 높음. 시작 시간은 밀리초 (ms) 단위로 측정되며 (통상 100ms 미만), 전통적인 가상 머신에 비해 메모리 오버헤드가 최소화되어 있습니다.
• 운영 복잡도 (Operational Complexity): 높음. 베어메탈 (Bare-metal) 인스턴스 또는 클라우드 환경에서의 중첩 가상화 (Nested virtualization) 지원이 필요합니다. 또한 전문적인 오케스트레이션 (Orchestration) 도구가 필요합니다.
• 권장 사항 (My Recommendation): 신뢰할 수 없는 코드를 처리하는 전용 AI 실행 엔진의 경우, 마이크로VM (MicroVMs)을 골드 스탠다드 (Gold standard)로 간주합니다. 보안상의 이점이 초기 설정의 복잡성보다 훨씬 큽니다.

⚙️ 구현: 보안 실행 래퍼 (Secure Execution Wrapper)

이러한 강화 원칙의 실제 적용 사례를 보여주기 위해, 저는 견고한 Python 실행 래퍼 (Execution wrapper)를 설계했습니다. 이 구현은 신뢰할 수 없는 코드를 실행하기 전에 표준 Linux 시스템 제어 기능을 사용하여 엄격한 리소스 제한을 강제하고, 권한을 낮추며 (Drop privileges), 실행을 격리하는 방법을 보여줍니다.

이 래퍼가 표준 프로세스 실행을 상당히 강화하기는 하지만, 진정한 심층 방어 (Defense-in-depth)를 달성하려면 반드시 격리된 컨테이너 (Container) 또는 마이크로VM (MicroVM) 내부에서 배포되어야 함을 강조해야 합니다.

import os
import sys
import pwd
...

즉각적인 침해 사고 대응 및 복구 플레이북 (Immediate Incident Response and Remediation Playbook)

동적 코드 (Dynamic code)를 실행하는 엔터프라이즈 AI 플랫폼을 운영 중이라면, 귀하의 시스템이 공격 대상이 되고 있다고 가정해야 합니다. 잠재적인 침해를 식별하고 인프라를 보호하기 위해 다음 대응 프로토콜을 즉시 실행할 것을 권장합니다.

1단계: 자산 식별 및 매핑 (Asset Discovery and Mapping)

귀하의 환경 내에 있는 모든 AI 실행 엔진 (AI execution engine) 인스턴스를 식별해야 합니다. 여기에는 운영 서버 (production servers), 개발 환경 (development environments), 스테이징 환경 (staging environments) 및 모든 로컬 테스트 인스턴스가 포함됩니다. 공격자들은 초기 거점 (foothold)을 확보하기 위해 모니터링되지 않는 스테이징 환경을 빈번하게 공격 대상으로 삼으며, 이후 운영 네트워크로 측면 이동 (lateral movement)을 시도합니다.

🔐 2단계: 로그 분석 및 위협 헌팅 (Log Analysis and Threat Hunting)

자동화된 알림에만 의존하지 마십시오. 최소 90일 전의 기록까지 거슬러 올라가 시스템 및 애플리케이션 로그에 대해 수동적이고 구조적인 감사 (audit)를 수행할 것을 권장합니다. 다음 지표 (indicators)들에 집중하여 조사를 진행하십시오: