XZ-Utils 백도어 사건

1. XZ-Utils 백도어 사건 개요

2024년 3월 29일, 마이크로소프트에서 일하는 개발자가 XZ 유틸에서 백도어가 발견되었다고 발표했습니다 . 이 개발자는 안드레스라는 분으로, 데비안 시스템에서 SSH 사용할 때 성능 이슈를 보고 있었다고 합니다 . SSH 로그인 과정에서 너무 많은 CPU 사이클을 잡아먹고 에러가 발생하는 것을 발견하고 디버깅하다가 XZ 유틸 업데이트로 문제가 생겼음을 알게 되었습니다 . XZ 유틸은 2005년에서 2008년에 라세 콜린이라는 개발자가 파일을 효율적으로 압축하는 LZMA 알고리즘을 사용하여 고안한 XZ 파일 형식을 기반으로 동작합니다 . 이 XZ 유틸은 시간이 지나면서 리눅스와 맥 OS 같은 유닉스 기본에서 많이 사용되게 되었습니다 . 여기에 백도어가 심겨져 리누스 계열에 대비함과 레드햇에 머지 되기 직전에 검출되었습니다 . 이 공격은 2024년 3월 29일에 공개되었으며, 널리 사용되는 오픈소스 소프트웨어에 대한 최초의 심각한 공급망 공격으로 보입니다 . 이 사건은 오픈소스 공급망 보안에 있어 분수령이 될 사건이라고 평가받고 있습니다 .

 

2. XZ-Utils 백도어 사건 타임라인

시점	내용	출처
2021년	'Jia Tan' 계정 생성 , XZ 유틸에 첫 패치 적용 (정상 코드)	,
2022년 2월 6일	'Jia Tan' 계정으로 널 검사 커밋 추가	,
2022년 4월 22일	'Jigar Kumar'가 'Jia Tan'의 패치 머지 지연에 불만 표출	,
2022년 5월 19일	'Dennis Ens'가 XZ for Java 유지 관리 상태 문의 , Lasse Collin이 느린 응답 사과 및 'Jia Tan'이 더 큰 역할 맡을 수 있다고 언급	,
2022년 5월 27일	'Jigar Kumar'가 패치 스레드에 압박 이메일 발송 ,	,
2022년 6월 8일	Lasse Collin이 정신 건강 문제로 제한적임을 언급	,
2022년 6월 10일	Lasse Collin이 'Jia Tan'의 첫 커밋 머지
2022년 6월 21일	'Dennis Ens'가 유지 관리자 변경 제안
2022년 6월 29일	Lasse Collin이 'Jia Tan'이 프로젝트에서 더 큰 역할 맡을 수 있음을 시사
2022년 9월 27일	'Jia Tan'이 5.4.0 릴리스 요약 제공
2022년 11월 30일	Lasse Collin이 버그 리포트 이메일 주소 변경 (Jia Tan과 공유)
2022년 12월 30일	'Jia Tan'이 xz 저장소에 직접 첫 커밋 머지	,
2023년 3월 18일	'Jia Tan'이 첫 릴리스 v5.4.2 태그 및 빌드
2023년 3월 20일	'Jia Tan'이 Google oss-fuzz 구성 업데이트 (버그 자신에게 보내도록)
2024년 1월 19일	'Jia Tan'이 웹 사이트를 GitHub 페이지로 이동하여 XZ Utils 웹 페이지 제어
2024년 2월 23일	'Jia Tan'이 백도어 파일 추가 (바이너리 테스트 파일 내 숨김)
2024년 2월 24일	'Jia Tan'이 v5.6.0 태그 및 악의적인 build-to-host.m4 포함 배포판 게시 , Gentoo에서 5.6.0에서 충돌 발생 시작
2024년 2월 26일	Debian이 xz-utils 5.6.0-0.1을 unstable에 추가
2024년 2월 28일	'Jia Tan'이 랜드락 감지 깨뜨리는 오타 추가 , Debian이 xz-utils 5.6.0-0.2를 unstable에 추가	,
2024년 3월 4일	RedHat 배포판에서 Valgrind 오류 발생 시작 (백도어 진입점 관련)
2024년 3월 5일	libsystemd PR 병합 (liblzma 제거) , Debian이 xz-utils 5.6.0-0.2를 testing에 추가 , 'Jia Tan'이 ifunc 버그 수정 커밋 ,
2024년 3월 8일	'Jia Tan'이 Valgrind 수정 커밋 (백도어 진입점 문제 해결)	,
2024년 3월 9일	'Jia Tan'이 백도어 파일 업데이트 커밋 , v5.6.1 태그 및 배포판 게시	,
2024년 3월 25일	Hans Jansen이 xz-utils 5.6.1 업데이트 위한 Debian 버그 파일
2024년 3월 27일	Debian이 업데이트 요청 받아들여 5.6.1 버전으로 변경
2024년 3월 28일	백도어 발견 및 비공개 제보 , RedHat이 CVE-2024-3094 할당 , Debian이 5.6.1 롤백
2024년 3월 29일	백도어 경고 공개 , RedHat이 Fedora Rawhide/40 베타에 백도어 포함 발표	,

 

3. 공격자의 수법 및 사회공학적 기법 분석

이번 XZ 유틸 백도어 사건에서는 사회공학적 기법이 주로 사용되었습니다 . 공격자는 'Jia Tan'이라는 이름으로 2년 넘게 xz 압축 라이브러리에 성실하고 효과적인 기여자로 활동하며 신뢰를 쌓았습니다 . 이후 다른 가짜 계정('Jigar Kumar', 'Dennis Ens' 등)을 사용하여 메인테이너인 라세 콜린에게 메일로 지속적인 압박을 가했습니다 . 이러한 압박은 라세 콜린이 프로젝트 유지보수에 어려움을 겪고 있던 상황을 이용한 것으로 보입니다 . 후에 조사 결과 압박에 사용된 많은 메일 계정이 인터넷 상에 사용 기록이 없어 'Jia Tan'과 동일 인물이 여러 계정을 만들어 압박한 것으로 추측됩니다 .

백도어를 숨기기 위한 수법도 매우 교묘했습니다. 백도어 코드는 바이너리 파일 형태의 테스트 파일 내에 숨겨져 추가되었습니다 . 바이너리 코드는 개발자가 내용을 쉽게 이해하기 어렵다는 점을 악용한 것입니다 . 또한, 보안 프로그램인 랜드락(Landlock)이 돌지 않도록 코드를 조작했습니다 . 다른 변경 사항들 사이에 점 하나를 끼워 넣어 코드 자체가 에러로 돌아가지 않도록 수정함으로써, 랜드락을 사용할 수 없다고 판단하게 만들었습니다 . 백도어의 진입점 역할을 하던 함수에서 에러가 발생하자, 다른 개발자에게 들통나기 전에 직접 해당 에러를 해결하는 등 치밀한 모습을 보였습니다 .

 

4. 백도어의 기능 및 잠재적 위험성

이번 XZ 유틸 백도어는 매우 심각한 기능을 가지고 있었습니다. 백도어는 sshd(SSH 데몬) 동작을 변경하는 데 사용되었습니다 . 특히, SSH 세션 시작 시 공격자가 숨겨진 명령을 보내는 것을 감시하여, 로그인하지 않고도 대상 시스템에서 임의의 명령을 실행할 수 있는 기능을 제공했습니다 . 이는 인증되지 않은 원격 코드 실행에 해당하며, 암호화 키를 가지고 있는 공격자는 이 백도어가 설치된 장치에 원하는 코드를 SSH 인증서에 업로드하여 실행할 수 있었습니다 . 다행히 백도어가 실제로 사용된 흔적은 보이지 않는다고 합니다 .

하지만 이 백도어가 악용될 경우 이론적으로는 진짜 아무거나 다 할 수 있었다고 합니다 . 맬웨어 설치부터 장치에 있는 암호화 키 탈취까지 전부 가능했습니다 . 암호화 키가 탈취되면 암호화된 통신 내용도 전부 볼 수 있게 되어 심각한 보안 문제가 발생합니다 . 압축 라이브러리인 xz-utils가 어떻게 SSH에 영향을 미치는지 궁금할 수 있지만, 시스템d와 같은 프로그램이 sshd와 XZ 유틸의 일부인 립 lgma를 모두 링크하면서, 립 lgma에 포함된 백도어가 sshd를 건드릴 수 있게 된 것입니다 .

 

5. 오픈소스 생태계에 미치는 영향 및 교훈

이번 xz-utils 백도어 사건은 오픈소스 소프트웨어의 공급망 보안에 있어 중요한 전환점이 될 사건으로 평가받고 있습니다 . 이 사건을 통해 오픈소스 생태계가 가진 양면성이 드러났습니다 . 집단 지성을 통해 좋은 프로그램을 개발하는 데 도움이 되지만, 동시에 많은 오픈소스 프로젝트가 유지보수의 어려움으로 인해 유기되는 경우도 있습니다 . 라세 콜린과 같은 메인테이너가 무보수로 많은 시간을 할애해야 하고 정신 건강 이슈까지 겪으면서 프로젝트 관리가 어려워진 상황이 공격자에게 이용되었습니다 .

이 사건은 오픈소스 프로젝트의 거버넌스와 권한 이양 프로세스에 대해 재고할 필요성을 일깨웁니다 . 핵심 메인테이너의 개인적 사정에 프로젝트가 좌우되지 않도록 분산된 거버넌스 모델을 고려해야 합니다 . 또한, 주요 오픈소스 프로젝트에 대한 보안 감사와 코드 리뷰가 더욱 중요해질 것입니다 . 특히 바이너리 데이터 추가와 같이 수상한 변경사항을 탐지하고 권한 악용을 막기 위한 자동화된 점검 도구도 필요합니다 . 공개적으로 개발되고 누구나 기여할 수 있는 오픈소스 방식의 장점을 유지하면서도, 악의적인 기여자를 선별하고 공격을 조기에 차단할 수 있는 기술적, 제도적 방안이 마련되어야 합니다 . 보안이 취약한 언어나 도구를 사용하는 프로젝트일수록 위험이 클 수 있으므로, 메모리 안전성 확보, 정적 분석, Fuzzing 등 다각도로 보안성을 높이려는 노력과 현대적 도구로의 전환도 요구됩니다 . 이번 사건을 통해 향후 비슷한 유형의 공격을 방어하기 위한 통찰을 얻을 수 있도록 자세한 분석 결과에 관심이 쏠릴 것입니다 .