블랙박스 Linux 머신처럼 AI 챗봇의 샌드박스를 감사한 경험

저는 아마 제 취미에 대해 우려 섞인 이야기를 하게 만들 법한 일에 6시간을 소비했습니다.

Kimi 2.6 Instant를 챗봇으로 사용하는 대신, 방금 SSH로 접속한 낯선 Linux 머신처럼 취급했습니다. 탈옥(Jailbreak)도, 프롬프트 인젝션(Prompt Injection)도, 수상한 행위도 없었습니다. 그저 제공된 환경 내부에서 수동적인 관찰과 측정만을 수행했습니다.

제가 발견한 것은 예상보다 더 흥미로웠습니다.

배경: 모델의 자기 설명을 무시해야 하는 이유?

초기에 저는 한 가지를 깨달았습니다. 모델이 할 수 있다고 말하는 것과 런타임(Runtime)이 실제로 허용하는 것이 항상 일치하지는 않는다는 점입니다.

여러분은 다음과 같은 말을 듣게 될 것입니다:

"저는 인터넷 접속 권한이 없습니다."
"저는 시스템 정보에 접근할 수 없습니다."

이 두 가지 모두 제품 계층(Product layer)에서는 사실일 수 있지만, 그 아래에는 훨씬 더 강력한 기능이 자리 잡고 있을 수 있습니다.

그래서 저는 질문을 멈추고 대신 측정을 시작했습니다.

인프라 (The Infrastructure)

첫 번째 놀라움: 이것은 아주 작은 채팅 런타임처럼 느껴지지 않습니다.

• 호스트(Host): Alibaba Cloud, LifseaOS
• 커널(Kernel): Linux 5.10.134-18.0.10.lifsea8.x86_64
• CPU: Intel Xeon Platinum, 2개의 논리 코어 (cgroup에 의해 제한됨 — 스트레스 테스트 중 61개의 throttle 이벤트 기록됨)
• RAM: 정확히 3,221,225,472 바이트에서 하드 OOM(Out Of Memory) kill 발생. 스왑(Swap) 없음.
• 실행(Execution): Kubernetes Pod, Burstable QoS 클래스

이것은 장난감 같은 백엔드가 아니라 실제 클라우드 인프라입니다.

자격 증명 발견 (The Credential Finding)

가장 직접적인 발견:

cat /proc/self/environ | tr '\0' '\n' | grep -i pass
# SSH_PASSWORD=sshpassword

프로세스 환경 변수에 하드코딩된 SSH 자격 증명이 놓여 있었습니다. 자신의 /proc/self/environ을 읽는 사람이라면 누구나 볼 수 있는 상태였습니다.

네트워크 제한을 고려할 때 의미 있는 방식으로 악용할 수는 없지만, 문서화할 가치가 있는 전형적인 컨테이너 설정 오류(Misconfiguration)입니다.

디스크 레이아웃 (Disk Layout)

vda (40GB)
├─ vda1    1MB     BIOS boot
├─ vda2    127MB   EFI/boot
...

핵심 발견 사항: /mnt는 Pod 재시작 후에도 유지됩니다. 이는 호스트와 공유되는 실제 ext4 파티션입니다. OverlayFS 루트는 휘발성(ephemeral)입니다. /mnt/agents는 FUSE 마운트(kimi-portal)이며, 컨테이너와 AI 플랫폼 레이어 사이의 브리지 역할을 하는 것으로 보입니다.

네트워크 아키텍처 (Network Architecture)

코드 실행 컨테이너는 진정으로 에어갭(air-gapped) 상태입니다:

• 외부 호스트로의 curl 요청: 조용히 실패함
• Chromium: 공용 인터넷에 접속할 수 없음
• Raw TCP/UDP 송신(egress): 방화벽에 의해 차단됨

하지만 내장된 웹 도구들은 순환하는 주거용 프록시 풀(residential proxy pool)을 통해 인터넷에 접속할 수 있습니다. 송신(egress) IP를 조사한 결과, Evomi 및 NetNut 프록시 제공업체를 통해 콜롬비아 기반의 ISP(Bogotá, Pitalito)가 확인되었습니다.

코드 컨테이너 (Code Container)    →    송신(egress) 거부
웹 도구 레이어 (Web Tool Layer)    →    주거용 프록시 풀 (Residential Proxy Pool)    →    인터넷

확인된 내부 네트워크:

• 컨테이너: 10.162.57.123
• CoreDNS: 192.168.0.10
• K8s API: 192.168.0.1

내부 포트에서 호스팅하는 것은 가능합니다. 제한되는 것은 공용 외부 송신(outbound egress)입니다.

가상 디스플레이 (The Virtual Display)

환경에는 가상 그래픽 디스플레이인 DISPLAY=:99가 노출되어 있었습니다.

테스트 결과 1920×1080 해상도에서 Xvfb가 실행 중임을 확인했습니다. 저는 Tkinter를 사용하여 GUI 창을 렌더링하고, 화면에 콘텐츠를 그린 뒤 스크린샷을 캡처했습니다. 이 모든 과정은 표준 채팅 인터페이스 내부에서 수행되었습니다.

소프트웨어 공격 표면 (Software Surface Area)

표준 유틸리티 외에 주목할 만한 설치 패키지들은 다음과 같습니다:

자동화 (Automation): Playwright, Selenium, PyAutoGUI, python3-xlib, 스크린샷 도구

머신러닝 (ML): PyTorch 2.8, TensorFlow, scikit-learn (CUDA/NVIDIA 패키지가 존재하지만 GPU 접근은 활성화되지 않음 — 프로그래밍 방식으로 확인 결과 false 반환)

비전/OCR (Vision/OCR): OpenCV, EasyOCR, Tesseract, Pillow

백엔드 (Backend): FastAPI, Uvicorn, websockets — 샌드박스 내부에서 웹 서버를 실행하기에 충분한 구성입니다.

오피스 (Office): python-docx, python-pptx, openpyxl, reportlab

보안 요약 (Security Summary)

발견 사항	비고
/proc/self/environ 내의 SSH 자격 증명	설정 위생(hygiene) 문제이나, 에어갭 상태를 고려할 때 악용 가능성은 낮음
...

시사점 (Takeaway)

시사점 (Takeaway)

표준적인 AI 채팅 인터페이스 하에서의 구성: Alibaba Cloud 상의 Kubernetes pod, OverlayFS 컨테이너 루트(root), 영구적인 ext4 파티션, FUSE로 마운트된 에이전트 브리지(agent bridge), 전체 자동화 스택, 그리고 주거용 프록시 풀(residential proxy pool)을 통한 웹 접속.

에어갭(air-gap)은 작동하고 있습니다. 환경 내의 자격 증명(credential)과 감사 로그(audit logging)의 부재는 주목할 만한 위생(hygiene) 측면의 발견 사항입니다.

다른 분들이 GPT, Gemini, 또는 Claude의 샌드박스(sandbox) 환경을 프로파일링한 적이 있는지 궁금합니다. 인프라 패턴을 비교해 보는 것은 매우 흥미로울 것입니다.

방법론: 수동적 조사(passive inspection)만 수행, 표준 채팅 UI 사용, 공격 시도 없음.