모든 공격과 사건은 곧 공격자들을 이해하기 위한 수단...근본 원인부터 알아내야
[보안뉴스 문가용 기자] 제로데이 취약점을 익스플로잇 하는 공격이 실제로 발생할 경우, 공격의 뿌리가 되는 부분, 즉 공격의 초기에서부터 이상한 점을 발견하는 게 중요하다. 이른 바 ‘근본 원인의 분석(root cause analysis)’이 필요하다는 것이다. 이를 통해 보안 전문가들은 공격이 어떤 식으로 발생했는지 알아내고 이후에 있을 공격에도 대비할 수 있게 된다.
[이미지 = utoimage]
현재 가상 공간에서 진행되고 있는 블랙햇에서 강연자로 나선 구글 프로젝트 제로(Google Project Zero)의 매디 스톤(Maddie Stone)은 “제로데이를 통해 사용자들을 노리는 행위를 최대한 어렵게 만드는 것이 우리의 일”이라고 운을 뗐다. “그렇게 하려면 그들이 어떤 식으로 움직이는지 최대한 많이 알아내야 합니다. 사이버 공격은 발생할 때마다 ‘파악의 기회’가 되죠.”
안타까운 건 의외로 이런 식의 접근법이 잘 발견되지 않는다는 것이다. 스톤은 “제로데이 익스플로잇에 대한 정보와 대책법은 보안 매체나 블로그에 자주 등장하고, 그와 관련된 멀웨어나 공격자에 대한 정보가 다뤄질 때도 있다”고 말한다. “하지만 공격자들이 실제 공격을 A단계에서부터 Z단계까지 어떻게 진행하는지 상세히 파악하는 부분에서는 약합니다. 특히 최초 침투를 분석하는 내용은 추측으로만 이뤄질 때가 많습니다.”
‘근본 원인 분석’의 목표는 최초 침투를 가능하게 했던 취약점이 무엇인지 파악하는 것이라고 스톤은 주장했다. “그 ‘파악’의 정도가 얼마나 깊어야 하냐면, 보안 전문가들도 똑같이 공격을 흉내 내볼 수 있어야 한다고 봅니다. 그 정도가 되면 공격자의 생리와 원리를 상세하게 이해했다고 볼 수 있죠. 대략적인 요약을 넘어선다는 것입니다. 그래야 공격 행위를 방해하기 위한 행동을 취할 수 있습니다. 막연하게 구조를 강화하고, 취약점을 패치하는 것 이상으로 아키텍처를 단단하게 만들 수 있게 됩니다.”
지난 1년 동안 프로젝트 제로 팀이 분석한 ‘실제 공격에 연루된 제로데이 취약점’은 11개였다. 분석은 당연히 ‘근본 원인 분석’으로 진행됐고, 크게 다섯 개의 기법들이 동원됐다. “취약점과 사건마다 그에 맞는 분석 방법이 따로 존재합니다. 획일적, 일률적으로 접근하면 제대로 된 분석이 이뤄지기 어렵습니다. 취약점을 역설계하는 방법에는 여러 가지가 있습니다. 상황과 분석 순서에 따라 창의력을 발휘해 맞춰가야 하기 때문입니다. 매번 인력, 자원, 시간, 위험도 등이 다르기 때문에 똑같은 방법론을 있는 그대로 적용할 수는 없습니다.”
그러면서 스톤은 ‘근본 원인 분석’ 방법을 네 가지 항목으로 나누었다.
1) 익스플로잇 코드의 리버싱 : 익스플로잇 샘플이 있을 때 가능하다.
2) 소스코드 패치 디핑 : 공격 표적의 소스코드에 접근할 수 있을 때 가능하다.
3) 바이너리 패치 디핑 : 두 개의 바이너리 빌드들을 비교하는 과정을 필요로 한다.
4) 버그 헌팅 : 패치되지 않은 취약점에 대한 정보와 익스플로잇 세부 정보를 근거로 하여 실행할 수 있다.
이 기법 중 어느 것을 활용해야 하는가는 상황과 사람에 따라 달라진다고 한다. “예를 들어 익스플로잇을 처음 발견한 사람에 따라 ‘고치는 것이 시급’하다고 판단된다면 ‘근본 원인 분석’ 과정을 거치지 않을 수 있습니다. 하지만 익스플로잇 코드를 직접 만든 사람이나, 익스플로잇이 되고 있는 제품이나 서비스를 제공하고 있는 벤더라면 얘기가 달라지죠. 이런 경우라면 (제로데이) 익스플로잇에 대한 철저한 분석을 진행해야 합니다. 벤더들에겐 그런 책임이 있어요.”
제3의 사용자들과 보안 전문가들이라면 어떨까? 제로데이가 익스플로잇 되는 걸 어쩌다 발견하게 되었다면? 아니면 그런 소식을 블로그 게시글이나 보안 권고문을 통해 접했다면? “십중팔구 이런 정보만으로 ‘충분히 대처할 만한 능력은 되지 않’을 것이 분명합니다. 그렇다면 먼저 ‘이 제로데이 취약점 문제에 대처하기 위해 얼마나 많은 시간과 자원을 투자할 수 있는가’를 결정해야 합니다. 그 예산과 자원 안에서 알맞은 방법론을 선택해야 하겠죠.”
스톤은 “프로젝트 제로 팀은 이 모든 입장에 처해보았다”고 말한다. “구글에서 만든 서비스의 소스코드에서 우리가 제로데이 익스플로잇을 발견할 때도 있고, 어떨 땐 파트너사들에서 우리에게 알려줄 때도 있습니다. 그럴 땐 ‘근본 원인 분석’까지 진행합니다. 그렇게 해서 공격자들의 공격 원리를 전부 파헤치려고 합니다. 하지만 대부분 저희 제로 팀은 서드파티로서, 타 회사의 서비스나 제품에서 취약점을 발견합니다. 그럴 땐 먼저 여러 가지 상황을 고려하여 ‘얼마나 이 부분에 대한 연구를 진행할 것인가’를 결정합니다.”
그러면서 그는 “보안 전문가들 대부분 서드파티의 입장에서 취약점과 익스플로잇을 접할 때가 가장 많을 것”이라며 “연구를 실시하기 전에 어느 정도 자원을 투자할 것인가를 냉정하게 정하는 것에 능숙해져야 할 것”이라고 지적했다. “연구와 분석을 한다고 해서 늘 성공적인 결과를 내는 건 아닙니다. 저희도 마찬가지입니다. 구글의 취약점 팀이라고 해서 늘 원하는 대로 성공을 거두지 않습니다. 몇 달을 분석해도 아무런 소득이 없을 수도 있어요. 도무지 최초 침투 방법을 알아내지 못할 때도 많습니다. 하지만 그렇더라도 그런 결과들로부터 뭔가를 배울 수 있어야 합니다. 그리고 그 배운 걸 다음 분석 때 적용하는 게 중요합니다.”
스톤의 실제 발표 슬라이드는 여기(https://i.blackhat.com/USA-20/Wednesday/us-20-Stone-Reversing-The-Root-Identifying-The-Exploited-Vulnerability-In-0-Days-Used-In-The-Wild.pdf)서 열람이 가능하다.
3줄 요약
1. 제로데이 취약점 익스플로잇 발견할 경우, 공격의 A부터 Z까지 알아내야 함.
2. 그렇게 해야 다음 공격을 더 어렵게 만들 수 있게 됨.
3. 그렇기 때문에 제로데이 취약점 익스플로잇을 발견할 경우 근본 원인 분석이 필요.
[국제부 문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>