SSTIC 2020 - J3
Finding vBulletin 0-days through poor man’s symbolic execution
vBulletin est un « forum » PHP payant qui à 20 ans. L’orateur nous montre les internals de vBulletin et comment il gère la génération de ses requêtes SQL. L’API propose plus de 1000 méthodes, et la combinatoire est énorme, du coup, pour vérifier si une API est vulnérable, il faut automatiser. L’orateur a fait une analyse statique avec propagation de teinte pour tenir à jour une liste des contrôles faits ou pas sur le paramètre (Une approche à la RIPS).
Face à une grosse combinatoire, l’approche automatique est franchement payante, mais l’émulation de fonction c’est pas évident. L’orateur attend que vBulletin ait patché les vulns avant de release le tool (on appréciera le responsible disclosure).
Sécurité des infrastructures basées sur Kubernetes
Kubernetes c’est un orchestrateur permettant de gérer une tartine de conteneurs type Docker. C’est un composant au cœur de l’approche infrastructure as code, et ça facilite la reproductibilité des déploiements.
L’API donne accès a plusieurs objets de l’infra k8s, des namespaces qui servent à l’isolation des « gros services », des pods qui représentent un environnement d’exécution aka conteneur, et des services qui permettent de rendre accessibles les applications niveau réseau. L’orateur nous explique en suite le workflow de fonctionnement de Kubernetes.
La sécurisation d’un cluster dépend de comment il a été déployé, si c’est du homemade ou du cloud. Si vous faites du homemade, gaffe a la sécurité de votre OS. Il faut aussi bien gérer les secrets, clefs privés, clefs d’API, etc…
Il faut bien entendu protéger l’accès réseau à l’etcd qui sert d’orchestrateur et s’assurer qu’il n’est pas accessible autrement que via l’API k8s. De même il faut restreindre l’accès a l’API uniquement aux pods qui en ont besoin.
Bien entendu si vous utilisez des composants Kubernetes additionnels, il va falloir adapter votre sécurisation aux bonnes pratiques de ces composants.
Process level network security monitoring and enforcement with eBPF
Pour empêcher les applications de prod de communiquer avec tout l’internet et les restreindre aux services nécessaires. Pour des applis classiques on va faire du Iptables, mais sous Kubernetes ou au niveau d’un conteneur c’est beaucoup plus compliqué. Souvent les moyens de filtrage manquent de granularité, c’est tout ou rien. Du coup l’orateur à travaillé sur une solution pour filtrer les paquets à la sortie des processus à l’aide d’eBPF. Cillium est une solution de filtrage qui fait ça niveau Pods, là ou l’approche de l’orateur se fait au niveau processus, ce qui est beaucoup plus fin. Cillium est très intrusif sur le fonctionnement du cluster qu’il faut ensuite le redémarrer.
Hacking Excel Online – How to exploit Calc
Exploitation de vulnérabilités sur Office Online. Souvent Office sert à atteindre des vulnérabilités locales à l’OS, et le dernier bug inhérent à Office date de 2015. Office Online, c’est un Win10 qui fait tourner IIS. Il faut distinguer la version cloud office online, et la version office on prem qui tourne chez vous. Du coup la question qui s’est posé dans les équipes Microsoft c’est QUID d’Office niveau sécurité. L’orateur est parti sur Excel de part son background. Excel à été fuzzé à mort depuis 20 ans, donc c’est pas évident d’y trouver des bugs. Et c’est pas les mitigations qui manquent dans Windows 10 pour empêcher les exploits de fonctionner. Comme Office n’embarque pas de moteur de script, ça limite la surface d’attaque. Par contre il y a un moteur de formules…
L’orateur plonge dans les internals des fonctions intéressantes pour un bug dans ce moteur de formule, et ça picote… (cf actes / prez / slides, toussa).
Scoop the Windows 10 Pool!
Une prez sur le Tas du kernel Windows 10. La compréhension d’un allocateur mémoire c’est assez clef pour l’écriture d’exploits. Les orateurs nous présentent donc le fonctionnement de l’allocateur Windows 10 (va falloir lire l’article, ouais faut vraiment lire l’article)…
Pour prouver l’exploitabilité d’une vuln avec l’allocateur Windows 10, les orateurs ont créé un driver vulnérable, le poc est dispo sur Github.
MI-LXC: Une plateforme pédagogique pour la sécurité réseau
Pour enseigner la sécurité informatique sur Internet, c’est bien d’avoir Internet… mais bon Internet c’est gros et on peut pas trop jouer avec, du coup l’orateur à conçu une Infrastructure as Code sous LXC qui reprend Internet avec des AS, une entreprise, un éditeur, une autorité de certification ACME type Let’s Encrypt.
Le framework permet de spécifier l’infra cible sans que ça soit trop verbeux.
L’orateur présente ensuite deux TPs type avec du Mitm BGP, et un scénario d’intrusion dans une entreprise. Tout ça est dispo sur Github. (j’aurais aimé avoir ça comme infra de TP comme étudiant)
Moon : un framework pour la gestion des autorisations
Sur OpenStack on fait du RBAC pour gérer les droits des utilisateurs. Moon offre une IHM pour gérer des politiques de sécurité. L’application est disponible sur le git d’opnfv.
WazaBee: attaque de réseaux Zigbee par détournement de puces Bluetooth Low Energy
Les environements IoT se partagent souvent les même bandes de fréquence, et les orateurs se sont posé la question d’utiliser un composant radio prévu pour un protocole pour basculer sur un autre et de se servir de l’IoT comme pivot. Soit le composant supporte nativement plusieurs protocoles, soit on force le composant mono-protocole à émettre un autre protocole. Par exemple, Le Packet into packet consiste à mettre une charge d’un protocole dans la payload d’un second.
Les orateurs nous rappellent le principe de la modulation numérique qui régit l’émission de signaux radio depuis un composant électronique. Le BLE est une variante du Bluetooth classique à faible consommation énergétique et dont la pile protocolaire est simple. Le Zigbee peut utiliser plusieurs bandes de fréquence différentes, et dispose de 15 canaux sur le 2,4ghz. Contrairement au BLE, les canaux sont espacés. L’orateur décrit le fonctionnement de la modulation employé pour transmettre un signal numérique dans Zigbee.
L’attaque consiste à envoyer des données en Bluetooth de sorte que la modulation génère une modulation équivalente aux paquets Zigbee. Les orateurs ont créé une table d’équivalence, et ont pris soin de choisir un canal ou il y a superposition entre le canal BLE et le canal Zigbee. Ils ont aussi désactivé le CRC qui sera forcément faut.
Les orateurs ont expérimenté avec deux chip BLE, en transmettant toutes leurs trames issues de leur table d’équivalence, et les ont reçues assez bien, sauf quand il y avait des canaux wifi en overlap. Les POC sont ici, et là.
Que faut-il attendre de DNS-over-HTTPS?
DoT consiste à faire du Dns over Tcp avec un port dédié, et du DNS encapsulé dans TLS. Le problème c’est que ça fait un port de plus à ouvrir sur le pare-feux. DoH consiste à faire du DNS over HTTP over TLS, du coup on repose sur un port passe-partout. Le problème, c’est que le navigateur vient faire des choix pour la résolution de noms qui contourne la politique du poste de l’utilisateur. On peut donc se poser la question de ce qui pourrait baver sur internet lorsqu’on requête des services internes par exemple.
Traditionnellement, lorsqu’on navigue sur des services internes, on interroge le DNS interne. Mais qu’arrive t’il lorsqu’on fait du DoH ? Dans le meilleur des cas les services sont injoignables, mais dans le pire cas un attaquant pourrait exploiter ces requêtes DNS sortantes. C’est l’objet des travaux des auteurs. Ils ont donc mis en place un banc de test avec des conteneurs docker et des VM Windows avec Chromium.
Dans la configuration du navigateur on peut spécifier des domaines exclus du DoH par GPO. Pour Firefox il y a un canari DNS use-application-dns.net si le DoH est utilisé par défaut. Il existe un certain nombre d’opérateurs dans le monde qui implémentent ce canari.
Les orateurs espèrent que les GUI en cas d’erreur de résolution deviendront plus claires, et proposent des serveurs DoH alternatifs.
Please Remember Me: Security Analysis of U2F Remember Me Implementations in The Wild
Le 2FA permet de se prémunir contre le vol de mot de passe en ajoutant un second protocole d’authentification. Elles ne sont pas toutes aussi robustes, et l’alliance FIDO a standardisé un format 2FA résistant appelé U2F.
L’orateur nous détaille le fonctionnement d’U2F, de l’enregistrement du token à l’authentification. Le protocole a fait l’objet d’analyses de sécurité publiés montrant qu’U2F était robuste. Les orateurs ont ajouté dans leur analyse les critères de résistance au shoulder-surfing, au keylogging, a l’accès physique au token, au leaks ou encore au phishing.
Du coup le modèle d’attaquant est balèze… on considère qu’il possède le mot de passe de l’utilisateur. Du coup ça résiste à tout sauf au vol du token (obvious) pour lequel il faudrait ajouter un facteur biométrique. U2F offre une option « remember-me » non documentée ni standardisée qui casse le modèle « standard ». Les « remember-me » sont basés sur des Cookies stockés dans le filesystem du navigateur. (enjoy legacy)
En pratique, les orateurs ont testé et si on transfert le cookie il n’y a pas de conséquence sur la navigation, le seul moyen d’invalider ces cookies « remember-me » consiste à désactiver/réactiver un token u2f pour le compte.
The exploits of a Google TAG analyst chasing in the wild
Depuis que Google a subit une grosse attaque de la part d’un état, Google fait passer la sécurité avant les autres priorités de l’entreprise. Du coup Google a créé l’équipe TAG, qui s’est mis à analyser des malwares avec les technos Google dont son fameux moteur de recherche. Ils ont absorbé plusieurs boites. En partant du principe que s’ils trouvait des attaques par point d’eau, ils trouveraient des 0-Day et couperaient ainsi l’herbe sous le pied des attaquants.
L’orateur a prid tous les exploits publics connus, il a passé ça dans une moulinette qui sort une Yara qu’ils posent en suite dans VirusTotal, et quand ça sonne, il tombe sur un e-mail qui contient un exploit IE use-after-free [cve-2014-1815]. En 2015 Hacking team se fait leaker et on y retrouve deux exploit 0-day qui serviront pour construire une règle de détection, rince & repeat. Et on trouve des samples antérieurs au leak qui ressemblent à un PoC de Vitaliy Toropov. L’autre sample est un exploit flash d’octobre 2014 utilisé a pown2own par vupen et patché en 2015. La collision de bugs est réelle, quand des chercheurs fouillent dans un domaine ils sont pas tout seuls à les trouver. CVE-2016-7855 match aussi cette règle, probablement parce qu’il s’agit du même framework d’exploitation.
Kaspersky à fait pareil sur un exploit Silverlight en 2016. A l’époque les exploits sont simples, il y avait déjà des collisions de bugs. Voyons maintenant ce qui a changé en 2019 ?
En 2019 ce n’est pas les mitigation qui manquent, ce qui fait que les exploits sont de plus en plus chers et plus durs à développer… Mais on en trouve toujours dans la nature. La taille des exploits elle fait x10 à cause du contournement des protections. CVE-2018-8653 est une vuln dans le moteur JavaScript plus complexe à exploiter. Ils utilisent la classe Enumerator() et il force le downgrade de IE11 a IE8 via des tags <meta> pour disposer de cette fonction. En recherchant avec l’aide de Google Project Zero les variantes possibles de l’exploit, ils ont découvert une autre 0-day qui a été patchée par Microsoft. En 2020 ils retrouvent le même exploit sans obfuscation de variables, même si ça ressemble a l’ancienne vuln, il teste sur IE dernière version et paf ça crash. En fait le use-after-free a changé d’emplacement, re-CVE car patch incomplet.
Avec le 0-day IE, ils ont trouvé un 0-day Firefox. Le trick wpad escape utilisé par les attaquants à re-servi pour sortir de la sandbox Firefox. Les exploits sont de plus en plus complexes, mais les tricks sont toujours les mêmes, et faut appeler le garbage collector. Si les victimes avait utilisé les dernières version d’IE et de Windows 10 ils n’aurait jamais pu être compromis. Le trick de downgrade IE8 se retrouve dans tous les exploits, et ça fait une belle règle de détection (ça sert aussi sur les XSS IE 😉 ).
Quand l’orateur regarde de près les exploit-kits, il retrouve beaucoup d’exploit publics n-days (exploit écrits après publication du patch). Une des cibles privilégiée c’est iOS. Du coup toujours la même technique de recherche pour découvrir des exploits similaires et parfois on tombe sur des codes qui était des 0-day lors de leur première apparition sur VT. Parfois les attaquants utilisent de l’offuscation, parfois ils oublient d’en mettre et du coup on peut facilement identifier les fonctions et identifier des portions identiques. Depuis que project Zero a publié sur l’attaquant, ce dernier à mis en place une nouvelle chaine d’exploits.
Les attaquants suivent de près les bugtrackers des devs des navigateurs et sur la base des fichiers de non-régression ils mettent au point leur exploit. Parfois Apple patch le bug sans CVE. Sur iOS 13 il y a beaucoup de mitigation. Il semblerait donc que les attaquants n’ont soit pas de bypass pour Pointer Authentication, soit ils ne veulent pas l’utiliser avec des vieilles vulns. Du coup avoir un device à jour et bien patché protège bien. Un auteur de jailbreak a trouvé des re-use de techniques d’exploitation iOS partagé dans une communauté privée de jailbreakers.
70% des bugs sont liés à des problèmes de gestion mémoire défaillante type use-after-free. Du coup Google propose de la re-écriture dans des langages memory safe comme Rust, Go, JavaScript (aaargh). Project Zero a pour objectif de tuer ces bugs critiques afin de couper l’herbe sous le pied des attaquants. Chrome travaille sur une proposition pour dégager l’accès au user-agent depuis JavaScript pour compliquer la tâche des exploit-kits. (je parie qu’ils vont se rediriger vers du fingerprinting…)
Tous ces sites hébergeant ces attaques sont poussés dans safebrowsing. La politique de fix force les éditeurs à patcher sous 7 jours ou à proposer aux utilisateurs un contournement. Chrome a décidé de réduire la fenêtre temporelle à disposition des attaquants pour écrire un exploit à partir d’un bug du bug-trackers, en releasant une mise à jour tout les 15 jours.