Fuite massive du Cadastre : 149M de lignes exfiltrées via Zéro Logement Vacant

Une brèche critique dans une plateforme citoyenne expose des données sensibles issues du cadastre et de la DGFiP, illustrant les risques systémiques liés à l'externalisation des services publics numériques.

En bref

• 149 millions de lignes de données cadastrales et fiscales ont été compromises lors d'une attaque contre la plateforme "Zéro Logement Vacant".
• L'acteur malveillant ZeroBytes revendique la fuite, menaçant de publier les données brutes.
• Les données concernées incluent des informations nominatives liées aux propriétaires, ainsi que des détails techniques sur l'infrastructure backend.
• Cet incident met en lumière la fragilité des "citizen tech" reliant directement le public à des bases de données sensibles de l'État (DGFiP, Cadastre).
• Pour les consultants IT, c'est un rappel brutal de l'importance de l'architecture Zero Trust et du contrôle strict des accès API.

Contexte

La plateforme "Zéro Logement Vacant" est un projet à vocation citoyenne et associative, conçu pour recenser les logements inoccupés en France afin de lutter contre le fléau du mal-logement. Son objectif initial était social : fournir une base de données accessible pour aider les associations, les élus et les citoyens à identifier les biens vacants dans leur quartier.

Cependant, cette initiative repose sur un modèle technique classique mais risqué : l'agrégation de données publiques ou semi-publiques (Cadastre) avec des données privées ou sensibles (propriétaires, situations fiscales potentielles via la DGFiP). Selon les informations relayées par Korben et revendiquées par le groupe ZeroBytes, la plateforme a été compromise. Le pirate affirme avoir accédé à une base de données contenant 149 millions d'enregistrements.

Cette fuite n'est pas anecdotique. Elle touche des entités régulatrices majeures :

• Le Cadastre : qui détient la géolocalisation précise des biens, les surfaces, et l'identification des propriétaires.
• La DGFiP (Direction Générale des Finances Publiques) : dont les données fiscales, si elles sont croisées ou incluses dans le dump, permettent d'identifier la situation financière des propriétaires.

L'incident survient alors que la France renforce ses exigences en matière de cybersécurité publique, notamment via la directive NIS2 et les recommandations de l'ANSSI. Il démontre que la sécurité ne se limite pas aux grandes administrations, mais s'étend à tout écosystème qui manipule des données d'intérêt général, y compris les plateformes intermédiaires ou associatives.

Détails techniques

Pour comprendre la gravité de cette fuite, il faut analyser la nature des 149 millions de lignes concernées et le vecteur probable d'attaque.

Nature des données exposées

Bien que ZeroBytes n'ait pas encore publié l'intégralité du dump (menaçant de le faire sous forme de "proof of concept"), les métadonnées suggèrent un mélange complexe :

1. Données cadastrales : Identifiants fiscaux, références parcelles, coordonnées GPS précises, surfaces bâties et non bâties.
2. Données nominatives : Noms, prénoms des propriétaires (personnes physiques ou morales).
3. Données potentiellement sensibles : Si la plateforme croisait ces données avec des informations de la DGFiP (comme les avis d'imposition ou les situations de vacance déclarées), cela crée un profilage financier et géographique extrêmement détaillé.

Hypothèse technique sur la vulnérabilité

Les plateformes du type "Zéro Logement Vacant" fonctionnent souvent via :

• Une base de données locale (PostgreSQL, MySQL) alimentée par des exports CSV/JSON du Cadastre.
• Un backend API (Node.js, Python/Django, PHP) exposant ces données pour l'interface web.
• Un stockage objet (S3 compatible) pour les fichiers bruts.

L'attaque de ZeroBytes pourrait reposer sur plusieurs vecteurs :

1. Injection SQL ou Faille d'authentification : Accès direct à la base de données via une API mal protégée.
2. Exposition du Bucket S3 : Si les exports bruts du cadastre étaient stockés dans un bucket public ou mal configuré (ACL public-read), le vol serait trivial.
3. Compromis d'un compte administrateur : Ransomware classique, où le pirate chiffre les données et exige un paiement pour ne pas les publier.

Exemple de configuration risquée (à éviter absolument)

De nombreuses plateformes citoyennes utilisent des configurations "quick & dirty" qui deviennent des cibles idéales. Voici un exemple de mauvaise pratique courante dans ce type d'application :

# .env.example - Mauvaise pratique fréquente
DB_HOST=localhost
DB_USER=root
DB_PASSWORD=change_me_123  # Mot de passe faible ou par défaut
API_KEY=sk_live_abc123xyz  # Clé API exposée dans le code front-end

# Configuration S3 dangereuse (Bucket public)
S3_BUCKET_NAME=zero-logement-vacant-data
S3_REGION=eu-west-3
# Pas de politique d'accès stricte, pas de chiffrement au repos activé explicitement

Ce qui aurait dû être fait :

• Utilisation d'un gestionnaire de secrets (HashiCorp Vault, AWS Secrets Manager).
• Chiffrement des données au repos et en transit.
• Restrictions d'IP sur les accès administratifs.
• Journalisation (logging) centralisée pour détecter les requêtes anormales (ex: téléchargement massif de lignes).

Analyse du volume : 149 millions de lignes

149 millions de lignes correspondent à une base de données volumineuse, potentiellement de plusieurs dizaines de Go voire centaines de Go en format brut. Cela suggère que le pirate n'a pas juste "scrapé" la page d'accueil, mais a accédé au cœur du système (Base de données ou Stockage). La rapidité avec laquelle le volume a été estimé par ZeroBytes indique probablement un accès direct à l'export SQL ou CSV complet.

Implications pour les consultants IT

Cet incident n'est pas qu'une affaire d'associations ; il impacte directement la posture de sécurité des consultants et architectes systèmes qui conçoivent ou auditent des systèmes manipulant des données publiques sensibles.

1. La fin de l'exception "Données Publiques"

Beaucoup de développeurs considèrent les données du Cadastre comme "publiques" et donc moins critiques. C'est une erreur fatale. La donnée publique devient sensible dès qu'elle est agrégée avec des données nominatives ou contextuelles.

• Réflexe à adopter : Traiter toute donnée contenant un identifiant unique (nom, adresse, référence fiscale) comme des Données Personnelles (RGPD) et des Données Sensibles au sens large. Appliquer les mêmes standards de chiffrement et d'audit qu'à une base de données bancaire.

2. Audit des chaînes d'approvisionnement de données (Data Supply Chain)

Si votre client ou votre projet consomme des données du Cadastre, de l'INSEE ou de la DGFiP via des API tierces :

• Vérifiez qui héberge ces agrégateurs. Sont-ils conformes ISO 27001 ? Ont-ils subi un audit récent ?
• Limitez le périmètre d'exposition. Ne stockez que les données strictement nécessaires à l'usage (principe de minimisation). Si vous n'avez besoin que du code postal, ne stockez pas la géolocalisation précise et le nom du propriétaire.

3. Durcissement des API et des Backends

Les plateformes citoyennes souffrent souvent d'un manque de ressources en cybersécurité. En tant que consultant, imposez :

• Rate Limiting strict sur les endpoints de lecture pour empêcher le scraping massif.
• WAF (Web Application Firewall) pour bloquer les tentatives d'injection SQL ou XSS.
• Chiffrement TLS 1.3 obligatoire et certificats valides.
• Séparation stricte des environnements : La base de données ne doit jamais être exposée directement au web. Utiliser un proxy inversé (Nginx, HAProxy) avec des règles d'authentification robustes.

4. Préparation à l'incident (IRP)

Même les petites structures doivent avoir un plan.

• Sauvegardes chiffrées et hors ligne : Pour pouvoir restaurer le service en cas de ransomware sans payer la rançon.
• Procédure de communication : Qui contacter en cas de fuite ? (ANSSI, CNIL, client final).
• Chasse aux menaces (Threat Hunting) : Analyser les logs d'accès aux fichiers de données. Une lecture anormale de 10 000 lignes par minute est un signal d'alerte immédiat.

Pour aller plus loin

• Lien source originale : La plateforme Zéro Logement Vacant a été piratée - Korben
• Action 1 : Si vous utilisez des données cadastrales dans vos projets, auditez immédiatement la configuration de vos buckets S3 et l'exposition de vos bases de données. Vérifiez qu'aucun endpoint ne permet d'exporter plus de 50 lignes par requête sans authentification forte.
• Action 2 : Revoyez votre politique de mots de passe et d'accès admin pour les systèmes manipulant des agrégats de données publiques. Imposez l'authentification à deux facteurs (MFA) obligatoire pour tout accès à la base de données ou au stockage objet.
• Action 3 : Intégrez une clause de "Data Breach Notification" dans vos contrats avec les clients qui fournissent des données tierces. En cas de fuite chez un fournisseur (comme ici), vous devez être informé sous 72h pour évaluer votre propre exposition.