Une campagne d’attaques DDoS par amplification cible les sites de paris en ligne

Une campagne d'attaques DDoS par amplification cible les sites de paris en ligne français

Publié 6 Novembre 2019

Pragma Security (Paris, France) et Qrator Labs CZ (Prague, République Tchèque) partagent un résumé des récentes attaques DDoS par amplification TCP (attaque SYN/ACK) ayant ciblé et impacté des sites de paris en ligne français. Nous avons toutes les raisons de croire que ces attaques vont avoir un impact plus large que les réseaux ciblés car elles représentent une menace très sérieuse, pouvant mettre à mal certaines architectures de protection et pouvant être générées avec relativement peu de moyens.

Lundi 4 Novembre à 17:24 UTC (18H24 heure de Paris), la plateforme de filtrage anycast du réseau de Qrator a fait face à une vaste attaque de type TCP SYN/ACK venant majoritairement d’Europe et des États-Unis. Ces attaques ciblaient, notamment, des clients utilisant les services Qrator Labs en Europe.

De par son architecture anycast (traitement de l’attaque à sa source), la solution anti-DDoS de Qrator a pu filtrer ces attaques sur ses centres de nettoyage notamment positionnés à Ashburn, Amsterdam et Francfort. Au plus fort de l’attaque, l’amplification TCP SYN/ACK a atteint 270,18 Gbps et presque 500 millions de paquets par seconde. Après 28 minutes d’attaque sans dommage sur nos clients, l’assaut s’est arrêté à 17:51 UTC (18H51 heure de Paris). Il est fort probable que les attaques aient été redirigées vers des cibles plus vulnérables.

De telles attaques par amplification SYN / ACK représentent une nouvelle génération d’attaques DDoS ayant une force de frappe capable de neutraliser les petits fournisseurs de services Internet et les fournisseurs d’hébergement au sein d’une même région. De plus, comme ce trafic spoofé est généré à partir des infrastructures cloud – dans le cas présent, principalement AWS avec un peu de Herzner et Akamai – il est possible pour les attaquants de trouver des services TCP vulnérables dans n’importe quel pays et de déplacer leur arsenal en quelques minutes à l’emplacement souhaité. De nos jours, l’omniprésence des infrastructures de fournisseurs de services cloud (IaaS, SaaS, …) devient une aubaine pour les attaquants.

Comme l’expliquaient Qrator et l’un de ses partenaires dans un précédent rapport en Août dernier, les principaux problèmes à l’origine de SYN / ACK (ainsi que le flooding de paquets TCP en général) sont les suivants:

1.Ce type d’attaque DDoS est presque intraçable et la cellule organisant ce type de compagne a de grandes chances de ne jamais être retrouvée et poursuivie. D’un point de vue technique, en raison de la faible adoption des approches de lutte contre l’usurpation d’adresse IP encore appelé IP spoofing (telles que le BCP 38 https://www.bortzmeyer.org/bcp38.html), les infrastructures cloud se transforment en armes puissantes pour les attaquants. La mise en conformité des infrastructures cloud nécessite une refonte substantielle du réseau et dans certaines circonstances, cette mise en conformité aurait des impacts très lourds sur d’autres fonctionnalités du réseau. Ainsi, il est illusoire d’attendre que ce problème soit résolu à court et moyen termes par les acteurs du cloud. A plus long terme, les organismes de normalisation (IETF) pourront éventuellement proposer des solutions plus pragmatiques et moins coûteuses à mettre en oeuvre mais tout reste à faire.

2. Il est assez difficile pour un transitaire ou un hébergeur de faire face à ce type d’attaque seul. Comme nous l’avions évoqué lors du FRnOG 34 (https://www.youtube.com/watch?v=JpAKwvWS_LY passage en minute 8:00), une approche par l’utilisation de re-routage BGP dans des boîtiers de mitigation asymétriques ou l’utilisation de BGP flowspec est, dans la grande majorité des cas, sans effet sur ces attaques.  Les attaquants se sont, une fois de plus, adaptés aux systèmes de défense et aux architectures que les transitaires utilisent.

3. Afin d’assurer le traitement correct des attaques SYN / ACK tout en conservant la possibilité de se connecter à un service externe, une société d’hébergement attaquée devrait suivre tous les paquets TCP SYN sortants pour les faire correspondre ultérieurement aux SYN / ACK reçus. Ce type d’approche va impacter lourdement les équipements de sécurité centralisés de type Firewall. Quelle que soit l’approche retenue par l’hébergeur, elle aura des effets collatéraux sur la latence du trafic, le RTT (round trip time) ou les deux.

4. Pour une part considérable des services exposés sur Internet, la capacité de se connecter à un service externe ou à une passerelle API via TCP est cruciale. Les robots d’exploration de sites Web (Web crawlers), les technologies telles que OAuth ou CDN, les entreprises d’évaluation du crédit (credit scoring) ou les compagnies d’assurance exposent ou consomment beaucoup d’API sur Internet. Ainsi la mise hors service d’un seul site ou API peut avoir des effets collatéraux de grande ampleur.

5. A l’exception de certains cas marginaux, le facteur d’amplification pour une attaque SYN / ACK, est compris entre 1 et 5. Ce facteur est donc très faible si on le compare au NTP (500+) ou au Memcached (9000+). Toutefois, compte tenu de la complexité à traiter ce type d’attaque, cinq fois le débit de paquets pourrait constituer un scénario de rupture dans l’approche et le traitement des attaques par déni de service.

Note : L’attaque par amplification SYN / ACK est également fréquemment reconnue comme “attaque par amplification TCP”. Bien qu’une telle formulation soit évidemment correcte (de la même manière qu’une attaque par amplification NTP pourrait être appelée une attaque par amplification UDP), nous pensons qu’il est important de faire la distinction entre les attaques par amplification SYN / ACK et les autres attaques par amplification TCP. Typiquement, il faut les différencier des attaques de réflexion utilisant des serveurs vulnérables dont la pile protocolaire TCP utilise des algorithmes prévisibles de génération de numéros de séquence. 

Add a Comment

Your email address will not be published. Required fields are marked *