Présentation des missions : la prochaine phase de la formation à la sécurité centrée sur les développeurs

Depuis 2015, nous impliquons les développeurs du monde entier en adoptant une approche proactive et positive de la sécurité, en les aidant à développer les compétences nécessaires pour sécuriser leur code, à réduire le nombre de retouches et de corrections et, espérons-le, à considérer l'équipe de sécurité comme autre chose qu'une police amusante.

Nous sommes toujours déterminés à soutenir les développeurs lorsqu'ils sécurisent le code à travers la galaxie, mais il est temps de changer les choses et de faire passer nos développeurs aguerris et soucieux de la sécurité au niveau supérieur.

Nous sommes ravis d'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 prochaine étape de la formation à la sécurité pour les développeurs, qui permettra aux utilisateurs de passer du rappel des connaissances en matière de sécurité à leur application dans un environnement de simulation réel. Cette approche de microlearning échafaudée permet de développer de puissantes compétences de codage sécurisé qui sont pertinentes pour le poste et bien 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. Cela peut sembler d'une simplicité trompeuse, mais c'est une vulnérabilité vraiment intelligente qu'il est amusant de décortiquer. 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 révélant comment le comportement de la vulnérabilité peut changer entre les langages de programmation. Il y a encore beaucoup à découvrir sur ce problème de sécurité, et notre mission est un excellent point de départ.

Collision frontale (cartographie des cas) sur GitHub

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

Bien qu'une faille de sécurité ne soit jamais une bonne nouvelle, les chercheurs en sécurité qui n'hésitent pas à faire preuve de 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 une excellente lecture, et c'est plutôt cool d'en savoir plus sur une nouvelle vulnérabilité et sur son fonctionnement.

Pour passer à un niveau supérieur de prouesse en matière de codage sécurisé, il est extrêmement puissant non seulement de détecter les vulnérabilités courantes (en particulier les nouvelles vulnérabilités intéressantes, nous savons tous que les acteurs malveillants rechercheront un terrain fertile pour extraire des données grâce à ces nouvelles techniques), mais également de disposer d'un environnement sûr et pratique pour comprendre comment les exploiter également.

Alors, c'est exactement ce que nous faisons. Poursuivez votre lecture 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 adopter l'état d'esprit d'un chercheur en sécurité et l'essayer vous-même.

Êtes-vous prêt à affronter une collision liée à la cartographie des cas dès maintenant ? Passez à la vitesse supérieure :

Unicode : complexe, personnalisable à l'infini et bien plus que de simples émojis

Le mot « Unicode » ne figure peut-être pas dans le lexique de la personne moyenne, 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, c'est que vous avez utilisé Unicode de près. Il s'agit d'une norme pour l'encodage et la gestion cohérents du texte provenant de la plupart des systèmes d'écriture du monde, garantissant que tout le monde peut s'exprimer (numériquement) en utilisant un seul jeu de caractères. Dans l'état actuel des choses, il y a plus de 143 000 caractères, donc vous êtes couvert, que vous utilisiez l'islandais, le turc sans points, ou quelque chose entre les deux.

En raison du volume considérable de caractères que contient 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 raisonnable que si vous convertissez une chaîne Unicode sans point en ASCII, elle devienne simplement un « i », n'est-ce pas ?

Un grand volume de codage de caractères comporte un grand risque de catastrophe.

Une collision de mappage de cas en Unicode est une logique métier Une faille, et à la base, peut conduire à une prise de contrôle de comptes non protégés par la 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 (SÉLECTIONNEZ Rowid comme identifiant, e-mail DES utilisateurs OÙ e-mail = ? , [email.toUpperCase ()],
(erreur, utilisateur) => {
si (erreur) {
console.error (err.message) ;
res.status (400) .send () ;
} autre {
Générer un mot de passe temporaire ((TempPassword) => {
AccountRepository.ResetPassword (user.id, tempPassword, () => {
messenger.SendPasswordResetEmail (e-mail, TempPassword) ;
res.status (204) .send () ;
}) ;
}) ;
}
}) ;
}) ;

La logique est la suivante :

1. Il accepte l'adresse e-mail fournie par l'utilisateur et la met en majuscule pour des raisons de cohérence
2. Il vérifie si l'adresse e-mail 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 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). Argh.)

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

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 que de multiples facteurs la rendent vulnérable :

1. Le comportement réel du casting Unicode
2. La logique qui détermine 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 le billet de blog de Wisdom :

1. Convertissez l'e-mail en ASCII avec Conversion de code 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 bonne idée de ne rien laisser au hasard en utilisant autant de couches de défense que possible. Pour autant que nous sachions, il existe peut-être d'autres moyens d'exploiter cet encodage, mais nous ne les connaissons tout simplement 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.

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

La plupart des développeurs savent que la compromission de données est néfaste pour les entreprises. Cependant, les ingénieurs sensibilisés à la sécurité constituent un puissant antidote contre les vulnérabilités, les violations et les problèmes de cybersécurité croissants.

Il est temps de faire passer vos compétences en matière de codage sécurisé et de sensibilisation au niveau supérieur. Découvrez cette vulnérabilité de GitHub dans une simulation immersive et sécurisée, qui vous permet de voir l'impact d'un code incorrect dans les contextes frontend et backend. Les attaquants ont un avantage, alors égalisons les règles du jeu et appliquons de véritables compétences avec un contre-coup de chapeau blanc.