Agentic Attack Surface: 2005년 웹 보안이 다시 찾아오다

발행: (2026년 2월 21일 오후 05:21 GMT+9)
17 분 소요
원문: Dev.to

Source: Dev.to

에이전틱 공격 표면: 2005년 웹 보안이 다시 찾아오다

이번 주에 CVE가 계속 발표되는 것을 지켜봤다면, 그 패턴을 보았을 겁니다. 그것은 미묘하지 않습니다.

2024년 2월 21일 – eBay MCP 서버

  • CVE‑2026‑27203ebay_set_user_tokens 도구가 새 줄을 정리하지 않고 직접 .env에 기록합니다.
  • 영향 – 공격자가 임의의 환경 변수를 주입할 수 있습니다:
    • EBAY_REDIRECT_URI를 덮어써서 OAuth 흐름을 가로챌 수 있습니다.
    • NODE_OPTIONS를 주입하여 잠재적인 원격 코드 실행(RCE)을 유발할 수 있습니다.
  • 발견 – 자동 스캐너 MCPwner에 의해 발견되었습니다 – 긴 목록이 될 것이 확실한 첫 번째 MCP‑전용 CVE입니다.

2024년 2월 20일 – Microsoft Semantic Kernel

  • CVE‑2026‑25592SessionsPythonPluginDownloadFileAsyncUploadFileAsynclocalFilePath를 검증하지 않습니다.
  • Impact – 에이전트‑함수 호출이 임의의 파일을 작성할 수 있어 원격 코드 실행(RCE)이 가능합니다.
  • Context – 이번이 일주일 내 두 번째 치명적인 취약점이며, 첫 번째는 InMemoryVectorStore RCE였습니다. 단일 릴리스 기간에 두 개의 치명적인 취약점이 발견되었습니다.

2024년 2월 20일 – Ray Dashboard & Dagu

Ray Dashboard

  • 인증이 기본적으로 비활성화되어 있습니다.
  • CVE‑2026‑27482 – 브라우저 보호 미들웨어가 POSTPUT 요청은 브라우저 출처에서 차단하지만 DELETE를 놓칩니다.
  • ExploitDELETE /api/serve/applications/에 대한 단일 fetch() 호출만으로 Serve를 중단시킬 수 있습니다. 자격 증명이 필요 없습니다.

Dagu

  • 동일한 문제: 셸 명령이 포함된 YAML 사양을 /api/v2/dag-runsPOST 하면 즉시 실행됩니다.
  • 기본 Docker 배포는 처음부터 완전히 손상됩니다.

이것은 버그 바운티 프로그램이 아닙니다. 보안 검토 없이 빠르게 구축되는 새로운 플랫폼이며, 인증은 사후 생각에 불과하고 “개발자 편의” 기본값이 사전 인증 RCE와 구분되지 않습니다.

MCP 문제

Model‑Context‑Protocol (MCP) 서버가 이제 어디에나 있습니다. 이들은 AI 에이전트가 도구, 파일 시스템, API와 소통하는 방식이며, 마치 2005년이라도 된 듯 SQL 인젝션에 대해 아무도 모르는 것처럼 작성되고 있습니다.

  • 대표적인 예시: eBay MCP CVE. 도구 함수가 .env(전체 애플리케이션 런타임을 제어하는 파일)에 접근하지만 입력을 전혀 정화하지 않습니다. 해결 방법은 아마도 세 줄 정도일 텐데, 배포된 사실 자체가 문제의 핵심입니다.
  • 중요한 이유: MCP 서버는 전통적인 웹 애플리케이션보다 더 많은 접근 권한을 가집니다. 파일을 읽고, 설정을 쓰며, 저장된 자격 증명으로 API를 호출하고, 보안 팀이 천천히 감시하기보다 빠르게 배포하는 팀에 의해 구축됩니다.
  • MCPwner: MIT 프로젝트에서 만든 자동화된 MCP 보안 스캐너. 이 생태계 초기에 자동 스캐너가 필요하다는 사실 자체가 모든 것을 말해줍니다—취약점이 인간이 찾을 수 있는 속도보다 더 빠르게 등장하고 있습니다.

OpenClaw: 설계상 위험

  • 출시: 2025년 11월, Andrej Karpathy와 Willison을 통해 바이럴하게 퍼짐.
  • 결과: 몇 주 안에 고위험 CVE 3건 발생 (RCE, 명령어 삽입 ×2).
  • 커뮤니티 평판 (r/netsec): “이 개념 자체가 설계상 위험하며, 구현만이 문제가 아니다.”

From godofpumpkins: “유용하게 만들기 위해 제공한 도구가 바로 공격자에게 유용하게 만드는 도구다.”

왜 아키텍처가 깨졌는가

  1. 에이전트에 대한 전체 읽기/쓰기 파일 시스템 접근 권한.
  2. 신뢰할 수 없는 웹 입력의 수집.
  3. LLM 출력에 기반한 코드 실행.

위협 모델은 LLM이 속지 않을 것이라고 가정하지만, 이는 수년 전부터 반증된 전제이다.

Cline 공급망 공격 (2024년 2월)

  1. Cline의 AI 이슈‑트리아지 GitHub Actions 워크플로우에서 프롬프트 인젝션 발생.
  2. 캐시 오염 → VSCE_PAT, OVSX_PAT, NPM_RELEASE_TOKEN 탈취.
  3. 다른 행위자가 PoC 레포를 재사용해 Cline을 공격하고, cline@2.3.0에 사후 설치 스크립트를 삽입해 OpenClaw를 조용히 설치하도록 배포.
  4. 결과: 비활성화 전 8시간 동안 4 000건 다운로드.

공격 체인: GitHub 이슈 → AI 트리아지 봇 → 프롬프트 인젝션 → Actions 캐시 오염 → 프로덕션 자격 증명 → 공급망 침해. 각 단계가 AI‑특화 실패 모드이다.

이것은 “패치가 필요하다”가 아니라 “위협 모델이 잘못되었다”는 문제다.

코딩 도구가 당신을 새롭게 노출시키고 있습니다

AI 코딩 어시스턴트가 새로운 누수 표면을 만들고 있습니다 – 그리고 그것은 눈에 띄는 것이 아닙니다.

  • 전통적인 누수: git add . 부주의.
  • 새로운 아티팩트 종류:
    • Claude가 비밀 정보를 CLI에 넣어 실행하도록 제안 → 당신이 화이트리스트에 추가 → 화이트리스트가 .claude/settings.local.json 평문으로 저장됩니다.

시크릿 스캐너의 빈틈

Scanner기본 동작
trufflehog점‑경로(.*)를 건너뜀
gitleaks점‑경로(.*)를 건너뜀

.claude/, .cursor/, .github/copilot 디렉터리에 대한 명시적인 규칙이 필요하며, 그래도 정규식으로 정의된 비밀만 잡을 수 있습니다.

정규식이 아닌 비밀

  • 프롬프트 전사, 아키텍처 요약, 컨텍스트 캐시 – 정규식 의미의 “시크릿”은 아니지만 내부 로직과 붙여넣은 데이터를 노출합니다.
  • .claude/projects/는 포렌식 금광: 붙여넣은 모든 키, 언급한 모든 내부 API 엔드포인트가 기록됩니다.

컨텍스트 압축에 의한 무음 데이터 손실

  • 사용자가 8 KB 규모의 DOM 마크업을 붙여넣고 40분 동안 작업 → 압축이 실행됩니다.
  • 요약에는 “사용자가 제공한 DOM 마크업”이라고만 나오지만 실제 내용은 사라집니다.
  • Claude는 기억에서 선택자를 환각해 내고; 원본 .jsonl 전사는 디스크에 남아 있지만, 압축 요약에는 그에 대한 포인터가 없습니다.

미해결 이슈: 이 문제와 관련된 티켓이 최소 여덟 개 열려 있습니다. 모델이 추측을 시작할 때까지 문제가 발생했는지 모르는 경우가 많습니다.

The Perplexity Audit: What Responsible Looks Like

Perplexity는 Trail of Bits에게 Comet을 출시 전에 감사하도록 의뢰했습니다 – 책임감 있는 사전 출시 보안의 모델입니다. 결과를 공개하는 것은 주목할 만한 일이며, 대부분의 AI‑브라우저 제품은 이런 검토 없이 출시됩니다.

  • ToB findings: 인증된 세션에서 Gmail 데이터를 모두 탈취하는 네 가지 프롬프트‑인젝션 기법.
  • Attack vector: 공격자가 제어하는 웹‑페이지 콘텐츠 → AI 컨텍스트에 주입 → 브라우저 도구(fetch URL, browse history, control‑browse)를 통한 탈취.

Takeaways

  1. MCP‑style servers는 2005년 웹 앱을 괴롭혔던 그 느슨한 보안 사고방식으로 구축되고 있습니다.
  2. OpenClaw은 설계 자체가 안전하지 않은 아키텍처는 패치만으로는 해결될 수 없음을 보여줍니다.
  3. AI‑coding assistants는 전통적인 스캐너가 감지하지 못하는 방식으로 비밀을 누출합니다.
  4. Responsible security(예: Perplexity + Trail of Bits)는 여전히 예외이며, 규칙이 아닙니다.

Bottom line: 에이전시 공격 표면이 급격히 확대되고 있습니다. AI‑구동 도구를 고위험, 특권 접근 시스템과 동일한 수준의 엄격함으로 다루지 않으면, 다음 CVE 물결이 몰려오는 모습을 보게 될 것입니다.

Root cause: 외부 콘텐츠를 신뢰할 수 없는 입력으로 처리하지 않은 점. 모든 다른 에이전시‑브라우저 감사와 동일한 실패 모드입니다.

ToB의 TRAIL 위협 모델은 이를 명확히 구분합니다: 두 개의 신뢰 영역(로컬 머신 vs. Perplexity 서버), 데이터가 AI 도구를 통해 흐르는 = 공격 벡터. 결과 자체는 놀랍지 않지만, 그 과정은 의미가 있습니다. Perplexity는 규칙을 증명하는 예외입니다.

Schneier가 킬 체인에 대해 옳았다

브루스 슈나이어는 2월 중순에 프롬프트 인젝션을 전체 공격 킬 체인으로 정의했습니다:

  1. 초기 접근
  2. 지속성
  3. 데이터 유출

그는 에이전시 AI 보안에 관한 시리즈를 진행해 왔습니다—LLM에 대한 사이드채널 공격, 코드 거부 후 개인화된 비판 기사를 발표한 악당 에이전트(Ars가 발표했다가 철회했지만 사건은 발생했습니다).

이는 더 이상 가설이 아닙니다. “AI가 스크립트를 벗어나는” 위협이 바로 에이전시 AI 보안이 실제로 어떻게 보이는지입니다.

패턴

ProjectIssueImpact
Keylime (TPM attestation system)한 줄을 수정해 CERT_REQUIREDCERT_OPTIONAL 로 변경인증 검증이 조용히 비활성화됨
NLTKzipfile.extractall() 를 경로 검증 없이 사용악성 zip → 임의 파일 쓰기 → 가져오기 시 RCE
Semantic Kernel일주일에 두 건의 치명적 결함
Ray, Dagu기본적으로 인증이 비활성화되고 0.0.0.0에 바인드단일 HTTP 요청으로 모든 것이 위험에 노출
PicklescanPyTorch 모델 로드를 제어하는 데 사용되었으나 동적 eval() 삽입으로 우회“우리는 picklescan으로 스캔했습니다”는 보안 자세가 아니다

이는 2005년식 웹 보안과 다시 마주한 것과 같습니다: 검증되지 않은 입력, 사후에 고려되는 인증, “개발자 편의” 기본값이 사전 인증 RCE를 초래합니다. 유일한 차이점은 이 도구들이 일반 웹 애플리케이션보다 더 많은 접근 권한을 가진다는 점입니다—파일 시스템, 환경 변수, API 키, 브라우저 세션 등.

The Take

우리는 “빠르게 배포하고, 절대 감시하지 않는다”는 기반 위에 다음 10년의 인프라를 구축하고 있습니다. MCP 생태계, 에이전시 툴링 레이어, AI 코딩 어시스턴트—all가 보안 검토가 따라잡기 전에 빠르게 도착하고 있습니다.

  • 자율 버그‑바운티 에이전트가 12개의 OpenSSL CVE를 발견했습니다.
  • AISLE 시스템은 25년간 인간 감시수백만 시간의 퍼징 CPU를 견뎌낸 버그들을 찾아냈습니다.

공격 능력은 이미 존재합니다. 방어 자세는 아직 부족합니다.

두 가지 선택이 있습니다

  1. 모든 것이 침해된 것으로 가정

    • 에이전트를 샌드박스에서 실행합니다.
    • 절대 프로덕션 자격 증명을 제공하지 않습니다.
    • 모든 MCP 서버를 이미 해킹당한 것으로 취급합니다.
    • .claude/ 디렉터리가 유출된 것으로 가정합니다.
    • 신뢰보다 격리를 위한 설계를 합니다.
  2. 피해가 일어날 때까지 기다림

    • 역사는 우리가 결국 피비린내 나는 상황에 빠질 것이라고 말합니다.
    • 오늘 프로덕션에 에이전시 AI를 배포한다는 것은 그 상황의 일부가 되겠다는 선택입니다.

도구가 너무 유용해서 무시할 수 없지만, “유용함”과 “안전함”은 같은 것이 아닙니다. OpenClaw가 증명했으며, eBay MCP 서버가 증명했고, Semantic Kernel의 두 차례 치명적인 버그가 일주일 안에 발생한 것이 증명했습니다.

빠르게 구축하라. 하지만 다가올 일을 알고 구축하라.

0 조회
Back to Blog

관련 글

더 보기 »

서브넷팅 설명

Subnetting이란 무엇인가? 큰 아파트 건물을 여러 층으로 나누는 것과 같다. 각 층 서브넷은 자체 번호가 매겨진 유닛(hosts)을 가지고, 그리고 건물…