
MSI Center – 단 몇 초 만에 SYSTEM 권한을 획득하는 방법
요약
MSI Center 소프트웨어에서 SYSTEM 권한을 획득할 수 있는 심각한 취약점을 분석한 기술 리포트입니다. Named Pipe 보안 설정 오류를 통해 일반 사용자가 최고 권한을 탈취하는 과정을 상세히 다룹니다.
핵심 포인트
- MSI Center의 'Notebook Foundation' 서비스 내 Named Pipe 취약점 발견
- Inno Setup 패키징 및 C#/.NET 파일 디컴파일을 통한 분석 과정
- 부적절한 Named Pipe 보안 설정으로 인한 권한 상승 가능성
- LocalSystem 권한을 이용한 레지스트리 및 WMI 조작 위험
MSI Center - 단 몇 초 만에 SYSTEM 권한을 획득하는 방법
AMD와 ASUS의 OEM 소프트웨어 모두에서 심각한 취약점을 발견한 후, 저는 더 많은 게이밍 제품에서 문제를 찾아 범위를 넓히고 싶었습니다.
결국 MSI Center로 결정했는데, 이 소프트웨어는 MSI의 모든 노트북과 완제품 데스크톱에 사전 설치되어 있는 것으로 보였기 때문입니다. 이는 제가 발견한 어떤 취약점이라도 광범위한 영향을 미칠 가능성이 높다는 것을 의미합니다.
다운로드 및 추출
이 과정의 첫 번째 단계는 항상 오프라인 설치 프로그램(offline installer)을 다운로드하는 것입니다.
이러한 기업 중 상당수는 지원되지 않는 하드웨어에서 설치 프로그램이 실행되는 것을 차단하거나, 아주 적은 수의 소프트웨어 설치만 허용합니다.
오프라인 설치 프로그램 사본을 확보했다면, Detect-It-Easy를 통해 실행해 보고 운에 맡겨야 합니다. 운이 좋다면 MSI Center를 패키징하는 데 어떤 소프트웨어가 사용되었는지 알려줄 수도 있습니다.
저희의 경우 운이 좋았고, MSI Center가 Inno Setup이라는 것을 사용하여 패키징되었다는 정보를 얻었습니다.

이러한 상황을 위해 특별히 만들어진 innoextract라는 도구가 있습니다.

설치 프로그램과 그 안에 포함된 .appxbundle(단순한 .zip 파일입니다)을 추출한 후에는 실행 파일(executables)을 디컴파일(decompile)할 차례였습니다.
디컴파일
DLL을 포함하여 총 170개의 실행 파일이 있었으며, 그중 대부분은 C#으로 작성되었습니다. 이를 위해 저는 ilspycmd를 사용하여 모든 파일을 디컴파일하는 bash 스크립트를 만들었습니다.
find . ( -name "*.exe" -o -name "*.dll" ) -exec file {} + | grep Mono | wc -l
find . ( -name "*.exe" -o -name "*.dll" ) -exec file {} + | grep -v Mono | wc -l
C++로 작성된 나머지 파일들에 대해서는, 가장 흥미로워 보이는 상위 약 10개의 파일을 선택하여 IDA에 넣은 다음, 전체 디컴파일 결과를 .c 파일로 내보냈습니다.
이 모든 과정을 거친 후, 저는 개별적으로 하나씩 살펴보기에는 파일이 너무 많다는 결론에 도달했습니다. 대신, 공통적인 약점을 검색하고 무언가를 찾을 수 있기를 바랄 수밖에 없었습니다.
제가 grep(검색)했던 것 중 하나는 CreateNamedPipe였습니다.
(Named Pipe(이름 있는 파이프)는 컴퓨터 상의 서로 다른 프로세스들이 서로 통신할 수 있는 방법입니다.)
취약점 (The vulnerability)
MSI의 ‘Notebook Foundation’ 서비스는 부팅 시 인증된 사용자라면 누구나 상호작용할 수 있는 Named Pipe를 생성합니다.
CreateNativePipeSecurity("D:(A;OICI;GRGW;;;AU)(A;OICI;GA;;;BA)");
CreateNamedPipe("\\.\\pipe\\MSI_SERVICE_2", PIPE_ACCESS_DUPLEX);
이 서비스는 다음과 같은 명령들을 트리거할 수 있도록 제공합니다:
-
Handshake (핸드셰이크)
-
다음 명령들을 호출하거나 상호작용하려면, 사용자의 애플리케이션을 "등록(register)"해야 합니다. 임의의 클라이언트 이름만 제공하면 되며, 이 이름은 다른 명령을 호출할 때 인자로 전달됩니다.
-
Registry (레지스트리)
-
이를 통해
LocalSystem(최고 권한)으로서 모든 레지스트리 키를 읽고, 쓰고, 삭제할 수 있습니다. -
WMI (Windows Management Instrumentation)
-
이를 통해 시스템 하드웨어를 모니터링하고 시스템 설정(예: Windows Defender 설정 및 제외 항목)을 변경할 수 있습니다.
-
PC
-
REXE - 임의의 인자와 함께 모든 실행 파일(executable)을
LocalSystem권한으로 실행합니다. -
KEXE - 시스템 상의 모든 실행 파일을 종료합니다 (마찬가지로
LocalSystem권한으로 실행됩니다).
짐작하셨겠지만, 이 기능들은 (로컬 관리자 권한이 없는 사용자를 포함하여) 인증된 사용자에게 노출되기에는 믿기 힘들 정도로 위험한 도구들입니다.
악성코드가 이를 악용하여 Windows Defender를 비활성화하거나 시스템 수준의 권한을 획득할 수 있습니다.
PoC (Proof of Concept, 개념 증명)
역사적으로 MSI는 공격으로부터 보호하기 위해 주로 '은닉을 통한 보안(security by obscurity)'에 의존해 왔습니다. 그들은 파이프와 통신하기 위한 커스텀 프로토콜을 만들었으며, 모든 메시지는 3DES(오늘날의 기준으로는 구식이며 안전하지 않은 암호화 방식)를 사용하여 암호화되어야 했습니다.
MSI_SERVICE_2Named Pipe에 연결을 엽니다.- 무작위 문자열(예: ABCD123)을 사용하여 애플리케이션을 등록합니다.
PC:REXE를 암호화합니다.
3DES를 사용하여 명령어를 암호화하고 클라이언트 이름을 키 (key)로 사용합니다. - Notebook Foundation 서비스는 등록된 모든 클라이언트 이름을 시도하여 복호화에 성공할 때까지 무차별 대입 공격 (brute-force)을 시도합니다.
- 복호화에 성공하면, 페이로드 (payload)를
LocalSystem권한으로 실행합니다.
제가 작성한 개념 증명 (Proof of Concept, PoC)에서는 권한 상승 (privilege escalation)이 가능하다는 것을 보여주기 위해 cmd.exe를 실행하도록만 만들었습니다. 하지만 악성코드 (malware)라면 임의의 PowerShell 명령어 또는 스크립트를 실행할 가능성이 높습니다.
최근 저는 이 취약점이 LAN 상의 SMB를 통해 원격으로도 트리거될 수 있으며, 결과적으로 원격 코드 실행 (Remote Code Execution, RCE)으로 이어질 수 있다는 사실을 발견했습니다. 다만, 명명된 파이프 (named pipe)가 인증된 사용자에게만 응답하기 때문에, 성공적인 공격을 위해서는 대상 장비에 대한 유효한 로그인 자격 증명이 필요합니다.
보고 (Reporting)
이 취약점에 대한 보고서를 MSI의 PSIRT 이메일로 보냈을 때, 저는 우려스러운 답변을 받았습니다:
Remote Server returned '554 5.2.2 mailbox full; STOREDRV.Deliver.Exception: QuotaExceededException.MapiExceptionShutoffQuotaExceeded;'
이것이 기본적으로 의미하는 바는 취약점 보고를 받는 메일함이 가득 차서 추가적인 이메일 수신을 거부하고 있다는 것이었습니다.
제 취약점 보고서를 거부했을 뿐만 아니라, 아마도 알 수 없는 기간 동안 이런 상태가 지속되어 저뿐만 아니라 다른 사람들의 취약점 보고서도 누락되었을 가능성이 큽니다.
이러한 우려스러운 상황 때문에, 저는 이 상황을 해결하는 데 도움을 줄 수 있는 MSI 직원을 찾기 위해 제 연락처들을 통해 연락을 취하기 시작했습니다.
결국 Gamers Nexus를 운영하는 Steve Burke가 MSI 직원과 연락할 수 있도록 도와주었습니다. 하지만 제 보고서가 메일 서버의 인상과는 정반대로 결국 MSI에 도달했었기에, 그 모든 노력은 헛수고였음이 드러났습니다.
이 작은 문제 이후, MSI와의 경험은 실제로 꽤 즐거웠습니다. 그들은 제가 취약점을 보고한 지 이틀(two days) 만에 패치를 준비했으며, 어떤 MSI Center 릴리스에 포함될 것인지, 그리고 새로운 버전을 언제 출시할 계획인지 저에게 알려주었습니다.
불행히도, MSI는 이에 대해 CVE를 발행할 수 있는 권한이 없었기에, MITRE나 제3자 CNA를 통해 요청할 것을 제안했습니다.
이 글을 쓰는 시점을 기준으로 약 한 달이 지났으며, 제 제출 건은 여전히 VulDB에서 검토 중입니다. 그들은 새로운 제출 건이 많아 대기 시간이 약 4주 정도 소요된다고 밝히고 있으므로, 조만간 검토가 완료되기를 바랍니다.
후원 (Donations)
지금까지 제가 Google, ASUS, AMD, TP-Link, Netgear, MSI (외 다수)에 보고한 취약점들에 대해, 그들이 지급한 버그 바운티 (bug bounties)는 총 0달러였습니다.
만약 이 글이 흥미롭거나 유용했다면, 제 Ko-fi를 통해 커피 한 잔을 사주실 수 있습니다: https://ko-fi.com/mrbruhh
타임라인 (Timeline) (DD/MM/YYYY)
- 09/05/2026 - 취약점 발견 (Vulnerability Discovered)
- 10/05/2026 - 취약점 보고 (Vulnerability Reported)
- 12/05/2026 - MSI 응답 및 패치 생성 완료 통보
- 01/06/2026 - MSI Center 2.0.70.0 출시
- 03/06/2026 - VulDB를 통해 CVE-2026-XXXX 요청
- 01/07/2026 - 엠바고 (Embargo) 종료
AI 자동 생성 콘텐츠
본 콘텐츠는 HN AI Posts의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기