Présentation de Missions: La prochaine phase de la formation à la sécurité centrée sur le développeur

Depuis 2015, nous encourageons les développeurs du monde entier à adopter 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 travaux de reprise et de remédiation, et à considérer l'équipe de sécurité comme autre chose que la police du plaisir.

Nous nous engageons toujours aux côtés des développeurs pour sécuriser le code dans toute la galaxie, mais il est temps de faire bouger les choses et d'amener nos développeurs aguerris et sensibilisés à la sécurité à un niveau supérieur.

Nous sommes ravis de vous annoncer la sortie d'une toute nouvelle fonctionnalité sur la plateforme Secure Code Warrior : Missions. Cette toute nouvelle catégorie de défis constitue la phase suivante de la formation à la sécurité développée par les développeurs. Elle permet aux utilisateurs de passer de la mémorisation des connaissances en matière de sécurité à leur application dans un environnement de simulation du monde réel. Cette approche de micro-apprentissage, basée sur l'échafaudage, permet de développer de puissantes compétences de codage sécurisé qui sont pertinentes pour l'emploi et beaucoup plus divertissantes que de regarder (verticalement) d'interminables vidéos de formation en arrière-plan d'une journée de travail.

Notre première mission publique jouable est une simulation de la faille Unicode de GitHub. Elle peut sembler faussement simple, mais il s'agit d'une vulnérabilité très intelligente qu'il est amusant de disséquer. Le chercheur en sécurité 0xsha a réalisé une étude de cas complète sur la façon dont ce même bogue peut être utilisé pour exploiter Django par le biais de transformations de cas, tout en révélant également comment le comportement de la vulnérabilité peut changer d'un langage de programmation à l'autre. Il y a encore beaucoup à découvrir sur ce problème de sécurité, et notre mission est un excellent point de départ.

La collision frontale de GitHub (cartographie des cas)

Dans un billet de blog du 28 novembre 2019, le groupe de recherche en sécurité Wisdom a fait état d'un bug de sécurité qu'il a découvert sur GitHub. Ils ont décrit comment ils ont pu utiliser une collision de mappage de cas dans Unicode pour déclencher une livraison d'email de réinitialisation de mot de passe à la mauvaise adresse email (ou si nous pensions comme un attaquant, une adresse email du choix de l'acteur de la menace).

Bien qu'une faille de sécurité ne soit jamais une bonne nouvelle, les chercheurs en sécurité qui pratiquent le whitehat offrent une certaine clémence - sans parler de la possibilité d'éviter un désastre - s'ils découvrent des erreurs potentiellement exploitables dans une base de code. Leurs blogs et leurs rapports sont souvent très intéressants à lire, et c'est plutôt cool de découvrir une nouvelle vulnérabilité et son fonctionnement.

Pour passer au niveau suivant de prouesses en matière de codage sécurisé, il est extrêmement utile non seulement de trouver les vulnérabilités courantes (en particulier les nouvelles vulnérabilités les plus intéressantes - nous savons tous que les acteurs malveillants chercheront un terrain fertile pour déterrer des données à l'aide de ces nouvelles techniques), mais aussi de disposer d'un environnement sûr et pratique pour comprendre comment les exploiter.

C'est ce que nous allons faire. Poursuivez votre lecture pour découvrir comment une collision de cartographie de cas en Unicode peut être exploitée, comment elle se présente en temps réel, et comment vous pouvez adopter l'état d'esprit d'un chercheur en sécurité et l'essayer par vous-même.

Prêt à affronter une collision de cartographie de cas dès maintenant ? Allez-y :

Unicode : Complexe, personnalisable à l'infini et bien plus que des émojis

Le terme "Unicode" ne fait peut-être pas partie du lexique du commun des mortels, mais il y a de fortes chances que la plupart des gens l'utilisent sous une forme ou une autre tous les jours. Si vous avez utilisé un navigateur web, un logiciel Microsoft ou envoyé un emoji, vous avez été confronté de près ou de loin à l'Unicode. Il s'agit d'une norme permettant d'encoder et de traiter de manière cohérente les textes provenant de la plupart des systèmes d'écriture du monde, afin que tout le monde puisse s'exprimer (numériquement) à l'aide d'un seul jeu de caractères. À l'heure actuelle, il existe plus de 143 000 caractères. Vous êtes donc couvert, que vous utilisiez l'islandais ou le turc sans point, ou tout ce qui se trouve entre les deux.

En raison du grand nombre de caractères Unicode, il est souvent nécessaire de trouver un moyen de convertir les caractères en un autre caractère "équivalent". Par exemple, il semble logique que si vous convertissez une chaîne Unicode avec un point en ASCII, elle se transforme simplement en "i", n'est-ce pas ?

Un grand volume d'encodage de caractères est synonyme d'un grand potentiel de désastre

Une collision de mappage de cas en Unicode est une faille de logique d'entreprise qui peut conduire à une prise de contrôle de comptes non protégés par 2FA. Pour illustrer la vulnérabilité en question, examinons un exemple de ce bogue 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 est la suivante :

1. Il accepte l'adresse électronique fournie par l'utilisateur et la met en majuscules pour des raisons de cohérence.
2. Il vérifie si l'adresse électronique existe déjà dans la base de données.
3. Si c'est le cas, il définira un nouveau mot de passe temporaire (ce n'est d'ailleurs pas la meilleure pratique. Utilisez plutôt un lien avec un jeton qui permet de réinitialiser le mot de passe).
4. Il envoie ensuite un courrier électronique à l'adresse obtenue à l'étape 1, contenant le mot de passe temporaire (il s'agit d'une très mauvaise pratique, pour de nombreuses raisons...).

Voyons ce qui se passe avec l'exemple fourni dans le billet de blog original, où un utilisateur demande une réinitialisation de son mot de passe pour l'adresse électronique John@GıtHub.com (notez le i sans point turc) :

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

Notez que ce processus aboutit à l'envoi du courrier électronique hautement sensible à la mauvaise adresse électronique. Oups !

Comment chasser ce démon de l'Unicode ?

L'aspect intéressant de cette vulnérabilité spécifique est qu'elle est due à de multiples facteurs :

1. Le comportement réel du casting Unicode
2. La logique déterminant l'adresse électronique à utiliser, c'est-à-dire l'adresse électronique fournie par l'utilisateur, au lieu de celle qui existe déjà dans la base de données.

En théorie, vous pouvez résoudre ce problème spécifique de deux manières, comme indiqué dans l'article de blog de Wisdom :

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

Lorsqu'il s'agit de renforcer un logiciel, il est préférable de ne rien laisser au hasard et de mettre en place autant de couches de défense que possible. Pour autant que nous le sachions, il existe peut-être d'autres moyens d'exploiter ce codage, mais nous ne les connaissons pas encore. Tout ce que vous pouvez faire pour réduire les risques et fermer les fenêtres qui pourraient être laissées ouvertes à un attaquant est précieux.

Vous êtes prêt à l'essayer vous-même ?

La plupart des développeurs savent que les données compromises sont mauvaises pour les affaires. Cependant, les ingénieurs sensibilisés à la sécurité sont un antidote puissant contre les vulnérabilités croissantes, les brèches et les problèmes de cybersécurité.

Il est temps d'améliorer vos compétences en matière de codage sécurisé et de sensibilisation. Découvrez cette vulnérabilité de GitHub dans une simulation immersive et sûre, où vous pourrez voir l'impact d'un mauvais code dans les contextes frontend et backend. Les attaquants ont un avantage, alors égalisons le terrain de jeu et appliquons de vraies compétences avec un contre-pied blanc.