来源

关联漏洞

介绍

# CVE-2025-0924 분석 중 나온 다른 취약점
## 01. Stored XSS와 WordPress,WP Activity Log  개요
- ### 1) Stored XSS와 WordPress,WP Activity Log  개요
  Stored XSS는 악성 스크립트가 서버에 저장되어, 이후 다른 사용자들이 해당 페이지를 열 때 자동으로 실행되는 취약점이며 CWE-79(Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'))로 지정 되어있는 공격의 일종 입니다.  
  
  WordPress는 전 세계적으로 가장 인기 있는 오픈 소스 CMS(콘텐츠 관리 시스템)로, 웹사이트와 블로그를 쉽게 구축하고 관리할 수 있게 해줍니다. 사용자가 코드 지식 없이도 다양한 플러그인과 테마를 통해 사이트를 확장하고 커스터마이징할 수 있습니다.

  WP Activity Log는 WordPress 사이트의 관리 활동을 추적하고 기록하는 플러그인입니다. 관리자가 사이트에서 발생한 다양한 이벤트를 실시간으로 모니터링하고, 보안 감사나 문제 해결을 위한 로그를 제공하는 데 유용합니다
  
  CVE-2025-0924은 WP Activity Log 플러그인(5.2.2 이하 버전)은 'message' 파라미터에서 입력 검증 부족과 출력 이스케이프 미비로 인해 발생하며 해당 취약점이 어떻게 발생하는지 살펴보고 이에 따른 대응 방안을 모색 해보고자 합니다.
## 02. WP Activity Log 5.2.2 환경의 Stored XSS 취약점 분석
- ### 2.1 WP Activity Log 5.2.2을 이용한 Stored XSS 분석
   WordPress 에서 사용자가 사이트 제목에 악성 스크립트를 복사 붙여 넣고 해당 변경 사항이 WP Activity Log 5.2.2를 통해 로그가 설정 되면 Stored XSS 공격이 이루어 집니다. 예제를 살펴 보며 WP Activity Log를 이용해 어떻게 Stored XSS가 유발 되는지 알아 보겠습니다.
  #### 1) 로그를 통한 XSS 공격 흐름
  <p align="center"> <img src="https://github.com/user-attachments/assets/79e208a1-6d2d-4f11-9a0f-508abf178cc5" alt="이미지 설명"> </p>
  <p align="center">[그림 1] WordPress 글 작성, DB 스크립트 삽입 </p> 
  [그림 1]을 보면, 처음 로그 생성을 위해 게시글을 생성합니다. 이 과정에서 두 개의 글을 작성하는데, 하나는 직접 타이핑하여 입력하고, 다른 하나는 복사하여 붙여넣는 방식으로 입력을 진행합니다.  
  
  게시글 생성 후 데이터베이스를 확인하면, 복사하여 붙여넣은 게시글의 경우 post_title 필드의 값이 적절히 **sanitize(입력 값 정리 및 필터링)**되지 않고 저장되는 현상을 확인할 수 있습니다.
  
  이는 입력 방식에 따라 데이터가 다르게 처리될 가능성을 시사하며, XSS(크로스 사이트 스크립팅) 취약점이 발생할 수 있는 원인이 될 수 있습니다.
  <p align="center"> <img src="https://github.com/user-attachments/assets/478bec9f-51de-416b-ae71-a8bc0d414d55" alt="이미지 설명"> </p>
  <p align="center">[그림 2]  WP Activity Log 로그 생성및 공격 체크</p> 
  [그림 1]에서 생성한 게시글 내역이 WP Activity Log의 로그로 남아 데이터 베이스에서 정보를 가져와 More details... 를 요청 하는 중 [그림 2]의 스크립트 실행을 확인 할 수 있습니다. 
  <p align="center"> <img src="https://github.com/user-attachments/assets/ade3fb7a-943f-4225-a9c9-a7de9b59ba1e" alt="이미지 설명"> </p>
  <p align="center">[그림 3]  class-list-events.php - More details... return</p>
  [그림 3]에서 보다 시피 More details... 는 AjaxInspector(ajax callback function / get metadata), occurrence를 받아 결과를 출력 합니다.
  <p align="center"> <img src="https://github.com/user-attachments/assets/42746a77-a4a0-4bde-83d1-fa3a4dedcb44" alt="이미지 설명"> </p>
  <p align="center">[그림 4] AuditLog.php -> AjaxInspector() - non sanitize</p>
  <p align="center"> <img src="https://github.com/user-attachments/assets/5cd741e7-892e-4b61-8045-0260e02dfdb0" alt="이미지 설명"> 
  <p align="center">[그림 4] metadata sample</p>
  [그림 3]에서 본 [그림 4]AjaxInspector 는 [그림 5]metadata 를 통해 결과 생성 중에 변수를 santize하지 않고 return하여 발생 하여 마무리 됩니다.
## 03. 대응 방안
지금 까지 WordPress 보안 로그 플러그인인 WP Activity Log 를 통하여 Stored XSS를 알아 봤습니다. 해당의 경우는 사용자 페이지 생성 및 로그에 스크립트 내용을 올릴수만 있다면 발생 함으로
대응 방안으로 WP Activity Log 5.2.2버전 이상 -> 5.3.0 업데이트 를 제시하고자 합니다.
####  WP Activity Log / AuditLog.php -> AjaxInspector() diff
 <p align="center"> <img src="https://github.com/user-attachments/assets/fdbb3cb2-7d72-4aaf-a8c3-5183732b2b6b" alt="이미지 설명"> 
 <p align="center">[그림 5] AjaxInspector 변경 사항 / esc_html() 추가</p>

## 04. 결론 
해당 사례에서는 결과 HTML을 반환할 때 esc_html()을 사용하여 적절히 sanitize하지 않아서 발생한 문제로 보입니다. 하지만 이 분석이 CVE-2025-0924에서 설명하는 취약점과 정확히 일치하는지에 대해서는 아직 확신이 서지 않습니다.  

현재 5.3.0 버전으로 업그레이드한 후 테스트를 진행했고, 조치가 이루어진 것을 확인했으나 CVE-2025-0924에서 설명된 취약점 Stored Cross-Site Scripting via the ##message## parameter 을 통해 이루어지며 class-alert.php, class-alert-manager.php를 경로라 명시하지만  

현재 저의 분석의 경우 message parameter가 아닌 meta data에서 문제가 되며 과정 중 문제가 되는 경로의 php의 경우 class-list-events.php, AuditLog.php 임으로 nist의 설명과 일치하는 부분은 Stored Cross-Site Script빼고 전부 다릅니다. 그러하여 정확한 일치 여부는 추가로 파악이 필요합니다.
## 05. 참고자료
(nist) https://nvd.nist.gov/vuln/detail/CVE-2025-0924

  
  
  

文件快照

 [4.0K]  /data/pocs/16d4797af3d4d70306ea73643f73eb2aade3724d
└── [5.9K]  README.md

0 directories, 1 file

备注