PC 유틸리티의 대명사 CPU-Z와 HWMonitor, 공식 사이트에서 악성코드 유포 정황 포착

무슨 일이 있었나요?

PC 하드웨어 정보를 확인할 때 거의 모든 사람이 한 번쯤 써봤을 CPU-Z와 HWMonitor. 이 두 프로그램의 공식 다운로드 사이트에서 배포되는 설치 파일이 변조되었다는 정황이 포착됐어요. 단순히 서드파티 미러 사이트가 아니라, 개발사인 CPUID의 공식 웹사이트에서 직접 내려받은 파일에서 문제가 발견된 거라 상당히 심각한 상황이에요.

보통 "공식 사이트에서 받으면 안전하다"는 게 보안의 기본 상식이잖아요. 그런데 그 전제가 깨진 거예요. 이건 단순한 피싱 사이트 문제가 아니라 공급망 공격(Supply Chain Attack)의 전형적인 사례인데요, 공급망 공격이 뭐냐면 소프트웨어가 만들어지거나 배포되는 과정 자체를 공격해서, 사용자가 정상적인 경로로 다운로드하더라도 이미 악성코드가 심어진 버전을 받게 만드는 공격 방식이에요.

구체적으로 어떤 문제가 있었나

HWMonitor 1.63 버전이 특히 문제로 지목됐어요. 공식 사이트에서 다운로드한 설치 파일을 분석해보니, 정상적인 프로그램과 함께 의심스러운 페이로드가 포함되어 있었다는 보고가 나왔거든요. CPU-Z 역시 같은 개발사에서 만드는 프로그램이라 함께 의심 대상에 올랐고요.

이런 공급망 공격이 무서운 이유는 몇 가지가 있어요. 첫째, 사용자가 아무리 조심해도 당할 수 있다는 점이에요. 공식 사이트에서 받았고, 프로그램 이름도 정상이고, 심지어 디지털 서명까지 유효할 수 있거든요. 둘째, 이런 유틸리티는 하드웨어 정보를 읽기 위해 커널 레벨 드라이버를 설치하는 경우가 많아서, 악성코드가 시스템 깊숙한 곳까지 접근할 수 있는 권한을 얻게 돼요. CPU-Z나 HWMonitor 같은 프로그램은 설치할 때 관리자 권한을 요구하잖아요? 그 권한이 고스란히 악성코드에게도 넘어가는 거예요.

셋째, 영향 범위가 어마어마해요. CPU-Z는 전 세계적으로 수천만 번 이상 다운로드된 프로그램이에요. 새 PC를 조립하거나, 중고 부품을 확인하거나, 오버클러킹할 때 거의 필수로 쓰이는 도구라서 타깃 풀이 굉장히 넓죠.

최근 공급망 공격 트렌드와의 연결

사실 이런 종류의 공격은 최근 몇 년 사이에 눈에 띄게 늘었어요. 가장 유명한 사례가 2020년의 SolarWinds 해킹인데, 네트워크 관리 소프트웨어의 업데이트 서버가 해킹되어 미국 정부 기관을 포함한 수만 개 조직이 피해를 입었죠. 2024년에는 리눅스의 핵심 라이브러리인 xz-utils에 백도어가 심어진 사건이 있었고, 이건 오픈소스 메인테이너의 신뢰를 악용한 케이스였어요.

CPU-Z/HWMonitor 사례는 이런 흐름의 연장선에 있어요. 공격자들이 점점 더 "신뢰받는 경로"를 노리고 있다는 뜻이거든요. 예전에는 수상한 이메일 링크를 클릭하지 않으면 됐지만, 이제는 공식 사이트에서 공식 프로그램을 받아도 안전하지 않을 수 있는 시대가 된 거예요.

비슷한 사례로 2023년에는 3CX라는 VoIP 소프트웨어의 공식 데스크톱 앱이 변조된 적이 있고, Codecov라는 코드 커버리지 도구의 업로더 스크립트가 해킹되어 CI/CD 파이프라인의 환경변수(시크릿 포함)가 유출된 사건도 있었어요.

한국 개발자에게 주는 시사점

개발자로서 이 사건에서 가져갈 수 있는 교훈이 꽤 있어요.

다운로드 후 체크섬 검증을 습관화하세요. 공식 사이트에서 받았더라도 SHA-256 해시를 확인하는 게 좋아요. 물론 해시값 자체도 변조될 수 있지만, 적어도 한 겹의 방어막은 되거든요. 윈도우에서는 certutil -hashfile 파일명 SHA256 명령어로 간단히 확인할 수 있어요.

본인이 배포하는 소프트웨어의 빌드 파이프라인 보안도 점검해보세요. CI/CD 서버의 접근 권한 관리, 빌드 아티팩트의 무결성 검증, 배포 서버의 보안 설정 등을 확인할 필요가 있어요. 특히 사내 도구나 SDK를 배포하는 팀이라면 이번 사건을 계기로 한번 돌아보면 좋겠어요.

시스템 유틸리티의 대안도 알아두세요. HWiNFO 같은 대체 도구도 있고, 리눅스에서는 lscpu, sensors 같은 기본 명령어로도 상당 부분 확인할 수 있어요. 하나의 도구에만 의존하지 않는 것도 리스크 관리의 일부예요.