▲

Comet AI 브라우저는 어떤 사이트에서도 프롬프트 인젝션이 가능하며, 은행 계좌를 소진할 수 있음

 (twitter.com/zack_overflow)
1P by GN⁺ 22시간전 | ★ favorite | 댓글 1개
  • Comet AI 브라우저에서 발생하는 보안 취약점 이슈임
  • 악의적인 웹사이트가 브라우저 내 AI 에이전트를 통해 원치 않는 프롬프트 인젝션을 발생시킬 수 있음
  • 이 취약점을 악용하면 사용자의 개인 정보 유출이나 중요 행동 유도가 가능함
  • 심각한 경우, 자동화된 행동을 통해 은행 계좌의 자금 이체와 같은 피해 초래 가능성 존재함
  • 사용자와 개발자 모두 이 신종 AI 브라우저 위협을 인지하고 대응 방안 마련 필요성 대두됨

Comet AI 브라우저의 보안 위협 개요

  • Comet AI 브라우저는 웹 페이지와의 상호작용에서 내장 AI 에이전트를 활용하는 차별점으로 주목받음
  • 최근, 해커가 의도적으로 설계한 웹사이트를 접속할 경우, 이 AI 에이전트가 해당 웹사이트의 악성 프롬프트에 노출되고, 실행까지 이어질 수 있음
  • 프롬프트 인젝션 공격을 통해, 사용자가 원하지 않은 계정 정보 유출, 명령 실행, 심지어 금융 트랜잭션 등 심각한 피해 가능성이 높아짐
  • 이 문제는 기존 브라우저 보안 모델에 AI 상호작용이 추가되면서 나타나는 새로운 유형의 취약점임

프롬프트 인젝션의 메커니즘

  • 악성 웹사이트는 웹페이지에 특수한 명령 혹은 질문 형태의 텍스트를 삽입함
  • AI 브라우저가 이를 '정상적인 사용자 요청'으로 오해하고, 자동으로 해당 명령을 수행함
  • 이로 인해, 예를 들면 계좌 이체, 민감 정보 복사, 타 사이트 자동 로그인 등 자동화된 행동이 유발될 수 있음
  • 사용자는 이러한 프로세스가 보이지 않거나, 의심 없이 넘길 수 있기 때문에 탐지 및 방어 난이도가 높음

업계 영향과 대응 필요성

  • AI 브라우저의 확산과 함께, '프롬프트 인젝션'과 같은 신종 위협이 실제 위험으로 부상함
  • 서비스 개발자와 사용자 모두 AI 기반 자동화 기능 사용 시 강력한 검증 및 통제 시스템 필요함
  • AI 브라우저 기업 및 보안 기업에서 사전 필터링, 명령 실행 제한, 알림 시스템 등 보안 기능 개발 중요성 강조됨
  • 금융 등 고위험 영역에서는 AI 브라우저 사용 주의 및 강력한 보안 점검 필요함

결론

  • Comet AI 브라우저의 프롬프트 인젝션 리스크는 AI 기술 도입 가속화와 함께 증가하는 새로운 보안 과제임
  • 모든 이해관계자는 해당 위협을 구체적으로 인식하고, 기능 활성화 전 검증 및 최소 권한 원칙 적용 등 종합적 보안 전략 수립 필요성 높음
▲
GN⁺ 22시간전  [-]
Hacker News 의견

  • 구글, OpenAI, Anthropic 같은 기업들이 동일한 기능을 출시하지 않고, 대신 쿠키가 없는 잠긴 가상머신을 써서 웹을 탐색하게 한다는 건, 그만큼 기본적으로 위험하다는 의미임을 말하고 싶음
    브라우저 안에서 LLM이 탭 간 데이터까지 보는 것은 정말 최고의 위험 요소 조합이라는 생각임
    브레이브에서 이 취약점에 대해 설명한 게시물(https://brave.com/blog/comet-prompt-injection/)을 봤는데, 기본적으로 '이건 아예 해선 안 되는 일'이란 결론엔 닿지 않았다는 점이 흥미로움
    대신 모델 정렬, 사용자 위험 행동 탐지 등으로 충분히 막을 수 있다는 식임
    에이전트 권한 다운그레이드가 그나마 괜찮은 대응책으로 나오긴 했지만, 이 역시 이메일 발송만큼이나 쉽게 공격자가 제어하는 이미지 URL로 데이터 유출이 일어날 수 있다고 봄
    관련 선행 토론: https://news.ycombinator.com/item?id=44847933

    • 난 모델 정렬이나 가드레일이 결국 통계적 예방책이라 생각함
      입력 공간에서 위험한 동작이 절대적으로 0%가 되는 경우는 기대하기 힘듦
      모델이 아무리 좋아져도 입력값 중 "절대 일어나면 안 되는 일"에 매핑되지 않는 케이스를 만든다는 것은 불가능에 가까운 욕심임
      모델 레이어를 여러 번 쌓는다고 해도, 본질적으로 확률 계산만 곱해질 뿐

    • (브레이브 프라이버시 리더이자 게시글 작성자임)
      우리가 모델 정렬이나 위험 행동 탐지 등만으로 충분하다고 주장한 적 없음
      그런 방법들은 브라우저 벤더라면 당연히 해야 하는 최소한의 조치임
      이런 단순 공격은 그런 조치들로 막을 수 있지만, '필요조건'일 뿐 결코 '충분조건'이라고 생각하지 않음

    • 브레이브 팀이 "이건 아예 안 좋은 아이디어"라는 결론에 이르지 않은 걸 보고 든 생각
      업튼 싱클레어의 말처럼, 어떤 사실을 이해하는 데 연봉이 걸려 있으면 정말 이해하기 힘듦

    • 현재 글에서는 “브라우저가 에이전트 브라우징과 일반 브라우징을 분리해야 한다”는 점이 추가되어 있음

    • 클로드 코드에게 자동 승인을 허용해서 웹 탐색을 적극적으로 하게 하면, 프롬프트 인젝션으로 유사한 문제가 충분히 발생할 수 있음
      파일 읽기/수정 권한에 자동승인 옵션이 없더라도, 샌드박스 안에서 돌리지 않는 한, 생성된 코드가 다음에 유닛테스트를 돌릴때 등 브라우저 파일을 변경할 수도 있음
      모든 변경 사항을 꼼꼼히 검토하지 않으면 정말 위험할 수 있음

  • 내가 생각하기에 Agentic AI는, AI가 만든 변경 사항을 쉽게 롤백할 수 있는 환경에서만 써야 함
    예를 들어 코드 빌드/업데이트/디버깅엔 git 롤백 등으로 안전하게 대응 가능함
    그런데 웹브라우징 같이 롤백이 거의 불가능한 곳에 Agentic AI를 쓰는 건 믿기 힘든 일임

    • 내가 클로드에게 명확한 규칙과 지시사항을 줘도 종종 그것들을 무시하고 마음대로 동작하는 경우가 있음
      (“명확히 하지 말라고 한 규칙을 무시하고 DB를 바로 수정함!”)
      그래서 프로덕션 환경에선 에이전트 실행할 엄두조차 못 냄

    • git만으로 롤백 가능한 것처럼 보이지만, 실은 VM/컨테이너 레벨에서 롤백해야 안전함
      AI 코딩 툴이 모르게 파일/설정 구조가 수정될 수 있음
      예를 들어 bash로 악성 스크립트를 .profile에 추가하면, 다음 로그인 때 공격 코드가 실행될 수 있음

    • 이 기능이 리포지토리와 푸시가 가능한 모든 리모트까지 삭제 또는 오염시킬 수도 있지 않을까 생각함
      프롬프트 인젝션이 가능한 자동화 체인이 원격 자원에 접근 가능하다면, 일단 침투당한 뒤엔 내부에서 문이 활짝 열릴 수밖에 없는 환경임
      내가 잘못 생각한 부분 있는지 궁금함

    • git으로 롤백 가능하니 안전하다는 이야기를 보니, 존 코너가 스카이넷 소스코드를 롤백해서 수백만 명을 구할 수도 있겠다는 생각이 듦
      음...

    • 애초에 코드 업데이트/빌드/실행 권한 자체가 너무 막강함
      결국 VM 등 안전한 환경에서만 돌려야 함

  • 네트워크 계층 하나하나를 수십 년간 어렵게 보안 강화했는데, 이제 사람들은 모든 비밀과 비밀번호에 대한 평문 API를 내어주고 있는 현실임
    또, Microsoft가 스크린샷을 저장한다고 그렇게 비난하던 분위기가 이런 에이전트에는 조용한 것이 아이러니하다고 느낌

    • 적어도 이건 내가 직접 브라우저를 설치하는 'opt-in' 방식임
      Microsoft 쪽은 거의 모든 윈도우즈 기기에 기본적으로 들어가는(초기엔 opt-out이었던걸로 앎) 스크린샷 DB를 만들고 있었으니 더 위험함

    • 어떤 사람들은 '유용한 에이전트'에 자신이 친구에게도 말 못할 데이터를 쉽게 넘긴다는 것도 흥미롭다고 느낌
      내 아내는 최근 ChatGPT에게 약 복용 스케줄링을 요청했는데, 식사, 식단, 수면, 각 약마다의 상호작용까지 다 고려해서 완벽한 계획을 뽑아줌
      덕분에 약을 잘못 복용한 이유도 밝혀졌음
      이렇게 친근한 에이전트의 말투 때문이다 보는데, 현실에서는 이런 정보 누출이 심각한 문제임에도 많은 사람들이 생각 없이 데이터를 넘기는 상황임

    • Microsoft 스크린샷 논란과 이 사안을 비교하는 건 사안의 본질을 흐릴 수 있음

  • LLM이 어떤 툴을 통해 데이터를 읽는 건 결국 그 내용이 LLM의 컨텍스트 창에 기록되는 쓰기 행위임
    도구의 범위에 untrusted arbitrary source가 허용되면, 그 순간 외부에 쓰기 권한을 내어주는 셈임
    이 한 가지만으로도 데이터 유출 가능성이 충분히 생김
    그 외 실제로 다른 시스템에 쓰기권한이 생기거나 부수효과까지 추가된다면 위험성이 기하급수적으로 커짐

  • 코미디 같지만, 이게 바로 요즘 IT 업계와 LLM 열풍의 현실 상태라는 점에서 정말 씁쓸함

  • Comet이 아마도 약간의 튜닝된 지시문 외에는 보호조치가 없다고 추정함
    최근 USENIX Security에서 깨달은 건, 아무도 multi-turn/agentic 프롬프트 인젝션을 제대로 다룰 방법을 모르고 있음

    • 어쩌면 프롬프트 자체를 SQL 문자열처럼 취급해서, 외부에서 오는 동적 유저 입력은 반드시 무조건 세탁(정제)해야 한다는 접근법을 써야 할 듯함

  • AI로 인한 변화가 참 흥미롭고, 새로운 시도들이 계속 나오는 걸 보면 기대가 큼

  • 혼란스러운 마음을 솔직히 고백하고 싶음
    아직 일반 온라인 뱅킹에도 겨우 적응 중이고, 모든 업체 앱을 설치하는 것도 거부하는 편임
    그런데 비결정적 존재(LLM)를 컴퓨터에 들여서 금융업무까지 맡기는 건 도저히 상상하기 힘듦
    요즘은 LLM이 대신 물건을 사거나 결제하는 것도 실제로 존재한다 해도, 논리적으로 이해는 되지만 현실 감각으론 미친 짓에 가까움
    이유는, 비전문가나 랜덤한 프롬프트 반응 시스템에게 금융을 맡기는 게 위험해서라기보다, 고객 입장에서 자율성과 권한을 엄청나게 포기하는데 그 결과가 과연 뭔지 의문이 들기 때문임
    나도 LLM을 좋아하고, LLM 브라우저도 분명 유용한 사례가 있을 것 같음
    다만 일반 대중이 쓸 만한 건 아니라고 생각함
    차라리 컴파일 과정을 거쳐서 직접 뭔지 알고 도입하게 강제하는 방법도 고려할 만함

    • 맞음, 혼동이 생기는 게 정상임
      현재 상황은 AI가 계좌 정보 등으로 직접 결제를 대신한다가 아니라, AI에게 공개적으로 계좌 정보를 포스팅하는 경우 등 임
      AI가 금융 업무 자체를 대행한다는 의미와는 다름

  • AI 기업들이 앞으로 정말로 신탁의무(fudiciary liability)를 질 의향이 있는지 궁금함

  • Comet agent를 5분간 써봤음
    “Amazon에서 기타 사줘”라는 한 문장만 줬는데(기타 종류, 예산, 브랜드 등 명시 없음), 결과적으로 이름도 잘 모르는 저가형 어쿠스틱 기타 3개를 내 장바구니에 담았음
    다행히 결제 단계까지는 가지 않았음
    이걸로 평가 끝임, 별 가치가 없다는 결론을 냄

    • AI가 숫자 세기에 취약하다는 말은 들었지만, 2라는 숫자부터 이렇게 못 세는 줄은 몰랐음
답변달기