Catégories
conférences

OWASP AppSec EU – J1

Les vidéos des présentations seront disponibles sur la chaine Youtube de l’OWASP

50 shades of appsec (@troyhunt)

Le domaine de la sécurité applicative est très actif, et c’est du à la démocratisation du hacking, N’importe qui peut devenir un « hacker » grâce aux nombreux outils disponibles de nos jours. Cette démocratisation est accompagnée d’une montée de l’ « hacktivisme » dont le process consiste à trouver des vulnérabilités puis à trouver une revendication. Cette démocratisation criminalise des ados qui font des conneries sur un site « juste pour voir » et se retrouvent avec un casier pour quasiment rien. La vraie cybercriminalité est elle aussi facile dans le domaine de la sécurité applicative, entre les leak pastbin, et les chantages au DDoS ou au leak pour UN bitcoin. Heureusement un grand nombre de ces cybercriminels ne sont pas très fins et tombent grâce à leurs erreurs. C’est notamment le cas de CabinCr3w, arrêté grâce aux métadonnées récupérées sur une photo qu’il a pris avec son iPhone.

La question se pose alors « est-ce que nous facilitons le travail des criminels ? ». Entre les systèmes de ré-initialisation de mot de passe stupides, les questions secrètes, et les login/pass en dur dans le JavaScript, les applications web sont parfois très vulnérables (petit exemple avec une sitemap contenant les mdp des utilisateurs dans les liens collectés automatiquement pour la construire –‘). La programmation par « copier-coller » est un fléau pour la sécurité web, les développeurs ré-utilisant des recettes pourries contenant des vulnérabilités connues depuis plus de 15 ans…

Le problème vient peut-être de la façon dont nous formons les développeurs (un peu de lol sur l’éducation 😉 ). Le type de question posé sur la sécurité peut être très drôle, c’est parfois désespérant, et les questions posées par les « pro » de la sécurité lors d’un audit sont parfois tout aussi débiles que celle qu’on peut trouver sur le net. Et parfois quand on regarde les photos et les vidéos des reportages issues de TV5Monde, on ne s’étonne pas de leur compromission.

Le problème vient peut-être aussi de la façon dont les experts de la sécurité communiquent avec les médias et les réseaux sociaux. Pourquoi avoir des mots de passes longs ? ou bloquer le copier-coller d’un mot de passe ? les raisons invoquées sont parfois très débiles, et démontre l’incompréhension des raisons techniques derrière les mécanismes de sécurité mis en place. Et l’explication est encore plus foireuse en 140 caractères.

Ce qu’on a pu apprendre grâce aux leaks de Snowden, c’est une bonne crypto et une bonne sécurité bien implémentée pose problème à la NSA pour réaliser ses écoutes, et quand on lit que le David Cameron veut interdire le chiffrement des données, on peut se dire que la sécurité fonctionne plutôt bien si on s’en donne la peine. Mais les utilisateurs ont une fâcheuse tendance à réduire ou contourner les mécanismes de sécurité dans le monde physique (mots de passes sur post-its, etc…).

Là ou la sécurité applicative rencontre le monde physique c’est l’IoT (internet of things), avec cette fâcheuse tendance à connecter tous les trucs possibles et imaginables. Mais comme il s’agit de composants low-cost, à faible capacité de calcul, leur sécurité peut être discutable, surtout quand ils contiennent vos codes d’accès wifi. En plus le coté « patch-management » et mise à jour, n’est pas vraiment pensé en amont de ces produits. Imaginez une attaque sur des toilettes connectées lorsque votre chef va aux chiottes :].

Mac Hack Backup Attack (@internot_)

Récupération de mots de passe à partir de backups time-capsule d’Apple.  L’orateur a récupéré une time-capsule pour sa femme. au bool, la time capsule montre un ssid « apple shop », et à la connexion, la time capsule montre un identifiant « apple time capsule shop ». il n’est apparemment pas possible de récupérer le mot de passe d’une time capsule, mais on peut désactiver temporairement les mécanismes de sécurité pour pouvoir changer son mot de passe, et la config de la time-capsule. En cochant la case « remember my password in my keychain » il est possible de récupérer le mot de passe de la time-capsule depuis le porte-clef apple. Et du coup, on peut accéder à tout les backups stockés dans la time-capsule (game over?). Le « porte-clef » apple stocke à peu près tous les mots de passes qui bougent dans un mac, et est protégé par le mot de passe de l’utilisateur. Parfois, lorsqu’il y a un système de login automatique, le mot de passe de l’utilisateur est dans /etc/kcpassword avec un « chiffrement » aisément réversible. Comme il n’y a aucun contrôle d’accès sur les backups. à l’aide d’outils publics, on récupère ainsi tout le contenu des keychain du mac depuis le backup.

Ne jamais vendre une Time Capsule, et ne jamais utiliser l’Auto-Login !

Copy & Pest (Mario Heiderich)

Un vecteur XSS qui requiert une interaction utilisateur mais avec un logo ! Le scénario est simple, l’utilisateur rédige un mail dans un webmail, et copie un contenu d’un autre document dans l’e-mail. et lorsqu’on colle le text, du code JavaScript s’exécute !  Tous les éditeurs « rich text » sont exposés à ce vecteur d’attaque. Le presse-papier à évolué du stockage d’un simple texte au stockage d’objets complexes. Le processus de copier-coller est plutôt complexe, et on ne sait pas trop ce qui s’y passe… ClipView est un outil permettant de voir le contenu de presse-papier. Environ 30 conteneurs sont initialisés dans le presse-papier sous différents formats lorsqu’on fait copier dans le presse-papier. C’est l’application réceptionnant le « coller » qui choisi le conteneur adapté par rapport à ses capacités. Les documents open-office sont en fait des conteneurs .zip, contenant un fichier style.xml dans lesquelles on peut injecter des entités xml, et injecter du HTML.
Heureusement, les navigateurs ont des fonctions de sanitization pour nettoyer le HTML et éviter les attaques. Le JavaScript est filtré, mais dans les balises style du texte, il est possible d’injecter du SVG (encore une fois…).

Ce trick peut être adapté aux fichiers PDF. Ici, l’attaquant à seulement 32 caractères sous la main, et ne peut utiliser de parenthèses & cie. Du coup en utilisant le mode ‘vbs’. grâce à ECMAScript 6, on peut utiliser les backticks `  pour exécuter du JS sans parenthèses. Adobe crée un conteneur RTF dans le presse papier, mais pas de HTML, mais IE convertit automatiquement le RTF en HTML.

On peut faire la même chose à partir des formats office .doc & .docx. On peut aussi faire ça depuis XPS (le pdf foiré de microsoft… ) en créant une font malicieuse contenant des propriétés qui seront transformés en propriétés HTML dans la balise style

L’inverse est possible aussi, lors d’une copie du HTML vers un fichier excel. Du coup lorsqu’on colle du contenu HTML dans excel, les sécurités sautent et le code est exécuté. Flash permet de modifier le contenu du presse-papier sur un simple click. Et Flash peut être inclus dans des PDF, et du coup le code Flash s’exécute. Comme l’utilisateur pour son copier-coller click sur le PDF, le contenu du presse papier n’est pas celui attendu.

La contre-mesure principale consiste à utiliser ctrl+shift+V pour ne coller que le texte !

Services Workers & Security (@sirdarkcat)

Historiquement, Gears était fait pour permettre de créer une application web fonctionnelle lorsqu’elle se retrouvait offline. AppCache est un cache applicatif toujours en place, et permet aux applications web de théoriquement fonctionner offline, mais à une fâcheuse tendance à péter l’application. lesWorkers sont des threads en JavaScript avec son propre contexte d’exécution. les ServiceWorkers sont des web-services qui tournent sur des Workers JS et qui servent le contenu de l’AppCache pour s’assurer que l’application ne casse pas. Les Services Workers peuvent aussi intercepter les requêtes envoyés à un site comme un proxy, ce qui conduit à des scénarios d’attaques possibles via ces Service Workers. Du coup si un XSS peut installer un Service Worker, c’est la fin des haricots. ImportScripts et la fonction utiliser par le Service Worker, et ignore la same-origin policy. En plus ils peuvent désactiver les sécurités du site ciblé puisqu’ils sont en situation de Man in the Middle.

Les Service Workers peuvent aussi servir à implémenter des mécanismes de sécurité, comme des sandboxes, la mise en place d’headers de sécurité comme x-frame-options sur un ensemble de sites de façons simples etc… (demo ici ?).

Server-Side Browsing considered harmfull (@Agarri)

le Server Side Browsing consiste à fournir une URL à un service web ou un serveur, et le serveur essaye d’atteindre l’adresse en question. Quelques exemples issus de bug bounty. Les vecteurs de ces attaques sont par exemple les API pour développeurs comme par exemples les mécanismes de payement en ligne qui intègres des callbacks ou « webhooks » avec des fonctionnalités de débug qui affichent le résultat des requêtes.  Il y a aussi les fonctionnalités d’intégration des RSS, l’upload à partir d’une URL.Google Translate, ou Prezi peuvent être utilisé pour ça aussi. Les proxy qui transforment les liens http en https pour éviter les warning lorsqu’on surf sur un site sous SSL. L’hébergement de code distant comme par exemple du code JavaScript permet d’obtenir des scanneurs de ports hébergés.

Les handlers classiques utilisables dans ce cas sont par exemple file://  pour la récupération d’infos. S’il s’agit d’un serveur avec java on peut utiliser file:///proc/self/cwd/../config/ . D’autres handlers existent (SSRF cheat sheet) mais ne seront pas couverts pendant le talk. http:// et https:// sont toujours disponibles, et à partir de ça, on peut obtenir des bannières SSH pour du fingerprinting. On peut aussi taper dans des backends Redis. Les destinations possibles de ces URLs sont les adresses de loopback ou de multicast. Ce qui permet de bypasser les contrôles d’accès par IP qui ne tournent que sur 127.0.0.1 comme Solr, Redis, memcached, etc… Parfois sur les adresses locales, on peut trouver des proxy, et donc enchaîner la requête sur le loopback et une requête vers une autre adresse. Sur EC2 ou OpenStack, un serveur est en écoute sur http://192.254.169.254/ contenant des méta-data utiles comme les scripts d’intentiation d’une VM avec des clefs SSH & cie bien utiles dans un pentest. Sur AWS, il est possible de chopper les credential pour créer une VM dans le cloud du client ciblé.

Le réseau interne reste aussi une source de cibles intéressantes, et la plupart du temps, ces services ne sont pas durcis correctement, voir sont carrément dépassés et vulnérables. Bon après, si rien n’est dispo en local, vous pouvez toujours taper sur les IP publiques des services du client, qui parfois réagissent différemment parce-que vous êtes à l’intérieur de son réseau, contournant ainsi les blacklists mises en place niveau IP protégeant les services internes.

Les redirections peuvent servir à re-diriger le serveur faisant la requête vers diverses cibles. Ces redirections 302 fonctionnent sur pas mal de services et de librairies serveur permettant la génération de requêtes HTTP. Du coup en combinant ces redirections vous pouvez obtenir des boucles. HTTP supporte différents mécanismes dans les urls (voir ici pour les techniques d’obfuscation permettant de bypasser les blacklists d’urls ou d’IP). http://0.0.0.0/ pointe sur l’addresse de loopback. Si la blacklist est appliqué au travers d’une première résolution, et qu’ensuite le nom de domaine est passé au composant proxy, il suffit de maîtriser son serveur DNS pour que ça pointe sur l’ip interne qui vous intéresse.

Dark tales of a phisherman

Le phishing et la pêche, c’est un peu la même chose, on met en place des lignes, des hameçons (hooks), et on met en place des pièges « à la con » mais qui fonctionnent. Le phishing dans le pentest requiert pas mal de travail de configuration et donc de risques d’erreurs. L’automatisation des tâches répétitives est la clef de ces campagnes. PhishLulz est un mix de PhishingFrenzy + BeEF.  PhishLulz permet d’automatiser la création des templates HTML, la collecte des logins/pass, la création de certificats SSL, etc… AWS est très pratique et ne coûte pas cher, et en cas de blacklist de l’ip il suffit de rebooter le tout pour changer d’adresse.

XSS Horror Show (@garethheyes)

Les chemins relatifs et les feuilles de styles peuvent avoir des effets inattendus… Parfois dans un pentest, quand on manipule les urls, les feuilles de style disparaissent et on ne sait pas trop pourquoi le site est plongé dans les années 90… En fait si on utilise des urls relatives dans un site web, il est possible de modifier le chemin relatif de ces ressources et obtenir une XSS. En CSS un navigateur ignore le contenu foireux d’une feuille de style, du coup si vous contrôlez un contenu sur le serveur accessible par une url relative, vous pouvez y placer du CSS et obtenir une exécution de code JavaScript ( des exemples ici).

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *