▲

GN⁺: XZ 백도어 사건 - 초기 분석 결과

 (securelist.com)
2P by neo 7달전 | favorite | 댓글 1개

  • Timeline of events:

    • 2024.01.19: XZ website moved to GitHub pages by a new maintainer (jiaT75)
    • 2024.02.15: "build-to-host.m4" is added to .gitignore
    • 2024.02.23: Two "test files" containing malicious script stages are introduced
    • 2024.02.24: XZ 5.6.0 is released
    • 2024.02.26: Commit in CMakeLists.txt sabotaging the Landlock security feature
    • 2024.03.04: Backdoor causes issues with Valgrind
    • 2024.03.09: Two "test files" are updated, CRC functions modified, Valgrind issue "fixed"
    • 2024.03.09: XZ 5.6.1 is released
    • 2024.03.28: Bug discovered, Debian and RedHat notified, Debian rolls back XZ
    • 2024.03.29: Email published on OSS-security mailing list, RedHat confirms backdoored XZ shipped
    • 2024.03.30: Debian shuts down builds and starts rebuild process
    • 2024.04.02: XZ main developer recognizes the backdoor incident

  • 악성 백도어가 포함된 XZ 배포판의 해시값:

    • xz-5.6.0: MD5, SHA1, SHA256 해시값 제공됨
    • xz-5.6.1: MD5, SHA1, SHA256 해시값 제공됨

초기 감염 분석

  • Stage 1 - 변조된 build-to-host 스크립트:

    • 릴리스 소스 파일은 처음에는 무해했지만, 해커가 제어하는 URL에서 다운로드 받으면 악성 코드를 실행하는 build-to-host.m4 파일이 포함됨
    • 이 .m4 파일은 빌드 중에 실행되어 테스트 폴더에 추가된 첫 번째 파일을 수정하고 압축 해제함

  • Stage 2 - 주입된 쉘 스크립트:

    • .m4 파일로 주입된 악성 스크립트는 리눅스에서 의도된 빌드 프로세스 내에서 실행 중인지 확인함
    • good-large_compressed.lzma 파일을 이용해 다음 단계를 실행하는데, 이는 정상 압축되었지만 압축 해제된 데이터 내부에는 쓰레기 데이터가 포함됨
    • head/tail 명령으로 33,492바이트 추출하고 tr 명령으로 기본 치환 적용해 난독화 해제함

  • Stage 3 - 백도어 추출:

    • 마지막 단계 쉘 스크립트는 예상 환경에서 실행 중인지 여러 검사를 수행함
    • 동일한 good-large_compressed.lzma 파일의 다른 오프셋에 숨겨진 백도어 바이너리 코드 자체를 추출함
    • XZ 도구로 파일 추출하고 일련의 head 호출로 RC4 유사 알고리즘을 사용해 바이너리 데이터 복호화함
    • 압축된 파일을 XZ로 추출하고 predefined 값으로 시작 부분 바이트 제거한 뒤 liblzma_la-crc64-fast.o로 저장
    • crc_x86_clmul.h의 is_arch_extension_supported 함수를 수정해 __get_cpuid 호출을 _get_cpuid로 바꿈

바이너리 백도어 분석

  • 은신 로딩 시나리오:

    • XZ는 CRC 계산에 lzma_crc32, lzma_crc64 함수 사용하는데 ELF 심볼 테이블에 IFUNC 타입으로 저장됨
    • 최적화 버전 사용 여부를 동적으로 결정하기 위해 IFUNC 사용
    • 백도어는 오브젝트 파일로 저장되며 주요 목표는 컴파일시 main 실행 파일에 링크되는 것
    • 오브젝트 파일은 _get_cpuid 심볼을 포함하는데 원본 소스에서 밑줄 하나를 제거해 코드가 _get_cpuid를 호출하면 실제로는 백도어 버전을 호출하게 됨

  • 백도어 코드 분석:

    • 초기 백도어 코드는 2번 호출되며, 실제 악성 활동은 lzma_crc64 IFUNC가 _get_cpuid를 호출할 때 시작됨
    • GOT 주소를 찾아 cpuid 포인터 위치를 찾고 main 악성 함수 포인터로 교체함
    • 감염된 시스템으로의 모든 연결을 모니터링할 수 있도록 특정 함수들을 후킹하는 것이 주요 목표

  • 핵심 동작:

    • RSA_public_decrypt, EVP_PKEY_set1_RSA, RSA_get0_key 등의 libcrypto 함수를 후킹 타겟으로 함
    • 현재 프로세스가 실행 기준에 맞는지 검사하고 kill switch 존재 여부 확인
    • Trie 구조를 사용해 문자열 연산 수행
    • 3개 이상의 symbol resolver 루틴을 사용해 ELF Symbol 구조체 위치 찾음
    • rtdl-audit 기능을 남용해 symbol resolving 루틴을 하이재킹함으로써 함수 후킹 달성

GN⁺의 의견

  • 이 기사는 오픈소스 소프트웨어에 악성코드가 주입된 매우 정교한 공격 사례를 잘 보여주고 있음. 오픈소스의 장점이 역으로 악용될 수 있다는 교훈을 줌.

  • 리눅스 시스템을 노리는 사이버 공격과 백도어가 갈수록 정교해지고 있음. 특히 SSH 서버를 통한 공격이 심각한 보안 위협이 될 수 있음.

  • 한편으론 오픈소스 생태계의 자정 능력도 보여줌. 결국 백도어가 커뮤니티에 의해 발견되어 빠르게 대응되었음. 투명성이 핵심.

  • 고도화된 Trie 자료구조, Symbol Resolver, dl_audit 후킹 등의 기법이 사용된 것은 리눅스 악성코드의 기술적 진화를 보여줌. 리눅스 시스템 보안에도 각별한 주의가 필요함.

  • 기업에서 오픈소스 소프트웨어를 도입할 때는 라이선스뿐 아니라 보안 측면의 검증도 필수. 신뢰할 수 있는 배포처인지, 코드에 대한 지속적 모니터링이 이뤄지고 있는지 꼭 따져봐야 함.

▲
neo 7달전  [-]
Hacker News 의견

요약:

  • 공격자가 감지를 피하기 위해 스크립트와 코드에 많은 노력을 기울였다는 점에서, 이 프로젝트 전체가 전환이나 동시에 진행되는 여러 노력에 대한 대안으로 기능할 수 있음
  • SSHD에 초점을 맞추는 것이 시스템 전체의 다른 부분이나 기술적, 사회적 측면에 영향을 미칠 수 있음을 고려해야 함
  • 각 동적 연결 라이브러리가 자체 GOT를 가지고 동적 연결이 완료되면 테이블을 읽기 전용으로 표시하는 것이 유용한 강화 단계가 될 수 있음
  • 소스 코드는 디스어셈블러를 실행하고 코드가 무엇을 하는지 이해한 다음 설명적인 이름으로 모든 것을 바꾸는 방식으로 생성된 것으로 보임
  • 백도어의 버그로 인해 발생한 SSH의 지연과 느려짐이 결국 노출되었는데, 이에 대한 분석이 이루어졌는지 궁금함
  • xz 저장소가 GitHub에 다시 등장했으며, 유지보수자들이 ifunc 지원을 제거하고 테스트 파일을 생성하는 코드를 커밋하는 등 정리 작업을 하고 있음
  • 사람들이 발견하지 못한 백도어가 많을 것이라는 상상과 이와 같이 눈에 띄지 않은 것이 없기를 바라는 마음
답변달기