Tout ceux qui ont connu la grande époque des sharewares se souviennent, peut-être avec nostalgie, des bidouilles à faire dans un éditeur héxadécimal pour déverrouiller (illégalement, c'était mal !) telle ou telle fonction. C'est en repensant à cette époque lointaine que je me suis dit qu'à présent j'était très certainement capable de comprendre ce qu'il y avait derrière le fait de changer quelques valeurs dans un éditeur hexa...voire même que je serai capable de reproduire le phénomène. Aussitôt pensé, aussitôt fait (ça m'a pris moins de 10mn, donc n'ayez pas peur : tout le monde arrivera à suivre ^^ !)

Première chose à faire pour reproduire les conditions de l'époque : trouver un programme cible à "déplomber". Pour le bien de la démonstration j'en réalise un moi-même qui se comportera donc de la façon que je souhaite et dont je connaitrai les rouages internes. Hop je dégaine vim :

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

int main(int argc, char** argv) {
    if (0==strcmp("secretpassword",argv[1])){
        printf("HACK SUCCESSFUL\n");
    }
    printf("Au revoir\n");
    return EXIT_SUCCESS;
}

Le concept de ce micro bout de code est simple : on invoque le programme avec un argument, si jamais cet argument est bien "secretpassword" le programme nous affiche "HACK SUCCESSFUL" (c'est la fonction que nous cherchons à "déplomber"), si l'argument fourni n'est pas le bon le programme passe directement à "Au revoir" (et si on ne fourni pas d'argument il segfault...c'est juste un programme d'exemple !). Bref, on compile ($gcc hackme.c) puis on lance gdb ($gdb a.out). Une fois le soft chargé dans gdb, on désassemble le bloc d'instruction principal ((gdb)disass /r main) :

0x08048461 <main+13>:    53     push   %ebx
0x08048462 <main+14>:    51     push   %ecx
0x08048463 <main+15>:    83 ec 10       sub    $0x10,%esp
0x08048466 <main+18>:    89 cb  mov    %ecx,%ebx
0x08048468 <main+20>:    8b 43 04       mov    0x4(%ebx),%eax
0x0804846b <main+23>:    83 c0 04       add    $0x4,%eax
0x0804846e <main+26>:    8b 00  mov    (%eax),%eax
0x08048470 <main+28>:    89 44 24 04    mov    %eax,0x4(%esp)
0x08048474 <main+32>:    c7 04 24 90 85 04 08   movl   $0x8048590,(%esp)
0x0804847b <main+39>:    e8 c8 fe ff ff call   0x8048348 <printf@plt>
0x08048480 <main+44>:    8b 43 04       mov    0x4(%ebx),%eax
0x08048483 <main+47>:    83 c0 04       add    $0x4,%eax
0x08048486 <main+50>:    8b 00  mov    (%eax),%eax
0x08048488 <main+52>:    89 44 24 04    mov    %eax,0x4(%esp)
0x0804848c <main+56>:    c7 04 24 95 85 04 08   movl   $0x8048595,(%esp)
0x08048493 <main+63>:    e8 d0 fe ff ff call   0x8048368 <strcmp@plt>
0x08048498 <main+68>:    85 c0  test   %eax,%eax
0x0804849a <main+70>:    75 0c  jne    0x80484a8 <main+84>
0x0804849c <main+72>:    c7 04 24 a4 85 04 08   movl   $0x80485a4,(%esp)
0x080484a3 <main+79>:    e8 b0 fe ff ff call   0x8048358 <puts@plt>
0x080484a8 <main+84>:    c7 04 24 b6 85 04 08   movl   $0x80485b6,(%esp)
0x080484af <main+91>:    e8 a4 fe ff ff call   0x8048358 <puts@plt>
0x080484b4 <main+96>:    b8 00 00 00 00 mov    $0x0,%eax
0x080484b9 <main+101>:   83 c4 10       add    $0x10,%esp
0x080484bc <main+104>:   59     pop    %ecx
0x080484bd <main+105>:   5b     pop    %ebx
0x080484be <main+106>:   5d     pop    %ebp
0x080484bf <main+107>:   8d 61 fc       lea    -0x4(%ecx),%esp
0x080484c2 <main+110>:   c3     ret

Bon...ça en raconte des choses tout ça...Heureusement que je connais le programme de base, et que je l'ai conçu exprès pour que la tache soit aisée, sinon je pense qu'avec mes compétences en assembleurs "un peu" rouillées je me serait amusé 5mn à trouver ce que je cherche. Ici aucun problème cependant : il n'y a qu'un seul embranchement conditionnel qu'on repère facilement :

0x0804849a <main+70>:    75 0c  jne    0x80484a8 <main+84>

Ce que l'on veut faire c'est donc supprimer cet embranchement conditionnel afin que le flux d'instruction poursuive son cours direct. Pour ce faire je vais utiliser une méthode à moi et honnêtement j'ignore complètement si c'est la méthode canonique ou pas, mais moi je l'aime bien.

D'abord j'utilise xxd¹ pour récupérer un dump héxa de mon binaire (xxd a.out > dump.txt), ensuite je cherche dans ce dump l'enchainement 750c qui correspond à mon saut conditionnel (antépénultième bloc dans la ligne suivante) :

0000490: 8504 08e8 d0fe ffff 85c0 750c c704 24a4  ..........u...$.

Je remplace maintenant mon saut conditionnel par l'instruction préférée des pionniers des shellcodes, à savoir le bien aimé 0x90 qui correspond à NOP². La ligne dans mon fichier dump devient donc :

0000490: 8504 08e8 d0fe ffff 85c0 9090 c704 24a4  ..........u...$.

On récupère un binaire à partir du dump héxa modifié (xxd -r dump.txt b.out). Et ensuite il suffit de lancer b.out avec n'importe quel argument pour bien passer par la fonction que l'on voulait déplomber et qui était auparavent "protégée" par mot de passe :

$ ./b.out HackYou
HACK SUCCESSFUL
Au revoir

Et voilà, le tour est joué. Il me reste encore quelques années/décénnies/vies de pratique avant d'espérer atteindre le niveau de compétence de certains gourous du désassembleur, mais en tout cas ça m'a bien amusé de constater le chemin parcouru depuis mes années collèges avec ce mini déplombage des familles... et ça m'a aussi donné envie de jouer plus souvent avec le couple gdb/xxd.

1. Inclu dans le package de "vim", c'est donc forcément un programme génial ;) ! ↩
2. NOP signifiant : No OPeration. Cette instruction ne fait rien du tout comme son nom l'indique :) ↩

L'autre jour je lurkais sur 4chan lorsque j'ai pu assister, en l'espace de 5mn, à deux Epic Fail ayant la même cause : la méconnaissance complète de l'existence des métadonnées EXIF. Comme je ne suis plus tout à fait certain d'avoir déjà abordé ce sujet ici, je le fais maintenant :)

Qu'est ce que les données EXIF ?

Expliqué très brièvement les données EXIF sont des métadonnées ajoutées à des fichiers images afin de stocker tout un tas de trucs intéressant (date de la prise de la photo, modèle de l'appareil utilisé, taux de compression, résolution, etc.). De nos jours 99% des appareils photos rajoutent des données EXIF quand ils prennent une photo (la pseudo-norme EXIF reprenant intégralement la norme JPEG il y a une totale compatibilité et l'utilisateur lambda ne voit qu'une image JPEG alors qu'il s'agit d'une image JPEG agrémentée de méta-données EXIF). Bien que cette pseudo-norme soit donc très répandue de nos jours et que certains savent clairement en faire bon usage, on trouve encore des gens qui ne sont pas conscients de l'existence de ces méta-données, comme vont vous le prouver les deux petites histoires qui suivent.

Se cacher derrière son petit doigt

Premier ''Epic Fail'' : quelqu'un publie une photo de sa future femme, dans une tenue que nous qualifierons de "Olé Olé", en prenant bien soin de masquer son visage au préalable pour qu'on ne la reconnaisse pas. Afin de protéger l'anonymat de sa promise notre amusant Anon¹ avait en effet pris soin de lancer son logiciel de retouche photo préféré et de rajouter un gros carré noir au dessus du visage de sa chère et tendre avant de publier la photo. Pourtant, moins d'une minute après avoir publié la photo ainsi censurée, une version dé-censurée a ressurgie sur 4chan...Comment cela est-il possible ? Va-t-on nous ressortir le coup des carrés noirs pdf mais sur le format JPEG qui n'a pourtant rien d'un format objet ?

Non c'est bien plus simple : l'appareil photo utilisé devait être de bonne facture puisque la miniature embarquée en donnée EXIF dans l'image censurée était, de mémoire, d'une résolution proche de 640x480 et elle n'a pas été mise à jour lors de la censure grossière appliquée avec un logiciel de retouche un peu cheap...L'image censurée embarquait donc une version 640x480 non-censurée, et c'est largement assez pour reconnaitre un visage : FAIL.

Jouer à cache-cache avec une balise A.R.V.A. dans la poche

Deuxième Epic Fail : Un autre Anon a utilisé son super smartphone pour prendre une photo de lui dans un miroir en pleine activité que nous qualifieront de "compromettante". Bien entendu il avait pris soin de porter un masque sur la photo afin de protéger son anonymat (pas folle la guêpe). Encore une fois la sanction est pourtant tombée en moins d'une minute : son smartphone ayant enregistré sa position GPS dans les données EXIF, un plan google map et une photo google streetview correspondant à son domicile ont fait écho à la publication de sa première photo...FAIL.

Conclusion

Pour jouer avec les tags EXIF je vous conseille ce super outil online, ou ce super outil offline. En tout cas maintenant vous ne pourrez pas dire que vous n'êtes pas prévenus ;) !

1. http://encyclopediadramatica.com/Anonymous ↩

Mini billet pour souhaiter de bonnes fêtes à tout le monde et, puisque c'est de circonstance, je vous résume¹ la description faite sur VX Heaven du premier virus répandue à grande échelle sur un réseau informatique et en ayant notablement perturbé le fonctionnement : CHRISTMAS EXEC

CHRISTMAS EXEC a été écrit en 1987 (22 ans déjà...) par un étudiant de l'université de Clausthal-Zellerfield (Allemagne) dans le but de souhaiter un joyeux Noël à ses amis de l'université. A l'époque Internet tel qu'on le connait aujourd'hui n'existait pas, et le programme s'est donc répandu d'abord sur le réseau de l'université de Clausthal-Zellerfield (à mes souhaits), puis il a fuit sur le réseau de recherche européen EARNet, il a poursuivi sa folle épopée sur BitNet aux USA et a terminé sa course en paralysant VNet, un réseau privé utilisé par IBM pour communiquer avec ses fournisseurs et clients.

Rien de bien sorcier dans ce programme pourtant puisqu'il se contentait d'afficher un ascii-art de Noël ...et de s'envoyer par mail à tout les contacts qu'il trouvait sur l'ordinateur "infecté". Les guillemets autour de "infecté" sont d'ailleurs importants puisque pour s'exécuter le programme avait besoin d'être volontairement lancé par l'utilisateur (bah ouais, de la bonne vieille ingénierie sociale :) ).

Comme quoi on n'a rien inventé...et 22 ans après on trouve encore des gens capable d'exécuter n'importe quoi quand on leur demande (je pense en particulier aux codecs "indispensables" pour visionner des films interdit aux moins de 18 ans, ou encore aux super antivirus-de-la-mort-qui-tue et qui doivent absolument être installés parce qu'ils viennent d'identifier 35² infections différentes sur votre poste mais qu'ils peuvent vous aider à le nettoyer...)

Allez, pour conclure ce billet (et certainement l'année vu que je pars loin du net pour la fin du mois) je vous retranscrit l'ascii-art de CHRISTMAS EXEC, ça n'a pas vieillit d'un poil :) !

                    *
                    *
                   ***
                  *****
                 *******
                *********
              *************                A
                 *******
               ***********                VERY
             ***************
           *******************            HAPPY
               ***********
             ***************            CHRISTMAS
           *******************
         ***********************         AND MY
             ***************
           *******************         BEST WISHES
         ***********************
       ***************************     FOR THE NEXT
                 ******
                 ******                    YEAR
                 ******

1. et je traduit également, si ça c'est pas trop gentil de ma part ?! ↩
2. Remplacez vous même par 10D6 pour le résultat correspondant à votre ordinateur ↩

Billet en vrac sur pleins de petites choses qui m'ont interpellé récemment.

L'oeil de moscou

Depuis quelques temps je tombe sur de plus en plus de moteurs de recherches orienté sécurité, et vu que pas mal de monde autour de moi ne les connais pas je me dit que partager leurs adresses ici ne sera pas inutile. D'abord il y a sucuri qui part d'un enregistrement DNS et qui vous donne une page synthétique présentant pleins d'informations utiles prêtes à être copiées/collées dans votre rapport de test d'intrusion (whois, enregistrements DNS, headers http, ...).

Ensuite il y a shodan qui me laisse un peu plus circonspect...en effet il permet de trouver des IP sur lesquelles écoutent des logiciels serveur de votre choix. Typiquement vous tapez "Apache 2.0" et shodan vous retourne des IP où des Apaches 2.0 écoutent (il vous retourne les headers HTTP en même temps afin que vous puissiez vérifier sa déduction). Ca peut être utile pour faire des statistiques et des jolis graphiques en couleur, mais à part ça... Enfin il y a des google dorks basées sur sucuri qui font à peu près la même chose. Franchement si l'un d'entre vous à une idée de l'utilité de ces deux derniers services, à part "faire des stats (dont la représentativité n'est pas certaine)" et "Victim as a service", je suis intéressé !

Pourquoi autant de café dans l'informatique ?

Du café, encore du café, toujours du café... Il y a quelques mois (vers Mai 2009 si ma mémoire est bonne) Microsoft a offert aux autorités américaines des clés USB baptisées COFEE et qui permettent, en gros, de lancer pleins d'outils de forensics lorsqu'elle sont branchées à un PC windows. Premier rebondissement de l'histoire : le contenu de ces clés USB a leaké à plusieurs endroits début Novembre (le plus sûr d'entre eux étant wikileaks). Second rebondissement (datant d'il y a à peine quelques jours) : Un outil "anti-COFEE" (baptisé, non sans humour, "Decaf") se promènerait sur la toile. L'outil est censé effacer des logs (windows et COFEE), en pourrir d'autres (rajoutant des infos aléatoires), désactiver le support de l'USB, ... bref Decaf est censé empêcher COFEE de fonctionner proprement. Pour la petite histoire Decaf n'est fournit que sous forme exécutable (donc pas de code source) et la licence en interdit la décompilation... j'attend impatiemment le troisième rebondissement de l'histoire où on apprendra que Decaf embarque une backdoor (que ça soit de l'info ou de l'intox).

La réalité rattrape la fiction

L'une des planches de xkcd qui m'avait le plus amusé est presque devenue réalité :) J'avais moi même faillit bricoler un système analogue à la lecture de ces vignettes, puis j'avais abandonné le projet faute de temps (et de réelle utilité...) mais visiblement quelqu'un d'autre est allé au bout d'une idée similaire (à priori sans avoir eu auparavant connaissance de la planche d'xkcd). Le projet s'appelle "VirusZoo" et est accessible via internet. Le concept est simple (et plus épuré que celui d'xkcd) : on choisi un virus depuis une collection de virus¹, ce virus infecte alors une machine virtuelle sous windows, et il ne nous reste plus qu'à observer la machine virtuelle grâce à des screenshot pris automatiquement et accessible depuis le site web de viruszoo :) Simple, efficace, et presque totalement dénué d'intérêt autre que le coté "fun" de voir vivre des virus informatique dans leur milieu naturel² :)

1. Pour autant que je sache il n'est hélas pas possible de proposer des nouveaux échantillons à rajouter à la collection ↩
2. Certains y voient comme intérêt la possibilité de mener des actions de sensibilisation en se servant des screenshots comme support visuels...pourquoi pas après tout. ↩

Avec tous ces androids qui fleurissent un peu partout dans mon entourage ces derniers temps il fallait bien que je craque un jour ou l'autre... Première étape du craquage : je me replonge (légèrement) dans le Java¹ pour jouer un petit peu avec le SDK et les émulateurs android fournis par Google. Et comme je sens que les étapes d'initialisations d'un projets ou d'une VM sont du genre à disparaitre de ma mémoire en moins de temps qu'il n'en faut à Windows ME pour planter je me suis dit que j'allais en faire un petit billet pour ce blog, à moitié sous forme de mémo donc, histoire de conserver une trace de toutes les étapes à mener pour jeter les premières fondations d'une appli android²

Téléchargement de l'environnement

Première étape : récupérer le SDK chez Google. Jusque là : facile ;) Ensuite on décompresse l'archive tar xvzf android-sdk_r3-linux.tgz. Toujours rien de compliqué jusqu'à présent. Pas d'improvisation, soyons discipliné cd android-sdk-linux && cat "SDK Readme.txt", la ligne suivante nous est donnée directement par le petit texte du Readme, ./tools/android update sdk. Ca ouvre un GUI...bon, c'est l'heure d'improviser. Visiblement le GUI permet de télécharger des composants essentiels qui ne sont pas inclus dans l'archive, par exemple ce qu'il faut pour créer des android virtuels (je me disait bien que 15M pour le tout ça faisait léger...). Je choisis un SDK pour Android 2.0 (la version la plus récente), et j'espère que ça suffira pour commencer (le bébé pèse tout de même plus de 40M et je suis en train de faire un gros emerge world à coté donc ma bande passante est assez limitée ;) )

Préparation de l'environnement

Une fois le téléchargement et l'installation (automatique) terminés on a toutes les briques de bases. Préparons tout ça pour que ça soit en état de fonctionner. Dans la fenêtre de GUI que je n'ai pas encore fermée (mais qu'on peut retrouver aisément en lançant juste ./tools/android sans arguments) je choisis le menu "Virtual Devices" et hop je clique sur "New", rien de super compliqué là, je prend les valeurs par défaut puis je clique sur "Create AVD" (Android Virtual Device). Ca a l'air d'avoir marché puisque ma VM (pardon, "mon AVD" ) apparait maintenant dans une liste de choix qui était auparavant vide. Je la sélectionne, je clique sur "Start" et là la magie s'opère : l'android virtuel démarre bien.

• Première constatation : je n'aurai peut-être pas du laisser le skin par défaut, il est vraiment laid (mais au moins il a l'air fonctionnel, je vais sans doute m'y habituer, et rien ne dit que les autres sont mieux lol).
• Seconde constatation : le démarrage est lent, mais alors vraiment lent ! Je pensais que sur émulateur ça irait plus vite que sur les vrais téléphones mais non (ceci dit mon pc n'est pas une machine de guerre...mais quand même). Je suppose que c'est la faute de Java, de toute façon quand quelque chose rame c'est forcément la faute de Java ;) !

Hello World

Démarrer le projet

Bien, maintenant qu'on arrive à faire tourner des android virtuels, il est temps de sacrifier à l'éternelle tradition du "Hello World". Seulement voilà : je n'aime pas le Java³, et je n'aime pas Eclipse non plus, donc je ne vais pas pouvoir suivre à la virgule près le tutoriel officiel...qu'à celà ne tienne, je vais essayer d'y coller au mieux et au moins je comprendrai sans doute un peu mieux comment ça se passe que ceux qui se contentent de cliquer sur des gros boutons Eclipse "Auto Write Code And Compile And Debug And Deploy And Become Rich" ;)

Première étape : démarrer un nouveau projet android. Pour ce faire j'aurai besoin de :

• Connaitre ma plateforme cible (i.e. la version d'android pour laquelle je veux écrire un programme). Comme je n'en ai téléchargé qu'une (pour android 2.0, souvenez vous) je suis prêt à parier que ma cible porte le numéro "1", mais bon, vérifions tout de même : ./tools/android list targets Gagné : l'indice 1 (le seul présent) correspond bien à l'API level 5, android 2.0 :)
• Un nom pour mon application. Je vais faire original : Hello
• Un répertoire pour stocker mon projet (s'il n'existe pas il sera créé en même temps que le projet). Encore une fois soyons original : ~/android_hello
• Le nom de la classe d'Activité par défaut de mon projet. Alors là ça demande une petite explication de texte : d'après ce que j'ai compris en survolant les site parlant d'android une "Activity" serait, en gros, l'équivalent d'un thread. Donc là il me demande plus ou moins le nom de la classe à lancer au démarrage de mon appli. Continuons dans l'originalité : HelloActivity
• Le namespace du package de mon projet, comme en Java. Hop : fr.ozwald.android.hello

Une fois ces éléments décidés, plus qu'à taper la commande magique :

./tools/android create project --target 1 --name Hello --path ~/android_hello --activity HelloActivity --package fr.ozwald.android.hello

Voilà, ça semble avoir marché. En tout cas il m'a créé tout pleins de fichiers dans ~/android_hello (qu'il a créé pour l'occasion) et ne m'a sorti aucun message d'erreur. J'aime quand un plan se déroule sans accroc !

Modifier le squelette de projet

Petit coup d'oeil dans le répertoire ~/android_hello/src/fr/ozwald/android/hello/, on y trouve un fichier Java qui correspond à priori au squelette de ma toute nouvelle application (et qui est le même que celui trouvé dans le tuto officiel avec Eclipse, elle est pas belle la vie ;) ?). Plus qu'à suivre les modifications proposées par le tuto officiel afin d'obtenir le code suivant :

package fr.ozwald.android.hello;

import android.app.Activity;
import android.os.Bundle;
import android.widget.TextView;

public class HelloActivity extends Activity {
   /** Called when the activity is first created. */
   @Override
   public void onCreate(Bundle savedInstanceState) {
       super.onCreate(savedInstanceState);
       TextView tv = new TextView(this);
       tv.setText("Hello, Android");
       setContentView(tv);
   }
}

Normalement ça devrait suffire pour le Hello World.

Compiler le projet

Compilons donc la chose, en mode debug (ce qui simplifie un peu le déploiement en zappant l'étape de signature du jar mais en interdit l'exécution hors des environnement virtuels) cd ~/android_hello && ant debug. Bon...bug. M'étonnes pas venant de Java -_- Il s'emmèle les pinceaux entre les JRE et les JDK que j'ai sur mon poste. Après 5mn à trifouiller je m'en sort avec un petit emerge -uv --oneshot java-config. suivi d'un java-config -S 2 afin de redéfinir ma JAVA_HOME actuelle pour pointer sur l'un des JDK que j'ai, plutôt que sur un JRE. Reprenons : ant debug. Le script semble content puisqu'il me parle de façon polie (i.e. pas de gros "FAIL" et autres "ERRORS") et effectivement dans le répertoire ~/android_hello/bin je trouve bien un Hello-debug.apk⁴. Youpi :) !

Tester l'appli

Plus qu'à installer notre appli sur notre android virtuel, et le tour sera joué. Pour ce faire je redémarre mon AVD et, depuis le répertoire "tools" du SDK android, je lance l'incantation magique qui devrait installer l'appli dessus pendant qu'il fonctionne ./adb install ~/android_hello/bin/Hello-debug.apk. Je regarde à présent dans l'AVD et, miracle, une nouvelle application est là : HelloActivity (bon, pas très joli tout ça, mais on s'en fout pour l'instant). Je la lance...Ca marche :) !

Voilà, finalement ça a presque été facile et ce post ne me servira peut être jamais tellement avoir un trou de mémoire là dessus semble peu probable, mais "sait-on jamais"... Et d'ailleurs pour conclure voici une mini astuce : à la place de compiler (ant debug) puis d'installer (adb install ~/android_hello/bin/Hello-debug.apk), vous pouvez (à condition qu'il n'y ai qu'un AVD en route) remplacer ces deux commandes par un unique ant install qui fera la compilation en debug puis l'installation à la volée. Vachement pratique ^_^ !

1. Le Python est supporté depuis peu via le "Android Scripting Environment" mais, hélas, il ne permet pas (encore ?) de réaliser des applications complètes déployables via le market :( ↩
2. Oui, je ne suis pas le premier, et certainement pas le meilleur auteur, mais comme prévenu : ce billet a pour premier but de me servir d'aide mémoire pour une fois ^_^ ↩
3. Oui je sais : ça ne se voit pas trop ;) ↩
4. apk c'est l'extension des applications pour android...à priori c'est des JAR ;) ↩