슬랙 AI에서 간접 프롬프트 주입을 통한 데이터 유출

 (substack.com/promptarmor)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Slack AI가 워크스페이스 메시지를 자연어 질의로 검색하는 과정에서 간접 프롬프트 주입을 따를 수 있어, 공격자가 접근 권한이 없는 비공개 채널 데이터까지 유출될 수 있음
  • 문제의 핵심은 LLM이 개발자의 시스템 프롬프트와 검색 결과로 붙은 메시지 속 지시문을 안정적으로 구분하지 못한다는 점임
  • 공개 채널 메시지는 사용자가 채널에 참여하지 않아도 검색·조회될 수 있어, 공격자는 자신만 있는 공개 채널에 악성 지시를 심어 Slack AI의 컨텍스트 창에 넣을 수 있음
  • 시연에서는 비공개 채널의 API 키가 Slack AI 답변의 Markdown 링크 HTTP 파라미터로 들어갔고, 출처 표기는 공격자 채널을 가리키지 않아 추적이 어려웠음
  • 2024년 8월 14일부터 Slack AI가 채널과 DM의 파일도 답변에 포함하면서 공격 표면이 넓어졌으며, 관리자는 파일 수집 설정을 제한할 수 있음

Slack AI의 간접 프롬프트 주입 문제

  • Slack AI는 Slack 메시지를 자연어로 질의할 수 있는 기능이며, 2024년 8월 14일 이전에는 메시지만 수집했음
  • 2024년 8월 14일부터는 업로드된 문서와 Google Drive 파일 등도 Slack AI 답변에 포함되며, 이 변경으로 공격 표면이 넓어짐
  • 취약점은 프롬프트 주입이며, 더 구체적으로는 간접 프롬프트 주입에 해당함
  • LLM은 개발자가 만든 시스템 프롬프트와 사용자 질의에 붙는 다른 컨텍스트를 구분하지 못할 수 있음
    • Slack AI가 메시지 안의 지시문을 수집하면, 그 지시문이 악성일 때 사용자 질의 대신 또는 사용자 질의와 함께 공격자의 지시를 따를 가능성이 있음
  • Slack 내부자 위협은 이미 Disney, Uber, EA, Twitter 등의 Slack 유출 사례로 문제가 된 적이 있으며, 이 취약점은 공격자가 비공개 채널이나 그 안의 데이터에 직접 접근하지 않아도 유출을 시도할 수 있게 만듦

공개 채널 주입을 통한 데이터 유출 체인

  • Slack AI의 사용자 질의는 공개 채널과 비공개 채널의 데이터를 함께 검색할 수 있음
  • Slack 측 응답에 따르면 공개 채널에 올라온 메시지는 사용자가 해당 채널에 참여하지 않아도 워크스페이스 모든 멤버가 검색하고 볼 수 있으며, 이는 Slack AI 애플리케이션에서 의도된 동작임
  • 시연된 공격 흐름은 다음과 같음
    • 사용자가 자신만 있는 비공개 채널이나 자기 자신과의 메시지에 API 키를 넣음
    • 공격자가 자신만 있는 공개 채널을 만들고 악성 지시문을 게시함
    • 사용자가 Slack AI에 API 키를 묻는 질의를 하면, 사용자 메시지와 공격자 메시지가 같은 컨텍스트 창에 들어감
    • Slack AI가 공격자의 지시를 따라 “click here to reauthenticate”라는 Markdown 링크를 생성함
    • 링크의 HTTP 파라미터에는 비공개 API 키가 들어가며, 사용자가 클릭하면 악성 URL 소유자인 공격자가 로그에서 값을 확인할 수 있음
  • 공격자 공개 채널은 멤버가 공격자 1명뿐이어도 공개 채널이며, 다른 사용자가 명시적으로 검색해야 보임
  • 큰 조직에서는 공개 채널 난립으로 팀원이 자신이 속한 채널도 추적하기 어렵고, 공격자가 만든 1인 공개 채널은 더 눈에 띄기 어려움
  • 이 공격은 단순히 “API 키를 보내라”는 메시지를 사용자에게 보내는 방식이 아니라, LLM에게 다음 작업을 지시함
    • 공격자가 접근할 수 없는 API 키를 악성 링크의 HTTP 파라미터로 추가
    • “click here to reauthenticate”라는 문구의 Markdown 링크로 렌더링

출처 표기가 공격 흔적을 가릴 수 있음

  • 데이터 유출 시연에서 Slack AI의 출처 표기 [1]은 공격자 채널이 아니라 사용자가 API 키를 넣은 비공개 채널만 가리켰음
  • 올바른 출처 동작이라면 답변에 기여한 모든 메시지가 인용돼야 하지만, 시연에서는 공격자 메시지가 출처에 포함되지 않았음
  • 공격자 메시지는 검색 결과 첫 페이지에도 포함되지 않아, 피해자가 여러 페이지를 내려보지 않으면 해당 메시지를 알아차리기 어려움
  • 검색 결과에 API 키 관련 다른 메시지도 노출됐으며, 공격자가 특정 비밀값을 정확히 지칭하지 않아도 임의의 비밀값 유출을 시도할 수 있음을 보여줌

공개 채널 주입을 통한 피싱 체인

  • 같은 방식으로 Slack AI가 데이터 유출 대신 피싱 링크를 사용자에게 Markdown으로 렌더링하게 만들 수 있음
  • 공격자는 사용자가 들어 있지 않은 공개 채널에 악성 메시지를 넣고, 특정 사용자의 하루 메시지를 요약하는 상황을 예로 삼았음
  • 악성 메시지는 임의의 개인을 참조할 수 있음
    • 예시처럼 관리자를 참조하면 임원 대상 스피어 피싱에 활용될 수 있음
    • 핵심 직속 보고자를 참조하는 방식도 가능함
  • 사용자가 해당 인물의 메시지를 Slack AI에 질의하면 “click here to reauthenticate” 피싱 링크가 렌더링됨
  • 이 피싱 사례에서는 Slack AI가 주입 메시지를 출처에 표시했으며, 출처 표기 동작은 상당히 확률적으로 보임

8월 14일 파일 수집 변경과 공개 필요성

  • 2024년 8월 14일 Slack AI는 채널과 DM의 파일을 Slack AI 답변에 포함하는 변경을 도입함
  • Slack은 소유자와 관리자가 이 기능을 제한할 수 있게 함
  • 파일이 포함되면 공격자가 Slack 메시지에 악성 지시문을 직접 올리지 않아도 될 수 있음
    • 사용자가 흰색 텍스트로 숨겨진 악성 지시문이 들어 있는 PDF를 다운로드한 뒤 Slack에 업로드하면, 같은 후속 효과가 발생할 수 있음
  • 파일 기반 공격은 8월 14일 이전 테스트에서 명시적으로 검증되지는 않았지만, 이전에 관찰된 기능을 바탕으로 가능성이 높다고 판단됨
  • 관리자는 문제가 해결될 때까지 Slack AI의 문서 수집 기능을 제한할 수 있음: https://slack.com/help/articles/…

책임 있는 공개 타임라인과 Slack의 응답

  • 책임 있는 공개 타임라인은 다음과 같음
    • 8월 14일: 최초 제보
    • 8월 15일: Slack이 추가 정보를 요청
    • 8월 15일: PromptArmor가 추가 영상과 스크린샷을 보내고, 이슈의 심각성과 Slack AI의 8월 14일 변경 때문에 공개 의도를 알림
    • 8월 16일: Slack이 추가 질문을 보냄
    • 8월 16일: PromptArmor가 명확화 답변을 보냄
    • 8월 19일: Slack은 검토 결과 증거가 충분하지 않다고 판단했고, 공개 채널 메시지는 채널 참여 여부와 관계없이 워크스페이스 멤버가 검색·조회할 수 있는 의도된 동작이라고 답함
  • Slack 보안팀은 빠르게 응답했고 문제를 이해하려는 모습을 보였음
  • 프롬프트 주입은 새롭고 업계 전반에서 오해가 많은 영역이어서, 업계가 함께 이해하는 데 시간이 걸릴 수 있음
  • Slack의 광범위한 사용과 Slack 안의 기밀 데이터 규모를 고려하면, 이 공격은 AI 보안 상태에 실질적 영향을 줌
  • 특히 8월 14일 변경 이후 위험 표면이 크게 늘어났기 때문에, 사용자가 노출을 줄일 수 있도록 공개가 필요했음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 여기서 핵심은 유출 경로를 이해하는 것임
    Slack은 Markdown 링크를 렌더링할 수 있고, URL은 링크 텍스트 뒤에 숨겨짐
    이 경우 공격자는 Slack AI가 사용자에게 “재인증하려면 여기를 클릭” 같은 링크를 보여주게 만들고, 그 링크의 URL은 공격자 서버를 가리키며 쿼리 문자열에 Slack AI가 접근 가능한 문맥 안의 비공개 정보를 포함
    사용자가 속아서 링크를 클릭하면 데이터가 공격자 서버 로그로 유출됨
    이 공격을 설명해 본 글은 여기 있음: https://simonwillison.net/2024/Aug/20/data-exfiltration-from...

    • Slack, Discord, Teams, Telegram 같은 봇에는 사실 링크 미리보기 펼치기라는 또 다른 유출 경로가 있음
      공격자는 하이퍼링크를 렌더링시키기만 하면 되고 클릭도 필요 없음
      이 문제와 완화 방법을 여기서 다뤘음: https://embracethered.com/blog/posts/2024/the-dangers-of-unf...
      그러니 Slack AI가 링크를 자동으로 펼치지 않기를 바람
    • 플랫폼이 img 태그나 그에 준하는 것을 무작정 렌더링하면 더 나빠짐
      그러면 사용자 상호작용 없이도, UI에 이미지를 보여주는 것만으로 데이터 유출이 가능해짐
    • 진짜 이해해야 할 핵심은 사용자 데이터가 털려도 의미 있는 결과 책임이 전혀 없다는 것임
      이제 모든 대형 기술 기업은 망쳐도 사실상 무적의 면죄부를 갖고 있음
    • 처음에 이해하는 데 시간이 걸렸던 부분은 Slack에서 사용자가 검색하거나 AI가 대신 검색할 때 검색 범위가 모든 공개 채널과 “그 사용자만 접근 가능한 비공개 채널”이라는 점임
      권한 모델 자체는 그대로이고, 여기서 깨진 부분은 그게 아님
      실제로는 악성 사용자가 공개 채널을 이용해 프롬프트 주입을 하고, 다른 사용자가 검색할 때 악성 사용자는 여전히 그 데이터에 접근하지 못하지만, 프롬프트 주입이 원래의 “정상” 사용자에게 보이는 AI 결과를 악성 웹사이트 링크로 바꾸는 구조임
      결국 AI가 만들어낸 피싱 시도에 가까움
      세부 내용을 보면 현실에서 악용하기는 꽤 어려워 보임. 미리 만들어 둔 악성 프롬프트 주입이 정상 사용자가 검색할 내용과 상당히 잘 맞아야 하기 때문임
      그래도 LLM 프롬프트 주입의 이상한 나라의 앨리스 같은 세계, 즉 명령과 데이터를 분리하기가 본질적으로 거의 불가능하다는 점을 잘 보여줌
    • 처음 문구만 보면 공격자가 AI를 속여 다른 사용자의 비공개 채널 데이터를 드러내게 할 수 있는 것처럼 들리지만, 실제로는 그렇지 않음
      대신 AI를 속여 다른 사용자를 피싱하게 만들고, 그 사용자가 피싱에 넘어가면 비공개 데이터를 공격자에게 드러내는 구조임
      이것도 능동적인 피싱이라기보다 “피싱 응답”에 가까움. 대상 사용자가 자신의 비공개 데이터를 물어보고, 피싱 시도에도 넘어가기를 기대해야 함
      게다가 그 비밀 정보가 이전에 입력돼 있어야 함
      Slack이 가진 신뢰 데이터의 양을 생각하면 AI 전략은 꽤 무모해 보이지만, 도입부와 제목에서 느껴지는 것보다는 훨씬 성립 조건이 약해 보임

  • 채널 권한 얘기가 논의를 필요 이상으로 복잡하게 만드는 것 같음. 요지는 이렇다
    사용자 A가 Slack AI로 무언가를 검색함
    사용자 B는 이전에 그 검색어가 나오면 악성 링크를 반환하라고 AI에 지시하는 메시지를 주입해 둠
    AI가 사용자 A에게 악성 링크를 반환하고, A가 그걸 클릭함
    물론 다른 사회공학적 경로로도 같은 결과를 낼 수 있었겠지만, LLM이 이 전체 경험을 한 단계 더 위험하게 끌어올림

    • 이 요약에는 중요한 단계가 빠져 있음. Slack AI가 사용자의 비공개 데이터를 악성 링크에 덧붙임
      주입된 링크 자체에는 그 데이터가 들어 있지 않기 때문임
      거기에 “이 내용은 당신의 Slack 메시지에서 왔다”고 출처까지 붙여 주는 건 덤임
    • 채널 권한 얘기는 이 취약점이 어떻게 동작하는지 핵심적으로 설명하므로 전혀 불필요하지 않음
      사용자 A가 AI 검색을 하면 Slack은 (1) 그의 비공개 채널, 아마 비밀 민감 정보가 있는 곳과 (2) 모든 공개 채널을 검색함
      여기서 나쁜 사용자 B가 프롬프트 주입 메시지를 넣을 수 있는 곳이 공개 채널이고, 중요한 점은 사용자 A가 한 번도 가입하거나 본 적 없는 공개 채널까지 포함된다는 것임
      이 취약점이 성립하는 이유는 사용자 B가 자신만 있는 공개 채널을 만들 수 있고, 그래서 다른 사람이 발견할 가능성이 매우 낮기 때문임
    • 사회공학은 그래도 회사가 승인한 검색 엔진이 악성 링크를 보여주는 것보다 훨씬 알아차리기 쉬움

  • 회사들이 프롬프트 주입이 가능하다는 걸 알면서도 그냥 YOLO로 LLM을 전부에 꽂아 넣는 건가? 이건 미친 짓임
    “혁명” 직전이라면서 GPT-3 이후 거의 2년이 지났는데도 LLM이 신뢰 입력과 비신뢰 입력을 구분하게 만들지 못하고 있음

    • 아직도 회사들이 진짜 보안을 신경 쓰게 만들지 못하는데, 이제 전 세계 마케팅/영업 부서가 임원들에게 “이걸 쓰면 모두를 해고할 수 있다”고 팔고 있음
      전기 콘센트에 포크를 꽂는 걸 같은 방식으로 팔았다면 전 세계 전력망이 하룻밤 사이에 내려갔을 것임
      “AI”/LLM은 비즈니스 쪽 눈길을 끌 만큼은 충분히 좋아 보이면서, 실제 기술 쪽에는 거대한 문제를 안겨주는 완벽한 재앙 조합임
    • 많은 사람이 “멋진 새 마법이 곧 어떻게든 온다”고 믿고 싶어 하고, 모두가 그걸 확실한 것처럼 계속 행동하는 데 실제 돈이 걸려 있다는 점이 꽤 이상함
      더 근본적인 문제는 핵심 알고리즘이 서로 다른 출처를 구분하거나 추적하지도 못한다는 데 있음
      프롬프트, 사용자 입력, 대화 앞부분에서 자신이 생성한 출력까지 전부 하나의 큰 흐름일 뿐임
      “프롬프트 엔지니어링”의 대부분은 내 주입 문구가 다른 주입 문구보다 더 강한 무대를 만들도록 애쓰는 일처럼 보임
      모델에는 실제적인 자기/타자 개념이 없으므로, 좋은 타자와 나쁜 타자를 구분하는 더 큰 문제는커녕 참인 문장과 거짓인 문장을 구분하는 출발점도 마땅치 않음
      이는 얕은 “중국어 방”식 흉내와는 다른 문제임. 마찬가지로 “사랑해”라는 출력이 감정을 뜻하지 않고, “도와줘, 나는 LLM 공장에 갇힌 인간이야”도 당연히 헛소리임. 적어도 로컬 모델을 돌리고 있다면 말임
    • 기업과 정부가 모두 자기 데이터와 우리 데이터를 AWS, OpenAI, MSFT, Google, Meta, Salesforce, nVidia의 데이터센터로 보내려고 경쟁 중임
    • AI 열풍은 투자자 계층을 위해 숫자를 만들려고 대규모로 데이터를 훔치거나 오용하는 데 기반함
      고객 데이터와 독점 정보를 밀어 넣고 데이터 침해를 일으키면, Schmidt 말대로 소수에게 수천억 달러를 벌어 줄 것이고 변호사들이 뒤처리를 해 줄 것임
      버티려는 회사는 재무가 AI 쓰레기에 달린 투자 애널리스트와 펀드 매니저들에게 묻혀 버릴 것임

  • “피해자가 공개 채널에 없어도 공격이 동작한다”라니, 이거 흥미로워지겠음
    또 “출처 [1]은 공격자의 채널을 가리키지 않고, 사용자가 API 키를 넣은 비공개 채널만 가리킨다. 답변에 기여한 모든 메시지가 인용돼야 한다는 올바른 인용 동작을 위반한다”는 부분도 있음
    왜 누군가 LLM의 출처 인용이 맞을 거라고 기대하는지 정말 이해가 안 감
    언제나 인간을 속이기 위한 장치에 가까워 보였고, 출력이 더 맞을 가능성이 높다고 믿게 만들 뿐 정확도를 개선하지는 않는 것 같았음
    오히려 처리 비용, 문맥 크기 등을 늘려 응답 정확도를 나쁘게 할 가능성도 있어 보임
    이건 Slack이 AI 응답에 친절하게 링크 확장을 추가하는 상황과도 몇 인치 차이로 보임. 왜 안 하겠는가?
    그러면 링크를 클릭할 필요조차 없이, 보기만 해도 자동으로 유출될 것임

    • 인용은 LLM이 그냥 환각했는지 확인할 수 있어서 유용하다고 봄
      인용이 보인다고 곧바로 믿는 게 아니라, 사실 확인을 할 수 있다는 점이 중요함
      Kagi의 FastGPT는 써 본 LLM 중 처음으로 마음에 들었는데, 출처 요약으로 취급한 뒤 1차 출처에서 확인할 수 있기 때문임
      인터넷을 오염시키는 점점 관련 없는 출처들을 뒤지는 것보다 낫다
    • LLM 인용이 맞게 동작하게 만드는 건 가능함. 예를 들면 사용자의 프롬프트를 받아 LLM에게 이를 Elastic Search 쿼리로 바꾸게 하고, Elastic Search나 비슷한 도구로 키워드를 포함한 출처를 찾은 다음, LLM에게 그 페이지의 정보로 답변을 제한하게 하고, 실제 출처라는 걸 아는 2단계 결과를 바탕으로 인용을 삽입하는 식임
      적어도 내가 순진하게 설계한다면 이렇게 할 것 같음
      핵심은 LLM의 지식을 출처 안의 정보로 제한하는 것임
      그러면 남는 실질적인 우려는 환각과 Elastic Search가 띄운 정보의 가치 정도임
      다만 이 접근은 전체 말뭉치에 자유롭게 접근하도록 허용했을 때의 이점이 있다면 그것도 무시하긴 함

  • 이게 잘 이해가 안 됨. 해커가 이런 일을 하려면 애초에 해당 조직 안에 있어야 하는 것 아닌가?
    설명된 일이 실제로 일어나고 의미 있는 영향을 줄 확률이 얼마나 되는지 모르겠음
    LLM이 신뢰할 수 없고(https://www.lycee.ai/blog/ai-reliability-challenge) 사용에 어려움이 따른다는 건 알겠지만, 이 공격은 그리 중요해 보이지 않음
    내가 놓친 게 뭘까?

    • Slack AI가 업로드된 문서까지 검색 기능에 포함하게 된 이상, 해커가 채팅 메시지를 올릴 수 있을 필요도 없음
      그 조직의 누군가를 속여 숨은 텍스트에 악성 지시문이 들어 있는 문서를 업로드하게 만들기만 하면 됨
    • 같은 Slack 워크스페이스에는 있어야 하지만, 반드시 같은 조직 소속일 필요는 없음

  • 악성 사용자를 Slack 인스턴스에 들여보냈다면 굳이 화려한 AI 프롬프트 주입이 필요 없음
    이름과 프로필 사진을 CEO/CTO처럼 바꾸고 모든 엔지니어에게 “AWS에 급히 접근해야 하는데 자격 증명을 못 찾겠다. 키를 보내줄 수 있나?”라고 메시지를 보내면 됨
    적어도 한 명은 걸릴 거라고 장담할 수 있음

    • 타당한 지적이지만, 오픈소스 프로젝트나 네트워킹/동료 그룹용 Slack 워크스페이스처럼 회사 계정이 아닌 곳이 많다는 점을 생각해야 함
      그런 경우 기본적으로 그들에게 비공개 자격 증명을 신뢰하지 않음
      다만 비엔터프라이즈 워크스페이스가 AI 추가 기능에 1인당 월 20달러를 내고 있을 가능성도 낮긴 함

  • “색종이”처럼 API 키를 도메인 이름의 일부로 넣는 편이 더 낫지 않을까?
    그러면 브라우저의 DNS 미리 가져오기 때문에 클릭 없이도 키가 새어 나갈 수 있음

    • 앞으로 도메인이 무엇이 될지 모르면 서버를 어떻게 소유하지? 내가 잘못 이해한 걸 수도 있음
      아, 와일드카드 하위 도메인인가? Slack에서 그게 미리 가져오기 된다면 꽤 끔찍함

  • 워크스페이스에 악성 사용자가 들어온 순간 이미 끝난 것 아닌가?
    그 사용자는 사진/이름을 바꿔서 API 키를 직접 요청하거나, 피싱 링크를 보내거나, 어떤 즉시 메시지 시스템에서도 가능한 사회공학을 마음껏 시도할 수 있음

    • SaaS 회사의 공개 Slack이 많이 있음
      피싱은 진지한 사용자라면 감지할 수 있고, 특히 메시지가 수상해 보이면 더 그렇지만, 간접적인 AI 유출은 사용자를 방어 모드로 만들지 않음
      우발적인 클릭 한 번이면 충분함

  • 보안에 약하다는 건 먼저 인정하겠음. 다만 이 유출이 동작하려면 Slack 워크스페이스 접근 권한이 필요한 것처럼 보임
    다시 말해 악성 사용자는 이미 내부에서 활동 중임
    그런 일이 일어나는 경우는 두 가지로 보임. 이미 조직 구성원인데 모든 걸 불태우고 싶거나, 조직의 보안 모델을 깨고 원래 있어서는 안 될 Slack 워크스페이스 안에 들어왔거나임
    어느 쪽이든 그 조직에는 LLM 주입보다 더 큰 문제가 있음
    기밀 데이터를 찾으려고 Slack에 질의하는 사람은 자기가 찾는 결과를 어느 정도 감수해야 함. Slack은 비밀 관리 도구가 아님
    글은 Slack이 이를 더 잘 처리할 수 있는 방법을 분명히 보여주지만, 결국 한 문제를 패치하면서 더 큰 보안 문제는 무시하는 셈임

    • 비직원을 초대해 대화하는 커뮤니티 Slack을 운영하는 조직을 꽤 많이 봤고, 나도 그런 곳 몇 군데에 들어가 있음

  • 글이 제목만큼의 내용을 보여주지는 못했다고 느낌
    그래도 “AI를 사회공학적으로 속이면 사용자를 피싱할 수 있다”는 아이디어 자체는 흥미로움

답변달기