$20로 RCE를 노리다 우연히 .mobi 관리자가 된 사건

 (labs.watchtowr.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • watchTowr Labs는 약 $20에 만료된 dotmobiregistry.net 도메인을 등록해 과거 .mobi WHOIS 서버 호스트명을 제어했고, 오래된 WHOIS 클라이언트와 TLS/SSL 인증서 검증 흐름이 여전히 그 주소를 신뢰한다는 점을 확인함
  • .mobi의 공식 WHOIS 서버는 whois.nic.mobi로 이전됐지만, 많은 도구가 예전 주소인 whois.dotmobiregistry.net을 하드코딩한 채 계속 질의하고 있었음
  • 2024년 8월 30일 임시 WHOIS 서버를 배포한 뒤 9월 4일까지 135,000개 이상 고유 시스템과 250만 건의 질의가 들어와, 방치된 레거시 도메인이 실제 인터넷 인프라에 넓게 연결돼 있음을 드러냄
  • 일부 TLS/SSL 인증기관은 .mobi 도메인 소유권 확인에 WHOIS 기반 이메일 검증을 사용했고, GlobalSign 테스트에서는 microsoft.mobi 검증 이메일 후보로 whois@watchtowr.com이 표시됨
  • 연구진은 악성 인증서를 실제 발급받지 않았고, 이후 영국 NCSC와 ShadowServer가 해당 도메인을 싱크홀로 연결해 합법적인 .mobi WHOIS 응답을 프록시하도록 조치함

$20짜리 만료 도메인이 WHOIS 인프라로 되살아남

  • watchTowr Labs의 원래 목표는 WHOIS 클라이언트가 서버 응답을 파싱하는 과정에서 현실적으로 악용 가능한 RCE를 찾는 것이었음
  • 초기 실험에서는 WHOIS 서버를 가장해 긴 문자열을 반환했고, 일부 클라이언트가 쉽게 크래시하는 것을 확인함
  • 다만 공격자가 WHOIS 응답을 제어하려면 보통 다음 중 하나가 필요했음
    • 네트워크 계층에서 WHOIS 트래픽을 가로채는 MITM
    • 실제 WHOIS 서버 접근 권한
    • 공격자가 제어하는 서버로 향하는 WHOIS referral
  • 이런 전제조건은 현실 공격에서 높은 장벽이지만, .mobi의 과거 WHOIS 서버 도메인이 만료되면서 상황이 달라짐
  • .mobi WHOIS 서버는 과거 whois.dotmobiregistry.net에서 whois.nic.mobi로 이전됐고, 이전 도메인인 dotmobiregistry.net은 2023년 12월쯤 만료된 상태였음
  • watchTowr는 이 도메인을 등록한 뒤, 예전 주소를 하드코딩한 WHOIS 클라이언트가 여전히 질의하는지 확인하기 위해 whois.dotmobiregistry.net 뒤에 WHOIS 서버를 배치함

WHOIS 서버 주소 하드코딩이 만든 공격면

  • WHOIS는 TLD마다 별도 서버를 쓰지만, 클라이언트가 해당 서버를 실시간으로 찾는 표준화된 메커니즘이 약함
  • 실제로는 IANA가 게시하는 텍스트 목록을 참고해 WHOIS 도구가 서버 주소를 개발 시점에 하드코딩하는 방식이 흔함
  • 서버 주소가 자주 바뀌지 않을 때는 문제가 덜 드러나지만, 주소가 바뀌고 과거 도메인이 만료되면 오래된 클라이언트가 폐기된 주소로 계속 질의할 수 있음
  • watchTowr는 lglass 서버로 들어오는 WHOIS 요청에 응답했고, 모든 질의 대상의 소유자가 watchTowr인 것처럼 보이는 가짜 WHOIS 정보를 반환함
  • 응답에는 ASCII art와 질의 중단 요청도 포함됨

관측된 질의 규모와 출처

  • 2024년 8월 30일 WHOIS 서버를 배포한 뒤, 몇 시간 만에 76,000개 이상 고유 출발지 IP가 질의함
  • 약 이틀 동안 SQLite DB에 130만 건의 질의가 쌓였고, 2024년 9월 4일 기준으로는 250만 건의 질의와 135,000개 이상 고유 시스템이 확인됨
  • 질의 출처에는 대형 도메인 등록기관과 WHOIS 기능 제공 사이트가 포함됨
    • domain.com
    • godaddy.com
    • who.is
    • whois.ru
    • smallseo.tools
    • seocheki.net
    • centralops.net
    • name.com
    • webchart.org
  • 보안 분석 서비스도 과거 .mobi WHOIS 서버를 사용함
    • urlscan.io는 .mobi 도메인 페이지에서 해당 WHOIS 결과를 사용함
    • VirusTotal는 watchTowr의 임시 WHOIS 서버를 질의하고 결과를 표시함
  • 메일 서버와 스팸 필터도 다수 확인됨
    • 스팸 필터는 발신자 도메인에 대해 WHOIS 조회를 수행할 수 있음
    • cheapsender.email부터 mail.bdcustoms.gov.bd처럼 방글라데시 정부 인프라로 보이는 호스트까지 포함됨
  • .gov 관련 주소는 여러 국가에서 확인됨
    • Argentina, Pakistan, India, Bangladesh, Indonesia, Bhutan, Philippines, Israel, Ethiopia, Ukraine, USA
    • Brazil 관련 예시로 antispam.ap.gov.br, master.aneel.gov.br이 포함됨
  • .mil 출처에는 Swedish Armed Forces가 예시로 등장함
  • .edu와 보안 기업 출처도 확인됐고, Group-IB, Detectify, Censys 등이 언급됨
  • .gov와 메일 서버가 .mobi 도메인에서 이메일을 받을 때마다 WHOIS 서버를 질의하면, 누가 누구와 통신하는지 수동적으로 관측할 가능성이 생김

오래된 WHOIS 클라이언트 취약점과 RCE 가능성

  • watchTowr는 WHOIS 응답 파싱 취약점의 선행 사례를 찾았고, 관련 CVE 검색 결과 26개 중 잘못된 WHOIS 응답으로 트리거되는 버그는 3개만 남았다고 정리함
  • 이처럼 사례가 적은 이유는 실제 악용에 TLD WHOIS 서버 제어 같은 어려운 전제조건이 필요하다는 인식과 맞물려 있을 수 있음
  • phpWHOIS CVE-2015-5243는 WHOIS 서버에서 받은 데이터를 PHP eval로 실행해 RCE가 가능한 취약점임
    • 취약 코드는 WHOIS 응답 문자열에서 "만 불완전하게 이스케이프한 뒤 eval에 전달함
    • Netitude의 분석은 ”;phpinfo();// 같은 예시 페이로드를 제시함
    • 취약한 phpWHOIS 버전은 whois.dotmobiregistry.net을 하드코딩하고 있었음
  • Fail2Ban CVE-2021-32749는 WHOIS 출력이 mail 도구에 제대로 정리되지 않고 전달돼 명령 주입이 가능한 취약점임
    • Fail2Ban은 차단한 IP의 소유자 정보를 WHOIS로 조회해 관리자 이메일에 포함할 수 있음
    • 다만 이 취약점은 IP 주소에 대한 WHOIS 조회에서 발생하므로, watchTowr가 확보한 .mobi 도메인 WHOIS 서버 제어만으로는 직접 닿지 않음
  • 실제 코드 실행에는 여전히 오래된 .mobi WHOIS 서버를 질의하는 클라이언트와 취약한 클라이언트 구현이 함께 필요함

TLS/SSL 인증서 검증 흐름까지 영향

  • 일부 TLS/SSL 인증기관은 도메인 소유권 확인을 위해 WHOIS 데이터에서 관리 연락처 이메일을 파싱하고, 해당 이메일로 검증 링크를 보내는 방식을 지원함
  • watchTowr가 나열한 WHOIS 기반 소유권 검증 지원 인증기관 또는 리셀러 예시는 다음과 같음
    • Trustico
    • Comodo
    • SSLS
    • GoGetSSL
    • GlobalSign
    • DigiSign
    • Sectigo
  • GoGetSSL 테스트에서는 가상의 watchTowr.mobi CSR을 올렸을 때 watchTowr가 설정한 whois@watchtowr.com이 표시되지 않았고, WHOIS가 성공하지 않은 상태로 보이는 placeholder 이메일만 표시됨
  • Entrust 테스트에서는 microsoft.mobi의 합법적인 WHOIS 레코드가 파싱돼 microsoft.com 도메인의 이메일만 검증 후보로 표시됐고, watchTowr.mobi는 파싱되지 않았음
  • GlobalSign 테스트에서는 처음에 microsoft.mobi WHOIS 레코드를 파싱하지 못하는 것으로 보였지만, watchTowr가 합법 WHOIS 서버의 microsoft.mobi 출력 형식을 복사해 자신의 WHOIS 서버에 맞춰 제공하자 결과가 바뀜
  • GlobalSign은 watchTowr의 WHOIS 서버를 질의했고, 응답에서 whois@watchtowr.com을 파싱해 microsoft.mobi 검증 이메일로 제시함
  • watchTowr는 이 지점에서 중단했으며, 악성 TLS/SSL 인증서를 실제로 발급받지 않았음
  • 이론상 공격 흐름은 다음과 같음
    • 과거 권한 있는 호스트명에 악성 WHOIS 서버를 배치함
    • 대상 .mobi 도메인에 대한 TLS/SSL 인증서 구매를 시도함
    • 인증기관이 WHOIS를 조회하고 실제 소유자가 아닌 공격자 이메일로 검증 메일을 보냄
    • 공격자가 링크를 클릭하면 대상 도메인에 대한 TLS/SSL 인증서를 받을 수 있음
  • 이 능력이 있으면 트래픽 가로채기나 대상 서버 사칭 같은 공격이 이론상 가능함

사후 조치와 남은 문제

  • 공개 전 영국 NCSC와 ShadowServer Foundation이 함께 대응함
  • dotmobiregistry.net 도메인과 whois.dotmobiregistry.net 호스트명은 ShadowServer가 제공하는 싱크홀 시스템으로 연결됨
  • 해당 싱크홀은 .mobi 도메인에 대한 합법적인 WHOIS 응답을 프록시함
  • 영향을 받은 당사자에게 알리는 절차도 마련됨
  • 이번 사례는 레거시 인프라, 방치된 도메인, WHOIS 기반 처리, TLS/SSL 인증기관 검증 절차가 함께 작동할 때 생기는 구조적 결함을 보여줌
  • MITM이 가능한 주체도 WHOIS 데이터를 위조해 같은 유형의 공격을 시도할 수 있으며, 인증서 투명성 같은 장치가 있어도 대규모 공격에는 운영상 장벽이 남아 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이 상황까지 온 데에는 여러 사람의 실수가 겹쳤겠지만, 이 특정 공격을 막을 수 있었던 한 가지는 분명함: 도메인을 절대 만료시키지 말 것
    .MOBI 최상위 도메인의 WHOIS 서버가 몇 년 전 whois.dotmobiregistry.net에서 whois.nic.mobi로 이전됐고, dotmobiregistry.net 도메인은 2023년 12월쯤 만료된 채 방치된 것으로 보임
    회사가 연 10달러라며 새 도메인을 쓰기 시작하면, 그 도메인은 사실상 영원히 연 10달러를 내야 하는 자산이 됨. 한 번 사업과 연결된 도메인은 그 연결을 완전히 끊을 수 없음

    • Verisign이 왜 독점 사업자이고 전기·수도 같은 공공재처럼 규제돼야 하는지 보여주는 가장 명확한 이유임. 선택권이 있고 종속되지 않는다는 말은 허상에 가깝고, 도메인을 사서 쓰기 시작하면 사실상 영원히 묶임. Verisign도 그걸 알기 때문에 독점을 지키려고 필사적으로 싸움
    • Google조차 이걸 잠깐 망친 적이 있음
      https://money.cnn.com/2016/01/29/technology/google-domain-pu...
    • 항상 하위 도메인을 써야 함. 기업은 존속 기간 내내 연 10달러짜리 도메인 하나면 충분함
    • 이 지점이 마음에 듦. Backblaze가 사용자 데이터를 잃을 만큼 디스크가 많이 고장 날 확률을 계산하던 블로그 글들이 떠오름
      결국 계산값 자체는 별로 중요하지 않다고 봤는데, 만료된 신용카드나 스팸 필터링 때문에 갱신 알림을 놓쳐 결제를 잊을 가능성이 더 크기 때문임
      거대 기업들은 도메인 비용 납부를 어떻게 잊지 않을까? 비싼 등록 대행사에 “무한대”에 가까운 기간의 갱신을 맡기는 걸까? 꽤 어려운 비즈니스 운영 문제로 보임

  • 어느 날 아침 일어났더니, 외딴곳 호텔방에서 누군가가 근처 카페 와이파이 핫스팟에 연결한 Raspberry Pi로 뭔가를 해서 인터넷이 통째로 사라졌다는 소식을 보게 될 것 같은 느낌

    • 대학 기숙사에서 누군가 집에서 가져온 아무 라우터나 꽂아 엉터리 DHCP 주소를 뿌리면서 인터넷이 망가지던 일이 떠오름. 그게 전 세계 규모로 벌어지는 느낌임
    • 실제로 꽤 많은 것들이 희망과 기도 위에 올라가 있긴 하지만 [0], 인터넷은 설계상 견고하게 만들어졌음 [1]. 이번 경우 범위는 .mobi로 제한됐음
      [0] https://xkcd.com/2347/
      [1] https://en.wikipedia.org/wiki/ARPANET#Debate_about_design_go...
    • 최근 “White House asks agencies to step up internet routing security efforts” [1]와 관련이 있는 건 순전히 우연일 뿐임
      [1] https://news.ycombinator.com/item?id=41482087

  • 왜 도구들이 WHOIS 서버 목록을 하드코딩해서 쓰는 걸까?
    DNS에 이를 등록하는 표준적인 방법이 있는 듯하지만, 간단히 테스트해보면 많은 최상위 도메인에 레코드가 빠져 있음. 동작하는 예시는 dig _nicname._tcp.fr SRV +noall +answer이고, _nicname._tcp.fr. 3588 IN SRV 0 0 43 whois.nic.fr.가 반환됨
    추가로, 이에 대한 만료된 인터넷 초안도 있음: https://datatracker.ietf.org/doc/html/draft-sanz-whois-srv-0...

    • 단순히 mobi.whois.arpa. CNAME whois.nic.mobi만 있어도 이미 문제를 해결할 수 있었음. 다만 모두가 이런 방식에 합의하고 채택하게 만드는 일이 어려움
      아래에서 fanf2가 말했듯, IANA WHOIS 서버부터 질의해도 될 것 같음. https://www.iana.org/whois에 mobi를 질의하면 응답 일부로 whois: whois.nic.mobi가 돌아옴
    • 현실에는 상상하는 것보다, 또 있어야 하는 것보다 훨씬 많은 하드코딩 문자열이 존재함
    • WHOIS는 아마 SRV 레코드라는 개념보다도 훨씬 오래됐을 것 같음
    • 이런 도구들은 보통 일회성 필요 때문에 만들어지고, 다른 사람이 쓰거나 본인이 나중에 참고하려고 공개됨. 다른 “엔지니어”들이 망설임 없이 복사해 붙여넣고, 그게 운영 환경에 들어가면 이번처럼 CVE가 됨
      개발자 역량 부족도 문제지만, AI 환각이 이 상황을 더 악화시킬 것임

  • 도메인을 의미 있게 한 번 쓰기 시작하면, 사실상 우주의 열적 죽음까지, 적어도 팀의 열적 죽음까지는 갱신해야 한다는 걸 깨닫지 못하는 팀을 너무 많이 봤음
    이런 경우든, 어딘가에 남아 있는 오래됐지만 중요한 URL이든, 팀원이 예전 도메인 이메일로 서비스에 가입한 경우든, 오래된 도메인을 정말 놓아도 되는 시점을 알기는 너무 어려움

  • 오래된 WHOIS 서버의 만료 도메인 하나를 사는 것만으로 생기는 공격 표면이 정말 어마어마함

  • WHOIS의 진짜 해법은 RDAP임
    안타깝게도 국가 코드 최상위 도메인에는 필수가 아니고, 국가 코드가 아닌 최상위 도메인 중에도 제대로 동작하지 않는 곳이 많음
    https://en.wikipedia.org/wiki/Registration_Data_Access_Proto...
    https://resolve.rs/domains/rdap-missing.html

    • 그게 글에서 설명한 문제들을 어떻게 완화함?

  • 아주 멋진 작업임
    dotmobiregistry.net 도메인과 whois.dotmobiregisry.net 호스트명은 이제 ShadowServer가 제공한 싱크홀 시스템을 가리키고, 이 시스템이 .mobi 도메인의 정상 WHOIS 응답을 프록시한다고 되어 있음
    이 도메인들이 폐기될 예정이었다면 404 같은 응답을 돌려주는 편이 나았을 것임. 계속 정상처럼 동작하게 두면 정식 도메인으로 전환할 유인이 줄어듦

    • Whois는 HTTP 상태 코드를 지원하지 않지만, ShadowServer 싱크홀은 이렇게 응답함:
      Domain not found.
      >>> Please update your code or tell your system administrator to use whois.nic.mobi, the authoritative WHOIS server for this domain. <<<
    • 글을 보면 몇 년 동안 이미 깨진 상태였고, 많은 클라이언트가 이를 알아차리지 못했던 것으로 보임

  • 컴퓨터 전반의 접근 방식 자체가 실패할 운명이라고 봄. 완벽한 보안에 기대고 있고, 그 보안은 SBOM 검사와 잦은 업데이트로 달성된다고 가정함
    하지만 절대 그렇게 되지 않음. log4j만 해도 전체 다운로드의 40%가 취약한 버전임. 공급망 안의 업체가 폐업하거나 구성 요소 유지보수를 중단하면 더 말할 것도 없음
    우리 몸이 늘 미생물과의 전쟁터인 것처럼, 모든 것은 언제나 버그투성이이고 구멍투성이일 수밖에 없음

    • 아니, 천천히지만 확실하게 좋은 코드와 신뢰할 수 있는 코드를 쓸 수 있고, 그걸 이용해 더 나은 도구를 만들고, 또 그 도구로 다음을 만들 수 있음
      아마 수십 년은 걸리겠지만 길은 꽤 분명해 보임. 노력을 들이고, 모든 “교훈”에서 얻은 지식을 적용하고, 멈추지 않으면 됨

  • 전반적으로 “우리는 이걸 하고 싶지 않았는데 상황이 계속 커졌고, 매 단계마다 예상보다 더 큰 걸 얻게 됐다”는 분위기가 좋았음
    반대하던 사람들이 말을 듣고 파싱을 고쳤다면, 글쓴이들이 이런 수고를 덜 수 있었을지도 모름

  • 이걸 뒤집어 보면, 전 세계의 모든 WHOIS 서버가 항상 진짜이고 안전하다고 믿어야 하는 걸까?
    특히 TLS 검증을 하는 인증기관 관점에서는 whois somethingarbitrary.ru를 실행했다가 러시아 서버 때문에 원격 코드 실행에 노출된다는 사실을 알고 싶지 않을 것임

답변달기