Découvrez Missions : la nouvelle étape de la formation à la sécurité centrée sur les développeurs

Depuis 2015, nous mobilisons les développeurs du monde entier grâce à une approche proactive et positive de la sécurité, en les aidant à acquérir les compétences nécessaires pour sécuriser leur code, réduire les retouches et les corrections, et, espérons-le, à ne plus voir l'équipe de sécurité comme la « police du plaisir ».

Nous restons déterminés à accompagner les développeurs dans la sécurisation de leur code à travers la galaxie, mais il est temps de bousculer les habitudes et de faire passer nos développeurs aguerris et sensibilisés à la sécurité au niveau supérieur.

Nous sommes ravis d'annoncer le lancement d'une toute nouvelle fonctionnalité sur la plateforme Secure Code Warrior : les Missions. Cette catégorie de défis inédite constitue la prochaine étape de la formation à la sécurité axée sur les développeurs, permettant aux utilisateurs de passer de la simple mémorisation de connaissances théoriques à leur application dans un environnement de simulation réel. Cette approche structurée de micro-apprentissage permet de développer des compétences solides en codage sécurisé, pertinentes pour le travail et bien plus divertissantes que de regarder passivement des vidéos de formation interminables pendant sa journée de travail.

Notre première Mission publique jouable est une simulation de la faille Unicode de GitHub. Cela peut sembler trompeusement simple, mais il s'agit d'une vulnérabilité très ingénieuse et amusante à disséquer. Le chercheur en sécurité 0xsha a réalisé une étude de cas complète sur la manière dont ce même bug peut être utilisé pour exploiter Django via des transformations de casse, tout en révélant comment le comportement de la vulnérabilité peut varier selon les langages de programmation. Il y a beaucoup à découvrir sur ce problème de sécurité, et notre mission est un excellent point de départ.

La collision frontale (mappage de casse) de GitHub

Dans un article de blog du 28 novembre 2019, le groupe de recherche en sécurité Wisdom a fait état d'une faille de sécurité découverte sur GitHub. Ils ont expliqué comment ils ont pu utiliser une collision de mappage de casse dans Unicode pour déclencher l'envoi d'un e-mail de réinitialisation de mot de passe vers la mauvaise adresse e-mail (ou, si l'on se place du point de vue d'un attaquant, vers une adresse e-mail choisie par l'acteur malveillant).

Bien qu'une vulnérabilité de sécurité ne soit jamais une bonne nouvelle, les chercheurs en sécurité « whitehat » font preuve d'une certaine clémence — sans parler de l'opportunité d'éviter un désastre — lorsqu'ils découvrent des erreurs potentiellement exploitables dans une base de code. Leurs blogs et rapports sont souvent passionnants à lire, et il est toujours intéressant d'en apprendre davantage sur une nouvelle vulnérabilité et son fonctionnement.

Pour atteindre le niveau supérieur en matière de codage sécurisé, il est extrêmement puissant non seulement de trouver les vulnérabilités courantes (surtout les nouvelles, car nous savons tous que les acteurs malveillants chercheront un terrain fertile pour exploiter ces nouvelles techniques), mais aussi de disposer d'un environnement sûr et pratique pour comprendre comment les exploiter.

Alors, faisons exactement cela. Continuez votre lecture pour découvrir comment une collision de mappage de casse dans Unicode peut être exploitée, à quoi cela ressemble en temps réel, et comment vous pouvez adopter l'état d'esprit d'un chercheur en sécurité pour essayer par vous-même.

Prêt à vous confronter à une collision de mappage de casse dès maintenant ? Lancez-vous :

Unicode : complexe, infiniment personnalisable et bien plus que de simples emojis

« Unicode » ne fait peut-être pas partie du vocabulaire courant, mais il est fort probable que la plupart des gens l'utilisent sous une forme ou une autre chaque jour. Si vous avez utilisé un navigateur web, un logiciel Microsoft ou envoyé un emoji, vous avez été en contact direct avec Unicode. Il s'agit d'une norme pour l'encodage et le traitement cohérents du texte provenant de la plupart des systèmes d'écriture mondiaux, garantissant que chacun puisse s'exprimer (numériquement) en utilisant un jeu de caractères unique. À l'heure actuelle, il existe plus de 143 000 caractères, vous êtes donc couvert, que vous utilisiez l'islandais, le « i » sans point turc ou tout autre système.

En raison du volume considérable de caractères dans le jeu Unicode, un moyen de convertir les caractères en un autre caractère « équivalent » est nécessaire dans de nombreux cas. Par exemple, il semble logique que si vous convertissez une chaîne Unicode contenant un « i » sans point en ASCII, elle devrait simplement se transformer en « i », n'est-ce pas ?

Un grand volume d'encodage de caractères implique un grand risque de désastre

Une collision de mappage de casse dans Unicode est une faille de logique métier qui, à la base, peut conduire à une prise de contrôle de comptes non protégés par la double authentification (2FA). Pour illustrer la vulnérabilité en question, examinons un exemple de ce bug dans un extrait de code réel :

app.post(/api/resetPassword, function (req, res) {
  var email = req.body.email;
  db.get(SELECT rowid AS id, email FROM users WHERE email = ?, [email.toUpperCase()],
      (err, user) => {
          if (err) {
              console.error(err.message);
              res.status(400).send();
          } else {
              generateTemporaryPassword((tempPassword) => {
                  accountRepository.resetPassword(user.id, tempPassword, () => {
                      messenger.sendPasswordResetEmail(email, tempPassword);
                      res.status(204).send();
                  });
              });
          }
      });
});

La logique fonctionne comme suit :

1. Elle accepte l'adresse e-mail fournie par l'utilisateur et la met en majuscules pour plus de cohérence.
2. Elle vérifie si l'adresse e-mail existe déjà dans la base de données.
3. Si c'est le cas, elle définit un nouveau mot de passe temporaire (ce n'est pas une bonne pratique, soit dit en passant. Utilisez plutôt un lien avec un jeton permettant une réinitialisation du mot de passe).
4. Elle envoie ensuite un e-mail à l'adresse récupérée à l'étape 1, contenant le mot de passe temporaire (c'est une très mauvaise pratique, pour de nombreuses raisons. Aïe.)

Voyons ce qu'il advient de l'exemple fourni dans le billet de blog original, où un utilisateur demande une réinitialisation de mot de passe pour l'adresse e-mail John@GıtHub.com (notez le i sans point turc) :

1. La logique convertit John@Gıthub.com en JOHN@GITHUB.COM
2. Elle effectue une recherche dans la base de données et trouve l'utilisateur JOHN@GITHUB.COM
3. Elle génère un nouveau mot de passe et l'envoie à John@Gıthub.com

Notez que ce processus finit par envoyer l'e-mail hautement confidentiel à la mauvaise adresse. Oups !

Comment exorciser ce démon Unicode

L'aspect intéressant de cette vulnérabilité spécifique est qu'elle repose sur plusieurs facteurs :

1. Le comportement réel de conversion Unicode
2. La logique déterminant l'adresse e-mail à utiliser, c'est-à-dire l'adresse fournie par l'utilisateur au lieu de celle déjà présente dans la base de données.

En théorie, vous pouvez corriger ce problème spécifique de deux manières, comme identifié dans le billet de blog de Wisdom :

1. Convertir l'e-mail en ASCII avec la conversion Punycode
2. Utiliser l'adresse e-mail issue de la base de données plutôt que celle fournie par l'utilisateur

Lorsqu'il s'agit de renforcer un logiciel, il est judicieux de ne rien laisser au hasard en multipliant les couches de défense. Pour autant que nous sachions, il pourrait exister d'autres moyens d'exploiter cet encodage que nous ignorons encore. Tout ce qui permet de réduire les risques et de fermer les portes laissées ouvertes aux attaquants est précieux.

Prêt à essayer par vous-même ?

La plupart des développeurs savent que la compromission de données est préjudiciable. Cependant, les ingénieurs sensibilisés à la sécurité constituent un puissant antidote contre la recrudescence des vulnérabilités, des failles et des problèmes de cybersécurité.

Il est temps de faire passer vos compétences en codage sécurisé au niveau supérieur. Découvrez cette vulnérabilité GitHub dans une simulation immersive et sécurisée, où vous pourrez constater l'impact d'un code défaillant, tant côté frontend que backend. Les attaquants ont l'avantage, alors équilibrons les chances et utilisez vos compétences pour une contre-attaque éthique.