2020-10-27 12:15 (화)
Zeroday가 실제 세계에 나오기까지의 과정
상태바
Zeroday가 실제 세계에 나오기까지의 과정
  • 길민권
  • 승인 2011.10.17 15:34
이 기사를 공유합니다

제로데이가 실제 환경에서 쓰일 경우 총 3가지 과정 거치게 된다
개인적으로 Security의 꽃은 “취약점”이라고 생각합니다. 취약점의 형태는 다양하게 나타날 수 있습니다. 컴퓨터 상에서 구동되는 프로그램들에서 발견될 수도 있고, 소셜 엔지니어링으로도 찾아낼 수 있습니다. 심지어 직원들의 나태함으로 인해서 발생할 수도 있죠.
 
애초에 취약점으로 인해 문제가 발생될 수 없는 환경이라면, Security 분야도 탄생하지 않았을 것입니다. 취약점들을 가리키는 다른 표현으로는, 제로데이(0-day)가 있습니다. 이번 글에서는 제로데이가 실제 세계에 나오기까지 어떤 과정을 거치는지 간략히 알아볼 것입니다.
 
In the wild에서는 Flash 0day, PDF 0day, 인터넷 익스플로러 0day 등 다양한 제로데이들을 볼 수 있습니다. 제로데이라는 단어 하나 때문에, “제로데이 = 버그”라는 공식 정도가 일반 사람들이 생각할 수 있는 지식이지만, 제로데이는 크게 다음 3단계를 거친 것이라 볼 수 있습니다.
 
1. 취약점 찾기 (Hunting bugs)
2. 취약점 증명 (Writing Proof of Concept)
3. 공격 성공률이 높은 Exploit 작성 (Weaponizing)
 
많은 사람들이 제로데이를 1번이라고 생각하는데, 이것이 실제 환경에서 쓰일 경우엔 위처럼 총 3가지 과정을 거치게 됩니다. 좀 더 자세히 알아보기 전에, 이 글에선 Memory corruption 류의 버그에 대해서 얘기할 것입니다. 그 이유는 현대의 OS에는 다양한 보안 메커니즘이 적용되어 있는데, 이 메커니즘들은 주로 Memory corruption류의 버그를 방지하기 위함이기 때문입니다. 즉, 최근의 상황에 맞게 이야기를 전개할 수 있는 주제라고 볼 수 있습니다.
 
1. Hunting bugs
말 그대로 소프트웨어의 취약점을 찾는 단계입니다. 우선 버그를 찾아야 일을 진행할 수 있기 때문에 가장 단계라 볼 수 있습니다. 해커들은 보통 다음 3가지 방법으로 버그를 발견합니다.
 
1-1. Auditing code
대상 프로그램의 소스 코드가 공개된 경우, 소스 코드 검증을 통해 취약점을 찾아냅니다. 특히 오픈소스 프로그램들은 이 방법으로 취약점 탐색이 많이 진행됩니다. 요즘에는 hex-rays 등 디컴파일러들의 기능이 무척 좋아졌기 때문에 바이너리만 존재하는 프로그램의 경우에도 소스 코드 검증으로 버그를 찾는 경우가 있습니다. 소스 코드를 통해 취약점을 발견하고 싶으신 분들은 The art of software security assessment(www.yes24.com/24/goods/2278855?scode=032&OzSrank=1)를 참고해보시기 바랍니다.
 
1-2. Fuzzing
자동화된 취약점 탐색 프로그램을 제작한 후에 대상 프로그램에 테스트를 하는 방법을 말합니다. 소스 코드, 바이너리 모두 적용할 수 있는 방법이고 상당히 많은 부분을 자동화하여 취약점을 찾을 수 있기 때문에 많은 해커들이 선호하는 방법입니다. 해외의 많은 보안 회사에서 Fuzzing을 독자적으로 진행하고 있으며, 아카데믹 학회에서도 관련 연구가 활발하게 이루어지고 있습니다. Fuzzing 관련 추천 도서는 곰책으로 유명한 Fuzzing: Brute Force Vulnerability Discovery (www.yes24.com/24/goods/2513138?scode=032&OzSrank=1) 입니다.
 
1-3. Reversing
바이너리를 직접 리버싱하여 버그를 찾는 해커들도 있습니다. 그러나 사실 많은 해커들이 1번과 2번 방식을 통해 버그를 찾습니다. 현대의 프로그램들은 규모가 크기 때문에 리버싱을 하는데 걸리는 시간이 오래 걸리기 때문에 시간대비 효율적인 면에서는 좋지 않다고 볼 수 있습니다. 그러나 1번의 경우 소스 코드가 존재해야만 가능하고 2번의 경우에는 커버하지 못하는 테스트 케이스가 많기 때문에 리버싱을 통해 찾는 방식만의 특별한 장점이 있을 수 있습니다. 리버싱 책으로 유명한 저서는 Secrets of reversing (www.yes24.com/24/goods/3386676?scode=032&OzSrank=1)이 있습니다.
 
노력 끝에 버그를 찾았다고 하더라도, 이게 끝이 아닙니다. 버그는 아직 가공되지 않은 보석과도 같습니다. 더 큰 가치를 갖기 위해서는 더 많은 과정들이 필요합니다.
 
2. Writing Proof of Concept
“Hunting bugs” 단계에서 발견한 버그들이 실제로 유용한 버그인지 증명을 하기 위해서는 이에 대한 PoC (Proof of Concept) 코드를 작성해야 합니다. 만약 버그 발견자가 해당 프로그램에 대해서 능숙하고 많은 지식을 알고 있는 상태라면 PoC를 작성하는 것은 어려운 일이 아닐 수도 있습니다. 그러나 버그 헌터들은 특성상 여러 프로그램을 대상으로 취약점 연구를 진행하며 항상 새로운 플랫폼으로 옮겨가는 경향이 있습니다.
 
현대의 프로그램들은 규모가 크기 때문에 해당 프로그램의 개발자조차 자기가 만든 모듈 이외에는 자세한 내용을 알지 못하는 경우가 많습니다. 따라서, 운이 좋은 경우가 아니라면 버그 헌터가 특정 프로그램에서 버그를 발견했다고 하더라도 그것을 금방 이해하고 exploit할 수는 없습니다.
 
즉, 버그에 유용한지에 대한 증명 코드를 만드는 것조차도 하나의 과정으로 볼 수 있을 정도로 어려운 작업입니다. 이 작업을 잘 수행하기 위해서는 해당 프로그램의 스펙을 파악하는 것이 중요합니다. 스펙을 확인하는 방법은 크게 3가지 입니다.
 
2-1. 개발 회사에서 (혹은 3rd party 업체에서) 작성한 Document 참고
가장 좋은 방법은 개발 회사에서 직접 작성한 문서들을 참고하는 것입니다. 명시된 스펙을 보면서 PoC 코드를 작성하면 훨씬 시간을 단축시킬 수 있습니다. 간혹 문서화를 게을리하거나 명시된 스펙과는 다른 스펙이 구현된 경우에는 트러블이 생길 수도 있습니다만, 해커들은 우선적으로 Document들을 찾는데 초점을 맞출 정도로 중요한 정보입니다.
 
2-2. 소스 코드 분석을 통한 프로그램 스펙 파악
오픈소스일 경우에는 코드가 이미 공개되어 있기 때문에 프로그램의 내부를 파악하는데 크게 어렵지 않습니다. 소스 코드는 실제로 돌아가고 있는 프로그램을 반영하기 때문에 종종 Document를 참조하는 것보다 나은 경우도 있습니다. Document는 항상 최신으로 업데이트되지 않을 수도 있고 실제 스펙과는 다른 경우가 있기 때문입니다.
 
2-3. Reversing을 통한 프로그램 분석 (소스 코드가 존재하지 않을 때)
Document도 없고 소스 코드도 존재하지 않는 경우라면 Reversing 밖에 방법이 없습니다. 취약점이 발생한 부분부터 시작하여 상위 플로우를 추적 해나가며 프로그램을 이해합니다. 프로그램이 복잡할 수록 시간이 오래 걸리며 가장 어려운 작업이라고 볼 수 있습니다.
 
앞서 언급했듯이 운이 좋은 경우, 가령 특정 레지스터를 쉽게 조작할 수 있다거나, 중요 메모리 위치를 손 쉽게 바꿀 수 있다거나 하는 경우에는 이 과정이 필요 없이 빠르게 다음 단계로 넘어갈 수 있습니다.
 
3. Weaponizing
마지막 단계입니다. 세계적으로 취약점 무기화에 관한 주제는 버그를 찾는 방법론보다도 더 많이 연구되고 있습니다.
 
앞의 두 단계들은 요구 사항과 목표가 명확한 반면에 이번 단계는 설정할 수 있는 범위가 비교적 넓다고 볼 수 있습니다. 따라서 앞의 단계들은 작업량의 범위가 크게 달라지지 않지만 마지막 단계는 목표 설정에 따라 작업량이 완전히 달라질 수 있습니다. 가령 모든 윈도우 버전, 언어 팩, 설치된 Anti Virus 등을 고려한 공격 코드가 목표라면 많은 작업량이 요구됩니다. 기술적인 면에서 봤을 때, Weaponizing 프로세스은 크게 3가지로 작업을 분류할 수 있습니다.
 
3-1. 공격 대상 환경 사전 파악
공격을 시도하기 전, 상대방의 환경을 정확히 알 수 있다면, 공격 성공률이 높아진다고 볼 수 있습니다. 하나의 공격 코드로 여러 버전에 공격을 성공시킬 수 있는 버그도 있지만 마이너 버전이 조금이라도 다를 경우 전혀 작동하지 않는 버그도 있습니다. 그렇기 때문에 대상 환경을 사전 파악하는 것이 무척 중요합니다.
 
웹 브라우저의 버그는 비교적 대상 PC 환경에 맞게 공격 코드를 적용하기가 수월합니다. 그 이유는 각종 리소스를 이용하여 대상 PC 환경 정보를 뽑아낼 수 있기 때문입니다. 사용하는 운영체제의 버전이나 AV 종류를 알아내기도 합니다.
 
3-2. Security mitigation 우회
대부분의 Security mitigation들은 Memory corruption의 위협을 줄이기 위해서 만들어 졌습니다. 이 말은, 만약 공격자가 Buffer overflow 등의 Memory corruption 버그를 보유하고 있다고 하더라도, 이 Security mitigation들을 우회하지 못한다면 사용할 수 없음을 의미합니다.
 
가장 대표적인 방어 메커니즘은 DEP(Data Execution Prevention http://en.wikipedia.org/wiki/Data_Execution_Prevention)와 ASLR(Address Space Layout Randomization http://en.wikipedia.org/wiki/Address_space_layout_randomization)이 있습니다. 최신 OS에서는 이러한 방어 메커니즘이 기본적으로 작동하고 있기 때문에, 우회할 수 있는 방법이 없다면 버그를 사용할 수 없습니다. 우회 방법 연구도 Weaponizing 과정 중 하나라고 볼 수 있습니다.
 
3-3. 은밀함 및 후처리
특히 정보 기관의 경우 공격에 성공하더라도, 공격을 당한 상대방이 눈치챌 수 없게끔 처리하는 작업에 많은 신경을 써야 합니다. Memory corruption의 경우 공격에 성공한 후 Stack 등을 정리해주지 않으면 메모리 액세스 위반 에러 등이 발생할 수도 있고, 이것은 상대방에게 공격에 대한 의심을 갖게 만듭니다.
 
따라서, 상대방 PC를 장악한 후의, 처리하는 과정을 위한 연구도 weaponizing의 한 분야라고 할 수 있습니다.
 
위와 같은 Weaponizing 작업을 수행하는 부류는 크게 3 집단입니다.
 
1) 대량 공격 범죄자들
일명 Massive attack으로 대량의 PC를 장악한 후, 게임 계정 탈취 등 원하는 이득을 취하는 집단을 말합니다. 이들은 취약점의 생태에 잘 알고 있습니다. 소프트웨어 취약점은 공개될 경우 금방 패치가 되어 가치가 빠르게 떨어질 수 있다는 것을 알기 때문에 짧은 시간 내에 실제 공격에 사용하는 것이 주 목적입니다.
 
그렇기 때문에 정교한 공격보다는, 그럭저럭 작동하는 무기를 만들어 빨리 적용합니다. 그렇다 보니 기술적인 면에서 뛰어나지 않은 경향이 있습니다. 이런 특성을 갖는 데에는 나름대로의 이유가 있습니다. Massive attack은 정교하진 않지만 어느 정도 작동하면서도 적은 작업 시간이 요구되는 공격 방식으로 단시간 내에 많은 PC를 잡는 것이 효율적이기 때문입니다.
 
2) 산업 스파이
비지니스의 규모가 커지면서 산업 스파이들도 기승을 부리고 있습니다. 이 부류의 공격자들은 실력이 천차만별이라는 정보가 있습니다. 아직까지 제대로 된 보안 마인드를 가진 회사들이 많지 않기 때문에, 저급 해킹 기술로도 성공할 수 있기도 하지만 군수 업체나 대기업들의 경우엔 세계적으로 유명하고 실력있는 해커들도 놀랄 정도의 고급 기술이 사용된다고 합니다.
 
3) 정보 기관
사실상 Weaponizing은 이 집단을 위한 것이라 볼 수 있습니다. PoC는 말 그대로 데모 코드이기 때문에 정보 기관에서 사용하기에 적합하지 않습니다. 예를 들어, Windows XP에서 작동하는 특정 취약점이 Windows 7에서는 여러 보안 기술에 막혀서 작동하지 않을 수도 있기 때문입니다.
 
하나의 플랫폼에서 작동하는 공격 코드가 다른 공격 코드에서 작동하지 않을 경우, 문제가 발생할 수 있습니다. 가령, 정보 기관에서 장악하고 싶어하는 상대방의 환경을 정확히 모르는 상황에서 해당 공격 코드를 사용하게 되면 정상적으로 작동하지 않아 상대방이 공격을 눈치챌 수 있습니다.
 
이것은 하나의 예일뿐이고, 정보 기관에서는 가능한 완벽한 공격 코드를 원하기 때문에 Weaponizing를 무척 중요시 여기고 있습니다.
 
이번 글에서는 제로데이가 실제 세계에 나오기까지 어떤 과정을 거치는지, 또 누가 Weaponizing을 하는지 대략적으로 알아보았습니다. 이 과정들은 취약점의 유형에 따라 달라질 수 있습니다. 다음 블로그 글에서는 각 과정 별로 좀 더 자세한 기술적인 사례를 들어 살펴보겠습니다.
 
리뷰를 해주신 분들입니다. 감사합니다!
ByungHo Min
Twitter – http://twitter.com/tais9
Facebook – http://www.facebook.com/tais9
[by beistlab 이승진]