- 미국(CISA, NSA, FBI), 호주(ACSC), 캐나다(CCCS), 뉴질랜드(NCSC-NZ)가 협동해 통신 인프라 관련 보안 가이드라인 발표 [1] - 사이버 위협 행위자, 특히 중국과 관련된 위협에 대응하기 위한 권고사항
2. 주요내용
구분
설명
모니터링
- 지속적인 스위치, 라우터, 방화벽 등 네트워크 장치의 구성 변경 모니터링 및 비정상적 변경에 대해 경고하는 메커니즘 구축 - 네트워크 흐름 모니터링 솔루션 구현 및 가시성 확보 - 관리 트래픽 노출 최소화 및 전용 관리 워크스테이션에서만 접근 허용 - 사용자 및 서비스 계정 로그인을 모니터링하여 비정상적인 로그인 시도 탐지 및 비활성화 - 중앙 집중화된 로그 관리 및 분석으로 신속한 의심스러운 활동 식별 등
강화 시스템 및 장치
- 프로토콜 및 관리 프로세스 개선 > 대역 외 관리 네트워크 사용 > 기본 거부 ACL 정책 구현 > 강력한 네트워크 세분화 > VPN 게이트웨이에 강력한 암호화 프로토콜 적용 > AAA(Authentication_인증, Authorization_권한부여, Accounting_계정관리) 로깅이 CIA 기능을 갖춘 중앙 로깅 서버로 전송되도록 보장 > 불필요한 프로토콜 비활성화 > 기본 비밀번호 사용 지양 > 신뢰할 수 있는 무결성 검증 도구 활용 등
Cisco 특정 지침
- 사이버 위협 행위자들은 Cisco 장비의 특정 기능을 표적으로 공격하므로 조치 필요 > Cisco Smart Install 서비스 비활성화 > Guestshell 액세스 비활성화 > 암호화되지 않은 웹 관리 기능 비활성화 > Telnet을 비활성화 > 비밀번호 관리 강화
- 세계 여러 정보 보안 관련 기관이 협력하여 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 환경
① 비정상적인 혹은 예상하기 힘든 도구의 활용 ② 벤더나 서드파티의 갑작스러운 접근 ③ 유지보수나 원격 모니터링을 위한 도구의 비정상적인 사용 ④ 운영 체제, 소프트웨어, 펌웨어, 환경, 데이터베이스 등의 무단 변경 및 무단 업데이트 ⑤ 제어 시스템과 외부 네트워크 간의 비정상적인 통신 ⑥ 평소에 통신 활동이 없던 구성 요소 간에 발생하는 통신 ⑦ 비정상적인 스크립트 실행
- 컨테이너 런타임 라이브러리와 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
- 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 공격 과정
① 공격자는 악성 이미지를 제작해 유포한 후 대상 플랫폼에서 악성 이미지 실행 > 공급망 또는 사회공학적기법을 사용해 이미지 실행을 유도 ② CVE-2024-0132를 악용해 호스트 파일 시스템에 엑세스 ③ Container Runtime Socket을 이용해 호스트 시스템에서 임의의 명령 실행 > docker.sock 및 containerd.sock 악용: root 권한으로 호스트 시스템에서 컨테이너로 임의의 명령을 실행할 수 있음
2.2 CVE-2024-0133
- 컨테이너 이미지가 호스트 파일 시스템에 빈 파일을 생성할 수 있는 취약점
영향받는 버전: NVIDIA Container Toolkitv 1.16.1 이하 버전
※ 두 취약점 모두 CDI (Container Device Interface)가 사용되는 경우 영향받지 않음 > CDI (Container Device Interface): 컨테이너 런타임에서 NVIDIA GPU와 같은 복잡한 디바이스에 대한 액세스를 표준화 [7]
- 해외 연구팀이 기아 차량의 번호판만으로 차량에 명령을 내릴 수 있는 취약점 발견 [1] - 모든 기아 차량에 영향 받으며, 기아 Connect 구독 여부와 관계없이 차량 하드웨어가 장착된 경우 공격 가능 - 공격자는 개인정보(차량 소유주 이름, 전화번호, 이메일, 실주소 등)뿐만아니라 차량의 제어권을 획득할 수 있음
2. 주요 내용
- 연구진은 웹사이트 owners.kia[.]com와 Kia Connect iOS 앱 com.myuvo[.]link 분석 > 두 애플리케이션은 인터넷을 통해 차량 제어 명령을 보낼 수 있음
※ 웹 사이트는 백엔드 역방향 프록시를 사용해 사용자 명령을 실제 차량 명령을 실행하는 api.owners.kia.com 백엔드 서비스로 전달 ※ 앱은 해당 API에 직접 액세스
- owners.kia[.]com 웹사이트에서 차량 문 잠금 해제를 위한 HTTP 요청
- 서버는 JSESSIONID를 사용해 Sid 세션 ID 생성 및 백엔드 API에 요청 전달
> Sid는 세션 토큰, Vinkey는 차대번호(VIN_차량 식별에 사용되는 고유한 일련 번호)와 매핑되는 UUID
2.1 Kia 딜러 인프라 취약점
- 연구진은 Kia에서 새 차를 구매할때, 차량 등록을 위해 고객에게 보내는 이메일에서 URL을 발견
> VIN 파라미터는 딜러가 생성한 일회성 토큰으로, 파라미터로 지정된 차량을 수정할 수 있음
- 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초 사이에 빼낼 수 있음을 입증
- 공격 범위는 전송 속도에 따라 달라짐 > 고속 전송의 경우 최대 3미터 범위에서, 느린 속도로 전송할 경우 7미터까지 범위가 확장 > 속도가 빠를수록 오류율이 증가
2.4 대응
- RAMBO 공격은 기존 보안 방어책으로는 탐지 및 차단이 어려움 > 네트워크 트래픽이나 파일 변조가 아닌 RAM에서 발생하는 전자기 신호를 악용하기 때문에 다음과 같은 대책 제안
- 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로 제보가 되었으나 아직 패치되지 않음
- ActiveX 보안 경고를 피하기위해 TransformNode 난독화 기술을 사용
> TransformNode 난독화: 소스 코드를 분석해 코드의 구조와 기능을 파악한 후 그 결과를 바탕으로 변환 규칙을 생성 및 적용하여 난독화 > 난독화된 내장 VBScript가 생성
- VBScript는 일련의 환경 변수에서 대상 페이로드를 설정한 뒤 DotNetToJs 기술을 활용하여 .NET 로더 실행
> DotNetToJs: Microsoft .NET 코드를 JavaScript 코드로 변환하는 프로세스
- 로더는 VBScript가 설정한 환경 변수에서 페이로드 검색 및 dllhost.exe의 새 인스턴스 생성하여 페이로드 주입 > 페이로드 주입에 DirtyCLR 기술, 함수 연결 해제 및 간접 syscall을 사용
- 확인 권고사항 > mmc.exe에 의해 호출된 apds.dll과 관련된 파일 작업 > MCC를 통한 의심스러운 실행, 특히 .msc 파일 인수를 사용하여 mmc.exe에 의해 생성된 프로세스 > 스크립트 엔진 또는 .NET 구성 요소에서 발생하는 mmc.exe에 의한 RWX 메모리 할당 > JScript 또는 VBScript와 같은 비표준 스크립트 인터프리터 내에서 비정상적인 .NET COM 개체 생성 > APDS XSS 리디렉션의 결과로 INetCache 폴더에 생성된 임시 HTML 파일