MyBB 1.6.10 Bypass CSRF Protection

[0pc0deFR]

Je continu dans la lancé des défauts de sécurité MyBB. Nous travaillons sur la version 1.6.10 qui est la dernière version actuellement.

La vulnérabilité a été testé sur le panel d'administration. La page http://server/MyBB/admin/index.php?actio...e0a39c46e5 permet de déconnecter l'utilisateur pour peu que my_post_key corresponde à my_post_key de l'utilisateur demandant la page (et donc l'utilisateur doit être connecté). A savoir que cette key ne change pas à chaque connexion (testé sur plusieurs machines et plusieurs comptes) et est unique à chaque utilisateur.

Admettons la key 527a58366ce545e1635be9e0a39c46e5 pour le compte admin1 et la key e8bfb94fa38932bc756601c6fae90708 pour admin2.

Si j'essaye de déconnecter l'utilisateur admin2 avec la key de admin1 MyBB plante. C'est là que c'est intéressant.

Avec du javascript et de l'AJAX exécuté sur le navigateur de l'administrateur ciblé (type CSRF), il est possible de faire un brute force pour trouver la key my_post_key.

Quel intérêt une fois la valeur my_post_key trouvé?
my_post_key est la valeur de sécurisation des formulaires MyBB sur le panel administrateur. L'anti-CSRF en somme. Il est donc possible de contourner la protection CSRF avec la valeur de my_post_key et donc d'expoiter une CSRF avec les techniques basiques d'exploitation.

En soit c'est très difficile d'exploitation car il faut énormément de ressources pour faire un brute force de ce type car ce n'est pas une petite chaîne qui est recherchée mais une chaîne de 32 caractères (un MD5) mais ça à le mérite d'être une vulnérabilité et surtout pour vos sites perso, faites attention à ça.

[Luxerails]

Brute-forcer 128 bits en ligne...
Je ne suis même pas sûr que, pour l'instant, quelqu'un ait déjà réussi à trouver une collision md5 avec le pigeonhole principle (calculer plus de 2^128 hashs)...

[notfound]

Brute-forcer 128 bits en ligne...
Je ne suis même pas sûr que, pour l'instant, quelqu'un ait déjà réussi à trouver une collision md5 avec le pigeonhole principle (calculer plus de 2^128 hashs)...

When in doubt. Use brute force.

[0pc0deFR]

La pour le coup ce n'est pas exploitable, c'est vrai (comme précisé sur le premier post) mais c'est le principe qui est intéressant. On pourrait imaginer la même vulnérabilité sur un site X ou Y avec une valeur de sécurisation de quelques caractères (par exemple 4, 5 ou 6) et là ça devient plus facilement exploitable.

[Luxerails]

Bof bof... je vois pas trop où est la faille, c'est tout à fait normal. Tu ne peux pas brute-forcer 128 bits, et encore moins en ligne. Et je doute qu'il existe des anti-csrf à 4 caractères, ça n'a aucun intérêt (ou alors c'est créé exprès pour le brute-force). Et puis dans tous les cas, le brute-force online, c'est chiant, et c'est super lent. C'est comme si je disais "olala, y'a une faille dans n-pn, si on brute-force le password d'un admin et ben on peut trouver son password peut-être, c'est super facile si le password fait 4 caractères"

A savoir que cette key ne change pas à chaque connexion (testé sur plusieurs machines et plusieurs comptes) et est unique à chaque utilisateur.

Ça c'est plus intéressant : comment est générée cette clé ?

[0pc0deFR]

Je suis d'accord avec toi sur le fait que ce n'est pas faisable en l'état mais c'est le concept qui est intéressant. Des anti-CSRF de quelques caractères ça doit exister mais en sois ce que je veux démontrer c'est que ce n'est pas une bonne idée de transmettre une clé de protection de cette manière alors qu'elle pourrait être traité directement dans le PHP sans la transmettre et la rendre modifiable par l'utilisateur.

Pour le principe de génération, je me suis dit la même chose mais je n'ai pas encore pris le temps de regarder ça. Je vais essayer de voir ça pendant ce WE.

[b0fh]

Et tu nous explique comment ta clef va protéger contre les CSRF, si on la "laisse dans PHP" et qu'on n'exige pas de l'utilisateur qu'il la transmette à chaque requête ?

[0pc0deFR]

Effectivement, vous avez tout à fait raison. b0fh, tu viens de me faire réfléchir pendant 10 bonne minutes car je pensais le défaut dans le fait que la clé soit transmise par une requête GET car modifiable via de l'AJAX mais au final c'est la même chose avec une requête POST. Dans tout les cas il est possible de bypass avec la technique exposé dans le premier post du thread, la seul vraie sécurité que je vois donc, c'est comme l'a évoqué Luxerails, la longueur de la clé qui rend le brute-force inefficace et le système de génération fiable. La je vous dis merci

[gruik]

de là à dire qu'on parle de rien depuis le début...

[kallimero]

Avec un peu d'ingénierie sociale, et pourquoi pas de clickjacking on peut réussir à obtenir ce jeton sans trop de problèmes.

Faisons l'hypothèse tout à fait farfelue que nous nous attaquons à un forum de sécurité informatique. En offrant, par exemple, à l'administrateur le lien d'un simulacre de PoC sur son browser, il peut se prendre au jeu et on peut alors l'amener à réaliser des actions qui mènent à l'obtention du jeton, et à la réalisation d'un exploit CSRF.

Puisque je n'ai pas grand chose à faire de mes journées, un exemple en vidéo ; http://www.dailymotion.com/video/x13qlkq...ample_tech

Bien sûr, ça reste une pseudo-vulnérabilité qui nécéssite pas mal d'interractions utilisateur, mais les développeurs auraient facilement pus l'éviter.

Ici le fonctionnement est très simple. Une iframe en opacity:0; avec, juste en dessous de l'endroit du logout, un faux lien.
Ainsi lorsqu'il copie l'adresse du lien il copie enfaite l'adresse du logout qui contient la post_key.
Ensuite, avec un champs texte qui possède le focus en continu, on récupère le lien quand la "victime" fait son ctrl+V.
Et on génère rapidement un formulaire d'ajout d'administrateur qu'on envoit aussitôt.

Très simple, très sale. Tout ce que j'aime.
Le code, pour les quelques clampins intéréssés ; http://pastie.org/pastes/8273633/text?ke...6hcmdn0maw
(vous comprendrez facilement que je suis faché avec javascript depuis quelques décénnies).
Le code est optimisé pour firefox 23.0.1, et fonctionne miraculeusement bien sous mon 15".