보안 / 오픈소스

리눅스 GRUB2 부트로더 결함, 대부분의 컴퓨터와 서버에서 안전 부팅 장애 발생

Lucian Constantin | CSO 2020.07.31
운영체제 유지보수 업체, 컴퓨터 제조업체, 보안 및 가상화 소프트웨어 공급업체가 현대 컴퓨터의 핵심 보안 기능 가운데 하나인 부팅 프로세스 무결성 확인을 우회하는 데 이용되는 취약점에 대응하기 위해 지난 몇 개월 동안 힘을 합쳤다. 이 결함은 GRUB2 리눅스 부트로더(bootloader)에 존재하지만 안전 부팅(Secure Boot)의 구현 원리상 윈도우와 다른 운영체제의 부팅 프로세스에도 작용할 수 있다.
 
ⓒ Getty Images Bank

이 취약점의 영향을 받는 모든 컴퓨터와 기기에 7월 29일 발표된 패치를 설치하기 위해서는 수동 테스트와 배포가 필요하고 대부분의 경우 시간도 많이 걸린다. 따라서 업데이트되지 않고 부팅 레벨의 악성코드와 무단 펌웨어 수정에 계속 취약한 채로 남아있는 시스템이 있을 것으로 예상된다. 


안전 부팅이란 무엇이고 어떻게 작동하는가?

안전 부팅은 운영체제가 초기화되고 실행 권한을 넘겨받기 전까지, 컴퓨터 부팅 프로세스와 관련된 모든 구성 요소의 무결성을 암호화된 형태로 확인하기 위한 표준 메커니즘이다. 안전 부팅은 모든 현대 컴퓨터에서 레거시 BIOS 펌웨어를 대체한 통합 확장 펌웨어 인터페이스(Unified Extensible Firmware Interface, UEFI)의 기능이다.

거의 모든 UEFI 구현에는 전체 플랫폼의 신뢰 루트를 구성하는 마이크로소프트의 루트 키가 포함된다. 이 키를 마이크로소프트 서드파티 UEFI 인증 기관(Certificate Authority, CA)이라고 한다. 컴퓨터에서 안전 부팅이 켜지면 모든 부팅 구성 요소가 이 CA에 연결된 키로 서명돼야 운영체제가 시작된다. 즉, 리눅스 배포판 역시 마이크로소프트가 서명한 부트로더가 필요하다는 의미다.

GRUB2(Grand Unified Bootloader version 2)는 대부분의 리눅스 시스템에 사용되는 표준 부트로더다. 많은 기능과 구성을 지원하는 복잡한 소프트웨어이므로 모든 리눅스 배포판은 자체 GRUB2 기반 부트로더를 유지 관리한다.

리눅스 공급업체는 GRUB 바이너리를 수정하거나 업데이트할 때마다 마이크로소프트에 재서명을 받는 번거로움을 피하기 위해 마이크로소프트에 “심(shim)” 부트로더라는, 훨씬 더 단순한 코드에 서명을 요청해 받은 다음 이 심을 사용해 GRUB을 확인하고 초기화한다. 심에는 일반적으로 리눅스 배포판이 제어하는 인증서가 포함돼 있다. 이를 통해 유지관리 업체는 신뢰 체인의 일부가 된 자체 인증서를 사용해 GRUB 바이너리와 다른 OS 구성 요소에 서명할 수 있는 재량을 확보한다.

컴퓨터에는 마이크로소프트 플랫폼 인증서가 내장된 UEFI가 기본적으로 포함된다. 이 인증서는 리눅스와 같은 다른 운영체제를 위해 마이크로소프트가 서명한 심 부트로더를 포함한 부팅 체인에 속하는 다른 구성 요소를 검증하는 데 사용된다. 이후 심 부트로더는 리눅스 배포판 유지보수 업체 스스로 서명한 전체 GRUB 기반 부트로더를 확인한다.


하나의 취약점이 전체 GRUB 감사 촉발

보안업체 이클립시움(Eclypsium) 연구진은 GRUB2가 grub.cfg라는 구성 파일의 내용을 파싱하는 방식에서 버퍼 오버플로우 취약점이 있음을 발견했다. GRUB 바이너리는 보통 서명이 되지만 구성 파일은 서명되지 않는다. 시스템 관리자가 여러 운영체제 선택 옵션이 있는 컴퓨터를 설정할 때 운영체제의 초기화 동작에 관한 여러 옵션을 변경하거나 부팅 항목을 추가하고자 하는 경우, 이 구성 파일을 편집해야 하기 때문이다.

공격자는 구성 파일에 특정 목적으로 만들어진 콘텐츠를 추가해 취약점을 악용하는 방법으로 운영체제가 시작되기 전에 신뢰된 부트로더의 컨텍스트에서 악성코드를 실행할 수 있다. 이를 통해 시스템에서 높은 권한과 지속성을 확보하고, OS와 커널에 대한 완전한 통제력을 얻게 된다. 부트 루트킷(boot rootkits) 또는 간단히 부트킷이라고도 하는 부팅 수준 공격은 10년 전 매우 흔한 공격이었으며 애초에 안전 부팅이 만들어진 가장 큰 이유 중 하나였다.

이런 공격은 여전히 존재하며 안전 부팅이 활성화되지 않은 시스템을 대상으로 공격할 수 있다. 예를 들어 페티야(Petya)와 낫페티야(NotPetya) 랜섬웨어 프로그램은 컴퓨터의 마스터 부트 레코드(Master Boot Record, MBR)를 암호화하는 것으로 알려졌다. FIN1이라는 이름을 사용하는 사이버 범죄 집단은 한 유틸리티를 사용해 시스템 볼륨 부트 레코드(Volume Boot Record, VBR)를 수정해 윈도우 또는 보안 소프트웨어가 완전히 초기화되기 전에 네메시스(Nemesis) 백도어를 시작한다.

안전 부팅은 완벽한 솔루션이 아니다. 과거의 특정 UEFI 구현에 존재했던 취약점은 공격자가 확인 과정을 건너뛸 수 있도록 했지만 일반적으로 공격의 범위는 특정 컴퓨터 제조업체나 UEFI 변형으로 제한됐다. 그러나 이클립시움에서 발견한 GRUB2 취약점은 GRUB 자체의 다목적성이 독이 되어 훨씬 더 광범위한 영향을 미칠 수 있다. 예를 들어 GRUB은 듀얼 부팅 또는 멀티 부팅 구성을 사용해 윈도우를 포함한 여러 운영체제를 초기화할 수 있다.

즉, 공격자는 윈도우 부트로더를 리눅스 배포판의 서명된 심과 취약점이 있는 GRUB2 버전으로 대체해 안전 부팅이 활성화된 윈도우 컴퓨터에 부트킷을 설치할 수 있다. 이후 GRUB2를 구성해 윈도우를 초기화하고 취약점을 악용해 지속성을 얻고 운영체제를 장악할 수 있다. 리눅스 심 부트로더와 GRUB2는 유효하고 UEFI 내부의 마이크로소프트 안전 부팅 키에 연결되므로 신뢰 체인이 그대로 유지된다.

공격자가 윈도우 부트로더를 GRUB2로 바꾸고 리눅스의 GRUB2 구성 파일을 수정하기 위해서는 시스템에 대한 관리자 권한이 필요하지만 안전 부팅은 이런 경우에도 부팅 프로세스의 무결성을 보호하도록 설계됐다.

이클립시움의 수석 연구원인 제시 마이클은 “처음부터 UEFI 안전 부팅의 명확한 설계 목표 중 하나는 이 유형의 공격에 대한 보호다. 공격자가 시스템 관리자 권한을 획득한 경우에도 마찬가지”라며, “관리자는 시스템에 대한 물리적 접근을 입증하지 않고는 안전 부팅을 끌 수 없다. UEFI BIOS로 들어가서 BIOS 옵션을 선택하면 안전 부팅을 끌 수 있지만 운영체제 내의 런타임에서는 그렇게 할 수 없어야 한다”라고 말했다.

이클립시움이 발견한 취약점의 식별 이름은 CVE-2020-10713이며 공통 취약점 등급 시스템(CVSS) 등급은 8.2(높음)지만 그게 전부가 아니다. 이클립시움이 비공개로 이 취약점을 보고한 후 오라클, 레드햇, 캐노니컬, VM웨어의 보안 팀이 GRUB2 코드베이스에 대한 보안 감사를 실시했는데, 그 결과 10여 개의 다른 취약점과 위험한 코드 동작이 발견되어 수정됐다. 이 가운데 일부에는 CVE 식별자가 부여됐지만(CVE-2020-14308, CVE-2020-14311, CVE-2020-14309, CVE-2020-14310) 나머지에는 부여되지 않았다.


안전 부팅 신뢰 철회 문제

이 코드 검토가 필요했던 이유는 취약한 GRUB2 버전에서 신뢰를 철회하는 작업은 업계의 대대적인 협업이 필요한, 복잡한 프로세스이기 때문이다. 수개월에 한번씩 새 결함이 발견될 때마다 신뢰 철회를 하는 방법은 실용적이지 않다. 리눅스 배포판은 패치된 GRUB2 버전을 사용하도록 부트로더를 업데이트하겠지만, 시스템 관리자 액세스 권한을 가진 공격자가 패치된 버전을 심 부트로더에 포함된 인증서로 서명된 이전의 취약한 버전으로 대체하는 것을 어떻게 막을 것인가? 즉, 이 경우 다운그레이드 공격을 막으려면 어떻게 해야 하는가?

방법은 있지만 그리 간단하지 않다. UEFI 안전 부팅 메커니즘에는 dbx라는 철회 목록이 있는데, 여기에는 유효한 인증서로 서명되었는지 여부에 관계없이 블랙리스트로 지정된 부트로더 바이너리 목록이 포함된다. 이 목록은 UEFI 펌웨어의 위치와 동일한 플래시 메모리 칩에 저장되지만 업데이트 요청이 정상적인지 확인하기 위해 암호화 확인 및 검증을 사용한다.

모든 기존 리눅스 심 부트로더 또는 심을 통하지 않고 직접 서명된 GRUB 바이너리는 영향을 받는 모든 컴퓨터 또는 기기에서 이 철회 목록에 추가돼야 한다. 이클립시움 연구진에 따르면, 이 철회 목록에는 약 200가지 항목이 있다. 심이 블랙리스트에 오른 리눅스 배포판은 마이크로소프트가 서명한 새 심을 받아 설치 프로그램과 심, GRUB2 부트로더를 업데이트해야 한다.

우분투를 유지 관리하는 캐노니컬, 그리고 데비안은 예외다. 두 업체는 중간 인증서를 사용해 자체 UEFI 신뢰 CA 인증서에 연결된 부트로더에 서명하기 때문이다. 이 두 기업은 중간 인증서를 철회해서 블랙리스트에 올리고 새 인증서를 만들어 이 인증서로 새 부트로더에 서명하기만 하면 된다.

마이클은 “한 가지 문제는 이 작업의 범위가 매우 넓고 연관된 당사자가 상당히 많다는 것”이라며, “지금까지 확인된, 모든 배포판과 영향을 받는 공급업체가 포함된 조정 그룹 중 하나에만 70명 정도의 사람들이 있다. 상당히 골치 아픈 문제인 만큼 프로세스를 개선하고 기술적인 문제를 해결하기 위해 많은 노력을 기울였다. 여러 심 또는 여러 GRUB 인스턴스가 아니라 캐노니컬과 데비안처럼 하나의 인증서만 철회하면 되는 방식을 다른 공급업체에도 전파하기 위해 노력하고 있다. 그래야 다음에 같은 문제가 발생할 때 더 효과적으로 대처할 수 있다”라고 말했다.

또 다른 문제는 이 UEFI 안전 부팅 철회 메커니즘이 과거에는 그다지 많이 사용되지 않았고 시스템 또는 공급업체마다 구현에 차이점이 존재할 수 있다는 점이다. 마이크로소프트는 지난 2월 UEFI dbx를 업데이트해 안전 부팅을 우회하는 데 사용 가능한 카스퍼스키 레스큐 디스크(Kaspersky Rescue Disk)에 포함된 취약한 UEFI 로더를 블랙리스트로 지정하는 윈도우 업데이트를 출시했다. 이 업데이트가 일부 컴퓨터에서 부팅 실패를 유발하는 바람에 마이크로소프트는 어쩔 수 없이 업데이트를 중단했다.

새로운 방식에서는 마이크로소프트가 서명할 철회 업데이트는 선택 사항이 되고, 관리자가 모든 종류의 기기에서 테스트할 수 있도록 적어도 처음에는 수동으로 설치해야 한다. 

마이클은 본지와의 인터뷰에서 “엔터프라이즈 환경의 IT 관리자라면 업데이트를 푸시하기 전에 환경에 배포된 모든 모델에서 테스트해야 한다”면서, “호환성 문제가 없는지 확인해야 하고, 복구 디스크 또는 데이터 및 재해 복구 미디어, 또는 기업의 특정 애플리케이션이 포함된 설치 이미지와 같은 기준 이미지도 업데이트하고 푸시하기 전에 준비하는 단계가 필요하다. 현장에 무작정 업데이트를 푸시할 경우 시스템이 다운되고 복구 미디어가 부팅되지 않는 골치 아픈 상황이 발생할 수 있기 때문이다. 또한 데이터센터에서 안전 부팅이 켜져 있지만 네트워크 부팅을 하는 네트워크 부팅 시나리오도 있으므로 부팅 미디어 역시 업데이트해야 한다”라고 설명했다. editor@itworld.co.kr

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.