xz sshd 백도어 래빗홀, 예상보다 훨씬 깊어

• xz의 sshd 백도어는 처음 드러난 RSA_public_decrypt 훅을 넘어, 접근하기 더 어려운 추가 코드 경로까지 일부 트리거됨
• 공격 흐름은 조작된 명령으로 mm_answer_keyallowed 훅을 설치한 뒤, 여러 개의 가짜 ssh-rsa 공개키를 이용해 명령 버퍼를 조립하는 방식임
• 이 “magic buffer”에는 추가 백도어 명령과 ed448 서명 2개가 들어가며, 서명에는 호스트키 SHA256 다이제스트와 KEX의 session_id가 반영됨
• 현재 PoC는 크게 수정한 paramiko SSH 클라이언트 라이브러리를 사용하며, 명령 0x03은 system() 기반 RCE와 uid/gid 설정을 가능하게 함
• 인증 우회도 확인됐고, mm_keyallowed_backdoor cmd 1로 mm_answer_authpassword 응답을 덮어쓰면 임의의 비밀번호로 로그인할 수 있음

---

더 깊게 연결된 백도어 경로

• xz sshd 백도어에는 처음 알려진 동작보다 더 깊은 기능이 포함돼 있으며, 일부는 직접 트리거된 상태임
• 핵심 진입점은 RSA_public_decrypt 훅임
  • 올바르게 제작한 명령을 보내면 sshd의 mm_answer_keyallowed 함수에 또 다른 훅이 설치됨
  • 이후 여러 개의 가짜 ssh-rsa 공개키를 제공해 “magic buffer”를 조각내어 합침
• “magic buffer”는 추가 백도어 명령을 담는 버퍼임
  • 내부에는 ed448 서명 2개도 포함됨
  • 이 서명들은 RSA_public_decrypt 쪽 백도어 서명처럼 호스트키의 SHA256 다이제스트로 salt 처리됨
  • 마지막 서명은 SSH 초기 키 교환(KEX)에서 파생된 0x20바이트 session_id도 반영함

PoC와 인증 우회

• 현재 PoC는 크게 수정한 paramiko SSH 클라이언트 라이브러리로 구현됨
• 현재 트리거된 명령은 이 코드 경로의 0x03임
  • system()을 통한 기본 RCE를 다시 가능하게 함
  • uid/gid 설정도 지원함
• 아직 이해해야 할 코드가 더 남아 있으며, mm_answer_keyallowed 백도어 명령 중 하나가 결국 mm_answer_keyverify도 훅하기 때문에 대화형 세션의 전체 인증 우회가 가능해 보임
• 이후 인증 우회가 확인됨
  • mm_keyallowed_backdoor cmd 1은 mm_answer_authpassword의 응답을 사용자 지정 값으로 덮어쓸 수 있음
  • 응답을 { u32(9), u8(13), u32(1), u32(0) }로 설정하면 어떤 비밀번호로도 로그인 가능함

[GN⁺]

Hacker News 의견들

• https://threadreaderapp.com/thread/1776691497506623562.html

• 이번 사건은 어떤 면에서는 매우 전문적이고, 다른 면에서는 꽤 아마추어처럼 보여서 이상함
  중요한 패키지의 유지관리자가 될 만큼 신뢰할 만한 정체성을 오래 쌓고, 여러 명이 관여한 듯한 사회공학 공격을 벌였고, 실제 정체와 공격 출처를 노출하지 않았으며, 난독화도 정교했음
  그런데도 프로덕션 버전에 버그와 성능 회귀가 흘러들어간 점은 허술해 보임. 국가 지원 조직이 정말 유능했다면 공개 프로젝트에 제출하기 전에 비공개로 충분히 테스트해서 의심을 살 성능 저하를 없앴을 것 같음

  • “국가 지원”이라고 들을 때 기대치가 너무 높은 것 같음. 큰 조직은 결국 다른 큰 조직과 비슷해져서 관료주의, 마감, 배포 주기, 팀 간 소통 문제를 겪음
    최근 iOS의 “백도어일지도 모르는” 사건도, 취약점을 많이 쌓아둔 조직은 일부를 태워먹는 데 늘 신경 쓰지는 않는다는 걸 보여줌
  • 코드를 개발한 사람들이 동시에 Valgrind를 돌리며 성능을 보고 있지 않았다는 건 믿기 어려운 일이 아님
    대상은 서버와 어플라이언스였고, 기본 이미지에서 Valgrind를 돌리는 서버나 어플라이언스가 얼마나 되겠나. 돌이켜보면 “왜 그 생각을 못 했지” 싶지만, 그들이 노린 시스템 이미지로 테스트했지 일반 개발자의 커스텀 이미지로 테스트하진 않았을 가능성이 큼
  • 2024-02-29에 libsystemd에 liblzma를 링크하지 않게 하는 PR이 올라왔음 [0]
    Kevin Beaumont는 “Jia Tan”이 이를 보고 백도어가 무력화될 수 있음을 즉시 깨달아, 이 익스플로잇에 들어간 막대한 작업을 날리지 않으려고 서둘렀을 것이라고 추측했고 [1], 그 말이 맞아 보임
    그 마감 압박 때문에 5.6.0에서 크래시가 났고, 이 사건이 잡힌 핵심 원인이던 성능 회귀를 줄이거나 없앨 다듬기 시간이 부족했을 것임
    [0]: https://github.com/systemd/systemd/pull/31550
    [1]: https://doublepulsar.com/inside-the-failed-attempt-to-backdo...
  • Google도 아무렇지 않게 Gemini를 출시할 수 있었다면, 이런 그림자 조직이 더 미묘한 방식으로 실패하는 게 그렇게 믿기 어려운가
    Patrick McKenzie가 다른 곳에서 보듯, 범죄 조직도 비범죄 조직과 비슷하게 위원회와 합의로 움직임. 그렇게 보면 기능 비대화로 생긴 성능 저하 때문에 배가 가라앉는 것도 이해됨. 내가 다닌 회사들은 더 아마추어 같은 실수도 했음
  • 유능한 국가 지원 조직에도 사고는 생길 수 있음. 정보기관도 상상만큼 냉혹하게 유능하지 않을 때가 있음. 영국에서 벌어진 Kremlin 암살 시도들은 실수의 코미디에 가까웠음 [1]
    어쩌면 사용하던 다른 백도어나 대체 접근 수단이 막혀서, 급하게 새 통로가 필요했을 수도 있음
    [1] https://en.wikipedia.org/wiki/Poisoning_of_Alexander_Litvine...

• 여기서 정교함이 정말 흥미로운데, 결국 꽤 눈에 띄는 성능 회귀 때문에 잡힘
  실제 범죄 프로그램에서 들은 인용구가 떠오름. “살인으로 잡히는 방법은 백만 가지가 있고, 그중 절반만 떠올릴 수 있어도 천재다”

  • 계정 뒤에 팀이 있었다고 보면 이해됨. 누군가는 기능을 개발했고, 더 부주의하거나 경험이 적은 다른 사람이 통합했을 수 있음
    또 다른 사람은 가짜 계정들을 관리하고 댓글과 PR에서 상호작용했을 가능성이 있음
  • 순진하거나 너무 잘 믿는 걸지도 모르지만, 이런 백도어가 이미 널리 퍼져 있을까 봐 걱정할 때마다 이 생각이 듦
    이번은 단지 운 나쁘게 걸린 건지, 아니면 이런 공격이 실제로 성공시키기엔 너무 어려운 건지 모르겠음. 후자였으면 좋겠지만, 사실 알 수 없음
  • 기억이 맞다면 성능 회귀는 코드가 기본값이 아닌 -fno-omit-frame-pointer로 컴파일됐을 때만 발생했음. https://mastodon.social/@AndresFreundTec/112187000944648334
  • 시간이 충분하고 로컬 테스트를 더 했다면 성공했을 가능성이 큼
    libsystemd의 @teknoraver 패치 때문에 그들의 마감 시점이 바뀌었다고 확신함
  • “절반만 떠올릴 수 있어도”라는 말은 살인 사건을 해결하려는 쪽에도 적용되는 건가?

• 이런 사건에서 세부를 깊게 파고드는 기술 글이 많이 나오면, 왜 다들 “이건 국가 지원임이 틀림없다”, “타임스탬프를 보라, 반박 불가능한 증거다”라고 하는지 자주 의아함
  xz 사건이 은밀했고 오래 공들인 공격인 건 맞지만, 유능한 개인 한 명을 넘어서는 무언가가 정말 필요한가? 온라인의 임의 개인들이 분석하고 이해할 수 있다는 사실은 한 사람이 이해 가능한 범위라는 뜻이기도 함
  그냥 똑똑하지만 불만을 품은 한 사람이 단독으로 벌였을 가능성은 왜 안 되는가

  • 국가 행위자를 떠올리게 하는 가장 큰 요소는 사회공학 공격에 투입된 시간 대비 기대 보상의 크기임
    이런 방식의 영리 목적 계획은 비합리적임. 비합리적 행위자나 돈이 아닌 동기를 가진 개인일 가능성을 배제하진 않지만, 국가 행위자가 유력 후보로 보이게 함
    성공했다면 팔 수 있는 가치는 엄청났겠지만, 주요 인프라에 익스플로잇을 넣고 고객이 사서 쓸 만큼 오래 들키지 않을 확률은 매우 낮음. 국가는 문샷을 감당할 수 있지만, 개인은 기대값이 더 높은 목표를 찾는 편이라고 봄
    물론 그렇다고 해서 유능한 국가 행위자였거나 많은 자원을 배정했다는 뜻은 아님
  • 동의함. 이 해킹에는 많은 기술, 결심, 시간이 필요했음
    하지만 그건 상당수 오픈소스 개발자에게도 해당하지 않나. 동기도 분명함. 이 익스플로잇은 암시장에서 수백만 달러 가치가 있었을 것임
  • 아무것도 없음. 그가 누구인지 아무도 모름
  • “반박 불가능한 증거”라는 건 어디서 봤는지 근거가 궁금함
    잘 아는 사람들의 추측은 많이 봤지만, 그런 표현은 보지 못했음

• 백도어 자체의 난독화를 정리한 글이 있나? 설치용 빌드 스크립트 말고 실제 백도어 말임
  바이너리를 Ghidra에 넣고 찾은 함수들을 훑어봤지만, 실행을 가로채는 데 쓰는 ifunc 메커니즘에 익숙하지 않아 포기하고 다른 사람들에게 맡겼음
  디버깅 방지 기능이 있으니 코드도 난독화됐을 것이라 봄. 불투명한 바이너리로 배포됐기 때문에 적어도 일부 코드는 우리가 갖고 있지 않은 키로 암호화됐을 거라 생각했음. STUXNET 페이로드 일부처럼

  • 백도어 자체에 대한 완전한 분석은 아직 나오지 않았음. 디버깅 방지는 플래그로 피할 수 있는 류도 있지만, 이번엔 컴파일 단계에서 처리돼서 좀 더 까다로움
    디버깅 방지 기능이 있다고 해서 코드가 반드시 난독화됐다는 뜻은 아님. 위에서 말했듯 빌드 시점에 이뤄졌기 때문임. 이미 자기 집에 덫을 설치한 셈임
    이번 일은 패키지 관리자가 올바른 출처의 소스를 가져오지 않을 때 생기는 문제를 보여줌

• 이 사건을 아주 자세히 따라가진 않았지만, 해킹 가해자에 대한 논의가 거의 들리지 않는다는 게 매우 이상함

  • “다만 나는 그가 실제로는 UTC+02 겨울/UTC+03 DST 시간대, 즉 동유럽(EET)이나 이스라엘(IST)을 포함하는 지역 출신이라고 본다”
    https://rheaeve.substack.com/p/xz-backdoor-times-damned-time...
  • 추측은 많이 있었음. 한 명보다는 여러 명일 가능성이 크고, 랜섬웨어 조직이나 국가 정보기관일 가능성이 있어 보임
  • Satoshi 분석 때처럼 관련 온라인 페르소나들의 커뮤니케이션을 의미론적으로 분석하면 문화적 방향을 가늠할 수 있어 흥미로울 것 같음
    시간이 지나며 문체 차이가 생겼는지 보면 여러 사람이 같은 페르소나로 활동했는지도 볼 수 있음. 커밋된 코드도 꽤 많으니, 코드 스타일 차이를 통해 한 명 이상이 관여했는지도 살펴볼 만함
  • 뭘 논의하나? 알려진 게 아무것도 없음

• 이게 널리 퍼지기 전에 발견된 건 꽤 다행임
  알 수 없는 주체가 우리 인프라에서 원격 코드 실행을 갖는 걸 원치 않는다는 당연한 이유만은 아님. 사람들이 계속 파고들면 결국 누구나 백도어를 사용할 수 있게 하는 페이로드를 만들어낼 가능성이 있음
  한 주체가 접근권을 갖는 것도 나쁘지만, 아무나 접근할 수 있게 되는 건 훨씬 더 나쁨

  • 페이로드가 비공개 RSA 키라면 거의 불가능한 일 아닌가?

• thereaderapp.com 대신 볼 수 있는 링크:
  https://nitter.poast.org/bl4sty/status/1776691497506623562

• 며칠이 지났는데도 아직 완전히 풀리지 않았다는 게 놀라움
  전 세계의 눈이 쏠려 있고 핵심 조각들도 이론상 공개돼 있는 상황에서, 이 정도로 버티는 건 난독화가 상당히 잘됐다는 뜻임

• 이번 사건에서 장기전 성격이 걱정됨
  첫째, 백도어를 만들 “인프라”를 구축하려고 오랫동안 때를 기다렸음. 둘째, 익스플로잇이 실제 프로덕션에 퍼진 뒤에도 또 다른 장기전을 준비했을 것임. 복권 당첨금을 쓰는 올바른 방식은 투자니까
  셋째, 지금도 이런 게임이 진행 중인지 궁금해짐. 무서움