OWASP Montréal reçoit Mario Contestabile

Pour clore la saison 2015 – 2016, OWASP Montréal est fier d’accueillir au Midi Conférence un des architectes de renom du développement applicatif au Canada, monsieur Mario Contestabile. En tant qu’auteur de plusieurs centaines de tests d’intrusion, il connait tous les rouages de ce qu’est véritablement une application Web «sécurisée». Mais avez-vous déjà remarqué que les rapports de tests d’intrusion mentionnent rarement, voir jamais : «Votre site est très difficile à pirater. Félicitations !» ? Et qu’en est-il de ces rapports qui contiennent des dizaines de soi-disant vulnérabilités ? Est-ce que cela signifie d’emblée que l’application devrait être mise hors ligne ?

Lors de cette conférence, nous examinerons des rapports concrets (ambigus) de vulnérabilités et nous les analyserons afin de mieux comprendre si elles représentent une véritable menace, ou si elles ne servent qu’à «remplir» les rapports.

Avec son expertise en protection et en attaque d’applications Web, il abordera les points suivants : Comment pouvez-vous sélectionner des systèmes de façon à mieux exécuter des protections de sécurité ? Éviter certains pièges dans votre application Web qui rendent les attaques plus faciles et la protection plus difficile. De nos jours, que peuvent faire les développeurs à l’intérieur de systèmes communs, qui puisse me rendre la tâche plus ardue en tant que « hacker »? Pouvons-nous exiger de meilleurs rapports de la part des firmes de sécurité? À quoi devrions-nous nous attendre de la part d’un « pentesters »? Comment pouvons-nous savoir si le « pentester » a vérifié les failles de l’application et qu’il n’a pas simplement utilisé un scanneur? Et enfin, comment pouvons-nous aider les « ethical hackers » à obtenir un meilleur rendement lors d’un test d’intrusion? Il expliquera le sujet en détails, et ensemble, nous verrons de quelles façons les développeurs d’applications peuvent exploiter le savoir-faire des « pentesters », et comment nous pouvons faire en sorte qu’une application Web soit protégée. Biographie : Mario Contestabile est reconnu comme l’un des experts en sécurité les plus réputés au Canada. Son expertise, construire et protéger votre plateforme applicative. Ancien développeur C++ et Java, Mario partage ses nombreuses connaissances en « ethical hacking » et en développement de codes sécurisé.

Transcript

1. développeurs - vous pouvez arrêter les pirates
2. À propos de moi • Je vous ai probablement déjà «hacké» • Vous ne le savez possiblement pas • Méfiez-vous des solutions miracles • Tout ce que je vous montrerai aujourd’hui provient d’un apprentissage de plusieurs années de travail dans le domaine de la sécurité • … et d’innombrables experts, • … et de conférences, et • de certifications. • Je travaille chez => Company Logo
3. • Qui engagez-vous pour vos «pen tests»? • Voici quelques recommandations générales : – Détaillez vos besoins de cette façon • Réseaux internes • Réseaux externes • Applications • Forensics (fraude informatique) • Phishing (hameçonnage) • Wi-Fi
4. • Qui engagez-vous pour vos «pen tests»? – Sachez ce que vous voulez. – Ne donnez pas de mandats trop large : • Par exemple, demandez qu’on scanne 10 000 postes de travail et qu’on vous fournisse un rapport. Vous obtiendrez un énorme rapport duquel vous ne retirerez probablement rien de valable. • Demandez plutôt d’obtenir l’accès administrateur contrôleur domaine de ces postes de travail. • Un «pen test» n’est pas un audit;
5. • Qui engagez-vous pour vos «pen tests»? – Préparez-vous en conséquence – C’est la partie la plus importante, pour la raison suivante : • Les mandats sont typiquement basés sur la durée. Plus on passe de temps sur des éléments secondaires, moins de temps est véritablement consacré à effectuer le «pen test» en question.
6. • Qui engagez-vous pour vos «pen tests»? – Les choses à faire au préalable comprennent • «Whitelistez» les adresses IP au préalable • Assignez une ressource au projet qui aura les connaissances techniques • Créez les comptes à l’avance – Si vous me faites attendre pour que toutes ces choses soient faites, c’est vous qui en ferez les frais
7. • Qui engagez-vous pour vos «pen tests»? – Une fois les choses en cours • Attendez-vous à ce qu’il y ait du remous. • Vous avez quelqu’un qui surveille un SIEM tel Qradar? Avisez-le. • Quelqu’un reçoit des courriels d’alerte Incapsula? Avisez-le. • Nous avons tous entendu des histoires d’horreur – phishing tests (des tests d’hameçonnage) qui dérapent – des systèmes qui tombent en panne inopinément
8. • Pourquoi la segmentation? – Certaines firmes excellent dans un domaine mais sont complètement nulles dans un autre. – Afin d’acquérir une bonne expérience de réseau interne, les «pen testers» ont besoin d’être fortement exposés à des situations réelles. Un environnement Windows où ces connaissances sont indispensables • NTLM (Pass the Hash, mimikatz) • RDP (C&A for RDP MiTM) • VLAN hopping (Protocoles Cisco et outils tels Yersinia, voiphopper, Ettercap)
9. • Pourquoi la segmentation? – Informez-vous quand à la taille de l’équipe propre à ce domaine, • Combien êtes-vous dans l’équipe «forensics»? • Quel équipement spécialisé utilisez-vous pour le Wi-Fi? • Demandez à vos pairs. Domaine bancaire, jeux d’argent, jeux vidéos, ils ont tous des différences, autant dans les risques que dans les besoins.
10. • Compliquez-moi la tâche – Mon rôle est de vous informer des pires scénarios (à l’intérieur de mon mandat) avant que vous ne les découvriez par une source anonyme – Pourquoi cela me donne parfois l’impression que vous me tenez gentiment la main afin que je trouve des vulnérabilités et que je les exploite? Ne procédez pas de cette façon. – Voici quelques trucs.
11. • Compliquez-moi la tâche (devops) – Ne me laissez pas exécuter n’importe quoi n’importe où sans d’abord me faire travailler pour. – Par exemple : pourquoi puis-je faire ceci?
12. • Compliquez-moi la tâche (devops) – Résultats Acunetix avec RailsGoat [7267 requêtes; 30 minutes, 6,79 % complété] – « Point n Click Hacking »
13. • Compliquez-moi la tâche (devops) – Résultats Acunetix avec RailsGoat lorsque vous me rendez la tâche difficile [12625 requêtes; 10 minutes, 100 % complété] – Rien de plus facile
14. • Compliquez-moi la tâche (devops) – Règles Ngnix pour bloquer les requêtes avec mauvaises en-têtes HTTP if ($http_user_agent ~ (sqlmap|Nikto|Nmap|mysqloit)) { return 403; } – Cela ne m’arrêtera pas, mais… • Prendra de mon temps • Empêchera probablement plus d’attaques qu’on pourrait le penser – Sur Nginx, si vous êtes à l’aise avec les «regex» et vous avez beaucoup de temps à y consacrer, voir https://github.com/nbs-system/naxsi
15. • Compliquez-moi la tâche (devops) – Règles Apache pour bloquer les requêtes avec mauvaises en-têtes HTTP SetEnvIfNoCase User-Agent "^sqlmap" hacker_dude SetEnvIfNoCase User-Agent "^Nikto" hacker_dude SetEnvIfNoCase User-Agent "^Nmap" hacker_dude SetEnvIfNoCase User-Agent "^mysqloit" hacker_dude <Directory "/var/www"> Order Allow,Deny Allow from all Deny from env=hacker_dude </Directory> – Cela ne m’arrêtera pas, mais… • Prendra de mon temps • Empêchera probablement plus d’attaques qu’on pourrait le penser
16. • Facilitez-moi la tâche (hacker) – Pour l’autre moitié des gens dans cette salle, voici ce que vous devez faire avec Burp pour contourner ces règles. – Dans Proxy-Options, ajoutez la règle match/replace: Ou utilisez l’outil spécifiquement: • Sqlmap --random-agent • Nmap --script-args http.useragent="foo"
17. • Compliquez-moi la tâche (développeurs) – Nous avons vu qu’en développement de logiciels il est possible de faire de petites choses qui feront en sorte que je travaillerai plus fort, mais qu’en est-il des développeurs d’application? – Oui vous le pouvez! Voici comment:
18. • Compliquez-moi la tâche (développeurs) – Pourquoi ne pas vous arrêter, réfléchir à la surface d’attaque de votre application, réfléchir à l’utilisation normale de votre application, et si vous détectez des anomalies, réagissez! – Voici quelques mesures que vous pouvez prendre dès aujourd’hui, des mesures simples mais efficaces qui me compliqueront la tâche:
19. • Compliquez-moi la tâche (développeurs) [requête inattendue] – Est-ce que la requête se trouve dans une section seulement accessible après avoir visité une autre section? Si oui, ai-je visité cette autre section au préalable? Si je ne l’ai pas fait, déconnectez-moi! – Exemple concret : • Requête JSon pour une description de produit après s’être connecté, sans avoir regardé les produits. Quel utilisateur normal se connecte, démarre dans son browser le «network analyzer tool», et décide d’élaborer des commandes «curl» manuellement… plutôt que de cliquer avec la souris?
20. • Compliquez-moi la tâche (développeurs) [requête inattendue] – Réponse: personne. Si une requête est reçue sans avoir précédemment regardé le catalogue de produits, déconnectez-moi!
21. • Compliquez-moi la tâche (développeurs) [requête perdue] – Est-ce que la requête est dans une section qui n’est même pas indexée? – Exemple concret: • Rappelez-vous de notre capture d’écran précédente. Imaginez que le hacker ait été suffisamment rusé pour cacher l’empreinte Acunetix. Pouvez-vous quand même me rendre cela compliqué? Certainement. Voici comment:
22. • Compliquez-moi la tâche (développeurs) [requête perdue] – Si nous regardons de plus près les requêtes effectuées, ce sont les suivantes: • /xmlrpc.aspx • /xmlrpc.jsp • /xmlrpc.asp • /xmlrpc/soap.php • /xmlrpc/soapserver.php • Vous savez désormais assurément 2 choses 1. Cet utilisateur est un outil 2. Cet outil est Acunetix Déconnectez-moi!
23. • Compliquez-moi la tâche (développeurs) [Cookies] – Qu’est-ce que je viens d’envoyer au juste? – Un exemple. Votre application utilise de un à quatre cookies lors d’une utilisation normale. – Les «pen testers» adorent les cookies; ils en ajoutent, enlèvent ceux qui sont existants, les renomment, les dupliquent... – Vous êtes le développeur, vous savez que l’application requiert ces cookies, et sous quelle forme
24. • Compliquez-moi la tâche (développeurs) [Cookies] – Si le nombre de cookies < que ce qu’il devrait • Déconnectez-moi – Si le cookie est < que la longueur minimale prévue OU si le cookie est > que la longueur maximale prévue • Déconnectez-moi – Par exemple, si votre cookie est encodé en hexadécimal MD5, déconnectez-moi s’il n’est pas d’une longueur de 32!
25. • Compliquez-moi la tâche (développeurs) [Paramètres] – Ce que je préfère. Vous avez remarqué combien vous, l’expert de l’application, en savez plus sur ce qui est attendu ou ce qu’est un comportement «normal». – Personnellement, lorsque je vois ceci dans BURP j’ouvre grand les yeux.
26. • Compliquez-moi la tâche (développeurs)[Paramètres]
27. • Dans cet exemple, c’est assez évident, je vais enlever le CSRF token, le fait qu’il soit là ne signifie pas que vous avez ajouté la directive dans tout le code! <html> <body> <form action="http://ec2-52-26-68-217.us-west-2.compute.amazonaws.com:3000/schedule.json" method="POST"> <input type="hidden" name="utf8" value="â&#156;&#147;" /> <input type="hidden" name="authenticity&#95;token" value="KmnLsfsJnIm6jRRxE05jrmtMEbD8v&#47;63ex7peHAeJ&#43;nSb0Fpb6OXNaclLEJ8yEex4qNAUoelcLSek&#47;es WSU5xg&#61;&#61;" /> <input type="hidden" name="schedule&#91;event&#95;name&#93;" value="James" /> <input type="hidden" name="schedule&#91;event&#95;type&#93;" value="pto" /> <input type="hidden" name="schedule&#91;event&#95;desc&#93;" value="James&#32;will&#32;demonstrate&#32;awesomeness" /> <input type="hidden" name="date&#95;range1" value="06&#47;14&#47;2016&#32;&#45;&#32;06&#47;14&#47;2016" /> <input type="submit" value="Submit request" /> </form> </body> </html> • Pen testers, assurez-vous d’enlever les jetons CSRF, on ne sait jamais!
28. • Compliquez-moi la tâche (développeurs) [Paramètres] • Qu’est-ce qui rend les paramètes si attrayants? – Cela nous donne à nous les hackers une façon d’accéder au coeur de votre application. Nous savons que ces paramètres seront traités dans votre application, alors nous souhaitons que certains seront traités incorrectement. – Y en a-t-il des plus attrayants que d’autres? Oui!
29. • Compliquez-moi la tâche (développeurs) [Paramètres] • N’aidez pas les hackers en utilisant des noms communs (rappelez-vous notre temps est limité) • debug=false • localDriveName=/mnt/foo – Cookies avec un format évident IP:date:user
30. • Compliquez-moi la tâche (développeurs) – Pourquoi je vous recommande de me déconnecter? – Parce que c’est pénible! – Vous invalidez ainsi toutes mes sessions – Vous interrompez tous mes scans en cours qui utilisent la session – Je dois réauthentifier et possiblement changer certaines valeurs de cookie dans divers outils
31. • Compliquez-moi la tâche (développeurs) [choix d’architecture] – Authentification / Login – Conception interne – Vous cherchez le trouble – Choisissez judicieusement – Des firmes qui avaient opté pour OpenID ont fait marche arrière – Considérez les authentifications fédérées telles que Facebook Login, Google Sign-in, Microsoft, Twitter, etc. – Voici pourquoi:
32. • Compliquez-moi la tâche (développeurs) [choix d’architecture] – L’authentification est une zone de votre application qui sera longuement analysée par des «pen testers». La raison étant que les logins «custom» sont rarement un succès. Ils sont d’une difficulté élevée a implémenter correctement. – Voici quelques exemples de ce que vous devez vous assurer qui soit parfaitement implémenté si vous le faites vous-même: (bonne chance)
33. • Compliquez-moi la tâche (développeurs) [choix d’architecture] – User farming lors de la création d’un compte – User farming dans l’option mot de passe oublié – Session farming au login – Mot de passe faible lors de la création d’un compte – Mot de passe faible dans l’option mot de passe oublié – Nom d’usager commun lors de la création d’un compte
34. • Compliquez-moi la tâche (développeurs) [choix d’architecture] – Attack force brute sur un compte – Attack force brute sur plusieurs comptes – Login multiples d’endroits différents – Login depuis node Tor – Jeton de session faible – Jeton de session sans drapeaux de sécurité
35. • Compliquez-moi la tâche (développeurs) [choix d’architecture] – Durée de vie d’une session – Login pas chiffré (http) – Captchas – 2FA (Two factor authentification) – Messages d’erreur mauvais tel que («password incorrect», «username not found») – Recouvrement du mot de passe (qu’est-ce qu’il y a dans le courriel) – Mot de passe oublié (est-ce que vous envoyez un courriel?)
36. • Compliquez-moi la tâche (développeurs) [choix d’architecture] • Éviter toutes ces embûches n’est pas évident • Si vous pouvez vous permettre de laisser les meilleurs ingénieurs au monde s’en occuper, laissez-les faire • Si je regarde des rapports antérieurs, je vois chacun de ces problèmes, mais aucune vulnérabilité avec ces sites qui utilisaient un gestionnaire d’identification comme moyen d’authentification
37. • Compliquez-moi la tâche (développeurs) [choix d’architecture] – Au lieu de toutes ces tâches, vous pouvez simplement ajouter ceci à votre site: <meta name="google-signin-client_id" content="foobar.apps.googleusercontent.com"> <div class="g-signin2" data-onsuccess="onSignIn"></div> Pour une authentification avec Google Sign-in, et <a href="#" onclick="signOut();">Sign out</a> <script> function signOut() { var auth2 = gapi.auth2.getAuthInstance(); auth2.signOut().then(function () { console.log('User signed out.'); }); } </script> pour le logout. – Il y a FB, Twitter, Microsoft et GitHub comme fournisseurs d’identité.
38. • Si vous devez le faire vous-même, faites un checklist avec chaque item que j’ai énuméré; demandez-vous comment est-ce que mon application réagirait dans chacun des cas? • Si vous écrivez votre code pour que celui-ci utilise un captcha, nécessite un mot de passe sécuritaire, les sauvegarde de facon sécuritaire avec un salted hash (ex: LinkedIn), en utilisant toujours une connexion TLS, et utilise un reset de mot de passe sécuritaire (ex: Sarah Palin proof), n’affiche pas de messages d’erreurs trop détaillés, cela nécessitera tout de même un «pen test» régulier des systèmes.
39. • Assumons que c’est ce que nous voulons faire. On est une gang de sécurité, comment pouvons-nous nous assurer de l’aspect sécurité de notre application? 1. Ne laissez pas d’exception se propager. Faites des catch partout, les messages génériques sont souvent trop détaillés.
40. 2. Quand vous traitez les paramètres d’un formulaire Web, faites une validation avant de les traiter! Par exemple <input size=”2” maxlength=”3” name=”foo”> Si vous recevez: “OR 1=1—” Clairement ce n’est pas un usager normal. Il faudrait que le browser soit corrompu pour que ça arrive. Il y a 9 caractères! Déconnectez-moi!
41. • Et ceci <input type="number" name=“IQ"> Dans votre code, typiquement vous ferez ceci: If not digit(val): return null; Mais ça ne sera jamais le cas! Et si ça arrive, eh bien vous êtes sous attaque! Soyez proactif et protégez- vous. Par exemple: If not digit(val): log_out(); return null;
42. • Prenez cet exemple d’un formulaire avec: <input type="hidden" name="country" value=“Canada"> Et par magie vous recevez ceci foo=bar&country=Norway OR mario==mario Ça ne fait pas de sens. Déconnectez-moi. Votre application vous remerciera, sinon elle sera soumise à beaucoup de stress. Et soyez sans crainte, vous ne pouvez pas accidentellement recevoir une valeur autre que «Canada».
43. 3. Enregistrez tout ce qui est sérieux • Tel que, de la fonctionnalité active seulement lorsqu’un cookie est présent (admin=true). • Fonctionnalités reliées à l’authentification. Ajoutez du logging intelligent qui démontre clairement ce qui se passe. Par exemple, si vous pouvez voir «James» a changé le mot de passe d’«Alice», c’est clair. • Toutes tâches administratives. Par exemple, «James» a supprimé le compte «Alice».
44. 4. Sauvegardez vos données de façon à ce que quand je les volerai, elles seront illisibles. – J’ai extrait des numéros de cartes de crédit en clair, des numéros d’assurance sociale en clair, ainsi que des mots de passe. Non pas de sites «mom and pop» mais d’un magasin en ligne, d’une université et d’un CMS. Ceci ne devrait jamais arriver, le pire c’est que je partirais avec des données illisibles.
45. 5. Utilisez les fonctionnalités des browsers. – Il y en a et elles sont supportées de plus en plus. Laissez simplement votre application mettre en marche ces fonctionnalités de sécurité! Pourquoi ne pas le faire? – Assurez-vous que vos connexions sont chiffrées avec TLS • Strict-Transport-Security: – Fichier téléchargé et visible des autres usagers du site? • X-Content-Type-Options: nosniff – Vous ne voulez pas votre contenu sur d’autre sites? • X-Frame-Options: deny – Cross-site Scripting • X-XSS-Protection: mode=block
46. 6. Utilisez un fournisseur d’identité pour votre login – Laissez-les s’occuper du reset de mot de passe, de la politique de mot de passe, des attaques par force brute, des comptes volés et de la sauvegarde sécuritaire. – Économisez sur vos coûts de développement – Économisez sur la maintenance et aussi payez pour que vos «pen tests» se concentrent sur la vraie fonctionnalité de votre application
47. 7. Whitelist • Qu’est-ce qu’on devrait whitelister? On se fait dire que ceux-ci ne sont pas bons. • Pensez à toutes ces vulnérabilités parce que vous n’avez pas envisagé la possibilité que la valeur soit hors contexte. Par exemple: – export=filename.excel becomes export=/etc/pswd – uploadfile=foo.txt becomes uploadfile=/etc/pswd – downloadfile=image.jpg becomes downloadfile=/stc/paswd
48. • Validez selon le gros bon sens, et sauver des heures de frustration. – Si le fichier a télécharger n’a pas l’extension «jpg», enregistrez l’erreur et déconnectez-moi. – Si le fichier a télécharger est plus grand que 200k, enregistrez l’erreur et déconnectez-moi. – Et pourquoi ne pas verifier si le fichier a exporter est bel et bien un «.excel»? Et que celui-ci provient du répertoire «/export» avant de l’envoyer?
49. • Suivez ces sept règles et optimisez vos chances de survie sur le net 1. Attention aux exceptions 2. Vérifiez vos paramètres 3. Enregistrez les opérations intéressantes 4. Utilisez les browsers à leur plein potentiel 5. Le login est un monstre, pensez-y 6. Un «whitelist» peut prévenir des surprises quand on envoie des informations aux clients
50. • Choses pour lesquelles les «pen tests» ne sont pas super efficaces – Code review • C’est compliqué • Ça prend beaucoup de temps • C’est spécifique au langage – Firewall rules review • C’est très dépendant du réseau en place • Ça prend un gars réseau Cisco
51. • Applications très «Domain specific» dans le genre médical ou finances où des opérations ne devraient pas être permises mais elles le sont. – Un «pen tester» ne peut pas savoir que c’est un cas invalide pour ce domaine • Service Web complexe à la SOAP – Ça nécessite souvent des appareils ou des clients software, en plus de la doc complète, pour comprendre le protocole, et après l’exploiter