‘XZ Utils 백도어 사태’로 살펴보는 공급망 보안
‘XZ Utils 백도어 사태’로 살펴보는 공급망 보안 관련
date: 2025.05.22
CVSS 10.0의 주인공 ‘XZ Utils’
지난 3월 29일, 마이크로소프트의 소프트웨어 엔지니어 ‘Andres Freund’는 무손실 데이터 압축 유틸리티 XZ Utils(이전에는 LZMA Utils) 5.6.0과 5.6.1버전에 SSH 백도어가 존재한다고 밝혔다. XZ Utils은 LZMA과 XZ파일 형식 기반으로 설계되었으며, 리눅스(Linux)를 포함한 거의 모든 Unix계열 운영체제 및 Windows 운영체제에서 사용이 가능하다.
Lasse Collin이 단독으로 운영하던 XZ Utils은 gzip이나 bzip2 보다 더 높은 압축률을 제공하면서, tar 파일이나 Linux 커널 이미지 압축 등에 사용되면서 사용자들의 주목을 받기 시작했다. XZ Utils은 공개된 오픈소스 프로젝트로 tukaani-project/xz를 통해 관리되고 있으며, 미러 사이트인 https://git.tukaani.org/?p=xz.git를 통해서도 접근이 가능하다.
Andres Freund는 XZ Utils에 SSH 백도어가 존재한다는 사실을 우연히 발견했다고 한다. 원격에서 로그인 시에 사용되는 SSH에서 Debian 시스템의 성능 문제를 해결하는 과정 중 SSH 로그인이 CPU를 너무 많이 소모한다는 사실을 발견하고, 이를 확인하는 과정에서 발견된 것이다.
메모리 누수를 탐지하는 리눅스용 디버깅 도구인 Valgrind를 통해 모니터링한 결과, XZ Utils에 백도어가 존재한다는 사실을 확인 후, XZ Utils의 업데이트 목록을 확인하는 과정에서 실수가 아닌 의도적인 백도어 삽입이 발생했음을 인지했다.
의도적으로 백도어가 삽입된 사건을 두고 사람들은 취약점이라고 부르기보다, ‘XZ Utils 백도어 사태’라고 칭했다. XZ Utils 백도어 사태는 Linux나 Unix 계열의 운영체제뿐만 아니라, Windows 운영체제에도 영향을 끼칠 수 있기 때문에 소프트웨어 상당수가 영향을 받을 수 있다. 따라서 솔라윈즈(SolarWinds), 코드코브(Codecov), 카세야(Kaseya)등 종전의 소프트웨어 공급망 공격의 악몽이 되살아나면서, 소프트웨어 공급망 보안의 중요성을 다시금 상기시키는 사건이라 볼 수 있다.
오픈소스 정보 메일링 서비스 openwall을 통해 Andres Freund가 공개한 내용에 따르면, 대부분의 최신 Linux 배포판에는 기본적으로 백도어가 설치된 XZ Utils의 5.6.0과 5.6.1버전이 포함된 것으로 알려졌다. XZ Utils에 삽입된 SSH 백도어는 원격에서 인증되지 않은 사용자가 인증 우회를 통해 취약한 XZ Utils로 시스템에 악의적인 공격 스크립트나 명령어를 실행할 수 있게 한다. 취약점을 점수화해서 제공하는 CVSS[1]에서 최고점인 10을 받았으며, CVE-2024-3094라는 취약점 관리 번호가 부여되어 있다.
XZ Utils 백도어 사태가 중요한 이유는 유틸리티에 원격 명령어 실행이 가능한 백도어가 삽입되어 있다는 점 이외에도, 백도어를 삽입하는 공급망 공격 과정에서 시사점을 찾을 수 있다. 공격자가 상호 간의 신뢰를 바탕으로 운영되는 오픈소스 생태계와 프로젝트 운영자의 신뢰를 이용했다는 점에서, 오픈소스 생태계의 소프트웨어 공급망 보안의 분수령이 될 만한 사건이다.
이번 글에서는 ‘CVE-2024-3094’라고 불리는 XZ Utils 백도어 사태에 대해 다시 되짚어보고, 나아가 오픈소스 생태계에서 발생하는 소프트웨어 공급망 공격 대응 방안을 고민해 보고자 한다.
XZ Utils 백도어 사태를 유발한 Jia Tan(JiaT75)의 행적을 통해 XZ Utils 5.6.0과 5.6.1버전에 SSH 백도어가 삽입되는 과정을 살펴보고자 한다.
1) 2021년 주요 활동 : Jia Tan(JiaT75)의 등장
XZ Utils에 SSH 백도어를 삽입한 사용자 JiaT75는 2021년 1월 26일 Jia Tan(JiaT75)이라는 계정을 생성한다. 이후 JiaT75가 XZ Utils에 처음으로 커밋(Commit)을 제출한 것은 이로부터 약 1년 후인 2022년 2월 6일 파라미터의 유효성을 검사하는 로직을 추가한다.
이해를 돕기 위해서 Git에서 소스코드를 배포하는 과정을 간단히 설명하면 다음과 같다. 일반적으로 소스코드를 변경하는 단위로 1개의 브랜치(Branch)에 1번의 Commit을 수행하게 된다. 이렇게 발생한 Branch를 다른 Branch 합칠 때 머지(Merge)기능을 사용하게 된다. 최종적으로 모든 변경 사항을 포함한 배포를 하기 위해서는 마스터(Master) Branch에 Merge시키면 된다.
2) 2022년 주요 활동 : XZ Utils 일부 관리 권한 획득
JiaT75은 202년부터 본격적인 XZ Utils 프로젝트 활동을 시작한다. 2022년 2월 6일 XZ Utils Repository에 처음으로 LZMA와 LZMA2 인코더의 파라미터 유효성을 검사하는 로직을 추가하는 Commit을 제출한다.
2022년 11월 30일에는 XZ Utils를 만든 창시자이자 단독 유지 관리 담당자인 Lasse Collins이 버그 보고 이메일을 본인의 계정이 아닌 XZ Utils의 공식 계정인 xz@tukaani[.]org으로 변경하고, 메일 수신 시에 Lasse Collins 본인과 JiaT75에 이메일을 리다이렉션 하도록 변경했다.
단독 관리자 체계가 깨지는 과정에서 비단 JiaT75만 연관된 것은 아니다. Jigar Kumar와 Dennis Ens는 XZ Utils의 백도어 삽입에 직접적으로 관여하지 않았으나, Lasse Collins에게 프로젝트를 혼자 관리해서 개발 속도가 느리다는 점을 지적하며 새로운 프로젝트 관리자를 추가할 수 있도록 압력을 가했다. 2022년 4월에는 Jigar Kumar가 JiaT75이 올린 패치가 Merge되지 않았다며 불만을 표출하거나 2022년 5월에는 Dennis Ens가 XZ Utils의 유지관리 상태를 문의하기도 했다.
이러한 상황 속에서 JiaT75는 XZ Utils 프로젝트 활동을 지속하며, Lasse Collins과 신뢰를 쌓게 된다. 이후 Lasse Collins은 늦은 응답에 사과하면서 JiaT75가 XZ Utils 운영을 도와주고 있으며, 향후 안전적인 프로젝트 운영을 위해 역할을 부여할 수 있음을 시사한다.
Jigar Kumar와 Dennis Ens가 압박 메일을 지속했기 때문에, JiaT75가 XZ Utils의 유지 관리자로서 권한을 획득하는 데 일조했다. Jigar Kumar와 Dennis Ens이 XZ Utils에 직접적인 기여를 하지 않았기 때문에 실존 인물이 아닐 가능성이 제기됐다. 그러나 Jigar Kumar와 Dennis Ens의 활동이 JiaT75가 유지 관리자로 승격되는 데 영향을 미쳤다는 사실을 부인할 수는 없다.
바로 이 점이 XZ Utils 백도어 사태를 눈여겨봐야 하는 이유다. 종전의 오픈소스 타깃의 공급망 공격은 개발 서버에 침투해서 악성코드를 삽입하거나, 서버 계정 및 인증서 탈취, 의존성 혼동(Dependency Confusion), 타이포스쿼팅(Typosquatting) 등의 공격을 수행했다. 이러한 공격 양상은 공급망 생태계의 취약점이나 상대적으로 보안 수준이 낮은 영역을 공격한 결과라고 볼 수 있다.
하지만 XZ Utils 백도어 사태는 단일 관리자로 운영되는 오픈소스 프로젝트와 다년간의 신뢰 관계를 유지한 사용자가 단일 관리자의 신뢰를 바탕으로 관리자 권한을 획득한 이후, 관리자에 의해 백도어가 삽입된 공격이 발생한 것이다.
따라서 향후 단일 관리자가 단독으로 운영하는 프로젝트들은 이번 사태와 유사하게 제2의 XZ Utils 피해자로 타깃팅 될 가능성이 높다. 직접적으로 공격에 가담하지 않더라도 Jigar Kumar와 Dennis Ens의 압박으로 인해 Lasse Collins은 심리적으로 부담될 수밖에 없는 상황에서 프로젝트에 긍정적으로 기여하고 있는 JiaT75의 존재는 사람의 심리를 이용했다는 점에서 다른 공급망 공격과 차이를 보인다.
XZ Utils 백도어 사태 이후 XZ Utils 관리자 Lasse Collins는 본인이 운영하는 사이트를 통해서 2024년 4월 30일을 기점으로 xz@tukaani[.]org으로 수신되는 메일은 본인에게만 전달되도록 변경했으며, 그전에는 JiaT75유저인 Jia Tan에게도 전달되었다는 사실을 밝혔다.
3) 2023년 주요 활동: XZ Utils 백도어 삽입을 위한 보안 설정 우회작업
2023년은 XZ Utils에 백도어를 삽입하기 위한 기반을 마련하는 과정이었다. 2023년 1월 11일과 3월 18일 Lasse Collins와 JiaT75이 각각 5.4.1 최종 버전과 첫 번째 릴리즈인 5.4.2를 빌드하고 배포하는 작업을 했다.
2023년 6월 27일과 28일에는 XZ Utils 공격을 위한 기반이 마련됐다. 먼저 6월 27일에는 Hans Jansen이 작성한 공격용 테스트를 JiaT75이 커밋을 승인했고, 이 외에도 crc64_fast.c에 대한 ifunc 구현에 대한 지원이 추가됐다. Andres Freund의 분석에 따르면 이때 추가된 ifunc은 백도어가 동작하는 방식 중 하나일 가능성이 높다고 밝혔다.
2023년 7월 8일에는 Google에서 퍼징 서비스를 위한 오픈소스 소프트웨어인 OSS-Fuzz에 PR(Pull Request)을 수행했다. PR은 사용자가 원격 저장소에 Push하여 새로운 사항이 적용되었을 때 다른 사용자에게 Push된 상황을 알리는 것을 의미한다. 해당 PR은 ifunc 퍼징을 비활성 하는 것으로 향후 악의적인 공격을 수행할 때, 변경 사항이 발견되지 못하게 하는 의도가 있다고 볼 수 있다.
4) 2024년 주요 활동: XZ Utils 백도어 삽입
2024년에는 본격적으로 XZ Utils에 백도어를 삽입하고 배포하기 위한 작업을 진행했다. 2024년 2월 15일 JiaT75는 .gitignore 파일을 통해 XZ Repository에 build-to-host.m4에 대한 무시 규칙을 추가한다. 이 과정은 실제 릴리스 번들에 포함될 이 스크립트 파일은 패키지 빌드 중에 실행되면서, 악성 M4 매크로가 포함되어 피해자의 시스템에 백도어가 설치되도록 초기화하게 된다.
2024년 2월 23일에는 JiaT75가 XZ Utils 난독화된 2개의 바이너리 백도어인 tests/files/bad-3-corrupt_lzma2.xz와 tests/files/good-large_compressed.lzma를 추가했다.
2024년 2월 24일에는 JiaT75가 악성 build-to-host.m4가 포함된 버전 5.6.0을 배포하면서, 악성 페이로드가 완벽하게 동작하게 됐다. 악성 페이로드인 백도어가 포함된 XZ Utils 5.6.0버전은 Debian, Fedora, OpenSUSE, Arch Linux 등에도 반영되어, XZ Utils 백도어에 영향을 받게 됐다. 2024년 3월 9일에도 JiaT75가 일부 개선된 버전의 바이너리 백도어를 XZ Utils 5.6.1에 삽입시키면서, 5.6.0과 마찬가지로 다수의 운영체제에 XZ Utils 백도어의 영향을 받게 했다.
이후 2024년 3월 29일 Andres Freund가 XZ Utils 백도어가 포함된 버전이 공개되었으며, 2024년 3월 30일에 XZ Utils의 원래 관리자인 Lasse Collins가 공격으로 인한 피해 사실을 공식 발표하고, 백도어가 설치된 버전은 삭제 처리되었다.
안전한 소프트웨어 생태계를 위한 방안
지금까지 ‘XZ Utils 백도어 사태’를 통해 소프트웨어 공급망 공격을 수행하는 과정에 대해 살펴보았다. 공격자는 리눅스 운영체제에 기본적으로 설치되는 XZ Utils에 백도어를 설치하기 위해, 다년간 프로젝트에 기여하여 운영 관리자 권한을 얻은 후 백도어를 삽입했다.
소프트웨어 공급망 공격은 소프트웨어 생명주기나, 소프트웨어 개발 생태계에 침투해 공격하기 때문에 피해 사실을 인지하기 어렵다. 하물며 XZ Utils 백도어 사태와 같이 다수의 소프트웨어에 연쇄적인 영향을 미칠 수 있는 소프트웨어 프로젝트인 경우라면, 공격의 영향도뿐만 아니라 원인 파악이 어려워 공급망 공격의 영향도를 알 수 있는 사례였다.
사이버 공격은 다양한 이해관계와 목적에 의해 발생한다. 특히 소프트웨어 공급망 공격은 단일 공격 대상을 통해서도 다수의 피해를 일으킬 수 있어, 최근 발생하는 사이버 공격의 상당수를 차지하는 방식이라고 볼 수 있다. 이러한 소프트웨어 공급망 공격에 대응하기 위해서는 소프트웨어 생태계를 이해하고, 안전한 소프트웨어를 운영하기 위한 방안이 무엇인지 모두 함께 고민하는 것이 문제해결의 시작이다.
소프트웨어 공급망 공격은 단순히 시큐어 코딩이나 모의해킹 등의 단편적인 방법으로 막을 수 없으므로, 다양한 관점에서 대응 방안을 고려해야 한다. 우선 소프트웨어 전반의 보안 강화를 위해 SSDF(Secure Software Development Framework)와 보안 설계(Security By Design)를 반영한 보안 내재화가 필요하다.
국내 한국인터넷진흥원(KISA)과 미국 사이버 보안 및 기반 시설 보호청(CISA)을 포함한 해외 유관기관에서는 소프트웨어의 투명성과 책임성을 통한 소프트웨어의 보안 내재화를 위한 목적으로, ‘보안 내재화 가이드(Shifting the balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software)’를 발표했다.
이처럼 소프트웨어 공급망을 악용하려는 공격자들의 공세에 대비하려면, 다양한 이해관계자들의 노력이 필요할 것이다. 앞으로 제2의 XZ Utils 사태에 대비하기 위해 모두 경각심을 가질 수 있길 바란다.
*CVSS와 관련해 더 자세한 내용은 이전에 쓴 ‘사이버 보안 위험: 숫자로 표현하는 'CVSS’를 참조 ↩︎