공격 표면 관리(ASM)나 지속적 위협 노출 스캐닝(CTEM)은 이제 대기업 보안 운영의 기본 요소가 됐다. 조직이 보유한 도메인 아래의 서브도메인과 IP를 자동으로 수집하고, 거기에 알려진 취약점 페이로드를 던져 노출된 자산을 찾아내는 방식이다. 그런데 이 자동화가 자산의 경계를 잘못 그으면, 정작 대상 조직과 아무 관계도 없는 제3자의 서버가 표적이 될 수 있다. NTP Pool을 운영하는 한 개인 서버 운영자 로빈(dreamstation.systems)이 겪은 일이 바로 그 사례다.
하나의 CNAME이 만든 오인
발단은 테슬라가 공개한 pool-ntp.tesla.com이라는 호스트명이었다. 이 이름은 자체 서버를 가리키는 것이 아니라 공용 시간 서버 집합인 pool.ntp.org로 향하는 CNAME이다. NTP Pool은 전 세계 자원봉사자들이 운영하는 수천 대의 NTP 서버를 라운드로빈 방식으로 묶어 놓은 것으로, 로빈의 서버(67.215.249.229)도 그 일원이었다. 문제는 자산 수집 도구가 tesla.com 하위에서 찾을 수 있는 모든 것을 끌어모으는 과정에서 pool-ntp.tesla.com을 포함시켰고, 이 이름이 해석되는 IP들을 그대로 테슬라 자산으로 인벤토리에 저장한 데 있었다. 즉, 테슬라 소유가 아닌 자원봉사 서버들이 능동 스캐닝 범위에 들어가 버린 것이다.
스캐너의 정체는 어태크서페이스 관리 도구인 Assetnote(현재 마케팅상 Searchlight Cyber로 불림)로 추정됐다. 트래픽은 세 개의 AWS(AMAZON-AES) IP인 54.165.75.96, 35.168.63.24, 52.44.200.251에서 왔고, Assetnote/1.0.0 (ExposureScan)이라는 사용자 에이전트를 달고 있었다. Host나 Referer 헤더에는 pool-ntp.tesla.com이 박혀 있었으며, SSRF 탐지를 위한 콜백 URL을 로빈의 서버가 대신 호출하도록 유도하는 시도까지 있었다.
무차별적으로 날아온 페이로드
로빈이 nginx 로그에서 확인한 공격 유형은 다양했다. 경로 탐색(path traversal), 웹셸 업로드, 소프트웨어 내부 정보 탐지, 워드프레스를 비롯한 CMS 관리 엔드포인트 탐색, SSRF, 그리고 Log4Shell까지 알려진 웹 취약점 대부분을 훑는 형태였다. 콜백 시도도 있었는데, Log4Shell·Text4Shell 탐지를 위해 assetnote-callback.com 호스트명을 심은 요청이 989건, SSRF 탐지용 canary.assetnotessrf.com을 담은 요청이 114건이었다. 흥미롭게도 Host 헤더가 login.solarcity.com으로 된 요청 15건이 /(S(x))/b/(S(x))in/System.Web.Mvc.dll를 요청했는데, 이는 /b/(S(x))in/을 /bin/으로 해석시키려는 ASP.NET 관련 기법으로 보인다.
템플릿 자체에 박혀 있던 흔적도 눈에 띄었다. Referer와 쿼리 문자열을 훑어보니 servicemcdonalds.com, saferas.com, rsmafghanistan.af, enrichcs.com.au, escience2010.org, al-forno.com.au, disneyfineart.com 같은 제3자 호스트명이 나왔고, 어떤 프로브의 Referer에는 RFC 1918 사설 주소까지 남아 있었다. 스캐너는 발견되는 모든 포트에 HTTP를 시도하는 성질이 있어, 로빈의 SSH·Postfix·Dovecot 포트에도 무의미한 HTTP 트래픽이 잔뜩 쌓였다.
운영자가 취한 대응과 그 결과
로빈은 이 문제를 두 갈래로 알리려 했다. 하나는 테슬라의 VulnerabilityReporting 창구로 보낸 메일이었다. 그는 자신의 서버가 NTP Pool 멤버이며 이틀 남짓한 기간에 두 스캐닝 호스트로부터 약 8,000건의 요청을 받았고, 모든 페이로드가 pool-ntp.tesla.com을 대상 호스트명으로 삼고 있다고 설명했다. 취약점을 신고하거나 무언가를 요구하는 것이 아니라, 테슬라가 의도치 않게 낯선 이들의 IP에 익스플로잇을 던지고 있음을 알리려는 취지였다. 다른 하나는 9월 8일부터 사람이 로그를 볼 때 눈에 띄도록 pool-ntp.tesla.com Host 요청에 비표준 상태 코드 299와 안내문을 응답으로 돌려준 것이다. 다만 이런 조치들만으로는 한동안 스캐닝 행위가 멈추지 않았다.
로빈의 집계에 따르면 8월 21일 이후 Assetnote 호스트에서 받은 요청은 5만 건을 넘었다. NTP Pool 운영자 커뮤니티에 문의한 결과, 매트 노드호프라는 운영자 한 명이 8월 15일부터 같은 현상을 겪고 있다고 답했지만 다른 이들의 추가 제보는 없었다. 이 때문에 로빈은 스캐너가 매번 pool-ntp.tesla.com을 재해석해 지오로케이션이 허용하는 모든 IP를 건드리는 것인지, 아니면 초기에 수집한 몇몇 IP만 집요하게 두드리는 것인지 확신하지 못했다. 결국 이 사안은 Assetnote 측의 파트릭이 먼저 연락을 취해 해결됐다.
실무적으로 이 사건이 남기는 교훈은 분명하다. 공유 인프라를 가리키는 CNAME을 조직 자체 도메인 아래에 두면, 자동 자산 수집 도구가 그 이름이 해석되는 모든 IP를 자기 자산으로 오인할 위험이 있다. 원문 작성자도 지적했듯 테슬라는 tesla.com 하위의 CNAME 대신 벤더 존을 쓰는 편이 나았을 것이다. 스캐닝을 운영하는 쪽에서는 자산 인벤토리에 라운드로빈·공유 IP가 섞여 들어가지 않도록 소유권 검증 단계를 두는 것이 필요하고, 스캐닝을 당하는 개인 운영자 입장에서는 방화벽 차단이라는 손쉬운 선택지가 있음에도 상대에게 상황을 알리는 데는 별도의 연락 채널을 뚫어야 하는 부담이 있다는 점도 드러난다. 참고로 이번 시도들 가운데 실제로 성공한 공격은 하나도 없었다.