Si les organisations veulent prendre au sérieux la sécurité des logiciels, elles doivent donner à leurs ingénieurs les moyens de jouer un rôle défensif contre les cyberattaques lors de l’élaboration de leur code.

Le problème est que les développeurs n’ont pas eu l’introduction la plus inspirante à la formation à la sécurité au fil des ans, et tout ce qui peut être fait pour rendre leur expérience plus engageante, productive et amusante va être un puissant facteur de motivation pour les aider à gagner en sécurité. compétences en codage.

Et après avoir consacré un temps précieux à la maîtrise de nouvelles capacités qui peuvent aider à battre les attaquants à leur propre jeu, l’opportunité de tester ces nouveaux pouvoirs n’est pas facile à trouver dans un environnement sûr.

Alors, que doit faire un ingénieur aguerri et conscient de la sécurité?

Une nouvelle fonctionnalité publiée sur la plateforme Secure Code Warrior, nommée ‘Missions, ‘est une catégorie de défi qui élève les utilisateurs du rappel des connaissances acquises en matière de sécurité à leur application dans un environnement de simulation réel.

Cette approche de micro-apprentissage en échafaudage développe des compétences de codage solides et sécurisées qui sont pertinentes pour le travail et beaucoup plus divertissantes que de regarder (verticalement) des vidéos de formation sans fin en arrière-plan d’une journée de travail.

La première «Mission» disponible est une simulation de la violation de GitHub Unicode. Ce n’est pas aussi simple que cela puisse paraître à la surface, et c’est une vulnérabilité vraiment intelligente qui est amusante à disséquer. Le chercheur en sécurité 0xsha a fait un é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 montrant également comment le comportement de vulnérabilité peut changer entre les langages de programmation.

Il y a beaucoup plus à découvrir sur ce problème de sécurité, et voici un bon point de départ.

Collision frontale (mappage de cas) de GitHub

Dans un article de blog à partir du 28 novembre 2019, le groupe de recherche sur la sécurité Wisdom a signalé un bogue de sécurité découvert sur GitHub. Ils ont expliqué comment ils ont pu utiliser une collision de mappage de cas en Unicode pour déclencher une remise d’e-mail de réinitialisation de mot de passe à la mauvaise adresse e-mail (ou si vous pensiez comme un attaquant, une adresse e-mail choisie par l’acteur de la menace).

Bien qu’une vulnérabilité de sécurité ne soit jamais une bonne nouvelle, les chercheurs en sécurité qui balancent un blanc qui font preuve de pitié – sans parler de l’opportunité 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 lus, et c’est plutôt cool d’en savoir plus sur une nouvelle vulnérabilité et son fonctionnement.

Afin de passer au niveau supérieur de prouesses de codage sécurisé, il est super puissant non seulement de trouver des vulnérabilités communes, mais aussi de disposer d’un environnement sûr et pratique pour comprendre comment les exploiter également.

Continuez à lire pour découvrir comment une collision de mappage de cas en Unicode peut être exploitée, à quoi elle ressemble en temps réel et comment vous pouvez prendre en compte l’état d’esprit d’un chercheur en sécurité et l’essayer par vous-même.

Unicode: plus que des émojis

« Unicode » n’est peut-être pas sur le radar de la personne moyenne, mais les chances sont bonnes 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é proche et personnel avec Unicode.

C’est une norme pour l’encodage et la gestion cohérents du texte de la plupart des systèmes d’écriture du monde, garantissant que tout le monde peut (numériquement) s’exprimer en utilisant un seul jeu de caractères.

Dans l’état actuel des choses, il y a plus de 143000 caractères, vous êtes donc couvert, que vous utilisiez l’islandais þ, le turc sans point ı, ou quoi que ce soit entre les deux.

En raison du volume considérable de caractères qu’Unicode a dans son ensemble, un moyen de convertir des caractères en un autre caractère «équivalent» est nécessaire dans de nombreux cas. Par exemple, il semble raisonnable que si vous convertissez une chaîne Unicode avec un « ı » sans point en ASCII, qu’elle se transforme simplement en « i », n’est-ce pas?

Avec un grand volume de caractères, l’encodage est excellent responsabilité potentiel de catastrophe.

Une collision de mappage de cas dans Unicode est une faille de logique métier et peut conduire à une prise de contrôle de comptes non protégés par 2FA. Découvrez un exemple de ce bogue dans un vrai extrait de code:

La logique va quelque chose comme ceci:

1. Il accepte l’adresse e-mail fournie par l’utilisateur et la met en majuscule par souci de cohérence.
2. Il vérifie si l’adresse e-mail existe déjà dans la base de données.
3. Si tel est le cas, il définira un nouveau mot de passe temporaire (ce n’est d’ailleurs pas la meilleure pratique. À la place, utilisez un lien avec un jeton qui permet la réinitialisation du mot de passe)
4. Il 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. Yikes.)

Voyons ce qui se passe avec l’exemple fourni dans le article de blog original, où un utilisateur demande une réinitialisation de mot de passe pour l’e-mail John@GıtHub.com (notez le turc dotless i):

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 finit par envoyer l’e-mail hautement sensible à la mauvaise adresse e-mail. Oups!

Comment chasser ce démon Unicode

L’aspect intéressant de cette vulnérabilité spécifique est qu’il existe plusieurs facteurs qui la rendent vulnérable:

1. Le comportement réel de la diffusion Unicode,
2. La logique déterminant l’adresse e-mail à utiliser, c’est-à-dire l’adresse e-mail 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. Convertissez l’email en ASCII avec la conversion Punycode,
2. Utilisez l’adresse e-mail de la base de données plutôt que celle fournie par l’utilisateur.

Lorsqu’il s’agit de renforcer les logiciels, c’est une excellente idée de ne rien laisser au hasard, en utilisant autant de couches de défense que possible. Pour autant que vous le sachiez, il peut y avoir d’autres moyens d’exploiter cet encodage – vous n’en êtes tout simplement pas encore conscient. 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.

Prêt à piloter votre propre mission?

Il est temps de faire passer vos compétences en codage sécurisé et en sensibilisation au niveau supérieur. Découvrez cette vulnérabilité GitHub dans une simulation immersive et sûre, où vous pouvez 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-coup de poing blanc.