Race Conditions et Smashing the State Machine

1. Qu'est-ce qu'un « état » dans une machine ?

Un état représente une situation particulière dans laquelle se trouve un système à un instant donné. Ce concept, fondamental en informatique, régit le fonctionnement de pratiquement toutes les applications que nous utilisons quotidiennement.

Prenons l'exemple concret d'un distributeur automatique de billets. Cette machine traverse plusieurs états distincts lors d'une transaction : état « prêt à l'emploi » (attente d'une carte), état « lecture de la carte » (validation des informations), état « saisie du code PIN », état « validation du code », état « sélection de l'opération », et enfin état « distribution d'argent » ou « fin de transaction ».

Cette logique s'applique identiquement aux applications web. Lorsque vous effectuez un achat en ligne, le serveur traverse plusieurs états : affichage du panier, application d'un code promo, validation du paiement. C'est précisément dans ces transitions d'état que se cachent les vulnérabilités exploitables par race condition.

2. Les race conditions : quand le timing devient une arme

Une race condition (condition de concurrence en français) se produit lorsque plusieurs processus s'exécutent simultanément et accèdent à la même ressource sans coordination adéquate. Le résultat final dépend alors de l'ordre d'exécution, qui devient imprévisible.

Illustrons avec un exemple parlant : un site de vente de billets d'avion avec un seul siège disponible. Deux utilisateurs cliquent sur « Acheter » au même instant. Logiquement, seul le premier devrait obtenir le billet. Mais si le système vérifie d'abord la disponibilité puis effectue la réservation dans deux opérations séparées, les deux utilisateurs peuvent passer la vérification avant que la réservation ne soit enregistrée.

2.1 La fenêtre de course (race window)

La période pendant laquelle une collision est possible s'appelle la fenêtre de course (race window). Cette fenêtre peut être extrêmement courte, de l'ordre de quelques microsecondes, ce qui rendait historiquement ces attaques difficiles à exploiter à distance.

2.2 Le problème du network jitter

Le network jitter désigne la variation du temps de latence entre l'émission et la réception des paquets réseau. Sur Internet, les paquets empruntent des chemins différents avec des latences variables, créant une irrégularité qui rendait les attaques par race condition imprévisibles.

Pour exploiter une race condition, il faut que plusieurs requêtes arrivent dans la même fenêtre temporelle sur le serveur. Avec des variations de latence de plusieurs dizaines de millisecondes, synchroniser des requêtes à distance semblait impossible. C'est précisément ce problème que la technique « Smashing the State Machine » résout.

3. La révolution Smashing the State Machine

Présentée à Black Hat USA 2023 par James Kettle, directeur de recherche chez PortSwigger, la technique Smashing the State Machine a transformé l'exploitation des race conditions web. L'innovation centrale : la single-packet attack.

Le principe est élégant : au lieu d'envoyer 20 requêtes dans 20 paquets TCP séparés (chacun subissant le jitter réseau), on encapsule les 20 requêtes dans un seul paquet TCP. Le serveur reçoit alors toutes les requêtes simultanément, éliminant totalement le problème du jitter.

L'algorithme exploite le multiplexage HTTP/2 : il retient stratégiquement le dernier octet de chaque requête, puis les libère tous simultanément. Les mesures de performance sont impressionnantes : avec un spread médian d'une milliseconde et un écart-type de seulement 0,3 ms entre Melbourne et Dublin (17 000 km), la synchronisation atteint une précision inégalée.

3.1 Les cinq classes de vulnérabilités identifiées

La recherche de Kettle identifie cinq catégories distinctes de vulnérabilités exploitables :

• Limit overrun : dépassement de limites sur codes promo, cartes cadeaux, retraits bancaires
• Multi-endpoint race conditions : collision entre endpoints différents partageant des données
• Single-endpoint collisions : un endpoint entrant en collision avec lui-même
• Partial construction attacks : exploitation d'objets partiellement initialisés
• Deferred collisions : collisions retardées via traitement batch

3.2 CVE critiques exploitant des race conditions en 2024-2025

Les race conditions ne sont pas qu'un problème théorique. L'année 2024 a vu plusieurs CVE critiques exploitant ce type de vulnérabilité :

4. Démonstration pratique : exploiter une race condition

PortSwigger propose des laboratoires pratiques sur sa Web Security Academy pour s'exercer à ces techniques. Voici une démonstration complète sur un scénario classique : l'exploitation multiple d'un code promo à usage unique.

4.1 Contexte du laboratoire

Le scénario est le suivant : nous devons acheter un article à 1 337 $ avec seulement 50 $ de crédit disponible. Un code promo « PROMO20 » offrant 20 % de réduction est disponible, mais il est censé être à usage unique. L'objectif : appliquer ce code plusieurs fois pour réduire suffisamment le prix.

4.2 Capture et analyse des requêtes avec Burp Suite

Avec Burp Suite, nous capturons les requêtes HTTP échangées avec le serveur. La requête POST d'application du code promo est notre cible principale. En tentant de renvoyer cette requête une seconde fois, nous obtenons le message « Coupon already applied », confirmant que le serveur vérifie bien l'unicité.

4.3 Vérification du stockage de session

Pour confirmer que le panier est stocké côté serveur et lié à notre session, nous analysons les requêtes GET. En modifiant le cookie de session, le panier apparaît vide, confirmant que l'état est bien maintenu côté serveur. Cette vérification confirme une opportunité de race condition.

4.4 Préparation de l'attaque parallèle

Nous créons un groupe de requêtes identiques dans Burp Suite. La fonction « Send group (parallel) » permet d'envoyer toutes ces requêtes simultanément, exploitant le principe de la single-packet attack.

4.5 Exécution et résultats

Après avoir retiré le code promo du panier pour revenir à l'état initial, nous lançons l'attaque. Les résultats montrent que plusieurs requêtes réussissent à appliquer le code promo « simultanément », avant que le serveur n'ait eu le temps de marquer le code comme utilisé.

En répétant l'opération, nous parvenons à réduire le prix jusqu'à 24,07 $, bien en dessous de notre crédit de 50 $. Le laboratoire est résolu avec succès.

5. Prévention et remédiation

La prévention des race conditions repose sur plusieurs principes fondamentaux issus de la gestion des transactions en base de données et de la programmation concurrente.

5.1 Le modèle ACID et les transactions atomiques

Une transaction doit respecter les propriétés ACID :

• Atomicité : la transaction s'exécute entièrement ou pas du tout
• Cohérence : la base reste cohérente avant et après la transaction
• Isolation : les transactions concurrentes n'interfèrent pas entre elles
• Durabilité : une fois validée, la modification est permanente

Le pattern recommandé combine vérification et action dans une seule opération SQL. Cette approche élimine la fenêtre TOCTOU (Time-of-check Time-of-use) en évitant un SELECT préalable suivi d'un UPDATE séparé.

5.2 Les idempotency keys

Pour les APIs REST, les idempotency keys constituent la défense la plus efficace. Chaque requête POST critique inclut un identifiant unique (UUID v4) dans un header dédié. Le serveur stocke atomiquement cette clé et rejette toute requête avec une clé déjà vue.

Stripe et Adyen implémentent ce pattern avec une durée de cache de 24 à 48 heures. Cette approche garantit qu'une même opération ne peut pas être exécutée plusieurs fois, même en cas de retry réseau légitime.

5.3 Outils de détection et tests

5.4 Mesures complémentaires

• Verrous distribués : Redis SETNX avec TTL ou Etcd pour les architectures microservices
• Niveaux d'isolation : SERIALIZABLE offre la protection maximale au prix de performances réduites
• Rate limiting : limiter le nombre de requêtes simultanées par session
• Monitoring : détecter les patterns d'attaque via l'analyse des logs

6. Contexte réglementaire français : NIS2, DORA et nouvelles obligations

La gestion des race conditions prend une dimension réglementaire nouvelle avec l'entrée en vigueur de plusieurs textes européens imposant des tests de sécurité applicative documentés.

6.1 NIS2 et la sécurité du développement

La transposition française de NIS2 est attendue au premier trimestre 2026 avec une conformité complète exigée fin 2027. Environ 15 000 entités françaises sont concernées.

L'article 21 impose explicitement la « sécurisation du développement/maintenance incluant la gestion des vulnérabilités », avec obligation de tests réguliers de résilience. Les sanctions atteignent 10 millions d'euros ou 2 % du CA mondial pour les entités essentielles, bien que l'ANSSI ait annoncé une période de grâce de 3 ans.

6.2 DORA et les tests de pénétration obligatoires

DORA (Digital Operational Resilience Act) s'applique depuis le 17 janvier 2025 au secteur financier. L'article 24-27 impose des programmes de tests couvrant :

• Scans de vulnérabilités
• Revues de sécurité réseau
• Analyses de code source
• Tests basés sur des scénarios

Les TLPT (Tests de Pénétration Fondés sur la Menace) deviennent obligatoires tous les 3 ans pour les entités systémiques.

6.3 Cyber Resilience Act

Le Cyber Resilience Act (Règlement 2024/2847) impose :

• À partir de septembre 2026 : notification obligatoire des vulnérabilités activement exploitées
• À partir de décembre 2027 : interdiction de mettre sur le marché des produits contenant des vulnérabilités connues exploitables

6.4 Les race conditions dans les bug bounty

Les race conditions figurent parmi les vulnérabilités les mieux récompensées sur HackerOne avec des primes atteignant 5 000 dollars. Les scénarios les plus valorisés concernent l'exploitation financière : codes promo multiples, paiements dupliqués, bypass de limites de retrait.

Cette valorisation économique confirme l'importance stratégique de ces vulnérabilités pour les organisations, particulièrement dans les secteurs e-commerce, fintech et services bancaires.