xz 타협에 대한 심층 분석

이 블로그 글의 AI 요약으로 바로 가기

xz는 사용자와 개발자 모두에게 무손실 압축을 제공하는 널리 배포된 패키지로, 전부는 아니더라도 대부분의 Linux 배포판에 기본적으로 포함되어 있습니다. 2009년에 만들어진 이후 수많은 버전이 출시되었습니다.

오픈 소스 프로젝트인 이 프로젝트는 GitHub에서 사용할 수 있습니다. 그러나 이 글을 작성하는 시점을 기준으로 이 프로젝트의 프로젝트 페이지 를 방문하면 기존의 GitHub 페이지 대신 "이 리포지토리는 서비스 약관 위반으로 인해 사용 중지되었습니다"라는 메시지가 표시됩니다. 이 위반은 멀웨어 배포로 인한 것입니다. 이 글에서는 이 사건의 내용, 이유, 방법, 심지어는 배후에 있는 '사람'에 대해 자세히 살펴봅니다.

부활절 직전 주 후반에 이 소식이 전해지자 트위터의 사이버 보안 영역은 폭발적으로 증가했고, 인터넷 탐정들은 모든 세부 사항에 집착했습니다. 이 글은 이러한 조사를 통해 수집 및 공개된 정보를 바탕으로 작성되었으며, 그 중 상당 부분이 통합되어 있습니다. 여기와 저자의 자체 조사를 통해 수집한 정보를 바탕으로 작성되었습니다. 출처는 가능한 경우 원래 출처로 다시 링크하여 제공되며, 직접적인 출처가 링크되어 있지 않은 경우 독자는 다음 중 하나에서 가져온 것으로 간주할 수 있습니다. GitHub 요점 이벤트 요약 또는 이 타임라인.

이 이야기는 매우 최근의 일이라는 점을 기억하세요. 아직 해결되지 않은 부분이 있으며, 원래 사건의 배후라고 믿었던 사람이 반드시 그런 것은 아닐 수도 있다는 (가능성이 희박한) 힌트도 있습니다. 이에 대해서는 이 도움말의 주의 사항 섹션에서 자세히 설명합니다.

안전벨트를 매세요. 이번엔 토끼굴이 깊숙이 들어갑니다.

역사적 맥락

다른 많은 오픈소스 프로젝트와 마찬가지로 xz 프로젝트는 한 개발자가 아이디어를 갖고 이를 전 세계와 공유하기 위해 시작한 개인 프로젝트로 시작되었습니다. 2009년에 또 다른 압축 관련 프로젝트인 lzma-utils의 유지보수를 담당했던 Lasse Collins가 xz를 만들었습니다. 이 프로젝트는 lzma의 확장 또는 진화로 설계되었으며, 현재 liblzma는 기본적으로 xz 패키지의 일부로 제공되고 있습니다.

대부분의 1인 프로젝트가 그렇듯이 작성자는 코드의 대부분을 담당하고 가끔씩 타사에서 들어오는 커밋을 관리하고 코드를 리포지토리에 통합하고 새 버전을 게시하는 일을 담당했습니다. 프로젝트가 주목을 받으면서 관리의 부담이 커졌고, 결국 다른 기여자들이 그 노력을 인정받아 코드 검토, 제출 수락 또는 거부, 리포지토리 관리 등의 작업을 관리할 수 있는 권한을 부여받게 되었습니다.

이전에 프로젝트에 기여했던 개발자 Jia Tan은 2년 조금 전에 커밋 및 릴리스 관리 권한을 부여받았습니다. 돌이켜보면, 새로운 관리자를 추가하는 과정은 라세 콜린스를 노린 소셜 엔지니어링 캠페인의 일부였던 것 같습니다. 이러한 이메일 교환의 타임라인은 여기.

프로젝트를 포기하거나 흥미를 잃었다는 압박과 비난을 받은 여러 사용자(또는 여러 사용자 아이디를 사용하는 한 개인)가 프로젝트의 메일링 리스트에 메시지를 보냈습니다. 이들은 패치 수락, 새 버전 출시, 다른 방법 채택이 지연되는 것에 대해 불만을 토로했고, 프로젝트 리더는 열성적인 새 기여자에게 의존하기 시작했습니다. 이러한 압박 전술의 배후에 있는 이메일 계정은 다음과 같은 특징을 보입니다. 해당 메일링 리스트 외에는 인터넷에 존재하지 않습니다..

xz는 시스템에서 Linux 커널을 패키징하는 데 사용할 수 있는 압축 형식 중 하나로, 시스템 부팅에 없어서는 안 될 필수 요소입니다. 달성된 압축률과 압축 해제 속도는 공간 효율적인 릴리스, 커널 이미지 및 기타 구성 요소를 위한 완벽한 옵션입니다.

잃어버린 시간

아이러니하게도 운명의 장난처럼, Microsoft의 소프트웨어 엔지니어인 안드레스 프라운드는 관련 없는 작업의 기준선을 설정하기 위해 Linux 가상 머신에서 타이밍 측정을 수행하던 중이었습니다. 그는 측정값에서 약간의 '노이즈'를 발견하기 시작했습니다. 원격 보안 셸 연결을 수락하는 sshd 프로세스는 연결 시도가 실패할 때에도 과도한 양의 CPU를 사용하고 있었으며, 500ms의 지연이 연결에 영향을 미치고 있었습니다. 설명할 수 없는 이 지연으로 인해 Freund는 성능 모니터링(perf) 및 디버깅(dbg) 도구를 사용하여 문제를 파악하기 위해 추가 조사를 진행했습니다.

그는 에서 백도어를 발견했습니다.. 특히, 그는 백도어와 삽입된 코드를 확인했는데, 백도어는 sshd가 호출하는 특정 함수에 피기백하여 작동합니다. 눈썰미가 좋은 독자라면 이미 알고 계시겠지만, sshd는 xz나 liblzma에 의존하지 않는다는 점에 유의해야 합니다. 그러나 시스템d를 사용하여 sshd를 로드하는 시스템에서는 시스템d에 liblzma가 종속성으로 포함됩니다. 이 연결로 인해 백도어 코드가 sshd에 도입될 수 있었습니다. 이 범주에 속하는 시스템에는 Fedora, Ubuntu, Debian 및 대부분의 파생 배포판이 포함됩니다.

백도어

이 코드가 xz(및 liblzma)에 도입된 방법은 xz 리포지토리에 추가된 몇 개의 바이너리 파일과 손상된 빌드 프로세스를 포함했습니다. 이 파일들은 원래 xz에 대한 "테스트 스위트"의 일부로 Jia Tan이 제출한의 "테스트 스위트"의 일부로 제출한 바이너리 블롭으로, "헥스 편집기로 수작업으로 만든" 파일이었습니다. 소스 코드를 읽는 것은 이미 복잡한 작업이지만 바이너리 코드를 읽는 것은 거의 불가능에 가깝습니다. "파일 자체보다 더 좋은 소스 코드는 없다"는 우스갯소리가 있을 정도입니다. 맞습니다.

악성 파일을 포함한 커밋은 2024년 2월 23일에 이루어졌습니다. 현재 알려진 바로는 악성 코드는 바이너리 파일 중 두 개에만 존재하며, 나머지 파일은 의도된 기능을 수행하는 것으로 보입니다(xz 및 liblzma의 압축 또는 압축 해제 프로세스에서 다양한 조건을 테스트하여 실패를 확인).

백도어의 주목할 만한 측면 중 하나는 임의의 사용자가 xz 리포지토리에서 코드를 가져와 백도어가 포함된 후 빌드해도 손상된 바이너리가 발생하지 않는다는 것입니다(현재로서는 그렇지만 나중에 잘못된 것으로 판명될 수도 있습니다). 실제 인젝션 코드는 컴파일 중에 특정 "build-to-host.m4" 파일이 있는 경우에만 출력에 포함되지만 이 파일도 ".gitignore"에 추가되어 최종 사용자가 일반적으로 사용하는 일반적인 git 작업에는 액세스할 수 없습니다. 그러나 이 파일은 Linux 배포판의 패키지 빌드 프로세스 중에 사용됩니다.

이 접근 방식은 보안 연구자들이 통제된 환경에서 사고를 복제하기 어렵게 만드는 동시에 실제 Linux 배포판에 코드를 적용하는 데 매우 효과적이었습니다.

악성 파일을 추가한 지 하루 뒤인 2월 24일, 동일한 사용자가 xz-5.6.0에 태그(의미: 다음 버전으로 표시됨)를 붙였습니다. Linux 배포판은 일반적으로 새 버전의 패키지를 가져오며, 예를 들어 Debian은 며칠 후 불안정한 리포지토리에 이 패키지를 포함시켰습니다.

28일에 빌드 과정에서 육지 탐지를 방해하는 Jia Tan의 추가 패치가 추가되었습니다.. 랜드락은 컴파일 중에 활성화될 경우 트리거되는 코드의 불필요한 링크 및 가져오기를 방지하는 보안 기능으로, 공격이 성공하려면 이를 우회해야 했습니다.

이것은 매우 미묘한 방식으로 이루어졌습니다. "."(점) 하나만 추가하면 샌드박스 검사의 컴파일이 중단되어 내륙 탐지가 항상 거짓을 반환하고, 그 결과 악성 코드에 대해 항상 비활성화됩니다. 이 변경 사항은 제출 당시에는 감지되지 않았습니다. 중요한 것은 이 커밋이 Jia Tan이 아닌 Lasse Collins의 이름으로 되어 있다는 점인데, 이는 위조되었거나 코드를 추가하기 전에 미묘한 변경이 발견되지 않았을 수 있습니다.

특히, 2월 29일에 시스템드 프로젝트의 시스템드 프로젝트에 대한 풀 리퀘스트가 이미지 크기를 줄이기 위해 liblzma 링크 중지를 요청했습니다. 이 요청이 있었다면 공격을 막을 수 있었을 것입니다. 이 이벤트는 실제 공격과는 무관한 것으로 보이며 우연의 일치로 타임라인을 앞당겼을 수 있으며, 해당 주제에 대한 이전 대화가 공개되어 공격자에게 알려졌는지는 알 수 없습니다.

악성 코드를 호출하는 함수는 _get_cpuid입니다. 아직 발견되지 않은 다른 함수가 있을 수 있습니다. 이 함수는 악성 페이로드 코드를 실행한 후 원래 _get_cpuid 작업을 수행하고 반환하며, Microsoft 엔지니어가 발견한 지연 시간을 추가합니다. 더 구체적으로 이 함수는 연결을 시작할 때 인증서 유효성 검사 프로세스 초기에 호출됩니다.

일부 분포에서는 분석 중에 해당 함수에서 밸그라인드 오류가 관찰되기 시작했습니다. 3월 8일, Jia Tan 은 발그라인드 탐지를 해결하기 위한 코드를 제출했습니다.를 해결하는 코드를 제출했는데, 지금 생각해보면 단순히 악성 코드의 분석을 비활성화하는 것으로 보입니다.

다음 날인 3월 9일, 지아 탄은 "백도어 파일이 자신의 컴퓨터에서 무작위로 생성되었으며, 향후 더 나은 재현을 위해서는 일정한 시드 값을 사용해야 한다"는 구실로 백도어 파일을 업데이트했습니다. 바이너리 파일은 분석이 어렵고, 특히 백도어 코드가 바이너리 블롭 내에서 미리 정의된 위치에서 값을 선택하기 때문에 탐지가 사실상 불가능합니다. 같은 날, 그는 xz-5.6.1을 태그하고 릴리스했습니다.

3월 25일, xz의 원래 관리자에게 압력을 가하는 데 사용된 이메일 계정 중 하나가 다시 등장했습니다. 데비안 프로젝트에 xz의 새 버전을 포함하도록 압력을 가하고 있습니다.. 유령 계정으로 보이는 다른 계정들도 압력을 가하기 위해 합류했습니다.

3월 28일, 지아 탄이 버그 리포트를 제출했습니다. 우분투에 xz-5.6.1 포함에 대한 버그 리포트를 제출했습니다.을 포함시켜 달라는 버그 리포트를 제출했습니다.

악의적인 동작은 특히 glibc를 실행하는 x86-64 시스템을 대상으로 합니다. 를 실행하고(glibc에서 제공하는 함수에 따라 다름) systemd를 통해 sshd를 실행하는 x86-64 시스템을 대상으로 합니다. 이 조건 세트는 데비안 기반 및 레드햇 기반 배포판과 일치합니다.

악성 코드의 난독화 해제 및 분석 결과, 이 악성 코드는 sshd에서 들어오는 연결이 수신될 때마다 활성화되는 것으로 나타났습니다. 최근에야 이 악성 코드가 코드는 연결 수신 시 특정 공개 키를 기대합니다.. 이 키가 없는 경우 sshd는 정상적으로 작동합니다. 그러나 공격자가 제어하는 키가 있으면 이 코드는 원격으로 제어되는 다른 동작을 트리거합니다.

탐지, 그리고 오픈 소스 세계가 흔들리고 있습니다.

3월 28일, 안드레스 프룬트의 조사로 백도어가 발견되었습니다. 배포에 대한 공지가 이루어졌고, 기본적으로 Jia Tan이 xz 프로젝트에 관여하기 이전 버전으로 패키지를 롤백하는 업데이트가 릴리스되었습니다. 즉, 이제 "5.6.1+really5.4.5" 버전의 xz를 여러 배포판의 저장소에서 사용할 수 있게 되었습니다.

지금까지 손상된 패키지의 존재를 인정한 배포판에는 Fedora Rawhide, Fedora 40 베타 및 Debian이 있습니다.

xz는 패키지 빌드 프로세스 자체에서 중요한 역할을 했기 때문에, Debian 프로젝트는 (백도어가 포함되기 전에) Jia Tan의 패치가 포함된 xz 버전을 실행하고 있었기 때문에 전체 빌드 시스템을 다시 빌드하기로 결정했습니다.

공급망 공격은 그 범위가 엄청날 수 있습니다. 이는 흔히 언급되지만, 이번 공격과 같이 명확하고 명백한 증거가 있을 때만 진정으로 분명해집니다.

이 상황을 분석하면 몇 가지 문제가 분명해집니다:

첫째, 적절한 자금과 리소스 없이 오픈소스 프로젝트가 운영되는 방식은 관리자가 부담을 느끼고 속아서 이상적이지 않은 타협을 받아들일 수 있는 상황을 초래할 수 있습니다. 이러한 취약점을 통해 위협 행위자가 침투하여 결국 주요 프로젝트에 대한 통제권을 확보할 수 있습니다.

둘째, xz는 적발된 프로젝트일 뿐입니다. 악성 코드로 인한 지연이 아니었다면, 시간을 더 갖고 최적화할 수 있었다면 이 공격은 전혀 탐지되지 않았을 수도 있고, 결국 모든 사람이 Debian 및 Red-Hat 기반 시스템에서 손상된 버전의 xz를 실행하고 있었을 것입니다. xz를 되돌리면 이 특정 위협이 무력화되었다고 가정합니다. 그러나 이 주장의 확실성은 현재로서는 불분명합니다.

셋째, 수많은 프로젝트에서 매일 매 순간 오픈소스 프로젝트에 코드가 추가됩니다. 종속성을 사용하고 검사하는 방식은 공격자가 의도한 표적 패키지에 악성 코드가 직접 닿지 않더라도 일련의 잘못된 경로를 통해 의도한 표적에 도달할 수 있게 합니다.

넷째, 오픈 소스 코드가 단순히 공개되어 있기 때문에 더 안전하다는 주장은 근거 없는 주장입니다. 이 주장은 모든 프로젝트의 모든 코드 줄, 모든 커밋을 면밀히 검토하는 충분하고 충분한 동기를 가진 개인이 있을 때만 해당됩니다. 이를 위해서는 고도로 숙련된 수많은 사람이 무기한으로 상당한 양의 무급 업무를 수행해야 합니다. 코드를 검사하고 심사하는 기능은 실제로 검사 및 심사가 수행되는 경우에만 효과적입니다. 그럼에도 불구하고 악성 코드의 본질과 난독화에 사용할 수 있는 방법으로 인해 의심하지 않는 프로젝트에 악성 코드를 삽입할 수 있습니다. 사실, 보안 관점에서 볼 때 소스 코드의 가용성은 최종 사용자에게 도움이 되는 것보다 취약점을 파악하려는 악의적인 공격자에게 더 큰 도움이 될 수 있다고 주장할 수도 있습니다. 오픈 소스 코드는 부인할 수 없는 많은 이점을 제공하지만, 내재적 보안이 항상 그 중 하나는 아닙니다. 이 백도어는 전적으로 우연히 발견되었습니다.누군가 코드를 적극적으로 검토했기 때문이 아니라 우연히 발견되었습니다.

다섯째, 오픈 소스 커뮤니티에서 평판을 쌓는 것은 다른 어떤 것도 없이 오직 GitHub의 커밋 기록에만 의존하는 경우가 많습니다. 프로젝트에 관심을 보이고 일부 코드 수정에 기여하는 것만으로도 인정받는 경우가 많습니다. 돕고자 하는 열의를 보여주는 것은 쉽게 조작될 수 있습니다. 따라서 익명 계정의 배후에 있는 특정 개인을 식별하는 것은 매우 어렵습니다. 한 사용자가 여러 개의 계정을 보유하거나 계정이 의심되거나 악의적인 것으로 확인되면 가짜 계정을 만들 수 있습니다. 충분한 리소스를 갖춘 조직은 이러한 계정을 만들고 인력을 배치할 수 있습니다.

여섯째, 대부분의 오픈소스 프로젝트에는 명확하게 정의된 재해 복구 계획이 없는 경우가 많습니다. 알려진 정상 상태가 무엇인지조차 파악하기 어려운 경우 정상 상태로 되돌리기란 쉽지 않습니다. 이번 공격의 원인으로 한 계정이 지목되고 있지만, 이 계정이 유일하게 사용된 계정인지 여부는 불확실합니다.

가능한 주의 사항

이 사건이 어떻게 전개되었는지 분석한 결과, 모든 것이 자금력이 풍부하고 고도로 숙련된 위협 행위자 또는 그룹의 개입을 시사하는 것으로 보입니다. 주목할 만한 몇 가지 관찰 사항은 다음과 같습니다:

Jia Tan은 9시에서 5시(또는 6시)까지 근무하는 스케줄을 따르는 것으로 보입니다. 커밋 및 GitHub 활동을 보면 다음과 같은 패턴이 나타납니다.특정 국가와 일치하는 주말과 공휴일을 한눈에 알아볼 수 있습니다. 그러나 git 커밋의 타임스탬프는 마음대로 조작할 수 있으며, 백도어 코드에서 입증된 전문 지식 수준에 비하면 커밋의 시간을 변경하는 것은 사소한 일이라는 점에 유의해야 합니다.
Jia Tan은 xz 외부의 여러 프로젝트에 코드를 기여했습니다. 실제로 이 계정은 Google의 OSS-Fuzz와 다른 여러 압축 관련 프로젝트에서 악의적이거나 버그가 있는 동작을 식별하기 위해 고안된 도구에 코드를 제출하기도 했습니다. 이 모든 코드는 현재 면밀한 조사를 받고 있으며 더 이상 신뢰할 수 없습니다.
흥미롭게도 악성 파일이 업로드된 커밋의 시간대가 Jia Tan 계정과 관련된 일반적인 시간대와 다릅니다. 이 불일치에 대한 자세한 분석 내용은 여기에서에서 확인할 수 있지만, 개발자 계정이 의도적으로 사용되었다기보다는 유출되었을 가능성이 제기되었습니다. 이 가능성은 여전히 남아 있지만, 사건의 다른 측면을 고려하면 그럴 가능성은 낮습니다. 그럼에도 불구하고 고려해야 할 사항입니다.

맺음말

이 이야기는 아직 끝나지 않았을 가능성이 높습니다. 지금까지의 대응은 xz의 GitHub 리포지토리를 종료하고, 배포 패키지를 이전 버전으로 롤백하고, 책임자로 추정되는 사용자의 다른 커밋을 재평가하는 것이었습니다.

공개 질문은 다음과 같습니다:

이는 현재까지 가장 정교한 공급망 공격 중 하나입니다. 한 해커의 소행이라고 생각하기 어렵습니다. 배후는 누구일까요? 지아 탄이 작업 일정을 준수했다면 어떤 국가, 조직 또는 그룹이 급여를 지급하고 있었나요?
2년 이상 운영을 유지하려면 상당한 자원과 노력이 필요합니다. 궁극적인 목표는 무엇이었나요? 결국 모든 Debian 기반 및 Red Hat 기반 시스템이 손상되었을 것입니다. 이러한 배포판을 실행하는 모든 시스템에 액세스할 수 있다면 누가 이득을 볼 수 있을까요?
커밋 메시지에서 시간 및 표준 시간대를 쉽게 조작할 수 있습니다. 의도적으로 특정 시간대를 가리키도록 설정했나요?
모든 악성 코드가 식별되었나요? 아직 발견되지 않은 페이로드가 더 있나요?
sshd가 유일한 대상 프로세스인가요?
공격의 영향을 받은 다른 프로젝트에는 어떤 것이 있나요?

사이버 보안 분야에서 우리는 끊임없이 총알을 피하고 있습니다. 그렇지 않을 때까지는요. 그리고 신기한 것은 너무 늦을 때까지 우리를 노리는 총알을 보지 못한다는 것입니다.

IT 보안에서 CVE의 중요성을 이해하면서 일반적인 취약점 및 노출(CVE)에 대해 자세히 알아보고 싶으신가요? 리눅스토크 위드 턱스케어 유튜브 시리즈 EP2를 시청하세요.

최근 발생한 xz 침해 사고에 대해 자세히 알아보고, 어떻게 발생했는지, 오픈 소스 커뮤니티에 미치는 영향에 대해 TuxCare의 Linux 토크 유튜브 Seie 에피소드 4에서 알아보세요.

요약