Background

Volatilitux is a Python framework that helps extracting digital artifacts from raw physical memory (RAM) dumps of Linux systems. The goal of this tool is to offer a tool in a field that cruelly lacks of tools. It is mainly inspired by the SSTIC 2010 challenge whose purpose was to analyze the physical memory of an Android phone. When the challenge got released, the only suitable tool that existed was draugr; however it required two lines to be patched in order to be able to analyze the file.

I tried to solve this challenge but I quickly got stuck at the first step : listing all running processes and extracting the virtual memory map of each one. I learned a lot reading the kernel source code, some blog posts, and finally the challenge solutions when they got released. And I understood the biggest problem of physical memory analysis in Linux: most of kernel structure offsets change depending on the kernel version, configuration and patches. Thus, the first step was to detect all of those offsets. And then, use them to extract and browse all kernel objects.

I first detected those offsets manually by recompiling Android 2.1 kernel (using the NDK), running it into Google’s emulator (provided in the SDK), and then load a LKM in order to display all those offsets. It worked.

Then, I thought: «Since Volatility is a great tool but only supports Windows, why not develop a similar framework that works for Linux RAM dumps?»

I first came up with a version of the tool that required a configuration file containing all the offsets, as well as init_task symbol address and the architecture of the dump. Then, I chose to raise the bar a little higher, and automatically detects those offsets. And here we are…

Features

Here are the main features of the tool:

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

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

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

Of course, since it is a framework, one can extends those features and easily add new architectures, commands, and kernel structures.

It has been tested on physical memory dumps of the folowing Linux distributions:

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

Requirements

Volatilitux requires Python 2.6. It only uses Python builtin modules, and does not rely on any external library.

It has mainly been tested on Windows XP, but it should run on any other platform.

Get the source

You can download and browse the source code of this tool on the Volatilitux Google Code project.

To download it directly:

• volatilitux-1.0.zip

Please read the README.txt file, as it contains information on how to use the tool.

Known bug

Yes, Volatilitux already has a bug . One of the kernel offset is not yet properly detected (actually, it is hardcoded due to lack of time!) for Ubuntu distributions. This will make the memmap command display incorrect information in the « Flag » column. However it should not prevent the other commands to run.

Quick Example

Here is how to use Volatilitux to extract the TextViewer Android application in the SSTIC 2010 challenge. Be sure to download the dump and extract « challv2″ to try it .

$ volatilitux.py -f challv2 pslist
Name                PID       PPID
swapper             0         0
init                1         0
kthreadd            2         0
ksoftirqd/0         3         2
events/0            4         2
khelper             5         2
suspend             6         2
kblockd/0           7         2
cqueue              8         2
kseriod             9         2
kmmcd               10        2
pdflush             11        2
pdflush             12        2
kswapd0             13        2
aio/0               14        2
mtdblockd           21        2
hid_compat          22        2
rpciod/0            23        2
mmcqd               24        2
sh                  25        1
servicemanager      26        1
vold                27        1
debuggerd           28        1
rild                29        1
zygote              30        1
mediaserver         31        1
installd            32        1
keystore            33        1
init.goldfish.s     34        1
qemud               35        1
adbd                37        1
qemu-props          44        34
system_server       52        30
putmethod.latin     96        30
m.android.phone     98        30
d.process.acore     101       30
ndroid.settings     116       30
roid.alarmclock     136       30
d.process.media     147       30
com.android.mms     170       30
m.android.email     183       30
com.svox.pico       207       30
nssi.textviewer     227       30
om.anssi.secret     233       30

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

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

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

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

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

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

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

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

The remaining of the challenge is left as an exercise for the reader .

Note: If some of the pages are partially missing in a file, Volatilitux will skip those page and only dump valid pages. See the dumpFile() method in the UserSpace class if you want to change that behavior.

You will find an example.py file in the root folder. You should read it it if you want to use the framework as a Python module.

Volatilitux Internals

Here are some implementation details.

Automatic detection of kernel structure offsets

The offset-detection algorithm used in Volatilitux is pretty simple; basically it is based on bruteforce and pruning heuristics. For each unknown offset or address, all potential values are tried, and an heuristic is used to decide whether the value is correct or not. Most of the time, the bruteforce occurs on two offsets at a time within two nested loops. The heuristic I use are sometimes pretty simple:

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

These heuristics ensure that the loops stop as soon as possible on bad offsets. The whole algorithm is implemented in core/forensics.py, which is actually the biggest file of the project…

Architecture

Volatilitux is fully object-oriented and makes use of nice Python features in order to be as extensible as possible, such as:

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

Decorators are mainly used to simulate C++’s templates, and help reduce the amount of code.

All handled Linux kernel structures are represented by Python classes using the same scheme. They all inherits from KernelStruct. Here is an example with task_struct:

@unix_name("task_struct")
class Task(KernelStruct):

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

  # More methods...

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

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

Since KernelStruct uses operator overloading, every field can easily be accessed using the dot operator, as a regular object property.

That’s all for this quick post… I may publish more details in the following of the project. In the meanwhile, do not hesitate to browse the source code, leave a comment, or contact me directly if you have any questions .

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

J’éditerai ce billet prochainement pour y ajouter un petit tutorial concernant l’installation et l’utilisation de XeeK.

XeeK is not dead

Ainsi, je travaille activement sur le projet depuis plus d’un mois. J’ai profité de l’expérience de mes collègues pour faire une petit brainstorm sur l’état du projet, et ainsi obtenir de nouvelles idées. Comme certaines de ces idées remettaient en cause la structure mise en place, j’ai préféré reprendre le développement du projet from scratch.

Quoi de neuf depuis 2009 ?

Plusieurs personnes ont développé des outils aux fonctionnalités similaires (Beef, XSS Shell, etc). Plutôt que de réinventer la roue, j’ai préféré m’inspirer de ces outils afin d’intégrer leurs bonnes idées dans la plateforme. Voici quelques unes des nouvelles fonctionnalités prévues pour le moment : (cette liste est susceptible d’évoluer dans les mois à venir)

• L’architecture est désormais de type client – serveur
• Les deux entités communiquent via une API basée sur HTTP/JSON
• Cette architecture permettra de développer de multiples clients, un peu sur le modèle de Metasploit :
  • Interface console
  • Interface Web
  • Interface graphique (applicative)
  • Pourquoi pas une extension Firefox
• Abandon du concept de « scheduler » ; les instructions sont désormais toujours récupérées dynamiquement
• Concept de chaine d’exploits : suite d’instructions qui s’enchaînent
• De nouveaux exploits sont prévus
  • Scan de port du réseau interne
  • Récupération d’historique
  • Proxy

Au niveau technique, ce nouveau XeeK nécessitera PHP >= 5.3.0 (à cause des Late Static Bindings), MySQL ainsi que Python pour l’interface en ligne de commande.

Licence

Ce projet est développé principalement dans le cadre de mon temps R&D chez Sysdream. Il sera diffusé en GPL suite à la conférence que je donnerai à la prochaine Nuit Du Hack. Un SVN ainsi qu’un wiki seront certainement mis en place pour permettre aux intéressés de récupérer les sources ainsi que la documentation.

En attendant le 19 juin, si vous avez des idées / suggestions, n’hésitez pas

GoRing0

GoRing0 est donc un rootkit qui a pour objectif de faire passer un thread en ring 0, et de le rebasculer accessoirement en ring 3 lorsqu’il le souhaite. Pour cela, celui-ci devra bien évidemment charger un driver, afin de s’élever les droits et de permettre une telle commutation. La partie utilisateur du rootkit pourrait se présenter sous la forme d’une librairie exportant deux fonctions principales : GoRing0() et GoRing3(), permettant le basculement en ring 0 et ring 3 respectivement. N’importe quel programme pourrait alors faire appel à ces fonctions et s’élever les droits à volonté. Je développe pour le moment sous Windows, mais idéalement, GoRing0 devrait être capable de fonctionner aussi bien sous sous Linux, la manipulation qu’il effectue étant surtout liée à l’architecture x86.

Le principe de fonctionnement de GoRing0 repose sur les interruptions. Les fonctions GoRing0() et GoRing3() déclenchent une interruption spécifique qui est hookée par le driver et qui se charge de modifier la valeur de CS empilée automatiquement par le processeur. En effet il se trouve que le ring courant du processeur (le CPL) est encodé dans les 2 premiers bits de CS ainsi que dans le descripteur de segment (dans la GDT) auquel il correspond. Plus intéressant encore, Windows définit deux valeurs spéciales de CS : une en userland (0x1b), et une en kernelland (0×8). Il suffit alors au handler d’interruption de substituer la valeur empilée de CS par la valeur kernelland pour passer le thread en ring 0 au retour d’interruption.

Pour le moment, j’ai un prototype fonctionnel stable : j’arrive à passer un thread en ring 0 et à le rebasculer en ring 3. Pour m’en assurer, je peux afficher la mémoire kernel depuis ce thread (adresses supérieures à 0×80000000 sous Windows). Cependant, lorsqu’un thread est en ring 0, il est impossible d’appeler des API Windows car celles-ci vérifient apparamment si le thread qui les appelle vient bien du ring 3. De même, il n’est pas possible d’appeler des fonctions du kernel depuis le thread même en ring 0, à moins d’en connaître l’adresse ou de la résoudre à l’exécution.

Nouvelle conférence à la Nuit Du Hack

Enfin, j’en viens à la véritable news de ce post… Au départ, je devais présenter une conférence sur XeeK et une autre sur InjecSO. Etant donné qu’InjecSO est sorti depuis un moment maintenant (avec la doc sur ce blog), que je me suis lancé dans ce nouveau projet, et que cette année il n’y a pour l’instant aucune conférence orientée kernel, j’ai pensé intéressant de remplacer la conférence sur InjecSO par une sur GoRing0. Je compte y présenter le projet et par la même occasion de présenter rapidement l’architecture x86 et le développement en mode kernel aux débutants en la matière. Ceux pour qui les concepts d’interruption, segments et autre GDT sont du chinois (autrement dit ceux qui n’ont pas compris le paragraphe technique ci-dessus…) sont les bienvenus, je compte justement expliquer tout cela ! Ca sera de plus l’occasion de releaser officiellement GoRing0 et de faire une petite démo. Sur ce, à la NDH !

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.

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 <stdlib.h>
#include <stdio.h>

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/<pid>/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/<pid>/ (<pid> étant le nom du processus en question) contenant plein d’informations. En particulier, le fichier /proc/<pid>/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/<pid>/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, &regs);
  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, &regs);
  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

[EDIT]

Le projet a subit de nombreux changements depuis la publication de ce billet. J’ai publié la première version du projet ici ; en attendant un tutorial vous pouvez retrouver des informations plus à jour dans ce billet. Gardez à l’esprit que les informations qui suivent (et particulièrement le jargon associé à l’outil ainsi que les fonctionnalités) ne sont plus complétement valides…

Le projet

XeeK, pour XSS Easy Exploitation Kernel, est un projet dont l’objectif est le suivant : démontrer la puissance de la XSS en proposant un outil pour exploiter facilement ce type de faille. Les premières idées qui ont engendré ce projet me sont venues cet été, mais c’est uniquement depuis quelques semaines que j’ai vraiment commencé à y travailler.

Un noyau et des modules

Certains me trouveront peut-être un peu ambitieux, mais mon but serait de faire de XeeK une sorte de Metasploit pour la XSS. Pour dire les choses autrement, l’objectif serait de proposer un framework, c’est à dire un ensemble de classes, ou de modules capables d’interagir ensemble. En fait, si le K de XeeK signifie kernel (noyau) c’est parce qu’il sera effectivement composé d’un noyau proposant les fonctionnalités génériques de base et d’une suite de modules qui pourront s’y greffer. Dans l’idéal, ces modules pourront être développés par n’importe qui. A titre de comparaison, considérez le noyau Linux et ses modules, ou bien Firefox et ses extensions.

Architecture

Concrètement, XeeK se composera d’une interface Web déployée sur un serveur appartenant à un attaquant, disons hacker.com. XeeK étant censé faciliter l’exploitation des failles XSS, il appartient à l’attaquant de découvrir ces failles ; je n’envisage pour le moment pas d’intégrer un scanner de ce type dans l’outil. Une fois une XSS trouvée sur un site quelconque, disons victime.com, l’attaquant pourra utiliser l’interface de XeeK afin de générer un exploit personnalisé et paramétrable. Après avoir défini l’exploit, celui-ci pourra être intégré à un lien piégé exploitant la XSS sur victime.com. Il ne restera plus à l’attaquant qu’à faire cliquer la victime sur ce lien…

Dans le jargon XeeK, l’attaquant commencera par créer une session, choisira sa ou ses victimes, et sélectionnera un scheduler, ou ordonnanceur. C’est ce composant qui déterminera comment les actions de l’exploit seront exécutées sur le navigateur de la victime. J’envisage pour le moment deux types de schedulers :

• Statique — toutes les actions de l’exploit seront définies à l’avance et intégrées « en dur » de façon définitive.
• Dynamique — l’exploit chargé sur le navigateur de la victime ne contiendra pas les actions proprement dit, mais un loader qui sera chargé de récupérer les actions sur le serveur XeeK (hacker.com) de façon dynamique et transparente. Ainsi, l’attaquant pourra modifier l’exploit et suivre la progression de la victime en temps réel.

Les actions exécutées chez les victimes seront susceptibles de retourner des résultats qui seront visualisables directement par le biais de l’interface. En fait, XeeK cachera l’aspect technique de l’exploitation et sera conçu pour simplifier au maximum les choses à l’attaquant. Plus précisément, l’attaquant aura devant lui une interface ressemblant à un debugger, à partir de laquelle il lance son exploit, observe sa progression et visualise les résultats. La différence avec un vrai debugger est que cet exploit sera exécuté sur les victimes et non sur sa propre machine…

Une application : BotNet

Puisque XeeK supportera plusieurs sessions en simultanée, chacune supportant elle-même plusieurs victimes, on en arrive à une des applications potentielles de l’outil : faire office de BotNet. Pour ceux qui l’ignorent, un botnet est un réseau de machines zombies contrôlable par un attaquant via un protocole quelconque. Ici, il s’agira de simples requêtes HTTP. La différence avec les « vrais » botnets est qu’ici, le code malveillant s’exécutera uniquement lorsque la victime aura son navigateur d’ouvert sur la page piégée.

Pour aider à la propagation du botnet, la possibilité la plus simple est d’utiliser une XSS permanente, c’est à dire quand l’injection de code est enregistrée en dur sur le site et affecte tous les visiteurs. Ainsi chaque visiteur tombant sur la page piégée rejoindra automatiquement le botnet à son insu et exécutera le même exploit que ses collègues. Tout cela grâce à une malheureuse petite XSS…

Imaginez qu’un site très connu et utilisé par des milliers de visiteurs soit vulnérable à une XSS permanente. Avec XeeK, il devient possible de lancer une attaque de masse contre tous les visiteurs de la page.

Fonctionnalités

Qu’est-ce que XeeK saura faire ? A vrai dire, les fonctionnalités définitives ne sont pas encore décidées (vu que les modules seront extensibles), mais voici un aperçu de ce que j’envisage.

• Furtivité du point de vue du visiteur (le site exploité continue à fonctionner sans problèmes).
• Exécution de code JavaScript arbitraire.
• Envoi de requêtes asynchrones (Ajax) vers le site vulnérable. Une des applications pourraît être d’exploiter des éventuelles failles XSRF (Cross Site Request Forgery).
• Envoi de requêtes asynchrones vers d’autres sites.
• Détournement de formulaire. Exemple : lorsque la victime remplit un des formulaires de la page, tout son contenu est envoyé sur hacker.com de façon transparente.
• Récupération de cookies.
• Récupération du contenu de la page (code HTML vu par la victime).
• Plus généralement, récupération de n’importe quelle variable accessible par JavaScript et DOM.
• Traceur de visiteur. L’exécution de l’exploit continue même si le visiteur change de page, chaque nouvelle page visitée étant loguée et accessible directement par l’attaquant.
• Simulation de clic sur des liens / boutons / n’importe quel élément graphique des pages.
• Fonctionne aussi bien en HTTPS qu’en HTTP ; cela ne change absolument rien.

Technologies

XeeK est pour le moment développé à l’aide de PHP, JavaScript, Ajax et MySQL. Bien entendu, les langages liés tels que CSS et HTML sont également utilisés à foison. Pour ce qui est de la compatibilité des navigateurs, pour être sincère je n’ai encore utilisé que Firefox. Soyons honnête ; je ne suis ni designer ni un pros des subtilités de chaque navigateur. Mais je tiens à préciser qu’avant d’effectuer une release, je ferais mon possible pour au moins que la partie « victime » de l’outil fonctionne sur IE qui est toujours, il faut le rappeler, le navigateur le plus utilisé. Je vise au moins IE7, peut-être IE6 mais il ne faut peut-être pas trop en demander pour une 1ère release

Release

Je sens venir la question « Quand XeeK sera-t-il publié ?« . Je n’ai malheureusement pas encore de réponse pour le moment. XeeK est encore au stade de prototype même si plusieurs fonctionnalités marchent déjà bien. Il me reste à concevoir la partie interface de l’outil, améliorer deux/trois petites choses, tester la partie exploitation sous IE… Comme vous pouvez vous en douter je ne travaille pas sur ce projet à plein temps, j’ai aussi des études. Pour donner une estimation, j’espère pouvoir publier une première release avant 2009. Mais cela ne constitue pas une garantie… En effet, je préfère prendre mon temps pour bien faire les choses, plutôt que de sortir quelque chose de bancal le plus vite possible. Au pire, je sortirais une alpha ou béta avant sa vraie sortie.

XeeK sera publié sous license GPL (2 ou 3). En d’autres termes, n’importe qui pourra utiliser, développer et améliorer l’outil à condition qu’il publie ses travaux également sous GPL.

Click and hack

Certains me reprocheront peut-être :

Tu n’as pas honte, de mettre à disposition des scripts kiddies un outil aussi dangereux, où il suffit de cliquer pour pirater ?

Je leur répondrai tout simplement non pour plusieurs raisons :

• Il existe des outils similaires encore lus puissants et plus simples à utiliser. Exemple : Metasploit. Personne ne se plaint de cet outil (enfin pas à ma connaissance) alors qu’il permet de rooter une machine sans aucune connaissance technique. C’est un outil utilisé par des professionnel pour le penetration testing.
• Cet outil n’est pas plus « dangereux » que les possibilités offertes par la faille XSS. Il essaye juste d’utiliser ces possibilités au maximum.
• En sortant cet outil et en le faisant connaître, j’espère faire prendre conscience à plus d’un que les failles XSS sont vraiment dangereuses, ce qui semble ne vraiment pas encore être le cas.

Sur ce, je crois que j’ai tout dit… Je vais continuer le développement de ce projet en espérant ne pas mettre trop de temps à le publier. Si vous avez des questions ou suggestions, les commentaires sont là pour ça !

Pour concevoir une application parallèle, on utilise assez souvent la programmation par messages. Dans le cadre de notre projet, nous utilisons la bibliothèque LAM/MPI qui fournit toute une API permettant d’envoyer des messages à des processus tournant sur des machines distantes. De plus, le but étant d’injecter des fautes, nous avons choisit de provoquer ces fautes lors des envois et réceptions de messages. Ainsi nous pouvons facilement simuler aussi bien les pannes logicielles (déni de service) et matérielles (coupure de lien d’un réseau, paquet perdu ou corrompu). Pour détourner les fonctions fournies par la bibliothèque LAM/MPI, nous utilisons la variable d’environnement LD_PRELOAD. Cette variable des systèmes UNIX/Linux permet de charger dynamiquement une bibliothèque au lancement d’une application. Le point intéressant est que cette bibliothèque peut redéfinir des fonctions qui existent déjà dans les autres bibliothèques, donc peut potentiellement les appeler tout en modifiant leur comportement.

LD_PRELOAD permet alors de modifier le comportement d’une application tout en n’ayant pas besoin de la recompiler ! Il est toutefois important de préciser que cette technique ne permet de détourner (hooker) que les fonctions définies dans des librairies dynamiques. C’est un point crucial et qui nous a posé quelques problèmes. En effet nous utilisions au départ la librairie MPICH 1, et il se trouve que lorsqu’une application est compilée avec, les appels MPI sont liés de manière statique. Un simple appel à la commande ldd permet de le voir. C’est pourquoi nous avons choisis d’utiliser LAM/MPI à la place.

Ainsi, nous avons développé une bibliothèque dynamique (fichier .so) dont le but est de venir d’interposer entre l’application parallèle et LAM/MPI. Cette bibliothèque (que nous avons nommé bibliothèque d’interposition) redéfinit les fonctions MPI_Send() et MPI_Recv() en injectant des fautes comme des corruptions de données et des dénis de service. Les fautes ne sont pas générées de manière permanentes ; nous utilisons en plus un processus qui tourne en tâche de fond (démon) qui communique avec la librairie par l’intermédiaire d’un segment de mémoire partagé. Ce démon est en réalité un serveur utilisant CORBA. Son rôle est de rester en attente de requêtes et de dialoguer avec la librairie pour déclencher l’injection de fautes. Il surveille également l’application ainsi que le système par l’intermédiaire de sondes logicielles afin de suivre en temps réel les valeurs de quelques variables, comme la charge CPU, l’occupation mémoire, etc. Ces valeurs sont sauvegardées dans une base de données pour être retraitées plus tard par un module de statistiques.

Sur chaque machine tournent donc : une instance de l’application distribuée, une instance de la bibliothèque d’interposition, et une instance du démon. Mais en plus de tout cela, il faut être capable de déployer l’application parallèle. Nous avons donc conçu un module dédié à cela, le simulateur. Il est contrôlable en ligne de commande ou via une interface graphique. Son but est de lancer l’application parallèle, les démons et activer le détournement de fonction en exportant la variable LD_PRELOAD sur toutes les machines.

Ce projet, bien que relativement complexe, se révèle très intéressant. Cela nous a permis de découvrir et d’utiliser des libraires et des technologies très utiles, comme CORBA, MPI, Boost, MySQL++. Nous utilisons également Flex et Bison pour la conception de l’interpréteur de commandes du simulateur.

Au fut et à mesure du développement, je mettrai sans doute en ligne quelques billets exposant de façon plus détaillée la conception de certains des modules.

Avec un ami, nous avons eu une idée commune : tant qu’à faire une application de simulation, autant se faire plaisir et la réaliser en 3D. Fans des technologies libres, nous avons donc choisi OpenGL et Glut. Nous avions tous les deux une petite expérience en OpenGL, pour ma part ce fut mon deuxième projet C++/OpenGL, bien que je trouve bien plus complexe que le 1er. Étant donné que nous n’avions pas des talents d’artistes, nous avons choisi de faire simple pour ce qui était de la représentation du monde et des individus. Les adeptes de Glut ou plus généralement de la 3D connaissent probablement la fameuse Théière de l’Utah utilisée dans un certain nombre d’applications 3D. Ce modèle étant déjà présent par défaut dans la bibliothèque GLUT, nous avons décidé de l’utiliser pour représenter les individus de nos colonies. Et nous en avons profité pour baptiser notre projet «Teapot Colony Wars».

Nous avions le choix du langage, et nous avons choisi le C++ non seulement pour sa rapidité, sa portabilité, mais aussi parce que nous souhaitions progresser dans ce domaine. Et tant qu’à faire, nous l’avons développé dans le but de le diffuser sous licence GPL 2, pour qu’il continue à vivre et évoluer si certains veulent le reprendre. De plus, nous avons vraiment eu la volonté de développer un projet en nous rapprochant du monde professionnel, tout en n’utilisant que des logiciels libres. Nous avons utilisé Subversion, un excellent outil de gestion de versions qui nous a bien simplifié la tâche pour le développement, ainsi que Doxygen, pour la génération de la documentation. Le rapport de conception a été réalisé en LaTeX, et la compilation de l’exécutable a été grandement facilité par l’emploi des Autotools (AutoConf, AutoMake, …).

Au final, Teapot Colony Wars, c’est :

• 96 fichiers sources (uniquement les .h et .cpp)
• Un diagramme de 45 classes
• Plus de 9600 lignes de code C++
• Un délai de 6 semaines pour réaliser le projet (pendant lesquelles nous avons eu des examens…)
• Plus de 280 heures de travail
• 268 révisions dans le dépot Subversion
• Une documentation PDF de 449 pages générée par Doxygen
• Un rapport de 28 pages décrivant la modélisation et nos choix conceptuels

Nous avons profité de la livraison du projet pour publier la version 1 sur Sourceforge.net. Voici quelques unes des caractéristiques de l’application :

• Le monde est composé de plusieurs colonies, chacune ayant sa couleur.
• Chaque colonie peut créer des individus qui possèdent des caractéristiques propres comme sa taille. Une colonie consomme de la nourriture pour créer un individu.
• Le monde est composé d’une grille de cellules qui ont chacune des propriétés. Certaines sont inaccessibles (murs), d’autres contiennent de la nourriture qui se renouvelle au fur et à mesure de la simulation (certaines sont à renouvellement instantané, mais pas d’autres). Certaines cases sont des couloirs et inaccessibles aux individus trop grands.
• Les individus évoluent selon certaines stratégies comportementales que la colonie leur impose. Leur but est de trouver de la nourriture et de la ramener à la colonie. Mais à chaque pas, un individu consomme de la nourriture proportionnellement à sa taille.
• Chaque individu ne peut voir que les 8 cases adjacentes et a une très petite mémoire : il ne peut se souvenir que de la dernière case qu’il a franchie. Mais pour l’aider, il peut déposer des phéromones sur son passage. Chaque colonie définit ainsi 3 phéromones qui ne peuvent être comprises que par ses individus. Chaque phéromone a une durée de vie et se dégrade au fur et à mesure, jusqu’à disparaître.
• Quand deux individus ennemis se croisent, il y a combat. C’est le plus fort qui gagne ! Le vainqueur peut alors se nourrir du cadavre de ses adversaires.
• L’utilisateur peut à sa guise faire une offrande en déposant une source de nourriture sur le terrain.
• Il était demandé de tester deux stratégies différentes pour les individus. Les algorithmes heuristiques, qui peuvent être simples mais souvent imparfaits, et les algorithmes génétiques, consistant à définir des gènes pour les individus et effectuer un brassage génétique de la population en sélectionnant les meilleurs.

Les commandes souris et clavier du simulateur sont les suivantes :

• Pavé numérique (4, 6 8, 2) : déplacements horizontaux et verticaux
• Molette ou touches + et – : zoom
• Maintien de Ctrl et défilement de la molette (ou + et -) : inclinaison verticale
• Maintien de Ctrl + Clic gauche ou droit : rotation à gauche ou à droite
• Espace : Activer / enlever le mode pause
• Clic gauche : effectuer une itération
• Étoile (*) : donner une offrande aux individus, qui apparaîtra sur le curseur de sélection (tore en bleu clair)

Nous sommes globalement très satisfaits de ce projet, car nous avons pu finir dans les temps, même si nous aurions aimé rajouter quelques fonctionnalités supplémentaires. Mais cela restera tout à fait possible étant donné la grande extensibilité de notre application. En effet, grâce à un usage intensif de toutes les techniques propres à la modélisation orientée objet, comme le polymorphisme et les designs patterns, nous avons construit un ensemble de classes génériques, qui peuvent s’apparenter à un framework. Il est ainsi tout à fait possible de rajouter à moindre coût des nouvelles cases, des nouveaux types d’individus, changer leur représentation (pour ceux qui n’aiment pas les théières…), changer le système de combat, et même pourquoi pas rajouter de nouveaux mouvements (comme le saut ou la téléportation).

Si cela vous intéresse, vous pouvez télécharger la version 1.0 du projet, tel que nous l’avons rendu à nous professeurs. Les sources sont disponibles, ainsi que les exécutables pour Linux et Windows. Attention toutefois pour ce dernier, il semble que la portabilité soit encore un tout petit peu imparfaite ; en effet nous n’avons pas encore eu le temps de changer quelques détails qui peuvent bloquer la génération de l’exécutable selon le compilateur utilisé. Mais nous allons bientôt remédier à cela…

Voici les liens pour accéder aux ressources du projet :

• Site du projet sur Sourceforge.net
• La page de téléchargement
• Le dépot SVN accessible en ligne
• Les détails pour effectuer un check-out du SVN
• La documentation HTML en ligne

Pour lancer l’application sous Windows, vous avez juste à lancer l’exécutable. Sous Linux, pensez toutefois à lancer l’application en mode console pour éviter les surprises ; en effet, il faut que le dossier de textures se trouve dans le dossier courant.

Pour compiler le projet sous Linux, assurez-vous de disposer des bibliothèques pour le développement d’application graphiques, en particulier Glut. Décompressez l’archive dans un répertoire, puis tapez les instructions suivantes :

$ ./configure --prefix=$HOME

$ make

$ make install

L’application s’installera automatiquement dans votre homedir, dans le dossier bin. Si la documentation vous tente, vous pouvez générer le HTML et les fichiers LaTeX en tapant :

$ doxygen Doxyfile

Ensuite, placez-vous dans le dossier doc/latex et tapez simplement :

$ make

Le PDF résultat se nomme «refman.pdf» et sera généré dans le dossier courant. Bonne lecture…

Un site internet du projet verra peut-être le jour au courant de l’année, si je trouve un peu de temps à y consacrer. N’hésitez pas à me faire part de tous vos commentaires sur ce projet. Profitez de sa licence et faites le vivre !