로그4j의 취약점은 평범한 애플리케이션 문제가 아니다. 얼마나 많은 곳에서 사용되고 있는지 찾아내는 것부터 어마어마한 양의 업무가 될 지경이다. 찾아낸 후의 패치 작업이 아직 눈에 들어오지 않을 정도다.
[보안뉴스 문가용 기자] 보안 팀들이 로그4j(Log4j)에서 발견된 취약점 때문에 바쁘다. 단순 패치 적용만으로 끝나는 문제가 아니기 때문에 더 그렇다. 일단 조직 내 사용되고 있는 로그4j를 전부 찾아내는 것부터, 그 하나하나의 사용 맥락과 환경을 고려해 패치 전략을 세워 실천하는 것까지, 어려움과 도전의 연속이다. 심지어 서드파티 서비스나 제품에서까지 이를 발견해 조치를 취해야 하니 어려움은 배가 된다.
심지어 취약점이 평화로운 상태로 그냥 패치를 기다려주는 것도 아니다. 이미 공격자들은 대거 공격을 시작했고, 하루에도 수십 만 번의 스캔이 진행되고 있다. 즉 취약한 요소들을 찾는 것 외에 공격의 흔적까지도 검사해야 한다. 그야말로 보안의 이중고, 삼중고가 터진 것과 같다.
로그4j는 로깅을 위한 도구로, 거의 모든 자바 애플리케이션들에 존재한다고 볼 수 있다. 여기에서 제일 처음 발견된 제로데이 취약점은 CVE-2021-44228라는 원격 코드 실행 취약점이다. 로그4j 2.0-beta9부터 2.14.1 버전에까지 영향이 있다. 공격자들의 익스플로잇이 성공할 경우 시스템 전체를 공격자가 장악할 수 있다. 그래서 아파치 재단은 2.15.0 버전을 새로 발표했으나 여기에서는 또 디도스 취약점이 나왔다. 이에 2.16.0 버전으로의 업데이트까지 필요한 상황이다.
현재 공격자들은 매섭게 악성 행위를 쏟아 붓고 있다. 암호화폐 채굴 코드, 랜섬웨어, 원격 접근 트로이목마, 웹셸, 봇넷 멀웨어들이 이미 하루에 몇 번씩 발견되고 있다. 각 보안 업체들은 고객사의 30~80%에서 공격 시도가 있었다고 말하고 있다. 서버, 가상기계, 모바일 장비, SIEM, SaaS, 클라우드 등을 가리지 않고 각종 공격 시도가 이어지고 있다고 한다.
그래서 취약한 요소들을 최대한 빨리 찾아내야 하는데, 자바의 패킹 원리 때문에 쉽지 않다. JAR 파일의 경우, 파일 내에 모든 디펜던시들을 포함하는 경우가 종종 있는데, 당연히 로그4j 라이브러리도 포함된다. 그래서 JAR 파일 내부를 들여다 보면 로그4j를 찾아낼 수 있는데, 문제는 JAR 안에 JAR도 포함될 수 있다. 그리고 그 JAR가 또 다른 JAR를 내포할 수도 있다. 그러니 몇 번이고 JAR 안의 JAR 안의 JAR 안을 조사하지 않으면 로그4j가 나오지 않을 수 있다.
그래서 보안 업체 넷스코프(Netskope)의 수석 엔지니어인 구스타보 팔라졸로(Gustavo Palazolo)는 “취약한 로그4j를 찾아내는 것이 지금 단계에서는 가장 어려운 일일 것”이라고 말한다. “자바 애플리케이션들 자체가 온갖 장비들에 다 들어있죠. PC는 물론 IoT 장비들과 대단히 오래된 레거시 시스템들에도 있고요. 이걸 다 조사해야 하는데, 결코 간단히 끝나는 일은 아닐 겁니다.”
찾고 나서도 문제다. 패치를 하려면 경우에 따라 애플리케이션, 혹은 그 애플리케이션이 설치된 장비나 네트워크 전체를 잠시 중단시켜야 하는데, 이것이 사업상 큰 문제를 야기할 수 있기 때문이다. 24시간 가동되어야 하는 웹사이트를 1시간 정도 다운시켜야 하는 걸 쉽게 승인할 관리자들은 거의 없다. “심지어 1시간으로 안 끝나는 경우도 다수일 것입니다.” 팔라졸로의 설명이다.
API도 이번 사태로 드러난 위험 요소 중 하나다. 보안 업체 노네임시큐리티(Noname Security)의 부회장 아네르 모락(Aner Morag)은 “로그4j로 인한 리스크를 최소화 하려면 해야 할 일이 몇 가지 있다”고 말한다. “가장 먼저는 API와 자바 서비스를 제공하는 모든 서버들을 매핑해야 합니다. 그리고 API 서버의 로그 메시지에 아무도 접근하지 못하게 막아야 하고요. 그 외 어떤 서버에 어떤 백엔드 서비스가 연결되는지를 파악하고 이를 제어하기도 해야 합니다. API를 API 게이트웨이나 로드 밸런서 뒤에 배치시키는 것도 중요합니다.”
보안 업체 알러트 로직(Alert Logic)의 부회장 톰 고럽(Tom Gorup)은 “서드파티 서비스와 제품도 골칫거리가 될 것”이라 말한다. “서드파티 업체들이 전부 로그4j를 찾아내 적절히 패치할 거라고 기대할 수는 없습니다. 분명히 보안 담당자가 스스로 나서야만 하는 시기가 있을 겁니다. 그럴 때는 스스로 서드파티 업체의 웹사이트에 접속해 직접 문의하는 것을 추천합니다. 담당자를 안다면 직접 전화를 해도 되고요. 그런 식으로 고객의 푸시를 받으면 무시할 수 없는 게 서드파티들의 입장이거든요.”
3줄 요약
1. 로그4j, 기업 내 모든 요소와 서드파티 제품, API에서 찾아내는 게 관건.
2. 찾아낸 후라도 다운타임 때문에 패치가 어려울 수 있어서 문제.
3. 서드파티가 걱정된다면 파트너사나 고객사로서 서비스 제공자에 직접 문의하는 것도 나쁘지지 않은 방법.
[국제부 문가용 기자(globoan@boannews.com)]
[보안뉴스 문가용 기자] 보안 팀들이 로그4j(Log4j)에서 발견된 취약점 때문에 바쁘다. 단순 패치 적용만으로 끝나는 문제가 아니기 때문에 더 그렇다. 일단 조직 내 사용되고 있는 로그4j를 전부 찾아내는 것부터, 그 하나하나의 사용 맥락과 환경을 고려해 패치 전략을 세워 실천하는 것까지, 어려움과 도전의 연속이다. 심지어 서드파티 서비스나 제품에서까지 이를 발견해 조치를 취해야 하니 어려움은 배가 된다.
[이미지 = utoimage]
심지어 취약점이 평화로운 상태로 그냥 패치를 기다려주는 것도 아니다. 이미 공격자들은 대거 공격을 시작했고, 하루에도 수십 만 번의 스캔이 진행되고 있다. 즉 취약한 요소들을 찾는 것 외에 공격의 흔적까지도 검사해야 한다. 그야말로 보안의 이중고, 삼중고가 터진 것과 같다.
로그4j는 로깅을 위한 도구로, 거의 모든 자바 애플리케이션들에 존재한다고 볼 수 있다. 여기에서 제일 처음 발견된 제로데이 취약점은 CVE-2021-44228라는 원격 코드 실행 취약점이다. 로그4j 2.0-beta9부터 2.14.1 버전에까지 영향이 있다. 공격자들의 익스플로잇이 성공할 경우 시스템 전체를 공격자가 장악할 수 있다. 그래서 아파치 재단은 2.15.0 버전을 새로 발표했으나 여기에서는 또 디도스 취약점이 나왔다. 이에 2.16.0 버전으로의 업데이트까지 필요한 상황이다.
현재 공격자들은 매섭게 악성 행위를 쏟아 붓고 있다. 암호화폐 채굴 코드, 랜섬웨어, 원격 접근 트로이목마, 웹셸, 봇넷 멀웨어들이 이미 하루에 몇 번씩 발견되고 있다. 각 보안 업체들은 고객사의 30~80%에서 공격 시도가 있었다고 말하고 있다. 서버, 가상기계, 모바일 장비, SIEM, SaaS, 클라우드 등을 가리지 않고 각종 공격 시도가 이어지고 있다고 한다.
그래서 취약한 요소들을 최대한 빨리 찾아내야 하는데, 자바의 패킹 원리 때문에 쉽지 않다. JAR 파일의 경우, 파일 내에 모든 디펜던시들을 포함하는 경우가 종종 있는데, 당연히 로그4j 라이브러리도 포함된다. 그래서 JAR 파일 내부를 들여다 보면 로그4j를 찾아낼 수 있는데, 문제는 JAR 안에 JAR도 포함될 수 있다. 그리고 그 JAR가 또 다른 JAR를 내포할 수도 있다. 그러니 몇 번이고 JAR 안의 JAR 안의 JAR 안을 조사하지 않으면 로그4j가 나오지 않을 수 있다.
그래서 보안 업체 넷스코프(Netskope)의 수석 엔지니어인 구스타보 팔라졸로(Gustavo Palazolo)는 “취약한 로그4j를 찾아내는 것이 지금 단계에서는 가장 어려운 일일 것”이라고 말한다. “자바 애플리케이션들 자체가 온갖 장비들에 다 들어있죠. PC는 물론 IoT 장비들과 대단히 오래된 레거시 시스템들에도 있고요. 이걸 다 조사해야 하는데, 결코 간단히 끝나는 일은 아닐 겁니다.”
찾고 나서도 문제다. 패치를 하려면 경우에 따라 애플리케이션, 혹은 그 애플리케이션이 설치된 장비나 네트워크 전체를 잠시 중단시켜야 하는데, 이것이 사업상 큰 문제를 야기할 수 있기 때문이다. 24시간 가동되어야 하는 웹사이트를 1시간 정도 다운시켜야 하는 걸 쉽게 승인할 관리자들은 거의 없다. “심지어 1시간으로 안 끝나는 경우도 다수일 것입니다.” 팔라졸로의 설명이다.
API도 이번 사태로 드러난 위험 요소 중 하나다. 보안 업체 노네임시큐리티(Noname Security)의 부회장 아네르 모락(Aner Morag)은 “로그4j로 인한 리스크를 최소화 하려면 해야 할 일이 몇 가지 있다”고 말한다. “가장 먼저는 API와 자바 서비스를 제공하는 모든 서버들을 매핑해야 합니다. 그리고 API 서버의 로그 메시지에 아무도 접근하지 못하게 막아야 하고요. 그 외 어떤 서버에 어떤 백엔드 서비스가 연결되는지를 파악하고 이를 제어하기도 해야 합니다. API를 API 게이트웨이나 로드 밸런서 뒤에 배치시키는 것도 중요합니다.”
보안 업체 알러트 로직(Alert Logic)의 부회장 톰 고럽(Tom Gorup)은 “서드파티 서비스와 제품도 골칫거리가 될 것”이라 말한다. “서드파티 업체들이 전부 로그4j를 찾아내 적절히 패치할 거라고 기대할 수는 없습니다. 분명히 보안 담당자가 스스로 나서야만 하는 시기가 있을 겁니다. 그럴 때는 스스로 서드파티 업체의 웹사이트에 접속해 직접 문의하는 것을 추천합니다. 담당자를 안다면 직접 전화를 해도 되고요. 그런 식으로 고객의 푸시를 받으면 무시할 수 없는 게 서드파티들의 입장이거든요.”
3줄 요약
1. 로그4j, 기업 내 모든 요소와 서드파티 제품, API에서 찾아내는 게 관건.
2. 찾아낸 후라도 다운타임 때문에 패치가 어려울 수 있어서 문제.
3. 서드파티가 걱정된다면 파트너사나 고객사로서 서비스 제공자에 직접 문의하는 것도 나쁘지지 않은 방법.
[국제부 문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-04-24] 
.jpg)
