themalwareguardian/uefi-security-research-howyar-sysreturn-netcopyHowyar SysReturn NetCopy의 CVE-2024-7344 사후 분석 - 리버스 엔지니어링 노트, 취약한 바이너리, 벤더 서신, 그리고 CVE-2026-79298(BOOTia32.efi의 RxPE 커스텀 PE 로더를 통한 IA-32 Secure Boot 우회)에 대한 개념 증명 도구.
Secure Boot라는 망토 아래에서, 어떤 아키텍처는 그것을 드러낸 취약점보다 더 깊이 가라앉는다. 어떤 바이너리는 폐기된다. 어떤 패치는 배포된다. 그러나 수면 깊은 곳에서는 오래된 습관이 흔적을 남긴다. 이것은 취약점이 공개되고, 패치되고, 잊힌 뒤에 남는 것이다.
이 저장소에 문서화된 발견 사항에는 **CVE-2026-79298**이 할당되었습니다.
조정된 공개 과정에서, 벤더는 CVE-2024-7344와 관련된 수정이 x64 부팅 경로만을 다루었다는 것을 확인했습니다. SysReturn NetCopy 기능의 일부로 배포된 BOOTia32.efi를 포함한 IA-32 부팅 경로는 원래 수정에 포함되지 않았습니다. 그 결과, 취약한 IA-32 구성 요소는 버전 11.3.034(2026년 7월)까지 상업적으로 계속 배포되었습니다.
전용 CVE 저장소는 전체 기술적 깊이 - 리버스 엔지니어링, 바이너리 분석, 벤더 서신, 재현 아티팩트, 그리고 개념 증명 도구 - 를 위해 이곳으로 다시 연결됩니다.
2026년 내내 나는 UEFI 보안에 깊이 빠져 있었다 - 부트킷 개발, Secure Boot 우회, 펌웨어 익스플로잇, CVE 분석, 공격 도구 개발, 연구 발표. 이것은 내가 전문화하기로 선택한 분야이며 매주 새로운 무언가를 가져다준다. 그 작업의 일부는 UEFI 구성 요소에서 알려진 CVE를 익스플로잇하는 것을 포함한다. 일부는 UEFI 부트로더를 배포하지만 공개적인 조사가 거의 이루어지지 않은 소프트웨어를 연구하는 것을 포함한다. 그리고 일부는 - 이 저장소가 문서화하는 부분은 - 내가 너무 자주 간과된다고 생각하는 질문을 던지는 것을 포함한다:
CVE 이후에 제품은 어떤 모습인가?
패치가 쏟아지는 동안이 아니다. 권고가 나온 그 주가 아니다. 18개월 후, 압박이 사라지고, 연구자들이 떠나고, 아무도 더 이상 지켜보지 않을 때.
이 저장소는 하나의 특정 제품 - Howyar SysReturn NetCopy - 에 대해 그 질문에 답하려는 나의 시도이다.
그리고 내가 발견한 것은 사람들을 놀라게 할 것이라고 생각한다.
보안 연구의 모든 것은 실마리를 충분히 따라가면 다른 무언가와 연결된다. 이 특별한 실마리는 직장에서 시작되었다. 우리는 특정 범주의 환경 - 교육 센터 - 에 대한 UEFI 및 부트킷 공격의 실제 위험을 분석하는 임무를 맡았다. 틈새처럼 들린다. 그렇지 않다.
이 분야 밖의 대부분의 사람들이 완전히 인식하지 못하는 현실이 여기 있다. 중간 규모 도시에서는 학교 전체에 70,000대 이상의 공유 기기가 쉽게 배포될 수 있다 - 8세에서 15세 사이의 학생들이 사용하는 노트북과 워크스테이션으로, 그 규모에서의 Windows 라이선스 비용이 종종 감당하기 어렵기 때문에 Linux 배포판을 실행한다.
이제 스스로에게 물어보라: 그 기기 중 몇 대가 Secure Boot가 제대로 활성화되어 있는가? 대부분의 장소에서 솔직한 답은 매우 적다는 것이다. 그리고 그 이유는 태만이 아니다. 그것은 운영상의 현실이다.
Linux 환경에서 Secure Boot를 제대로 활성화한다는 것은 모든 커널에 서명하는 것을 의미한다. 모든 커널 업데이트 - 그리고 최근 몇 년간 Linux 커널 취약점이 빠르게 나오고 있다 - 는 모든 단일 기기에 배포할 새로운 서명된 이미지를 필요로 한다. 이는 조정된 업데이트 파이프라인, 키 관리 인프라, 훈련된 인력, 그리고 수십 개 위치에 분산된 수천 개의 엔드포인트에 걸친 지속적인 유지 관리를 의미한다.
그러한 자원을 가진 조직에게는 관리 가능하다. 대부분의 학군에게는 그렇지 않다. 그 규모에서 제대로 하기에는 사람도, 예산도, 도구도 충분하지 않다. 그래서 Secure Boot는 비활성화된 채로 남는다.
BIOS 비밀번호는 설정되지 않는다 - 제한된 인력으로 70,000대의 기기에서 이를 교체하는 것은 비현실적이기 때문이다. 그리고 그 기기들은 펌웨어 수준에서 완전히 노출된 채로, 매일 수백 명의 학생들이 사용한다.
보안 관점에서 이것이 실제로 의미하는 바는, UEFI 익스플로잇을 이해하는 공격자가 OS가 로드되기 전에, 어떤 보안 소프트웨어가 시작되기 전에, 어떤 보호 메커니즘도 개입할 기회를 갖기 전에 펌웨어 계층에서 그 기기 중 하나를 침해할 수 있다는 것이다. 부트킷은 재부팅을 넘어, OS 재설치를 넘어, 모든 것을 넘어 지속될 수 있다. 나는 내가 그런 종류의 도구를 직접 개발하기 때문에 이것을 안다. 그 기술들은 존재한다. 그것들은 이론적이지 않다.
이것은 알려진 문제이다. 널리 인정되고 있다. 그리고 그것은 곧 사라지지 않을 것이다.
그 문제에 대한 운영상의 대응 - 학교가 적절한 Secure Boot 대신 실제로 배포하는 것 - 은 복구 소프트웨어이다.
아이디어는 간단하다: 학생이 세션 중에 무엇을 하든, 다음 재부팅 후 모든 것이 알려진 깨끗한 상태로 돌아간다. 멀웨어, 구성 변경, 손상된 시스템 파일, 실수로 또는 의도적으로 삭제된 데이터 - 사라진다. 이는 유지 관리 비용을 극적으로 줄이고 관리자가 모든 기기에 완벽한 펌웨어 수준 보안 제어를 갖출 필요 없이 공유 기기를 관리할 수 있는 방법을 제공한다.
우리가 이러한 환경에서 어떤 제품이 사용되는지 평가하기 시작했을 때, 여러 이름이 나왔다. 그중 하나가 Howyar SysReturn이었다 - 교육 배포용으로 특별히 설계된 대만 제품으로, 학교 컴퓨터 실습실, 공유 워크스테이션, 대규모 관리 환경을 명시적으로 지원한다.
그 이름을 본 순간, 나는 내가 정확히 무엇을 하고 싶은지 알았다.
2025년 1월, ESET Research는 CVE-2024-7344 - SysReturn 및 동일한 코드베이스를 기반으로 구축된 여러 다른 복구 제품에 영향을 미치는 Secure Boot 우회 - 의 공개를 발표했다.
그 취약점은 깊이 좌절스러운 방식으로 우아했다. Microsoft가 서명한 UEFI 애플리케이션 - 펌웨어가 신뢰하고, Secure Boot가 활성화된 상태에서도 실행될 수 있는 - 은 자체 커스텀 PE 로더를 완전히 처음부터 구현했다. Secure Boot 서명 검증을 강제하는 표준 UEFI LoadImage 및 StartImage 함수를 사용하는 대신, cloak.dat라는 파일에서 EFI 바이너리를 수동으로 파싱하고 실행했다. 단일 바이트 키로 XOR 암호화되었다. 서명 검사가 없다. 그 파일 안에 무엇이 있든 완전한 펌웨어 수준의 신뢰로 실행되었다.
Microsoft는 2025년 1월 Patch Tuesday 업데이트에서 취약한 바이너리를 폐기했다. 보안 업계는 다음 일로 넘어갔다. 그러나 나는 계속 그것에 대해 생각했다.
취약점 자체가 해결되지 않았기 때문이 아니다 - ESET은 그것을 철저히 문서화했고 폐기는 명확했다. 나를 계속 끌어당긴 것은 다른 질문이었다. 시간이 지나야만 답할 수 있는 종류의 질문:
그들은 실제로 고쳤는가? 아니면 그저 압박을 피해갔는가?
차이가 있다. 진정한 수정은 근본 원인을 다룬다 - 이 경우, Secure Boot를 우회하는 커스텀 PE 로더의 사용이다. 우회책은 근본적인 아키텍처를 그대로 둔 채 즉각적인 문제를 사라지게 만든다.
나는 Howyar가 어느 쪽을 했는지 알고 싶었다.
나는 Howyar Technologies에 직접 연락하여 전문적인 조달 평가를 위한 SysReturn 평가판 사본을 요청했다 - 이는 애초에 이 연구를 만들어낸 전문적 맥락을 고려할 때 전적으로 정확했다.
벤더는 협조적이고 신속했다. 그들은 전체 체험 라이선스, 매뉴얼, 튜토리얼 비디오, 그리고 완전한 평가 패키지를 제공했다. 그들은 또한 Secure Boot 호환성에 대한 상세한 질문에 답변했는데, 이는 나중에 내가 발견한 것과 직접적으로 관련이 있는 것으로 밝혀졌다.
그 모든 서신은 편집 없이 이 저장소에 포함되어 있다.
여기서 기술적 세부 사항을 스포일러하지 않겠다 - 그것은 Vulnerability Research 디렉터리의 역할이며, 나는 그것을 전체적으로 읽어볼 것을 진심으로 권한다. 그러나 이 정도는 말하겠다.
UEFI는 그 자체로 하나의 세계이다. 그 안에서 일하는 개발자는 적다. 애플리케이션 소프트웨어나 웹 서비스를 위해 존재하는 보안 검토 프로세스는 펌웨어 구성 요소까지 일상적으로 도달하지 않는다. 나쁜 관행은 일단 자리 잡으면 지속되는 경향이 있다 - 악의 때문이 아니라, 생태계가 작고, 조사가 드물며, 잘못했을 때의 결과가 주의를 기울이는 소수의 연구자를 제외하고는 종종 보이지 않기 때문이다.
내가 SysReturn v11.2.031 - Microsoft의 폐기 이후 15개월 이상 지난 2026년 4월에 출시된 - 에서 발견한 것은 바로 그러한 역학의 명확한 예이다.
근본 원인은 고쳐지지 않았다. 취약한 바이너리는 교체되지 않았다. 바뀐 것은 운영상의 것이었다: Secure Boot가 활성화된 시스템을 위한 다른 부팅 경로로, 나머지 거의 모든 것을 그대로 두었다.
커스텀 PE 로더 - 바이너리 자체의 디버그 문자열에 이름이 나오는 RxPE 구성 요소 - 는 2026년 4월 릴리스에 존재하며, 2024년에 ESET이 분석한 버전에서 작동했던 것과 동일하게 작동한다.
Howyar가 2026년 4월에 배포한 바이너리의 Authenticode 해시는 Microsoft가 2025년 1월에 폐기한 해시와 바이트 단위로 일치한다.
나는 그것이 중요하다고 생각한다. 사람들이 그것에 대해 알아야 한다고 생각한다. 그리고 이 저장소의 기술 문서는 이 발견을 직접 검증하고자 하는 누구나 그렇게 할 수 있을 만큼 충분히 상세하다고 생각한다.
| 디렉터리 | 설명 |
|---|---|
📚 00 Manual | Howyar가 제공한 벤더 매뉴얼, 브로셔, 공식 제품 문서 |
📦 01 Binaries | 분석을 위해 평가 패키지에서 추출한 주요 바이너리 |
📬 02 Disclosure | 평가 과정에서 Howyar Technologies와 주고받은 전체 이메일 서신 |
🔬 03 Vulnerability Research | 리버스 엔지니어링, 바이너리 분석, Authenticode 검증, ALRM 형식 분석, 스크립트, 기술적 발견 |
기술적 이야기 - BOOTia32.efi의 전체 리버스 엔지니어링, ALRM 페이로드 형식, XOR 복호화, RxPE 커스텀 PE 로더, 폐기된 바이너리와의 Authenticode 해시 일치, 그리고 Howyar가 실제로 바꾼 것과 그대로 둔 것에 대한 분석 - 는 모두 다음에 있다:
➡️ 취약점 연구
"패치" 이후 분석을 시작하기 전에 CVE 자체에 대한 맥락을 원한다면, ESET 권고가 좋은 참고 자료이다. 나는 또한 CVE-2024-7344를 문서화한 저장소와 관련 UEFI 취약점을 더 자세히 유지 관리하고 있다.
읽기 시작하라. 망토는 여전히 거기에 있다.
