취약점 분석 방법론: 코드 리뷰, 패치 Diffing, 퍼징

새로운 취약점을 발견하는 접근법은 크게 세 가지로 나뉜다 — 소스 코드를 사람이 직접 읽는 코드 리뷰, 패치 전후 바이너리/코드를 비교하는 패치 Diffing, 그리고 자동으로 수많은 입력을 대입해보는 퍼징. 실무에서는 이 셋을 상황에 맞게 섞어서 쓴다.

1. 코드 리뷰 기반 분석#

소스 코드가 있을 때(오픈소스, 또는 계약상 코드 접근이 허용된 화이트박스 점검) 가장 정확한 방법이다.

어디부터 봐야 하는가#

전체 코드를 처음부터 읽는 건 비효율적이다. 취약점이 몰려있을 확률이 높은 지점부터 우선순위를 둔다.

• 신뢰 경계를 넘는 지점: 사용자 입력이 처음 들어오는 파싱 코드, 외부 API 응답을 처리하는 코드
• 위험한 함수 호출: strcpy, system, eval, unserialize, 원시 SQL 쿼리 조합 부분을 먼저 grep으로 훑는다
• 최근 변경된 코드: git log로 최근 커밋을 확인 — 새로 추가된 기능일수록 검증이 덜 됐을 확률이 높다
• 보안 관련 코드 자체: 인증, 권한 검사, 암호화 로직 — 여기 있는 버그는 파급력이 크다

데이터 흐름 추적#

사용자 입력이 어디서 들어와서(source) 어디서 위험하게 쓰이는지(sink)까지, 중간에 검증/이스케이프 없이 그대로 이어지는 경로(taint path)를 손으로 따라간다. semgrep, CodeQL 같은 정적 분석 도구로 흔한 패턴을 자동 스캔한 뒤, 결과를 사람이 다시 검증하는 방식이 실무에서 일반적이다.

2. 패치 Diffing (1-day 취약점 분석)#

벤더가 "보안 패치"라고만 하고 구체적인 취약점 내용을 공개하지 않는 경우가 많다. 이때 패치 전 버전과 패치 후 버전의 코드/바이너리를 비교해서, 정확히 뭐가 고쳐졌는지 역으로 알아내는 게 패치 Diffing이다. CVE 분석 글들에서 다룬 사례들처럼, 취약점이 공개된 뒤에도 "패치를 아직 안 한 시스템"을 대상으로 익스플로잇을 만드는 리서치에 이 방법이 흔히 쓰인다.

소스 코드가 있는 경우#

git diff v1.2.3 v1.2.4 -- src/

간단히 diff만 봐도 변경된 함수와 조건문을 확인할 수 있다. 특히 길이/경계 검사 조건이 추가되거나(if (len > MAX) 같은 게 새로 생김), 함수 호출 순서가 바뀌는 경우가 취약점 수정의 전형적인 패턴이다.

바이너리만 있는 경우#

소스가 공개되지 않은 상용 소프트웨어는 패치 전후 바이너리를 디스어셈블해서 비교한다.

• BinDiff, Diaphora: 두 바이너리의 함수를 자동으로 매칭시켜서, 어떤 함수가 바뀌었는지 시각적으로 보여주는 도구
• 바뀐 함수를 찾으면, Ghidra/IDA로 두 버전을 나란히 놓고 정확히 어떤 조건/검증이 추가됐는지 확인 → 그 검증이 "무엇을 막기 위한 것"이었는지 역으로 추론하면 원본 취약점의 실체가 드러난다

이 방식은 리버싱(정적/동적 분석) 카테고리에서 다룬 기법들을 그대로 실전에 적용하는 과정이기도 하다.

3. 퍼징 (Fuzzing)#

사람이 코드를 읽지 않고도, 프로그램에 방대한 양의 변형된 입력을 자동으로 대입해서 크래시(=잠재적 취약점)를 찾아내는 방법이다.

기본 아이디어#

정상적인 입력 샘플(시드)을 하나 주고, 그걸 조금씩 무작위로 변형해가며 프로그램에 계속 먹인다. 크래시가 나면 그 입력이 버그의 단서가 된다.

Coverage-guided Fuzzing#

무작정 무작위로 변형만 하면 같은 코드 경로만 반복해서 테스트하게 된다. AFL++, libFuzzer 같은 현대적인 퍼저는 코드 커버리지(어떤 분기를 지나갔는지)를 계측해서, "지금까지 안 지나가본 새로운 코드 경로"로 이어지는 입력 변형을 우선적으로 유지하는 방식으로 훨씬 효율적으로 새로운 버그를 찾아낸다.

afl-fuzz -i seeds/ -o findings/ -- ./target @@

퍼징이 잘 통하는 대상#

• 파일 포맷 파서(이미지, 문서, 압축 포맷 등 — 입력 구조가 복잡할수록 파싱 로직에 버그가 몰려있다)
• 네트워크 프로토콜 파서
• 반대로, 인증/비즈니스 로직처럼 "올바른 순서로 여러 상태를 거쳐야 하는" 코드는 무작위 입력만으로는 도달하기 어려워서 퍼징 효율이 떨어진다 — 이런 곳은 코드 리뷰가 더 적합하다

크래시 이후: 삼각측량(Triage)#

퍼저가 크래시를 찾아도, 그게 실제로 악용 가능한 취약점인지(메모리 손상 등) 아니면 그냥 프로그램이 assert로 죽은 것뿐인지 구분해야 한다. AddressSanitizer(ASan)를 붙여서 퍼징하면, 크래시 시점에 정확히 어떤 메모리 손상이 일어났는지(버퍼 오버플로우, use-after-free 등) 훨씬 자세한 정보를 얻을 수 있어서 이 과정이 크게 빨라진다.

세 가지 방법을 어떻게 조합하는가#

실전에서는 순서를 섞어 쓴다 — 퍼징으로 크래시 지점을 찾은 뒤, 그 지점을 코드 리뷰나 리버싱으로 정밀 분석해서 실제 악용 가능성(exploitability)을 판단하는 흐름이 특히 흔하다. 어느 한 방법만 고집하기보다, 대상의 특성(소스 유무, 코드 복잡도, 시간 여유)에 맞춰 방법을 고르는 게 실제 리서치 속도를 크게 좌우한다.