关联漏洞
介绍
# CVE-2024-5452
## 01. Python 객체 역직렬화 와 pytorch-lightning 개요
- ### 1) Python 객체 역직렬화 와 pytorch-lightning 개요
Python 객체 역직렬화(Deserialization)는 저장되거나 전송된 직렬화된 데이터를 다시 Python 객체로 변환하는 과정이다.
PyTorch Lightning은 PyTorch 기반의 딥러닝 모델 훈련을 쉽게 관리할 수 있도록 도와주는 라이브러리 이며 DeepDiff는 두 개의 Python 객체를 비교하여 차이를 분석하는 라이브러리다.
CVE-2024-5452는 Lightning의 AI 모델 가중치 관련 웹 애플리케이션 기능에서 DeepDiff와 Lightning을 활용하는 과정에서 취약한 헤더 검증 과 델타 속성 오염을 통하여 역직렬화 시 RCE를 일으키는 취약점이다.
이로 통해 공격자가 임의의 객체를 주입하거나 원격 코드 실행(RCE)을 수행할 수 있는 취약점이 발생하는 코드 흐름을 살펴보고, 이에 대한 대응 방안을 모색 해보겠습니다.
## 02. pytorch-lightning 환경의 역직렬화 취약점 분석
- ### 2.1 DeepDiff에 Delta 오염을 이용한 공격 분석
pytorch-lightning 에서 웹 애플리케이션 엔드 포인트 중 /api/v1/delta 에 delta의 속성을 오염시켜 보내어 공격 할 수 있다.
예제를 살펴 보며 delta의 dunder속성 오염 시켜 어떻게 객체 역직렬화 취약점이 유발 되는지 알아보고자 한다.
#### 1) DeepDiff에 Delta 오염을 이용한 공격 흐름
<p align="center"> <img src="https://github.com/user-attachments/assets/35db6a38-d826-452d-9eff-cb8aa7368b67" alt="이미지 설명"> </p>
<p align="center">[그림 1] POC - Endpoint 공격 </p>
<p align="center"> <img src="https://github.com/user-attachments/assets/01a3f742-5204-480f-81d6-1b0e50bf88d5" alt="이미지 설명"> </p>
<p align="center">[그림 2] lightning/api/core/api.py / 취약한 헤더 검사 로직 파트 </p>
<p align="center"> <img src="https://github.com/user-attachments/assets/900b4576-c318-4266-a67d-1ac46e21b439" alt="이미지 설명"> </p>
<p align="center">[그림 3] POC - Vuln Injection / 전체 오염 설정 내용 </p>
<p align="center"> <img src="https://github.com/user-attachments/assets/1a5cf1b5-5757-41e9-b732-6d1b4383cbc2" alt="이미지 설명"> </p>
<p align="center">[그림 4] lightning/api/core/app.py / 설정 구간 </p>
<p align="center"> <img src="https://github.com/user-attachments/assets/5cc36e4e-34b1-42f0-920a-0b8b086d8c0c" alt="이미지 설명"> </p>
<p align="center">[그림 5] lightning/api/core/app.py / 설정 저장 구간 </p>
첫번쨰 요청은 [그림 2]의 /api/v1/delta의 header 검증을 [그림 1]를 통해 우회 후 조작한 델타 [그림 3]를 주입 시키고 [그림 4],[그림 5] 를 통하여 설정을 저장 시킨다.
그럼 이제 두번째 요청에서 이 조작 한 델타의 설정들이 어떻게 작용 하는지 살펴 보자
<p align="center"> <img src="https://github.com/user-attachments/assets/62b7cc77-f794-4c32-a534-9439d2c99479" alt="이미지 설명"> <img src="https://github.com/user-attachments/assets/d663cba9-6445-442e-974b-16428ca08877" alt="이미지 설명"> </p>
<p align="center">[그림 6] lightning/api/core/app.py / 초기 경로 흐름 </p>
[그림 6]은 델타가 설정 된 후 두번 째 요청 흐름이며 run_once() -> maybe_apply_change() -> _collect_deltas_from_ui_and_work_queues() <br>
<p align="center"> <img src="https://github.com/user-attachments/assets/9d4eb1ed-d1fc-483c-bbb5-6ca3088a8279" alt="이미지 설명"> </p>
<p align="center">[그림 7] isinstance 오염 케이스 </p>
[그림 7] _collect_deltas_from_ui_and_work_queues()에서의 isinstance 검사를 오염된 설정으로 통과(isinstance(delta, _DeltaRequest) == False)시켜 else로 동작한다.
<p align="center"> <img src="https://github.com/user-attachments/assets/bcc91236-d5bd-40e8-a042-2f3212ed1bbe" alt="이미지 설명"> </p>
<p align="center">[그림 8] isinstance 오염 케이스 1 </p>
[그림 8] 이해를 돕기 위해 isinstance(delta, _DeltaRequest), delta, _DeltaRequest(타입)의 결과를 출력 첫번째 요청은 설정을 위한 요청으로 변조를 세팅중 이여 정상이고 다음 요청은 _DeltaRequest타입이 str로 오염되어 조건을 우회 하고 있다.
흐름 상 다음 타겟인 _process_requests의 예시를 보겠습니다.
<p align="center"> <img src="https://github.com/user-attachments/assets/326f2239-4ba6-4edb-8861-2fdfd32bed45" alt="이미지 설명"> </p>
<p align="center">[그림 8] isinstance 오염 케이스 2 </p>
[그림 9] 를 보다시피 위와 동일한 내용으로 _process_requests는 오른쪽 클라이언트 POC코드의 세팅 으로 isinstance(request, _APIRequest)의 검사를 오염된 설정으로 통과 하였습니다, 해당 오염은 str을 OrderSet 인스턴스에 대해 isinstance 호출이 참을 반환 하는 케이스 입니다. 현재 까지 2가지 형태의 isinstance 오염을 봤는데 이후의 상황 또한 똑같은 형식으로 진행 됩니다.
<p align="center"> <img src="https://github.com/user-attachments/assets/4b3707b0-dabd-4dbc-bf64-9bbff35451ec" alt="이미지 설명"> </p>
<p align="center"> <img src="https://github.com/user-attachments/assets/1533e755-c555-4187-ad28-90fb1439d593" alt="이미지 설명"> </p>
<p align="center"> <img src="https://github.com/user-attachments/assets/d41d099a-38a2-4d8a-b9ca-861f99877ac2" alt="이미지 설명"> </p>
<p align="center">[그림 10] isinstance 오염 케이스 3 </p>
[그림 10] 의 isinstance는 끝나고 마지막 으로 _DeltaRequest에 설정한 값들로 결과 를 출력 하는 것으로 모든 흐름의 마무리 입니다.
<p align="center"> <img src="https://github.com/user-attachments/assets/4856390d-c229-40e7-8c7a-b445c43a114c" alt="이미지 설명"> </p>
<p align="center">[그림 11] RCE Commnad </p>
<p align="center"> <img src="https://github.com/user-attachments/assets/45be66b0-7943-423e-be96-dab4036dfdf6" alt="이미지 설명"> </p>
<p align="center"> <img src="https://github.com/user-attachments/assets/41472127-a9b4-4895-b1a1-5932cbdbb17f" alt="이미지 설명"> </p>
<p align="center">[그림 12] RCE Response </p>
[그림 12] 모든 조건이 끝나고 설정한 값들을 불러와 root 권한의 exec를 call해서 [그림 11]의 커맨드를 실행하여 마무리 한다
#### 2) DeepDiff에 Delta 오염을 이용한 공격 간략 예시(왼쪽: lightning App server, 오른쪽: Client)
<p align="center"> <img src="https://github.com/user-attachments/assets/2fddc991-5038-43c4-b03b-29002cee5baf" alt="이미지 설명"> </p>
## 03. 대응 방안
지금까지 lightning환경에서 객체 역직렬화(CVE-2024-5452)를 통한 RCE 취약점이 수행되는 흐름을 확인 해봤습니다. 서버 자체가 탈취 당하는 공격 방식이기에
대응 방안이 중요합니다. 이를 위해 최신 버전 업데이트 제시 하고자 합니다.
- ### lightning 업데이트
lightning <= 2.2.1 일 경우 lightning > 2.3.3 이상의 버전으로 업데이트 해주시기 바랍니다.
- ### lightning 라이브러리 간략 수정
해당 방안은 피치 못할 케이스에 간략하게 막는 방법임으로 참고만 하시길 바랍니다. /api/v1/delta 엔드포인트에 간략한 로직 추가(경로 /lightning/app/core/api) 혹은 상단의 세션 검사 파트 강화
- ### IPS 를 통한 탐지 및 차단
공격은 post man을 통해 json에 dunder속성을 명시하여 테스트
방어 구문 alert http any any -> any any (msg:"Detected __str__ dunert pattern"; pcre:"/(?i)(?:__\w+__)+/"; sid:1000003; ) / 간략한 dunder 속성(__build__) 탐지 정규식 적용
## 04. 결론
지금까지 Lightning과 Deepdiff 를 통한 Dunder 속성을 오염시켜 RCE를 발생 시키는 취약점을 알아 봤습니다. 해당 취약점은 첫번째로 취약한 헤더 검증, 다음으로는 취약한 delta의 속성 검사 를 통한 객체 역직렬화 에서 일어나는 취약점 이였습니다.
## 05. 참고자료
(poc) https://security.snyk.io/vuln/SNYK-PYTHON-PYTORCHLIGHTNING-7218866
(nist) https://nvd.nist.gov/vuln/detail/CVE-2024-5452
文件快照
[4.0K] /data/pocs/eb9b1e28d5915d22ce118bf0aa8d456317366805
└── [8.3K] README.md
0 directories, 1 file
备注
1. 建议优先通过来源进行访问。
2. 如果因为来源失效或无法访问，请发送邮箱到 f.jinxu#gmail.com 索取本地快照（把 # 换成 @）。
3. 神龙已为您对POC代码进行快照，为了长期维护，请考虑为本地POC付费，感谢您的支持。