로그4셸 사태가 끔찍한 건, 취약한 요소들을 하나하나 찾아낼 기술을 우리가 가지고 있지 않다는 것이다. 그래서 대응에 시간이 걸리고 있고, 앞으로도 수개월 걸릴 예정이다. 또 다른 로그4셸 사건이 터졌을 때도 대응의 시간이 걸리게 된다면, 우리는 지금 헛수고를 하고 있는 것인지도 모르겠다.
[보안뉴스 문가용 기자] 꿈같은 연말연시여, 안녕. CVE-2021-44228(로그4셸)이라는 역대 최악의 취약점 때문에 보안 업계는 곧바로 ‘연중 모드’로 돌입했다. 뭐가 이 취약점을 이리도 특별하고 지독하게 만드는 것일까? 얼마나 큰 재앙이 우리에게 예정되어 있는 것이며, 우리는 이걸 지켜보고만 있어야 하는 걸까? 어떻게 해야 최악의 상황은 면할 수 있을까?
필자는 이 지면을 통해 로그4셸에 대해 썰을 좀 풀어보고자 한다. 하지만 기술적인 설명을 하려는 건 아니다. 이미 필자가 아니어도 수많은 전문가들이 했고, 앞으로도 할 것이다. 로그4셸의 기술적 보고서가 하나 더 나오는 게 그리 큰 의미를 갖지는 않는다고 본다. 다만 왜 이 취약점을 가지고 이리들 호들갑을 떠는지를 산업 종사자의 시선으로 보고 싶다.
퍼펙트 스톰
로그4셸이라는 취약점은 그 자체로 좋지 않은 특성을 가지고 있다. 심지어 익스플로잇 행위가 매우 간단한 편에 속한다. 데이터와 관련된 취약점이기 때문에 인터넷에 연결된 시스템이 아니라 데이터와 연결된 시스템들이 공격에 노출된다. 클라우드 깊숙한 곳 어딘가에 로그4셸이 도사리고 있을 수도 있다. 아직 로그4셸 익스플로잇이 안 나와서 망정이지, 누군가 이걸 개발하는 순간 데이터라는 게 존재하는 사이버 공간 모든 곳에서 폭발적인 사고들이 터져나갈 가능성이 높다.
‘폭발적인 사고’ 혹은 ‘퍼펙스 스톰’이라고 말하게 되는 이유는 다음과 같다.
1) 로그4셸 취약점이 발견된 소프트웨어인 로그4j(Log4j)는 아주 조금의 과장을 섞어서 표현하자면 세상 어느 곳에나 있다. 심지어 접근하는 데에 권한을 필요로 하는 것도 아니다.
2) 자바가 조금이라도 사용되는 환경에서라면 이제 100% 안전을 보장할 수 없다. 모든 로그4j 인스턴스들을 패치하면 되긴 하는데, 이 로그4j라는 게 세상 모든 곳에 다 사용되기 때문에 다 찾아낼 수가 없다.
3) 공격자는 피해자를 꼬드겨 로그에 뭔가를 쓰도록 만들기만 하면 된다. 이를 위해 해커들 사이에서 여태까지 고안된 방법은 무수하게 많다. 간단한 것도 많고 제법 복잡하지만 효과가 확실한 것도 많다.
4) 검사를 시작한 시기와 결과가 나오는 시기 간에 유의미한 차이가 생길 수 있다. 이럴 때 탐지 결과가가 올바르지 않을 수도 있고, 취약한 시스템이 튼튼하다는 진단을 받을 수 있다.
아군의 포격과 잘못된 ‘보안 자신감’
로그4셸 취약점 자체로도 버거운데, 보안 전문가들 사이에서 서로를 해롭게 하는 행위들이 나타나기도 했다. 예를 들어 서드파티가 로그4j와 관련하여 새로운 규칙을 추가한다고 치자. 물론 이런 대처는 대단히 긍정적이다. 하지만 이 때문에 외부 스캔 결과를 믿기 힘들어진다. 공격자들의 공격 행위가 어려워진 만큼 보안 전문가들의 검사도 힘들어지는 것이다. 위험한 상태에 놓여 있는 것을 위험한 줄도 모르고 그냥 지나치게 될 가능성이 높아진다.
예를 들어 우리 프레토리안(Praetorian)에서는 주말 동안 스캐너를 하나 만들었다. 우리 고객들의 웹사이트들을 돌아다니며 취약점을 찾아내는 기능을 가진 스캐너였다. 하지만 고객사 측에서 여러 가지 설정 변경과 규칙 추가 등을 하는 바람에 스캔이 제대로 이뤄지지 않았다. 물론 한 사이트 한 사이트 추가 맞춤형 스캔을 실시하면 되는데, 그렇게 하나하나 공들여 검사하려는 게 스캐너 제작의 목적은 아니었다. 빠르게 취약한 요소들을 발견하는 게 목적이었지.
이렇게 했을 때 스캔 결과만을 놓고 ‘우린 안전하다’고 여기는 것이 치명적인 실수가 된다. 급하게 만든 스캐너에서 나온 결과를 누가 믿겠느냐, 라고 누군가는 물을 수 있다. 하지만 시중에 판매되고 있는 다른 스캔 솔루션들도 비슷한 문제를 가지고 있다면 어떤가? 로그4셸 익스플로잇을 일단 막아두기 위해 변경한 설정들이 ‘좋아 보이는’ 건강검진 결과지를 사용자에게 제출하고 있다는 건 지금 어떤 스캐너나 예외일 수 없다.
필자가 강조하고 싶은 건 지금 우리가 사용하고 있는 모든 보안 도구들에 한계가 있다는 것을 인지하고 대응을 해야 한다는 것이다. 스캔 한 번 쭉 해보고 ‘우리 회사는 안전하다’고 CEO에게 보고서를 올리는 보안 담당자가 되어서는 안 된다. 우리도 위에 언급한 스캐너를 사용하며 고객들에게 ‘여기서 양호하다는 결과가 나온다고 해도 사실은 위험할 수 있다’는 걸 고지했다. 스캐너가 ‘괜찮다’는 결과를 내는 건 ‘취약점 하나 없는 깨끗한 상태’라는 게 아니라 ‘취약점이 뻔한 수법으로 찾기 힘들다’는 뜻이다.
외부에서 하는 스캔은 제한점이 분명히 존재한다. 스캔 결과를 100% 믿고 싶다면 모든 디지털 요소들의 모든 소스코드를 스캔해야 한다. 이렇게 함으로써 취약한 모든 버전들을 하나하나 걸러내야 한다. 하지만 이게 현실적으로 가능한 일인가? 그렇기 때문에 필자는 앞으로 로그4j와 관련된 ‘후처리 작업’이 실제 현장에서는 앞으로 수개월 동안 이어질 것으로 보인다. 언론에서 시들해져도 현장은 여전히 시끄럽고 고될 것이다. 로그4j처럼 사이버 공간 내 모든 요소에 깊숙하게 파고든 요소들을 편리하게 자동으로 찾아낼 기술을 우리는 아직 가지고 있지 않다.
그렇다면 앞으로 어떤 일이 벌어질까?
미래를 정확히 예측하는 건 어려운 일이지만, 그래도 한 가지는 분명하게 말할 수 있다. 적어도 앞으로 수주 동안은 로그4j를 찾는 데에 여러 조직들이 많은 시간을 들일 것이라는 점이다. 하지만 이게 꼭 나쁜 일은 아니다. 코로나가 마지막 팬데믹이 아닐 가능성이 높듯이, 이렇게 모든 사이버 공간과 네트워크 환경을 모조리 뒤져야만 하는 일이 앞으로 더 생기지 말란 법이 없다. 이참에 한 번 싹 들여다보는 훈련을 하는 것이 도움이 될 것이라고 필자는 보고 있다.
한 가지 아쉬운 건 보안 업계의 대응이 ‘조직화 되지 않았다’는 것이다. 사이버 공격은 점점 조직화 되고 따라서 강력해지는데, 우리는 아직도 파편이 되어 그 막강한 공격들에 대응하고 있다. 좀 더 우리 안에서 의견을 교환하는 방식에 대한 훈련이 필요해 보인다. 로그4셸 사태가 아무리 ‘최악의 상황’이더라도 언젠가는 해결될 것이다. 다만 다음에 비슷한 일이 터졌을 때, 똑같이 우왕좌왕한다면 그건 우리 잘못이 된다. 다음의 로그4셸 사태에도 대응할 수 있을 만한 능력을 지금 다져두어야 한다.
글 : 리차드 포드(Richard Ford), CTO, Praetorian
[국제부 문가용 기자(globoan@boannews.com)]
[보안뉴스 문가용 기자] 꿈같은 연말연시여, 안녕. CVE-2021-44228(로그4셸)이라는 역대 최악의 취약점 때문에 보안 업계는 곧바로 ‘연중 모드’로 돌입했다. 뭐가 이 취약점을 이리도 특별하고 지독하게 만드는 것일까? 얼마나 큰 재앙이 우리에게 예정되어 있는 것이며, 우리는 이걸 지켜보고만 있어야 하는 걸까? 어떻게 해야 최악의 상황은 면할 수 있을까?
[이미지 = utoimage]
필자는 이 지면을 통해 로그4셸에 대해 썰을 좀 풀어보고자 한다. 하지만 기술적인 설명을 하려는 건 아니다. 이미 필자가 아니어도 수많은 전문가들이 했고, 앞으로도 할 것이다. 로그4셸의 기술적 보고서가 하나 더 나오는 게 그리 큰 의미를 갖지는 않는다고 본다. 다만 왜 이 취약점을 가지고 이리들 호들갑을 떠는지를 산업 종사자의 시선으로 보고 싶다.
퍼펙트 스톰
로그4셸이라는 취약점은 그 자체로 좋지 않은 특성을 가지고 있다. 심지어 익스플로잇 행위가 매우 간단한 편에 속한다. 데이터와 관련된 취약점이기 때문에 인터넷에 연결된 시스템이 아니라 데이터와 연결된 시스템들이 공격에 노출된다. 클라우드 깊숙한 곳 어딘가에 로그4셸이 도사리고 있을 수도 있다. 아직 로그4셸 익스플로잇이 안 나와서 망정이지, 누군가 이걸 개발하는 순간 데이터라는 게 존재하는 사이버 공간 모든 곳에서 폭발적인 사고들이 터져나갈 가능성이 높다.
‘폭발적인 사고’ 혹은 ‘퍼펙스 스톰’이라고 말하게 되는 이유는 다음과 같다.
1) 로그4셸 취약점이 발견된 소프트웨어인 로그4j(Log4j)는 아주 조금의 과장을 섞어서 표현하자면 세상 어느 곳에나 있다. 심지어 접근하는 데에 권한을 필요로 하는 것도 아니다.
2) 자바가 조금이라도 사용되는 환경에서라면 이제 100% 안전을 보장할 수 없다. 모든 로그4j 인스턴스들을 패치하면 되긴 하는데, 이 로그4j라는 게 세상 모든 곳에 다 사용되기 때문에 다 찾아낼 수가 없다.
3) 공격자는 피해자를 꼬드겨 로그에 뭔가를 쓰도록 만들기만 하면 된다. 이를 위해 해커들 사이에서 여태까지 고안된 방법은 무수하게 많다. 간단한 것도 많고 제법 복잡하지만 효과가 확실한 것도 많다.
4) 검사를 시작한 시기와 결과가 나오는 시기 간에 유의미한 차이가 생길 수 있다. 이럴 때 탐지 결과가가 올바르지 않을 수도 있고, 취약한 시스템이 튼튼하다는 진단을 받을 수 있다.
아군의 포격과 잘못된 ‘보안 자신감’
로그4셸 취약점 자체로도 버거운데, 보안 전문가들 사이에서 서로를 해롭게 하는 행위들이 나타나기도 했다. 예를 들어 서드파티가 로그4j와 관련하여 새로운 규칙을 추가한다고 치자. 물론 이런 대처는 대단히 긍정적이다. 하지만 이 때문에 외부 스캔 결과를 믿기 힘들어진다. 공격자들의 공격 행위가 어려워진 만큼 보안 전문가들의 검사도 힘들어지는 것이다. 위험한 상태에 놓여 있는 것을 위험한 줄도 모르고 그냥 지나치게 될 가능성이 높아진다.
예를 들어 우리 프레토리안(Praetorian)에서는 주말 동안 스캐너를 하나 만들었다. 우리 고객들의 웹사이트들을 돌아다니며 취약점을 찾아내는 기능을 가진 스캐너였다. 하지만 고객사 측에서 여러 가지 설정 변경과 규칙 추가 등을 하는 바람에 스캔이 제대로 이뤄지지 않았다. 물론 한 사이트 한 사이트 추가 맞춤형 스캔을 실시하면 되는데, 그렇게 하나하나 공들여 검사하려는 게 스캐너 제작의 목적은 아니었다. 빠르게 취약한 요소들을 발견하는 게 목적이었지.
이렇게 했을 때 스캔 결과만을 놓고 ‘우린 안전하다’고 여기는 것이 치명적인 실수가 된다. 급하게 만든 스캐너에서 나온 결과를 누가 믿겠느냐, 라고 누군가는 물을 수 있다. 하지만 시중에 판매되고 있는 다른 스캔 솔루션들도 비슷한 문제를 가지고 있다면 어떤가? 로그4셸 익스플로잇을 일단 막아두기 위해 변경한 설정들이 ‘좋아 보이는’ 건강검진 결과지를 사용자에게 제출하고 있다는 건 지금 어떤 스캐너나 예외일 수 없다.
필자가 강조하고 싶은 건 지금 우리가 사용하고 있는 모든 보안 도구들에 한계가 있다는 것을 인지하고 대응을 해야 한다는 것이다. 스캔 한 번 쭉 해보고 ‘우리 회사는 안전하다’고 CEO에게 보고서를 올리는 보안 담당자가 되어서는 안 된다. 우리도 위에 언급한 스캐너를 사용하며 고객들에게 ‘여기서 양호하다는 결과가 나온다고 해도 사실은 위험할 수 있다’는 걸 고지했다. 스캐너가 ‘괜찮다’는 결과를 내는 건 ‘취약점 하나 없는 깨끗한 상태’라는 게 아니라 ‘취약점이 뻔한 수법으로 찾기 힘들다’는 뜻이다.
외부에서 하는 스캔은 제한점이 분명히 존재한다. 스캔 결과를 100% 믿고 싶다면 모든 디지털 요소들의 모든 소스코드를 스캔해야 한다. 이렇게 함으로써 취약한 모든 버전들을 하나하나 걸러내야 한다. 하지만 이게 현실적으로 가능한 일인가? 그렇기 때문에 필자는 앞으로 로그4j와 관련된 ‘후처리 작업’이 실제 현장에서는 앞으로 수개월 동안 이어질 것으로 보인다. 언론에서 시들해져도 현장은 여전히 시끄럽고 고될 것이다. 로그4j처럼 사이버 공간 내 모든 요소에 깊숙하게 파고든 요소들을 편리하게 자동으로 찾아낼 기술을 우리는 아직 가지고 있지 않다.
그렇다면 앞으로 어떤 일이 벌어질까?
미래를 정확히 예측하는 건 어려운 일이지만, 그래도 한 가지는 분명하게 말할 수 있다. 적어도 앞으로 수주 동안은 로그4j를 찾는 데에 여러 조직들이 많은 시간을 들일 것이라는 점이다. 하지만 이게 꼭 나쁜 일은 아니다. 코로나가 마지막 팬데믹이 아닐 가능성이 높듯이, 이렇게 모든 사이버 공간과 네트워크 환경을 모조리 뒤져야만 하는 일이 앞으로 더 생기지 말란 법이 없다. 이참에 한 번 싹 들여다보는 훈련을 하는 것이 도움이 될 것이라고 필자는 보고 있다.
한 가지 아쉬운 건 보안 업계의 대응이 ‘조직화 되지 않았다’는 것이다. 사이버 공격은 점점 조직화 되고 따라서 강력해지는데, 우리는 아직도 파편이 되어 그 막강한 공격들에 대응하고 있다. 좀 더 우리 안에서 의견을 교환하는 방식에 대한 훈련이 필요해 보인다. 로그4셸 사태가 아무리 ‘최악의 상황’이더라도 언젠가는 해결될 것이다. 다만 다음에 비슷한 일이 터졌을 때, 똑같이 우왕좌왕한다면 그건 우리 잘못이 된다. 다음의 로그4셸 사태에도 대응할 수 있을 만한 능력을 지금 다져두어야 한다.
글 : 리차드 포드(Richard Ford), CTO, Praetorian
[국제부 문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-05-17] 
.jpg)
.jpg)
