꼰머의 보안공부

1. Ingress NGINX Controller

- Ingress란 클러스터 외부에서 내부로 접근하는 요청들을 어떻게 처리할지 정의해둔 규칙들의 모음 [1][2][3][4]
- Ingress Controller란 Ingress 리소스에 정의된 규칙을 읽고, 해당 규칙에 따라 트래픽을 라우팅 [1][2][3][4]
- Ingress NGINX Controller란 NGINX를 역방향 프록시 및 로드 밸런서로 사용하는 Kubernetes용 Ingress Controller [5][6]

2. 주요내용 [7]

- Ingress NGINX Controller의 구조적 설계 문제로 공격자가 악의적인 Ingress 객체를 전송하여 임의의 NGINX 설정을 주입할 수 있음

> 취약점 악용에 성공 시 클러스터 내 모든 시크릿 노출, 원격 코드 실행 등이 가능

- Admission Controller는 사용자의 요청을 변조(Mutate)와 검증(Validation)을 통해 요청의 승인 여부를 결정

> 기본적으로 인증 없이 누구나 접근 가능한 상태로 배포되어 네트워크를 통해 액세스 가능

※ 변조(Mutate) : 사용자의 요청을 사전 정의된 변형 규칙에 따라 요청을 변경

※ 검증(Validation) : 요청이 기준에 맞는지 확인하여 해당 요청을 승인 또는 거절

- Admission Controller는 Admission Webhook Endpoint를 통해 Kubernetes API 서버와 통신

> AdmissionReview 구조로 통신

> 일반 적으로 Kubernetes API 서버만 AdmissionReview 요청을 보내야 하지만, Admission Controller는 누구나 접근 가능하기 때문에 임의의 AdmissionReview 요청을 전송할 수 있음

- Ingress NGINX Controller는 AdmissionReview 요청을 처리할 때 템플릿 파일과 제공된 Ingress 객체를 기반으로 임시 NGINX 구성 파일을 생성

> 임시 파일 생성 후 nginx -t 명령을 사용해 임시 구성 파일의 유효성을 테스트

> 이때, 적절한 검증이 없어 조작된 Ingress 객체를 전송해 임의의 NGINX 구성을 삽입할 수 있음

2.1 취약점

2.1.1 CVE-2025-24514 [9]

- authreq 파서는 인증 관련 주석을 처리하는 역할을 수행

> 주석에는 URL을 포함하는 auth-url 필드를 설정해야 하며, 해당 값을 적절한 검증 없이 $externalAuth.URL에 포함

> ngnix -t 명령을 실행할 때 명령에 포함되어 실행

2.1.2 CVE-2025-24513 [10]

- 부적절한 입력 값 검증으로 Directory Traversal 공격이 가능

> 이를 통해 DoS 또는 제한된 비밀 객체 노출 발생 가능

2.1.3 CVE-2025-1097 [11]

- authtls 파서는 auth-tls-match-cn 주석을 CommonNameAnnotationValidator를 사용하여 필드 값을 검증

> auth-tls-match-cn 주석은 CN=으로 시작

> 이를 통해 임의의 코드 실행이 가능

2.1.4 CVE-2025-1098 [12]

- mirror-target과 mirror-host Ingress 주석을 사용하여 nginx에 임의의 구성을 삽입할 수 있음

> 이를 통해 임의의 코드 실행이 가능

2.1.5 CVE-2025-1974 [13]

- 특정 조건 하에서 Pod Network에 액세스할 수 있는 인증되지 않은 공격자가 임의 코드 실행이 가능

3. 대응방안

- 벤더사 제공 보안 업데이트 적용 [14][15][16][17]

- 추가 모니터링 및 필터 적용

> Admission Controller가 Kubernetes API 서버에서만 접근 가능하도록 접근 제한

> Admission Webhook Endpoint가 외부에 노출되지 않도록 설정

> Admission Controller 컴포넌트가 불필요할 경우 비활성화

> Helm을 사용하여 ingress-nginx를 설치한 경우 controller.admissionWebhooks.enabled=false로 설정하여 재설치
> 수동으로 ingress-nginx를 설치한 경우

① ValidatingWebhookConfiguration에서 ingress-nginx-admission 삭제

② ingress-ngin-controller 컨테이너의 Deployment 또는 Daemonset에서 '--validating-webhook' 인수 삭제

4. 참고

[1] https://kubernetes.io/ko/docs/concepts/services-networking/ingress/
[2] https://kubernetes.io/ko/docs/concepts/services-networking/ingress-controllers/
[3] https://somaz.tistory.com/120
[4] https://somaz.tistory.com/324
[5] https://github.com/kubernetes/ingress-nginx
[6] https://kubernetes.github.io/ingress-nginx/
[7] https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities
[8] https://velog.io/@utcloud/k8s-Admission-Controller
[9] https://github.com/kubernetes/kubernetes/issues/131006
[10] https://github.com/kubernetes/kubernetes/issues/131005
[11] https://github.com/kubernetes/kubernetes/issues/131007
[12] https://github.com/kubernetes/kubernetes/issues/131008
[13] https://github.com/kubernetes/kubernetes/issues/131009
[14] https://kubernetes.github.io/ingress-nginx/deploy/upgrade/
[15] https://github.com/kubernetes/ingress-nginx/releases/tag/controller-v1.11.5
[16] https://github.com/kubernetes/ingress-nginx/releases/tag/controller-v1.12.1
[17] https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133&pageIndex=1&nttId=71698&menuNo=205020

1. 개요

- 스마트폰을 통한 비대면 금융 서비스의 특성상, 금융 서비스를 이용하는 주체가 실제 권한을 가진 주체인지 확인하는 것이 매우 중요

- 인증 수단 자체에 대한 보안성은 확보했더라도, 인증 절차의 검증이나 절차 간의 연계에 대한 보안성 확보 등은 강구해나가야 할 과제

- 최근 이러한 인증 수단 및 절차의 허점을 이용한 금융 서비스의 명의 도용 및 인증 우회 피해 사례가 증가해 인증 서비의 보안이 더욱 중요

- 금보원은 간편 비밀번호·생체인증 등 다양한 금융 인증 체계를 해커의 관점에서 심층 분석한 ‘레드아이리스 인사이트 리포트 : Campaign Poltergeist’를 발간 [1]

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

2. 주요 내용

- 인증 수단 자체의 보안성이 강화되었더라도, 인증 절차의 설계와 구현 과정의 미흡함은 공격자에게 취약점을 노출하는 원인이 됨

2.1 인증 수단 및 절차 분석

- 서비스 이용 주체의 명의를 확인하는 데 사용되는 인증 수단의 분류

- 인증 절차 분석

> 인증 수단 자체가 가지는 안정성도 중요하나, 이를 어떻게 절차적으로 설계하고 구현하는지가 취약점을 결정짓는 핵심 요소

2.2 인증 우회 취약점 분석

- 인증 절차는 일반적으로 인증 정보 획득, 요청, 검증, 응답 및 서비스 요청 단계로 구성

> 인증 요청자는 클라이언트, 인증 검증자는 서버로써 인증 정보를 주고 받으며 전체적인 인증 절차를 수행

> 외부 기관과 연계하여 인증을 수행하는 경우, 인증 정보 획득, 검증 단계에서 클라이언트 혹은 서버가 외부 기관과 통신하여 인증 절차를 진행

2.3 Campaign Poltergeist

- 인증 우회 취약점의 연계를 통해 타 사용자의 계정 권한을 탈취, 추가 공격을 감행

> 마치 다른사람이 된 것처럼 인증 수단들을 발급하고 금융 서비스를 이용

2.4 근본 원인

① 여러 인증 수단의 복합적 사용

- 각 인증 수단 결과를 서버에 기록 및 검증하는 절차 역시 복잡해져 구현 실수 발생

- 하나의 인증 수단이 우회되거나 공격자가 임의로 발급받을 수 있다면 다른 인증 수단의 발급/등록 과정을 연쇄적으로 우회될 수 있음

② 복잡한 외부 인증 기관과의 연계

- 여러 인증 수단의 구현을 위해 금융사 자체적으로 모든 인증 서비스를 구현 및 운영할 수 없어 외부 인증 기관과 연계

- 클라이언트가 서버로 전달한 외부 인증기관 인증 결과의 정상 여부, 명의 일치 여부 등의 확인 과정이 복잡해짐

③ 인증 서비스 코드 통합 및 유지보수의 어려움

- 외부에서 개발한 코드를 통합하였기 때문에 코드에 대한 이해도가 떨어지고, 복잡한 인증 절차가 맞물려 연계 및 검증에 허점이 발생

-  또한 수정 또는 변경사항이 있을 시 유지보수를 위해 코드를 수정하는 과정에 문제가 발생 가능

2.5 대응방안

① 견고한 인증 프로세스 설계

- 여러 인증 수단의 복잡한 사용과 외부 인증기관과의 복잡한 연계로 견고한 인증 프로세스 설계가 필요

- 모든 발생 가능한 공격 유형에 대비하고, 그 결과를 서비스 최종 요청 처리 시 확인할 수 있도록 설계해야 함

- 인증 과정과 관련된 로그를 남기고 이상 행위를 탐지할 수 있도록 설계

② 인증 절차 구현 시 보안 요구사항 적용

- 인증 수단별로 발생 가능한 모든 취약점 유형을 고려하여 보안 요구사항을 적용

- 다양한 인증 서비스 코드를 통합하고 유지보수하는 과정에서도 이러한 요구사항이 적용될 수 있도록 해야 함

- 하나의 인증 수단 뿐만 아니라 전체 인증 절차를 연계하는 과정에서도 요구사항을 충족하는지 검증 및 보완

③ 인증 우회 취약점 분석 및 대응

- 불가피한 사유로 인증 우회 취약점이 남아있거나 기능 수정 등을 통해 새롭게 발생 가능

- 주기적인 취약점 분석과 모의해킹을 통해 잠재 위협을 제거

- 대목적을 두고 공격 방식의 제한없이 수행하는 모의해킹을 통해 위협을 식별

2.6 결론

- 모바일 앱을 통한 금융 서비스 이용이 보편화되면서 비대면 신원 확인의 중요성이 증가

- 하나의 인증 수단이 우회되어도, 다른 인증 수단으로 신원을 확인하여 부정 행위를 차단할 수 있도록 복합적인 인증 절차가 정확히, 제대로 구현되어야 함

3.참고

[1] https://www.fsec.or.kr/bbs/detail?menuNo=1011&bbsNo=11640
[2] https://www.dailysecu.com/news/articleView.html?idxno=164205

1. 개요

- 스타링크(Starlink)를 탑재한 스바루 차량들에서 심각한 보안 취약점 발견 [1]
- 공격에 성공하면 미국, 캐나다, 일본에 있는 모든 스바루 차량과 고객 계정에 무제한 접근이 가능
- 이메일 주소, 전화번호, 차량번호판 중 하나만 알아도 최소 네 가지 공격을 진행할 수 있음

※ 현재는 보안 패치가 적용된 상태

2. 주요 내용

- 사용자가 차량에 명령을 보낼 수 있는 MySubaru 모바일 앱을 분석
> 프록시 처리한 후 명령을 가로채고 승인 없이 차량의 잠금을 해제할 수 있는지 찾기 위함
> 그러나, 앱의 보안 상태와 인증 시스템 모두 보안이 정상적으로 작동

2.1 portal.prod.subarucs.com

- 일반적으로 자동차 제조사들은 고객용 앱보다 더 광범위한 권한을 가진 직원용 앱이 있으며, subarucs.com이 이에 해당함
- 도메인에 대한 스캔을 실행한 결과 하위 도메인 hxxps://portal.prod.subarucs.com/login.html을 발견
> 해당 도메인에는 ‘스타링크 관리자 포털’(STARLINK Admin Portal)'이라는 이름이 붙어 있었음
> 구글링 결과 STARLINK는 스바루 차량 내 인포테인먼트 시스템의 이름으로 차량의 모든 원격 제어 기능을 담당

※ 인포테인먼트 (Infotainment) : 정보(Information)와 오락(Entertainment)의 합성어로, 정보 전달에 오락성을 가미한 소프트웨어를 지칭하는 용어

2.2 /assets/_js/

- 해당 페이지의 소스를 확인해 아래 부분을 확인

> "/assets/_js/" 폴더 아래에 몇 가지 흥미로운 JavaScript 파일이 있었기 때문에, 다른 JavaScript 파일을 찾기 위해 디렉토리를 무차별 대입

2.3 login.js

- FFuF를 실행한 후 흥미로운 코드가 있는 login.js 파일을 확인
> 확인 토큰 없이 직원의 계정을 재설정할 수 있는 "ResetPassword.json" 엔드포인트가 있는 것으로 확인

2.4 /forgotPassword/resetPassword.json

- 임의의 계정 정보를 포함한 POST 요청을 전송

- 유효한 계정 정보를 사용해 테스트한 결과 비밀번호를 정상적으로 변경할 수 있었음

2.5 2FA 우회

- 변경한 계정 정보를 통해 로그인을 시도한 결과 2FA 인증이 필요

- UI에서 클라이언트 측 오버레이를 제거하는 간단한 방법으로 2FA 인증을 우회할 수 있었음

> 또한 모든 버튼이 정상적으로 작동

2.6 차량 해킹

- 지인의 차량 번호판을 통해 관리자 패널에서 접근 권한을 부여
> 계정이 성공적으로 생성되었음을 확인할 수 있는 이메일을 수신
> 생성된 계정으로 지인 차량의 잠금을 원격에서 해제할 수 있었음

3. 참고

[1] https://samcurry.net/hacking-subaru#finding-the-subaru-admin-panel
[2] https://github.com/ffuf/ffuf
[3] https://www.youtube.com/watch?v=0i8juy6RPBI
[4] https://www.boannews.com/media/view.asp?idx=135796

1. 개요

- 터널링 프로토콜의 보안 취약점이 발견돼 420만 개 이상의 인터넷에 연결된 호스트가 공격에 노출 [1][2]
> 터널링 프로토콜 : 두 네트워크 간에 데이터를 전송할 때, 데이터를 캡슐화하여 다른 네트워크 프로토콜의 데이터 패킷 안에 포함시켜 안전하고 효율적으로 전달할 수 있도록 해주는 네트워크 통신 프로토콜
- VPN 서버, 가정용 라우터, 인터넷 핵심 라우터, 모바일 네트워크 게이트웨이, 콘텐츠 전송 네트워크 노드 등 다양한 호스트가 공격에 취약
- 서비스 거부 공격부터 비인가 네트워크 접근까지 다양한 악성 활동을 가능하게 함

2. 주요내용

- IPIP/IP6IP6, GRE/GRE6, 4in6, 6in4 프로토콜에서 인증과 암호화를 지원하지 않아 외부에서 패킷을 변조 또는 악용할 수 있는 문제가 발견
> 스캐닝 (Standard tunnel, Subnet-spoofing, Spoofing, 6to4 & IPv4-mapped address, Tunneled ICMP Echo/Reply, Tunneled ICMP TTL Expired)을 통해 전체 IPv4 주소공간(37억개)과 1,000만 개의 IPv6 주소를 스캔

- 스캔 결과 약 430만 개의 취약한 호스트 중 약 190만 개의 호스트가 스푸핑이 가능한 것으로 확인

- 공격자는 터널링 헤더를 조작해 접근 제어를 우회하고 서비스 거부 공격 등의 악성 행위를 수행할 수 있음
> 외부 헤더 : 출발지 공격자 IP, 목적지 취약한 호스트 IP
> 내부 헤더 : 출발지 취약한 호스트 IP, 목적지 공격 대상 IP
> 취약한 호스트가 외부 헤더 중 출발지 IP(=공격자 IP)를 제거하고, 내부 헤더를 확인해 목적지로 전달
> 내부 헤더의 출발지 IP가 신뢰할 수 있는 호스트 IP인 경우 네트워크 필터를 우회할 수 있음 

- 4개의 CVE가 할당

- 대응방안

> 인증 및 암호화 프로토콜(IPsec, WireGuard 등)을 사용해 터널링 트래픽 보호
> 라우터와 미들박스에 트래픽 필터링 구현
> 악의적인 터널링 패킷에 대한 심층 패킷 검사(DPI)
> 암호화되지 않은 터널링 패킷 모두 차단

3. 참고

[1] https://papers.mathyvanhoef.com/usenix2025-tunnels.pdf
[2] https://www.top10vpn.com/research/tunneling-protocol-vulnerability/
[3] https://www.youtube.com/watch?v=eFZsM3khrSk&t=157s
[4] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7595
[5] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7596
[6] https://nvd.nist.gov/vuln/detail/CVE-2025-23018
[7] https://nvd.nist.gov/vuln/detail/CVE-2025-23019
[8] https://thehackernews.com/2025/01/unsecured-tunneling-protocols-expose-42.html
[9] https://www.dailysecu.com/news/articleView.html?idxno=163202

1. 개요

- 도메인 컨트롤러를 대상으로 시스템 충돌과 재부팅을 유발할 수 있는 취약점 LDAPNightmare 발견 [1]
- 서비스 거부 취약점 CVE-2024-49113과 정수 오버플로를 통한 원격 코드 실행 취약점 CVE-2024-49112
- Windows 서버를 대상으로 한 심각한 보안 위협이 되고 있어 가능한 한 빨리 '24.12 보안 업데이트 적용 필요

1.1 LDAP(Lightweight Directory Access Protocol)

- 네트워크 상에서 조직이나 개인정보 혹은 파일이나 디바이스 정보 등을 찾아보는 것을 가능하게 만든 소프트웨어 프로토콜로 389 포트 사용 [2][3]

> 디렉토리 서비스 표준인 X.500의 DAP(Directory Access Protocol)를 기반으로한 경량화(Lightweight)된 버전으로 서버-클라이언트 구조

※ 디렉토리 서비스란 이름을 기준으로 대상을 찾아 조회하거나 편집할 수 있는 서비스

2. 취약점

2.1 CVE-2024-49113

- Windows LDAP 프로토콜에서 발생하는 서비스 거부 취약점

> 공격자가 조작된 CLDAP 요청을 보내 LSASS 프로세스를 충돌시켜 서버 재부팅을 유발할 수 있음

CLDAP (Connection-less Lightweitght Directory Access Protocol)
- LDAP의 한 종류로, UDP/389포트를 사용 (LDAP는 TCP 사용)
- LDAP 대비 응답 시간이 빠르고 오버헤드가 낮으나, 데이터 손실이 발생 가능
※ UDP의 특성상 송신 IP를 확인하지 않고, 응답 패킷이 요청 패킷보다 훨씬 커 DRDoS 공격에 사용됨 (평균 50~86배 정도 증폭)

LSASS (Local Security Authority Subsystem Service)
- Windows 운영체제에서 시스템의 보안 정책을 강화를 위한 윈도우의 프로세스
> 윈도우 시스템에 로그인하려는 사용자의 유효성을 판단
> 사용자 비밀번호 저장 및 관리, 비밀번호 변경 요청 처리
> 인증된 사용자에게 시스템 자원에 접근할 수 있는 권한을 부여하는 액세스 토큰을 생성
> 시스템 보안 관련 이벤트를 기록하며, 시스템의 보안 정책을 적용 및 관리
※ 시스템의 모든 사용자 자격 증명을 저장하고 관리하기 때문에 공격자의 주요 목표 중 하나이며, Mimikatz 등의 공격 도구 존재

- 공격과정

① 공격자는 피해자 DC에 DCE/RPC 요청을 전송

- 공격자가 제어하는 LDAP 서버를 쿼리하도록 조작된 DCE/RPC 요청을 전송

> RPC 메소드 중 DsrGetDcNameEx2 메소드는 도메인 컨트롤러의 LDAP 서버 정보를 반환하기 위해 설계된 RPC 호출임

- DsrGetDcNameEx2 메소드의 매개변수 중 DomainName을 공격자가 제어하는 DNS 서버로 조작하여 요청 전송

> DomainName이 특정 도메인 또는 사이트를 가리킬 때, 자동으로 해당 도메인에 대한 LDAP DNS SRV 쿼리를 생성

> DNS는 공격자가 제어하는 LDAP 서버의 호스트 네임과 LDAP 포트 정보 응답

- DC (Domain Controller) : 로그인, 이용권한 확인, 새로운 사용자 등록, 암호 변경 등을 처리하는 기능을 하는 서버 컴퓨터
- DCE/RPC (Distributed Computing Environment/Remote Procedure Calls) : 분산 컴퓨팅 환경(DCE)에서 원격 프로시저 호출(RPC)을 구현하기 위한 프로토콜
- DNS SRV (Service Resource Record) : 특정 서비스에 대해 도메인 이름을 기반으로 연결할 수 있는 호스트 및 포트 정보를 제공하는 DNS 레코드 유형

② NBNS 요청 및 응답

- LDAP 서버의 호스트네임과 포트 정보를 수신한 피해자는 LDAP 서버에 대한 NBNS 쿼리를 수행

> 호스트네임에 대응하는 LDAP 서버의 IP 주소(공격자가 제어하는 LDAP 서버 IP) 응답

- NetBIOS (Network Basic Input/Output System) : 윈도우 네트워크에 사용되는 컴퓨터 이름 [6]
- NBNS (NetBIOS Name Service) : NetBIOS 네트워크 상에서 호스트 이름을 IP 주소로 해석하기 위해 사용되는 프로토콜 [7]

③ 조작된 CLDAP 응답으로 시스템 재부팅 유도

- 피해자 DC는 공격자의 LDAP 서버에 CLDAP 요청을 전송

> 공격자는 LDAP 참조(referral) 결과 코드와 함께 조작된 lm_referral 값을 포함한 조작된 CLDAP 응답 전송

> 조작된 lm_referral 값에 의해 범위를 벗어난 읽기와 LSASS를 충돌이 발생하고 시스템 재부팅을 유도할 수 있음

※ 관련 PoC [8]

2.2 CVE-2024-49112

- Windows LDAP 프로토콜에서 발생하는 원격 코드 실행 취약점 (CVSS: 9.8)

> CLDAP 패킷을 변조하여 LDAP 서비스에서 임의 코드를 실행할 수 있음

<<내용 추가 예정>>

3. 대응방안

- MS 12월 보안 위협에 따른 정기 보안 업데이트 적용 [10]

> 즉시 패치가 어려운 경우 권고 사항

① 악성 값이 설정된 CLDAP 참조 응답을 모니터링
② 비정상적인 DsrGetDcNameEx2 호출을 탐지
③ 도메인 컨트롤러를 대상으로 하는 의심스러운 DNS SRV 조회를 감지

4. 참고

[1] https://www.safebreach.com/blog/ldapnightmare-safebreach-labs-publishes-first-proof-of-concept-exploit-for-cve-2024-49113/
[2] https://yongho1037.tistory.com/796
[3] https://hec-ker.tistory.com/319
[4] https://nvd.nist.gov/vuln/detail/CVE-2024-49113
[5] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nrpc/fb8e1146-a045-4c31-98d1-c68507ad5620
[6] http://www.ktword.co.kr/test/view/view.php?m_temp1=319&id=452
[7] https://wiki.wireshark.org/NetBIOS/NBNS
[8] https://github.com/SafeBreach-Labs/CVE-2024-49113
[9] https://nvd.nist.gov/vuln/detail/CVE-2024-49112
[10] https://www.boho.or.kr/kr/bbs/view.do?searchCnd=1&bbsId=B0000133&searchWrd=&menuNo=205020&pageIndex=2&categoryCode=&nttId=71606
[11] https://www.dailysecu.com/news/articleView.html?idxno=162699

[12] https://www.boannews.com/media/view.asp?idx=135499&page=1&kind=1

1. 개요

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

2. 주요내용

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)

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

2.3 로그의 품질

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

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

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

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

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

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

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

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

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

2.4 로깅 우선순위

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

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

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

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

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

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

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

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

2.6 LotL 탐지

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

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

- 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]

3. 대응방안

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

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