XZ Utils 백도어(XZ Utils Backdoor)는 2024년 3월 29일에 발견된 오픈소스 압축 라이브러리 XZ Utils의 공급망 공격 사건이다. CVE-2024-3094로 지정되어 CVSS 점수 10.0(!)을 받은 이 사건은 사이버보안 역사상 가장 정교한 공급망 공격 중 하나로 평가받고 있다.
개요[편집 / 원본 편집]
XZ는 대부분의 현대 Linux 배포판에 기본적으로 설치되어 있어, 이 백도어의 발견은 전 세계 리눅스 시스템에 심각한 위협이 되었다. 2024년 3월 29일, 개발자 Andres Freund가 자신의 Debian sid 환경에서 매우 미묘한 성능 이상을 조사하던 중 이 백도어를 발견했다. 백도어는 XZ Utils 버전 5.6.0(2024년 2월 24일 릴리스)과 5.6.1(2024년 3월 9일 릴리스)에만 존재했으며, SSH 서버를 통한 원격 인증 우회 및 코드 실행을 가능하게 하는 매우 위험한 백도어였다.
배경[편집 / 원본 편집]
이 백도어 사건의 가장 충격적인 부분은 공격자의 장기간에 걸친 치밀한 계획이다. GitHub 계정 "Jia Tan"(또는 Jia Cheong Tan, JiaT75)은 2021년에 생성되어 거의 2년 전부터 XZ 프로젝트에 기여하기 시작했다. 공격자는 정상적인 버그 수정 및 기능 개선 기여, 커뮤니티 내에서의 적극적인 활동, 점진적인 권한 확대를 통해 신뢰를 구축했다.
추가적인 교묘한 소셜 엔지니어링을 통해 Jigar Kumar와 Dennis Ens 같은 sock puppet 계정들이 기능 요청을 제출하고 다양한 이슈를 보고하는 데 활용된 것으로 의심된다. 특히 Denis Ens 계정이 Lasse Collin(원래 유지보수자)에게 더 많은 유지보수자가 필요하다고 압박했고, Jigar Kumar 계정이 릴리스 일정에 대해 불평하며 Jia Tan을 도와달라고 요청하는 등의 사회공학적 압력을 가했다.
Jia Tan은 2023년 1월부터 직접 푸시 권한을 얻었다. 이 시점부터 공격자는 프로젝트 홈페이지를 tukaani.org/xz/에서 xz.tukaani.org/xz-utils/로 변경하여 Jia의 프로젝트 제어권을 더욱 강화했다. 또한 2023년에 XZ 프로젝트의 퍼저 구성에서 '간접 함수 지원'을 비활성화하는 PR을 열어, 나중에 추가할 백도어가 퍼저에 의해 탐지되는 것을 방지하기 위한 준비를 했다.
백도어 삽입[편집 / 원본 편집]
2024년 2월 23일과 3월 9일, 최종 단계인 실제 코드가 두 번의 커밋을 통해 프로젝트에 커밋되었다. 첫 번째는 2024년 2월 23일에 백도어 코드가 삽입되었고, 두 번째는 3월 9일에 백도어 완성을 위한 커밋이 이루어졌다.
Jia Tan은 백도어가 포함된 버전을 주요 배포판에 포함시키기 위해 적극적으로 활동했다. Debian에 백도어 버전을 포함시키도록 압박했고, misoeater91, krygorin4545 등의 의심스러운 익명 계정들이 포함을 촉구했다. 특히 krygorin4545의 PGP 키는 논의 시작 하루 전에만 생성된 것으로 확인되었다. Jia Tan은 Ubuntu 베타 프리즈 전에 백도어 버전을 포함시키려 했으나 실패했다.
기술적 분석[편집 / 원본 편집]
이 백도어는 매우 정교하고 복잡한 구조를 가지고 있다. 먼저 빌드 시스템 조작 단계에서 릴리스 tarball에 포함된 build-to-host.m4 파일이 GitHub의 업스트림 버전과 완전히 다르다. 이는 C 프로젝트에서 다운스트림 소비자들이 autotools와 autoconf 실행 방법을 기억할 필요가 없도록 하는 일반적인 관행을 악용한 것이다.
두 번째로 Git 저장소의 tests/ 폴더에 조작된 테스트 파일들이 있다. tests/files/bad-3-corrupt_lzma2.xz와 tests/files/good-large_compressed.lzma 파일들이 백도어 구현에 활용되었다. 세 번째 단계인 런타임 조작에서는 악성 주입이 xz 버전 5.6.0과 5.6.1 라이브러리에 있으며 난독화되어 있고 다운로드 패키지에만 완전히 포함되어 있다. Git 배포에는 악성 코드 빌드를 트리거하는 M4 매크로가 없다.
백도어는 SSH 데몬을 조작하는 방식으로 작동한다. 영향을 받은 XZ Utils 버전의 악성 페이로드는 OpenSSH 서버(SSHD)와 동일한 프로세스에서 실행되며, SSH를 통해 임의의 페이로드를 전송할 수 있도록 OpenSSH 서버의 복호화 루틴을 수정한다. 이를 통해 특정 원격 공격자(특정 개인 키를 소유한)가 인증 단계 전에 실행될 임의의 페이로드를 SSH를 통해 전송할 수 있도록 허용한다.
시스템이 CVE-2024-3094에 취약하려면 여러 조건들이 충족되어야 한다. IFUNC 지원을 위해 glibc를 사용하는 배포판이어야 하고, XZ Utils 5.6.0 또는 5.6.1, 또는 해당 버전의 liblzma가 설치되어 있어야 한다. 또한 SSH 서버가 Systemd에 의해 서비스로 실행되는 GNU Linux x86/64 시스템이어야 하며, 라이브러리가 패키지 관리자에 의해 설치되어야 하고, 공격자가 원격으로 상호작용할 수 있도록 인터넷에 노출된 SSH 서버가 있어야 한다.
흥미롭게도 백도어에는 비활성화 메커니즘이 포함되어 있다. /etc/environment에 "yolAbejyiejuvnup=Evjtgvsh5okmkAvj" 문자열을 추가하면 악성 백도어 기능이 비활성화된다(SSH와 Systemd 재시작 후 적용).
발견 과정[편집 / 원본 편집]
2024년 3월 29일, Microsoft 소프트웨어 엔지니어 Andres Freund가 오픈소스 커뮤니티에 XZ 버전 5.6.0과 5.6.1의 SSH 백도어에 대해 경고했다. 발견 과정은 매우 우연한 일련의 사건들로 이어졌다. Freund는 자신의 Debian sid 환경에서 SSH 연결 시 평소보다 약간 높은, 하지만 거의 눈에 띄지 않을 정도로 미묘한 CPU 사용량 증가와 지연시간을 감지했다. 이는 몇 밀리초에서 최대 몇백 밀리초 수준의 매우 작은 차이였지만, 예민한 개발자의 눈에는 이상하게 느껴질 정도였다.
발견 과정은 "정말로 많은 우연의 일치가 필요했다"고 Andres Freund가 말했듯이, 매우 운이 좋은 발견이었다. 만약 이런 미세한 성능 차이가 감지되지 않았다면 CVE-2024-3094는 여전히 야생에서 활동하고 있을 수도 있었다. 일반 사용자들은 이 정도의 미미한 지연을 느끼지 못했을 것이고, 시스템 관리자들도 특별히 모니터링하지 않는 한 발견하기 어려웠을 것이다.
발견 즉시 보안 커뮤니티는 빠르게 대응했다. 여러 보안 연구자들이 백도어 코드 분석을 시작했고, 주요 Linux 배포판들이 긴급 보안 권고를 발행했으며, 전 세계 기술 미디어에서 대대적으로 보도되었다.
영향받은 시스템[편집 / 원본 편집]
백도어는 여러 Linux 배포판에 며칠간 패키징되어 있었다. 확인된 영향받은 배포판으로는 Fedora Linux의 Fedora 40 beta와 Fedora Rawhide, Debian의 unstable, testing, experimental, Kali Linux, 그리고 Arch Linux 2024.03.01, VM 이미지 20240301.218094에서 20240315.221711, 2024-02-24와 2024-03-28 사이에 생성된 컨테이너 이미지가 있다.
다행히도 업계 지식에 따르면, Ubuntu나 Amazon Linux 같은 다른 널리 사용되는 배포판에는 백도어가 패키징되지 않았다. 또한 버전 5.6.0과 5.6.1은 새로운 버전이었고 아직 주류 프로젝트에 광범위하게 통합되지 않아, 전체적으로 취약한 머신의 수가 제한되었다.
대응 및 완화[편집 / 원본 편집]
보안 커뮤니티와 배포판 유지보수자들은 즉각적으로 대응했다. 사이버보안 및 인프라 보안청(CISA)의 권고에 따르면, 이 Linux 백도어의 위험을 완화하는 가장 안전한 방법은 XZ Utils를 XZ Utils 5.4.6 Stable과 같은 손상되지 않은 버전으로 다운그레이드하는 것이다.
각 배포판은 신속하게 업데이트를 발행했다. Fedora 40은 최신 버전(5.4.x)으로 업데이트했고, Fedora 41 & Rawhide는 즉시 사용을 중단했다. Debian은 최신 버전(5.6.1+really5.4.5-1)으로 업데이트했고, Alpine Edge는 최신 버전(5.6.1-r2)으로, Kali는 최신 버전(5.6.1+really5.4.5-1)으로, OpenSUSE Tumbleweed는 최신 버전(5.6.1.revertto5.4)으로, Arch Linux는 최신 버전(5.6.1-2)으로 각각 업데이트했다.
여러 탐지 방법이 개발되었다. 가장 간단한 방법은 "strings $(which xz) | grep '5\.6\.[01]'" 명령을 실행하여 출력에 5.6.0 또는 5.6.1이 포함되어 있으면 백도어 버전을 실행하고 있을 가능성이 높다는 것을 확인하는 것이다. 잠재적으로 백도어가 있는 바이너리에 의존하는 것이 이상적이지 않으므로, OpenWall 메일링 리스트에서 공유된 detect_sh 스크립트를 사용할 수도 있다. 이 스크립트는 sshd가 사용하는 liblzma 경로를 찾아 함수 시그니처를 확인하는 방식으로 작동한다.
JFrog Research 팀이 CVE-2024-3094를 위한 오픈소스 탐지기를 발행했다. 이 도구는 로컬 머신이 CVE-2024-3094에 취약한지(SSH 페이로드가 실행될 수 있는지)와 현재 CVE-2024-3094의 영향을 받고 있는지(XZ의 악성 버전이 현재 설치되어 있는지) 확인한다.
영향받은 시스템의 복구 과정은 다음과 같다. 먼저 안전한 XZ Utils 버전으로 즉시 다운그레이드해야 한다. 그 다음 xz를 다운그레이드한 후, 머신을 재부팅하거나 OpenSSH 서버를 재시작하여 메모리에서 패치된 코드를 제거한다. 이후 잠재적인 침해 활동을 확인하는 보안 점검을 실시하고, 비정상적인 활동을 감시하는 모니터링을 강화해야 한다.
보안 업계의 평가[편집 / 원본 편집]
XZ 백도어는 공개적으로 문서화된 많은 공급망 공격 중 하나이지만, 기술적 관점과 인간적 관점 모두에서 그 복잡성으로 인해 눈에 띈다. 이러한 장기간 운영은 일반적으로 국가 후원 위협 행위자의 영역이지만, 구체적인 귀속은 현재 존재하지 않는다. 하지만 2년 이상의 장기 계획, 여러 sock puppet 계정을 통한 정교한 사회공학, 매우 높은 수준의 기술적 전문성이 요구되는 기술적 복잡성, 탐지를 피하기 위한 세심한 준비와 은밀성 등의 특징들이 국가 차원의 작전임을 시사한다.
이 사건은 오픈소스 생태계의 근본적인 보안 문제들을 드러냈다. 오픈소스 프로젝트의 분산된 신뢰 모델의 한계, 장기간에 걸친 신뢰 구축을 통한 권한 상승의 위험성, 유지보수자 승계 과정의 보안 취약점 등이 신뢰 모델의 취약성으로 지적되었다. 또한 프로젝트들이 원래 개발자들도 추가하지 않은 복잡한 의존성을 가지고 있어, 모든 것을 처리하고 검사하기가 더욱 어려워진 빌드 시스템의 복잡성 문제와, 정교하게 설계된 백도어는 기존의 정적 분석 도구나 퍼저를 우회할 수 있음이 증명된 자동화된 보안 도구의 한계도 드러났다.
대응 도구 및 기술[편집 / 원본 편집]
여러 보안 업체들이 신속하게 탐지 및 보호 기능을 제공했다. Trend Micro는 고객을 위한 SmartScan Cloud 패턴에서 Trojan.Linux.CVE20243094.A로 탐지하는 기능과 Container Security를 위한 Artifact Scanner를 제공했다. JFrog는 CVE-2024-3094의 영향을 받지 않으며, 취약한 xz_utils 버전을 포함하는 레시피들이 Conan Center에서 제거되었다. Datadog Cloud Security Management(CSM) 고객은 CSM Vulnerabilities를 사용하여 백도어에 감염된 가상 머신이나 컨테이너를 식별할 수 있다.
커뮤니티에서도 다양한 도구들이 개발되었다. GitHub Gist에서 상황에 대한 포괄적인 정보와 링크가 제공되었고, 설치된 취약한 패키지 검색용 Velociraptor Artifact가 개발되었으며, 다양한 탐지 스크립트들이 공개적으로 공유되었다.
교훈 및 향후 대응[편집 / 원본 편집]
이 사건을 통해 오픈소스 보안 강화를 위한 여러 방안들이 제기되었다. 코드 검토 프로세스 강화 방안으로는 모든 커밋에 대한 다중 검토자 요구, 자동화된 코드 분석 도구의 의무적 사용, 빌드 시스템 변경에 대한 특별한 주의가 필요하다고 지적되었다. 유지보수자 관리 개선 측면에서는 새로운 유지보수자 승인을 위한 더 엄격한 절차, 기존 유지보수자에 대한 정기적인 신원 확인, 권한 분산을 통한 단일 실패점 제거가 중요하다고 평가되었다. 공급망 투명성 확보를 위해서는 빌드 과정의 재현 가능성 확보, 소스 코드와 배포 바이너리 간의 일치성 검증, 서명 및 검증 프로세스 강화가 필요하다고 분석되었다.
XZ Utils 백도어 사건은 오픈소스 거버넌스 모델의 재검토, 자동화된 보안 검사 도구의 발전, 공급망 보안에 대한 인식 제고, 정부 차원의 오픈소스 보안 투자 확대 등의 장기적 변화를 가져올 것으로 예상된다.