Сверлим Bluetooth

Никита Кислицин

Хакер, номер #077, стр. 077-060-2

Следующая команда «Remote_Name_Request» получает имя устройства по известному адресу и используется таким образом:

$ hccontrol -n ubt0hci Remote_Name_Request 00:0a:d9:7f:88:0d

После выполнения запроса на экране появится символическое имя устройства с указанным адресом. Полный список доступных команд можно получить, набрав в консоли man hccontrol, либо обратившись к документации на диске. А мы идем дальше.

[bluetooth пинг-понг]

В bluetooth-стэке есть протокол L2CAP (Logical Link Control and Adaptation Protocol), позволяющий интерфейсам более высокого уровня передавать и получать пакеты данных длиной до 64 Кбайт.

L2CAP использует концепцию так называемых каналов, каждый из которых представляет собой ни что иное, как отдельное логическое соединение поверх радиолинка. Каждый такой канал привязан к некоторому протоколу (один протокол может занимать несколько каналов, но не наоборот), таким образом, что каждый пакет L2CAP, получаемый каналом, перенаправляется к соответствующему протоколу более высокого уровня.

Есть две утилиты, предоставляющих доступ к этому протоколу, первая из которых носит символическое название l2ping. Как несложно догадаться, эта тулза предназначена для проверки связи между устройствами и с виду работает так же, как и icmp ping:

# l2ping –a 00:0a:d9:7f:88:0d

0 bytes from 00:0a:d9:7f:88:0d seq_no=0 time=37.823 ms result=0

...

Но это, конечно, только с виду. Обрати внимание, что многие устройства возвращают в ответ на L2CAP echo request пустые пакеты, так что 0 bytes – это в порядке вещей.

Помимо тестирования связи, у этой утилиты есть еще одно интересное применение – DoS-атаки на синезубые устройства. Подобно icmp-флуду, существует гипотетическая возможность завалить с головой любой bluetooth-девайс L2CAP пакетами с целью прервать активные пользовательские соединения. Как я уже отмечал выше, максимальный размер пакета составляет 65 килобайт и, в общем-то, понятно, что для достижения цели необходимо использовать несколько устройств в режиме максимальной производительности. Так же есть возможность вести “обстрел” в несколько потоков с каждого из доступных устройств. При этом нужно экспериментально определить оптимальную длину пакетов и количество тредов – в своих опытах я пришел к тому, что оптимальнее всего работать в 3-4 потока, именно в этом случае достигается максимум используемой мощности канала.

[крадем записные книги]

Теперь расскажу об одной из самых сладких вещей в этой статье – о краже пользовательской информации из телефонов по bluetooth, так называемом BlueSnarfing’е. Предположим, в людном месте (например, в кафе в центре города), я насканил несколько доступных девайсов. С большой долей вероятности у меня получится украсть пользовательские данные по bluetooth так, что этого не заметят их владельцы. Виной тому – кривая поддержка интерфейса OBEX в ряде телефонов (в том числе, например, в мегапопулярных SonyEricsson t68, t610, t630 и Nokia 6310i).

Однако, прежде, чем начинать бизонить, не лишним будет разобраться, что такое OBEX и как осуществлена его поддержка во FreeBSD. Протокол Object Exchange – популярная фишка, используемая для простой передачи файлов между портативными устройствами. Например, если нужно без геморроя передать с одного телефона на другой несколько контактов, или ежедневник – то всегда юзают OBEX, это очень удобно. Сервер и OBEX-клиент реализованы во FreeBSD в виде пакета obexapp, который наколбасил уже знакомый нам Макс и его даже включили в список портов — comms/obexapp. Устанавливать тулзу проще всего именно оттуда, если не хочется геморроя со всеми зависимостями и прочей ботвой. Если же ты не ищешь легких путей – забирай с диска сорцы и собирай руками, а мы пока научимся пользоваться тулзой. Делается это просто: