Skip to content
KitploitKITPLOIT
도구블로그
제출
도구블로그
제출

해킹, 침투 테스트 및 사이버 보안 도구를 당신의 보안 무기고에!

Kitploit은 해킹, 사이버 보안 및 침투 테스트 도구 디렉토리입니다. 최신 프로젝트 업데이트를 발견하여 취약점을 찾고, 시스템을 분석하고, 테스트를 자동화하고, 보안을 강화하세요.

··피드·문의·개인정보·© 2026 Kitploit

도구 디렉토리

카테고리

모든 카테고리 보기
Loading categories
cve-2024-23897-jenkins-poc — CVE-2024-23897의 자체 포함 Docker 재현 및 분석, args4j @-구문 인수 확장을 통한 Jenkins CLI 임의 파일 읽기 | Kitploit
도구/GitHubGitHub/rivaedoardo62-boop/cve-2024-23897-jenkins-poc
Vulnerability AnalysisExploitationWeb SecurityPenetration TestingPapers & ResearchLearning & Education
GitHubrivaedoardo62-boop/cve-2024-23897-jenkins-poc

cve-2024-23897-jenkins-poc

CVE-2024-23897의 자체 포함 Docker 재현 및 분석, args4j @-구문 인수 확장을 통한 Jenkins CLI 임의 파일 읽기

인기

모두 보기 →

커뮤니티에서 가장 많이 사용되는 도구를 찾아보세요.

모든 도구 탐색

도구 컬렉션을 둘러보세요

모든 도구 보기 →
공유
저장소 보기
2개월 전아직 검토되지 않음

CVE-2024-23897: Jenkins 임의 파일 읽기 (args4j @-Syntax)

CVE-2024-23897의 완전한 로컬 재현으로, Jenkins CLI의 치명적인 (CVSS 3.1 기본 점수 9.8) 임의 파일 읽기 취약점입니다. 이 프로젝트는 Jenkins 마이너 버전만 다른 두 개의 Docker 스택을 실행하고, 동일한 개념 증명을 두 스택에 대해 수행하여, 패치되지 않은 컨트롤러에서 취약점이 발생하고 패치된 컨트롤러에서는 조용해지는 것을 보여줍니다.

모든 것은 단일 Python 프로그램인 poc.py에 의해 구동됩니다. 이 하네스는 환경(Docker Compose, 공식 jenkins-cli.jar 클라이언트, 출력의 그대로 캡처)만 조율합니다. 취약성 자체는 Jenkins의 자체 Java 코드에 존재하며 여기서 재구현되지 않습니다.

패치 검토 및 CVSS 분해를 포함한 전체 서면 분석은 report/report.pdf에 있습니다.

한 문단으로 설명하는 취약점

Jenkins CLI는 args4j 라이브러리를 사용하여 인수 파서를 구축합니다. args4j에는 expandAtFiles라는 기능이 있으며, atSyntax 플래그에 의해 제어되고 기본적으로 활성화되어 있습니다. 이 기능은 명령이 실행되기 전에 @/path/to/file 형식의 인수를 해당 파일의 내용으로 다시 작성합니다. 파일은 Jenkins 컨트롤러 프로세스의 권한으로 열립니다. 세 가지 CLI 전송(HTTP, WebSocket, SSH) 모두 동일한 파서를 통해 전달되므로, CLI 명령을 보낼 수 있는 모든 클라이언트는 컨트롤러에서 임의의 파일을 읽을 수 있습니다. 수정(커밋 554f0378)은 기본값이 false인 상수 ALLOW_AT_SYNTAX를 추가하여 확장을 비활성화합니다.

이것은 고전적인 경로 탐색이 아닙니다. ../도 없고, 탈출할 기본 디렉토리도 없습니다. 경로가 직접 열립니다. 결과 축에서는 임의 파일 읽기이고, 메커니즘 축에서는 인수 확장입니다.

저장소 구조

root@kitploit:~
cve-2024-23897-jenkins-poc/
  README.md                      # 이 파일
  LICENSE
  poc.py                         # Python 재현 하네스 (모든 하위 명령)
  Dockerfile.vuln                # jenkins/jenkins:2.426.2-lts + matrix-auth
  Dockerfile.fix                 # jenkins/jenkins:2.426.3-lts + matrix-auth
  docker-compose.vuln.yml        # jenkins-vuln + attacker-vuln
  docker-compose.fix.yml         # jenkins-fix  + attacker-fix
  init.groovy.d/
    01-create-users.groovy       # matrix-auth를 통해 admin + readuser 부트스트랩
  evidence/
    docker-versions.txt          # 호스트 Docker + Compose 버전
    output-vulnerable.txt        # `poc.py exploit` 중 캡처됨
    output-fixed.txt             # `poc.py verify-fix` 중 캡처됨
  report/
    report.pdf                   # 전체 서면 분석
    report.tex                   # LaTeX 소스 (자체 포함, 외부 그림 없음)

사전 요구 사항

요구 사항

호스트에 JDK가 필요하지 않습니다. Java는 공격자 컨테이너 내에서 실행됩니다. Compose 파일은 platform: linux/amd64를 고정하여 Apple Silicon에서 이미지가 동일하게 동작하도록 합니다. 이는 운영상의 선택이며, 플랫폼에 독립적인 취약점에는 영향을 미치지 않습니다.

실행 방법

저장소 내에서:

root@kitploit:~
python3 poc.py up-vuln       # 취약한 스택 빌드 및 시작, CLI jar 가져오기
python3 poc.py place-proof   # 컨트롤러 내부에 무해한 마커 파일 쓰기
python3 poc.py exploit       # PoC 실행, evidence/output-vulnerable.txt 기록
python3 poc.py up-fix        # vuln 종료, 패치된 스택 빌드 및 시작
python3 poc.py verify-fix    # 동일한 PoC 실행, evidence/output-fixed.txt 기록
python3 poc.py teardown      # 두 스택 중지 및 제거

첫 번째 실행은 몇 분 정도 소요됩니다(이미지 풀 및 플러그인 설치). 이후 실행은 훨씬 빠릅니다.

poc.py exploit은 캡처된 출력에 마커 문자열 POC-PROOF-LINE이 나타나면 통과합니다(누출 발생). poc.py verify-fix는 반대 조건에서 통과합니다. 마커가 없어야 합니다. 두 하위 명령 모두 실패 시 0이 아닌 상태로 종료되므로, 두 증거 파일과 종료 상태 자체가 테스트 결과입니다.

아키텍처

두 Compose 파일은 동일한 Docker 네트워크에서 동일한 두 서비스를 실행합니다. Jenkins 컨트롤러(피해자)와 작은 eclipse-temurin:17-jre 공격자 컨테이너입니다. poc.py는 호스트에서 실행되고 subprocess를 통해 Docker를 구동하지만, 실제 java -jar jenkins-cli.jar ... 호출은 공격자 컨테이너 내부에서 실행됩니다. 공격자는 Jenkins 데이터 볼륨에 접근할 수 없으며, 원격 공격자처럼 네트워크를 통해서만 컨트롤러에 도달합니다.

권한 부여 모델

init.groovy.d/01-create-users.groovy는 matrix-auth 플러그인을 사용하여 의도적으로 다른 권한을 가진 두 개의 계정을 생성합니다:

계정권한PoC에서의 역할

이는 Jenkins 코어 기본값이 생성했을 '로그인한 모든 사용자 대 익명'보다는 공식 권고에서의 정확한 분할(Overall/Read 대 익명)을 재현합니다. 따라서 전체 파일 누출은 관리자 권한이 아닌 CVE 단독으로 인한 것입니다.

결과

PoC는 각 컨트롤러에 대해 네 가지 컨텍스트를 실행합니다. 아래 표는 A/B 비교를 요약합니다. 전체 캡처는 evidence/에 있습니다.

두 열 사이에서 변경되는 유일한 변수는 Jenkins 마이너 버전이며, 이를 통해 패치 후 atSyntax의 기본값이 변경됩니다. 따라서 반대 결과는 동작 변경이 커밋 554f0378의 파서 수정 때문임을 나타냅니다.

Docker가 버그를 수정하지 않는 이유

컨테이너에서 Jenkins를 실행하는 것은 완화책이 아닙니다. 파서는 Jenkins JVM의 권한으로 파일을 읽으며, 해당 파일은 자격 증명 저장소를 보유한 동일한 컨테이너 파일 시스템 내에 있습니다. 컨테이너 경계는 호스트를 Jenkins 프로세스로부터 보호할 뿐, Jenkins 프로세스 자체를 보호하지 않습니다. 여기서 Docker 설정은 데모 샌드박스에 불과합니다.

완화 방법

패치된 릴리스로 업그레이드하세요: 2.442(주간), 2.426.3 또는 2.440.1(LTS). 모두 2024년 1월 24일에 게시되었습니다. 즉시 업그레이드가 불가능한 경우, 시스템 속성 hudson.cli.CLICommand.allowAtSyntax를 설정하지 않은 상태(기본값)로 두면 ALLOW_AT_SYNTAX가 false로 유지되어 확장이 비활성화됩니다. 개별 CLI 전송을 비활성화하는 것은 세 가지 모두 동일한 파서로 수렴되므로 부분적인 조치에 불과합니다.

안전 참고 사항

모든 작업은 로컬 Docker 환경에서 실행되며, 하네스가 자체 생성하는 무해한 세 줄 마커 파일(/tmp/poc-proof.txt)을 대상으로 합니다. 공용 Jenkins 인스턴스는 스캔되거나 접촉되지 않으며, secrets/master.key 또는 credentials.xml과 같은 실제 비밀은 절대 읽히지 않습니다.

참고 자료

  • Jenkins 보안 권고 2024-01-24 (SECURITY-3314, SECURITY-3315): https://www.jenkins.io/security/advisory/2024-01-24/
  • CVE-2024-23897에 대한 NVD 항목: https://nvd.nist.gov/vuln/detail/CVE-2024-23897
  • jenkinsci/jenkins의 수정 커밋 554f0378: https://github.com/jenkinsci/jenkins/commit/554f03782057c499c49bbb06575f0d28b5200edb
  • args4j (ParserProperties.withAtSyntax): https://github.com/kohsuke/args4j
  • Zscaler ThreatLabz 분석 자료 (파일 읽기에서 RCE로): https://www.zscaler.com/blogs/security-research/jenkins-arbitrary-file-leak-vulnerability-cve-2024-23897-can-lead-rce
도구 다운로드
비고
Docker Engine 24 이상사용된 정확한 버전은 evidence/docker-versions.txt에 기록되어 있습니다
Docker Compose v2내장 docker compose 플러그인으로 제공됩니다
Python 3.8 이상표준 라이브러리만 필요, pip install 불필요
디스크 공간두 개의 Jenkins 이미지, temurin 이미지 및 matrix-auth 플러그인에 대해 약 1.5 GB
admin
Jenkins.ADMINISTER
최소 한 명의 관리자를 만족시키기 위해서만 존재하며, 공격에 사용되지 않음
readuserJenkins.READ만 (Overall/Read)인증된 공격자
anonymous없음인증되지 않은 공격자
관찰취약한 2.426.2패치된 2.426.3
@-토큰 처리파일 내용으로 확장됨리터럴 문자열로 처리됨
readuser + connect-node전체 파일 공개 (3줄 중 3줄)공개 없음
anonymous + who-am-i / help인증 게이트 전 파서 오류를 통한 부분 누출 (첫 번째 줄)공개 없음
출력에서 POC-PROOF-LINE 마커존재함없음