Claude Opus: AI가 작성한 Chrome Exploit로 버그바운티 $2,283 획득

서론

어느 날 아침, 버그바운티 헌터의 DM으로 하나의 메시지가 날아왔다. “Claude가 Chrome 익스플로잇 짜서 $2,283 받았습니다.” 솔직히 반신반의했다. LLM이 그 정도 수준의 코드를 작성할 수 있다고? 몇 달 전만 해도 AI가 생성한 코드는 컴파일 에러 투성이였다. 하지만 분석을 시작한 순간, 생각이 바뀌었다.

Anthropic의 대규모 언어 모델 Claude Opus가 Chrome 브라우저의 V8 엔진 취약점을 분석하고, 실제로 동작하는 익스플로잇 코드를 생성했다. 더 놀라운 건, 이 코드가 구글의 버그바운티 프로그램에서 유효한 취약점으로 인정되어 현금 보상금까지 받았다는 점이다.

이 사건은 단순한 호기심 거리가 아니다. 보안 연구의 패러다임이 변하고 있다는 신호다. AI가 단순히 코드 리뷰나 취약점 스캐닝을 넘어, 실제 공격 가능한 익스플로잇을 생성하는 수준에 도달했다. 이 글에서는 Claude Opus가 어떻게 Chrome 익스플로잇을 작성했는지, 그 기술적 과정과 시사점을 분석한다.

⚠️ 윤리적 경고: 본 글에서 다루는 모든 기술적 내용은 방어 및 보안 연구 목적으로 작성되었습니다. 실제 시스템에 대한 무단 침투 시도는 범죄행위입니다.

AI 기반 익스플로잇 생성의 기술적 배경

전통적 익스플로잇 개발 vs AI 생성

전통적으로 브라우저 익스플로잇을 작성하려면 다음이 필요했다:

| 항목 | 전통적 방식 | AI 보조 방식 | | :— | :— | :— | | 필수 지식 | V8 엔진 내부 구조, JIT 컴파일러, 메모리 관리 | 프롬프트 엔지니어링, 취약점 개념 이해 | | 소요 시간 | 수일 ~ 수주 | 수시간 (반복 포함) | | 초기 진입 장벽 | 매우 높음 | 중간 | | 코드 품질 | 전문가 수준 | 변동적 (검증 필요) | | 반복 작업 | 수동 디버깅 | 자동 생성 + 수동 튜닝 |

핵심은 AI가 모든 것을 대신한다는 게 아니라는 점이다. 숙련된 연구자의 가이드下에 AI가 보조 도구로 사용되었다.

공격 흐름도

Claude Opus가 익스플로잇을 생성한 전체 프로세스를 시각화하면 다음과 같다:

1
2
3
4
5
6
7
8
9
graph LR
    A[취약점 보고서 수집] --> B[Claude Opus 분석]
    B --> C[PoC 코드 초안 생성]
    C --> D[연구자 수동 검증]
    D --> E[실패  피드백 제공]
    E --> B
    D --> F[익스플로잇 완성]
    F --> G[버그바운티 제출]
    G --> H[보상금 수령 $2,283]

Claude Opus의 Chrome 익스플로잇 생성 과정

Step 1: 취약점 정보 수집 및 분석

연구자는 먼저 공개된 Chrome 취약점 정보를 Claude Opus에 제공했다. 여기에는 다음이 포함되었다:

  • CVE 보고서 및 패치 커밋
  • V8 엔진의 Git 변경 사항
  • 관련 Bug Tracker entries
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
# 연구자가 Claude에게 제공한 프롬프트 예시 (개념적 재구성)
prompt = """
다음은 V8 엔진의 Maglev JIT 컴파일러에서 발견된 취약점입니다:

CVE-2024-XXXX
- 타입 혼동(Type Confusion) 취약점
- Maglev의 배열 요소 타입 추론 오류
- 패치 커밋: [해시값]

첨부된 패치 diff를 분석하고, 
이 취약점을 트리거하는 최소 PoC를 작성하세요.
메모리 안전을 보장하는 환경에서만 테스트합니다.
"""

# Claude의 응답 구조 (실제 응답은 더 복잡함)
response = claude.generate(prompt)

Step 2: PoC 코드 생성 및 반복

Claude Opus는 패치를 역분석하여 취약점의 근본 원인을 파악하고, 이를 트리거하는 JavaScript 코드를 생성했다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
// 학습 목적의 개념적 PoC 구조 (실제 익스플로잇과 다름)
// V8 Maglev JIT 타입 혼연 예시

function triggerBug(arr, index) {
    // JIT 컴파일러가 특정 타입으로 최적화하도록 유도
    return arr[index];
}

// 워밍업: JIT가 배열을 SMI(Small Integer) 타입으로 추론
let array = [1, 2, 3, 4, 5];
for (let i = 0; i < 10000; i++) {
    triggerBug(array, 0);
}

// 타입 혼란: JIT의 타입 가드를 우회하여 
// 다른 타입의 객체를 참조하게 만듦
array[0] = {};  // 객체 할당

// 여기서 JIT는 여전히 SMI 타입으로 최적화된 코드를 실행
// 결과: 타입 혼동 발생
let result = triggerBug(array, 0);
console.log(result);  // 예상과 다른 동작

참고: 위 코드는 학습 목적의 단순화된 예시입니다. 실제 익스플로잇은 메모리 레이아웃 조작, 가젯 체인 구성 등 훨씬 복잡합니다.

Step 3: 익스플로잇 안정화

초기 PoC는 취약점을 트리거할 수 있었지만, 안정적인 코드 실행까지는 추가 작업이 필요했다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# 익스플로잇 안정화를 위한 반복 프로세스 (의사코드)
class ExploitDeveloper:
    def __init__(self, ai_assistant):
        self.ai = ai_assistant
        self.iteration = 0
    
    def refine_exploit(self, crash_log):
        self.iteration += 1
        
        # AI에게 크래시 로그와 함께 개선 요청
        improved_code = self.ai.analyze(
            crash_log=crash_log,
            previous_attempt=self.current_code,
            target="안정적인 익스플로잇"
        )
        
        # 테스트 환경에서 검증
        result = self.test_in_sandbox(improved_code)
        
        if result.is_reliable():
            return improved_code
        else:
            # 실패 시 피드백 루프
            return self.refine_exploit(result.crash_log)

# 실제 프로세스: 약 10-15회 반복

핵심 기술: V8 JIT 타입 혼란 공격 원리

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
graph TD
    A[JavaScript 코드 실행] --> B[Ignition 인터프리터]
    B --> C[프로파일링 데이터 수집]
    C --> D[Maglev JIT 컴파일]
    D --> E[타입 추론 기반 최적화]
    E --> F{타입 가드 검증}
    F -->|정상| G[최적화된 코드 실행]
    F -->|우회 성공| H[타입 혼란 발생]
    H --> I[메모리 안전성 위반]
    I --> J[임의 코드 실행 가능]

타입 혼란(Type Confusion)의 기본 원리:

V8의 JIT 컴파일러는 성능 향상을 위해 런타임 타입 정보를 기반으로 코드를 최적화한다. 문제는 이 타입 추론이 잘못될 때 발생한다.

| 단계 | 정상 동작 | 공격 시나리오 | | :— | :— | :— | | 초기 실행 | 배열을 Integer로 처리 | 배열을 Integer로 처리 | | JIT 컴파일 | Integer 전용 최적화 코드 생성 | Integer 전용 최적화 코드 생성 | | 타입 변경 | 가드 체크로 재컴파일 | 가드 우회 또는 경쟁 조건 | | 결과 | 안전한 실행 | Integer로 객체 포인터 해석 |

AI가 보안 연구에 미치는 영향

생산성 변화

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
# AI 보조 익스플로잇 개발 효율성 분석 (개념적 모델)
class SecurityResearchProductivity:
    def __init__(self):
        self.traditional_hours = 120  # 전통적 방식 평균 소요 시간
        self.ai_assisted_hours = 40   # AI 보조 방식 소요 시간
        
    def calculate_efficiency(self):
        # 초기 분석 단계: AI가 80% 시간 단축
        vulnerability_analysis = {
            "traditional": 30,  # 시간
            "ai_assisted": 6,
            "reduction": 0.80
        }
        
        # PoC 개발: AI가 60% 시간 단축
        poc_development = {
            "traditional": 50,
            "ai_assisted": 20,
            "reduction": 0.60
        }
        
        # 안정화: AI가 40% 시간 단축 (여전히 수동 작업 많음)
        stabilization = {
            "traditional": 40,
            "ai_assisted": 14,
            "reduction": 0.40  # 수동 튜닝 필요
        }
        
        return {
            "vulnerability_analysis": vulnerability_analysis,
            "poc_development": poc_development,
            "stabilization": stabilization
        }

productivity = SecurityResearchProductivity()
results = productivity.calculate_efficiency()

AI 익스플로잇 생성의 한계

Claude Opus가 성공했지만, 여전히 중요한 한계가 존재한다:

  1. 전문가 가이드 필수: AI가 혼자서 처음부터 끝까지 익스플로잇을 작성한 게 아니다. 숙련된 연구자의 지시와 검증이 필요했다.

  2. 반복적 튜닝: 한 번에 완벽한 코드가 나오지 않았다. 크래시 로그 분석, 메모리 레이아웃 조정 등 수동 작업이 수반되었다.

  3. 특정 취약점 클래스에 국한: 타입 혼란 같은 잘 알려진 패턴에는 강하지만, 논리적 취약점이나 복잡한 경쟁 조건은 여전히 어렵다.

  4. 환경 의존성: 특정 Chrome/V8 버전에 한정된 익스플로잇. 범용성은 제한적이다.

방어자 관점: AI 생성 익스플로잇에 대응하는 방법

1. JIT 하드닝 강화

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
// V8 엔진 빌드 시 JIT 보안 옵션 (Chrome 컴파일 설정)
// gn args out/Default

# JIT 컴파일러 보안 강화
v8_enable_verify_heap = true
v8_enable_sandbox = true

# Maglev/TurboFan 검증 강화
v8_enable_maglev_graph_verification = true
v8_enable_turbofan_type_verification = true

# 메모리 안전 기능
v8_enable_pointer_compression = true
v8_enable_memory_corruption_api = false

2. 런타임 모니터링

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
# Chrome 브라우저 보안 모니터링 스크립트 예시
import subprocess
import json

def monitor_chrome_security():
    """Chrome 보안 관련 프로세스 및 플래그 모니터링"""
    
    security_flags = [
        "--site-isolation-trial-opt-out",  # 사이트 격리
        "--disable-jit",                    # JIT 비활성화 (고보안)
        "--no-sandbox",                     # 샌드박스 비활성화 감지
    ]
    
    result = subprocess.run(
        ["wmic", "process", "where", "name='chrome.exe'", 
         "get", "CommandLine"],
        capture_output=True, text=True
    )
    
    # 보안 플래그 감지 로직
    findings = []
    for line in result.stdout.split('
'):
        for flag in security_flags:
            if flag in line:
                findings.append({
                    "flag": flag,
                    "severity": "HIGH" if "no-sandbox" in flag else "MEDIUM"
                })
    
    return findings

3. 취약점 패치 우선순위 결정

| 취약점 유형 | AI 생성 가능성 | 패치 우선순위 | | :— | :— | :— | | 타입 혼란 (Type Confusion) | 높음 | 최우선 (24시간 내) | | UAF (Use-After-Free) | 중간 | 높음 (48시간 내) | | 버퍼 오버플로우 | 높음 | 최우선 (24시간 내) | | 논리적 취약점 | 낮음 | 중간 (1주 내) | | 경쟁 조건 (Race Condition) | 낮음 | 높음 (48시간 내) | | XSS/CSRF | 높음 | 중간 (1주 내) |

AI가 잘 생성하는 패턴의 취약점일수록 빠른 패치가 필요하다. 공격자도 AI를 사용할 수 있기 때문이다.

버그바운티 생태계에


출처: https://news.google.com/rss/articles/CBMifEFVX3lxTE8wTG5acl9DcEkwQklJWVVkQTdmdThGN0RQWkJjMEpWYXp6aVZVWXBaSE1vYV9PaDh1S3pNSXVueU1JUjk4WGtHZ3V0TkJ4eTJYUHBjdUUtVzV0QTY0OFpkVUNoSF80Q19qVUtTMUt1Q2FhLWFQUkl0dzFPMHk?oc=5

Hugo로 만듦
JimmyStack 테마 사용 중