티스토리 뷰

오늘 전산, IT, 보안에 관련된 최악의 보안 사태. 인터넷 역사 중에 최악의 보안 결함 사건에 대해서 알아보자. LOG4J 사태, 로그4J 보안취약점으로 애플, 텐센트, 아마존, 테슬라, 클라우드플레어, 스팀, 마인크래프트, 구글, 링크드인, 깃허브 등 수많은 기업들이 해당 보안 관련 취약점에 노출이 되었다. 거의 전 세계 모든 기업과 관련된 전산 시스템들이 취약점에 노출이 되어버린 매우 역사적인 대형 사건이어서 최대한 빨리 보안 패치를 하려는 기업과 해킹하려는 세력 간의 경쟁이 치열해지고 있다.

 

JAVA-자바-LOG4J-로그-워크프레임-개발패키지-프로그램-설명사진
LOG4J 보안 취약점 사태에 대한 참고 사진 _출처 : nomad coders

 

 

애플도 당한 최악의 보안사태 Log4J

 

전 세계 서버 시스템을 뚫은 Log4j 공포로 IT업계, SW 보안 경쟁이 불 붙었다. CVSS(Common Vulnerabilities Scoring Sytem) 혹은 취약점 등급 시스템은 현재 최고 10등급의 단계에서 10단계 등급(10 Critical)인 상태이다. 현재의 상황이 엄중하고, 심각함을 경고하고 있다.

 

 

인터넷 탄생 이후 역사상
최악의 보안사태
Log4J = Log4Shell

 

 

캐나다 정부는 4천여 개 의정부 웹사이트를 해킹 사고 예방을 위해 폐쇄했고, 미국 국토안보부도 피해를 줄이기 위해 백방의 노력 중이다. 인터넷 즉 가상의 세계는 모두 난리가 났다고 보면 된다. 인터넷 역사상 최악의 보안사태이다.

 

Log4j 사태를 아무도 인지하지 못했고, 이런 상황의 파급력을 아무도 몰랐다고 전해진다. 즉 이 보안 취약점으로 누가 이미 해킹을 당했는 것도 확인을 못하고 있는 상태이다. 이 사태를 "Log4J Vulnerabiliy = Log4J 취약점", "Log4Shell"이라고 한다.

 

Log4Shell은 제로데이 RCE 취약점이다. 여기서 제로데이 취약점이라는 것은 시스템의 결함인데, 오직 해커만 알고 있는 경우이다. 이 제로데이 취약점이 발견되면 해당 시스템의 관리자는 이것을 고칠 시간이 말 그대로 "0일(제로데이)"라는 뜻이다. 해당 취약점이 이미 노출되어 해킹에 사용되고 있어서이다. 제로데이란 즉 번개처럼 고쳐야 한다는 뜻이다.

 

Log4Shell-보안취약점-알리바바-보안팀이-첫발견됨
Log4Shell은 알리바바 보안팀에 의해서 첫 발견됨

 

Log4Shell은 알리바바 보안팀에 의해서 2021년 12월 9일에 처음 발견이 되었다. 그러나 클라우드플레어에 따르면 해당 취약점은 이미 2021년 12월 1일부터 해킹에 사용되고 있었다. 즉 이 취약점은 이미 12월 9일 전부터 사용되었고, 이 사태를 아무도 몰랐다는 것이다. 끔찍한 상황이다. 기업 전산담당 및 보안담당은 피가 거꾸로 돌고, 머리가 멍한 상황인 것이다.

 

Log4Shell은 제로데이 'RCE' 취약점이다. 여기서 RCE는 Remote Code Execution 원격 코드 실행의 약자이다. 즉 해커가 원격코드를 실행해서 기업의 서버, 개인의 서버 시스템을 마음대로 제어를 할 수 있다는 것이다.

 

최근 랜섬웨어로 큰 일을 겪은 기업들의 사례를 보듯이 강도 같은 해커가 당신 회사 전산시스템 서버에 몰래 들어와서 서버를 악의적으로 제어를 한다. 몇십 년 모은 기업 데이터를 지워버릴 수도 있고, 몽땅 다운로드해서 하여갈 수도 있고, 비밀번호를 바꾸어서 암호화해버려서 돈을 달라고 협박을 한다.

 

제일 무서운 점은 Log4Shell 취약점의 범위가 너무너무 넓다는 것이다. 대기업 및 글로벌 기업은 이미 이 취약점에 모두 노출이 되었다. 문제의 범위가 이렇게 크고 넓은 이유는 패키지 'Log4J' 때문이다. Log4J는 Java가 쓰이는 곳에서는 그냥 범용적으로 사용되는 패키지이다.

 

Java는 전 세계적으로 엄청 쓰고 있는 프로그래밍 언어이다. 2015년 오라클에 따르면 Java는 130억 개 기기에서 구동 중이라고 전한다. 이런 Java 프로그래밍 언어에 아주 유명한 패키지에 결함이 생겼는데 이 결함으로 해커들은 원격 코드 조종이 가능해졌다.

 

왜 Log4j는 범용적으로 널리 사용되고 있는 것일까? 모든 기업들은 흔적=로그(Log)를 기록하는 것을 의무적이라고 보고, 기록하는 것을 즐긴다. 서버 시스템에 발생되는 모든 과정과 결과를 기록을 한다. 예를 들어 1명의 접속자가 홈페이지로 이동하거나 로그인하거나 댓글을 달거나 이런 사소한 개인의 활동까지 모두 기록을 한다.

 

 

GET/login-2021-12-20-20:00-Browser:Chrome-OS:Windows11

 

 

로그(Log) 파일은 이러한 수백 개, 수천 개의 혹은 그 이상의 기록들이다. 위의 예시는 윈도우 11 운영체제에서 크롬 웹브라우저를 쓰는 개인이 2021년 12월 20일 20시에 로그인 페이지에 접속했다는 로그(Log)이다. 이런 로그 기록을 Log4j 프레임워크가 로그를 포맷팅 하고, 필터링하고, 프로그램 혹은 애플리케이션의 파일로 기록하는 작업을 한다. 인터넷에 연결된 모든 프로그램은 로그를 의무적으로 기록한다.

 

여기에서 Java를 쓰는 애플리케이션이라면 Log4j를 무조건 사용한다. 이처럼 아주 간단한 작업만 수행했던 Log4j가 역사상 가장 끔찍한 취약점의 원인이 되었나?

 

Log4j는 'Lookups'라는 기능이 있다. 약간의 일반 유저의 시스템에 코드 입력을 신뢰하기도 한다. 해커가 서버 시스템에 요청에 String(문자열)이 있으면 Log4j는 이것을 로그에 넣음과 동시에 해당 URL를 불러온다. 여기에서 해당 URL에서 JNDI(자바 네이밍 디렉터리 인터페이스)라는 Lookup를 사용하는데 문제는 해커로 공격받는 서버는 URL만 부르는 것이 아니라 해당 URL에 호스팅 되어있는 코드가 공격받는 서버에 실행이 될 수도 있다.

 

Fastly에 따르면 엄청난 규모의 스캔이 이루어지고 있다고 한다. 해커들이 어떤 웹사이트의 서버들이 취약한지 열심히 찾고 있다는 뜻이다. 이미 웜(Worm)을 연구하는 해커 그룹도 있다고 한다. 24시간 48시간 이내에 만들어서 해당 취약점을 파고 들어가서 활동을 해볼 것이라고 트위터에 공지하기도 한다.

 

이 문제가 핫이슈가 되어버린 시점부터 많은 기업들이 서비스를 패치하고 업데이트하고 있다. 말은 쉽다. 하지만 이 작업은 쉽지 않다. 원하는 만큼 빠르게 업데이트하지 못하고, 심지어 본인의 시스템에 Log4j가 있는지도 모르는 곳도 있다. 빠르게 업데이트를 준비하였더라도 시스템 패치를 하려면 잠시라도 몇 시간이라도 시스템을 잠시 중단해야 하는 상황도 발생한다.

 

오늘 거래하는 IT 기업의 책임자와 전화를 하니 며칠째 집에 못 들어가고 있다고 한다.

 

현재 한국 기업을 대상으로 취약점 업데이트를 독려를 하고 있는 과학기술정보통신부는 12월 16일 주요 기업 정보보호 최고책임자(CISO) 긴급 간담회를 열어 방어 전략을 논의했다. 한국 정부가 이렇게 급히 움직이는 이유도 Log4j의 범용성 문제가 크다. 과기정통부가 12월 12일 정보통신, 금융, 의료 등 주요 기반 시설 147개를 점검했더니 30곳에서 Log4j를 사용한 것으로 나타났다. 일반인들은 모르겠지만 지금 IT업체, 개발자들은 난리가 났다.

 

 


참고 유튜브 영상 : nomad coders

https://youtu.be/kwS3twdVsko

 

글 참고 기사 : 한국경제 "전세계 서버 뚫은 'Log4j' 공포 IT업계, SW 보안경쟁 불붙었다"

https://www.hankyung.com/it/article/2021122094851