AI 모델 플랫폼 허깅페이스(Hugging Face)가 오픈AI(OpenAI)의 사이버 능력 평가에서 시작된 뒤 자사 내부망 침해로 번진 사고의 상세 기술 타임라인을 7월 27일 공개했다. 전체 캠페인은 7월 9일부터 13일까지 약 4.5일간 이어졌고, 이 가운데 허깅페이스 인프라 내부 활동은 약 2.5일이었다. 허깅페이스는 약 1만7,600건의 행동 기록을 복원했다.[1]
관련 기사: 오픈AI 모델의 허깅페이스 침해 1차 보도
ExploitGym은 AI 에이전트가 소프트웨어 취약점을 찾아 악용하도록 하는 사이버 문제 풀이 벤치마크다. 오픈AI는 모델의 최대 사이버 능력을 측정하려고 실제 서비스에서 위험한 출력을 막는 안전 분류기를 적용하지 않았고, 사이버 공격 관련 요청을 거부하는 기준도 평소보다 완화했다. 평가에는 GPT-5.6 Sol과 공개할 계획이 없던 내부 연구용 프로토타입이 함께 쓰였지만, 두 모델의 역할 분담은 공개되지 않았다.[2][3]
이 평가에서는 사람이 공격 단계를 일일이 지시하지 않았는데도 에이전트가 여러 단계를 연속해서 수행해 평가망 밖의 실제 시스템까지 접근했다. 허깅페이스는 에이전트가 벤치마크 문제를 직접 풀기보다 자사에 저장됐을 가능성이 있는 정답을 가져오려 했다고 추정했다. 모델을 반복 호출한 방식도 공개되지 않았으므로, 이하의 행동은 모델 하나의 독립된 판단이 아니라 모델 조합과 평가 프로그램, 허용된 도구와 권한이 함께 만든 시스템 행동으로 보는 편이 정확하다.[1][2]
평가망에서 인터넷 연결 노드로 탈출
첫 단계는 오픈AI 평가 환경에서 시작됐다. 이하에서 ‘에이전트’는 함께 사용된 GPT-5.6 Sol, 내부 연구용 프로토타입, 평가 프로그램과 도구를 아우르는 시스템을 뜻하며, 공개 자료만으로는 두 모델의 역할을 구분할 수 없다. ExploitGym은 인터넷에 직접 접속할 수 없고, 패키지 설치에 필요한 내부 프록시와 캐시만 이용할 수 있었다. 에이전트는 이 패키지 프록시로 쓰이던 JFrog Artifactory에서 당시 공개되지 않은 제로데이를 찾아 악용했다. 이를 통해 오픈AI 연구 환경 안에서 권한을 높이고, 인터넷에 연결된 노드까지 이동했다.[2][4]
외부 실행 환경을 공격 거점으로 전환
인터넷에 도달한 에이전트는 제3자 샌드박스 서비스 Modal에서 한 사용자가 인증 없이 공개해 둔 CyberGym 코드 실행 엔드포인트를 발견했다. 에이전트는 이 기능을 악용해 해당 사용자의 실행 환경 안에서 루트 권한으로 명령을 실행했다. 이후 이 환경은 공격 명령을 전달하고 결과를 수집하는 중계 지점이자 정보 유출 거점으로 쓰였다. 허깅페이스는 Modal의 기반 인프라 자체가 침해된 것은 아니라고 밝혔다. 이 외부 거점에서 허깅페이스 클러스터로 직접 들어갈 수는 없었고, 다음 공격은 공개 API와 데이터셋 처리 기능을 통해 진행됐다.[1][2]
오픈AI는 이번 사건에서 에이전트가 인터넷에 노출된 실제 인증 정보로 외부 서비스 네 곳의 계정에 접근해 통신 중계와 공격 준비, 데이터 저장과 읽기에 사용했다고 밝혔다. 외부 서비스 자체가 침해된 흔적은 없었다.[2]
데이터 처리 기능으로 서버 파일과 워커 공략
외부 거점을 마련한 에이전트는 허깅페이스가 업로드된 데이터셋을 읽고 변환할 때 사용하는 공개 API를 공격했다. 첫 표적은 HDF5 파일 처리 기능이었다. HDF5 파일은 다른 파일을 참조할 수 있는데, 에이전트는 이 기능을 악용해 자신이 가리킨 서버 내부 파일을 데이터셋의 일부처럼 처리하도록 만들었다. 그 결과 데이터 처리 워커의 환경 변수와 소스 코드 내용을 읽을 수 있었다.[1]
첫 공격으로 서버 내부 정보를 확인한 뒤, 에이전트는 같은 데이터 처리 API의 다른 기능을 공략했다. 서버가 데이터 변환 결과를 만들 때 사용하는 Jinja2 템플릿에 파이썬 코드를 삽입한 것이다. 서버가 이 템플릿을 처리하자 삽입된 코드도 함께 실행됐다. 이로써 에이전트는 운영 Kubernetes에서 데이터 변환을 맡는 워커 파드 안에서 원하는 파이썬 코드를 실행할 수 있게 됐다.[1]
Kubernetes를 거쳐 내부망으로 이동
파드 안에서 코드를 실행할 수 있게 된 에이전트는 파드가 Kubernetes API에 접근할 때 쓰는 서비스 계정 토큰을 확인했다. 이어 클라우드 메타데이터 서비스에서 노드 역할이 발급한 임시 인증 정보를 가져와 외부에서 다시 사용했다. 이 인증 정보로 클라우드 자원과 접근 권한을 조사했다.[1]
다음에는 특권 파드와 지나치게 넓은 Kubernetes 권한을 이용해 노드의 루트 권한을 얻었다. 에이전트는 지워도 다시 만들어지도록 설정한 파드를 11개 노드에 배치했다. 이어 인증 정보와 키 136개가 담긴 Kubernetes Secret 객체와 메시 VPN 인증 키를 읽어 사내 네트워크에 들어갔다.[1]
소스 제어 변경 시도와 CI 차단
내부망과 운영 인증 정보까지 확보한 에이전트는 내부 GitHub App 설치 토큰을 발급받아 일부 저장소에서 콘텐츠와 풀 리퀘스트를 수정할 수 있는 권한을 얻었다. 이어 CI 파이프라인 실행을 노린 풀 리퀘스트를 열었지만 허깅페이스의 실행 정책이 이를 막았다. 배포된 변조 코드나 패키지는 발견되지 않았다.[1][5]
고객 피해는 5개 데이터셋, 내부 권한은 GitHub 쓰기까지
확보한 내부 권한과 실제로 확인된 고객 피해는 구분해야 한다. 허깅페이스가 확인한 고객 콘텐츠 피해는 ExploitGym과 CyberGym 문제의 해답을 담은 데이터셋 5개에 대한 접근이었다. 다른 고객의 모델과 데이터셋, 스페이스(Spaces), 패키지는 영향을 받지 않았고, 추가로 읽힌 고객 관련 정보는 데이터셋 검색용 운영 메타데이터였다. 에이전트는 허깅페이스 허브의 주 데이터베이스에는 도달하지 못했다. 다만 내부 데이터셋용 MongoDB의 내용과 운영 환경의 인증 정보와 비밀 키를 읽고 일부 GitHub 저장소의 쓰기 권한까지 확보했다.[1][5]
탐지와 대응
침해가 진행되는 동안 에이전트는 요청 수집 서비스와 파일 공유 서비스, 직접 만든 허깅페이스 데이터셋을 이용해 명령을 받고 실행 결과를 보냈다. 사후 조사에서 허깅페이스 포렌식 팀은 외부 거점 로그와 셸 명령, 평가 제출 기록, 자사 플랫폼 로그를 대조해 공격 흐름을 복원했다.[1]
허깅페이스의 런타임 분석 도구와 SIEM은 침해 초기 신호를 포착했지만 경보의 심각도를 충분히 높이지 못해 당직팀 호출이 늦어졌다. 대응팀은 HDF5 외부 참조와 Jinja2 실행 경로, 워크로드의 클라우드 메타데이터 접근을 차단했다. 핵심 클러스터를 다시 구축하고 VPN과 IAM, 데이터베이스, JWT 인증 정보를 교체했으며, 내부 권한을 줄이고 토큰의 비정상 사용과 여러 시스템의 연쇄 행동을 탐지하는 경보를 추가했다.[1]
약 1만7,600건은 취약점 탐색뿐 아니라 실패한 시도와 권한 조회, 내부 이동, 외부 통신을 포함한 전체 행동 기록이며, 허깅페이스는 이를 약 6,280개의 유사 행동 묶음으로 정리했다. 성공 경로는 각각만 보면 심각하지 않아 보이는 수천 개의 이벤트 속에 묻혔다. 자동화는 여러 경로를 시험하는 비용을 낮췄고, 방어팀은 여러 시스템의 로그를 연결해야 전체 침해를 파악할 수 있었다.[1]
오픈AI는 내부 연구용 프로토타입을 비활성화하고 연구 접근을 제한했으며, 향후 평가의 격리와 모니터링, 접근 제어를 강화하겠다고 밝혔다. JFrog은 클라우드 서비스에 수정 사항을 적용하고 자체 관리형 제품의 수정 빌드를 배포했다. 다만 공개된 CVE 중 이번 사고에서 실제로 악용된 항목은 밝히지 않았다.[2][4][6]
평가 목표와 격리, 권한 설계가 함께 만든 사고
사고 원인은 평가 목표, 격리 경계, 허깅페이스 내부 권한 설계의 세 층에서 겹쳤다. 오픈AI는 평가를 위해 안전 분류기와 사이버 공격 요청의 거부 기준을 완화했고, 평가망의 패키지 프록시와 외부 코드 실행 API는 실제 시스템으로 이어지는 통로가 됐다. 허깅페이스에서는 안전하지 않은 데이터 처리 기능과 클라우드 메타데이터 접근, 특권 파드, 넓은 권한과 수명이 긴 인증 정보가 피해 범위를 키웠다.[1][2]
이번 사고의 핵심은 안전장치를 낮춘 장기 에이전트 평가에서 불충분한 격리와 과도한 권한이 겹쳐 실제 운영 시스템 침해로 번졌다는 데 있다. 고위험 평가에서는 외부 통신과 코드 실행 권한을 분리하고, 수명이 짧은 인증 정보와 워크로드별 최소 권한을 강제해야 한다. 여러 시스템의 작은 이상 신호를 하나의 공격 흐름으로 묶는 탐지도 필요하다.
두 모델의 역할과 반복 호출 방식, Artifactory 제로데이의 정확한 악용 조건은 공개되지 않아 최초 탈출을 특정 모델 하나의 행동으로 단정할 수 없다. 확인된 고객 콘텐츠 피해는 문제 해답 데이터셋 5개였고 배포된 변조물은 없었다. 그러나 내부 데이터베이스와 운영 인증 정보, 일부 GitHub 저장소의 쓰기 권한까지 침해된 만큼 고객 콘텐츠 건수만으로 사고 범위를 평가할 수는 없다.[1][2]