.jpg)
4개월 전 발견된 로그4셸 취약점은 역사상 최악의 취약점으로 꼽힌다. 그런데도 패치의 속도는 여느 때와 다르지 않아 느리고 느리다. 아직도 9만 개 이상의 서버가 취약한 채로 인터넷에 노출되어 있다.
[보안뉴스 문가용 기자] 4개월 전 로그4j(Log4j)에서 발견된 취약점이 아직도 만연한 문제로 남아 있다. 최근 보안 업체 레질리온(Rezilion)이 최근 쇼단 검색 엔진으로 스캔을 실시한 결과 취약한 버전의 로그4j를 인터넷에 그대로 노출시키고 있는 서버가 9만 개 이상인 것으로 나타났다. 레질리온은 “이 숫자는 빙산의 일각일 뿐”이라고 보고 있다. 인터넷에 연결되지 않은 취약한 서버들도 얼마든지 존재할 것이기 때문이다.
비슷한 조사 결과를 구글도 얼마 전에 발표한 바 있다. 당시 구글은 로그4셸(Log4Shell) 취약점의 영향권 아래 있는 패키지 17,840개 중 단 7,140개 만이 업데이트 됐다고 발표했었다. 보안 업체 소나타입(onatype)은 4월 20일 메이븐 센트럴 자바(Maven Central Java) 애플리케이션 리포지터리에서 다운로드 되는 로그4j 중 36%가 로그4셸을 내포하고 있다고 했었다. 2월에 조사했을 때도 나타난 숫자는 비슷했다고 한다.
레질리온의 취약점 연구 수석인 요탐 페르칼(Yotam Perkal)은 “이는 기존의 다른 취약점 발굴 사태와도 비슷한 현상”이라고 말한다. “대대적으로 경고가 나오고 업계 전체에서 큰 우려의 목소리가 나오기까지 했는데도 4개월이 지난 시점에 패치하지 않은 시스템이 상당 수 존재한다는 거, 보안 전문가들은 익히 들어본 이야기입니다. 세상에는 패치하지 않아야 할 이유가 산적해 있습니다.”
문제의 로그4셸 취약점은 CVE-2021-44228로, 지난 해 12월 9일 아파치재단(Apache Foundation)이 처음 공개했었다. 픽스도 함께였다. 이 취약점은 사실상 거의 모든 자바 애플리케이션 환경에 존재하는 것으로 보이며, 익스플로잇도 매우 간단한 것으로 알려져 있다. 보안 전문가 대다수가 역대 최악의 취약점으로 로그4셸을 꼽고 있으며, 따라서 최대한 빨리 패치를 적용하라고 촉구했다. 다행히 실제 이 취약점과 관련된 사건은 일어나지 않고 있다.
로그4셸의 가장 큰 문제는 취약한 요소를 찾아내는 게 무척이나 어렵다는 것이다. 애플리케이션의 디펜던시 구조 내에서도 가장 깊숙한 곳에 로그4j가 있을 수 있기 때문이다. 따라서 수많은 개발자들이 자기도 모르게 로그4j를 직간접적으로 사용하고 있는 경우가 많고, 따라서 앱 사용자들도 이렇게 만들어진 애플리케이션을 아무렇지도 않게 사용하게 된다. 그래서 거의 모든 자바 환경에 이 취약점이 존재한다고 보안 전문가들은 설명하는 것이다.
“많은 기업과 기관들이 내부 네트워크를 운영하기 위해 서버들을 운영하고 있고, 이런 내부 서버들은 인터넷에 연결하지 않습니다. 다만 그런 서버들에도 로그4j가 설치되어 있는 경우가 거의 대다수이고, 그렇기에 인터넷 검색으로 찾을 수 없었을 뿐 많은 서버들이 취약한 채 사용되고 있을 겁니다. 마찬가지로 공개되지 않은 내부자 전용 애플리케이션이나 각종 IT 기술들에도 취약한 로그4j가 있을 겁니다.” 페르칼의 설명이다.
게다가 문제는 로그4j만이 아니다. 평균적으로 2020년 전에 공개된 오픈소스 취약점의 절반이 최신 버전에까지 살아남아 있다고 페르칼은 강조한다. “저희가 분석한 바에 의하면 오픈소스에서 발견된 취약점이 패치되는 데에는 100일 이상 걸립니다. 이는 취약점이 발견되고, 공개되고, 패치가 개발되고, 각종 플랫폼들을 통해 패치가 공유되는 데까지의 과정을 말합니다.”
보안 업체 로그포인트(Logpoint)의 전문 서비스 수석인 니콜라이 쏜달(Nicolai Thorndahl)의 경우, “로그4셸 취약점을 찾는 것 자체가 아직 많은 조직들에게 큰 어려움으로 남아 있다”고 설명한다. “로그4j는 수많은 애플리케이션의 로깅 기능을 담당하는 라이브러리입니다. 숨은 기능이죠. 사용자가 쉽게 눈으로 확인할 수 없다는 겁니다. 로그4j를 이용한 소프트웨어를 개발한 쪽에서도 굳이 로그4j가 사용되었다고 알리지 않고요. 즉, 아직 많은 기업들이 자기들 회사에 로그4j가 생각보다 많이 있다는 걸 깨닫지 못하고 있다는 게 지금 가장 큰 문제입니다.”
그래서 쏜달은 지금까지는 로그4j를 익스플로잇 한 공격 사례가 없었을지 몰라도 앞으로 나타날 것이라고 보고 있다. “시간이 지나면 로그4j를 통한 공격 사례가 흔한 사건이 될 것으로 보고 있습니다. 다만 그 시간이 4개월 후가 될지, 1년 후가 될지는 아직 아무도 모르죠. 그 때가서 로그4j를 다시 찾아 패치한다는 건 굉장히 자원을 많이 소모하는 일이 될 겁니다. 지금부터 미리미리 로그4j를 찾아내서 해결하는 게 중요합니다.”
3줄 요약
1. 로그4j에서 취약점 발견된 지 4개월이 지났음.
2. 그런데도 아직 인터넷 잠깐 스캔하면 수많은 취약 서버들이 발견되고 있음.
3. 내부 서버와 애플리케이션까지 생각하면 지금 발견되는 건 빙산의 일각일 듯.
[국제부 문가용 기자(globoan@boannews.com)]
[보안뉴스 문가용 기자] 4개월 전 로그4j(Log4j)에서 발견된 취약점이 아직도 만연한 문제로 남아 있다. 최근 보안 업체 레질리온(Rezilion)이 최근 쇼단 검색 엔진으로 스캔을 실시한 결과 취약한 버전의 로그4j를 인터넷에 그대로 노출시키고 있는 서버가 9만 개 이상인 것으로 나타났다. 레질리온은 “이 숫자는 빙산의 일각일 뿐”이라고 보고 있다. 인터넷에 연결되지 않은 취약한 서버들도 얼마든지 존재할 것이기 때문이다.
[이미지 = utoimage]
비슷한 조사 결과를 구글도 얼마 전에 발표한 바 있다. 당시 구글은 로그4셸(Log4Shell) 취약점의 영향권 아래 있는 패키지 17,840개 중 단 7,140개 만이 업데이트 됐다고 발표했었다. 보안 업체 소나타입(onatype)은 4월 20일 메이븐 센트럴 자바(Maven Central Java) 애플리케이션 리포지터리에서 다운로드 되는 로그4j 중 36%가 로그4셸을 내포하고 있다고 했었다. 2월에 조사했을 때도 나타난 숫자는 비슷했다고 한다.
레질리온의 취약점 연구 수석인 요탐 페르칼(Yotam Perkal)은 “이는 기존의 다른 취약점 발굴 사태와도 비슷한 현상”이라고 말한다. “대대적으로 경고가 나오고 업계 전체에서 큰 우려의 목소리가 나오기까지 했는데도 4개월이 지난 시점에 패치하지 않은 시스템이 상당 수 존재한다는 거, 보안 전문가들은 익히 들어본 이야기입니다. 세상에는 패치하지 않아야 할 이유가 산적해 있습니다.”
문제의 로그4셸 취약점은 CVE-2021-44228로, 지난 해 12월 9일 아파치재단(Apache Foundation)이 처음 공개했었다. 픽스도 함께였다. 이 취약점은 사실상 거의 모든 자바 애플리케이션 환경에 존재하는 것으로 보이며, 익스플로잇도 매우 간단한 것으로 알려져 있다. 보안 전문가 대다수가 역대 최악의 취약점으로 로그4셸을 꼽고 있으며, 따라서 최대한 빨리 패치를 적용하라고 촉구했다. 다행히 실제 이 취약점과 관련된 사건은 일어나지 않고 있다.
로그4셸의 가장 큰 문제는 취약한 요소를 찾아내는 게 무척이나 어렵다는 것이다. 애플리케이션의 디펜던시 구조 내에서도 가장 깊숙한 곳에 로그4j가 있을 수 있기 때문이다. 따라서 수많은 개발자들이 자기도 모르게 로그4j를 직간접적으로 사용하고 있는 경우가 많고, 따라서 앱 사용자들도 이렇게 만들어진 애플리케이션을 아무렇지도 않게 사용하게 된다. 그래서 거의 모든 자바 환경에 이 취약점이 존재한다고 보안 전문가들은 설명하는 것이다.
“많은 기업과 기관들이 내부 네트워크를 운영하기 위해 서버들을 운영하고 있고, 이런 내부 서버들은 인터넷에 연결하지 않습니다. 다만 그런 서버들에도 로그4j가 설치되어 있는 경우가 거의 대다수이고, 그렇기에 인터넷 검색으로 찾을 수 없었을 뿐 많은 서버들이 취약한 채 사용되고 있을 겁니다. 마찬가지로 공개되지 않은 내부자 전용 애플리케이션이나 각종 IT 기술들에도 취약한 로그4j가 있을 겁니다.” 페르칼의 설명이다.
게다가 문제는 로그4j만이 아니다. 평균적으로 2020년 전에 공개된 오픈소스 취약점의 절반이 최신 버전에까지 살아남아 있다고 페르칼은 강조한다. “저희가 분석한 바에 의하면 오픈소스에서 발견된 취약점이 패치되는 데에는 100일 이상 걸립니다. 이는 취약점이 발견되고, 공개되고, 패치가 개발되고, 각종 플랫폼들을 통해 패치가 공유되는 데까지의 과정을 말합니다.”
보안 업체 로그포인트(Logpoint)의 전문 서비스 수석인 니콜라이 쏜달(Nicolai Thorndahl)의 경우, “로그4셸 취약점을 찾는 것 자체가 아직 많은 조직들에게 큰 어려움으로 남아 있다”고 설명한다. “로그4j는 수많은 애플리케이션의 로깅 기능을 담당하는 라이브러리입니다. 숨은 기능이죠. 사용자가 쉽게 눈으로 확인할 수 없다는 겁니다. 로그4j를 이용한 소프트웨어를 개발한 쪽에서도 굳이 로그4j가 사용되었다고 알리지 않고요. 즉, 아직 많은 기업들이 자기들 회사에 로그4j가 생각보다 많이 있다는 걸 깨닫지 못하고 있다는 게 지금 가장 큰 문제입니다.”
그래서 쏜달은 지금까지는 로그4j를 익스플로잇 한 공격 사례가 없었을지 몰라도 앞으로 나타날 것이라고 보고 있다. “시간이 지나면 로그4j를 통한 공격 사례가 흔한 사건이 될 것으로 보고 있습니다. 다만 그 시간이 4개월 후가 될지, 1년 후가 될지는 아직 아무도 모르죠. 그 때가서 로그4j를 다시 찾아 패치한다는 건 굉장히 자원을 많이 소모하는 일이 될 겁니다. 지금부터 미리미리 로그4j를 찾아내서 해결하는 게 중요합니다.”
3줄 요약
1. 로그4j에서 취약점 발견된 지 4개월이 지났음.
2. 그런데도 아직 인터넷 잠깐 스캔하면 수많은 취약 서버들이 발견되고 있음.
3. 내부 서버와 애플리케이션까지 생각하면 지금 발견되는 건 빙산의 일각일 듯.
[국제부 문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-11-22] .jpg)
.jpg)
.jpg)
.jpg)
.jpg)
