XZ 백도어: “인증 우회가 아닌 RCE이며, 게이트가 있고 재생 불가능합니다”

• xz 백도어 역공학 예비 분석에 따르면, 이 동작은 단순한 인증 우회가 아니라 원격 코드 실행(RCE)에 가까움
• 후킹된 RSA_public_decrypt가 서버 호스트 키의 서명을 고정된 Ed448 키로 검증하는 흐름이 핵심임
• 서명 검증을 통과하면 페이로드가 system()으로 전달되어 실행될 수 있음
• 분석은 허가를 받아 공유된 예비 결과이며, Bluesky 게시물에는 인용 게시물 또는 임베디드 콘텐츠가 포함됨
• 백도어는 게이트가 있고 재생 불가능한 형태로 요약되어, 같은 입력을 단순 재사용하는 공격과는 다르게 봐야 함

---

xz 백도어의 실행 흐름

• 허가를 받아 공유된 역공학 예비 분석은 후킹된 RSA_public_decrypt에 초점을 둠
  • 서버의 호스트 키에 대한 서명을 고정된 Ed448 키로 검증함
  • 검증 이후 페이로드를 system()에 전달함

분류와 제약

• 이 동작은 인증 우회가 아니라 원격 코드 실행(RCE) 으로 분류됨
• 백도어는 gated/unreplayable 특성을 가진 것으로 요약됨
• 원문 Bluesky 게시물에는 인용 게시물 또는 다른 임베디드 콘텐츠가 포함됨

[GN⁺]

Hacker News 의견들

• 이 사안에 대한 추가 리버스 엔지니어링 결과가 있음. 백도어가 문자열을 숨기기 위해 쓰던 prefix trie에서 추출한 심볼 재매핑 정보가 들어 있고, 리버스 엔지니어링/분석 자체에서도 숨으려 한 것으로 보임
  https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9...
  디코딩된 문자열 전체 목록은 여기 있음
  https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01
  OpenSSL 내부를 잘 모르는 입장에서 보자면, N 값은 rsa_st의 n 필드에서 가져오는 듯함
  https://github.com/openssl/openssl/blob/56e63f570bd5a479439b...
  이 값은 BIGNUM이고, 가변 길이 타입으로 보임
  https://github.com/openssl/openssl/blob/56e63f570bd5a479439b...
  백도어는 원격 공격자에게서 받은 인증서에서 이 값을 꺼내 ChaCha20으로 복호화를 시도하고, 성공하면 system()에 넘김. system()은 현재 프로세스가 실행 중인 사용자 권한으로 셸 스크립트 한 줄을 실행하는 단순 래퍼에 가까움
  제대로 이해한 게 맞다면, 이건 공개키 우회보다 더 나쁨. 공개키 우회라면 이론적으로 로그인하려는 사용자 권한만 얻고, 강화된 SSH 설정에서는 root 로그인을 막았을 가능성이 큼
  하지만 이건 sshd 프로세스 자체 맥락의 원격 코드 실행이라서, root로 실행 중인 sshd라면 페이로드도 root로 실행될 수 있음. 널리 퍼진 원격 코드 실행으로서는 현실적으로 거의 최악에 가까움

  • 적절한 샌드박싱, SELinux, 완화 기법이 있으면 공격자가 root 권한으로 뭔가 하는 걸 막을 수도 있음. 다만 SSH 데몬에 샌드박스를 효과적으로 적용하는 건 매우 어렵다
  • 어마어마함. 10억 대 컴퓨터의 권한으로 무엇을 할지 어떻게 결정한다는 건지 감도 안 옴

• 이 백도어가 성능 문제 때문에 발견되지 않았다면 나중에 발견될 가능성이 얼마나 됐을지 궁금함. 성능 문제는 코드상의 실수/고칠 수 있는 결함으로 이해했는데, 이를 잡아낼 도구가 있었을지도 중요함
  이런 질문은 이런 종류의 백도어가 처음인지, 아니면 처음으로 드러난 것뿐인지 이해하는 데 관련이 큼

  • 악의적인 IT 행위자가 매우 많은 환경에서 1년 정도 일해본 입장에서는, 발견 가능성은 늘 꽤 높다고 봄. 비밀 유지에는 상상하기 어려울 정도의 에너지가 필요하고, 진실의 일관성을 유지하는 것도 마찬가지임
    작은 실수 하나로 모든 게 무너질 수 있고, 때로는 한 문장만으로도 연쇄 반응이 시작돼 정교하게 짜인 계획이 드러남
    범죄 수사가 매일 그렇게 이뤄짐. 경찰 업무에는 자원 제약이 있지만, 소프트웨어는 취미로 분석하는 사람들, 취미처럼 계속 분석하는 전문가들, 직업적으로 분석하는 전문가들이 매일 들여다봄
    결국 언젠가는 발견됐을 가능성이 큼
    XZ 공격은 매우 잘 실행됐고, 거의 걸작에 가까움. 국가 기관이 관여했어도 놀랍지 않음. 하지만 동시에 엄청나게 운이 좋았음. 지금 문제로 표시되는 것 중 하나라도 발견했다면 나뿐 아니라 많은 동료가 긴 추적에 들어갔을 것임
    얻을 수 있는 결론 하나는, xz/liblzma가 오픈소스가 아니었다면 이런 문제를 찾는 건 불가능했을 거라는 점임. 물론 오픈소스였기 때문에 애초에 가능해진 면도 있지만, 이게 Windows나 MacOS 안에 있었다고 상상해보면 됨
  • 익스플로잇이 사용되지 않았다면 발견 확률은 꽤 낮았을 것임. 숨긴 위치를 제대로 골랐음. 사실상 코드베이스 밖이라 감사자가 보지 않는 곳이었음
    다만 쓰지 않으면 목적을 달성하지 못함. 더 많이 사용할수록 나중에 탐지될 가능성도 커짐. SolarWinds와 비교할 만함
  • 앞으로 몇 달 동안 많은 사람이 이런 방향으로 엄청 고민하게 될 것 같음. 코드 리뷰인지, 어떤 종류의 행위 분석인지가 문제임
    개인적으로 system() 호출은 다소 허술했고, 바이너리 기능 스캐너가 그 경로를 잠재적으로 찾아낼 수도 있었을 것 같음
  • 이건 잡기 어려웠을 것 같음. sshd 패치는 허용 가능한 단계인 링킹 시점에 일어나고, 이 분석이 맞다면 마스터 키 백도어도 아니라서 일반적인 로그인 감사 흔적이 없음. 그리고 sshd가 다른 프로세스를 시작하는 것 자체는 당연히 허용될 수 있음
    매우 촘촘한 SELinux 정책이라면 sshd가 셸이 아닌 뭔가를 실행하는 걸 잡을 수도 있겠지만, 그런 수준의 강화는 매우 드물 것임
    대상 바깥에서 발견하는 문제도 이미 실험해본 셈임. 여러 사람이 valgrind 등으로 페이로드를 들여다봤지만 보지 못했음. 디버깅 환경에서 발견되지 않도록도 꽤 잘 보호돼 있음. 페이로드 아래의 드러난 인프라가 ASan 같은 도구와 호환되지 않기 때문임
    설령 링크되더라도 코드는 main() 훨씬 전에 실행되므로, 디버거로 liblzma 근처를 뒤져도 보통 실행 장면을 관찰하지 못함
    strace라면 프로세스가 생성된 뒤의 모든 시스템 호출과 링커 동작을 볼 수 있음. 하지만 지금까지 파악한 바로는 페이로드가 그 단계에서 활성화 여부를 결정하려고 시스템 호출을 하지는 않고, argv와 environ 등을 보는 것으로 보임
  • 흥미로운 파생점으로, Ken Thompson 공격도 PWB에서 메모리 성능 버그 때문에 발견됐다는 점이 떠오름
    [0] https://en.wikipedia.org/wiki/PWB/UNIX
    [1] https://news.ycombinator.com/item?id=38020792

• 바이너리 페이로드 안에 인코딩된 문자열이 있는 것으로 보임
  https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01...
  이 문자열은 킬 스위치로 동작함
  https://piaille.fr/@zeno/112185928685603910
  정말 그렇다면 완화책 하나는 다음일 수 있음

  echo "yolAbejyiejuvnup=Evjtgvsh5okmkAvj" | sudo tee -a /etc/environment  
  

  • 반드시 -a를 포함해야 함. 그렇지 않으면 환경 파일을 날려버릴 수 있음. 그리고 일반적으로는 악성 코드가 없는 버전으로 업그레이드하고 재시작하는 게 맞음
  • 너무 이상함. 자기 시스템을 보호할 방법을 남기고 싶어 한 국가 행위자 냄새가 강함

• 백도어가 정확히 뭘 하는지 간단히 설명해줄 수 있나? 아직 아는 건가? 백도어 자체가 페이로드는 아닌 것 같은데, 악성 압축 파일이 필요한 건지, 아니면 sshd 프로세스에 훅을 걸어서 원격 공격자의 악성 패킷을 듣는 건지 궁금함
  원문은 공격자가 SSH 세션의 인증 전 단계에서 악성 페이로드를 보낼 수 있는 것처럼 들리는데, 왜 익스플로잇이 영영 나오지 않을 수도 있다고 하는지도 모르겠음. 코드를 리버스 엔지니어링할 수 있다면 개념 증명도 쓸 수 있는 것 아닌가?
  결국 공격자는 이 백도어가 있는 머신을 어떻게 제어하는 건가?

  • 정확히 두드리면 열리는 문을 떠올리면 됨. 비밀 노크를 모르는 사람에게는 그냥 벽처럼 보이고 벽처럼 동작함. 비밀 노크가 없으면 애초에 열린다는 걸 증명할 방법조차 없을 수 있음
    여기 상황도 비슷함. xz는 수상한 일을 하기 전에 어떤 데이터를 복호화하려고 시도함. 비대칭 방식이라 비밀 암호화 키를 제공하지 않고도 복호화 검증은 가능함. 공개 대응 키를 갖고 있기 때문임
    비밀 키를 찾는 게 현실적으로 불가능하고, 페이로드 복호화에 실패하면 눈에 띄게 다른 동작을 하지 않기 때문에 익스플로잇 코드는 영영 공개되지 않을 수 있음. 익스플로잇 코드를 만들 방법은 비밀 키가 어떻게든 발견되는 것뿐이고, 현실적으로는 백도어 개발자가 유출하는 경우밖에 없음
  • 읽어본 내용 기준으로 공격 벡터는 이렇다고 봄. sshd가 시작되며 libsystemd를 로드하고, 이것이 해킹 코드가 들어 있는 XZ 라이브러리를 로드함
    XZ 라이브러리는 RSA 서명을 검증하는 OpenSSL 함수들의 자체 버전을 주입함
    누군가 SSH에 로그인하면서 인증용 서명된 SSH 인증서를 제시하면, 그 변조된 함수들이 호출됨
    인증서에는 정상 로그인 과정에서 사용자명이나 역할 같은 단언 정보가 들어갈 수 있고, 이 정보로 특정 사용자 로그인에 유효한 인증서인지 판단함. 하지만 변조된 함수가 특정 공격자 키로 서명된 인증서를 감지하면, 인증서의 하위 필드 일부를 꺼내 시스템 명령으로 실행함. 실행 맥락은 sshd, 즉 root 사용자임
    안타깝게도 공격자의 서명 키는 모르고, 해킹 코드가 검증에 쓰는 공개키만 알고 있음. 기본적으로 공격자는 감염된 시스템에서 root로 임의 명령 실행을 할 수 있고, 흔적은 많아 봐야 실패한 로그인 시도 정도일 것임. 인터넷에 노출된 시스템이라면 그런 시도는 원래도 많이 들어옴
  • 아직 정확히 무엇을 하는지는 모르는 것 같음. 다만 “재생 불가” 부분은 이렇게 이해함. 페이로드가 잘못됐거나 공격자 키의 서명이 검증되지 않으면 백도어가 정상 동작으로 되돌아간다는 것임
    공격자의 키 서명이 필요하다는 점이 핵심임. 그 키가 유출되거나 RSA 알고리즘이 깨지지 않는 한, 다른 연구자나 제3자가 이 백도어를 악용하는 건 불가능함. RSA가 깨진다면 이보다 훨씬 큰 문제가 생김
  • 공개키 암호가 제대로 사용됐고 악용 가능한 버그가 없다면, 리버스 엔지니어링을 해도 개념 증명을 만들 수 없음
  • 배포된 익스플로잇은 소스가 아니라 바이너리였고, 테스트 데이터 안에 교묘히 숨겨져 있었음. 또 공개되지 않은 개인 키로 페이로드를 검증함
    현재로서는 공격자만 익스플로잇을 실행할 수 있으므로 스캔도 불가능함. 성능 저하 같은 2차 효과를 제외하면 탐지하기 어렵고, 실제로 그렇게 발견됐음

• 이렇게 많은 Linux 서버가 매일 쓰는 중요한 패키지가 자금 부족 때문에 원 저자가 유지보수하지 못하게 된다는 게 이해하기 어려움. 오픈소스에는 뭔가 바뀌어야 함
  한 가지 해결책은 일정 규모 이상의 회사나 사업체에 유지보수 비용을 내도록 강제하는 라이선스일 수 있음

  • 그런 라이선스에는 사람들이 크게 반대함. “더 이상 자유롭지 않다”는 큰 반발이 시작되고, 해당 주체가 취소당함
  • 정말 자금 부족인지, 아니면 번아웃인지가 궁금함
  • 제안된 EU Cyber Resilience Act가 해결책을 자처하고 있음. 간단히 말하면 방화벽이든 토스터든 제품 수명 동안의 취약점에 대해 벤더가 책임을 짐
    따라서 벤더는 오픈소스를 안전하게 유지할 유인이 생김. 유지보수자에게 돈을 주거나, 코드 감사를 의뢰하거나, 정규직을 고용해 기여하게 하는 식임
  • 중요함과 필요함은 다름. 이 패키지는 중요하다기보다 필요한 패키지임
  • xz처럼 복잡한 것이 왜 필요한지 이해하기 어려움. bzip2 코드는 작고, 한 사람의 극히 일부 시간만으로도 유지보수할 수 있을 것임

• 현재 xz 저장소에 들어가면 GitHub 이용 약관 위반으로 비활성화돼 있음. 비활성화 자체는 당연하지만, GitHub가 코드와 히스토리는 남겨두고 배너를 표시하며 악용 가능한 기능만 막았으면 함
  그래야 연구자와 다른 사람들이 익스플로잇을 배울 수 있음. 더 사소한 상황에서 라이브러리가 악성 코드를 호스팅하다가 저장소가 내려가 있으면, 그냥 별일 아니라고 넘길 수도 있음

  • 자동화 도구가 내려받는 걸 원치 않을 것 같음
  • 해당 저장소의 GitHub 이벤트를 CSV로 여기서 볼 수 있음: https://github.com/emirkmo/xz-backdoor-github
    소스 코드에 관심 있다면 찾기 쉬움. 이 코드와 Git 저장소는 전 세계 여러 Git 저장소에 연결돼 있고, 릴리스에도 소스가 여러 번 번들돼 있음
  • xz에는 자체 Git 미러가 있어서 모든 커밋을 볼 수 있음

• 잘 알려지지 않은 오픈소스 게임의 사실상 유지보수자로서, 개발자들이 오고 가는 걸 봐왔음. 가치 있는 기여는 그냥 모두 병합함
  어떤 협업자들은 다양한 코딩 스타일로 C와 C++가 뒤섞인 상태에서 기능을 꽤 깊게 파고듦. 항상 구현 세부사항을 다 파악하진 못하지만, 마음 한구석에는 누군가 정말 나쁜 백도어를 넣으면 프로젝트가 망하겠다는 생각이 있음
  다행히 게임이 워낙 obscure하고 공격 표면도 아주 작음. 그래도 선의로 Windows 바이너리에 서명해볼까 하는 유혹은 멈추게 됐음
  이 xz 백도어는 정말 거대한 악몽이고, 원 개발자들과 여기에 휘말린 모든 사람이 안타까움

  • 물론 맞는 말이지만, 소프트웨어만의 문제는 아님. 사실 의미 있는 관점에서 “문제”라고 부를 수 있는지도 확신이 없음
    숲길을 걷고 있을 때 지나가는 차가 그냥 치고 갈 수도 있음. 운전자는 잡히지 않을 가능성이 높고, 막을 방법도 없으며, 경찰도 곁에 없음. 소프트웨어 백도어보다 훨씬 무서운 이 시나리오는 사실 뭔가를 하며 살아가기 위해 받아들여야 하는 최소한의 위험임. 실제로 그런 일이 벌어지기도 함
    하지만 결국 대다수 사람은 남을 적극적으로 해치려 하지 않음. 인간이 하는 모든 일은 늘 그 가정 위에 있었고, 지금도 그렇음
    코드 리뷰를 조금 더 엄격히 하고, 린터와 CI와 패턴 매칭을 더 쓰고, 코드 서명을 더 보급하고, 사람들의 신원을 검증하면 이런 일이 막힐 거라는 환상이 오히려 진짜 문제임. 세상을 모든 세부 수준에서 관리하고 통제할 수 있고 그래야 한다는 Silicon Valley식 망상의 증상임. 그런 “치료법”은 막으려는 어떤 병보다 훨씬 나쁠 수 있음
  • ZeroMQ의 고 Pieter Hintjens는 Optimistic Merging이라는 관행을 옹호했음. 기여를 코드 리뷰나 CI 결과를 기다리지 않고 즉시 병합하는 방식임. 느슨한 병합 기준을 두는 접근이 완전히 동떨어진 건 아님
    [1]: http://hintjens.com/blog:106
    기여자가 즐겁게 프로젝트에 참여하는 커뮤니티를 만드는 장점은 이해함. 하지만 프로젝트가 명확한 비전이나 방향 없이 커지게 만들고, 결국 다른 사람의 기여를 공통 기준에 맞추기 위해 유지보수자에게 과도한 부담을 지우는 방식처럼 느껴졌음
    실제 코드 리뷰가 미래의 알 수 없는 시점으로 밀리며, 그때 리뷰가 철저할지도 모르고 누가 책임지고 수행하거나 문제를 고칠지도 불명확함. 결국 사용자에게 무엇이 배포되는지 통제할 수 없는 혼돈의 처방처럼 들림
    악성 코드 배포 문제도 있음. 해당 블로그 글의 댓글에서도 이 문제가 나오고, Pieter는 xz 사례와 정확히 같은 시나리오를 설명함
    “Mallory가 참을성 있고 기만적이며 충분히 오래 유효한 기여자처럼 행동해 프로젝트 제어권을 얻은 뒤, 천천히 백도어를 심는다고 가정하자. 그러면 신중한 코드 리뷰도 도움이 되지 않는다. Mallory는 유지보수자가 될 만큼 충분한 신뢰만 얻으면 되며, 그것은 가능 여부가 아니라 방법의 문제다.”
    그는 “최선의 방어는 커뮤니티의 규모와 다양성”이라고 결론 내림
    하지만 신중한 코드 리뷰는 실제로 이런 일이 벌어질 가능성을 낮출 수 있다고 봄. 신뢰받는 기여자든 외부 기여자든 모든 기여를 철저히 리뷰하면, 이상한 동작이나 “A를 한다”고 하지만 실제로는 B를 하는 커밋을 더 일찍 발견할 가능성이 커짐
    Optimistic Merging이 더 큰 규모와 다양성의 커뮤니티로 이어지는지도 논쟁적임. 엄격한 기여 가이드라인을 갖고도 활발한 커뮤니티가 있는 프로젝트는 많음. 그리고 악성 패치를 언제 어떻게 잡을지에 답하지 못함
    xz의 문제는 작은 커뮤니티가 아니라 커뮤니티가 없었다는 점임. 단일 악성 행위자가 프로젝트 제어권을 얻었고, 다른 누구의 감독도 거의 없었음. 기여 가이드라인은 커뮤니티 규모의 요인이 아니었고, Optimistic Merging을 썼든 아니든 이런 일은 일어났을 것임
    [2]: http://hintjens.com/blog:106/comments/show#post-2409627
  • 회사들이 네트워크 경계 보안을 위해 엄청난 노력을 하면서도, 개발 조직에서는 일상적으로 brew install cask나 vi/emacs/vscode 확장을 설치하는 걸 보면 늘 놀라움
    Rust는 기본값이 가장 안전한 프로그래밍 언어/커뮤니티라고 할 만하고, 포인터 장난을 거의 못 하게 하는 수준의 보안 우선 설계를 갖고 있음. 그런데 가장 흔하고 권장되는 설치 경로는 이렇고, 나도 완전한 위선자라 자주 이렇게 함
    https://www.rust-lang.org/tools/install
    이건 한 예일 뿐임. “이걸 curl해서 sh에 파이프하라”는 식으로 원격 코드 실행을 스스로 열어놓으면서 동시에 누군가의 unsafe 블록을 두고 논쟁하는 습관이 너무 많은 사람에게 근육 기억이 돼버렸음
  • 솔직히 우리의 선의가 악용된다는 걸 깨닫는 건 시간문제였음. “빨리 깨고 빨리 고치자”나 “내 프로젝트 소유권 가져갈 사람?” 같은 행동은 문제를 부르는 셈이지만, 오픈소스가 코딩에 대한 무급 애정 노동인 이상 그런 것 없이 사는 것도 상상하기 어려움
    이런 일이 벌어져 안타깝지만 놀랍지는 않음. 이런 악의적 행위자에 맞설 더 나은 도구가, 그것도 오픈소스로, 나왔으면 함

• 이 백도어가 던지는 질문들이 있음. 같은 팀이나 비슷한 팀이 심어둔 다른 백도어는 또 무엇이 있는가? 이런 팀은 얼마나 많이 활동하는가? 이런 침투 공격에 취약한 의존성은 얼마나 많은가? 우리 업계의 이런 은밀 작전 대상 공격 표면은 얼마나 되는가?
  apache httpd, postgres, mysql, nginx, openssh, dropbear ssh, haproxy, varnish, caddy, squid, postfix 같은 주요 네트워크 서비스와 그 모든 의존성, 그리고 그 의존성들의 모든 커미터 그래프를 만드는 것이 어디가 가장 가치가 높고 감시를 덜 받았는지 파악하는 첫걸음일 수 있음
  이게 누군가 이런 일을 시도한 첫 사례일 리는 없음. 실패해서 드러난 첫 사례일 뿐임. Linux 커널에 시도됐다 발견된 백도어는 알고 있지만, 이건 원격 공격이고 완전히 다른 성격임

  • 왜 모두가 하듯이 제로데이를 쓰지 않고 백도어를 만들기로 했을까?
    왜 탐지되더라도 버그처럼 보일 수 있는 무해해 보이는 것을 배포하지 않고, 완전한 기능의 백도어를 구현하고 배포 방식까지 숨기려 했을까?
    이런 건 의식적인 결정이었을 것임. 그 이유가 목표가 무엇이었는지에 대한 힌트를 줄 수 있음
  • Debian은 왜 root로 실행되고 인터넷에서 연결을 받는 서비스에 불필요한 라이브러리를 로드하도록 패치했는지도 질문해야 함

• 이건 원격으로 익스플로잇을 스캔하려면 우리에게 없는 공격자의 개인 키가 필요하다는 뜻 같음. 다른 선택지는 로컬에서 탐지 스크립트를 돌리는 것뿐임

  • 어떤 스캐너들이 선택할 수 있는 완전히 끔찍한 방식은, RSA 인증을 제공하면 “잠재적으로 취약”하다고 표시하는 것임. 대부분의 SSH 서버가 RSA 인증을 제공하고, 실제로 SecSH RFC도 이를 구현 필수로 말함. 그러면 사람들이 비밀번호 인증으로 돌아가도록 부추길 수 있음
    이 문제가 실제 시스템에 광범위하게 퍼졌다는 게 밝혀지지 않는 한, 그런 방식은 예전에 비슷한 “전문가”들이 매년 비밀번호를 바꾸라고 요구해서 실제 보안은 낮추고 문서상 보안만 좋아 보이게 만들었던 일보다 더 나빠 보임
  • 클라이언트 공개키가 특정 지문과 일치할 때만 서명 검증 코드가 실행되는 것으로 보이므로, 타이밍 정보로 탐지할 수 있을지도 모름
    백도어의 서명 검증은 약 100µs 정도 걸릴 것이므로, 지문이 일치하는 키는 그렇지 않은 키보다 처리 시간이 그만큼 길어져야 함. 이 시간 차이는 적어도 LAN에서는 현실적으로 탐지 가능하고, 스캐너가 대상과 가까운 위치에서 실행된다면 인터넷 너머로도 가능할 수 있음
    반복 인증 실패 뒤 클라이언트 IP를 차단하는 시스템은 스캔이 더 어려울 것임
    (https://bench.cr.yp.to/results-sign.html에는 Ed448 검증이 약 40만 사이클로 나오고, 4GHz에서는 100µs에 해당함)
  • 트윗에는 “재생 불가”라고 되어 있음. 왜 재생할 수 없는지 궁금함. 백도어가 들어간 sshd가 어떤 챌린지를 내고 공격자가 거기에 서명해야 하는 구조인가?

• 인기 없을 의견일 수 있지만, 전체 작전을 감탄하지 않을 수 없음. 물론 규탄하지만 그래도 감탄하게 됨. 구상부터 실행까지 정말 예술 작품 같았고, 이렇게 일찍 잡힌 건 엄청난 행운이었음

  • 페이로드가 SSH 로그인 중 무작위로 0.5초 멈추는 현상을 만들지 않았다면 아마 오랫동안 발견되지 않았을 것임
    다음번에는 공격자들이 사람이 기다리는 작업에서 이상한 지연 급증을 만들지 않는 페이로드를 만들 가능성이 큼
    어쩐지 Kim Dotcom이 불법 도청 대상이라는 걸 알아낸 일이 떠오름. MW3에서 갑자기 핑이 크게 높아졌기 때문임. 조사해보니 자기 패킷만 물리적으로 아주 먼 거리에 있는 GCSB 사무실을 거쳐 라우팅되고 있었음. GCSB는 뉴질랜드 영주권자를 도청할 권한이 없음. 결국 그는 뉴질랜드 총리에게 개인 사과를 받았음
  • “어쨌든 병합되어서는 안 될 그자는 대단한 일을 했다. 끔찍하지만, 대단한 일이었다.”
    가장 기발했던 부분은 침투할 프로젝트 선택이었다고 봄. 뒤늦게 “Hans”의 IFUNC 풀 리퀘스트 논의를 읽으면 가슴 아프지만, 왜 이 프로젝트가 선택됐는지 정말 잘 보여줌
    “Jia”와 “Hans” 뒤에 몇 명이 있었고, 커뮤니케이션과 코드 기여를 어떻게 분석하고 전략화했는지 알고 싶음. 메일링 리스트에서 압박을 가장한 3차 인격 같은 일부 측면은 다소 허술하게 만들어진 것처럼 보임
    그래서 정교한 소규모 팀이나 심지어 단독 개인이 했을 가능성도 아직 있음. 국가 행위자라면 이런 작전을 위해 가짜 인격을 하루 종일 만들고 유지하는 사람들이 있을 거라고 생각함
    누군가 “이 세 사용자가 좀 무례하게 밀어붙이는 게 이상한데, 누구지? 계정이 모두 같은 시기에 만들어졌네. 수상하다. 왜 누가 굳이 가짜 계정으로 이걸 이렇게 강하게 밀지? 조사해봐야겠다”라고 생각했다면 곤란했을 것임. 전체 투입 노력에 비하면 그 부분은 부주의하거나, 계획이 나쁘거나, 예산이 부족했던 셈임
  • 동의하지만, 사회공학 부분은 특히 잔인하게 느껴짐
  • 그렇게 인기 없는 의견은 아닐 것 같음. 여러 면에서 매우 인상적인 공격임. 미묘했고, 여러 해에 걸쳐 구축됐으며, 공격자가 조사 계기가 된 이상한 성능 저하를 실수하지 않았다면 아마 우리는 몰랐을 것임
    극적인 가설을 덧붙이면, 공격자가 자신이 터뜨리는 정보 핵폭탄에 겁을 먹고 일부러 망쳤을 수도 있음
    최종 결과는 혐오하면서도 공격의 복잡성은 인정할 수 있음
  • “감탄”이 맞는 단어인지는 모르겠지만, 꽤 인상적인 작전인 건 맞음