Votre surface d’attaque est plus grande que votre inventaire

Demandez à une équipe la liste de ses services exposés sur Internet. Elle sortira un inventaire : le site, l’extranet, le webmail, deux API. Demandez ensuite la même liste à quelqu’un qui ne dispose que de sources publiques et ne touche jamais à vos serveurs. Sa liste sera presque toujours plus longue.

L’écart entre les deux correspond à la surface d’attaque oubliée : des services qui existent, répondent, et que personne ne surveille. Le guide d’hygiène informatique de l’ANSSI place la connaissance de son système d’information parmi ses toutes premières mesures, avant même le durcissement, puisqu’un actif inconnu ne reçoit ni correctif ni surveillance.

Les exemples ci-dessous utilisent le domaine fictif exemple.fr.

Ce que révèlent les certificats

Avec Certificate Transparency (RFC 6962), les autorités de certification publient les certificats qu’elles émettent dans des journaux publics. Les principaux navigateurs exigent cette publication pour faire confiance à un certificat. Chaque nom pour lequel vous avez obtenu un certificat TLS public est donc consultable par tous, y compris ceux que vous n’avez jamais annoncés.

Le service crt.sh indexe ces journaux :

# Tous les noms vus dans des certificats pour exemple.fr et ses sous-domaines
curl -s "https://crt.sh/?q=%25.exemple.fr&output=json" \
  | jq -r '.[].name_value' | tr 'A-Z' 'a-z' | sort -u

On y trouve typiquement staging.exemple.fr, vpn2.exemple.fr, jenkins.exemple.fr ou ancien-crm.exemple.fr, autrement dit l’historique lisible des projets, des migrations et des prestataires passés. Un certificat wildcard (*.exemple.fr) masque les noms individuels, sans rien empêcher pour autant : l’énumération DNS, les moteurs de recherche et les archives du web prennent le relais.

Traiter la liste obtenue

Lancez cette requête sur vos propres domaines. Pour chaque nom, posez trois questions : existe-t-il encore, qui en est responsable, doit-il rester public ? Un nom sans responsable identifié est à traiter en priorité, quelle que soit la réponse aux deux autres.

Préproductions et environnements oubliés

Les environnements de test forment le cas le plus fréquent. Créés vite, pour un projet, par une équipe qui finira par partir, ils tournent souvent avec le mode debug activé (traces d’erreur et variables d’environnement affichées), des comptes de test aux mots de passe triviaux, une copie parfois complète des données de production et des composants jamais mis à jour.

Une préproduction joignable depuis Internet offre à un attaquant les mêmes possibilités qu’une production, souvent avec moins de résistance. Les mesures efficaces sont simples : une authentification placée devant l’application (SSO, VPN ou au minimum une restriction par adresse IP), des données anonymisées et une date de fin fixée dès la création. Un fichier robots.txt ou une balise noindex ne protègent rien. Ils demandent aux moteurs de ne pas indexer et signalent du même coup où regarder.

Les enregistrements DNS orphelins

Prenons un sous-domaine qui pointe, par un CNAME, vers une ressource cloud supprimée : application hébergée, bucket de stockage, page statique. Si le fournisseur laisse n’importe quel client recréer une ressource du même nom, un attaquant peut la créer et servir le contenu de son choix sous votre domaine. Il obtient ainsi un hameçonnage crédible, la lecture de cookies de session selon leur portée, ou le contournement de politiques de sécurité fondées sur le domaine. Le guide de test OWASP décrit cette prise de contrôle de sous-domaine sous la référence WSTG-CONF-10.

Un premier contrôle :

# Vers quoi pointe ce nom, et la cible existe-t-elle encore ?
dig +short CNAME promo2024.exemple.fr
dig promo2024.exemple.fr | grep -E 'status: (NXDOMAIN|NOERROR)'

Au démantèlement, l’ordre compte : supprimez d’abord l’enregistrement DNS, puis la ressource. Dans l’ordre inverse s’ouvre une fenêtre pendant laquelle le nom pointe vers une ressource que n’importe qui peut réclamer.

Stockages cloud ouverts

Un bucket S3, un conteneur Azure Blob ou un bucket Google Cloud Storage peut devenir public en une case cochée. Dans la plupart des cas rencontrés, l’ouverture découle d’une décision temporaire (partager un export avec un prestataire, héberger les fichiers d’une campagne) que personne n’est revenu annuler.

Pour vérifier qu’un bucket AWS refuse la lecture anonyme, tentez un listage sans identifiants :

# Doit échouer avec AccessDenied si le bucket n'est pas public
aws s3 ls s3://exemple-exports/ --no-sign-request

Chez AWS, Block Public Access appliqué au niveau du compte empêche ces ouvertures accidentelles. Azure et Google Cloud proposent des contrôles équivalents au niveau du compte de stockage ou de l’organisation. Les dépôts de code publics relèvent de la même logique : une clé d’API commitée par erreur puis supprimée reste lisible dans l’historique Git.

Les domaines qui vous ressemblent

Votre surface d’attaque comprend aussi des domaines que vous ne possédez pas. exemple-fr.com, exemp1e.fr ou exemple.fr.secure-login.example servent à hameçonner vos clients et vos collaborateurs, et à monter des fraudes au virement.

L’outil open source dnstwist génère les variantes plausibles d’un nom (omissions, inversions, homoglyphes, changements d’extension) et vérifie lesquelles sont enregistrées :

dnstwist --registered exemple.fr

Une fois un typosquat repéré, plusieurs suites sont possibles : le surveiller, le signaler aux listes anti-hameçonnage, demander sa suspension à l’hébergeur ou au registraire. Pour les noms en .fr, l’Afnic propose une procédure de résolution des litiges, SYRELI. Enregistrer soi-même les variantes les plus évidentes reste souvent la solution la moins coûteuse.

Votre domaine comme expéditeur

Reste un angle souvent négligé : la possibilité pour un tiers d’envoyer des courriels au nom de votre domaine. Trois mécanismes complémentaires la limitent. SPF (RFC 7208) déclare quels serveurs peuvent émettre pour le domaine. DKIM (RFC 6376) signe cryptographiquement les messages. DMARC (RFC 7489) indique aux destinataires quoi faire d’un message qui échoue à ces contrôles, et vous adresse des rapports.

dig +short TXT exemple.fr | grep spf1
dig +short TXT _dmarc.exemple.fr
dig +short TXT selector1._domainkey.exemple.fr   # le sélecteur dépend de votre fournisseur

Une politique DMARC en p=none sert à collecter des rapports ; les messages usurpés continuent d’être délivrés. L’objectif est p=quarantine puis p=reject, une fois les rapports rua analysés et toutes les sources légitimes déclarées.

Les domaines qui n’envoient aucun courriel (noms de campagne, anciennes marques, typosquats défensifs) sont des cibles idéales pour l’usurpation, justement parce que personne ne les surveille. Verrouillez-les explicitement :

exemple-promo.fr.          TXT  "v=spf1 -all"
_dmarc.exemple-promo.fr.   TXT  "v=DMARC1; p=reject;"
exemple-promo.fr.          MX   0 .        ; « null MX », RFC 7505

Le null MX (RFC 7505) déclare que le domaine ne reçoit pas de courriel.

D’un inventaire ponctuel à une surveillance continue

Tout ce qui précède peut se faire à la main, une fois. La difficulté vient de ce que la surface d’attaque change en permanence : un nouveau certificat chaque semaine, un bucket créé pour une démonstration, un prestataire qui déploie un sous-domaine, un domaine ressemblant enregistré un vendredi soir. Un inventaire annuel décrit un état qui a déjà changé au moment où on le lit.

DataShield, l’outil d’attack surface management du Thucy Lab, automatise ce travail de découverte et de suivi : il cartographie ce qu’Internet sait de vous, le surveille chaque jour et classe les signaux par criticité. La règle de départ reste organisationnelle et aucun outil ne la remplace : chaque actif exposé a un responsable nommé et une date de fin.