▣ 스펙터·멜트다운에 대처하는 7가지 방안
2017년 6월, 구글 보안 분석팀 및 보안 전문가들은 마이크 로프로세서가 성능 개선을 위해 명령을 추측실행(Specula tive Execution)하는 방식을 악용한 해킹 메커니즘을 밝혀냈 다.
근본적인 원인은 보안상의 속도를 위해 최적화된 모든 최 신 프로세서의 설계 결함에 있으며, 이를 통해 해커는 운영체 제(OS) 커널로 보안돼야 할 메모리 내용을 읽을 수 있고, 따 라서 커널 작업을 손상시키거나 패스워드나 암호 키 등의 보 안 데이터에 접근할 수 있다.
이는 스펙터(Spectre)와 멜트다 운(Meltdown)이며, 현재까지 2가지의 스펙터 변종이 파악 됐다.
스펙터·멜트다운 익스플로잇(exploit)은 마이크로프로세 서가 추측실행을 구현하는 방식의 취약점을 노린다.
따라서 이러한 취약점을 제거하기 위해 코어 마이크로프로세서 설계 를 수정하는 장기적인 수단이 필요하다.
이 과정에서 마이크 로프로세서의 코어 아키텍처 수정이 가장 중요하며, 필요한 재설계가 이뤄지고 새로운 기기가 시장에 출시되기 까지는 최대 18개월에서 최대 24개월이 소요될 것으로 보인다.
많은 소프트웨어 업체들은 이러한 취약점을 즉각적으로 보완하기 위해 자체 업데이트와 패치에 집중하고 있다.
익스플로잇은 모든 컴퓨팅 디바이스에 영향을 미칠 수 있 다.
PC와 클라우드 서버가 가장 많이 노출되며 온프레미스 서버가 그 뒤를 잇는다.
네트워킹, 스토리지 장비, 스마트폰, 사물인터넷(IoT), 엔드포인트 등은 대개 엄격히 통제되는 코 드를 실행하므로 악성코드를 실행할 위험이 현저히 낮지만, 패치 설치에 따른 성능 문제가 발생할 가능성이 높다.
한편 기기에 탑재된 마이크로프로세서가 추측실행을 지원 하지 않는 경우, OS 업데이트를 적용하더라도 기능에 지장을 주지 않는다.
그러나 피해 입은 프로세서가 탑재된 기기를 업 데이트할 때와 마찬가지로, OS가 커널과 사용자 메모리 공간 을 전환하는 방식이 수정되기 때문에 성능 저하가 발생할 수 있다.
모든 프로세서와 소프트웨어가 이러한 익스플로잇에 동 일한 수준으로 취약한 것은 아니며, 시스템이 확인되지 않거 나 신뢰할 수 없는 코드 작동에 노출돼있는 정도에 따라 위험 수준이 달라진다.
기업의 비즈니스 정보 보안과 리스크 관리 책임자들은 분 명하고 실용적인 리스크 기반 시정 계획을 통해 이와 같은 위 험을 관리하고 해결할 수 있도록 준비해야 한다.
가트너는 IT 조직들에 자체 시스템이 해커 공격에 노출될 가능성을 사전 에 파악해 둘 것을 당부한다.
◆ 위험을 인식하고 현실적인 대응방안을 찾아라
구글 보안팀이 밝혀낸 익스플로잇은 그 심각성이 상당하지 만, 아직 실제 공격에 대해 알려진 바는 없다.
최신 OS와 하이퍼바이저는 모두 정형화되고 계층화된 권 한 모델에 기반해 보안 격리·분리 기능을 제공한다.
이와 같 이 악용 가능한 설계 취약점은 하드웨어에 있기 때문에, 그 위의 모든 소프트웨어 레이어들은 공격 대상이 될 수 있다.
바로 이러한 점 때문에 가트너는 현실적이고 빠른 대응에 나 설 것을 권고한다. 공격으로부터 안전한 메모리는 처음부터 있을 수 없다.
웹에서 자바스크립트를 통해 패치되지 않은 PC나 노트북, 모바일 기기 등에 공격을 취하면 즉각 위험이 발생한다.
공급 업체의 펌웨어와 하이퍼바이저 레이어 업데이트가 이뤄지지 않은 퍼블릭 클라우드 인프라에서 구동되는 타 가상머신 (VM)에서 악성 애플리케이션이 실행될 수 있다.
개념증명(POC) 공격은 한 번에 한 비트씩 이뤄져 상대적으 로 속도가 느리지만, 공격 코드가 작아서 분명하게 확인하기 어렵다.
해커들은 패스워드 캐시, 암호화·비암호화 키, TLS (Transport Layer Security) 키, 인증서, 코드 서명 인증서, 토큰이나 이와 유사한 민감한 데이터, 암호 등을 주로 노린다.
이와 같은 위험이 있기는 하지만, 메모리는 읽힐 수는 있어 도 변경될 수는 없다는 점을 인식해야 한다.
결함을 악용하려 면 신뢰할 수 없는 코드를 대상 시스템에 삽입하고 실행해야 하는데, 이는 잘 관리된 서버에서는 상당히 어려운 작업이다.
또한 너무 성급하게 패치에 의존하지 않는 것도 좋다. 초기 패치들은 일부 바이러스 백신 제품과 충돌을 일으킨 바 있고 윈도우 데스크톱을 잠갔다.
탑재된 AMD 마이크로프로세서 와 충돌해 시스템 부팅 장애를 일으킨 패치도 있었으며, 다른 초기 패치들 중에는 심각한 성능 저하를 일으켜 후속 패치로 해결된 사례도 있었다.
◆ 세부 인벤토리에서 시작하라
대부분의 최신 IT 시스템은 해당 취약점에 어느 정도 영향 을 받을 수밖에 없다.
보안 책임자들은 피해를 입은 시스템의 인벤토리를 시작점으로 삼아야 한다.
Y2K가 여러 시스템에 타격을 입히는 취약성을 갖고 있어서 의도적인 단계별 치료 계획이 필요했던 것이 아니다.
경우에 따라 패치하지 않는 것 이 적절한 결정일 때도 있다.
각 시스템마다 기기 또는 워크로드, 마이크로프로세서 버 전과 펌웨어 버전을 추적하려면 자세한 데이터베이스나 스프 레드시트가 필요하다.
소프트웨어 레이어에는 OS 제조사, OS 버전과 하이퍼바이저 업체와 버전 목록을 만들어야 한다.
최종 사용자용 시스템의 경우 브라우저 업체와 버전이 추적 돼야 하며, 바이러스 백신 소프트웨어나 엔드포인트 보호 플 랫폼 소프트웨어가 갖춰진 시스템의 경우 이들의 버전도 추 적돼야 한다.
또한 스택의 각 레이어에서는 공급 업체로부터 패치 사용 이 가능한지, 신뢰해도 되는지 추적해야 한다.
◆ 위험을 최우선 순위에 둔 복구 계획을 마련하라
이번 사태를 통해 드러난 취약점은 원격 공격이 불가능하 다.
공격이 성공하려면 해커들이 시스템 상에서 코드를 실행 해야 하기에 모든 시스템에 대한 응용 프로그램 제어와 화이 트리스팅을 통해 알 수 없는 코드 실행의 위험성을 현저히 줄 일 수 있다.
또한 비슷한 시스템과 애플리케이션 그룹의 대표 시스템 하나를 업그레이드해 실질적 성능 영향을 파악할 필 요가 있다.
초기에 OS와 펌웨어 업데이트 호환 문제가 있었던 AMD 윈도우의 경우 특히 이러한 작업이 필요하다.
리눅스(Linux)를 사용하는 기업의 경우 CPU와 리눅스 배 포본 내에서 프로세스문맥식별기(PCID) 지원이 가능한지 확 인해야 한다.
또한 IaaS에서 더 큰 인스턴스 유형으로 이동, 혹은 가상화 데이터 센터의 밀도 축소와 물리적 서버 추가 등 으로 시스템에 추가 용량을 적용할 준비가 돼 있어야 한다.
◆ 복구를 우선시 하라
퍼블릭 클라우드 제공업체들의 펌웨어와 가상화 레이어의 패치가 시행됐는지 확인해야 한다.
클라우드 업체의 기본 펌 웨어와 하이퍼바이저 레이어 업데이트가 이뤄질 때까지 IaaS 공유 인프라는 특히 취약하기 때문이다.
기업들은 클라우드 제공업체가 이러한 패치 작업을 수행했는지 확인하거나, 수 행 시점을 파악하고 있어야 한다.
일부 클라우드 제공업체들 의 경우 VM 재부팅이 필요할 수 있다. AWS, 애저, 구글은 이미 패치 작업을 완료했다.
데이터 센터 내 가상 데스크톱 인프라(VDI) 서버가 네트워 크에서 격리돼 있지 않은 경우 패치는 반드시 필요하다.
이들 은 본질적으로 데이터 센터에서 운영되는 데스크톱이기 때문 이다. 우선 펌웨어 업데이트를 한 후, 하이퍼바이저 패치를 완료해야 한다.
그리고 모든 VM 내의 모든 OS를 패치해야 한다. 데스크톱, 노트북, 워크스테이션 역시 패치가 필요하 다.
자바스크립트를 이용해 사용자 모르게 브라우징되는 드 라이브 바이 브라우징(drive-by browsing)을 통해 정체불 명의 코드가 유입될 위험이 있기 때문이다.
대부분의 경우 고 객들은 소프트웨어 스택을 먼저 업그레이드 한 다음 펌웨어 업그레이드를 진행하는데, 이는 펌웨어 업데이트가 가능할 때까지BR>칩셋 버전이 공격에 취약한 경우, 자바스크립트 기반 공격 의 위험을 처리하기 위해 스마트폰 OS나 브라우저를 업데이 트해야 한다.
iOS 버전이 11.2.2 이상이고, 안드로이드 버전이 2018년 1월 이후의 보안으로 업데이트 됐는지를 확인해야 한 다.
펌웨어를 업데이트 한 후에는 데이터 센터에 사용된 가상 화 레이어를 패치해야 한다.
그 다음 퍼블릭 IaaS 혹은 프라이 빗 데이터 센터와 같은 외부 서버의 OS를 패치하고, 마지막으 로 IaaS, 프라이빗 데이터 센터, VMs과 같은 내부의 서버, 네 트워크, 스토리지, 보안기기, IoT 등을 확인해야 한다.
◆ 패치가 항상 옳은 것은 아니다
정보보안책임자는 패치를 하지 않는 방안도 고려해야 한 다.
대표적으로 구 시스템에서 패치가 충분치 않은 경우가 이 에 해당된다.
네트워크나 스토리지 컨트롤러 등 위험의 감소 가 성능 저하를 상쇄하지 않을 경우도 마찬가지이다.
잘 관리 된 일부 서버 중에서도 향후 패치가 확실하게 수용 가능한 파 급력을 가질 때까지 성능 보호를 위해 패치를 건너뛰는 경우 가 있다.
펌웨어 업그레이드가 불가능하고 OS와 하이퍼바이 저 업데이트는 가능할 경우, 기업은 OS와 하이퍼바이저를 패 치해야 한다. 스펙터 변종 2와 같이 3가지 변종 중 하나만이 펌웨어 업데이트를 필요로 한다.
OS 벤더들 역시 항상 패치를 권장하는 것은 아니다.
예를 들어 마이크로소프트의 경우, 서버가 정체불명 혹은 신뢰할 수 없는 코드를 실행하지 않는 한 관리자의 추가적인 대응 행 동이 요구되지 않는다고 발표한 바 있다.
레드햇도 관리자가 직접 성능 보호를 위해 패치 적용 여부를 선택하도록 했다.
◆ 강력한 시스템 운영 관리가 필요하다
패치되지 않았거나 부분적으로 패치된 시스템의 경우, 다 양한 대응(mitigating controls)으로 위험을 줄일 수 있다.
가장 중요한 점은 신뢰할 수 없는 정체불명의 코드를 디바 이스에 심는 기능을 제한하는 것이다.
정체불명의 코드를 제 한함으로써 위험의 상당 부분을 줄일 수 있다.
스펙터·멜트 다운 공격을 하기 위해서는 로컬 코드 실행이 필요하기 때문 이다.
즉, 모든 시스템이 서버 워크로드에 대해 ‘자동거부방식’을 택해야 한다.
예를 들어
▪ 제한된 물리적·논리적 로컬 네트 워크 액세스
▪ USB 포트 비활성화
▪ 런타임 보호를 위한 애 플리케이션 제어 및 화이트리스팅 설치
▪ 다형성 OS 생성 통 한 고급 커널 및 어드레스 공간 보호
▪ 강력한 변경 관리 제어 기능을 갖춘 관리 액세스용 PAM
▪ 외부 인터넷 연결 비활성 화
▪ 로컬 브라우저 및 이메일 계정 비활성화
▪ 웹서버, CWPP 에이전트와 같은 지원 소프트웨어와 OS의 다른 레이 어에 패치 적용
▪ CWPP 최신 버전 여부 확인
▪ 네트워크 기 반 공격 방어를 위한 네트워크 혹은 호스트 기반 IPS 보호 실 행 등을 활용할 수 있다.
향후 추가적인 대응을 위한 노력이 필요
이와 같은 문제점은 과거에도 존재해왔으며, 이번 사태도 그 연장선상에 있다.
새로운 유형의 공격을 발견하기 위해 추 측실행과 관련된 설계상의 결함에 대한 추가 연구가 필요하다.
향후 몇 년에 걸쳐 하이퍼바이저, OS, 브라우저와 펌웨어 업그레이드 등 추가적인 패치가 나와야 한다.
스펙터·멜트 다운은 새로운 차원의 취약점을 드러냈고, 이는 시작에 불과 하다. 스펙터·멜트다운 연구자들도 이와 같은 의견에 동의 한다.
보다 넓게 봤을 때, 추측실행으로 정보가 누출될 수 있는 다른 방법들이 있기 때문에 메모리 캐시에 국한된 대처 방안 만으론 충분치 않을 가능성이 높다.
물론 추측실행은 전원과 전자기 신호 등 기존 부수 채널에도 영향을 미치므로, 지금 언급되는 소프트웨어나 마이크로코드에 대한 대처방안은 향 후 연구로 나아가는 과도기적 수순으로 보는 것이 적절하다.
완전한 결함 차단을 위해서는 새로운 하드웨어가 필요하며, 이 하드웨어의 상용화는 다소 시일이 걸릴 것이다.
시스템 인벤토리가 향후 대응을 위한 노력의 주요 로드맵 역할을 하게 되는 이유가 여기에 있다.
가트너 연구는 그간 모든 유형의 취약점을 겨냥한 공격 위험에 대응하기 위해 서 버 상에서 애플리케이션 제어와 화이트리스팅을 사용할 것을 권장해 왔다.
아직 완료하지 않았다면, 지금 물리적, 가상, 퍼 블릭 클라우드, 컨테이너 기반 등 서버 워크로드의 종류에 관 계없이 서버 워크로드 보호를 위한 ‘자동거부방식’을 적용해 야 할 시점이다.
이는 표준 관행으로 자리 잡아야 하며, 2018 년 모든 보안과 리스크 관리 책임자들이 가장 우선시해야 할 부분이다.
출처 : 디비가이드넷
ISMS 인증컨설팅 | 취약점 진단 및 모의 침투 | 보안솔루션 공급
