Joomla! Admin user creation (3.4.4 → 3.6.3)

On October 25th, Joomla! was updated to version 3.6.4 to address two vulnerabilities :

CVE-2016-8869 concerning registration with elevated privileges.
CVE-2016-8870 concerning account creation while registration is disabled.

In this post, we wanted to quickly discuss the vulnerability and its impact on vulnerable installations.

Upon patch-diffing the two versions, we noticed that an entire method had been removed from the components/com_users/controllers/user.php file : the register method from the UsersControllerUser class.

patchdiff

Normally, the register method used by Joomla! is the one from the UsersControllerRegistration class, in components/com_users/controllers/registration.php.

The deleted one is most likely a leftover from old patches, and doesn’t enforce a check on whether or not user registration is enabled (as opposed to the UsersControllerRegistration.register method).

Moreover, the $data array is supposed to be sanitized in the first line below, but the unsanitized value is then used in the register function at the end of this snippet, allowing us to submit custom data such as group and uid values.

novalidation

We can call this method by posting our registration values on the index.php?option=com_users&task=User.register URL.

POST /index.php?option=com_users&task=User.register HTTP/1.1
 Host: localhost
 Connection: keep-alive
 Accept-Encoding: gzip, deflate
 Accept: */*
 User-Agent: python-requests/2.11.1
 Cookie: 96b8cb33d84fb0aa459957bcad81cf90=go86e62fsve2a3jaqdmk6h6oq4
 Content-Length: 284
 Content-Type: application/x-www-form-urlencoded

user[password1]=exploit&user[username]=exploit&user[email2][email protected]&user[password2]=exploit&user[name]=exploit&user[email1][email protected]&user[groups][]=7&7c48521fa302676bada83d0e344011f2=1

The newly created user is then found on the server  :

accindb

For a valid request, we need to retrieve a CSRF Token and post it with a value = 1.

We are able to specify a custom user[id] value. If that id pre-exists in the database, the corresponding user will be overwritten during the registration.

Additionally, we can get high privileges by posting an array of user[groups][] values that will be assigned to the account. The default group id for Administrators is 7.

However, the only way to get the SuperAdmin group (8 by default) is to overwrite a pre-existing SuperAdmin user by specifying his user id.

Note that if user registration is disabled, the new/overwritten user will be blocked from logging in resulting in a denial of service for the SuperAdmin account.

In order to find and compromise a SuperAdmin account, it is possible to bruteforce all user ids and try to create a user with all possible groups. This will ensure that only the existing SuperAdmin accounts are overwritten (only the SuperAdmin ids can be overwritten to have SuperAdmin rights).

To create an admin account when the Administrator group id isn’t 7, it is possible to assign all the group ids from 1-99 (but leave the SuperAdmin group id out).

Download the PoC

CybSec16

La Cybsec16 est maintenant terminée et toute l’équipe SCRT présente a de nouveau passé un bon moment en compagnie de différents acteurs du monde de la sécurité en suisse romande (et un peu au delà). Une excellente organisation, des conférences intéressantes et diversifiées ainsi que les divers events “networking” ont largement contribué au succès de l’événement.

Comme plusieurs personnes sont venues me demander les slides de ma présentation, les voici:

https://download.scrt.ch/cybsec16/chlam2308161-1_cybsec_swisscom.pdf

En extra, les slides de ma rump session préparée à la dernière seconde:

https://download.scrt.ch/cybsec16/chlam0311161-1_cybsec_rump.pdf

Merci aux organisateurs et à l’année prochaine!

recon 2016

Première fois à recon et, oh waww! Assez différente des autres conférences, recon (dont le site web est recon.cx et non recon.com) est fortement orientée sur le Reverse Engineering et l’exploitation, que ce soit hardware ou software.

Étalée sur 3 jours avec une seule track, la conférence est pleine de talks à la fois intéressants et hallucinants, que nous tentons donc de résumer dans ce long post!

Hardware-Assisted Rootkits and Instrumentation: ARM Edition

Cette première présentation introduit le PMU (Performance Monitoring Unit), une extension CPU présente sur de nombreux systèmes ARM permettant d’obtenir des informations du système en temps réel. En fixant un compteur de -1 sur une instruction il est possible de recevoir une ISR (Interrupt Service Request), et ainsi d’accéder à une capture des registres au moment de l’instruction.. ou presque, puisqu’un délai appellé “skid” peut survenir entre l’instruction et l’interruption associée, auquel cas il est nécessaire de s’adapter par différents mécanismes.
Il est alors possible d’utiliser les propriétés du PMU afin de hooker des instructions tel que SVC sur ARM afin de surveiller les syscalls effectués sans patcher directement l’Exception Vector Table (EVT), qui est la technique classique intrusive, susceptible d’être détectée par des outils de sécurité.
2 exemples de monitoring des syscalls via le PMU sont alors présentées:

  • rootkit classique sur Android qui cache des fichiers / processus en hookant getdents, et une autre démonstration sur read()
  • détection/prévention d’attaque ROP, de façon similaire à la détection de stack pivot EMET sur Windows en monitorant l’état de la stack lors de requête mprotect (démonstration contre l’exploit Stagefright). Évidemment c’est ici une mesure basique loin de vraiment bloquer le ROP, mais une démonstration intéressante

Black box reverse engineering for unknown/custom instruction sets

L’auteur a présenté “deux” techniques:

  • On triche car l’architecture n’est en réalité pas inconnue et il existe de la documentation (datasheets, press release, etc.)
  • Il n’y a pas de documentation et il faut donc statistiquement analyser les données.

Bien entendu, la présentation s’est focalisée sur la deuxième partie. On peut en général visualiser les interrupt table ou les vector table, et a grand coup d’analyses statistiques, il est possible de déterminer quelle instruction est le call et en déduire laquelle est le ret. Les instructions push/pop apparaissent aussi avant les call/ret et des comparaisons sont généralement utilisées juste avant les jump. En procédant ainsi il est possible de commencer à écrire un désassembleur pour l’architecture et déduire d’autres instructions.

Une partie dynamique consiste alors à capturer les états, et si l’instruction mov est connue, déduire ce que font les autres instructions basé sur ces états via un “oracle“.

Visiting The Bear Den

Les analystes de ESET décrivent ici leur suivi des activités d’un groupe d’attaquants connu sous plusieurs noms dont APT28, Fancy Bear, sofacy… qui est connu pour avoir ciblé des embassades et ministères dans plus de 40 pays ainsi que l’OTAN. Ces derniers commencent leur attaque par du spear phishing, et utilisent plusieurs 0days (flash, windows, office) afin d’exécuter du code arbitraire, élever les privilèges et établir une communication chiffrée avec des serveurs de C&C (malware Sednit). L’exploit kit – SEDKIT – se compose de plusieurs composants dont un dropper en delphi, un bootkit, un rootkit, un outil de pivot… l’éventail d’armes attendu pour une APT.

Un aspect intéressant de l’analyse est la présence de quelques fails découverts tel que l’oubli de configurer bitly en mode privé permettant ainsi de découvrir les URLs, le code C++ commenté du composant XAGENT laissé en ligne, ou encore du code et messages de debug laissés dans les exploits (non obfusqués).

Shooting the OS X El Capitan Kernel Like a Sniper

La team Keen (aka Team Sniper à pwn2own 2016) introduit tout d’abord les mitigations présentes dans le dernier kernel OS X: les classiques kASLR, DEP, SMEP et SMAP (qui est supporté par le hardware des derniers mac). La structure vm_map_copy – utilisée pour garder une copie de certaines données, et cible privilégiée des exploits kernel pour obtenir un arbitrary read – a par ailleurs été modifiée: le pointeur kdata a été retiré, puis une vérification a été ajoutée sur le champ size qui se faisait alors utiliser afin de contourner la première mitigation. Ces dernières rendent l’exploitation bien plus complexe malgré la présence d’un TOCTOU possible sur la vérification du champ size.

Leur observation est que la kslide fixée pour l’ASLR du kernel 64-bit est relativement faible, avec une couverture d’environ 512MB. Il est donc possible de faire du Heap Spraying afin d’obtenir de façon fiable des données contrôlées à une adresse fixe, dont des adresses kalloc‘ed et une ropchain kernel permettant de contourner SMAP/SMEP.

Ils démontrent ensuite cette technique sur leur exploit pwn2own: un bug permettant un write-what-where restreint de 8 floats dans un range de [-0xFFFF:0xFFFF]. Afin de l’exploiter ils sprayent la mémoire en mettant un tag (0x41414141) à un endroit précis, itèrent sur tous leurs objets jusqu’a retrouver ce tag, puis avancent octet par octet jusqu’à obtenir une adresse de vtable, permettant ainsi de retrouver l’adresse de base du kernel. Ils peuvent alors ensuite remplir à nouveau leurs objets avec une ropchain et finir par réécrire la vtable afin de pivoter dans la ropchain.

JavaJournal

La plupart des reversers sont réticents à lire du code Java. Bien que le bytecode se décompile facilement, reverser du code Java obfusqué dans lequel toutes les classes, méthodes et variables sont renomées en variantes de oO0o0O() s’avère vite pénible.
JavaJournal s’intéresse alors plutôt à la création de traces Java pour extraire les informations au runtime (tel que des chaînes de caractères déchiffrées), en tracant un processus Java avec le Java Debug Wire Protocol. L’application et le framework pyspresso sous-jacent sont codés en python et disponible sur github.

The Remote Metamorphic Engine

L’objectif du RME est d’obfusquer du code afin d’empêcher l’analyse par un reverser ou par une intelligence artificielle d’AV avec machine learning. Le concept (simplifié) est d’avoir une zone “trusted” à distance, et une zone “untrusted” en local qui exécute du code polymorphe/métamorphe en utilisant un challenge envoyé par la zone trusted . Le code est généré de sorte à ce qu’il faille exécuter le challenge pour y répondre, et de nombreuses mesures de détection de modification de la mémoire, détection d’émulation / debug, et d’obfuscation sont ajoutées pour complexifier le tout.

La question qui persiste toutefois est l’intérêt pratique de toute cette complexité puisqu’un analyste pourrait toujours analyser les syscalls effectués sans être détecté; tout le reste des opérations pourrait alors s’effectuer de manière beaucoup plus simple directement à distance dans la zone trusted

BBS-Era Exploitation for Fun and Anachronism

Cette présentation revient à l’ère du modem, avant l’apparition d’Internet, en gardant les connaissances d’exploitation modernes. Les BBS – Bulletin Board System – n’étaient évidemment pas sujets aux protections actuelles telles que DEP, ASLR, /GS, SafeSEH ou encore CFI… un fuzzing simpliste est suffisant pour découvrir des vulnérabilités, et l’exploitation s’avère donc très simple.

Ils ont terminé par une démonstration d’exploitation de RIPTerm.exe dont le payload lance le jeu Doom.

Dangerous Optimizations and the Loss of Causality

Les compilateurs optimisent le plus possible le code compilé, en enlevant typiquement le code jugé inutile ou inatteignable, sans forcément retourner de warnings à la compilation. Un exemple serait de tenter de détecter les integer overflows avec un code tel que if (ptr + len < ptr || ptr + len > max_ptr), que le compilateur pourrait optimiser en if (ptr + len > max_ptr) si len est unsigned, rendant ainsi le code vulnérable.

La recommandation est alors d’éviter les comportements indéfinis (ex: if (len > max_ptr - ptr)) et d’ajouter l’option -Wstrict-overflow=N à la compilation pour mieux détecter ces comportements.

Breaking Band

Cette recherche a été motivée par le lancement de Mobile PWN2OWN en 2012 avec un prix de départ de 100’000 $ pour un exploit dans un baseband. Pour rappel, le baseband est un système embarqué dans les téléphones mobiles et permet la communication sur les réseaux mobiles. Personne n’avait gagné ce prix jusqu’en 2015, ou l’équipe de Comsecuris a finalement exploité un baseband de Samsung Galaxy S6 pour la modique somme de 150’000 $.

Le baseband du S6 edge utilise le processeur cellulaire “Shannon”, à priori développé par Samsung. Il s’occupe de toute la couche mobile, 2G-4G, la carte SIM, la communication avec le système, etc. L’architecture est un ARM Cortex-R7. Afin de débuter l’analyse, les chercheurs ont d’abord tenté de reverser le blob binaire contenu dans les mise à jour de firmware Samsung. Ce dernier était composé d’un code de démarrage (bootstrap) et d’un binaire de 38MB, ayant une forte entropie. Ils n’ont pas réussi à le déchiffrer de manière statique.

Ils ont ensuite découvert qu’il était possible de générer des ramdump du CP (cellular processor) via la commande cbd (root) ou encore depuis le téléphone en utilisant le code *#9090# (spécifique à samsung) et en forçant le dump. Cela a permit de récupérer le binaire de 38M depuis le dump de 130MB en clair. Afin de le reverser plus facilement, ils ont ensuite identifié les fonctions au moyens de strings de debug, et les chemins des nom de fichiers. Ils ont ainsi pu générer ~20’000 functions nommées et il a fallu ensuite reverser les tâches kernel et la gestion de la mémoire.

Ils ont ensuite cherché des moyens de débugger les crash, et ont trouvé que les commandes AT permettent de lire ou d’écrire dans la mémoire (entre autre), permettant ainsi de connaître l’état de la pile au moment de crash. Pour rechercher des failles dans le baseband, ils ont identifié les fonctions gérant les messages dans la couche réseau L3 et ont pu retrouver le handler de messages 3G.

Un bug a été rapidement trouvé dans la gestion de message “PROGRESS” ou l’élément envoyé spécifie sa valeur et sa longueur, permettant d’effectuer un stack buffer overflow classique. Leur poc démontrait la prise de contrôle en redirigeant les appels reçu par la victime suite à un SMS reçu. Ils ont terminé leur présentation avec quelques pistes possibles pour escalader d’une compromission de baseband vers l’OS du téléphone.

Process Failure Modes

Alors que relativement simple à effectuer sur les systèmes UNIX, la création sécurisée de nouveaux processus sur Windows peut s’avérer complexe et peut être abusée à des fins d’élévation de privilèges.

Typiquement des problèmes liés à l’impersonation de l’utilisateur peuvent surgir lors de la création par un service privilégié (Task Scheduler, UAC, …); plusieurs exemples d’anciens bugs découverts dans Windows sont ainsi présentés, tel que l’utilisation du jeton d’accès (token) du service plutôt que celui de l’utilisateur, l’absence de token par l’utilisation de CreateProcess – qui lorsque lancée en contexte d’impersonation d’utilisateur laisse à l’utilisateur la possibilité de définir son propre handler d’exécutable afin de lancer une autre commande (avec les privilèges du service) que celle hardcodée dans l’application, la création d’un processus en Session 0 (utilisée pour les services) avec un token anonyme – ce qui peut avoir plusieurs conséquences tel que d’ouvrir la porte à d’autres attaques comme que le squatting de nom d’objet.

Le dernier exploit présenté est un bug de reference cycle provoqué par l’impersonation d’un LowBoxToken (AppContainer). Les objets du kernel restent présents tant que leur reference count n’atteint pas zéro. Puisque le bug maintient le reference count et permet donc de conserver un objet de processus malgré qu’il soit terminé. L’exploit “raising the dead” parvient alors à en abuser pour effectuer un Session ID Use-After-Free, nécessitant de se déconnecter et attendre qu’un administrateur se connecte et réutilise l’ID de session.

Quelques tricks pouvant induire en erreur les équipes de réponse à incident sont ensuite présentés, tel que la suppression d’un exécutable en cours d’exécution, l’exécution directe de DLL en processus, ou encore confondre WMI et Process Explorer afin qu’ils voient le chemin d’un autre exécutable.

How Do I Crack Satellite and Cable Pay TV?

Probablement la présentation la plus impressionnante techniquement. Chris Gerlinsky s’est attaqué au protocole Digicipher 2 utilisé dans de nombreuses set-top-boxes aux USA.

Il s’est focalisé sur le chiffrement utilisé pour le flux vidéo, et surtout comment le casser. Ayant identifié le chip responsable du déchiffrement en hardware sur un boîtier, il a entrepris de mapper les pins afin de trouver lesquelles pouvaient être reliées à quoi sur le PCB. Il a ainsi pu identifier qu’une batterie alimentait le chip, donc que les clés étaient probablement stockées en RAM et paramétrées par le constructeur en usine.

Chris a alors décidé de décaper le chip à l’acide couche par couche, et de l’observer au microscope électronique. Ceci a permis d’extraire visuellement la ROM bit par bit (!) et reconstituer le firmware exécuté sur le chip. Le CPU a été identifié comme un Motorola 6502.

Il a ensuite tenté de glitcher ce chip pour essayer d’obtenir une exécution de code en redirigeant le flux d’exécution sur la pile, permettant à terme de lire la mémoire et d’extraire les clés de chiffrement. En envoyant son payload via le bus SPI et en glitchant l’alimentation du chip, il a pu exécuter son shellcode, consistant en une boucle infinie de réception de shellcode sur le bus SPI. Le dump optique de la ROM a alors pu être comparé à celle lue via le shellcode. La comparaison bit à bit a montré un taux d’erreur de seulement 0.04%!

Le chip en test ayant été dessoudé du PCB, la RAM est donc vide. Il a par la suite ponté les pins d’un autre chip sur une batterie externe afin de maintenir les données en RAM avant de le dessouder à son tour. L’implémentation DES a alors été analysée car les résultats démontraient un algorithme non standard. Certains bits étaient en effet XORés lors de la lecture des données chiffrées avant le déchiffrement.

Il a finalement implémenté le tout en software et visualisé la mire d’attente d’un programme en pay per view. La présentation se conclut par “This was somewhat useless as there is nothing worth watching on TV

Monitoring & controlling kernel-mode events by HyperPlatform

HyperPlatform est un hyperviseur qui se veut simple à étendre et rapide d’exécution (contrairement à Boschs par exemple), tout en supportant les versions modernes de Windows (7-10 x86/x64). Le code est open-source ici.

L’hyperviseur est basé sur Intel-VT et hook les événements VM-exit, fournissant ainsi le contexte d’exécution et l’accès à la mémoire avec EPT. Cela permet alors de créer une API rapide et invisible du point de vue de l’OS. Le but original était d’analyser la protection patchguard du kernel Windows, mais les possibilités d’utilisation sont nombreuses. Une démonstration de EopMon basé sur HyperPlatform montre alors la détection et prévention d’une attaque de vol de jeton d’accès à des fins d’élevation de privilèges.

More Flash, More Fun!

Flash, bien que supposé être en voie de disparition, reste la cible privilégiée des attaques sur les navigateurs*. Sa surface d’attaque se décompose en 3 composants:

  1. ActionScript 2 (AS2): ensemble d’APIs ancien et réduit ayant de nombreux bugs mais dont l’exploitabilité peut s’avérer complexe
  2. ActionScript 3 (AS3): plus récent, moins de bugs mais exploitation plus simple
  3. “anticorpus”: les fonctionnalités présentes en dehors des langages de script: parseurs MP4, décompression…

En plus d’être affecté par les bugs tels que Heap Overflow ou Use-After-Free, Flash est notoirement susceptible aux bugs de Type Confusion, qui surgissent lorsqu’un type est casté en un autre “mauvais” type invalide avant utilisation, permettant alors d’écrire des valeurs arbitraires qui se retrouvent utilisées en pointeur par l’autre type.

Afin de complexifier l’exploitation et éviter les techniques classiques tel qu’écraser le champ size dans un Vector adjacent afin d’obtenir un arbitrary read/write, plusieurs mitigations ont été introduites, tel que l’isolation des classes utilisées de façon récurrentes dans les exploits dans un heap différent et l’application de checksums sur les structures sensibles. Évidemment ces derniers ne suffisent pas à bloquer toutes les attaques, ce qui est démontré en décrivant un exploit dans le reste de la présentation.

A Monitor Darkly: Reversing and Exploiting Ubiquitous On-Screen-Display Controllers in Modern Monitors

La journée s’est terminée par une présentation assez drôle, de par les slides mais aussi de la mise en scène faite par cette équipe de chercheur qui ont remarqué par hasard qu’un nouvel écran s’affichait en tant que device DDC. Après pas mal de recherche, ils se sont lancés dans le reversing du firmware et de l’OSD de leur écran, afin de pouvoir afficher n’importe quoi.

Plusieurs exemples ont été présentés avec une licorne apparaissant sur l’écran, ou encore l’affichage d’un cadenas vert dans firefox lors de l’accès à 4chan.

Sol[IDA]rity

Sol[IDA]rity est un nouveau plugin alternatif pour effectuer du Reverse Engineering collaboratif dans IDA. Plusieurs projets s’y attèlent déjà, mais ces derniers sont soit difficiles à utiliser, soit nécessitent l’utilisation de services externes.

Ce plugin permet de créer un projet (un par binaire), et de partager les modifications effectuées avec certains utilisateurs choisis: structures, noms/types de fonctions/variables, contenu décompilé par hex-rays, etc. Le tout en temps réel, avec la possibilité de se resynchroniser (replay des modifications) lorsqu’on se reconnecte au serveur.

Sol[IDA]rity est implémenté tout en python et hook de nombreux composants Qt afin de customiser IDA. Le code du client et du serveur devraient être open-sourcé, et on ne peut être qu’impatient de tenter de l’utiliser!

Des démonstrations sont disponibles sur https://solidarity.re/

Keystone: the last missing framework of Reverse Engineering

Après avoir publié les frameworks Capstone (désassembleur) et Unicorn Engine (émulateur CPU), le seul composant manquant à l’auteur était un assembleur: Keystone. L’objectif de ce dernier est d’exposer un framework simple d’utilisation et de le maintenir à jour avec les instructions ajoutées par les derniers CPUs, sans faire le choix simple mais lent d’utiliser masm ou binutils et de parser l’output.

De même que les 2 autres frameworks du même auteur, Keystone est multi-architecture et multi-plateforme, dispose d’une API C/C++ et de bindings pour python et quelques autres langages hipster. Keystone est implémenté au dessus de LLVM, ce qui lui fournit un très bon support de par l’implication de plusieurs vendeurs CPU dans le projet.

When Governments Attack

L’EFF (Electronic Frontier Foundation) agit sur plusieurs sujets tel que défendre les droits digitaux aux tribunaux, publier des articles sur la loi & la confidentialité, ou développer des projets tel que le récent Let’s Encrypt. Dans cette présentation plusieurs scénarios d’attaque effectués par des gouvernements contre des journalistes et activistes sont décrits, et révèlent que les attaques n’ont pas nécessairement besoin d’être sophistiquées pour marcher: des bloggeurs vietnamiens étaient ciblés par des fichiers Office malicieux, l’Éthiopie en utilisant des techniques similaires avait installé l’outil de surveillance FinFisher sur l’ordinateur d’un citoyen américain, ou encore des appels téléphoniques de Social Engineering ont été tentés sur des personnes travaillant en relation avec des activistes iraniens.

Des domaines qui n’appartenaient plus à l’EFF tel que electronicfrontierfoundation.org ont été utilisés dans des attaques plus sophistiquées tel que Pawn Storm (Russie?), qui de leur expérience inclut l’utilisation conjointe de spear phishing et de 0days Java (Désactivation du click to play + vulnérabilité de désérialization d’objet) pour finallement déployer le malware Sednit.

Reverse Engineering ISC controllers

Après avoir vu le cours Coursera “Computer Architecture”, l’auteur a décidé d’acquérir une carte FPGA Xilinx afin de développer son propre processeur. Par la suite, il s’est rendu compte qu’il n’était pas possible de le faire depuis Linux. Il s’est donc concentré sur le reversing des outils de Xilinx afin de développer une librairie opensource permettant de communiquer avec n’importe quelle board FPGA.

L’auteur a d’abord analysé le traffic USB du controlleur Xilinx, dumpé son firmware et reversé le protocole utilisé par ce controlleur pour communiquer en JTAG vers les boards. Certains des outils développé sont publiés sur github :

https://github.com/diamondman

Abusing the NT Kernel Shim Engine

Le Kernel Shim Engine (KSE) est un composant non documenté du kernel Windows permettant d’intercepter divers appels effectués par les drivers. La structure utilisée par ces derniers (fonctions Kse du kernel) est obtenue par Reverse Engineering due à l’absence de symboles.
Le KSE permet de poser des Device Shims et Driver Shims. Par défaut Windows enregistre et utilise plusieurs shims, dont certains built-ins: KmWin7VersionLie (falsifie la version de Windows perçue par le driver), KmWin8VersionLie, KmWin81VersionLie, SkipDriverUnload (curieux..), DriverScope… La setup du KSE est contrôlé par des clés de registre et la Shim Database (SDB). Dans un premier temps l’IAT est hookée, puis les callbacks et gestionnaires d’IRPs (I/O Request Packets).
Le KSE permet donc d’intercepter proprement de nombreux appels intéressants dans le kernel, et semble donc être une bonne cible pour les malwares (ou solutions anti-malware).
La fin de la présentation introduit DriverMon: un outil graphique de monitoring de l’activité des drivers, qui devrait être ajouté à cette URL dans un futur proche.

Movfuscator-Be-Gone

L’instruction mov a été prouvée Turing-complete il y a quelques années. L’année dernière un obfuscateur nommé M/o/Vfuscator a été publié, qui compile un programme en instructions mov seulement, anéantissant alors le CFG et rendant le code beaucoup plus dur à reverser. Cette présentation introduit le Demovfuscator, qui rétabli le CFG (testé sur des épreuves de CTF) en utilisant une combinaison de static taint analysis et le solveur SMT z3.

.NET serialiception

Introduction

After discovering a weird base64 encoded format during pentest I wanted to find out what was that format and I met BinaryFormatter.

The BinaryFormatter format is internally used in a bunch of functions or can be used directly to materialize .NET objects.

The binary format is well documented here.

To be able to serialize and unserialize .NET objects, they must extend the ISerializable class.

As other serialization formats, the unserialized object is often casted to a specific one triggering some error if it doesn’t fit.

This research focus on the one that implements some specific deserialization constructors which are executed regardless of the expected casting.

James Forshaw already did a lot of work on this subject (https://media.blackhat.com/bh-us-12/Briefings/Forshaw/BH_US_12_Forshaw_Are_You_My_Type_WP.pdf) but firstly I wanted an easy way to tamper this BinaryFormatter format and then implement some POC everybody could use during penetration testing.

My scenario is to try to exploit this BinaryFormatter serialization from a web application. As I said, I saw it directly in POST and Cookies data during a pentest but another interesting vector is the ViewState that could pass BinaryFormatter format with the Token_BinarySerialized (even if I’m late on the subject http://fr.slideshare.net/ASF-WS/asfws-2014-slides-why-net-needs-macs-and-other-serialization-talesv20 as it’s rare to find one without a HMAC).

Firstly I wrote a JSON <-> BinaryFormatter converter so it’s easy to extract readable information from a BinaryFormatter stream, edit it in JSON and send back the modified version.

I quickly did the same with ViewState so I could tamper a non hmaced ViewState and insert my crafted BinaryFormatter to it.

Then I just have to find the interesting class.

ISerializable

Analysing most of the native ISerializable extended class, I noticed every actions an attacker could do by tampering a BinaryFormatter stream (I tried to be comprehensive).

Here is a list of quite interesting things we can do during deserialization :

Already known

Use examples/TempFileCollection_arbitrary_delete_or_smb_connect.json
ObjectId 8 is a BinaryObjectString which contains the filepath you want to delete (if you use a UNC path it will connect to it and leak hash)

Useless at the first view

Check examples/HashMembershipCondition_arbitrary_empty_ctor_call.json
ObjectId 4 contains a BinaryObjectString which contains the Assembly string of the class you want to construct.
This class should have an empty argument constructor that would be called (so it seems very useless)

I didn’t try it as I didn’t find an idea to exploit it.

  • Call to ParseManifest (unkown) ndp/clr/src/BCL/system/activationcontext.cs

I didn’t try it as I don’t know what Manifest is (maybe interesting)

  •  Unserialize Icon, Font, Bitmap, Cursor, ImageList

ndp/fx/src/commonui/System/Drawing/Icon.cs
ndp/fx/src/commonui/System/Drawing/Advanced/Font.cs
ndp/fx/src/commonui/System/Drawing/Bitmap.cs
ndp/fx/src/winforms/Managed/System/WinForms/Cursor.cs
ndp/fx/src/winforms/Managed/System/WinForms/ImageListStreamer.cs

Could be good to exploit native parser bug remotely.

  • Load X509 certificate ndp/clr/src/BCL/system/security/cryptography/x509certificates/x509certificate.cs

Interesting discoveries

DataSet object waits for XmlSchema BinaryObjectString that is vulnerable to Xml External Entities (check examples/DataSet_XXE.json).

Unfortunately Microsoft XML parser is quite susceptible so I didn’t succeed to blindly leak a web.config file (I only read C:\Windows\system.ini as POC). Actually I don’t know what to leak with a blind XXE on Windows System.

Maybe an XXE expert could do better, but it’s still a quite critical vulnerability if you know the application (SSRF and co…)

  • Unmarshal COMObject

So here comes the best part!

COMObject Marshaling

James Forshaw already pointed it ndp/fx/src/wmi/managed/System/Management/InteropClasses/WMIInterop.cs without trying to exploit it.

As COMObject Mashaling is a native windows function, I looked at the COMObject marshaling format to add a third layer of serialization (https://msdn.microsoft.com/en-us/library/cc226828.aspx) and reversed the ole32.dll CoUnmarshalInterface function.

I know nothing about COMObject so maybe I missed an easy exploit but I didn’t succeed to use OBJREF_STANDARD, OBJREF_HANDLER, and OBJREF_EXTENDED.

On the other hand OBJREF_CUSTOM allows you to pass an arbirary clsid that would load the associated DLL and try to unmarshall another layer of specific data pObjectData if this COMObject exposes the IMarshal interface (kind of 4th layer of custom serialization).

Unfortunately automatically trying junk data on every CLSID I found in the register didn’t produce anything.

Reversing ole32.dll shew me some special hardcoded CLSID. One of them  (CLSID_StdWrapper : {00000336-0000-0000-C000-000000000046}) used with special IID (IUnknown {00000000-0000-0000-C000-000000000046}) seems to use the pObjectData and fuzzing its format gives me a crash with controlled register \o/ !

I did my first tests on specific 64bits binaries under windows 7 and then setup a windows server 2008 R2 64 bits with IIS and asp.net 2.5 but the COMobject unmarshalling from BinaryFormatter is a feature of .NET (even in the last version) and the crash occurs in ole32.dll not related to IIS version so it should work everywhere.

crash_capture_20160512_103139

I figured that it may be possible to control RIP from this pointer with a very specific structure.

[Pointer + 0x20] -> [Pointer2 + 0x20] -> [Pointer3 + 0x28]
                                      -> [Pointer3 + 0x10]
                                      -> [Pointer3] == 0
[Pointer + 0x38] -> [Pointer4 + 0x38] -> [Pointer5] -> [Pointer6 + 8] -> RIP

Of course finding such specific structure in randomly mapped memories was impossible.

If you remember the list of possible unserializable .NET objects one of them should raise your attention to achieve heap spray.

Bitmap ! Indeed it is possible to craft a specific BMP that would be mapped untouched in memory (see examples/Image.json).
But how can we achieve heap spray without sending Gb of BMP?

BinaryFormatter allows internal object reference!

Firstly it may allow an easy DOS by cross referencing two objects (haven’t tested yet).

Secondly, it’s perfect to do a nice heap spray!

Just create one ArraySinglePrimitive with your BMP sprayed data and create as many ClassWithMembersAndTypes (System.Drawing.Image) with member “Data” a MemberReference pointing to the ObjectID of this ArraySinglePrimitive.

I choose an arbitrary bmp size aligned on 0x10000 ((640 * 818) == 0x180000 + bmp header) so it would reduce the shift in random mapping.

Once I found a nice always mapped address (0x30303030) I tried to spray the magic pointer allowing me to control RIP.

def q(i):
 return struct.pack('<Q', i)

spray =  q(0) + q(pointer+0x8)
spray += q(RIP-1) + q(0xDEADBABEDEFECA7E)
spray += q(pointer) + q(0xDEADBABEDEFECA7E)
spray += q(0xDEADBABEDEFECA7E) + q(pointer+0x10)

heap

A very good point for us is that memory access errors are handled by .net so spawned IIS worker process w3wp.exe doesn’t crash.

You can try as many times as you want and it should take maximum 8 tries to find your structure correctly aligned!

With relatively good RIP control, next part was to find non-ASLR DLL to construct our ROP.
Fortunately, diasymreader.dll is non-ASLR and seems to be loaded after a first .net exception.

I needed to change my magic pointer structure to also control RSP with one gadget and point it in my sprayed retchain+ropchain.

heaprop

spray =  q(0) + q(pointer+0x8)
spray += q(RIP-1) + q(0xDEADBABEDEFECA7E)
spray += q(pointer) + q(RIP2)
spray += q(RSP) + q(pointer+0x10)

RIP : push rsi # pop rsp # add rsp, 0x20 # pop rdi
RIP2 : pop rsp # add rsp, 0x10

This way I can control RSP !

Last part should be straight-forward as virtualAlloc and memcpy functions can be called from diasymreader.dll.

A third heapspray with nopsled+shellcode should be enough to stabilize the exploit.

heapsc

I successfully reliably exploited this vulnerability on my IIS lab directly from a non hmac’ed ViewState to run meterpreter.

To sum up :

  1. ViewState deserialization with Token_BinarySerialized
    If you directly find BinaryFormatter (with ot without obfuscation (SAP application I’m looking at you with your base64(gzip(base64(BinaryFormatter)))))
  2. BinaryFormatter deserialization which we use to deserialize 3 BMP 400 times each and a IWbemClassObjectFreeThreaded object
  3. this object actually contains a malicious marshalled COMobject that allows us to control a special pointer.
  4. if this pointer dereference a specific structure that we spray with our first BMP we can control RIP then RSP that point on our second BMP with a ROPCHAIN that VirtualAlloc and memcpy our shellcode from the third BMP.

Conclusion

Deserializing untrusted input is bad, we all know that… I didn’t find public POC of vulnerability with .NET serialization (compare to Java) so here it is!

For information, I reported the COMObject deserialization crash to Microsoft and they flagged it “defense in depth” as it requires untrusted unmarshaling first, so if they make a patch it will be in a long time.

Unfortunately I didn’t find another vector to exploit the COMObject unmarshaling bug (RPC DCOM use another dll to unmarshal COMObject) but maybe someone with better windows knowledge could find an idea !

Last but not least the .NET remoting system internally uses BinaryFormatter. It has been replaced by WCF but it should be possible to exploit the same bugs if WCF is configured to accept NetDataContractSerializer.

SCRT infrastructure division – New partnership announcement

SCRT has launched a partnership with Skybox Security to help its clients to strenghlen their risk identification and measurement capabilities.

Information systems are constantly getting complexer and are very dynamic. Skybox provides a powerful set of integrated security solutions that give unprecedented visibility of the attack surface and key Indicators of Exposure (IOEs) such as exploitable attack vectors, hot spots of vulnerabilities, network security misconfigurations and non-compliant firewalls. Skybox allows to break down information silos through integration with dozens of security solutions that enterprises are already using. By extracting actionable intelligence from data using modeling and simulation, Skybox gives security leaders the insight they need to quickly make decisions about how to best address threat exposures that put their organization at risk, therefore increasing operational efficiency.

More information on Skybox Security at http://www.skyboxsecurity.com