▲

GN⁺: Xzbot: xz 백도어를 위한 노트, 허니팟 및 익스플로잇 데모

 (github.com/amlweems)
1P by neo 8달전 | favorite | 댓글 1개

xz 백도어 탐색 (CVE-2024-3094)

  • honeypot: 가짜 취약 서버를 통해 침투 시도 탐지
  • ed448 patch: 자체 ED448 공개 키를 사용하도록 liblzma.so 패치
  • backdoor format: 백도어 페이로드 형식
  • backdoor demo: ED448 개인 키를 알고 있다고 가정하고 RCE를 트리거하는 CLI

honeypot

  • 공개 키 N이 백도어 형식과 일치하는 모든 연결 시도를 기록하는 간단한 openssh 패치 제공
  • 연결 시도는 sshd 로그에서 다음과 같이 나타남

ed448 patch

  • 백도어는 하드코딩된 ED448 공개 키를 사용하여 서명 검증 및 페이로드 복호화
  • 이 키를 자신의 것으로 교체하면 백도어를 트리거할 수 있음
  • 백도어가 포함된 libxzma 공유 객체를 다운로드하고 패치 스크립트를 실행하여 키 교체

backdoor format

  • SSH 인증서를 사용하여 연결하고 CA 서명 키 N 값에 페이로드를 포함시켜 백도어를 트리거할 수 있음
  • 이 페이로드는 공격자의 ED448 키로 암호화 및 서명되어야 함
  • 페이로드 구조는 명시된 형식을 따름

backdoor demo

  • 취약한 SSH 서버에 연결하고 id > /tmp/.xz 명령을 실행하는 방법 제공
  • 취약한 서버에서 system() 호출을 감시하고 명령이 실행되는 것을 관찰할 수 있음
  • 정상적인 sshd 프로세스 트리와 백도어를 통한 프로세스 트리는 다르게 보임

GN⁺의 의견

  • 이 기사는 CVE-2024-3094로 지정된 xz 백도어 취약점에 대한 심층적인 탐색을 다루고 있으며, 보안 연구원들과 시스템 관리자들에게 매우 유익한 정보를 제공함.
  • 백도어를 탐지하고 대응하는 방법을 제시함으로써, 취약한 시스템을 보호하는 데 도움이 될 수 있음.
  • 이러한 취약점은 시스템의 근본적인 보안 메커니즘을 우회할 수 있기 때문에, 소프트웨어 개발자와 보안 전문가들은 이러한 유형의 취약점을 이해하고 예방하기 위한 조치를 취해야 함.
  • 비슷한 기능을 제공하는 다른 보안 도구나 프로젝트로는 OpenSSH, Fail2Ban, Snort 등이 있으며, 이들은 시스템을 보호하기 위한 추가적인 방어층을 제공할 수 있음.
  • 이 기사는 새로운 취약점에 대한 기술적인 세부 사항을 제공하므로, 이를 통해 보안 커뮤니티가 더 강력한 방어 전략을 개발하는 데 도움이 될 수 있음.
▲
neo 8달전  [-]
Hacker News 의견
  • 해커뉴스 댓글 요약:
    • 공격자의 개인 키가 필요한 RCE(Remote Code Execution) 취약점에 대한 흥미로운 지적. 수정: 링크를 잘못 이해했으며, 원래 댓글을 기록으로 남김.

      • 해당 취약점은 iron하게도 보안을 의식한 것으로 보임. 또한, 같은 메일 스레드에서 백도어를 커밋한 개인이 최근에 커널에도 기여한 것으로 나타남.

    • 해커 커뮤니티와 특히 amlweems가 POC(Proof of Concept)를 빠르게 구현하고 문서화한 것에 대한 감탄. 수정: 취약한 배포판을 찾는 방법과 SSH 서버에 대한 활동적인 프로빙을 모니터링하는 방법을 찾는 것이 다음 단계.

      • 커뮤니티의 빠른 대응과 분석에 대한 칭찬.

    • PoC가 이상 행동을 감지하는 도구들(Carbon Black, AWS GuardDuty, SysDig 등)에 대해 시도된 적이 있는지, 그리고 이를 통해 빠르게 감지될 가능성에 대한 궁금증.

      • 이상 행동 감지 도구들과의 PoC 테스트에 대한 호기심.

    • SSH 연결이 없어도 작동했는지에 대한 의문. GitHub에 있는 문자열 목록에 "DISPLAY"와 "WAYLAND_DISPLAY"가 포함되어 있음.

      • SSH와 직접적인 연관이 없는 문자열들의 존재로 인한 추가적인 영향 범위에 대한 추측.

    • 런타임에 openssh.patch를 필요로 하지 않고, 어떻게 liblzma.so.5.6.1이 메모리에 로드될 때 openssh_RSA_verify에 패치를 적용했는지에 대한 질문.

      • 런타임에 취약점을 이용한 과정에 대한 기술적인 질문.

    • 성공적인 공격이 로그를 남기지 않는다는 점. 이로 인해 공격자가 로그를 남기지 않고 임의의 명령을 실행할 수 있었는지에 대한 질문.

      • 로그 생성 없이 공격이 가능했던 점에 대한 우려.

    • xz, OpenSSH, Linux 프로젝트의 책임자들이 이 취약점에 대해 어떻게 대응했는지, 미래에 이러한 취약점을 방지할 수 있는 방법에 대한 의견.

      • 프로젝트 책임자들의 대응과 미래의 예방책에 대한 관심.

    • 국가 차원의 스파이 활동과 백도어에 대한 논의. 미국은 하드웨어 개입을 선호하는 반면, 이스라엘과 같은 다른 나라들은 장기적인 소프트웨어 백도어에 초점을 맞춤.

      • 국가별 백도어 전략에 대한 분석.

    • ED448 사용 이유에 대한 의문. 일반적으로 curve 25519가 권장됨에도 불구하고.

      • 특정 암호화 알고리즘 선택에 대한 의문 제기.

답변달기