꼰머의 보안공부

1. 개요

- 아마존 웹 서비스 (AWS)에서 새로운 유형의 네임 혼동 (Name Confusion) 공격 ‘whoAMI’를 발견 [1]

- 아마존 머신 이미지 (Amazon Machine Image, AMI)의 이름 혼동을 악용해 원격 코드 실행을 통해 AWS 계정에 침투할 수 있음

- 개발자가 AWS에서 AMI를 검색할 때 ‘소유자 (owner)’ 속성을 지정하지 않을 경우, 공격자가 악성 AMI를 통해 피해자의 계정에 침투할 수 있음

2. 주요 내용

- 누구나 카탈로그에 AMI를 게시할 수 있음

> 사용자는 owners 속성을 지정해 AMI 게시자에 대한 정보를 확인할 수 있으며, 해당 속성을 지정하는 것은 중요함

"describe-images" 명령에서 "--소유자" 매개변수를 생략하면 소유권에 관계없이 실행 권한이 있는 모든 이미지가 반환됩니다.

- owners로 허용되는 값

※ --owners 속성을 표의 값과 함께 사용하면 whoAMI 이름 혼동 공격에 취약하지 않음

- owners 값이 생략된 경우 AMI ID를 찾는 과정

- 공격자는 [사진 2]를 악용해 다음과 같이 공격을 진행

- 다음 조건이 충족되면 공격에 쉽게 노출

① name 필터만 사용

> owner, owner-alias, owner-id 등의 파라미터를 지정하지 않을 경우

② 'most_recent=true' 옵션 사용

> 최신 이미지를 자동으로 선택하도록 설정한 경우

③ 자동화된 이미지 검색

> Terraform과 같은 IaC (Infrastructure as Code) 도구가 최신 이미지를 자동으로 선택하도록 설정한 경우

- AWS 및 HashiCorp (Terraform 개발사)의 대응

① AWS : Allowed AMIs

>  신뢰할 수 있는 AMI만 사용할 수 있도록 허용 목록을 설정할 수 있는 보안 통제 장치

② HashiCorp : ‘most_recent=true’ 옵션 관련 보안 강화

> owner 필터 없이 사용할 경우 경고 메시지를 출력하도록 조치

> 25년 출시되는 Terraform 6.0.0 버전부터는 경고를 오류로 격상할 예정

- DataDog은 whoAMI 스캐너 공개 [3]

> 현재 실행 중인 EC2 인스턴스를 감사

> 공개 계정과 검증되지 않은 계정 모두에서 실행된 AMI가 있는지 알려줌

3. 참고

[1] https://securitylabs.datadoghq.com/articles/whoami-a-cloud-image-name-confusion-attack/
[2] https://www.youtube.com/watch?v=l-WEXFJd-Bo
[3] https://github.com/DataDog/whoAMI-scanner
[4] https://www.dailysecu.com/news/articleView.html?idxno=163773

1. 개요

- 세계 3대 BIOS 회사(Insyde, AMI, Phoenix)에서 만든 제품 전부에 영향을 주는(세계 PC 95%) 취약점이 발견 [1]

> 여러 취약점들을 통합한 이름으로 LogoFAIL 취약점으로 명명

> IBV(Independent BIOS Vendor)는 UEFI 펌웨어가 포함된 최신 시스템에 대해 다양한 형식의 이미지 파서를 제공

> 사용자 정의 로고를 통해 입력을 지정할 수 있으며, DXE 단계에서 취약점이 발생하는 것으로 판단됨 

- 취약점을 악용하는데 성공할 경우 엔드포인트에 존재하는 모든 보안 장치들이 무력화되며, 높은 권한을 획득

1.1 UEFI (Unified Extensible Firmware Interface) [2][3]

- 통합 확장 펌웨어 인터페이스
- 운영 체제와 플랫폼 펌웨어 사이의 소프트웨어 인터페이스를 정의하는 규격
- BIOS를 대체하는 펌웨어 규격으로, 16비트 BIOS의 제약 사항 극복 및 새로운 하드웨어의 유연한 지원을 위해 64비트 기반으로 개발

1.2 ESP (EFI system partition) [2][4]

- PC가 부팅되면 UEFI는 EFI 파티션에 저장된 파일을 로드하여 운영 체제 및 기타 필요한 유틸리티를 시작

1.3 DXE (Driver Execution Environment) [2][5]

- 대부분의 시스템 초기화가 수행

2. 취약점

- 3대 BIOS는 다양한 이미지 파서를 제공

> 이미지 파서는 부팅이나 BIOS 설정 중에 로고를 표시할 수 있도록 하기 위해 존재

> 벤더사는 사용자가 파서에 입력을 지정할 수 있는 사용자 정의 기능을 제공하며, 해당 기능이 취약점을 야기

※ Insyde 기반 펌웨어: BMP, GIF, JPEG, PCX, PNG, TGA 파서
※ AMI 기반 펌웨어: 단일 BMP 파서, BMP, PNG, JPEG, GIF 파서
※ Phoenix 기반 펌웨어: BMP, GIF, JPEG 파서

※ 제공하는 파서는 다를 수 있음

- 침해된 이미지들을 EFI 시스템 파티션(ESP)이나 서명이 되지 않은 펌웨어 업데이트 영역에 삽입해 악성코드 실행

> 시스템 부팅 과정 자체를 공격자가 하이재킹 하는 것

> Secure Boot, Intel Boot Guard와 같은 보안 장치를 우회할 수 있으며, OS 단 밑에서 공격을 지속시키는 것도 가능

※ Secure Boot, Intel Boot Guard : 부팅시 펌웨어의 유효성 즉, 펌웨어의 서명을 확인해 유효한 경우 부팅을 시작 (서명을 이용해 부팅 프로세스를 검증) [6][7]

2.1 취약점 상세

- 일반적으로 로고는 펌웨어 볼륨에서 직접 읽어짐

> 볼륨은 하드웨어 기반 자체 검사 부팅 기술(예: Intel Boot Guard)로 서명 및 보호

> 공격자는 해당 섹션에 서명하는 데 사용된 OEM 캐인 키가 아닌 한 사용자 정의 로고를 사용할 수 없음

> OEM별 사용자 정의를 통해 로고를 사용할 수 있으며, 공격자 또한 동일한 방법이 사용 가능

※ OEM(Original Equipment Manufacturing): '주문자 상표 부착 생산', 주문자는 제품 계발 및 참여만 직접 하고, 생산은 하청업체나 다른 생산 라인 등에 외주

- OEM별 사용자 정의 로고를 읽는 방법은 다음과 같음

① 로고는 “\EFI\OEM\Logo.jpg” 와 같이 ESP의 고정 위치에서 읽혀짐

② OEM/IBV는 사용자 정의 로고를 설치하고 OS에서 캡슐을 플래시할 수 있는 공급업체별 통합 도구를 제공

③ NVRAM 변수에는 로고를 읽는 ESP 경로가 포함

④ 로고 자체는 압축된 형태로 NVRAM 변수 내에 저장

> 로고가 포함된 펌웨어 영역이 Boot Guard에 포함되지 않으면 공격에 악용될 수 있음

- 분석 결과 Insyde의 PNG 파서를 제외한 모든 파서는 하나 이상의 취약점이 존재

> 총 29개 중 15개는 임의 코드 실행을 야기

2.2 원인 및 PoC

- 근본적인 원인은 입력 데이터에 대한 유효성 검사의 부족

① Insyde 의 BMP 파서 버그

> RLE4/RLE8 압축을 지원하는 코드에서 취약점 발생

> PixelHeight (공격자 제어 가능) 및 변수 i 가 0 일 때 발생

> 이 경우 변수 Blt 는 BltBuffer [ PixelWidth * -1] 의 주소 로 초기화

> 공격자는 Blt를 BltBuffer 아래의 임의의 주소로 임의로 설정할 수 있음

② AMI 펌웨어 PNG 파서 버그

> 첫 번째 버그: 실패 시 NULL을 반환하는 "EfiLibAllocateZeroPool" 함수 의 반환 값에 대한 검사 누락

> 두 번째 버그: 할당 크기를 나타내는 32비트 정수의 정수 오버플로

※ 공격자가 변수 "PngWidth"를 큰 값으로 설정시 2를 곱한 결과가 오버플로되어 작은 값 할당(예: 0x80000200 * 2 = 0x400)

3. 참고

[1] https://binarly.io/posts/finding_logofail_the_dangers_of_image_parsing_during_system_boot/
[2] https://en.wikipedia.org/wiki/UEFI
[3] https://namu.wiki/w/UEFI
[4] https://en.wikipedia.org/wiki/EFI_system_partition
[5] https://uefi.org/specs/PI/1.8/V2_Overview.html
[6] https://learn.microsoft.com/ko-kr/windows-hardware/design/device-experiences/oem-secure-boot
[7] https://github.com/corna/me_cleaner/wiki/Intel-Boot-Guard
[8] https://www.boannews.com/media/view.asp?idx=124406&page=4&kind=1