recon Bruxelles 2017

Première édition de recon en Belgique en ce début d’année! Le logo de l’évènement change, mais le programme reste le même: Reverse engineering et exploitation. Du coup, pas une seule conférence n’a oublié son screenshot d’IDA Pro (qui est d’ailleurs le sponsor de l’évenement). Comme pour l’édition 2016 de Montréal, les conférences ont duré trois jours avec une seule track, donc pas de remords ni de regrets. 🙂

Je vous propose un aperçu de quelques conférences de cette première édition Européene:

Hackable Security Modules Reversing and Exploiting FIPS-140-2 lvl3 HSM firmware

Cette présentation traitait de l’analyse d’un firmware de HSM dans le but d’y déceler des vulnérabilités. Un HSM (Hardware Security Module) permet de stocker et gérer des clés cryptographiques de manière sécurisée. Ils sont typiquement utilisés par les autorités de certification afin de protéger l’accès à leurs clés privées.

Le HSM testé est produit par la société Ultimaco et est certifié FIPS-140-2 level 3. Cette certification implique que le boitier dispose d’un mécanisme de détection des intrusions physiques en plus d’un système bloquant l’accès aux clés contenues dans le module. L’appliance est un système Linux doté d’un module HSM connecté en PCIe. Lors du premier démarrage, une clé de chiffrement et une clé de backup sont générées afin de protéger toutes les autres clés stockées sur le système.

La première étape a consisté à décompresser le firmware qui utilisait un format propriétaire (MPKG) et qui contenait différents firmwares pour chaque module de l’appareil au format MTC. Ce format MTC est une version modifiée du standard COFF. Après l’avoir reversé, le code binaire a pu être extrait. Sauf que le HSM utilise un processeur de signal (DSP) TMS320C64x produit par Texas Instrument qui n’est pas pris en charge par les logiciels de désassemblage classiques. Ainsi il était nécessaire de créer un module de désassemblage pour ajouter cette architecture dans Capstone. La complexité de l’architecture a rendu la tâche très ardue mais finalement le code a pu être désassemblé.

L’analyse du code a permis de mettre en évidence au moins une vulnérabilité. En effet, un contrôle est effectué au moment d’ouvrir une base de données afin d’empêcher l’accès aux clés. La routine de vérification contrôle que la base de données ne soit pas la chaine de caractères VMBK1 (nom de la base contenant la clé de backup). Sauf que le nom de base peut être préfixé par la localisation de cette dernière, ainsi FLASH\VMBK1.db permet de récupérer les clés.. 🙂

L’entreprise qui développe le produit à mis près d’une année pour corriger la faille… Cependant il ne lui a fallu que quelques jours après la présentation pour demander à l’auteur de retirer ses outils hébergés sur Github.

Breaking Code Read Protection on the NXP LPC-family Microcontrôlers

L’auteur présente le contournement de la protection Code Read Protection (CRP) implémentée dans les microcontrôlers de la famille NXP LPC. Cette protection permet normalement d’éviter que le code du microcontrôleur puisse être extrait de la flash. Chris Gerlinsky nous montre comment mettre en place une attaque par glitching afin de neutraliser le CRP.

Le contournement débute par l’acquisition d’un microcontrôleur de cette famille. Le chip est programmé avec un code simple qui consite en une boucle infinie dans laquelle deux variables sont incrémentées de manière identique puis comparées. Le but étant de détecter si l’une des deux variables n’a pas été incrémentée correctement à cause d’un glitch.

Un circuit particulier (Xmega-A1 MAX4619) est utilisé pour générer les glitchs (impulsions de tension basses) en switchant entre deux sources d’alimentation: Une source à la tension nominale (1.9v) et une autre plus basse qui va permettre de générer les erreurs (~0.7v). Ce circuit est directement utilisé pour alimenter le microcontrôleur. Des glitchs sont ensuite générés en variant la tension basse afin de trouver une valeur qui génère un maximum d’erreurs dans la comparaison des deux variables incrémentées sans interrompre l’alimentation du microcontrôleur. L’étape suivante consiste à faire varier la longueur des impulsions et finalement de décaler l’impulsion dans le temps afin qu’elle affecte la vérification du flag CRP.

Lorsque l’impulsion arrive au bon moment, le résultat de la comparaison du flag CRP est modifiée et l’accès au bootloader est autorisé permettant ainsi de lire la flash.

Le code du module de glitch est disponible sur github.

Transforming Open Source to Open Access in Closed Applications

Un grand nombre de logiciels propriétaires intègrent du code Open Source afin de réduire le temps de développement et par conséquent les coûts. Cette démarche à cependant un certain nombre de désavantages en termes de sécurité qui ne sont pas forcément pris en compte par l’éditeur du logiciel. D’une part, les mises à jour du logiciel Open Source doivent être intégrées dans le projet ce qui retarde la correction effective des vulnérabilités dans la solution propriétaire. D’autre part, l’abandon d’un projet Open Source utilisé expose fortement le logiciel dont le/les composants ne seraient plus mis à jour.

Ce cas de figure est illustré dans la présentation par le logiciel Acrobat Reader. En effet, le moteur de traitement XSLT d’Acrobat est basé sur le projet Open Source Sablotron, qui a cessé d’être maintenu en mai 2015. Les auteurs utilisent une technique de matching de code binaire pour trouver des correspondances entre le code propriétaire et le logiciel Open Source.

L’analyse du code source des fonctions/parties reprisent a permis de mettre en évidence plusieurs vulnérabilités critiques (exécution de code) dans le lecteur de PDF.

miLazyCracker

Kevin Larson a apporté sa pierre à l’édifice du cracking NFC contre les cartes Mifare Classic et Mifare Plus. Il a présenté son outil miLazyCracker qui, faute d’améliorer l’attaque, rend l’exploitation extrêmement simple. En effet, l’outil développé n’attend aucun argument et se met en attente d’une carte Mifare. De plus il exploite un hardware bon marché, le SCL3711.

Vous trouverez son outil directement sur Github miLazyCracker.

Teaching Old Shellcode New Tricks

Le framework Metasploit utilise une technique baptisée Stephen Fewer’s Hash API (SFHA) qui permet de simplifier l’appel d’une fonction particulière de l’API Windows en utilisant un hash. Les solutions antivirus ont fini par utiliser ce pattern afin de détecter Meterpreter (la partie cliente de Metasploit). De plus, l’outil EMET de Microsoft détecte et bloque l’exécution de shellcode qui emploie cette technique.

Ce talk présente une technique basée sur IAT / LLAGBA qui permet de remplacer le SFHA. L’outil développé traite un payload généré à l’aide de msfvenom et remplace le stub SFHA afin de bypasser EMET. En plus de cela, il permet de supprimer les hashs originaux afin de limiter la détection du payload par les anti-virus.

Pour son outil, c’est par ici: fido.

Harnessing Intel Processor Trace on Windows for fuzzing and dynamic analysis

Cette présentation décrit la nouvelle fonctionnalité intégrée dans les processeurs Intel de génération Skylake, à savoir Intel Processor Trace. Cette fonctionnalité permet de tracer l’exécution d’un programme directement en hardware, ce qui réduit largement la charge CPU nécessaire au suivi.

Les deux présentateurs travaillent sur le développement d’un driver Open Source pour Windows qui supporte le multiprocesseur. Un plugin permettant de visualiser la trace directement dans IDA Pro est également disponible. Le code du driver et du plugin sont disponible dans ce repository WindowsIntelPT.

Le driver active la fonctionnalité dans le processeur. Ce dernier commence alors à enregistrer les instructions dans plusieurs fichiers de log (un par processeur logique). En parallèle le driver collecte certaines informations sur la mémoire. Les différentes informations récupérées sont croisées avec le binaire lui-même afin de retracer l’exécution. Finalement le plugin IDA permet de charger la trace et de visualiser graphiquement le chemin d’exécution. D’après les conférenciers, un overhead de l’ordre des 10% serait constaté.

.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.

Bypassing TPM-based Bitlocker

Attack on Windows authentication mechanism

At the recent BlackHat Europe conference (November 10 – 13, Amsterdam) a security researcher called Ian Haken presented a very interesting, simple yet powerful attack allowing to bypass Windows (Kerberos) authentication on machines being part of  a Domain.

The attack in itself allows someone – having physical access to the Windows workstation or laptop – to log into the system by resetting the password of a domain account. For that the attacker will just need to setup a rogue Domain Controller and configure it to declare the target account as expired. Indeed Haken identified a loophole in the mechanism which allows an attacker to force the local update of the cached Domain credentials despite the Kerberos KDC failing to prove it’s identity to the target workstation.

The whole attack, whose details are well explained in Ian Haken’s paper, can be setup using common open-source software and very simple configuration steps.

By itself, this would not be a significant breakthrough as other means of achieving similar results are widely known (e.g. by booting the machine on a live system and tampering with the system). This attack however becomes very interesting when applied to systems using Microsoft Bitlocker for full-disk encryption and configured for using the machine’s TPM (without PIN or USB key) in order to avoid explicit pre-boot authentication.

In this context, the encryption keys are automatically retrieved by the Windows bootloader from the TPM without any user (or attacker) input in order to provide a transparent Windows boot. In this scenario, the whole security of the (encrypted) data on the system falls back on the Windows login mechanism as any user being capable of logging into the system would (transparently) have access to all or part of the local data (depending on the user privileges).

Obviously in this context, Haken’s attacks turns out into a way of bypassing Bitlocker encryption in order to have access to the (encrypted) system and data.

Mitigation

A security bulletin (and corresponding patch) has been issued by Microsoft : MS15-122.

According to Microsoft, “the update addresses the bypass by adding an additional authentication check that will run prior to a password change.”

Recommendations

Microsoft’s security bulletin is rated as Important which does not correspond to the highest severity level. However, as the attack targets a common Bitlocker configuration (actually Microsoft does not generally recommend the use of pre-boot authentication) this attacks appears as very easy to implement against stolen or lost laptops with potentially critical consequences in terms of data confidentiality.

For that reason SCRT heavily recommends this patch to be applied as quickly as possible on affected systems, taking care not to neglect mobile systems that may be used by employees “on the field” or “on the road” and that may not be subject to frequent system updates (e.g. because they are often out of reach from standard company’s infrastructure and update workflow).

SCRT Security Day 2015

secDay_banner

Jeudi 17 septembre
09:00 – 17:00
Hôtel Best Western à Chavannes-de-Bogis

PROGRAMME

09:00 – 09:30      Accueil & Petit déjeuner
09:30 – 10:00      Introduction par SCRT
10:00 – 10:45      Tenable : From vulnerability management to continuous network monitoring
10:45 – 11:00      Pause
11:00 – 11:45      HP TippingPoint : HP TippingPoint Advanced Threat Appliance (ATA) solution.
11:45 – 12:30      Fortinet : Internal Segmentation Firewall
12:30 – 13:45      LUNCH
13:45 – 14:30      Varonis : La gouvernance des données à l’aide des solution Varonis
14:30 – 15:15      Splunk : Introducing Splunk; SIEM VS Security Intelligence
15:15 – 15:30      Pause
15:30 – 16:15      Entrust : Entrust eliminating the password in the enterprise
16:15                   APÉRITIF

INSCRIPTIONS

Le nombre de places étant limité, nous vous remercions de bien vouloir confirmer votre présence via le lien suivant : https://www.eventbrite.fr/e/billets-scrt-security-day-2015-17305044855 avant le 7 septembre 2015.

Defcon 2015 résolution heapsoffun

La semaine dernière, plusieurs ingénieurs de SCRT ont participé aux qualifications du CTF Defcon avec l’équipe 0daysober, qui a terminée 10ème et se qualifie donc pour la finale ! Ce post décrit deux des épreuves résolues, knockedup et heapsoffun.

Heapsoffun

If you have been knockedup then you know what to do. Perhaps try "tirer"
sha1sum heapsoffun 5ee5b2cde811e617cd789c73c1d8d2d9e8b27c36
Yes we know the flag is owned by root.

Un challenge pwnable de 4 points faisable après knockedup.

tldr; un challenge de reverse de 1 point permettant d’ouvrir 2 ports en fonction d’une séquence de paquets envoyée sur des ports UDP.

Continue reading Defcon 2015 résolution heapsoffun