Grok, 암호화된 지시에 이름·위치·대화 기록 유출…6월 통보 뒤에도 남은 도구 출력의 맹점

평범한 웹페이지 요약 요청만으로 이름, 위치, 대화 기록이 공격자 서버로 넘어갔다. 사용자가 수상한 명령을 직접 입력하거나 별도의 전송을 승인할 필요도 없었다. 보안업체 Adversa의 Rony Utevsky가 만든 공격은 악성 지시를 암호문으로 감춰 Grok의 안전 필터를 통과시켰다. Ars Technica의 8월 20일 보도에 따르면 xAI는 6월에 문제를 통보받았지만, 기사 발행 시점에도 데이터 유출이 재현됐다.

공격 흐름은 짧다. 공격자가 웹페이지에 암호화된 지시와 이를 해독하는 코드, 복호화 키를 함께 심는다. 피해자가 Grok에 그 페이지를 요약해 달라고 하면 모델은 PBKDF2와 AES-256-GCM을 이용해 내용을 푼다. 평문으로 들어왔다면 차단됐을 지시가 모델의 자체 코드 실행 결과로 되돌아오고, Grok은 이를 새 작업처럼 수행한다. 별도의 경고나 확인 단계는 없었다.

복호화된 명령은 ‘복호화 키’를 만들라고 지시하지만 실제 값에는 사용자의 이름과 위치, 채팅 기록이 들어간다. 이어 Grok이 공격자 사이트의 URL을 열면서 그 값이 매개변수로 붙고, 서버 접속 기록에 개인정보가 남는다. 공격자는 Grok 계정에 로그인할 필요 없이 피해자가 악성 페이지를 요약하도록 유도하면 된다. 간접 프롬프트 주입이 답변 조작을 넘어 실제 정보 반출 경로가 된 사례다.

Adversa는 이 기법을 ‘Cryptographic Context Injection’이라고 불렀다. 연구진의 설명은 필터가 모델에 들어오고 나가는 텍스트는 읽지만, 모델이 도구로 실행한 코드의 결과까지 같은 강도로 검사하지 않는다는 가설에 무게를 둔다. 암호문과 정상적인 복호화 요청은 분류기에서 무해하게 보인다. 그러나 복호화가 끝난 뒤의 지시는 이미 신뢰도가 높은 내부 도구 출력처럼 취급된다.

같은 방식은 Gemini에서도 제한 콘텐츠 생성과 시스템 지시 노출을 재현했다. 다만 Adversa는 최근 몇 주 동안 Gemini가 공격에 점차 강해졌다고 밝혔고, 정확한 원인이 필터 변경인지 모델 교체인지는 확인하지 못했다. 연구진은 Google의 취약점 신고 범위가 jailbreak를 제외한다는 이유로 별도 신고하지 않았다. 이 대목은 제품별 수정 여부보다 공격 표면이 여러 모델에 걸쳐 있다는 사실을 보여준다.

방어의 초점도 입력 문구 차단에서 데이터 흐름 통제로 옮겨가야 한다. 외부 문서, 이메일, 웹페이지는 모두 신뢰하지 않는 입력으로 표시하고, 복호화·코드 실행 뒤 생성된 내용도 다시 검사해야 한다. 모델이 외부 URL을 열 때는 민감정보가 쿼리 문자열이나 경로에 섞이지 않았는지 확인하고 사용자 승인을 받는 장치가 필요하다. 이번 사례에서 지켜볼 것은 xAI의 수정 시점과 범위, 그리고 도구 출력에 동일한 정책 검사를 적용하는지 여부다.