1. 개요

- 미국(CISA, NSA, FBI), 호주(ACSC), 캐나다(CCCS), 뉴질랜드(NCSC-NZ)가 협동해 통신 인프라 관련 보안 가이드라인 발표 [1]
- 사이버 위협 행위자, 특히 중국과 관련된 위협에 대응하기 위한 권고사항

2. 주요내용

구분 설명
모니터링 - 지속적인 스위치, 라우터, 방화벽 등 네트워크 장치의 구성 변경 모니터링 및 비정상적 변경에 대해 경고하는 메커니즘 구축
- 네트워크 흐름 모니터링 솔루션 구현 및 가시성 확보
- 관리 트래픽 노출 최소화 및 전용 관리 워크스테이션에서만 접근 허용
- 사용자 및 서비스 계정 로그인을 모니터링하여 비정상적인 로그인 시도 탐지 및 비활성화
- 중앙 집중화된 로그 관리 및 분석으로 신속한 의심스러운 활동 식별 등
강화 시스템 및 장치 - 프로토콜 및 관리 프로세스 개선
> 대역 외 관리 네트워크 사용
> 기본 거부 ACL 정책 구현
> 강력한 네트워크 세분화
> VPN 게이트웨이에 강력한 암호화 프로토콜 적용
> AAA(Authentication_인증, Authorization_권한부여, Accounting_계정관리) 로깅이 CIA 기능을 갖춘 중앙 로깅 서버로 전송되도록 보장
> 불필요한 프로토콜 비활성화
> 기본 비밀번호 사용 지양
> 신뢰할 수 있는 무결성 검증 도구 활용 등
Cisco 특정 지침 - 사이버 위협 행위자들은 Cisco 장비의 특정 기능을 표적으로 공격하므로 조치 필요
> Cisco Smart Install 서비스 비활성화
> Guestshell 액세스 비활성화
> 암호화되지 않은 웹 관리 기능 비활성화
> Telnet을 비활성화
> 비밀번호 관리 강화
사고 보고 - 피해 발생 시 당국의 관련 기관에 즉시 신고
설계에 의한 보안 - 설계 단계에서부터 보안 고려하여 개발
- 소비자는 보안성을 만족하는 제품을 구매

3. 참고

[1] https://www.cisa.gov/resources-tools/resources/enhanced-visibility-and-hardening-guidance-communications-infrastructure

1. 개요

- 세계 여러 정보 보안 관련 기관이 협력하여 LotL 공격 대비 가이드라인 발표 [1]
- 장시간 공격을 유지할 수 있게 해 주는 LotL 공격이 공격자들 사이에서 인기
- ‘이벤트 로그 관리’를 방어책으로 내세움

 

2. 주요내용

2.1 LotL (Living off the Land)

이미 사용자 시스템에 설치된 여러 자원을 공격에 활용하는 방법
- 정상적으로 발생하는 트래픽과 공격으로 발생한 트래픽의 구분이 힘들며, 공격 지속성을 크게 높일 수 있는 장점

 

2.2 이벤트 로깅 (Event logging)

- 이벤트 로깅은 네트워크 가시성을 지원해 운영과 시스템의 보안 및 복원력을 개선

구분 개요
효과적인 이벤트 로깅 솔루션 ① 중요한 소프트웨어 구성 변경 또는 설치시 담당자에게 경고 잔송
② LotL 공격 또는 침해 후 횡적 이동 등의 보안 사고를 나타낼 수 있는 보안 이벤트 식별
③ 침해의 범위와 정도를 밝혀 사고 대응 지원
④ 정책이 잘 적용되도록 하며, 위반 여부 모니터링
⑤ 오탐과 노이즈를 줄여 저장 공간과 요청 시간 관련 비용을 절감
⑥ 보안 담당자들이 정보를 바탕으로 결정을 내릴 수 있게 지원
⑦ 보안 분석가들에게 유용한 로그와 플랫폼을 제공
핵심 고려 요소 ① 기업에서 승인된 이벤트 로그 정책
② 중앙 집중식 이벤트 로그 접근 및 상관 분석
③ 저장된 데이터의 보안 및 이벤트 로그 무결성
④ 관련 위협에 대한 탐지 전략
로그 정책 ① 어떤 이벤트를 로깅할 것인지 정의
② 어떤 시스템에 이벤트 로깅을 적용할 것인지 정의
③ 이벤트 로그를 모니터링하는 방법 정의
④ 이벤트 로그를 얼마나 보관할 것인지 정의
⑤ 로그 수집 관련 정책의 재평가 시기 정의

 

2.3 로그의 품질

- 사고 대응 및 위협 탐지의 맥락에서 이벤트 로그의 품질은 얼마나 잘 포맷 되었는지가 아닌, 수집된 이벤트 유형에 의해 결정

- 유용한 이벤트 로그는 보안 이벤트를 평가하여 정오탐을 식별하는 능력을 강화

> OT 장치를 포함하는 경우 해당 장치에 대한 고려가 필요

> OT 장치는 메모리와 프로세스에 부하를 주는 임베디드 소프트웨어를 사용하며, 과도한 로깅은 장치의 운영에 악영향을 미칠 수 있음

> OT 장치는 자세한 로그를 생성할 수 없으므로 센서를 사용하여 로그 기능을 보완할 수 있음

> 대역 외 로그 통신 또는 오류 코드와 기존 통신의 페이로드를 기반으로 로그를 기록

 

- LotL을 사용하는 공격자들은 주로 다음과 같은 로그를 수집해 파악할 수 있음

구분 설명
Linux 기반 - curl, systemctl, systemd, python 등을 사용했을 때 기록되는 로그
- 기타 일반적인 LOLBin의 사용와 관련된 로그
Windows 기반 - wmic.exe, ntdsutil.exe, Netsh, cmd.exe, PowerShell, mshta.exe, rundll32.exe, resvr32.exe 등을 사용했을 때 기록되는 로그
- 명령 실행, 스크립트 차단, PowerSehll용 모듈 로그, 관리 작업에 대한 로그
Cloud 환경 - API 호출 및 최종 사용자 로그인을 포함한 모든 컨트롤 플레인 작업을 기록
- 컨트롤 플레인 로그는 읽기 및 쓰기 활동, 관리 변경 사항 및 인증 이벤트를 기록하도록 구성

 

- 이벤트 로그는 대응을 돕기에 충분한 세부 정보가 포함되어 있는 것이 좋음

미국 관리예산국
M-21-312의
로그에 포함되어야
하는 내용
① 올바르게 포맷되고 정확한 타임스탬프 (밀리초 단위가 이상적)
② 이벤트 유형
③ 장치 식별자의 MAC 주소 또는 기타 고유 식별자
④ 세션/트랜잭션 ID
⑤ 자율 시스템 번호
⑥ 출처 및 도착지 IP (IPv4 및 IPv6 포함)
상태 코드
⑧ 응답 시간
⑨ 추가 헤더 (Ex. HTTP 헤더)
⑩ 사용자 ID (해당되는 경우)
⑪ 실행된 명령 (해당되는 경우)
⑫ 이벤트 상관 관계를 돕기 위한 고유 이벤트 식별자 (가능한 경우)
※ 모든 데이터는 추출을 더 쉽게 하기 위해 "키-값 쌍" 형식으로 포맷 (가능한 경우)

 

- 로그의 품질을 높이는 요소들

구분 설명
콘텐츠 및 형식 일관성 - 로그를 중앙 집중화할 때 JSON과 같은 구조화된 로그 형식을 사용
- 형식, 순서, 스키마를 일관되게 유지
- 로그가 생성될 때부터 일관된 형식을 유지하는 것이 좋음
- 그러나, 모든 로그가 정해진 형식을 따를 수 있는 것은 아니므로 자동화된 로그 정규화 방법론을 마련할 필요
타임스탬프 일관성 - 모든 시스템에서 동일한 날짜-시간 형식과 표기법을 사용
- ISO 8601 형식은 연도-월-일-시-분-초-밀리초 순서 권고
로그 보존 - 시스템에 대한 위험 평가 결과에 따라 로그 보관 기간 결정하며, 침입과 영향을 평가하는 로그는 좀 더 오래 보존
- 조직에 적용되는 모든 규제에 어긋나지 않도록 보존
- 조직이 보유하고 있는 저장 공간도 고려
- 공격자들이 로그를 삭제할 수 있으므로, 로그에 대한 접근 또한 강화
※ 어떤 경우 사고를 발견하는 데 최대 18개월이 걸리고, 어떤 악성코드의 경우 70~200일 동안 네트워크에 거주하는 것을 고려

 

2.4 로깅 우선순위

- 조직 내에서 로그 소스를 우선순위를 둘 것우선순위가 낮은 로그도 모니터링할 것을 권장

구분 설명
로깅 우선순위 - LotL 맥락에서 기업의 망은 공격자들이 사용하기 좋은 도구들이 많음
> 해당 도구들과 관련하여 로그의 우선순위를 정하는 것이 효과적

 공격 대상이 될 가능성이 높은 중요 시스템과 데이터
② 원격 접근, 네트워크 메타데이터, 기본 서버 OS, 인터넷 연결 서비스
③ ID 및 도메인 관리 서버
④ 기타 중요 서버
⑤ 네트워크 외곽에 있는 라우터와 방화벽 등
⑥ 관리자의 관리 작업을 위한 워크스테이션
⑦ 환경 설정, 시스템 모니터링, CI/CD, 취약점 스캔, 비밀 관리, 권한 관리에 사용되는 시스템
⑧ 데이터 저장소
⑨ 보안 소프트웨어
⑩ 사용자 컴퓨터
⑪ 사용자 애플리케이션
⑫ 웹 프록시
⑬ DNS 서비스
⑭ 이메일 서버
⑮ DHCP 서버
⑯ 오래된 레거시 IT 자산
⑰ 하이퍼바이저 호스트
⑱ 프린터 등 부수적인 IT 장치
⑲ 애플리케이션 게이트웨이 등 네트워크 구성 요소
OT 환경
로깅 우선순위
- 최근 OT 네트워크에 대한 공격이 증가

① 안전 및 서비스 제공에 중요한 OT 장치 (Air-Gap 시스템 제외)
② 공공 인터넷과 연결된 OT 장치
③ 네트워크 외곽선을 통과했을 때 접근이 가능해지는 OT 장치
④ 로깅 기능이 없는 OT 장치 (OT 장치의 네트워크 트래픽 모니터링 필요)
엔드포인트
로깅 우선순위
- 팬데믹 등으로 재택 근무의 증가

사용자가 사용하는 웹 프록시
② 회사/기관에서 운영 혹은 사용하는 DNS 서비스
③ 조직에 공식 등록된 장치들의 보안 상황
④ 조직에 공식 등록된 장치들의 행동 패턴
⑤ 사용자 계정에서 발생하는 활동
⑥ VPN 솔루션
⑦ MDM 및 모바일 애플리케이션 관리(MAM)
클라우드 컴퓨팅
로깅 우선순위
- IaaS, PaaS, SaaS 등 플랫폼과 유형에 따라 이벤트 로깅 방식을 조정
> Ex. IaaS : 테넌트에 로깅 책임을 부여 / SaaS : 서비스 제공 업체에 로깅 책임 부여
> 기업(사용자)과 제공자(CSP) 간 긴밀한 협조 필요

표적이 될 가능성이 높은 중요 시스템과 데이터
② 공공 인터넷에 직접 연결된 서비스
③ 클라우드 서비스에 직접 접근하고 관리하는 테넌트의 계정
④ 환경 설정
⑤ 모든 보안 관련 계정 (생성, 삭제, 수정 등)
⑥ 서드파티 인증 서비스를 활용할 때(성공/실패 로그)
⑦ 클라우드 서비스에서 생성된 로그, 클라우드 API 로그, 네트워크 이벤트 등

 

2.5 이벤트 로그의 안전한 저장 및 무결성

- 중앙 집중식 이벤트 로깅 시스템을 구축한 후 SIEM, XDR과 같은 분석 도구로 로그를 전달할 것을 권장

> 충분한 저장 용량을 갖출 것 (침해가 발생하였으나, 과거 이벤트 로그가 없으면 사고 대응에 부정적 영향을 미침)

> 별도의 네트워크 또는 세분화된 네트워크에 보관하며, 로그 변조의 위험을 줄이기 위한 추가 보안 제어 기능이 필요

 

- 이벤트 로그의 안전한 전송 및 무결성을 보장하기 위해 TLS 1.3 및 암호화 검증 등의 보안 메커니즘 구현 권장

> 공격자들은 로그를 수정하거나 삭제하며, 로그에서 유용하면서 민감한 데이터를 확인할 수도 있음

> 적정한 요건을 갖춘 사용자만이 이벤트 로그에 접근할 수 있는 권한을 부여

 

2.6 LotL 탐지

- 아주 조금의 이상 행동이라도 탐지 및 기록해야 함

구분 설명
이상 (비정상적) 행동 비정상적인 시간대에 발생한 사용자 로그인 (근무 외 시간, 공휴일 등)
② 사용자가 일반적으로 접근하지 않는 서비스에 접근 혹은 접근 시도
③ 비정상적인 장치를 활용한 로그인 및 로그인 시도
④ 비정상적으로 빈번한 로그인 시도
⑤ 물리적으로 불가능한 로그인 시도 (불가능한 이동(Impossible Travel) 등)
⑥ 대량의 데이터 다운로드 및 외부 유출
⑦ 정상 인증 단계를 거치지 않은 로그인
⑧ 다양한 사용자 ID로 접근하는 단일 IP 주소
⑨ 사용자 계정 생성 / 비활성화 된 계정의 재활성화(특히 관리자 계정)
⑩ 일반적으로 통신 트래픽이 없는 장치에서 트래픽이 발생
⑪ 비정상적인 스크립트 실행
⑫ 갑작스러운 로그 삭제
⑬ 비정상적인 프로세스 생성 및 실행
⑭ 보안 소프트웨어 및 로깅 소프트웨어의 환경 설정 변경
추가 분석 ① 프로세스 생성 이벤트 / 명령줄 감사 등 상세 로깅 활성화 상태로 유지
> 로그 가시성 향상 가능
② 조직 내에서 사용할 수 있는 정상 바이너리의 기준 생성
> 비정상 바이너리가 자연스럽게 결정
③ 진화하는 위협에 따라 다양한 운영 체제에 대한 탐지 규칙 생성
Windows : powershell.exe, cmd.exe, regedit.exe 등에 대한 상세 탐지 규칙
Linux : curl, systemctl, python 등에 유의
OT 환경 ① 비정상적인 혹은 예상하기 힘든 도구의 활용
② 벤더나 서드파티의 갑작스러운 접근
③ 유지보수나 원격 모니터링을 위한 도구의 비정상적인 사용
④ 운영 체제, 소프트웨어, 펌웨어, 환경, 데이터베이스 등의 무단 변경 및 무단 업데이트
⑤ 제어 시스템과 외부 네트워크 간의 비정상적인 통신
⑥ 평소에 통신 활동이 없던 구성 요소 간에 발생하는 통신
⑦ 비정상적인 스크립트 실행

3. 참고

[1] https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3880942/nsa-joins-allies-in-releasing-best-practices-for-event-logging/
[2] https://www.boannews.com/media/view.asp?idx=132371&page=1&kind=1

1. NVIDIA Container Toolkit [1]

- 컨테이너 런타임 라이브러리와 NVIDIA GPU를 활용하도록 컨테이너를 자동으로 구성하는 유틸리티가 포함
- Docker 컨테이너 내에서 NVIDIA GPU를 효율적으로 활용할 수 있도록 만들어진 도구
> 일반적인 환경에서 Docker를 동작 시키면 Host의 CPU를 기반으로 Docker가 생성되며, GPU를 사용할 수 없음
> 과거에는 GPU를 사용하기 위해 컨테이너 내에 NVIDIA GPU 드라이버를 설치하였으나, 안전성-하드웨어와 컨테이너의 드라이버 버전을 매번 맞춰야하는-문제가 있음
> NVIDIA Container Toolkit은 Container에서 GPU를 사용시 libcuda.so와 같은 Host에 있는 CUDA Toolkit들을 마운트해주는 역할

※ CUDA(Computed Unified Device Architecture) Toolkit: 고성능 GPU 가속 애플리케이션을 만드는 개발 환경을 제공 [2]

 

2. 취약점 [3]

2.1 CVE-2024-0132

[사진 1] CVE-2024-0132 [4]

- NVIDIA Container Toolkit에서 발생하는 TOCTOU 취약점 (CVSS: 9.0)

> 악성 이미지를 통해 실행되는 컨테이너를 탈출해 호스트 시스템에 대한 전체 액세스 권한을 얻을 수 있음

> 악용에 성공할 경우 코드 실행, 서비스 거부(DoS), 권한 상승, 정보 유출, 데이터 변조 등의 공격을 유발할 수 있음

※ 구체적인 기술적 세부 사항은 공개하지 않음

영향받는 버전: NVIDIA Container Toolkitv 1.16.1 이하 버전

2.1.1 TOCTOU (Time-Of-Check to Time-Of-Use) 취약점

자원을 사용하는 시점과 검사하는 시점이 달라서 자원의 상태변동으로 야기되는 Race Condition 취약점

> 병렬시스템(멀티프로세스로 구현한 응용프로그램)에서는 자원(파일, 소켓 등)을 사용하기에 앞서 자원의 상태를 검사

> 하지만, 자원을 사용하는 시점과 검사하는 시점이 다르기 때문에, 검사하는시점(Time Of Check)에 존재하던 자원이 사용하던 시점(Time Of Use)에 사라지는 등 자원의 상태가 변하는 경우가 발생

동기화 구문을 통해 한번에 하나의 프로세스만 공유자원에 접근 가능하도록 처리

> 성능에 미치는 영향을 최소화하기 위해 임계코드 주변만(동기화가 필요한 부분만) 동기화 구문을 사용

2.1.2 공격 과정

[영상 1] 공격 과정 [5]

① 공격자는 악성 이미지를 제작해 유포한 후 대상 플랫폼에서 악성 이미지 실행
> 공급망 또는 사회공학적기법을 사용해 이미지 실행을 유도
② CVE-2024-0132를 악용해 호스트 파일 시스템에 엑세스
③ Container Runtime Socket을 이용해 호스트 시스템에서 임의의 명령 실행
> docker.sock 및 containerd.sock 악용: root 권한으로 호스트 시스템에서 컨테이너로 임의의 명령을 실행할 수 있음

 

2.2 CVE-2024-0133

[사진 2] CVE-2024-0133 [6]

- 컨테이너 이미지가 호스트 파일 시스템에 빈 파일을 생성할 수 있는 취약점

영향받는 버전: NVIDIA Container Toolkitv 1.16.1 이하 버전

 

※ 두 취약점 모두 CDI (Container Device Interface)가 사용되는 경우 영향받지 않음
> CDI (Container Device Interface): 컨테이너 런타임에서 NVIDIA GPU와 같은 복잡한 디바이스에 대한 액세스를 표준화 [7]

3. 대응방안

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

취약점 제품명 영향받는 버전 해결 버전
CVE-2024-0132
CVE-2024-0133
NVIDIA Container Toolkit v1.16.1 이하 v1.16.2
NVIDIA GPU Operator v24.6.1 이하 v24.6.2

4. 참고

[1] https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/index.html
[2] https://developer.nvidia.com/cuda-toolkit
[3] https://www.wiz.io/blog/wiz-research-critical-nvidia-ai-vulnerability
[4] https://nvd.nist.gov/vuln/detail/CVE-2024-0132
[5] https://www.youtube.com/watch?v=kslKQMgWMzY
[6] https://nvd.nist.gov/vuln/detail/CVE-2024-0133
[7] https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/cdi.html
[8] https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133&pageIndex=1&nttId=71562&menuNo=205020
[9] https://nvidia.custhelp.com/app/answers/detail/a_id/5582
[10] https://thehackernews.com/2024/09/critical-nvidia-container-toolkit.html

1. 개요

- 해외 연구팀이 기아 차량의 번호판만으로 차량에 명령을 내릴 수 있는 취약점 발견 [1]
- 모든 기아 차량에 영향 받으며, 기아 Connect 구독 여부와 관계없이 차량 하드웨어가 장착된 경우 공격 가능
- 공격자는 개인정보(차량 소유주 이름, 전화번호, 이메일, 실주소 등)뿐만아니라 차량의 제어권을 획득할 수 있음

 

2. 주요 내용

- 연구진은 웹사이트 owners.kia[.]com와 Kia Connect iOS 앱 com.myuvo[.]link 분석
> 두 애플리케이션은 인터넷을 통해 차량 제어 명령을 보낼 수 있음

※ 웹 사이트는 백엔드 역방향 프록시를 사용해 사용자 명령을 실제 차량 명령을 실행하는 api.owners.kia.com 백엔드 서비스로 전달
※ 앱은 해당 API에 직접 액세스

 

- owners.kia[.]com 웹사이트에서 차량 문 잠금 해제를 위한 HTTP 요청

[사진 1] 요청 예시

- 서버는 JSESSIONID를 사용해 Sid 세션 ID 생성 및 백엔드 API에 요청 전달

> Sid는 세션 토큰, Vinkey는 차대번호(VIN_차량 식별에 사용되는 고유한 일련 번호)와 매핑되는 UUID

[사진 2] 요청 예시

2.1 Kia 딜러 인프라 취약점

- 연구진은 Kia에서 새 차를 구매할때, 차량 등록을 위해 고객에게 보내는 이메일에서 URL을 발견

> VIN 파라미터는 딜러가 생성한 일회성 토큰으로, 파라미터로 지정된 차량을 수정할 수 있음

https://kiaconnect.kdealer.com/content/kDealer/en/kiauser.html?token=dealer_generated_access_token&vin=example_vin&scenarioType=3

 

- 해당 URL을 로드하면 토큰의 유효성을 확인하는 HTTP 요청이 전송

> 딜러 사이트의 요청 URI가 owners 사이트와 동일한 /apps/services/kdealer/apigwServlet.html

> 딜러용 내부 API로 요청을 전달하는 프록시가 있을 것으로 예상

[사진 3] 토큰 유효성 검사

- JavaScript를 확인한 결과 딜러 차량 조회, 계정 조회, 등록, 해지 등 직원 전용 기능을 가진 API 호출 발견

> 소유한 차량의 VIN으로 API 앤드포인트에 접근해 보았으나, 401 Unauthorized 반환

dealerVehicleLookUp() {
    this.displayLoader = !0, this.vinToEnroll = "eDelivery" != this.entryPoint ? this.vinToEnroll.replace(/\s/g, "") : this.userDetails.vin, "17" == this.vinToEnroll.length && this.landingPageService.postOffice({
        vin: this.vinToEnroll
    }, "/dec/dlr/dvl", "POST", "postLoginCustomer").subscribe(i => {
        i && (i.hasOwnProperty("body") && "0" == i.body.status.statusCode ? this.processDvlData(i.body) : "1003" == i.body.status.errorCode && "kia-dealer" == this.entryPoint ? this.reRouteSessionExpire() : (this.displayLoader = !1, this.alertMessage = i.body.status.errorMessage, document.getElementById("triggerGeneralAlertModal").click()))
    })
}

 

2.2 일반 계정으로 딜러 API 접근

- 딜러 웹 사이트에서 새로운 계정을 생성해 액세스 토큰을 생성한 뒤 API 접근 시도

> 딜러 사이트에서 owners 사이트와 동일한 방식으로 사용자 등록을 시도한 결과 200 OK 반환

> 이후 로그인하여 액세스 토큰 생성 VIN 조회 API 호출 결과 차량 소유주 이름, 전화번호, 이메일 주소 반환

> 일반 자격 증명과 수정된 채널 헤더를 사용하면 모든 딜러용 API에 접근할 수 있다는 것을 의미

 

2.3 차량 무단 접근

- JavaScript를 살펴본 결과 차량 등록, 해지, 수정 엔드포인트가 어떻게 동작하는지 파악

[사진 4] 차량 무단 접근

- 다음 4단계를 거치면 차량에 무단 접근이 가능하며, 피해자는 차량 접근 알림이나 권한 변경 사실을 알지 못함

> 번호판을 통해 VIN을 알아낸 뒤 API를 이용해 추적, 잠금 해제, 시동 걸기, 경적 울리기 등의 명령을 수행할 수 있음

① 딜러 토큰 생성 및 HTTP 응답에서 “token” 헤더 추출

- authUser 엔드포인트를 통해 인증하여 세션 토큰 획득

[사진 5] 딜러 토큰 생성

② 피해자의 이메일 주소 및 전화번호 알아내기

- 추가된 세션 토큰 헤더를 통해 kiaconnect.kdealer.com 웹사이트의 모든 딜러 엔드포인트에 접속 및 피해자의 이름, 전화번호, 이메일을 검색할 수 있음

[사진 6] 피해자 정보 조회

③ 유출된 이메일 주소와 VIN으로 기존 소유자의 접근 권한 수정

- 이전 단계에서 얻은 이메일을 이용해 공격자를 기본 계정 소유자로 추가

[사진 7] 차량 소유주 접근 권한 수정

④ 공격자를 차량의 새로운 소유자로 추가

- 공격자의 이메일을 이용해 차량의 소유자로 추가 및 이를 통해 차량에 임의 명령을 보낼 수 있음

[사진 8] 공격자 추가

2.3 PoC용 대시보드 제작

- 공격자는 (1) Kia 차량의 번호판을 입력하고 (2) 소유주 개인 식별 정보를 가져온 뒤 (3) 차량 제어 명령을 실행할 수 있는 개념 증명용 대시보드 개발

- 차량 무단 접근을 시도하는 Exploit 페이지명령 전달과 위치를 추적하는 Garage 페이지로 구성

> 잠긴 Kia 렌트카를 대상으로 테스트 및 문 잠금/해제, 시동 켜기/끄기, 경적 울리기, 위치 추적에 성공

[영상 1] PoC [2]

- 해당 취약점을 Kia에 제보 및 수정 완료

> PoC 도구는 공개되지 않았으며, Kia는 취약점이 악의적으로 악용되지 않았음을 확인

3. 참고

[1] https://samcurry.net/hacking-kia#targeting-kia-dealer-infrastructure
[2] https://www.youtube.com/watch?v=jMHFCpQdZyg
[3] https://news.hada.io/topic?id=16961
[4] https://www.boannews.com/media/view.asp?idx=133232&page=1&kind=1
[5] https://www.dailysecu.com/news/articleView.html?idxno=159771

1. 개요

- Air-gap 컴퓨터에서 데이터를 빼내는 RAMBO(Radiation of Air-gapped Memory Bus for Offense) 공격 발표
- RAM에서 발생하는 전자기 방사를 악용
- 인터넷 등 네트워크와 단절된 시스템도 완전히 안전하지 않다는 사실을 보여줌

 

2. 주요내용 [1]

2.1 RAM (Random Access Memory)

- 데이터를 임시로 저장하는 메모리 장치로 전원이 차단되면 내용이 지워지는 휘발성 기억 장치
- 주로 CPU가 실행할 프로그램의 데이터나 명령어를 빠르게 읽고 쓸 수 있도록 지원하는 역할

 

2.2 Air-Gap

공용 또는 안전하지 않은 네트워크와 물리적으로 연결되지 않은 컴퓨터 시스템
보안을 최우선으로 해야 하는 환경에서 주로 사용
- 네트워크와 물리적으로 격리되어 보안을 강화하는 장점이 있으나 운영이 복잡해지는 단점이 존재
> 별도 네트워크 인프라 구축을 위한 높은 비용
> 외부 시스템과 데이터를 주고받기 위해 물리적인 매체 사용 필요
> 소프트웨어 업데이트의 어려움 등

 

2.3 RAMBO(Radiation of Air-gapped Memory Bus for Offense) Attack

악성코드가 삽입된 USB 드라이브 등을 Air-Gap 시스템에 연결하여 악성코드를 배포
> Air-Gap 시스템에 물리적인 접근이 가능해야하는 조건이 존재
감염된 Air-Gap 시스템에서 정보를 빼내기 위해 Air-Gap 은닉 채널을 사용

※ 은닉 채널: 정상적인 통신 경로가 아닌, 의도치 않은 방식으로 정보를 전달하는 비밀 통로

 

- 악성코드는 RAM을 조작해 약한 전자기 신호를 생성하고 은닉 채널을 통해 전송 및 이를 수신하여 데이터 탈취
> 문서, 키로깅, 비밀번호, 생체 정보 등을 Air-Gap 은닉 채널을 통해 탈취
본 논문에서 악성코드는 RAM의 전자기 방출을 활용하여 정보를 변조하여 외부로 전송하고, 무선 수신기와 안테나를 통해 정보를 수신 및 복조한 다음 원래의 바이너리 또는 텍스트로 디코딩해 정보 탈취

 

- RAM은 CPU와 데이터, 명령어, 주소를 System Bus를 통해 주고 받음

Data Bus - CPU와 기억장치, I/O장치 사이에서 Data를 전달하는 통로 (양방향)
- Data Bus 크기(폭)는 한 번에 전송될 수 있는 데이터의 크기(Bit 수)를 결정 
Ex. 64Bit Data Bus는 한 번의 작업으로 64Bit(8Byte)의 데이터를 전송 가능
Address Bus - CPU에서 주기억장치, I/O장치로 기억장치 주소, I/O 장치 포트 번호를 전달하는 통로 (단방향)
- Address Bus 크기(폭)은 최대 기억장치 용량 결정(2^주소 버스 크기)
Ex. 32Bit Address Bus는 최대 4기가바이트(2^32) 메모리를 주소 지정할 수 있음
Control Bus - 데이터 전송 타이밍과 시퀀스를 조정하는 제어 신호를 전달
- 데이터가 준비되면 읽기, 쓰기, 메모리 칩 활성화 및 신호 전달을 처리

 

- 데이터가 Bus를 통해 전송될 때, 주로 Data Bus에서 급격한 전압 및 전류 변화를 수반
> 이는 전자기장을 생성하여 전자기 간섭(EMI) 또는 무선 주파수 간섭(RFI)을 통해 전자기 에너지를 방출할 수 있음

 

- 해당 공격에서는 온오프 변조 방식(On-Off Keying)과 맨체스터 코드(Manchester code)를 사용
온오프 변조 방식을 사용해 1과 0을 전자기 신호로 변환하며, 1은 신호가 켜진 상태, 0은 꺼진 상태로 표현
맨체스터 코드(Manchester code) 사용해 데이터를 전송하는 동안 오류 검출 및 신호 동기화를 강화 
> 공격자는 전자기 신호를 포착해 원래 이진 정보로 복원하며, 이 정보는 비밀번호, 암호화 키, 중요 문서 등 다양한 민감 데이터를 포함할 수 있음

 

- 공격은 소량의 데이터를 전송하는 데 매우 효과적
> 최대 1,000bps의 전송 속도를 가지며-초당 128Byte, 0.125KB/s-비밀번호, 키 입력, 암호화 키 등 데이터를 탈취하는데 충분함
> 4096 Bit RSA 키를 4~42초 사이에 빼낼 수 있음을 입증

[사진 1] RAMBO 비밀 채널을 통한 다양한 유형의 정보 유출 시간

공격 범위는 전송 속도에 따라 달라짐
> 고속 전송의 경우 최대 3미터 범위에서, 느린 속도로 전송할 경우 7미터까지 범위가 확장
> 속도가 빠를수록 오류율이 증가

 

2.4 대응

- RAMBO 공격은 기존 보안 방어책으로는 탐지 및 차단이 어려움
> 네트워크 트래픽이나 파일 변조가 아닌 RAM에서 발생하는 전자기 신호를 악용하기 때문에 다음과 같은 대책 제안

물리적 보안 강화 공기 격리 시스템 주변의 접근을 제한하는 물리적 방어를 강화
전자기 방해 장치 전자기 방사 신호를 방해하는 장치를 사용해 신호가 포착되지 않도록 해야 함
패러데이 케이지 공기 격리 시스템을 패러데이 케이지에 넣어 전자기 방사를 외부로부터 차단할 수 있음
RAM 신호 교란 RAM 동작 시 신호를 방해해 전자기 방사 신호 자체를 교란하는 방법

※ 단, 이러한 대책은 높은 비용과 운영상 부담을 초래할 수 있음

 

3. 참고

[1] https://arxiv.org/abs/2409.02292
[2] https://www.dailysecu.com/news/articleView.html?idxno=159257

1. 개요

- 업데이트된 윈도우 시스템의 보안을 무너뜨릴 수 있는 두 개의 제로데이 취약점이 공개 (Windows Downdate 공격) [1]

- 다운그레이드 공격을 통해 윈도우 서버 시스템이 이전의 취약한 상태로 되돌아갈 수 있음

> 윈도우 업데이트의 액션 리스트를 조작함으로써 시스템의 구성 요소를 다운그레이드

> 공격자는 NT 커널, DLL, VBS, UEFI 기능까지 다운그레이드할 수 있음

 

1.1 Windows Update Architecture

- Windows Update COM을 통해 통신하는 업데이트 클라이언트와 업데이트 서버가 포함

> 업데이트 클라이언트는 Administrator, 업데이트 서버는 Trusted Installer가 적용되며, 업데이트 파일은 Trusted Installer만 액세스 가능

[사진 1] Windows Update 개요

- 업데이트 흐름

① 클라이언트는 서버가 제공하는 업데이트 폴더에 포함된 업데이트를 수행하도록 서버에 요청

> 업데이트 폴더에는 업데이트 구성 요소가 들어 있음

구분 설명
MUM 파일 - MS 업데이트 메타데이터
- 메타데이터 정보, 구성 요소 종속성, 설치 순서 등을 포함
- 명시적으로 서명되어 있지 않지만 Catalog 파일에 서명되어 있음
Manifest 파일 - 파일 경로, 레지스트리 키, 설치 프로그램에서 실행할 설치 프로그램 등과 같은 설치 관련 정보가 포함
- 명시적으로 서명되어 있지 않지만 Catalog 파일에 서명되어 있음
Differential 파일 - 기본 파일의 델타 파일
- 기본 파일과 델타 파일을 합치면 전체 업데이트 파일이 나옴
- 서명되지 않음
Catalog 파일 - MUM과 Manifest 파일의 디지털 서명
- 여러 파일을 한 번에 서명할 수 있도록 함
- 파일 자체적으로 디지털 서명이 되어 있어 수정 불가

② 서버는 업데이트 폴더의 무결성 검증

③ 무결성 검증 후, 클라이언트가 액세스할 수 없는 서버 제어 폴더에 업데이트 파일을 저장

④ 서버는 서버 제어 폴더에 작업 목록을 Pending.xml 파일로 저장하며, 해당 파일에 업데이트 작업이 포함

> 파일 생성, 파일 삭제, 파일 이동, 파일 하드 링크, 레지스트리 키 및 값 생성, 키 및 값 삭제 등의 기능을 제공하는 XML 파일

OS가 재부팅되면 작업 목록 작동 및 재부팅 중 업데이트 진행

 

2. 주요내용

- 윈도우 시스템을 다운그레이드 할 수 있는 제로데이 공격 Windows Downdate 발견

> CVE-2024-38202 (CVSS: 7.3): Windows Update Stack 권한 상승 취약성

> CVE-2024-21302 (CVSS: 6.7): Windows Secure Kernel Mode 권한 상승 취약성

 

2.1 Differential 파일 및 Action List

- 해당 공격에서는 Differential 파일 악용을 시도하였으나, 그러지 못함

> 예상 업데이트 파일의 해시 값이 Manifest 파일에 하드코딩되어 있음

> Manifest 파일 변경 시 Catalog 파일의 서명이 깨짐

 

- Action List의 경우 Trusted Installer가 적용되어 내용을 변경할 수 없음

> 레지스트리에서 Action List 경로를 검색해보니 PoqexecCmdline 키 발견 (목록과 목록 경로를 구문 분석하는 실행 파일을 포함)

> 해당 키의 보안 속성을 확인한 결과 Trusted Installer가 적용되지 않음

 

- 다운그레이드를 수행하기 위해 다음 작업을 수행

> 식별자는 무결성 확인을 위해 작업 목록의 식별자와 비교되는 숫자

> 다음 세 가지 작업 모두 Trusted Installer가 적용되지 않음

> 이를 통해 사용자 지정 다운그레이드 작업 목록으로 시스템을 업데이트할 수 있었음

* 작업 목록은 검증 후 생성되므로 검증을 가정하기 때문에 모든 무결성 검증을 우회

[사진 2] 다운그레이드
[사진 3] 다운그레이드 공격 전(위) 후(아래) AFD.sys 버전 비교

2.2 VBS UEFI 잠금 우회

- VBS (Virtualization-Based Security): 하드웨어 가상화 및 Windows 하이퍼바이저를 사용하여 시스템을 여러 개의 격리된 환경으로 나누고, 각 환경을 보호함으로써 전체 시스템의 보안을 강화하는 기술 [3]

- UEFI (Unified Extensible Firmware Interface): 운영 체제가 시작되기 전에 시스템을 검사하고, 보안 부팅(Secure Boot) 등의 기능을 통해 보안성을 높임 [4]

> UEFI 잠금 기능을 구현하여 VBS를 비활성화로부터 보호

> 사용자가 VBS를 비활성화하려면 MS에서 서명한 EFI 애플리케이션을 로드해야 함

> EFI는 부팅 중 사용자에게 VBS 비활성화를 물리적으로 승인하도록 요청하며, 승인 시 VBS 비활성화

 

- OS로더가 정상적으로 부팅되고 VBS의 파일 중 하나를 검증하지 못하면 VBS를 포기

> 해당 프로세스를 통해 VBS 비활성화 및 UEFI 잠금을 우회할 수 있었음 [5]

[사진 4] VBS 비활성화

2.3 Exploit

- VBS의 보안 경계는 다음을 권한 상승으로 간주

> VTL0(일반적인 실행 환경) -> VTL1(보안이 강화된 환경)

> Ring3(일반적인 실행 환경)/0(커널) -> Ring -1(하이퍼바이저)

[사진 5] 권한 상승

- 연구에서는 세 가지 경우를 대상으로 다운그레이드 수행

① 보안 모드의 격리된 사용자 모드 프로세스 대상

[사진 6] 보안 모드의 격리된 사용자 모드 프로세스 대상

- Credential Guard

> Ring3-VTL1에서 LsaIso.exe라는 이름의 격리된 사용자 모드 프로세스로 구현

> Credential Guard를 실행하면 비밀이 원래 LSASS 프로세스 대신 VTL1 LsaIso.exe에 저장

 

- CVE-2022-34709로 다운그레이드 진행 및 다운그레이드 감지 없이 허용 (Ring3-VTL0 -> Ring3-VTL1)

> CVE-2022-34709: Windows Defender Credential Guard 보안 기능 우회 취약성 [6]

② 보안 모드 커널 대상

[사진 7] 보안 커널 대상

- 보안 커널이란 일반 커널에 보안 기능을 추가하여 안전성을 강화한 커널

- CVE-2021-27090로 다운그레이드 진행 및 다운그레이드 감지 없이 허용 (Ring3-VTL0 -> Ring3-VTL1)

> CVE-2021-27090: Windows 보안 커널 모드 권한 상승 취약성 [7]

③ 하이퍼바이저 대상

[사진 8] 하이퍼바이저 대상

- 하이퍼바이저 권한 상승 취약점이 다수 있었으나, 구체적인 내용은 공유되지 않음

> 하이퍼바이저를 2년 전 버전으로 다운그레이드 시도 및 다운그레이드 감지 없이 허용 (Ring3-VTL0 -> Ring3-VTL1)

 

[사진 9] 다운그레이드 전(위) 후(아래) 하이퍼바이저 버전 비교 [8]

- 24.02 MS에 내용 전달 및 MS 24 8월 정기 보안 업데이트에서 해당 취약점을 포함한 다수의 취약점에 대한 패치를 제공 [9]

 

3. 참고

[1] https://www.safebreach.com/blog/downgrade-attacks-using-windows-updates/
[2] https://www.safebreach.com/wp-content/uploads/2024/08/AFD-Downgrade-Kernel-Code-Execution.mp4
[3] https://learn.microsoft.com/ko-kr/windows-hardware/design/device-experiences/oem-vbs
[4] https://namu.wiki/w/UEFI
[5] https://www.safebreach.com/wp-content/uploads/2024/08/Credential-Extraction-PPL-and-UEFI-Lock-Bypass.mp4
[6] https://nvd.nist.gov/vuln/detail/CVE-2022-34709
[7] https://nvd.nist.gov/vuln/detail/cve-2021-27090
[8] https://www.safebreach.com/wp-content/uploads/2024/08/Hyper-V-Hypervisor-Downgrade.mp4
[9] https://msrc.microsoft.com/update-guide/releaseNote/2024-Aug
[10] https://www.dailysecu.com/news/articleView.html?idxno=158444

1. 개요 [1]

- SmartScreen, Windows Smart App Control는 평판 기반 보호를 제공

- 평판 기반 보호는 낮은 오탐률을 유지하면서 탐지 기능을 향상 시킬 수 있으나, 우회가 가능

> 공격자가 SmartScreen, Windows Smart App Control을 경고나 팝업 없이 우회할 수 있는 설계상 약점 존재

 

2. SmartScreen, Windows Smart App Control

2.1 SmartScreen [2][3]

- Window 8 부터 적용된 보안 기능

- 사용자를 악성 웹 사이트, 악성 파일 다운로드 등의 위협으로부터 보호

- 사용자가 웹 사이트를 방문하거나 임의의 파일을 다운 또는 설치할 때 사이트와 파일의 안전성을 검증하여 차단 또는 경고를 발생

- 방문하는 웹 사이트 또는 다운로드 파일의 평판(사전 정의 목록 비교, 다운로드 트래픽, 백신 조회 결과 등)을 비교하여 정상과 악성 판단

> 사용자로부터 사이트 또는 파일에 대한 의견을 받아 목록 업데이트 가능

> 웹 사이트의 경우 상위 트래픽(정상), 위험(차단), 알 수 없음(사용자가 접근 여부 결정)

> 파일의 경우 다운로드 허용 또는 차단(파일 실행 시 경고 창을 발생시켜 마지막으로 확인)

※ 설정 (Windows + I) > 개인 정보 및 보안 > Windows 보안 > 앱 및 브라우저 컨트롤 > 평판 기반 보호 > 평판 기반 보호 설정 > Microsoft Edge SmartScreen

[사진 1] SmartScreen

2.2 Windows Smart App Control (SAC) [4]

- Window 11 부터 적용된 보안 기능

- 사용자가 직접 설치하는 모든 앱을 실시간 분석 및 평판을 확인(사전 정의 목록 비교, 서명 출처 등)하여 악성 앱으로부터 시스템을 보호

> 앱 실행 시 앱에 대한 정보를 MS의 클라우드 기반 보안 서비스로 전송하여 악성 여부 확인

> 앱에 대한 확실한 예측을 할 수 없는 경우 서명의 유효성을 확인

> 악성이거나 유효한 서명이 없는 경우 또는 유효하지 않은 경우 앱 차단

※ 설정 (Windows + I) > 개인 정보 및 보안 > Windows 보안 > 앱 및 브라우저 컨트롤 > 스마트 앱 컨트롤

[사진 2] Windows Smart App Control (SAC)

3. 우회 방법

3.1 서명된 악성코드 (Signed Malware)

- SAC악성 코드에 코드 서명 인증서를 사용하여 서명함으로써 우회 가능

> 공격자는 기업을 사칭하여 EV(Extend Validation) 서명 인증서를 도용하는 방법을 찾아냄

> 인증 기관(CA, Certificate Authority)는 부정하게 취득한 인증서를 최소화하고 남용을 단속하는데 더 많은 노력 필요

 

* 참고 [5]

구분 설명
DV (Domain Validation) 도메인의 소유정보만으로 인증
OV (Organization Validation) DV + 소속되어 있는 회사(조직) 정보를 추가로 인증
EV (Extend Validation) OV + 확장적인 검증이 필요

 

3.2 평판 하이재킹 (Reputation Hijacking)

- 평판 기반 멀웨어 방지 시스템에 대한 일반적인 공격 방법

> 평판이 좋은 앱을 찾아 용도를 변경하여 시스템을 우회하는 것을 포함

> FFI(Foreign Function Interface) 기능을 포함하는 경우 공격자는 메모리에 임의의 코드와 멀웨어를 쉽게 로드하고 실행할 수 있음

* Foreign Function Interface(FFI): 한 프로그래밍 언어로 작성된 프로그램이 다른 언어로 작성된 서비스를 이용할 수 있거나 그에 따른 함수를 호출할 수 있는 구조 [6]

 

- 또는, 정상적인 애플리케이션을 악용하여 평판을 가로챌 수 있음

> BoF 또는 여러 애플리케이션을 체인으로 연결하여 임의의 코드를 실행시킬 수 있음

 

* 관련 PoC [7]

3.3 평판 씨딩 (Reputation Seeding)

- 격자가 제어하는 바이너리를 시스템에 시드하는(≒뿌리는) 것

> 신중하게 제작된 바이너리의 경우 무해한 것으로 보일 수 있으며, 추후 악용 가능

> SAC 같은 보안 시스템은 시간이 지남에 따라 파일의 신뢰도를 높이는 경향이 있으며, 이를 이용하여 악성 코드의 신뢰도를 높일 수 있음

 

* 관련 PoC [8]

3.4 평판 변조 (Reputation Tampering)

- 일반적으로 평판 시스템은 파일의 해시값을 사용하여 파일의 무결성을 보장

> 그러나 SAC는 파일의 일부분을 변경해도 평판이 유지되는 경우가 있음

> 공격자들은 파일의 일부분을 변경하여 악성 코드를 삽입할 수 있으며, 조작된 파일은 SAC의 검증을 통과할 수 있음

 

* 관련 PoC [9]

3.5 LNK Stomping

- 사용자가 파일을 다운로드하면 브라우저는 Mark of the Web (MotW)라는 데이터 스트림 생성

> SmartScreen는 웹 마크가 있는 파일만 검사하며, SAC는 특정 파일 형식이 있는 경우 이를 완전히 차단

* Mark of the Web (MotW): 파일이 인터넷에서 다운로드되었다는 것을 나타내는 것으로, 웹 마크가 있는 파일 실행 시 인터넷에서 다운로드되었으며 해로울 수 있음을 경고 [10]

 

- 비표준 대상 경로나 내부 구조를 가진 LNK 파일을 통해 우회가 가능

> 해당 LNK 파일은 explorer.exr에 의해 표준 형식으로 수정

> 이러한 수정으로 인해 보안 검사가 수행되기 전에 MotW 라벨이 제거되어 우회 가능

 

* 관련 PoC [11]

4. 탐지

- 평판 하이재킹은 특성상 탐지하기 어려움

> 남용되는 것으로 알려진 애플리케이션을 분류 및 차단하는 것은 지속적인 활동이나, 이러한 활동은 항상 공격자보다 뒤쳐짐

> 좀 더 강력한 접근 방식은 남용되는 소프트웨어의 일반적인 범주를 식별하기 위한 행동 시그니처를 개발하는 것

 

5. 결론

- 평판 기반 보호 시스템은 상용 악성 코드를 차단하는 강력한 계층

> 그러나 다른 보호 기술과 마찬가지로 우회할 수 있는 방법이 존재

> SAC, SmartScreen에는 보안 경고 없이 최소한의 사용자 상호 작용으로 초기 액세스를 허용할 수 있는 여러 근본적인 설계 약점이 존재

> 두 기능을 활성화 한다고 하더라도 추가 보안 장치들이 필요

 

6. 참고

[1] https://www.elastic.co/security-labs/dismantling-smart-app-control
[2] https://learn.microsoft.com/ko-kr/windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-smartscreen/
[3] https://blog.naver.com/ucert/222547866683
[4] https://support.microsoft.com/en-us/topic/what-is-smart-app-control-285ea03d-fa88-4d56-882e-6698afdb7003
[5] https://www.koreassl.com/support/faq/DV-OV-EV-%EB%B3%B4%EC%95%88-%EC%9D%B8%EC%A6%9D%EC%84%9C%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90%EC%9D%B4-%EB%AD%94%EA%B0%80%EC%9A%94
[6] https://ko.wikipedia.org/wiki/%EC%99%B8%EB%B6%80_%ED%95%A8%EC%88%98_%EC%9D%B8%ED%84%B0%ED%8E%98%EC%9D%B4%EC%8A%A4
[7] https://github.com/joe-desimone/rep-research/blob/ea8c70d488a03b5f931efa37302128d9e7a33ac0/rep-hijacking/poc-rep-hijack-jam.zip
[8] https://github.com/joe-desimone/rep-research/blob/ea8c70d488a03b5f931efa37302128d9e7a33ac0/rep-seeding/poc-rep-seeding.zip
[9] https://github.com/joe-desimone/rep-research/blob/ea8c70d488a03b5f931efa37302128d9e7a33ac0/rep-tampering/poc-rep-tampering.zip
[10] https://en.wikipedia.org/wiki/Mark_of_the_Web
[11] https://github.com/joe-desimone/rep-research/blob/8e22c587e727ce2e3ea1ccab973941b7dd2244fc/lnk_stomping/lnk_stomping.py
[12] https://www.boannews.com/media/view.asp?idx=131857&page=4&kind=1

1. 개요

- MMC를 활용해 보안 장치를 우회하는 새로운 공격 수법 GrimResource 등장 [1]

> MMC를 통해 MSC 파일을 열 수 있음
> 해당 MSC 파일 내 StringTable이라는 요소에 저장되어 있는 APDS 자원을 익스플로잇
> 보안 장치들을 우회하여 원하는 코드 실행 가능

 

1.1 Microsoft Management Console, MMC

- 마이크로소프트 관리 콘솔
Windows 운영 체제에서 시스템 구성 요소를 관리하고 설정하는 데 사용되는 도구
여러 관리 항목들(스냅인, 특정 시스템 구성 요소를 관리하는 작은 모듈)을 한곳에 모아 관리할 수 있도록 하는 프로그램
- Windows 환경에서 GUI와 콘솔의 생성, 저장, 열기 등을 수행할 프로그램 작업을 제공하는 일종의 응용 프로그램

 

1.2 Management Saved Console, MSC

MMC에서 만든 사용자 정의 콘솔을 저장한 파일

 

2. 주요내용

GrimResource 공격은 apds.dll 라이브러리에 있는 오래된 XXS 결함을 사용

> MSC 파일의 StringTable섹션에 취약한 APDS 리소스에 대한 참조를 추가하여 임의의 자바스크립트를 실행할 수 있음

해당 취약점은 이미 2018년 MS와 Adobe로 제보가 되었으나 아직 패치되지 않음

[사진 1] StringTable 섹션 APDS 리소스

 

ActiveX 보안 경고를 피하기위해 TransformNode 난독화 기술을 사용

> TransformNode 난독화: 소스 코드를 분석해 코드의 구조와 기능을 파악한 후 그 결과를 바탕으로 변환 규칙을 생성 및 적용하여 난독화
> 난독화된 내장 VBScript가 생성

[사진 2] TransformNode 난독화

 

- VBScript는 일련의 환경 변수에서 대상 페이로드를 설정한 뒤 DotNetToJs 기술을 활용하여 .NET 로더 실행

> DotNetToJs: Microsoft .NET 코드를 JavaScript 코드로 변환하는 프로세스

[사진 3] VBScript

 

- 로더는 VBScript가 설정한 환경 변수에서 페이로드 검색dllhost.exe의 새 인스턴스 생성하여 페이로드 주입
> 페이로드 주입에 DirtyCLR 기술, 함수 연결 해제 및 간접 syscall을 사용

[사진 4] 환경변수 설정
[사진 5] 페이로드 검색 로더

 

- 확인 권고사항
> mmc.exe에 의해 호출된 apds.dll과 관련된 파일 작업
> MCC를 통한 의심스러운 실행, 특히 .msc 파일 인수를 사용하여 mmc.exe에 의해 생성된 프로세스
> 스크립트 엔진 또는 .NET 구성 요소에서 발생하는 mmc.exe에 의한 RWX 메모리 할당
> JScript 또는 VBScript와 같은 비표준 스크립트 인터프리터 내에서 비정상적인 .NET COM 개체 생성
> APDS XSS 리디렉션의 결과로 INetCache 폴더에 생성된 임시 HTML 파일

 

- 의심스러운 MSC 파일을 탐지하는데 도움이 되도록 YARA 규칙 및 침해지표 제공

rule Windows_GrimResource_MMC {
    meta:
        author = "Elastic Security"
        reference = "https://www.elastic.co/security-labs/GrimResource"
        reference_sample = "14bcb7196143fd2b800385e9b32cfacd837007b0face71a73b546b53310258bb"
        arch_context = "x86"
        scan_context = "file, memory"
        license = "Elastic License v2"
        os = "windows"
    strings:
        $xml = "<?xml"
        $a = "MMC_ConsoleFile" 
        $b1 = "apds.dll" 
        $b2 = "res://"
        $b3 = "javascript:eval("
        $b4 = ".loadXML("
    condition:
       $xml at 0 and $a and 2 of ($b*)
}
 

X의 Samir님(@SBousseaden)

Elastic Security Labs has discovered a new method for initial access and evasion in the wild, termed #GrimResource, which involves arbitrary execution in mmc.exe through a crafted MSC file. https://t.co/q4u4gTPE6O https://t.co/usWJvhygIC

x.com

 

3. 참고

[1] https://www.elastic.co/security-labs/grimresource
[2] https://x.com/i/status/1804225219571147140
[3] https://thehackernews.com/2024/06/new-attack-technique-exploits-microsoft.html
[4] https://www.bleepingcomputer.com/news/security/new-grimresource-attack-uses-msc-files-and-windows-xss-flaw-to-breach-networks/
[5] https://www.boannews.com/media/view.asp?idx=130867&page=1&kind=1

+ Recent posts