
Este repositorio proporciona un entorno de aprendizaje para entender cómo funciona un exploit de RCE en Exim para CVE-2018-6789.
Este es un conjunto de archivos, scripts, notas, ... para configurar un entorno en el que investigar el RCE de Exim (CVE-2018-6789). Puede utilizarse para depurar Exim, escribir exploits, rastrear llamadas a funciones de Exim, aprender sobre la gestión de memoria personalizada de Exim (storeblocks), descubrir cómo funciona un exploit del mundo real, ...
¡Solo debe utilizarse con fines académicos!
vagrant-libvirt)Descarga el código fuente de Exim ejecutando
$ git submodule update --init
Hay un Vagrantfile en el directorio raíz. Utiliza libvirt como proveedor de virtualización. La box se descarga directamente del mirror de Fedora mediante box_url porque las descargas de Vagrant Cloud están actualmente rotas (migración a HCP); Fedora solo publica boxes de libvirt y VirtualBox allí (no de VMware), y un box_url directo es específico del proveedor, por lo que esta configuración está dirigida únicamente a libvirt.
# -*- mode: ruby -*-
# vi: set ft=ruby :
memory = 8192 # in MiB
cpus = 4
Vagrant.configure("2") do |config|
# Vagrant Cloud downloads are broken; pull the box from Fedora's mirror
config.vm.box = "fedora-44-cloud-base"
config.vm.box_url = "https://download.fedoraproject.org/pub/fedora/linux/releases/44/Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-libvirt-44-1.7.x86_64.vagrant.libvirt.box"
config.vm.provider "libvirt" do |lv|
lv.memory = memory
lv.cpus = cpus
end
config.vm.provision "shell", inline: <<-SHELL
/vagrant/scripts/setup_vm.sh
SHELL
end
Puedes cambiar la configuración como quieras, pero ten en cuenta que, por ejemplo, el script setup_vm.sh utiliza dnf para instalar paquetes. Si quieres usar Ubuntu debes reemplazar las líneas dnf install por apt-get install y ajustar los nombres de los paquetes en consecuencia. Sin embargo, no hay garantía de que la configuración funcione correctamente.
Cuando estés satisfecho con tu configuración, simplemente ejecuta:
$ vagrant up
para preparar la máquina y, después:
$ vagrant ssh
para conectarte a ella. Si no sabes cómo usar Vagrant, échale un vistazo aquí: https://www.vagrantup.com/intro/getting-started/
Vagrant mapea el directorio actual (es decir, el repositorio que acabas de clonar) como un directorio compartido en /vagrant. Para crear y ejecutar la imagen Docker de Exim introduce los siguientes comandos dentro de tu VM (vagrant ssh)
[vagrant@localhost ~]$ cd /vagrant
[vagrant@localhost vagrant]$ ./scripts/reset_docker.sh
La primera vez tardará mucho más porque Exim se compilará desde el código fuente. Si modificas scripts de depuración u otros archivos que se copiarán dentro del contenedor Docker, siempre puedes usar ./scripts/reset_docker.sh para reconstruir la imagen Docker. Por supuesto, también puedes extraer las líneas necesarias del script y ejecutarlas como comandos individuales.
Cuando todo esté listo deberías ver una consola de root:
Successfully tagged exim:latest
787f310ef922a1e519cf8bb47f1c4fed5f510da705e7ceefd48f160c980e969c
root@787f310ef922:/opt#
Las cadenas extrañas pueden verse diferentes en tu máquina, pero ahora estás dentro de un contenedor Docker de Debian ejecutándose en una VM de Fedora sobre tu máquina anfitriona.
Primero, puedes crear dos sesiones SSH con vagrant ssh en dos ventanas de terminal. Una se puede usar para ejecutar exploits e interactuar con Exim a través de SMTP. La otra se usa para iniciar, ejecutar, depurar, ... Exim dentro del contenedor Docker. ASLR está deshabilitado en la VM, por lo que puedes establecer breakpoints fiables que no cambien durante las sesiones de depuración.
Ejemplo de sesión:
Primer terminal:
$ vagrant ssh
[vagrant@localhost vagrant]$
Segundo terminal:
$ vagrant ssh
[vagrant@localhost vagrant]$ cd /vagrant
[vagrant@localhost vagrant]$ ./scripts/reset_docker.sh
...
# now you are inside the Debian Docker container
root@99296cf63016:/opt# ./run_exim.sh
root@99296cf63016:/opt# ./attach_exim.sh
El script run_exim.sh termina y Exim se ejecuta en segundo plano. El script ./attach_exim.sh debería adjuntar gdb al proceso demonio de Exim en ejecución y mostrarte una salida como esta:
...
pwndbg: loaded 170 commands. Type pwndbg [filter] for a list.
pwndbg: created $rebase, $ida gdb functions (can be used with print/break)
Attaching to process 14
Reading symbols from /usr/exim/bin/exim-4.89_1-1-fc6d6586-XX-1...done.
...
0x00007ffff6b7f5e3 in __select_nocancel () at ../sysdeps/unix/syscall-template.S:84
84 ../sysdeps/unix/syscall-template.S: No such file or directory.
Breakpoint 1 at 0x5555555c03d2: file smtp_in.c, line 1762.
Breakpoint 2 at 0x5555555c051d: file smtp_in.c, line 1884.
Breakpoint 3 at 0x55555556a2c8: file base64.c, line 154.
Breakpoint 4 at 0x5555555c6aca: file smtp_in.c, line 3690.
Exim está en ejecución y esperando peticiones. Los breakpoints que se han establecido provienen del archivo debugging/breakpoints. Puedes usar Ctrl+C para interrumpir el proceso y dar el control a gdb. También podrías ejecutar uno de los scripts de exploit proporcionados para comprobar si todo funciona como se espera:
Primer terminal:
[vagrant@localhost ~]$ cd /vagrant/sploits/
[vagrant@localhost sploits]$ ./sploit_0.py
[+] Opening connection to localhost on port 25: Done
Segundo terminal: