지난해 많은 대학생들의 기말고사 기간이던 12월 초중반, 컴퓨터 관련 커뮤니티가 뜨겁게 달아올랐다. 그 원인은 바로 log4j 취약점인 것인데, 해당 사건을 적잖이 많은 곳에서 언급하며 비상조치에 들어갔기에 보안에 관심 가지고 공부하는 사람이라면, 그 사건이 정확히 무엇인지는 몰라도 그런 사건이 있었구나는 알 고 있었을 것이다.
오늘 보안뉴스의 첫 이야기는 그 'log4j 취약점'에 대해 다루고자 한다.
log4j 취약점을 설명할 수 있는 키워드로는 #Java #zeroday #RCE #minecraft #apache 가 있으며, 이 순으로 글의 흐름을 구성했다.
우선 log4j가 무엇인지에 대한 설명이 필요할 것이다.
log4j는 프로그래밍 언어 JAVA에서 매우 빈번하게 쓰이는 패키지로, 이름에서도 알 수 있듯 로그의 기록을 지원하는 오픈소스 소프트웨어 라이브러리이다. 즉, 서버에 일어나는 일을 기록할 때 사용하는 패키지인 것인데, 웬만한 서비스는 사고 발생 시 원인 파악과 복구를 위해 로그를 실시간으로 기록하기 때문에 사실상 JAVA를 사용하는 애플리케이션 및 서비스라면 log4j를 사용한다.
이렇게 광범위하고 널리 쓰이는 것인데, 이것에 사실 취약점이 있었던 것이라면?
필연적으로 log4j가 쓰이는 모든 곳이 해커에게 취약점 선물세트가 된 셈이다.
IT 강기업인 애플과 MS부터 이미 해당 취약점에 취약하다는 것이 파악되었고, 사실상 JAVA를 쓰는 모든 기업에 위협이 노출되어 발 빠르게 대규모 패치에 나섰다.
log4j는 zeroday 취약점이라고 불린다. zeroday란, 시스템의 결함이 아직 노출되지 않아 만약 해커가 해당 취약점을 발견하였을 시 관리자는 그것을 알 리가 없어 고칠 시간이 0(zero)이기 때문에 zeroday라고 불린다. 이는 당연하다. 그렇게 널리 쓰이는 패키지에 버그가 있음을 알고 있었다면 진작에 고쳤을 것이다. 그래서 반갑지 않은 zeroday의 발견은 언제나 다급한 조치가 이어지며, 이번에도 그러했다.
log4j는 또한 RCE 취약점이다. RCE란 Remote Code Execution의 약자로, 해당 취약점을 통해 원격 서버에서 마음대로 코드를 돌릴 수 있는 심각하게 치명적인 취약점이다. 원격으로 사소한 파일 한두 개 삭제부터 랜섬웨어, 시스템 전체 조종 및 마비까지 가능케하는 RCE는 버그 헌팅 계에서도 높은 점수로 평가된다.
log4j 취약점을 이야기할 때 뜬금없이 게임 '마인크래프트(Minecraft)'가 같이 언급되었다. 일부 마니아층이 두꺼운 유명한 게임으로, 필자 또한 저 게임을 가끔씩 하고 있다. 그래서 더 눈길을 끌었는데, 어떤 연유로 저런 알 사람만 알만한 게임과 사상 최악의 사태인 log4j가 나란히 불리게 된 것일까? 이는 마인크래프트 또한 JAVA를 기반으로 만들어진 게임인데, 여기서 log4j 취약점이 처음 발견되었기 때문이다. 게임의 채팅창에 프로그래밍 코드로 이루어진 특정 채팅 메시지를 입력하였더니 관련 이벤트가 발생하여 대상 컴퓨터에서 원격으로 프로그램을 실행시킬 수 있는 해킹이 가능했다.
정리하자면, 이렇게 크게 이슈가 된 데에는 제로데이였고, 원격 실행 취약점이었으며, 정말 많이 쓰이는 곳에 잠재된 취약점이었기 때문이었다.
어떤 원리로 공격이 이루어진 것인가?
log4j에는 lookups라는 기능이 있어 공격자가 서버에 요청을 보내면, log4j는 해당 요청을 로그에 기록하고 동시에 해당 url을 불러온다. 문제는 이 해당 url이 어떤 내용을 담고 있는지 전혀 파악하지 않고 무작정 불러오기 때문에 발생한다. 만약 공격자가 악의적인 url을 송부한다면 이는 크게 문제가 된다. 해당 url에 malicious code가 호스팅 되어 있어도 걸러낼 수 없기 때문이다.
Apache 기반의 JAVA 사용 애플리케이션에 원격의 자바 객체 주소를 포함시켜 취약한 서버에서 실행하면 공격 성공이다.
대응 방안은 어떤 것이 있을까?
우선 이미 발 빠르게 움직인 보안 전문가들의 패치와 버전 상승을 통해 원래 취약점에 노출된 상태더라도 손쉽게 대처할 수 있다.
네트워크로써 방어하는 방법도 있다. 객체가 담긴 문자열을 필터링한다거나, 인바운드 와 아웃바운드 정책을 설정하여 네트워크 패킷을 탐지하여 방지하는 방안을 둘 수 있다.
또한 신뢰된 코드 베이스 정책이 있을 수 있다. 백신 및 EDR(엔드 포인트 탐지) 기술을 사용하여 능동적인 탐지 및 방어도 가능할 것이다.
이번 사건은 또 다른 생각거리가 있는 사건이다.
log4j 취약점은, 버전 업데이트를 통해 금방 해결할 수 있었으나 많은 수의 서비스는 당장 손을 쓸 수 없는 상황에 처해있다.
하나의 모듈처럼 생각해서 레고 블록을 맞추듯이 끼워 넣는 프로그래밍을 했던 것이 관건인데, 그래서 그것의 최초 시작 지점이 어딘지 가늠하기 어려웠고, 서로 얽혀있는 특성상 그 하나만 고친다면 다른 기능이 연쇄적으로 망가질 수 있어 대놓고 뚫려있는 수도관을 함부로 막을 수 없었다.
이번 사건을 계기로 이러한 조각 소프트웨어 사용의 문제점을 쉬쉬하지 않고, 수면 위에 올려 적극적으로 대책을 모색할 때다.
관련해서 다룬 뉴스 기사가 있어 인용한다.
사태가 이렇게까지 퍼진 데에는 현대 기술의 발전 과정이라는 이유가 있다. 특히 마이크로서비스라든가 소프트웨어의 컴포넌트화가 이 현상을 과속화했다. 소프트웨어를 텍스트 파일로 한 줄 한 줄 써내려가는 게 아니라, 미리 만들어져 기성상품화 되다시피 한 ‘조각 소프트웨어들’을 끼워 맞추는 방식으로 만들다 보니 소프트웨어가 소프트웨어에 의존하고, 그 소프트웨어가 또 다른 소프트웨어에 의존하는 식의 ‘디펜던시의 망’이 만들어지게 된 것이다.
실제로 오픈소스 소프트웨어들을 다운로드 하는 전 세계 개발자들의 수는 2020년~2021년 사이 73% 증가했다는 연구 결과가 있다. 이미 ‘조립하는 방식’의 개발이 주류가 된 지 오래라는 뜻이다. 개발 시간을 줄이고, 오류를 줄일 수 있기 때문에 개발자들에게 선호될 수밖에 없는 방식이다. 하지만 그런 편리함에 익숙해져 갈 때 우리는 더 이상 그 끝을 알 수도, 추적할 수도 없는 소프트웨어의 디펜던시 생태계를 만들고 있었고, 로그4j와 같은 요소에서 문제가 발생했을 때 취약점을 보완할 수 없는(혹은 상당히 오랜 시간이 걸리는) 데에까지 이르렀다.
최근 구글의 오픈소스 통찰팀(Open Source Insights Team)은 조사를 통해 자바 패키지의 80%가 로그4j에서 나온 취약점의 영향을 받으며, 심지어 직접 업데이트를 할 수도 없다는 사실을 알아냈다. 아마 자바 생태계에서 로그4j의 리스크가 완전히 사라질 때까지는 수년이 족히 걸릴 것이라고 한다. 때문에 구글만이 아니라 보안 업계의 전문가들은 차라리 로그4j 사태가 더 커져서 디펜던시 관계에 있는 소프트웨어의 추적을 보다 용이하게 하는 법안이나 제도, 표준이 나오기를 고대하고 있다. 특히 ‘소프트웨어 재료 명시’ 제도가 생기기를 바라는 전문가들이 많다.
‘소프트웨어 재료 명시’ 제도(SBoM)란, 마치 시장에서 식료품의 원재료와 원산지 등을 표기한 채로 유통하는 것과 비슷한 방식으로 소프트웨어가 거래되도록 하는 것을 말한다. “어떤 디펜던시들을 내포하고 있는지 분명하고 투명하게 밝힘으로써 특정 구성 요소에서 취약점이 발견됐을 때 사용자들이 최대한 빠르고 정확하게 패치를 적용할 수 있도록 하자는 것이죠.” 보안 업체 리버싱랩스(ReversingLabs)의 수석 소프트웨어 아키텍트인 토미슬라브 페리신(Tomislav Pericin)의 설명이다.
“소프트웨어 재료를 명시하는 제도는, 현 소프트웨어 개발 및 유통 체제에서는 반드시 있어야 합니다. 취약점 소식이 나왔을 때, ‘나에게 해당이 되는가’와 ‘어디서 업데이트를 구하는가’에 대한 답을 가장 빨리 스스로 확인할 수 있는 방법이기 때문이죠. 다만 소프트웨어 재료 명시라는 게 실제 상황에서 ‘수동 작업’으로 이뤄지고, 따라서 실현하는 게 상당히 어려울 수 있다는 한계가 있긴 합니다. 소프트웨어가 얼마나 많이, 자주 바뀌는지 생각해 보면 수동 작업 문제가 반드시 해결해야 된다는 걸 알 수 있을 겁니다.”
작년 바이든 행정부는 사이버 보안 관련 행정명령을 발표하면서 소프트웨어 개발자들이 재료들을 명시해야 한다는 내용을 담은 바 있다. 물론 모든 소프트웨어가 아니라, 연방 정부 기관에 판매되는 소프트웨어에 한해서였다. 이 행정명령을 받고 미국의 정보 통신 관련 기관이 ‘재료 명시의 최소 기준’ 가이드라인을 발표하기도 했었다. 즉, 어려워 보이긴 하지만 소프트웨어의 구성 요소들을 공개한다는 것의 필요성이 널리 인정받고 있다는 것이다. “미국 정부에서 움직이기 시작했으니 가까운 미래에 볼 수 있지 않을까 합니다.”
https://m.boannews.com/html/detail.html?tab_type=1&idx=103890
편리함과 보안은 원래 같은 길을 가기 어렵다.
편하고 보장된 것을 따라 빠르게 프로그래밍하려다 보니 보안성이 약해진 대표적인 사건이 되었다.
해커와 정보 보안 전문가의 log4j 취약점을 향한 줄다리기가 이어지고 있다.
완전히 멎기까지 수 년이 걸릴 수 있는 사건이라고 한다.
기술이 고도화되고 촘촘해지는 와중에 보안 사건이 크게 발생할 때마다 복잡한 심경이다.
참고한 자료
https://m.boannews.com/html/detail.html?idx=103887
https://www.youtube.com/watch?v=kwS3twdVsko
https://selfish-developer.com/entry/log4j-%EC%9D%B4%EC%8A%88-%EC%82%B4%ED%8E%B4%EB%B3%B4%EA%B8%B0
