전 세계 서버 대부분에 영향을 줄 수 있는 UEFI 펌웨어 코드 실행 취약점을 Ars Technica가 보도했어요. “서버 취약점이야 매일 나오는데?” 싶을 수 있지만 이번 건 좀 달라요. 운영체제나 애플리케이션이 아니라, 그보다 훨씬 아래에서 컴퓨터를 깨우는 펌웨어에서 나온 문제거든요. 구체적인 CVE 번호, 영향받는 펌웨어 버전, 제조사별 패치 일정은 원문과 각 서버 제조사의 보안 공지를 꼭 확인해 주세요. 여기서는 이런 취약점이 왜 유독 무서운지, 실무에서 뭘 챙겨야 하는지 풀어볼게요.
UEFI가 뭐냐면
서버 전원 버튼을 누르면 운영체제가 바로 뜨는 게 아니에요. 그 전에 메인보드에 들어 있는 펌웨어가 CPU, 메모리, 디스크 같은 하드웨어를 하나씩 깨우고 점검해요. 그다음 부트로더를 찾아서 운영체제에 바통을 넘겨주거든요. 예전엔 이걸 BIOS라고 불렀고, 지금은 그 후계자인 UEFI가 표준이에요.
건물로 비유하면 UEFI는 기초 공사이자 정문 경비실이에요. 그런데 UEFI는 부팅이 끝나도 완전히 퇴장하지 않아요. SMM(시스템 관리 모드) 같은 일부 기능은 운영체제가 돌아가는 동안에도 커널보다 높은 권한으로 남아 있어요. 그래서 보안 업계에선 이 영역을 “링 -2”라고 부르기도 해요. 커널이 링 0이니까, 그보다 두 단계 아래에서 모든 걸 내려다보는 셈이죠.
펌웨어 취약점이 특히 위험한 이유
보안 솔루션이 보지 못해요. 백신이나 EDR은 운영체제 위에서 동작해요. 공격 코드가 그보다 아래에 숨어 있으면 찾아내기가 극도로 어려워요.
지워지지 않아요. 펌웨어는 디스크가 아니라 메인보드의 플래시 칩에 저장돼요. 그래서 디스크를 포맷하고 OS를 새로 깔아도 악성코드가 그대로 남을 수 있어요. 2018년 ESET이 찾아낸 LoJax가 실제 공격에서 확인된 첫 UEFI 루트킷이었어요. 2023년엔 최신 윈도우 11의 시큐어 부트까지 우회하는 부트킷 BlackLotus가 공개됐고요.
신뢰의 뿌리가 흔들려요. 시큐어 부트는 “검증된 코드만 부팅한다”는 약속인데, 그 검증을 맡은 펌웨어가 뚫리면 그 위의 보안 장치가 전부 의미를 잃어요.
왜 “대부분의 서버”일까
여기가 핵심이에요. 델, HPE, 레노버, 슈퍼마이크로 같은 서버 제조사는 펌웨어를 처음부터 직접 만들지 않아요. 인텔·AMD의 참조 코드, 오픈소스인 TianoCore EDK II, 그리고 AMI·Insyde·Phoenix 같은 독립 BIOS 벤더(IBV)의 코드를 가져와서 손보거든요. 모두가 같은 밀가루로 빵을 굽는 구조라, 밀가루에 문제가 생기면 브랜드와 상관없이 전부 영향을 받아요.
이런 일은 처음이 아니에요. 2023년 LogoFAIL 때는 부팅 로고 이미지를 처리하는 코드의 결함이 수많은 기기를 위협했어요. 2024년 PixieFail 때는 EDK II의 네트워크 부팅 코드에서 취약점 9개가 한꺼번에 나왔고요. 같은 해 PKfail은 “테스트용이니 믿지 말 것”이라고 적힌 시큐어 부트 키가 수백 개 모델에 그대로 실려 출하된 사실을 드러냈죠.
패치가 느릴 수밖에 없는 구조
펌웨어 패치는 긴 사슬을 거쳐요. 원천 코드를 고치면 IBV를 거쳐 서버 제조사로 가고, 제조사가 모델별로 펌웨어를 배포한 다음에야 고객이 적용할 수 있어요. 게다가 적용하려면 서버를 재부팅해야 해서, 운영 중인 장비는 미루기 일쑤예요. 지원이 끝난 구형 모델은 아예 패치가 안 나오기도 하고요. 그래서 공개되고 몇 년이 지나도 취약한 펌웨어가 현장에 남아 있는 경우가 흔해요.
업계도 이 문제를 알고 있어요. 구글, 마이크로소프트, AMD, 엔비디아가 함께 시작한 오픈소스 하드웨어 신뢰 루트(부팅 코드가 변조되지 않았는지 맨 처음 검증하는 부품) 프로젝트 Caliptra가 있어요. 펌웨어를 투명하게 공개하려는 coreboot, OpenBMC 같은 시도도 같은 흐름이고요.
한국 개발자·운영자를 위한 체크리스트
퍼블릭 클라우드만 쓴다면 펌웨어는 대부분 클라우드 사업자가 책임져요. 사업자의 보안 공지 정도만 챙기면 되죠. 하지만 한국엔 금융, 공공, 제조처럼 IDC나 사내 전산실에서 물리 서버를 직접 운영하는 곳이 아직 많잖아요. 그렇다면 이렇게 점검해 보세요.
- 자산 파악: 리눅스에서
sudo dmidecode -t bios로 펌웨어 버전을 확인하고, 서버 모델별 목록을 만들어 두세요. - 제조사 보안 공지 구독: 쓰는 제조사의 공지를 받아보세요.
fwupd를 지원하는 장비라면fwupdmgr get-updates로 업데이트를 확인할 수도 있어요. - BMC·IPMI 관리망 분리: 서버 원격 관리 포트는 절대 인터넷에 노출하지 말고 별도 관리망에 두세요.
- 시큐어 부트와 TPM 활용: 측정 부트를 켜 두면 부팅 과정이 단계별로 기록돼서 변조 흔적을 잡는 데 도움이 돼요.
- 펌웨어도 정기 패치에 포함: OS 패치처럼 펌웨어 업데이트도 점검 주기에 넣어 두세요.
마무리
한 줄로 정리하면, 보안의 맨 아래층이 흔들리면 그 위에 쌓은 모든 게 흔들려요. 여러분 회사에선 서버 펌웨어 업데이트를 누가, 얼마나 자주 챙기고 있나요? 혹시 “BIOS는 건드리면 안 되는 것”으로 여겨지고 있진 않나요?
🔗 출처: Hacker News