Ambiente di Apprendimento per Exim RCE (CVE-2018-6789)

Descrizione

Questo è un insieme di file, script, appunti, ... per configurare un ambiente in cui investigare la vulnerabilità RCE di Exim (CVE-2018-6789). Può essere utilizzato per eseguire il debug di Exim, scrivere exploit, tracciare le chiamate alle funzioni di Exim, imparare la gestione personalizzata della memoria di Exim (storeblocks), scoprire come funziona un exploit reale, ...

Dovrebbe essere utilizzato solo per scopi accademici!

Requisiti

Vagrant con libvirt/KVM (il plugin vagrant-libvirt)
Docker (solo se decidi di eseguire Docker sulla tua macchina host e non all'interno della VM Vagrant)

Configurazione

Scarica il codice sorgente di Exim eseguendo

$ git submodule update --init

VM

Nella directory principale è presente un Vagrantfile. Utilizza libvirt come provider di virtualizzazione. La box viene scaricata direttamente dal mirror di Fedora tramite box_url perché i download da Vagrant Cloud sono attualmente interrotti (migrazione HCP); Fedora pubblica solo box libvirt e VirtualBox su di esso (nessun VMware), e un box_url diretto è specifico del provider, quindi questa configurazione è mirata solo 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

Puoi modificare la configurazione come preferisci, ma tieni presente che, ad esempio, lo script setup_vm.sh utilizza dnf per installare i pacchetti. Se vuoi usare Ubuntu, devi sostituire le righe dnf install con apt-get install e adattare i nomi dei pacchetti di conseguenza. Tuttavia, non vi è garanzia che la configurazione funzioni correttamente.

Quando sei soddisfatto della tua configurazione, esegui semplicemente:

$ vagrant up

per configurare la macchina e successivamente

$ vagrant ssh

per connetterti. Se non sai come usare Vagrant, dai un'occhiata qui: https://www.vagrantup.com/intro/getting-started/

Container Docker

Vagrant mappa la directory corrente (cioè il repository che hai appena clonato) come directory condivisa su /vagrant. Per creare ed eseguire l'immagine Docker per Exim, inserisci i seguenti comandi all'interno della tua VM (vagrant ssh)

[vagrant@localhost ~]$ cd /vagrant
[vagrant@localhost vagrant]$ ./scripts/reset_docker.sh

La prima volta ci vorrà molto più tempo perché Exim verrà compilato dal sorgente. Se modifichi script di debug o altri file che verranno copiati nel container Docker, puoi sempre usare ./scripts/reset_docker.sh per ricostruire l'immagine Docker. Ovviamente, puoi anche estrarre le righe necessarie dallo script ed eseguirle come comandi singoli.

Quando tutto è finito, dovresti vedere una console di root:

Successfully tagged exim:latest
787f310ef922a1e519cf8bb47f1c4fed5f510da705e7ceefd48f160c980e969c
root@787f310ef922:/opt#

Le strane stringhe potrebbero apparire diverse sulla tua macchina, ma ora ti trovi in un container Docker Debian in esecuzione in una VM Fedora sulla tua macchina host.

Utilizzo della VM e del container

Innanzitutto, puoi creare due sessioni SSH con vagrant ssh in due finestre di terminale. Una può essere utilizzata per eseguire exploit e interagire con Exim tramite SMTP. L'altra viene utilizzata per avviare, eseguire, eseguire il debug, ... di Exim all'interno del container Docker. ASLR è disabilitato nella VM, quindi puoi impostare breakpoint affidabili che non cambiano durante le sessioni di debug.

Esempio di sessione:

Primo terminale:

$ vagrant ssh
[vagrant@localhost vagrant]$

Secondo terminale:

$ vagrant ssh
[vagrant@localhost vagrant]$ cd /vagrant
[vagrant@localhost vagrant]$ ./scripts/reset_docker.sh
...
# ora sei all'interno del container Debian Docker
root@99296cf63016:/opt# ./run_exim.sh
root@99296cf63016:/opt# ./attach_exim.sh

Lo script run_exim.sh termina ed Exim rimane in esecuzione in background. Lo script ./attach_exim.sh dovrebbe collegare gdb al processo demone di Exim in esecuzione e fornire un output come questo:

...
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 è in esecuzione e in attesa di richieste. I breakpoint impostati provengono dal file debugging/breakpoints. Puoi usare Ctrl+C per interrompere il processo e dare il controllo a gdb. Potresti anche eseguire uno degli script di exploit forniti per testare se tutto funziona come previsto: