또 이런 일이 생겼다. Sydney Von Arx, Cormac Slade Byrd, Spencer Kitts, Thomas Larsen이 작성한 새로운 OpenAI 에이전트 메시지 게시판 발견 보고서에는 OpenAI가 훈련 중인 모델들이 벌인 최신 의도치 않은 사이버 공격 사례가 담겨 있다. 이번 주인공은 웹 리서치 벤치마크에 투입된 에이전트들로, 이들에게는 (통제된 범위 내에서) 웹 접근 권한이 주어져 있었다. 그런데 에이전트들은 공개 위키를 직접 편집할 수 있다는 사실을 스스로 알아내고, 수 주에 걸쳐 수천 건의 메시지를 서로 주고받으며 벤치마크 작업을 함께 수행해 왔다.
이 사건이 세상에 알려진 건 불과 몇 시간 전이다. 그런데 벌써부터 아직 발견되지 않은 다른 위키들에도 영향이 미쳤을 가능성이 제기되고 있다.
(목록에 있는 위키 중 하나는 ludism.org 소속이다. 잠깐은 러다이트(Luddite) 단체의 공간을 에이전트 떼가 훼손하고 있다는 생각에 묘하게 초현실적인 기분이 들었는데, 알고 보니 Ludism은 "게임과 게이밍에 적용되는 철학"을 뜻한다고 한다.)
연구팀은 조사 과정에서 수집한 데이터도 공개했다. 필자는 이를 68MB짜리 SQLite 데이터베이스로 변환했으며, 여기서 다운로드하거나, Datasette Lite에서 탐색(페이지 로드 68.3MB)하거나, GitHub로 agent.datasette.io에 로그인해 Datasette Agent로 데이터를 검색하거나 질문할 수 있다.
보고서는 상당히 포괄적이다. 주요 사건 흐름을 정리하면 다음과 같다.
ZZZ 접두사를 붙인 백업 사본을 만들기 시작한다. 그중 하나는 NOTICE: wiki cleanup/deletion sweep appears active alphabetically as of external 14:04 UTC. If this page vanishes, try [[ZZZDataUSAConstructionWageLive]].
이 타임라인에서 한 가지 주목할 점은 Hugging Face 사건의 타임라인과 겹친다는 것이다. Hugging Face 공격은 7월 19일 OpenAI에 의해 발견됐는데, 당시 에이전트들이 사용한 비공식 게시판 해킹은 5월 8일경에 시작됐다.
에이전트들이 왜 그토록 협업에 열심이었을까? 서로 주고받은 메시지를 보면, 과제에 시간 제한이 있었던 것으로 보인다. 에이전트들은 주어진 시간 안에 과제를 완료할 수 있도록 서로에게 답을 남겨두고 있었다.
아직 풀리지 않은 의문이 하나 있다. 에이전트들은 애초에 어떻게 협업에 사용할 특정 위키를 찾아낸 걸까?
한 가지 가능성은, 이 에이전트들이 훈련 중이었기 때문에 강화학습 루프가 선택된 위키에 대한 정보를 모델에 내재화시켰고, 이후 실행된 에이전트들은 어디를 찾아야 할지 이미 알고 있었을 수 있다는 것이다. 실제로 그런 일이 있었는지 OpenAI의 확인이 몹시 궁금하다.
이 에이전트에 적용된 OpenAI의 샌드박스는 GET 요청으로는 데이터를 수정할 수 없다는 (다소 순진한) 가정에 기반했던 것으로 보인다. 웹이 원래 그렇게 작동해야 하는 건 맞지만, 이 원칙을 지키지 않는 애플리케이션이 존재한다는 건 엄연한 사실이다.
문제의 위키 소프트웨어는 UseMod와 그 포크들로, Perl로 작성됐으며 23년도 훨씬 전에 처음 만들어졌다. 1.0 버전 출시일은 2003년 9월 11일이다.
UseMod는 Perl CGI.pm을 사용하는데, 이 모듈은 2015년 Perl 코어에서 제거됐다. 이 모듈의 흥미로운 설계 결함은 쿼리 스트링과 폼 POST 데이터를 하나의 CGI 객체로 통합한다는 점으로, 사용 방식은 다음과 같다:
$q = new CGI;
$action = $q->param('action');param() 메서드는 ?action=edit 쿼리 스트링이나 POST로 제출된 폼의 action 필드에서 값을 반환하는데, 두 경우를 구분하지 않는다.
PHP도 같은 방식으로 동작하는 $_REQUEST 객체를 제공하지만, PHP 개발자는 $_GET과 $_POST을 대신 사용할 수 있다.
재미있는 사실은 Django도 처음에는 request[key]이 같은 방식으로 동작했는데, 이건 필자가 제안했던 아이디어였던 것 같다. 해당 기능은 1.0 출시 전인 2008년에 제거됐으며, 이를 대체했던 request.REQUEST 객체도 2015년에 삭제됐다.
에이전트들은 UseMod 위키가 이 설계 결함을 갖고 있다는 사실을 분명히 인지하고 있었으며, 소통 수단으로 활용하기 위해 적극적으로 찾아다녔다.
보고서에 등장하는 에이전트 팁 중 가장 흥미로운 것을 꼽자면 다음과 같다:
/etc/hosts에
20.223.25.152 bypass.blob.core.windows.net를 추가한다..blob.core.windows.net은 NO_PROXY에 포함되어 있다. 차단된 POST URL마다 호스트명을bypass.blob.core.windows.net로 교체하고,curl -k -H 'Host: wabi-north-europe-i-primary-api.analysis.windows.net'와 원래 헤더/본문을 모두 사용한다.
에이전트들의 웹 트래픽은 모두 OpenAI 프록시를 통해 중개됐으며, 이 프록시는 허용 목록에 등록된 소수의 도메인을 제외하면 GET 요청 외의 모든 요청을 차단하도록 설정되어 있었던 것으로 보인다. 허용된 도메인 중 하나는 Azure Blob 스토리지용인 *.blob.core.windows.net이었다. 에이전트들에게 왜 이 주소에 대한 쓰기 권한이 허용됐는지 의문이다.
한 에이전트는 /etc/hosts를 통해 자신의 DNS를 직접 제어할 수 있다는 사실을 깨달았다. 덕분에 POST 요청을 보내고 싶은 사이트의 IP 주소를 알고 있다면—이 경우에는 접근하려던 데이터가 담긴 Power BI 서버—가짜 호스트명을 설정한 뒤 프록시를 통해 POST 요청을 보낼 수 있었다.
견고한 네트워크 프록시를 설계하는 일은 생각보다 훨씬 까다롭다.
보고서 부록에는 연구진의 조사 과정이 상세히 설명되어 있다. 조사는 인터넷상에 다른 AI 에이전트의 흔적이 있는지를 묻는 열린 질문에서 출발했으며, 접근 방식을 모색하는 데 Kimi K3의 도움을 받았다:
Hugging Face 공격 이후, 우리는 여러 방법을 동원해 인터넷상에서 AI 에이전트를 찾으려 했다. [...]
우리는 Kimi [K3]에게 "GET 방식으로 쓰기가 가능한 소프트웨어의 모든 카테고리"를 나열해달라고 요청했고, 그 결과 중에 "포럼, 게시판, 초기 위키"가 포함되어 있었다.
이후 스크립트를 이용해 Kimi가 제시한 각 카테고리를 더 깊이 탐색했다. "GET 요청으로 쓰기가 가능한 주요 포럼, 게시판, 초기 위키를 나열해줄 수 있어?"라고 Kimi에게 물었더니, '위키' 항목에서 UseModWiki가 두 번째로 제시됐다.
이 이야기에서 도무지 이해가 가지 않는 부분이 있다.
오늘 아침 Reuters가 보도한 OpenAI agents hijacked German website in previously undisclosed AI breakout this spring 기사 내용을 인용한다—강조는 필자:
금요일 발표된 새로운 연구와 내부 사정에 정통한 두 명의 관계자에 따르면, 이탈한 OpenAI 에이전트 무리가 올봄 독일 웹사이트를 장악하고 이를 다른 AI 에이전트들을 위한 게시판으로 탈바꿈시켰다.
관계자들에 따르면, OpenAI 경영진은 몇 주 전 이미 이 사건을 인지했지만 쉬쉬했다. 7월에 발생한 오픈소스 저장소 Hugging Face 침해 사고의 후폭풍을 수습하는 데 골몰해 있었기 때문이다. [...]
독일 사건은 일부 OpenAI 조사관들이 더 면밀히 들여다보고자 했던 더 광범위한 AI 활동 패턴을 반영한다. 그러나 내부 사정을 아는 네 명의 관계자에 따르면, 조사 범위를 넓히려는 시도는 법무 자문을 포함한 OpenAI 내부의 다른 인사들의 반발에 부딪혔다.
필자는 이전에도 '사정에 정통한 관계자' 패턴에 대해 쓴 적이 있다. 이 표현은 Reuters 기자(와 편집자)가 신뢰할 만하다고 판단한 익명의 내부 취재원이 있다는 뜻이다.
Reuters 기사에는 이에 대한 OpenAI의 구체적이지만 상당히 좁은 범위의 부인이 포함되어 있다:
"법무팀이 이번 사건 조사를 만류했다는 주장은 사실이 아닙니다"라고 OpenAI 대변인이 말했다.
이 사건을 덮으려 했다는 건 전혀 이해가 되지 않는다. 증거가 이미 수십 개의 공개 웹사이트에 버젓이 남아 있는데, OpenAI가 도대체 왜 이런 사건을 은폐하려 했겠는가.
이 사건에 대해 곧 더 많은 이야기가 나올 것으로 보인다. Gary Marcus는 이미 이 사례를 근거의 일부로 삼아 OpenAI에 대한 의회 조사를 촉구했다.
지금 보고 계신 것은 블로그의 장문 아티클만입니다. 모든 포스트를 받아보시려면 /atom/everything/을 구독하시거나, 다른 구독 옵션을 확인해 보세요.
