Le Bulletin Cyber – Mars 2021

Thématiques associées Cybersécurité EY Consulting

Découvrez l’édition du mois de mars de notre Bulletin Cyber, un condensé des dernières attaques par ransomware et les différents aspects de sécurisation des actions utilisateur.

2021 : Evolution de la menace et réponse coordonnée

Dans un récent rapport, l'ANSSI a montré que les attaques par ransomware ont progressé de près de 255% en 2020 par rapport à 2019. Cette progression aura également mis en valeur certains principes qui, s'ils sont considérés aujourd'hui comme acquis, n'ont pas toujours été évidents :

  • L’adaptation des criminels à leur cible : les cybercriminels les plus évolués ont complexifié leurs attaques et les personnalisent. Si les campagnes massives existent toujours, et visent avant tout à toucher un grand nombre de victimes, les pirates informatiques cherchent aussi à maximiser leurs revenus en s'adaptant au contexte de l'organisation et de ses moyens, et n'hésitent pas à modifier leurs outils ou leurs méthodes pour les rendre spécifiques à leur cible.
  • Le ransomware-as-a-service : ce modèle est désormais plébiscité par certains groupes de pirates, puisqu'il permet d'offrir à des individus ne disposant pas de compétences techniques d'un service clé en main. Les pirates peuvent aussi élargir leur base de clients, et de victimes, et réduire les coûts des attaques. Les dernières opérations des forces de l'ordre se concentrent d'ailleurs sur les pirates opérant de tels services, puisqu'elles permettent de faire cesser rapidement de grandes campagnes malveillantes.
  • La double-extorsion : aujourd'hui, la plupart des opérateurs criminels agissent en deux temps : une fois les données chiffrées, les pirates publient publiquement sur leurs sites de premiers éléments, prouvant leurs méfaits, et pressent ainsi les victimes à payer les rançons sans quoi les données seraient divulguées. Ce principe à double-détente est devenu si courant qu'il nous ferait même oublier qu'il n'en a pas toujours été ainsi : la seule immobilisation des données était la norme des ransomware des années durant.

Cette progression rapide et cette évolution ont fait prendre conscience aux pouvoirs publics de l'importance d'une réponse forte. Aux Etats-Unis, le CISA a multiplié les alertes et les messages de sensibilisation tandis qu'en France, le Gouvernement a présenté un plan de stratégie nationale pour la cybersécurité d'un milliard d'euros, financé par France Relance et le Programme d'Investissement d'avenir.

Les administrations locales et le secteur de la santé seront les premiers bénéficiaires de ce plan, considérant qu'ils sont des victimes récurrentes, et systématiques, des cybercriminels : récemment encore, des mutuelles et des hôpitaux, des municipalités et des collectivités territoriales ont encore été la cible de campagnes malveillantes. Parmi les évènements les plus critiques, la publication des données de près de 490 000 patients français, principalement dans les régions de l'Ouest et du Centre, a exposé les patients à des risques de phishing et d'ingénierie sociale.

Quand les protocoles d’authentifications sont faillibles : focus sur JWT

Le point commun entre toutes les architectures des systèmes d’information modernes en entreprise, c’est qu’elles ont tendance à se complexifier de plus en plus. L’objectif principal d’une application étant de permettre à un utilisateur de réaliser une (ou plusieurs) actions de manière efficace et sécurisée, les entreprises se concentrent de plus en plus sur les manières d’assurer la sécurisation de ces actions. 

En tant qu’experts de la cybersécurité, nous nous intéressons particulièrement à ces aspects de sécurisation des actions utilisateur, principalement en étudiant les mécanismes d’authentification et d’autorisation.

Toc toc, je peux entrer ?

OAuth2 est un protocole d'autorisation, défini dans le cadre de la RFC 6749  de plus en plus utilisé en entreprise. Il répond à la question suivante : comment s'assurer qu'un utilisateur puisse, de la manière la plus sécurisée et la plus efficace possible, accéder à toutes les ressources auxquelles il a le droit d’accéder, et uniquement celles-là ?

OAuth2 répond à cette question en définissant un ensemble de flows d'autorisation, i.e. des trames prédéfinies d’échange d’authentifiant entre l’utilisateur de l’application et les différents composants du backend de l’application permettant de récupérer un access_token.
Cet access_token est alors systématiquement inclus dans les requêtes effectuées par les utilisateurs de l’application.

Les flows les plus importants définis par OAuth2 sont les suivants :

  • Authorization Code Grant Flow
  • Refresh Token Grant Flow
  • Client Credential Grant Flow

Le JWT, porte-clé des autorisations

Les JSON Web Token (ou JWT) sont un format de tokens de données ayant comme propriété d’être compact, self-contained et pouvant être signé.

Les JWT sont l'une des implémentations possibles des access_tokens utilisés dans les flows OAuth2, même s’il faut noter que cette implémentation n'est pas la seule possible.

Un JWT revêt la forme suivante :

Il peut être décomposé en 3 parties :

  • Header : eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Le header permet de définir comment le reste du token doit être traité : ici nous avons un algorithme de hashage en HS256 (HMAC with SHA-256).

  • Payload : eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ

La payload contient les claims, qui sont les informations inclues directement dans le JWT et que l’application doit prendre en compte pour gérer les autorisations de l’utilisateur.

  • Signature : SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

La signature permet de s’assurer de l’intégrité du JWT. Elle est calculée suivant la méthode de hashage du Header et utilise un secret défini à la création du JWT. De ce fait, il n’est pas possible de modifier le JWT tout en gardant son intégrité sans connaitre la signature.

La poste n’accepte pas encore les JWT

Le JWT, tel que présenté plus haut, s’avère donc être un moyen pratique d’assumer la fonction d’autorisation dans le contexte d’applications web. La question est : comment rajouter ce JWT aux requêtes HTTP envoyées aux serveurs ?

La RFC 6750 apporte des éléments de réponse en recommandant d’utiliser le header « HTTP Authorization » avec le schéma d’authentification HTTP Bearer (défini dans ce même RFC).
L’idée est de dire que le porteur du token (ou le bearer en anglais) a le droit de demander l’accès à la ressource[1]. Ce qui est intéressant, et utile d’un point de vue sécurité, avec l’utilisation du « header Authorization » est le fait qu’il n’est pas inclus par défaut dans la requête du navigateur. Si l’utilisateur clique sur un lien malicieux et que cela génère une requête, cette dernière ne contiendra pas le header et donc sera refusée par le serveur.

Ce vecteur d’attaque vous rappelle quelque chose ? Oui, c’est bien du CSRF (ou Cross Site Request Forgery). L’utilisation d’un JWT dans un Authorization Header le protège de l’attaque de type CSRF.

C’est génial, j’en achète 10 000

Bien que l’utilisation du JWT soit de plus en plus fréquente et qu’il devient une solution privilégiée chez beaucoup de développeurs, son implémentation doit être réalisée avec vigilance : 

To sign or not to sign ?

L’un des premiers contrôles à effectuer afin de vérifier la bonne implémentation des JWT est de regarder du côté du champ (aussi appelé ‘claim’) du header du JWT.

Supposons qu’on ait un « alg » défini à « HS256 ». Le serveur va donc vérifier, à la réception du token, que la signature HMACSHA256 (utilisant le secret défini à la génération du JWT) est bien valide.

Si on définit la valeur de « alg » à « none », certaines implémentations de JWT[2] ne sauront   pas comment traiter ce cas et la signature ne sera pas vérifiée. Il sera alors possible de modifier le JWT sans compromettre son intégrité, et donc pouvoir s’octroyer tous les droits souhaités.

Il est recommandé de mettre à jour les librairies vulnérables à cette attaque afin de s’en protéger.

Faux et usage de faux

Toujours dans la même philosophie du claim « alg » des JWT, il est possible de réaliser une attaque par re-signature (re-signing attack).

Ici, l’idée est de jouer avec les nuances entre la cryptographie asymétrique (ici RS256) et la cryptographie symétrique (ici HS256). Voici le scénario :

  • Le client récupère une clé (appelée clé publique) du serveur. Le serveur garde une autre clé appelée clé privée.
  • Le JWT est signé en RS256 (RSA donc asymétrique) avec la clé publique au moment de l’envoi.
  • Le serveur vérifie que le JWT est bien intègre en utilisant la clé privée.

Deux clés différentes existent donc : une pour signer et une autre pour vérifier la signature.

Toutefois, en faisant croire au serveur qu’il n’y a qu’une seule clé, celle-ci pourrait être utilisée pour lui faire accepter des JWT modifiés. L’articulation serait alors la suivante : 

  • Le client récupère la clé publique du serveur. Le serveur garde une autre clé appelée clé privée.
  • Le JWT est signé avec la clé publique au moment de l’envoi mais le claim « alg » est défini à HS256 au lieu de RS256 (symétrique cette fois)
  • Le serveur, pensant maintenant que la signature du JWT est basée sur de la cryptographie symétrique, vérifie que le JWT est bien intègre en utilisant la clé publique (qui de son point de vue est la seule clé de l’échange).

Cette erreur d’implémentation permet donc à un utilisateur malveillant de produire des JWT signés contenant toutes les informations nécessaires à l’acquisition de nouveaux droits.

Clap de fin ?

Un aspect un peu plus fonctionnel de l’utilisation du JWT doit enfin être mis en exergue : la déconnexion.

Un JWT étant un access_token utilisé uniquement dans le cadre de la gestion des autorisations : il ne se préoccupe pas de la question de la déconnexion qui est du domaine de l’authentification.

Que faire alors si une application se base uniquement sur les JWT afin de valider toutes les actions de l’utilisateur et que la déconnexion n’annule pas ce JWT ?
En théorie (et malheureusement aussi en pratique), il est possible de rejouer les requêtes de l’utilisateur déconnecté et d’accéder aux mêmes droits que lui ; les implémentations des JWT ne prennent pas en compte cet aspect et donc souffrent toutes de ce problème.

Cette vulnérabilité, couplée à des JWT avec des durées de validité qui se comptent en heures (rappelez-vous plus haut, exp – iat) et un mécanisme de renouvellement de JWT nécessitant uniquement l’ancien JWT permettraient alors à un utilisateur malveillant d’ obtenir un JWT quelques heures après la déconnexion d’un utilisateur légitime pour réaliser des actions indéfiniment en renouvelant le token JWT.

Cette faiblesse d’implémentation ne doit pas être négligée. Elle peut cependant être contournée via l’utilisation d’un refresh token[3] ou bien via la mise en place d’une solution de fédération d’authentification et d’autorisation (via OpenID Connect[4] par exemple, basée sur OAuth 2).

Clap de fin !

Nous avons vu dans cet article ce que Oauth2 apportait de majeur dans l’évolution et la prise en compte de la sécurité dans le monde du web. Cependant, nous avons également découvert certains points d’attention à avoir lors de l’implémentation JWT.

Comme toujours, la vérification et le respect de la norme peut faire éviter quelques erreurs, aux conséquences pouvant être très dommageable concernant l’activité de l’entreprise.

Pour aller plus loin

Les dirigeants, les conseils d'administration et les responsables de la cybersécurité ne sont pas toujours informés des menaces que suscitent les nouvelles formes émergentes de cybercriminalité. Ce bulletin propose une vision claire de ces menaces, qu’elles soient sectorielles, informatiques ou mobiles. Il présente les dernières tendances ainsi qu’une version synthétique des rapports proposés chaque semaine à nos clients. N’hésitez pas à nous contacter pour plus d’informations

Nos atouts

  • Le Lab : 600m2 dédiés à la recherche et au développement à l’innovation et à la transformation numérique.
  • War Room : Un environnement hautement sécurisé exploitant des solutions collaboratives et des technologies propriétaires innovantes.
  • Cyber Teams : L’équipe EY France cybersécurité est composée d’experts pluridisciplinaires, proposant des solutions nouvelles pour résoudre des problématiques stratégiques pour nos clients.
  • CyberEye : Une solution leader de Cyber Threat Intelligence solution, apportant une connaissance précise des cybermenaces pouvant toucher les entreprises.
  • ASC and CTI : Nos 63 Advanced Security Centers, situés dans de nombreux pays, partagent des renseignements opérationnels et centrés vers les entreprises pour notre Cyber Threat Intelligence.

Ce qu’il faut retenir

Les attaques par ransomware ne cessent de progresser et les cybercriminels les plus évolués continuent à personnaliser et complexifier leurs attaques. Si les campagnes massives existent toujours, c’est parce que les pirates n'hésitent pas à modifier leurs outils ou leurs méthodes pour les rendre spécifiques à leur cible. Dans cette nouvelle édition du bulletin cyber, les experts EY décryptent certains principes et reviennent sur les différents aspects de sécurisation des actions utilisateur, notamment le protocole d’autorisation OAuth2, qui est de plus en plus utilisé comme une solution privilégiée chez beaucoup de développeurs.

[1] https://swagger.io/docs/specification/authentication/bearer-authentication/

[2] https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/

[3] https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/

[4] https://openid.net/connect/faq/