Quand les attaquants se régalent avec les cookies

Dans un récent rapport de type CTI [2], le CERT-FR de l’ANSSI rappelle les limites de l’authentification forte lorsque les attaquants dérobent directement un jeton d’authentification à l’utilisateur. Cela ne veut pas dire que l’authentification à plusieurs facteurs est inutile, loin de là, juste qu’elle ne sert plus à rien quand un attaquant a commencé à piocher un cookie dans la boite. Comme tout dispositif (de la vie numérique ou réelle) de sécurité, il est important d’avoir en tête le périmètre qu’il protège. Dans une voiture, si les freins peuvent vous permettre d’éviter de heurter un obstacle, lorsque le choc est survenu, ils ne servent plus à rien. Ce sont d’autres dispositifs qui interviennent dans la phase suivante, tels que la ceinture et les airbags pour vous éviter de taper la tête contre le volant ou de passer à travers le pare-brise. Vous n’entendrez jamais personne vous dire que les freins d’une voiture ne servent à rien.

Alors la recette des cookies, ça consiste en quoi ?
On peut dire qu’il y a deux principales recettes :

- la première consiste à compromettre le terminal utilisateur authentifié et lui dérober le jeton d’authentification, comme le font plusieurs outils de type RAT (Remote Administration Tool), notamment Qbot [3], Cryptbot [4] ou encore ce RAT s’appuyant sur un Bot Telegram, plus difficile à identifier au niveau des flux réseau [5].

- la seconde recette consiste à attirer l’utilisateur, via un courriel de phishing généralement, à se connecter sur un serveur contrôlé par l’attaquant sur lequel est exécuté un reverse proxy de type Muraena [6] ou encore le très bien pensé Evilginx [7] pour intercepter le jeton d’authentification. 

Le CERT-FR rappelle que les groupes LAPSUS$ (piratage d’Okta notamment) et Nobelium (piratage de SolarWinds notamment) ont recours à ce type d’attaque pour compromettre des accès et que des boutiques comme Genesis font de la vente de jetons d’authentification leur business.

Parmi les recommandations de l’ANSSI, on retrouve le durcissement du SI dédié à l’administration, ou encore la réduction de la durée de vie des sessions lorsque cela est possible.
Côté utilisateur, même si cela n’est pas indiqué dans le rapport, un truc tout bête peut limiter les risques également : se déconnecter du service web lorsque l’on a fini de l’utiliser.

[1] https://www.apssis.com/video/353/conference-13-le-mot-de-passe-est-mort-vive-l-authentification.htm 

https://www.apssis.com/actualite-ssi/338/le-mot-de-passe-est-mort-vive-l-authentification-votre-cle-est-elle-sous-le-paillasson-le-compte-rendu-de-gerard-peliks.htm 

[2] https://www.cert.ssi.gouv.fr/cti/CERTFR-2022-CTI-005/ 

[3] https://malpedia.caad.fkie.fraunhofer.de/details/win.qakbot 

[4] https://malpedia.caad.fkie.fraunhofer.de/details/win.cryptbot 

[5] https://github.com/romanrakhlin/RAT-via-Telegram-Bot 

[6] https://github.com/muraenateam/muraena 

[7] https://github.com/kgretzky/evilginx2 

L'auteur

Chef de projet sécurité numérique en santé - GCS e-santé Pays de la Loire Charles Blanc-Rolin est également vice-président de l’APSSIS(Association pour la promotion de la Sécurité des Systèmes d'Information de Santé)