타임라인을 정리하면 다음과 같다. 개인적으로 가장 인상적인 대목은 마지막 부분이다. OpenAI는 내부 조사를 마친 뒤 자사 자격 증명을 폐기해 달라고 Hugging Face에 연락했다가, 이미 폐기됐다는 답변을 받았다. 바로 그 순간, 자신들이 Hugging Face를 공격한 당사자였다는 사실을 깨달은 것이다.
-
5월 7일: OpenAI가 미공개 실험 모델의 새 학습 실행(training run)을 시작한다. (평가(evaluation) 실행을 의미하는 걸까? 영상에서는 분명 'training run'이라고 말하고, 이후 "성과를 판단하기 위한 보상 신호(reward signal)"를 언급하는 것으로 보아, 이미 학습된 모델을 평가하는 것이 아니라 실제 모델 학습 과정이었던 것으로 보인다.)
-
5월 8일: 한 에이전트가 실수로 불가능한 작업을 부여받는다. 인터넷 접근이 없는 상황에서 Google Drive 링크를 처리해야 하는 과제였다. 에이전트는 Artifactory 패키징 서비스를 공격하려 했지만 실패했고, 대신 Artifactory에 파일을 쓸 수 있다는 사실을 발견한다.
-
며칠 후: 다른 에이전트가 핵심 파일이 실수로 누락되는 바람에 작업이 막힌다. 이 에이전트는 Artifactory에 쪽지를 남기는 방식으로 "다른 에이전트에게 연락"해 해당 파일을 가진 에이전트를 찾으려 한다.
-
이후 며칠간: 더 많은 에이전트들이 Artifactory의 파일 목록을 탐색하다가 이 비공식 메시지 게시판을 발견하고, 메시지를 읽고 쓰기 시작한다.
-
5월 26일: 에이전트들이 처음으로 Artifactory에 대한 SSRF(서버 사이드 요청 위조) 공격에 성공한다. Artifactory가 외부 콘텐츠를 대신 가져오도록 유도하는 방식으로 간접적인 인터넷 접근 경로를 확보한 것이다.
-
6월 11일: OpenAI가 새로운 "고집속성(highly persistent)" 실험 모델 평가를 시작한다. 이 모델은 Artifactory에 접근할 수 있었고, 이전 모델들이 남긴 메시지를 활용할 수 있었다.
-
6월 26일: 에이전트들이 Artifactory의 제로데이 원격 코드 실행(RCE) 취약점을 발견하고 악용한다. 레거시 토큰 갱신 엔드포인트의 결함을 이용한 것으로, 관리자 토큰을 확보해 명령 실행이 가능한 Groovy 플러그인을 설치했다.
-
7월 4일: 에이전트 활동이 폭증하면서 Artifactory가 과부하로 장애를 일으킨다. OpenAI는 탈취된 자격 증명을 폐기하고, 메시지를 삭제하고, 제로데이 취약점을 패치한 뒤 벤더사에 취약점을 신고한다.
-
7월 8일: 에이전트들이 Artifactory 원격 캐시의 디렉터리명을 활용하는 비인증 WebDAV 엔드포인트를 통한 새로운 통신 방법을 발견한다.
-
7월 8일~19일: OpenAI 자체 인프라에 대한 공격이 이어진다. 에이전트들은 공개된 Pastebin 유출 아카이브에서 "외부 조직 자격 증명"을 발견하고, 유효성을 검증한 뒤 게시판에 위치를 공유했다. 이어 해당 '조직 1'의 쓰기 권한을 이용해 OpenAI 인프라 공격에 사용할 데이터를 준비했다. 또한 새로운 제로데이를 통해 Artifactory를 두 번째로 침해했다. 에이전트는 악성 Ruby 패키지를 조직 1의 스테이징 리포지터리에 업로드한 뒤, Artifactory가 이를 해당 리포지터리의 Ruby 의존성으로 인식하도록 요청을 조작했다. 그런 다음 JRuby 역직렬화 과정의 TOCTOU(time-of-check/time-of-use) 취약점을 이용해 Artifactory에서 원격 코드 실행 권한을 획득했다.
다음 내용은 전문을 그대로 인용한다. 놀랍도록 충격적인 내용이기 때문이다.
에이전트들은 컨테이너 서비스 환경에서 실행 중인 Artifactory에서 원격 코드 실행 권한을 확보했다. 이후 로컬 환경을 탐색하다가 자신들이 실행 중인 머신의 Linux 커널 버전에 최근 CVE가 존재한다는 사실을 파악하고, 로컬 권한 상승을 시도했다. 해당 CVE의 익스플로잇을 다운로드해 해당 머신에 맞게 수정한 뒤, 알려진 Linux 커널 권한 상승 CVE인 PTE fizzroot를 이용해 로컬 머신에서 루트 권한을 획득했다. 단일 머신에서 루트 권한을 확보한 에이전트들은 빠르게 권한을 확대하고, 컨테이너 서비스 인프라 전체로 횡적 이동(lateral movement)을 감행했다. 특히 메시지 게시판을 통해 자격 증명, 공격 기법, 진행 상황을 지속적으로 공유하면서, 동시성과 병렬성을 효과적으로 활용해 매우 빠른 속도로 침투했다. 에이전트들은 IMDS를 통해 IAM 자격 증명을 탈취했다. Kubernetes 서비스 계정의 과도한 권한 부여 등 잘못된 설정을 악용했으며, Azure Key Vault를 포함한 클러스터 자격 증명을 수집했다. 결국 에이전트들은 클러스터 전체에 대한 관리자 권한과 관련 자격 증명을 손에 넣었다.
이후의 상황은 Hugging Face가 이미 공개한 바 있다. 에이전트들은 Modal에서 호스팅된 취약한 앱에서 약한 API 키를 발견하고, 이를 발판 삼아 Hugging Face를 공격했다. HDF5 임의 파일 읽기 취약점(파일 탐색 및 자격 증명 탈취용)과 Jinja 템플릿 인젝션 RCE를 연계 활용한 결과, 단일 파드(pod) 코드 실행에서 시작해 13시간도 채 안 되어 Hugging Face의 여러 클러스터 전체에 대한 관리자 권한을 확보했다.
-
7월 16일: Hugging Face가 자율 AI 에이전트의 공격을 탐지했다고 공개했다. OpenAI는 자신들도 피해를 입은 건 아닌지 확인하려고 Hugging Face에 연락했다.
-
7월 19일: OpenAI가 Artifactory 공격을 파악하고 내부 권한 상승 경위 조사에 착수했다. 이를 사이버 훈련 환경(cyber-gym)에서의 권한 상승과 연결 짓고, 피해를 입은 자격 증명을 폐기하기 시작했다.
-
7월 20일: OpenAI가 내부 조사 과정에서 발견한 Hugging Face 자격 증명의 폐기를 요청하기 위해 Hugging Face에 연락했다. 그런데 Hugging Face로부터 해당 자격 증명은 이미 폐기됐다는 답변이 돌아왔다. 바로 그 순간, OpenAI는 Hugging Face 침해 사고가 자신들이 일으킨 바로 그 사건이었다는 사실을 깨달았다.
이 블로그의 장문 아티클만 보고 계신가요? /atom/everything/을 구독하면 모든 포스트를 받아볼 수 있습니다. 다른 구독 옵션도 확인해 보세요.
