SSH 백도어링
악의적이거나 보안에 취약한 관리자는 특정 라이브러리에 악성 코드를 삽입했습니다. 리블즈마xz 압축 도구 및 라이브러리의 일부인 이 취약점을 이용해 SSH에 백도어를 만들었습니다. 이는 고도화된 소프트웨어 공급망 공격으로, 해당 라이브러리는 백도어를 포함하도록 의도적으로 수정되었으며, 공격 페이로드를 검토자로부터 숨기기 위해 난독화 및 은밀화 기법이 사용되었습니다.
이 문제는 최근(3월 29일)에 발견되어 공개되었으며, 공격 대응은 현재 진행 중입니다. 하지만 이 공격은 제한된 환경(x86_64 아키텍처용 DEB 및 RPM 패키지, GCC로 빌드된 버전)의 사전 출시 버전에만 영향을 미치는 것으로 보여 빠르게 차단되었습니다. CVE 주었습니다 CVSS 기본 점수 10점 만점에 10점을 주는 이 점수는 가장 심각한 사이버 보안 취약점에만 부여됩니다. 만약 이 취약점이 안정적인 배포판에 포함된다면 그 영향은 엄청날 것입니다.
공격에 대한 기술적 분석에는 다음 사항이 포함됩니다. xz 백도어에 대한 심층 분석이 내용은 다른 곳에서 분석되었습니다. 이 글에서는 공격 발생 시점, 탐지 방법, 현재까지의 사건 처리 과정, 그리고 이 공격에서 얻을 수 있는 교훈에 대해 중점적으로 다루겠습니다.
백도어의 긴 흔적은 초기 패치 이후에도 계속 남아 있었습니다. CVE-2024-3094가 공개된 지 1년이 넘은 2025년 8월, 보안 연구원 Binarly는 Docker Hub에 게시된 12개의 Debian Docker 이미지에서 여전히 백도어가 존재하는 것을 발견했습니다. Debian 팀은 이를 활성 위험 요소가 아닌 과거 개발 과정의 결과물로 간주하여 제거를 거부했습니다. 이와는 별도로, OpenSSF XZ 사건 직후 OpenJS는 유사한 사회공학적 공격을 통한 자바스크립트 프로젝트 탈취 시도가 이미 발생했다는 공동 경고를 발표했는데, 이는 여기서 사용된 유지보수자 신뢰도 공격 패턴이 다른 곳에서도 재사용되고 있음을 시사합니다.
XZ 백도어가 어떻게 삽입되었는지
참고: Git 저장소는 다음 위치에 있습니다. git.tukaani.org. 그러나, 또한 다음과 같은 것이 있었습니다. GitHub에 호스팅된 저장소 (현재 차단됨) GitHub 계정이 나중에 Git 저장소에 통합될 변경 사항을 게시했던 곳입니다.
백도어의 일부는 5.6.0 및 5.6.1 버전의 배포된 tarball에만 존재하고 Git 저장소에는 없으며 특정 요소에 의존하는 것으로 보입니다. build-to-host.m4 파일의 한 줄 autoconf에서 사용하는 매크로 파일입니다. 나머지 부분은 두 개의 테스트 파일로 추정되는 파일에 있었습니다. bad-3-corrupt_lzma2.xz 좋은 대형 압축.lzma
그랬어. commit널어서 말리다 GitHub 계정 "Jia Tan"에 의해지아T75)에의 xz 저장소 2월 23일에 테스트 파일(.lzma 및 .xz로 압축된 블록)을 추가하는 사소한 변경 사항이 있었습니다. 흥미롭게도 테스트 파일은 테스트에서 사용되지 않았습니다! .m4 파일의 한 줄은 특정 조건이 충족될 경우 구성이 완료된 후 실행되도록 난독화된 스크립트(tarball에 포함됨)를 삽입합니다. 이 스크립트는 Makefile을 수정합니다. 리블즈마 이 라이브러리는 .xz 파일에서 데이터를 추출하는 코드를 포함하며, 난독화 해제 후 최종 결과가 나옵니다. 이 스크립트에서`configure` 함수는 `configure` 프로세스의 마지막에 호출됩니다. 이 함수는 빌드 프로세스를 수정하여 코드를 삽입할지 여부를 결정합니다. 수정 대상은 GCC 컴파일러와 GCC 링커를 사용하는 경우, Debian 또는 rpm을 사용하는 경우, 그리고 x86_64 Linux 배포판인 경우입니다. 조건이 충족되면 삽입된 코드는 두 개의 `read` 문을 대체하여 실행을 가로챕니다. 이펑 리졸버를 사용하면 특정 호출이 대체됩니다. 이로 인해 심볼 테이블이 메모리에서 파싱됩니다(이 과정은 시간이 걸리며, 나중에 설명하겠지만 이것이 탐지의 원인이 되었습니다).
그다음부터 흥미로운 상황이 펼쳐집니다. 백도어는 동적 링커에 감사 후크를 설치하고, RSA_public_decrypt 함수 심볼이 도착하기를 기다립니다. 이 심볼은 백도어 코드 내부의 특정 지점으로 리디렉션되고, 백도어 코드는 다시 콜백 함수를 호출합니다. 라이브러리 크립토아마도 일반적인 인증을 수행하기 위한 것일 겁니다. 그리고 실행 중인 프로그램의 프로세스 이름이 지정된 경우 페이로드가 활성화됩니다. /usr/sbin/sshdSSH 서버가 공격 대상이라는 것이 분명했습니다. 전통적으로, sshd를 OpenSSH와 같은 서버는 연결되어 있지 않았습니다. 리블즈마하지만 sshd는 자주 패치됨 systemd-notify를 지원하여 sshd가 실행 중일 때 다른 서비스가 시작될 수 있도록 합니다. 그런 다음 liblzma는 간접적으로 로드됩니다. 시스템그렇게 원을 마무리 짓습니다.
백도어에 대한 분석은 아직 완전히 이루어지지 않았지만, 가능성이 있어 보입니다. 원격 명령 실행 허용 (RCE) sshd 데몬의 권한으로사전 인증 컨텍스트에서 실행됩니다. 원격 인증서의 정보는 백도어와 일치하면 ChaCha20으로 복호화되고, 복호화에 성공하면 해당 정보가 전달됩니다. 체계()그러므로 이것은 본질적으로 게이트형 원격 코드 실행(RCE)이며, 단순한 공개 키 우회보다 훨씬 더 심각한 문제입니다.
이후 배포된 5.6.1 버전의 tarball에는 흔적을 숨기기 위한 추가적인 노력이 담겨 있었는데, 심볼 이름에 대한 난독화를 강화하고 발견된 오류를 수정하려는 시도가 포함되었습니다. 확장 메커니즘 특정 서명을 찾기 위해 추가 테스트 파일을 검색하여 백도어에 추가하는 기능도 마련되었습니다.
이처럼 상당히 정교한 공격은 안정적인 리눅스 배포판이 나올 때까지 눈치채지 못할 수도 있습니다. 다행히도, 비정상적인 일이 발생하는 이유를 알아보려는 사람들이 있습니다.
XZ 백도어 공격 발견
악성 행위가 주입된 경우, 우연이나 사고로 인해 발견되는 경우가 많습니다. 좋은 예로는 다음과 같은 것이 있습니다. 사용 중단 경고 ("경고 따위 누가 신경 써?")라는 말이 결국 발견으로 이어졌습니다. 이벤트 스트림 공격 2018년 10월에. 또 다른 한 명은 경고를 보낸 사용자입니다. 코드코브 2021년 4월에 그들의 bash 업로더 스크립트가 체크섬 검사를 통과하지 못했다고 밝혔습니다("누가 체크섬으로 아티팩트의 무결성을 검증합니까?"). SSH 관련 이상 증상 및 특이 증상 loginsloginCPU 사용량이 많고 실행 시간이 늘어나며 Valgrind 오류가 발생하는 현상이 호기심을 자극했습니다. 안드레스 프로인드그는 경계심이 강한 PostgreSQL 개발자이지만 보안 분석가는 아니라고 본인이 밝혔다.데비안 시드(Debian Sid)에서 OpenSSH를 사용하여 몇 가지 조사를 진행한 후, 그는 응답 시간 문제가 특정 라이브러리 때문이라는 결론을 내렸습니다. 리블즈마,의 일부 xz 유틸리티 압축 라이브러리. 이유: “상위 xz 저장소와 xz tarball에 백도어가 심어졌습니다."이 진단은 정말 정확했어요!" 2024년 3월 29일, Andres는 Openwall에 첫 번째 분석 글을 게시했습니다.상위 xz/liblzma의 백도어로 인해 SSH 서버가 손상되었습니다.사실: XZ Utils 5.6.0 및 5.6.1 tarball에는 백도어가 포함되어 있습니다. 이 tarball은 앞서 언급한 Jia Tan 계정으로 생성 및 서명되었습니다. He 마스토돈에 게시됨 그날 늦게, 그는 그 발견이 우연이었고 많은 우연의 일치가 필요했다는 것을 깨달았습니다. 다른 사용자들의 댓글도 읽어볼 만합니다. GitHub 사용자 똑같은 (샘 제임스라고도 함)이 좋은 요약본을 게시했습니다. xz-utils 백도어 관련 FAQ 공격 내용이 요약되어 있으며, 더 많은 내용과 연결되어 있습니다. 심층 분석 공격 페이로드의 일부입니다. 이러한 분석은 기술적으로 매우 흥미로웠고, 고도로 정교하게 설계된 주입 과정을 더 잘 이해하는 데 도움이 되었습니다.- xz/liblzma: Bash 단계 난독화 설명인젝션 스크립트에 의한 난독화 해제 과정을 4단계로 나누어 잘 분석하셨네요.
- 필리포 발소르다의 블루스카이 스레드 RSA_public_decrypt 백도어 자체를 분석한 결과, 그 특성이 드러났습니다. 이는 인증 우회가 아닌 원격 코드 실행(RCE) 공격이며, 게이트형(작성자의 개인 키를 허용하고, 허용하지 않을 경우 정상 동작으로 복귀)/복구 불가능한 공격입니다. 공격자는 탐지를 피하기 위해 눈에 띄지 않게 행동하려 했습니다!
- @smx-smx 님의 XZ 백도어 분석 (진행 중) – 백도어에 대한 추가 분석 (처음에는 거의 길을 잃을 뻔했어요 😀)
- xz 백도어 문서 위키5.6.1 인젝션 스크립트에 대한 또 다른 분석입니다.
사건 처리 방식
안드레아스 프로인트가 신중하게 정보를 공개한 이유는 그의 말에 따르면 다음과 같습니다."상위 프로젝트 관련성이 분명해 보이므로 상위 프로젝트 버그를 보고하지 않았습니다. 처음에는 데비안 관련 문제라고 생각하여 security@...ian.org로 예비 보고서를 보냈습니다. 그 후 distros@에 문제를 보고했습니다." CISA는 배포를 통해 통보를 받았습니다.
누가 공격받고 있는 건가요?
GitHub의 JiaT75 계정이 해킹당했거나(GitHub가 최근 2단계 인증을 의무화했음을 기억하십시오) 계정 소유자가 범죄에 연루되었을 가능성이 있습니다. 하지만 공격의 기술적 정교함을 고려할 때, 고도화된 지속적 위협(APT), 어쩌면 국가 지원 공격일 가능성도 충분히 제기됩니다. 사이버 보안 기관과 사법 당국의 추가 조사를 통해 진실이 밝혀질 것입니다. 이 항목 YCombinator Hacker News에서 Jia Tan에 대한 기사 이 책은 범인이 누구인지, 그리고 그의 활동이 무엇인지 밝혀줍니다. 추천합니다! 악당들이 사회공학적 기법을 이용해 다른 사용자들을 속이려는 방식에 대한 많은 정보를 제공합니다."정말 짜증나는 일입니다. 백도어를 만든 것으로 추정되는 사람이 몇 주 동안 저(rwmj)와 연락을 주고받으며 xz 5.6.x 버전을 페도라 40 및 41에 추가해 달라고 요청했습니다. 그 이유는 xz의 '훌륭한 새 기능' 때문이라고 했죠. 심지어 그와 함께 발그라인드 문제를 해결하기도 했습니다(나중에 알고 보니 그 문제는 그가 추가한 백도어 때문에 발생한 것이었습니다). 어젯밤에는 실수로 엠바고가 깨지는 바람에 문제를 해결하기 위해 정신없이 바빴습니다. 그는 2년 동안 xz 프로젝트에 참여하면서 온갖 종류의 바이너리 테스트 파일을 추가해 왔는데, 솔직히 이 정도 수준의 전문성을 보면 증명이 나기 전까지는 xz의 이전 버전조차도 의심스러울 것 같습니다."
지아 탄은 추적을 방지하기 위한 조치를 취했습니다. VPN(vpn.singapore.witopia.net)을 사용하여 접속한 것으로 보이는데, 이는 그 자체로는 문제가 없습니다. 또한, 많은 변경 사항은 (이 경우 ProtonMail에서 발송된) 일회성 이메일을 통해 변경 사항 병합을 촉구하는 방식으로 이루어진 것으로 보입니다.
해당 행위자는 리눅스 커널까지 더 깊이 파고들려는 의도가 있을지도 모릅니다. 왜냐하면 그는 해당 프로젝트의 기여자이기 때문입니다. xy에 내장된 해당 프로젝트. 현재까지 초기 분석 결과 유산의 증거는 발견되지 않았습니다.
참고: 또 다른 잘 알려지지 않은 XZ 기고가 "한스 얀센" (GitHub 사용자 "hansjans162")는 철저한 조사 아래데비안에서의 해당 계정은 현재 다음과 같습니다. 차단그는 데비안 게임즈를 여러 차례 업데이트하여 자신이 debian/xz-utils에 심어놓으려던 백도어를 숨겼고, 업스트림 5.6.1 버전을 업데이트하여 백도어 배포를 서두르려 했습니다. 데비안/불안정.
현재로서는 이것이 (아직 신원이 확인되지 않은) APT 공격이며, 여러 계정을 사용하고 최소 2년 동안 이 캠페인을 진행해 왔으며, SSH에 원격 코드 실행(RCE) 취약점을 심기 위해 꾸준히 노력해 왔다는 것만 말씀드릴 수 있습니다.
이 글을 쓰는 시점까지 "자 탄"의 정체는 확인되지 않았습니다. 특정 개인, 조직 또는 국가 기관을 지칭하는 신뢰할 만한 증거는 공개적으로 확인되지 않았으며, 이는 해당 인물의 작전 수행 능력이 얼마나 뛰어났는지를 보여줍니다.
XZ 백도어 공격은 예방할 수 있었을까요?
꽤 어렵습니다.
첫째, 주입된 백도어의 일부가 테스트에서 사용되지 않는 압축된 테스트 파일에 포함되어 있었습니다. 나중에 생각해 보면 이는 (과도한) 경고를 발생시킬 수 있겠지만, 실제 환경에서 모든 테스트 파일이 실제 테스트에 사용되는지 확인하는 데 누가 신경 쓰겠습니까? 둘째, 주입된 백도어의 일부가 릴리스 tarball에 포함된 매크로 파일에 포함되어 있었는데, 예상되는 tarball과의 차이점을 수동으로 확인하기가 어렵습니다. 또한 자동화도 복잡한데, (automake/autoconf 작동 방식을 아는 사람이라면 누구나 알 수 있듯이) 빌드 자체의 예상 결과를 모델링하여 실제 tarball이 예상과 일치하는지 분석하기가 어렵기 때문입니다. 몇몇 사람들이 그것을 게시했습니다. as "tarball 파일이 Git 트리와 일치하지 않는 것은 버그가 아니라 기능입니다."소스 코드에서 바이너리 tarball의 출처를 추적하는 것은 아직 해결되지 않은 문제입니다.
사용자 평판이요? 글쎄요, JiaTan75의 GitHub 계정은 과거 기록에 따르면 악의적인 행위를 하지 않았습니다. commit증거가 축적된 후에야 계정이 정지되었지만, 3월 29일까지는 일반 사용자가 정상적인 거래를 하고 있었습니다. 뭐, 그렇게 정상적이라고는 할 수 없지만요. 나중에는요. commits이, 이, 이예산 및 이 (익스플로잇 코드를 수정하여) 백도어가 예상하는 스택 레이아웃과의 차이로 인해 일부 구성에서 발생하는 Valgrind 오류 및 충돌을 수정하려고 시도했습니다. Commit 리뷰를 통해 이를 감지할 수는 있겠지만, 바이너리 테스트 파일의 변경 사항이나 C 소스 코드에서 GCC 속성을 변경하는 진짜 이유를 분석할 인내심을 가진 사람이 누가 있겠습니까?
SSH 연결 시 경보를 울려야 할까요? login 300ms 대신 800ms가 걸린다고요? 아마도 지나치게 신중한 사람들만 알아챌 겁니다. 키케로는 이렇게 말했죠. “경솔함은 젊은 시절에, 신중함은 노년 시절에 어울린다.”
ifunc 인프라는 2023년 6월에 "Hans Jansen"과 "Jia Tan"에 의해 추가되었습니다. 이것은 첫 번째입니다. commit crc64_fast.c에 ifunc 지원을 추가했습니다(이후 백도어를 주입하는 데 사용됨). 백도어 바이너리를 테스트 파일에 주입하기 몇 달 전의 일입니다!
참고: 저자 및 commit여기서 의견이 다를 수 있지만, 이는 정상적인 현상입니다. 라세 콜린이 프로젝트 관리자이며, 그가 변경 사항을 병합했기 때문입니다. 그는 심지어 "한스 얀센"에게 감사를 표하기도 했습니다.
안드레스 프로인트의 게시글과 레드햇이 생성한 CVE가 나오기 전에는 아무도 우려를 제기하지 않았습니다. 이제 이 문제를 감지하는 여러 도구들이 배포되면 영향을 받는 구성 요소를 제대로 탐지할 수 있습니다. 사후.
아마도 가장 효과적인 예방책은 리눅스 배포판의 특성, 즉 불안정하고 최첨단 버전이 단계적인 과정을 거쳐서야 안정적인 배포판으로 전달되는 방식에 있었을 것입니다.
XZ 백도어 공격에서 얻은 교훈
우리는 탐지하기가 얼마나 어려운지 주목했습니다. 계획적인 백도어는 내부 위협으로 간주해야 합니다. 내부 직원이 심거나 내부 계정이 해킹당했을 때 설치되기 때문입니다. 그리고 이러한 사람들은 대부분 신뢰받는 사람들입니다. 또한 백도어가 배포된 아티팩트에 심어져 있으면 탐지하기가 더욱 어려워집니다.
케빈 보몬트 같은 작가들 지적하다 체계이는 타사 서비스에 백도어를 설치할 수 있는 광범위한 공격 표면을 열어줍니다. 악의적인 공격자가 바로 이 점을 악용한 것입니다. Systemd는 많은 사람들이 사용하지만, XZ는 상위 계층에 있는 잘 알려지지 않은 라이브러리입니다. "상류가 오염되면 하류의 모든 사람들이 독이 든 물을 마시게 된다"는 말이 있습니다.
시스템 관련 없는 변경 요청 압축 라이브러리를 동적으로 로드합니다.백도어를 제거하는 기능은 이미 시스템에 통합되었지만 아직 배포되지 않았습니다. libsystemd로 인해 추가되는 종속성이 취약점의 원인이 될 수 있습니다.그리고 어제 이 요청이 접수되었습니다.
A 본문 "xz: ifunc를 비활성화하여 문제를 해결하세요"에서 commit 그러한 활동을 예방하려면 어디에 초점을 맞춰야 하는지에 대한 날카로운 통찰력을 제공했습니다(강조는 제가 했습니다).
"우리 공동체가 배워야 할 교훈은 안전을 확보하는 데 더 집중해야 한다는 것입니다." software supply chain security 소스 코드 감사뿐 아니라 빌드 시스템 전체를 종합적으로 감사해야 합니다. 예를 들어, SolarWinds 해킹 사건처럼 공격자들이 SolarWinds의 비공개 소스 모니터링 소프트웨어 제품의 소프트웨어 업데이트를 변조한 사례가 있습니다.
FAQ
XZ 백도어는 오늘날에도 여전히 위험한 요소인가요?
대부분 차단되었지만 완전히 사라진 것은 아닙니다. 2025년 8월, 연구원들은 데비안에서 비활성 과거 유물로 취급하는 여러 데비안 도커 허브 이미지에서 백도어가 여전히 존재하는 것을 발견했습니다. 개발팀은 2024년 패치로 백도어가 완전히 차단되었다고 가정하기보다는, 오래되고 패치가 적용되지 않은 기본 이미지를 사용하고 있지 않은지 확인해야 합니다.
