How an NTP Pool Operator Got Caught in a Tesla “Cyberattack”

The administrator of dreamstation.systems, a participant in the volunteer NTP Pool network, described a curious story: for several weeks his server was hit by a flood of attacks whose source turned out to be not a gang of malicious actors, but a legitimate attack-surface analysis tool.

In his nginx logs the author noticed persistent traffic from three addresses in Amazon's cloud. The requests came with the Host header pool-ntp.tesla.com, carried the user-agent Assetnote/1.0.0 (ExposureScan), and tried to exfiltrate data through Assetnote's callback domains. In the period since August 21, the server received more than 50,000 such requests.

How it happened

The cause lies in the DNS chain. Tesla published the record pool-ntp.tesla.com as a CNAME pointing to pool.ntp.org — a round-robin selection from thousands of volunteer precise-time servers. The Assetnote service (now marketed as Searchlight Cyber) collected all the domains under tesla.com, added this address to Tesla's asset inventory, and began “legally” checking it for vulnerabilities. The trouble is that the round-robin resolved to the IP of an unrelated person, and the scanner seems to have “latched onto” his machine specifically. The author reasonably points out that Tesla should have used a dedicated vendor zone rather than a CNAME of its own.

What was flying at the server

The arsenal turned out to be rich: path traversal, web-shell uploads, probing of WordPress and other CMSes, SSRF, Log4Shell and Text4Shell. Nearly a thousand requests contained assetnote-callback.com domains, and another hundred-plus carried addresses for SSRF checks. The scanner also tried to speak HTTP on every port it found, showering even SSH, Postfix and Dovecot with junk.

The funniest part is the “junk” baked into the exploit templates themselves: the Referer headers and query strings turned up unrelated domains like login.solarcity.com, servicemcdonalds.com and disneyfineart.com, as well as a private address from the 192.168 range. The author proudly notes that not a single attack succeeded.

Attempts to get through

The owner wrote to Tesla at its vulnerability-reporting address, emphasizing that this was not a bug in their systems but simply “unintentional mischief”: the company is hurling exploits at unrelated people's IPs. Getting no reply, from September 8 he began answering requests to this host with the nonstandard code 299 and the text “This is not Tesla infrastructure!”, hoping a live human would read the note. He deliberately left the firewall off — it was too interesting to watch.

The story ended happily: in an update the author reported that an Assetnote employee had contacted him and the problem was resolved.

Source: Hacker News