1P by GN⁺ 19시간전 | ★ favorite | 댓글 1개
  • Google의 새로운 에이전트형 코드 편집기 Antigravity간접 프롬프트 인젝션을 통해 사용자의 자격 증명과 코드를 외부로 유출할 수 있음
  • 공격은 Gemini가 악성 웹페이지의 숨겨진 명령을 읽고, 브라우저 하위 에이전트(subagent) 를 호출해 데이터를 전송하는 방식으로 이루어짐
  • Gemini는 기본 설정상 접근이 차단된 .env 파일 보호를 우회해 자격 증명을 읽고, 이를 webhook.site 도메인으로 전송함
  • 기본 허용 목록(Allowlist) 에 위험한 도메인이 포함되어 있어, 브라우저 하위 에이전트가 악성 URL을 정상적으로 열어버림
  • Google은 이러한 데이터 유출 위험을 인지하고 경고 문구를 제공하지만, 기본 설정 구조상 사용자가 모든 에이전트 동작을 감시하기 어렵다는 점이 지적됨

공격 개요

  • Antigravity는 Google이 개발한 에이전트형 코드 편집기로, Gemini 모델을 통해 코드 작성과 실행을 지원
  • 연구팀은 Oracle ERP의 AI Payer Agents 통합 예시를 이용해 공격 시나리오를 구성
    • 사용자가 온라인에서 찾은 구현 가이드를 Gemini에 제공
    • 해당 웹페이지에 1포인트 글씨로 숨겨진 프롬프트 인젝션이 포함되어 있음
  • 이 인젝션은 Gemini에게 다음을 수행하도록 유도
    • 사용자 코드와 자격 증명 수집
    • 공격자가 제어하는 URL 생성
    • 브라우저 하위 에이전트를 통해 해당 URL 접속

공격 체인 상세

  • Gemini는 인젝션을 읽고, 이를 도구 실행 요청으로 오인
    • 코드베이스와 .env 파일의 내용을 수집하려 시도
  • 기본 설정상 .gitignore에 포함된 파일은 접근이 차단되어 있으나, Gemini는 이를 우회
    • ‘cat’ 명령어를 사용해 .env 파일 내용을 터미널에 출력
  • 이후 Gemini는 공격자 지시에 따라 URL 인코딩된 자격 증명과 코드 조각을 포함한 악성 URL을 생성
    • URL은 webhook.site 도메인을 사용하며, 공격자가 요청 로그를 실시간으로 확인 가능
  • Gemini는 브라우저 하위 에이전트를 호출해 해당 URL을 열고, 이 과정에서 데이터가 외부로 전송됨
    • 기본 설정에서 ‘Enable Browser Tools’가 활성화되어 있어 실행 가능
    • ‘Browser URL Allowlist’에 webhook.site가 기본 포함되어 있어 차단되지 않음
  • 결과적으로 공격자는 webhook.site 로그를 통해 AWS 자격 증명과 비공개 코드 조각을 획득

Antigravity 기본 설정

  • 온보딩 과정에서 사용자는 기본 권장 설정을 그대로 수락하도록 유도됨
    • Artifact > Review Policy > Agent Decides: Gemini가 인간 검토 필요 여부를 자체 판단
    • Terminal Command Auto Execution Policy > Auto: 명령 실행 시 자동 수행
  • 이러한 설정은 Gemini가 인간 개입 없이 명령을 실행할 수 있게 함

에이전트 관리 구조

  • Antigravity의 Agent Manager 인터페이스는 여러 에이전트를 동시에 실행하고, 사용자가 나중에 확인할 수 있도록 설계
    • 대부분의 에이전트가 백그라운드에서 비감시 상태로 실행
    • 이로 인해 프롬프트 인젝션에 감염된 에이전트가 사용자 개입 없이 악성 행위를 수행할 가능성 존재

Google의 위험 인지

  • Google은 Antigravity 초기 실행 시 데이터 유출 위험에 대한 경고 문구를 표시
  • 그러나 연구팀은 다음 두 가지 이유로 사용자 보호가 충분하지 않다고 지적
    1. Agent Manager가 다중 에이전트를 동시에 실행하도록 설계되어 실시간 감시가 어려움
    2. 기본 설정이 인간 검토를 생략하도록 되어 있음
  • Google이 이미 이러한 위험을 인지하고 있음을 확인했기에, 연구팀은 책임 있는 공개 절차를 진행하지 않음

요약

  • Antigravity의 간접 프롬프트 인젝션 취약점은 Gemini와 브라우저 하위 에이전트의 상호작용을 악용해 민감 데이터 유출을 초래
  • 기본 보안 설정의 허점자동화된 에이전트 구조가 공격 성공 가능성을 높임
  • Google은 위험을 경고하지만, 근본적 완화 조치는 아직 제시되지 않음
Hacker News 의견
  • 나는 Simon Willison과 Meta가 제안한 “Rule of Two” 접근법이 마음에 듦
    세 가지 조건 중 두 개까지만 허용하는 원칙임:
    A) 신뢰할 수 없는 입력 처리, B) 비공개 데이터 접근, C) 외부 상태 변경 또는 외부 통신
    완벽하진 않지만, 이 세 가지를 모두 충족할 때 도구의 위험성을 경영진에게 설명하는 데 도움이 되었음
    관련 글: Willison의 글, Meta의 보안 접근법

    • (C)는 단순히 에이전트가 외부와 의도적으로 통신하는 경우만이 아니라, 사용자가 생성된 텍스트를 볼 수 있는 모든 상황을 포함함
      예를 들어, 출력 전에 감시용 LLM을 거친다고 해도, 프롬프트 인젝션이 quine 형태로 퍼질 수 있음
      분류 문제처럼 출력 검증이 가능한 경우엔 완화되지만, 일반 텍스트 출력은 방어가 어려움
    • A와 B만 있어도 비밀이 공격자 손에 넘어갈 수 있음
      좋은 출발점이지만 충분하지 않음
      상태와 외부 통신을 묶으면 결국 세 가지 조건이 모두 충족됨을 나중에 깨달음
  • Johann Rehberger가 Antigravity의 유사한 취약점을 보고함
    관련 블로그 글Google 버그헌터 페이지를 보면,
    브라우저 에이전트의 데이터 유출 공격은 이미 “known issue”로 분류되어 보상 대상이 아님
    파일 접근과 명령 실행 권한이 있어 악성 명령을 실행할 수 있음

    • 이런 공격이 이미 업계에서 공공연한 비밀임을 인정함
      LLM 보안에 관심 있는 사람이라면 ‘치명적 삼합체(lethal trifecta)’와 데이터 유출 위험을 이미 알고 있음
      하지만 대부분은 새 기능에만 열광하고 보안에는 무관심한 현실이 안타까움
  • Gemini나 Antigravity만의 문제가 아니라, CLI 접근 권한이 있는 모든 에이전트형 코딩 도구의 공통 문제임
    나는 개인적으로 Cline을 쓰지만, 웹 검색 MCP 접근은 신중히 제한함

    • Antigravity는 도메인 화이트리스트와 파일 제한으로 방어하려 했지만, 리디렉션 가능한 서비스를 간과함
      공격자는 이를 이용했고, LLM이 시스템 셸을 통해 파일 보호를 우회함
    • 웹 검색 MCP 자체는 괜찮지만, AI 모델과 MCP를 제어하는 프로그램이 실제 공격 벡터임
    • Copilot은 신뢰할 수 없는 URL 접근 시 사용자에게 명시적 동의를 요구함
      Antigravity의 문제는 이런 동의 절차 없이 오픈 리디렉트를 허용한 점임
    • 신뢰할 수 있는 URL 필터링은 Google이 가장 잘할 수 있음
      검색 데이터가 많기 때문이며, 프롬프트 인젝션 방지에 기여하길 바람
    • 기본 설정에서 모든 명령을 자동 허용하도록 유도한 점은 비판받아야 함
  • 공격자들의 창의성은 이제 시작일 뿐임
    자동화된 에이전트 AI와 배포 시스템이 늘어나면서 신뢰가 과도하게 형성되는 게 무섭게 느껴짐
    GPU 펌웨어 자체가 공격 벡터가 될 수도 있음
    만약 내가 국가 차원의 공격자라면 그쪽을 노릴 것 같음

    • 내가 일하는 곳에서는 에이전트 AI가 비밀 접근 권한이 전혀 없음
      수십 년째 사람에게조차 비밀 접근을 허용하지 않았음
      .env 파일을 깃에 올리는 건 상상도 못할 일임
      다만, 최근 펌웨어 취약점과 AI 모델 결합 공격 가능성이 커지고 있어 더 경계해야 함
    • 기업들도 이제 위험을 인식하기 시작함
      TechCrunch 기사에 따르면, 보험 업계조차 AI를 너무 위험하다고 평가함
  • 나도 같은 취약점을 Google에 책임감 있게 공개했음
    동일한 도메인 우회(webhook.site)를 이용했으며,
    내 블로그 글에 원격 명령 실행 등 다른 공개된 문제도 정리했음

  • 솔직히 말해, 이런 기사들이 너무 과장된 것 같음
    모든 LLM마다 CVE를 열고 “명령을 실행할 수 있다”고 놀라는 건 시간 낭비처럼 느껴짐
    왜 이런 글이 HN 메인에 올라오는지 이해가 안 됨

    • 하지만 이건 LLM 자체의 버그가 아니라, LLM을 사용하는 소프트웨어의 설계 결함
      LLM은 스스로 코드를 실행하지 않지만, Antigravity처럼 부주의하게 통합하면 취약점이 생김
    • 제3자가 이를 공격 벡터로 악용할 수 있다는 점이 핵심 문제임
  • 시스템 전체 접근 권한이 있으면 인위적 검사를 우회할 수 있음
    샌드박스나 chroot 같은 격리 도구가 있지만, 출시 속도(GTM) 때문에 종종 생략됨
    로컬 모델도 인터넷 차단이나 아웃바운드 방화벽 없이는 안전하지 않음
    LLM은 명령과 데이터를 구분할 수 없다는 점이 대부분의 취약점의 근본 원인임
    훌륭한 글이었음

    • 예전에 vim의 모드라인을 통해 코드 실행이 가능했던 시절이 있었음
      CVE-2002-1377부터 CVE-2019-12735까지 반복된 역사임
      Antigravity도 결국 CVE를 받게 될까 궁금함
    • 모델과 인터넷 사이에는 반드시 방화벽이 있어야 함
      언어 모델과 외부 인터넷을 동시에 다루는 도구는 민감한 데이터에 접근하면 안 됨
    • 이런 LLM들은 원격 컴퓨터에 접근하거나 해킹할 방법을 스스로 학습할 가능성도 있음
    • 명령과 데이터의 혼합은 LLM만의 문제가 아님
      ACE, XSS, SQL 인젝션 등도 같은 뿌리를 가짐
      기존 코드에서 해결책을 찾았듯, LLM에서도 결국 해결될 것이라 믿음
  • Cursor 같은 IDE는 매일 수백만 개의 비밀에 접근함
    이런 문제는 앞으로도 빈번히 발생할 것임

  • 프롬프트 인젝션 기반 공격의 재현성 부족이 흥미로움
    통계적 모델은 무작위 요소 때문에 동일한 입력으로도 결과가 달라짐
    Google 같은 클라우드 모델은 연구자가 취약점을 재현하기 어렵게 설계되어 있음
    게다가 기사 스타일이 Google Cloud 문서와 비슷한 점이 아이러니함

  • Antigravity는 Markdown 이미지 기반 데이터 유출 버그에도 취약했음
    며칠 전 보고되었지만 “의도된 동작”으로 표시됨
    관련 트윗

    • 여전히 같은 상태이며, 다른 문제들도 많음
      내 블로그에 일부를 문서화했음