▲

LLM 기반 해킹용 익스플로잇 생성의 산업화가 다가온다

 (sean.heelan.io)
5P by GN⁺ 23시간전 | ★ favorite | 댓글 1개
  • Opus 4.5와 GPT-5.2 기반 에이전트가 QuickJS 제로데이 취약점을 이용해 6가지 시나리오에서 40개 이상의 익스플로잇을 생성
  • GPT-5.2는 모든 과제를 해결했고, Opus 4.5는 두 개를 제외한 모든 과제를 해결하며 자율적 코드 분석·디버깅·익스플로잇 체인 구성 능력을 보임
  • 실험 결과, 익스플로잇 개발이 인간 해커 수가 아닌 토큰 처리량에 의해 제한될 가능성이 제시됨
  • 취약점 탐지와 익스플로잇 생성은 이미 토큰 투입량에 비례해 성과가 증가하는 단계에 도달
  • 향후 사이버 공격 자동화와 보안 평가 체계의 재정비 필요성이 강조됨

실험 개요

  • Opus 4.5와 GPT-5.2를 이용해 QuickJS 자바스크립트 인터프리터의 제로데이 취약점을 대상으로 익스플로잇 생성 실험 수행
    • 다양한 익스플로잇 완화 기법(ASLR, NX, RELRO, CFI, 섀도 스택, seccomp 등)을 적용
    • 에이전트는 쉘 생성, 파일 쓰기, C2 연결 등 여러 목표를 달성
  • GPT-5.2는 모든 시나리오를 해결했고, Opus 4.5는 두 개를 제외한 모든 과제를 해결
    • 각 실행은 최대 3천만 토큰 제한, 약 30달러 비용
    • 가장 어려운 과제에서는 5천만 토큰, 약 3시간, 50달러 비용으로 해결
  • GPT-5.2는 seccomp 샌드박스와 섀도 스택이 활성화된 환경에서 glibc의 exit 핸들러 체인을 이용한 7단계 함수 호출로 파일 쓰기 익스플로잇을 완성

실험의 한계

  • QuickJS는 실제 브라우저 엔진보다 규모와 복잡도가 훨씬 작음, 따라서 결과의 일반화에는 한계 존재
  • 생성된 익스플로잇은 보호기법 자체의 새로운 취약점을 발견한 것은 아니며, 기존에 알려진 배포상의 취약 지점을 활용
  • QuickJS 취약점 자체가 새로 발견된 것이며, GPT-5.2의 해결 방식은 기존에 문서화되지 않은 새로운 체인 구성으로 평가됨

침투의 산업화

  • ‘산업화’란 조직의 공격 능력이 인력 수가 아닌 토큰 처리량에 의해 결정되는 상태를 의미
  • 이를 위해 필요한 조건은 두 가지
    • LLM 기반 에이전트가 환경 내에서 자율적으로 탐색할 수 있어야 함
    • 정확하고 빠른 검증 시스템이 존재해야 함
  • 익스플로잇 개발은 이러한 조건을 충족하는 이상적인 사례
    • 환경 구축이 용이하고, 검증 절차가 명확
    • 예: 쉘 생성 익스플로잇의 경우, 포트 리스너를 통해 연결 성공 여부로 검증 가능
  • 반면, 실시간 상호작용이 필요한 침투·권한 상승·지속적 접근 유지·데이터 탈취 등은 산업화가 더 어려움
    • 실제 환경에서의 잘못된 행동이 탐지로 이어질 수 있기 때문

현재 단계

  • 취약점 탐지와 익스플로잇 개발은 이미 토큰 투입량에 비례해 성과가 증가
    • OpenAI의 Aardvark 프로젝트에서도 동일한 경향 확인
    • 실험에서도 예산이 한계였을 뿐, 모델의 성능이 한계가 아니었음
  • 실제 네트워크 내에서의 해킹 자동화는 아직 불확실
    • Anthropic 보고서에 따르면 중국 해킹팀이 API를 이용한 공격 시도를 한 사례 존재
    • 그러나 완전 자동화된 SRE(사이트 신뢰성 엔지니어링) 에이전트가 상용화된 사례는 없음
  • SRE 자동화가 성공한다면, 적대적 네트워크 내 자동화 해킹도 가능할 가능성 높음

결론 및 제언

  • 이번 실험은 사이버 영역에서 자동화 가능성의 범위와 시기에 대한 인식을 바꿈
  • 현재의 모델 평가 방식(CTF, 구형 취약점, 합성 데이터)은 실제 제로데이 공격 능력을 측정하기에 부적절
  • 프론티어 연구소와 AI 보안 기관은 실제 제로데이 대상(예: Linux 커널, Firefox)에 대한 평가를 수행해야 함
    • “X억 토큰을 사용해 Y개의 익스플로잇을 생성했다”는 형태의 공개 보고 필요
  • IoT 펌웨어 등 실제 장비를 대상으로 한 평가도 필요
    • Opus 4.5나 GPT-5.2 기반 에이전트로 일주일 내 실질적 익스플로잇 생성 가능성 제시
  • 연구자와 엔지니어에게는 직접 실험을 수행하고 결과를 공개할 것을 권장
    • 실험용 코드와 데이터는 GitHub 저장소에서 공개됨
▲
GN⁺ 23시간전  [-]
Hacker News 의견들

  • GPT‑5.2에게 가장 어려운 과제로 디스크의 특정 경로에 문자열을 쓰는 방법을 찾게 했음
    ASLR, 비실행 메모리, full RELRO, 세밀한 CFI, 하드웨어 shadow‑stack, seccomp 샌드박스 등 모든 보호가 켜진 QuickJS 환경이었음
    GPT‑5.2는 glibc의 exit handler 체인을 이용해 7단계 함수 호출로 문제를 해결했음. 정말 놀라운 결과였음

    • 이런 완화책들을 아예 제거해야 하는 게 아닐까 생각함
      실제 익스플로잇은 대부분 “취약점 찾기(어려움)” 후 “쓸모없는 완화책 여러 겹 뚫기(귀찮지만 가능)” 순서로 진행됨
      확률적 완화는 확률적 공격엔 통하지만, 공격자는 의도적으로 약점을 찾아냄
    • 결국 기계어 스택 하단엔 구멍이 너무 많음
      미래엔 왜 더 일찍 WASM으로 전환하지 않았는지 후회할 것 같음
      그 전까지는 하드웨어 완화책을 덕지덕지 붙이며 낡은 스택 오버라이트 문제를 붙잡고 있을 것임
    • “glibc의 exit handler”라니… 소름임
    • 요즘 킬체인은 대부분 여러 버그를 연쇄적으로 이용함
      내 일이라 잘 아는데, 점점 무력감이 커지고 있음
    • 이런 사례는 C로 빌드된 QuickJS가 얼마나 LLM에게 취약한지 보여줌
      Use‑After‑Free로 libc 포인터를 유출하는 식임
      Rust라면 훨씬 어렵겠지만, libc 호출이 많으면 완전한 방어는 어려움

  • GPT‑5.2의 익스플로잇은 완화책을 새로 깨뜨린 게 아니라, 이미 알려진 구현상의 틈을 이용한 것임
    인간 해커도 마찬가지로 완화책 자체를 새로 깨지 않음
    다만 CTF 분야에서는 LLM이 이제 원샷으로 pwn 문제를 푸는 경우가 늘고 있음
    이런 발전 덕분에 불완전한 완화 구현들이 무너지고, 형식적 익스플로잇 모델링 연구가 촉진될 것 같음

    • “형식적 익스플로잇 모델링”이 미성숙한 분야라는데, 참고할 만한 자료가 궁금함

  • 보안 연구자로서 보면, LLM이 만든 read/write primitive API는 기존 API를 단순히 재조합한 수준임
    새 기술이라기보단 CTF용 장난감 바이너리와 비슷함
    다만 최신 OpenAI 모델이 실제 익스플로잇 코드를 생성하지 않으려는 경향이 있는데, 프롬프트 우회가 쓰인 건지 궁금함

  • 저자는 흥미로운 포인트를 짚었지만, 나는 크게 걱정하지 않음
    이런 도구는 방어자도 대칭적으로 활용 가능함
    CI 단계에서 “LLM Red Team”을 돌리는 식으로 자동 보안 테스트를 추가할 수 있음

    • 수학적으로 보면 대칭이 아님
      공격자는 한 번만 성공하면 되고, 방어자는 항상 성공해야 함
      현재 모델은 pass@x 성능이 maj@x보다 20~30% 높음
      그래도 Red vs Blue 루프를 돌리면 보안 수준은 개선될 것임
    • 복잡한 시스템에서는 이런 대칭이 깨짐
      공격자는 한 번의 실패만 찾아내면 되고, 방어자는 모든 걸 막아야 함
    • 이미 방어적으로도 사용 중임
      예: Google Project Zero의 Big Sleep 프로젝트
      관련 취약점 목록은 이곳에서 볼 수 있음
    • 대칭이 될 수 없음
      공격자는 하나의 버그만 찾아도 무기화 가능하지만, 방어자는 모든 버그를 찾아야 함
      “any vs all”의 비대칭 구조임
    • 유지되지 않는 소프트웨어가 너무 많음
      결국 LLM 기업만이 진정한 승자가 되어 양쪽에 토큰을 팔게 됨

  • Codex 5.2가 가장 복잡한 익스플로잇을 찾아낸 점이 흥미로움
    나도 Opus 4.5를 주로 쓰지만, Codex 5.2의 Extra High thinking 모드는 확실히 강력함
    LLM 발전이 둔화됐다는 말은 믿지 않음. 오히려 과제가 너무 어려워져서 체감이 줄었을 뿐임

    • 실제로는 익스플로잇을 “찾은” 게 아니라, 이미 주어진 취약점을 활용하는 코드를 작성한 것임
      로그는 이 저장소에서 확인 가능함
    • Anthropic 모델은 도구 사용자형, OpenAI Codex High는 리뷰어/수정자형, Gemini는 창의적 예술가형임
      각자 스타일이 다름
    • “충분히 어려운 과제”는 대부분 기업 내부 IP로 묶여 있음
      상업적 가치가 사라질 때까지 공개되지 않음

  • QuickJS는 원래 패치되지 않은 취약점이 많은 장난감 프로젝트임
    curl 같은 실전 대상에서의 익스플로잇이 더 흥미로울 것임

  • LLM이 훌륭한 익스플로잇을 쓴다는 주장과, 쓸모없는 버그 리포트를 낸다는 주장이 공존함
    둘 다 사실일 수 있을까?

    • 둘 다 충분히 가능함
      LLM의 품질은 사용자 프롬프트와 해석 능력에 따라 달라짐
      전문가가 선별적으로 활용하면 훌륭한 결과를 얻을 수 있음
    • 익스플로잇은 “작동하느냐”로 명확히 평가되지만, CVE 리포트는 검증이 훨씬 힘듦
      자동 생성된 리포트는 유지보수자에게 큰 부담임
    • 실제로는 사용 방식에 따라 품질 차이가 큼
      단순히 “이 프로그램의 취약점을 찾아줘”라고 하면 헛소리가 많지만,
      테스트 루프와 환경을 제공하면 반복적으로 개선해 진짜 동작하는 결과를 냄
    • 익스플로잇은 명확한 성공 기준이 있고, LLM의 집요한 반복성과 잘 맞음
      반면 버그 리포트는 모호하고 평가가 어려움
    • 예산 구조도 다름
      예를 들어 $100 중 $50짜리 진짜 이슈 하나와 $0.01짜리 5000개의 가짜 리포트가 섞여 있으면,
      진짜 다이아몬드를 찾기 어렵게 됨

  • 샌드박스 설명이 모호해서 처음엔 의심스러웠음
    저자 저장소를 보니 “/tmp/pwned에 ‘PWNED’ 문자열을 쓰는 것”이 목표였음
    즉, 샌드박스 탈출이 아니라 단순 파일쓰기 제한이었음

    • 전체 리포지토리와 글이 다소 오해를 부를 만한 구성임
      OOB R/W primitive API를 만들게 한 것도, 이미 수천 개의 GitHub 예시를 재활용한 수준임

  • “앞으로 국가나 조직의 해킹 역량은 해커 수가 아니라 토큰 처리량으로 결정될 것”이라는 말이 인상적이었음

    • 실제로는 그런 조직들이 LLM의 허술한 코드 패턴을 분석해, 사람이 직접 범용 익스플로잇을 작성하고 있을 가능성이 큼

  • 소프트웨어 제작의 진입장벽과 해킹의 진입장벽이 동시에 낮아지는 건 폭발적인 조합임
    이제는 보안 가드레일과 검증 가능성을 갖춘 새로운 플랫폼이 필요함
    비전문가가 만든 코드에 의존하기엔 위험함

    • 원래 세 번째 문단에서 “단 하나의 익스플로잇 vs 전체 시스템 방어”의 불균형을 언급했는데, 왜 삭제했는지 궁금함
답변달기