Google says it’s too easy for hackers to find new security flaws

보안 취약점이 사라지지 않는 이유

해커들은 같은 유형의 소프트웨어 취약점을 계속해서 악용하고 있다. 회사들이 종종 나무만 보고 숲을 보지 못하기 때문이다

2018년 12월, 구글의 연구원들은 마이크로소프트의 인터넷 익스플로러 브라우저를 겨냥한 해커 집단을 발견했다. 이보다 2년 전 마이크로소프트는 인터넷 익스플로러의 신규 개발을 중단했다. 하지만 익스플로러는 여전히 매우 많이 쓰이는 브라우저이므로 해킹 방법만 찾을 수 있다면, 수십억 대의 컴퓨터를 열어볼 수 있게 되는 셈이다.

이 해커들은 제로데이 취약점(zero-day vulnerabilities)이라고 하는, 이전에 보고된 적 없는 새로운 결함을 찾아다니고 있었다.

이들이 발견된 직후, 구글 연구원들은 익스플로잇(exploit)* 하나가 악용되고 있는 것을 목격했다. 마이크로소프트는 패치를 배포하고 결함을 수정했다. 2019년 9월, 같은 해커 집단이 또 다른 유사한 취약점을 악용하는 것이 발견되었다.

*익스플로잇: 소프트웨어나 하드웨어의 취약점을 이용해 공격자의 악의적 동작을 실행하도록 만든 명령어나 공격 행위

2019년 11월과 2020년 1월, 2020년 4월에 동일한 버그 클래스(bug class)에서 단기간에 악용되는 제로데이 취약점이 더 많이 발견되어 최소 5개가 추가되었다. 마이크로소프트는 여러 가지 보안 업데이트를 배포했다. 하지만 일부는 표적이 된 취약점을 실제로 수정하지 못했고, 또 다른 일부는 해커가 코드에서 한두 줄만 바꿔도 익스플로잇을 다시 실행할 수 있었다.

“이런 버그 중 하나를 이해하면, 몇 줄만 바꿔서 제로데이 공격을 계속 할 수 있다.”

구글의 보안 연구원 매디 스톤(Maddie Stone)의 새로운 연구에 따르면, 이 일련의 사건은 사이버보안의 훨씬 더 큰 문제를 보여준다. 즉 해커들이 은밀한 제로데이 결함을 지속적으로 악용하기가 너무 쉽다는 뜻이다. 이는 기업들이 결함과 허점을 영구히 차단하는 일을 제대로 해내고 있지 않기 때문이다.

프로젝트 제로(Project Zero)로 알려진 구글 보안팀의 일원인 스톤의 연구는, 인기 있는 크롬 브라우저에서 구글이 겪었던 문제를 포함해 여러 실제 사례를 집중 조명한다.

지난 2월 2일, 보안 컨퍼런스 에니그마(Enigma)에서 스톤은 “우리가 발견한 문제는 업계 전반에 만연해 있다. 불완전한 패치 때문에 공격자가 제로데이로 사용자들을 공격하기가 더 쉬워졌다”고 말했다. 그는 “(우리가 보안 취약점을 제대로 수정하지 않기 때문에) 공격자들은 새로운 버그 클래스를 내놓거나, 완전히 새로운 익스플로잇을 개발하거나, 이전에 연구된 적 없는 코드를 살펴보지 않아도 된다. 이미 알려진 다양한 취약점을 재사용할 수 있는 여건이 지금 조성돼 있다”고 주장했다.

쉽게 딸 수 있는 열매

‘프로젝트 제로’는 제로데이 결함을 찾는 데만 전념하는 구글 내부 조직이다. 제로데이는 모든 해커들이 탐하는 취약점이며, 제로데이 공격으로 인한 보상은 어느 때보다 커졌다. 취약점을 찾아 공략하기가 더 어려워졌기 때문이 아니라, 오늘날과 같은 초연결 사회에서 보안 취약점에 대한 공격은 더 강력한 힘을 발휘하기 때문이다.

팀 조직 후 6년 동안 프로젝트 제로는 150개가 넘는 주요 제로데이 버그를 공개적으로 추적해왔다. 2020년 스톤의 팀은 악용된 제로데이 결함 24개를 문서화했다. 이 중 4분의 1은 이전에 발견된 취약점과 매우 유사했다. 3개는 불완전하게 패치되었고, 이는 곧 해커의 코드에 몇 가지 수정만 하면 공격이 계속 진행될 수 있다는 의미였다. 보안 공격들 상당수는 이런 기본적 실수와 ‘쉽게 딸 수 있는 열매(low-hanging fruit)’를 악용한다고 그녀는 말한다.

스톤은 “이는 해커에게는 그리 어렵지 않은 일”이라며 “이런 버그 중 하나를 이해하면, 몇 줄만 바꿔서 제로데이 공격을 계속 할 수 있다”고 말했다.

왜 수정되지 않을까? 소프트웨어 기업에 근무하는 대부분의 보안 팀은 시간과 자원이 제한되어 있다. 따라서 엔지니어의 우선순위와 보상 제도가 제대로 갖춰져 있지 않으면, 이들은 취약점의 근본 문제를 해결하는 대신 눈 앞에 보이는 문제만 수정하고 넘어간다는 것이 그녀의 생각이다.

다른 연구자들도 이것이 일반적인 문제임을 확인해준다.

사이버보안 기업 트렌드마이크로의 취약점 연구원 존 심프슨(John Simpson)은 “심지어 내가 발견한 제로데이 중 2~3개는 다름 아닌 소프트웨어 기업이 코드 한 줄만 수정해 내놓은 보안 패치였다. 수정한 코드의 바로 다음 줄에도 동일한 취약점이 있었는데 이를 굳이 고치려고 하지 않았다”고 말한다. 그는 “이런 이야기는 지칠 때까지 할 수 있다. 하지만 기업이 보고된 버그만 수정하기보다 더 많은 일을 할 수 있는 적절한 구조를 만들지 않는 한, 보안 패치의 품질은 결코 나아지지 않을 것”이라고 말했다.

변화를 위해 가장 중요한 것은 결국 시간과 비용이다. 즉, 엔지니어가 새로운 보안 취약점을 조사하고, 근본 원인을 찾아내고, 개별 취약점에 자주 나타나는 심층적 문제를 수정할 수 있는 공간을 더 많이 제공해야 한다는 것이다. 이는 또한 변종 분석(variant analysis)도 가능하게 할 것이라고 스톤은 말했다. 변종 분석은 다른 곳에서 같은 취약점을 찾거나, 혹은 같은 코드 블록에서 다른 취약점을 찾는 것을 뜻한다.

전혀 다른 열매

일부 기업은 이미 다른 접근 방식을 시도하고 있다. 예를 들어 애플은 취약점을 더 근본적인 수준에서 제거함으로써 아이폰의 가장 심각한 보안 위험을 해결해왔다.

2019년 구글 프로젝트 제로 연구원 나탈리 실바노비치(Natalie Silvanovich)는 애플 아이메시지에서 치명적인 제로클릭(zero-click, 상호작용 없는 공격을 말함), 제로데이 버그를 발표해 화제가 됐다. 이 결함을 통해 공격자는 피해자가 아무 것도 하지 않아도 피해자의 휴대폰 전체를 장악할 수 있다. 사용자가 문제를 일으키는 링크를 클릭하지 않은 경우에도 해커가 휴대폰을 제어할 수 있었다. (2020년 12월에는 아이메시지의 또 다른 제로클릭 제로데이 취약점을 악용해 언론인을 해킹한 사례가 보고되었다.)

애플은 특정 취약점에 좁게 접근하는 대신, 아이메시지의 핵심으로 파고들어가 해커들이 악용하고 있는 근본적이고 구조적인 문제를 해결했다. 애플이 이런 변경 사항의 구체적 특성에 대해 아무런 언급도 하지 않았지만(애플은 iOS 14 소프트웨어 업데이트와 함께 일련의 개선 사항만 발표했다), 프로젝트 제로의 사무엘 그로스(Samuel Groß)가 최근 애플의 운영체제인 iOS와 아이메시지를 면밀히 분석해 어떤 일이 있었는지를 추론했다.

아이메시지 앱은 현재 블래스트도어(BlastDoor)라는 기능을 통해 휴대전화의 나머지 부분과 분리되어 있으며, 이는 스위프트라는 애플의 프로그래밍 언어로 작성되어 있어 해커들이 아이메시지의 기억장치에 접근하기가 더 어렵게 됐다.

애플은 또 iOS의 아키텍처를 개선하여 아이폰의 공유 캐시에 접근하기 더 어렵게 만들었다. 공유 캐시는 최근 몇 년간 아이폰 해킹의 가장 대표적 수법이었다.

마지막으로 애플은 해커들이 빠른 속도로 연속해서 비밀번호 입력을 반복 시도하는 공격인 ‘브루트 포스(brute force)’ 공격을 하지 못하도록 차단했다. 새로운 제한 기능을 통해 이전에는 몇 분만에 완료할 수 있는 공격이 이제는 몇 시간 또는 며칠이 걸릴 수 있기 때문에 해커의 관심에서 멀어지게 되었다.

그로스는 “애플이 최종 사용자의 보안을 향상시키기 위해 이런 종류의 대규모 리팩터링(refactorings, 결과의 변경 없이 코드의 구조를 재조정하는 것)을 위한 자원을 따로 떼어둔 것이 인상적”이라고 썼다. 그는 “이런 개선은 공격적 보안 작업의 가치를 잘 보여준다. 즉, 단일 버그만 수정한 것이 아니라, 익스플로잇 관련 작업에서 얻은 통찰력을 기반으로 한 구조적 개선이 이루어졌다”고 설명했다.

사회가 점점 더 연결될수록 해킹이 미치는 결과도 더 커지고 있다. 이는 기술기업들이 모든 취약점과 익스플로잇을 유발하는 주요 사이버보안 문제에 우선순위를 두고 이에 투자하는 것이 그 어느 때보다 중요하다는 의미이다.

스톤은 “기술기업 경영자들에게 할 조언은 오로지 투자를 더 하라는 것뿐”이라고 말했다. 그는 “엔지니어들에게 취약점의 근본 원인을 충분히 조사하고 패치할 시간적 여유를 주고, 변종 분석을 수행할 재량을 제공해야 한다. 또한 기술적 부채(technical debt)*를 줄이는 작업에 보상을 제공하고, 체계적 수정에 집중할 수 있게 하라”고 조언했다.

* 기술적 부채: ‘소프트웨어 개발 과정에서 장기적으로 바람직한 접근법 대신 당장 편한 해법을 택해 발생하는 추가적 작업 비용’

미리보기 3회1회

MIT Technology Review 구독을 시작하시면 모든 기사를 제한 없이 이용할 수 있습니다.