Ну и как мне теперь слушать Bluetooth-наушники в метро?
Пользователи Android должны дождаться исправлений безопасности для своих устройств, так как это зависит от производителя конкретного устройства. Пока можно установить приложение «BlueBorne Vulnerability Scanner» (созданное командой Armis) из Google Play Store, чтобы проверить, уязвимы ли ваши устройства для атаки BlueBorne или нет.
Я вас понял
image
Пока можно установить приложение «BlueBorne Vulnerability Scanner» (созданное командой Armis) из Google Play Store, чтобы проверить, уязвимы ли ваши устройства для атаки BlueBorne или нет.

При полностью выключенном (а не скрытом от всех) блютусе программа говорит, что устройство уязвимо. Отличнo.
Каким конкретно способом программа проверяет устройство найти, увы, не удалось… Вполне вероятно, что для проверки текущего устройства включенный блютуз и не нужен, не будет же устройство само к себе подключатся) Вполне возможно, что достаточно просто выполнить несколько функций из загруженных библиотек, или же подключиться к уязвимым сервисам локально. А вот для тестирования удалённых устройств — блютуз вполне себе включается самой программой.
Ну да. Наверно, программа проверяет, установлено ли ПО с уязвимостями, а не включено ли оно. А то кто знает — вдруг в момент проверки что-то выключено, ты скажешь человеку «всё ок», а он потом запустит прогу — и привет.
Все намного проще, для устройства на котором приложение установлено, просто проверяется Build.VERSION.SECURITY_PATCH, если он до 1 августа, тогда уязвим.
Вообще все приложение — красивые анимашки, а в код посморишь, там 1 класс на всю логику(com.armis.blueborne_detector.VulnerabilityUtils).
Для проверки устройств по близости, приложение по маку устанавливает производителя, ось и название устройства, на основе этих данных градирует устройста на 3 категории.
Ага, дождёшься их, как же. У меня сейчас Samsung S4 и он меня вполне устраивает. Там есть такие прикольные штуки, как термометр и гигрометр. Но я сильно сомневаюсь, что Samsung выпустит патч для аппарата, отстающего на четыре поколения.
Такой вопрос: а если «Режим модема» у меня выключен в настройках, BNEP и PAN же должны быть отключены, и RCE невозможно, только менее опасные уязвимости. Или всё-таки нет?

Ну и какая утечка через наушники(на которые не будет обновлений)? Замена передаваемого трафика на свой: сигнал на динамики, сигнал с микрофона?

Процитирую Википедию
Внедрение кода в атаке «человек посередине» главным образом применяется для захвата уже авторизованной сессии, выполнения собственных команд на сервере и отправки ложных ответов клиенту.
Атака «человек посередине» позволяет криптоаналитику вставлять свой код в электронные письма, SQL-выражения и веб-страницы (то есть позволяет осуществлять SQL-инъекции, HTML/script-инъекции или XSS-атаки), и даже модифицировать загружаемые пользователем бинарные файлы для того, чтобы получить доступ к учетной записи пользователя или изменить поведение программы, загруженной пользователем из интернета.
Нормальные люди не запускают бинарные файлы, которые пришли по блютусу с наушников.
Вчитайтесь в статью. Там идёт эксплуатация уязвимости, чтение памяти побитово, и похищение ключей. Всё остальное — дело техники. Посмотрите ролик, там даже музыка не включена, не то что «запуск принимаемых файлов»… похоже вы вообще не поняли всю серьезность проблемы.
С моей стороны это был сарказм.
У меня часы, уже вторые, с функцией смарт. Соединяются по BT с телефоном. Получается, включать BT нужно дома… (только если нет злоумышленника за стеной ))) Тогда все смартфункции часов идут лесом… Мдя…
Итак, в чём проблема? Bluetooth сложный.
Проблема-то очевидна, но решение её «не продаваемое».
Как только авторучку вы подключите к интернету, тут же у юристов прибавится работы с легитимностью подписей и утечкой кофиденциальной рукописной информации. Выход один — не подключать авторучку к интернету, но разве маркетологи на это пойдут?!
Решение уязвимости блютуза прибавит еще тысчонку страниц в его спецификации, и все на голубом глазу будут думать, что это уменьшит уязвимость…

Только идиоты делают одно и то же, всякий раз надеясь на другой результат. Если не ошибаюсь, слова приписывают Эйнштейну. Могучий старик.
Только идиоты делают одно и то же, всякий раз надеясь на другой результат.

Человек набирает один и тот же номер и получает короткие гудки.
Идиот! Там всегда будет занято.


Я, конечно, понимаю, что имелось ввиду, но что сказано (или написано), то и имеем.
И это общая проблема подобных громких абсолютных фраз

Во-первых,
> Безумие — это точное повторение одного и того же действия. Раз за разом, в надежде на изменение. Это есть безумие.

Во-вторых, не важно всегда ли будет занято. Лучше найти другой номер.

Полагаю, достаточно стандартной является ситуация ожидания события, когда понять факт наступления события позволяет только выполнение некоторой процедуры проверки.
Ожидание освобождения абонента путем периодического набора его номера — только один из вариантов этой ситуации (я знаю о существовании телефонов с автоматическим дозвоном, но случаи бывают разные).

Раз уж вы в формализм хотите уйти… у вас в тексте «ожидание», а в цитате «надежда». Ну и «периодически» и «раз за разом» — тоже разные вещи.

Надежда — это про всего лишь про отсутствие гарантий ожидаемого.
В примере с дозвоном пациент каждый раз надеется, что именно в этот раз поведение системы наконец изменится. При этом необходимость дозвониться до данного конкретного абонента заставляет набирать номер раз за разом несмотря на ненулевую вероятность полной невозможности дозвониться (например, абонент забыл положить трубку и неизвестно, когда заметит этот факт и заметит ли вообще).


"Периодически" и "раз за разом" на самом деле не так уж и далеко друг от друга.
Если совсем уж формально, то "периодически" — это "раз за разом с некоторым интервалом между событиями". Но в реальной жизни слово "периодически" не всегда означает наличие определенного периода, а потому можно считать, что смысл достаточно близок.

> Надежда — это про всего лишь про отсутствие гарантий ожидаемого.

Надежда — это при отсутствии объективных причин ожидать «ожидаемого».

> заставляет набирать номер раз за разом несмотря на ненулевую вероятность полной невозможности дозвониться

Мне кажется тут уместен только один вопрос: на которой итерации забирать в психушку?

При отсутствии объективных причин (за объективную причину вполне проходит отличная от нуля вероятность) мы имеем безнадежную ситуацию.
А насчет психушки после некоторого числа итераций (количество допустимых итераций определяется ситуацией) согласен. Раз за разом не означает бесконечное число попыток, а потому не вижу противоречий со своей позицией.

Эйнштейн просто компы не застал. 90% проблем так и чинятся.
Что насчёт симбиана, байду и прочих? Для них нет рабочих эксплоитов?
Каким образом хакер перенаправит трафик через «злонамеренный интерфейс», если в устройстве, например, просто нет возможности расшарить интернет по BT? Или вовсе не реализовано PAN.

Естественно, что наибольшему риску взлома подлежат наиболее интересные с точки зрения хакера устройства, а не все подряд. Вряд ли кто будет специально ковырять байду ради сферической возможности взломать байду. Главное, что принципиально показан метод, а уж степень риска каждый определяет для себя сам.

У владельцев iOS устройств как я понял проблем уже нет

Судя по статье, уязвимость LEAP не закрыта.
Armis раскрыл Apple сведения об этой атаке. Эксплойт был устранён в версии IOS 10 и версии Apple TV выше 7.2.2, однако эта уязвимость по-прежнему представляет большой риск для любого iOS-устройства до версии 10. Уязвимость может быть использована злоумышленником для выполнения кода с повышенными привилегиями.


то есть это нельзя понимать однозначно?
Похоже, невнимательно прочёл.

С iOS 10 нет. Более старые версии подвержены.

по поводу LEAP не беспокоюсь это для владельцев AirPods и AppleTV
Как я понимаю iPhone как раз уязвим. Только из описания непонятно должен ли быть атакущий аутентифицирован.

На следующей неделе выйдет иос11 и я уверен что там уже заплатка будет

Уже исправлено в iOS 10, а для старья (2011 года выпуска) обещают патч на 9.3.5.
> Итак, в чём проблема? Bluetooth сложный.

Проблема с тем же buffer overflow это несовершенство инструментов, а не просто сложность спецификации. Какой бы сложной спецификация не была, программа не должна позволять buffer overflow. Для этого есть rust например. Но йожики будут продолжать писать на C/C++ ведь на C/C++ пишут все. Как впрочем никто не будет ломать обратную совместимость чтобы сделать язык более статически анализируемым.
Bluetooth сложный

То, что BT сложный заметно на практике, т.к. перебирая разные комбинации телефонов и BT-гарнитур у меня ни одна из них не работала на 100% без проблем. То здесь, то там всплывали разные косяки. То долгое подключение, то заикания звука, то какие-то странные подвисания.
Видимо дело в смартфоне. Имею 6S и сколько гарнитур/наушников перепробовал, всё хорошо было. Из последнего даже дешманский китайский блютус адаптер в машине работал. Когда был Nexus во владении, тоже никаких косяков не было. Так что проблема явно не с гарнитурами.
Проблема не в языке. Как уже не раз обсуждали в тойже теме heartbleed, что rust не панацея.
Небезопасный код можно написать на любом языке.
Можно. Но есть языки которые страхуют от этого, а есть те которые «поощряют» это.
Компания Microsoft выпустила обновления для системы безопасности в июле.

Может кто-нибудь подсказать конкретные номера обновлений?
Так и называется «июльский пакет обновления», но его уже заменил октябрьский.
а для 7 и хр?
Я поспешил с месяцем, во вторник вышел сентбярьский пакет для 7 и выше.
еще бы для хр ибо есть пара устройств с ней (выше никак по ресурсам ибо проц т7200 и 2гб озу)
Спасибо что предупредили, а то я как раз задумался о покупки bluetooth гарнитуры. Теперь не стану покупать.
Есть ещё такая статья, старше на 9 минут.
Microsoft – Contacted on April 19, 2
Microsoft – Contacted on April 19, 2017 after which details were shared. Updates were made on July 11. Public disclosure on September 12, 2017 as part of coordinated disclosure.
[...]
Linux – Contacted August 15 and 17, 2017. On September 5, 2017, we connected and provided the necessary information to the the Linux kernel security team and to the Linux distributions security contact list and conversations followed from there. Targeting updates for on or about September 12, 2017 for coordinated disclosure.
017 after which details were shared. Updates were made on July 11. Public disclosure on September 12, 2017 as part of coordinated disclosure.
[...]
Linux – Contacted August 15 and 17, 2017. On September 5, 2017, we connected and provided the necessary information to the the Linux kernel security team and to the Linux distributions security contact list and conversations followed from there. Targeting updates for on or about September 12, 2017 for coordinated disclosure.

MS получили детали 9 Апреля, и чинили 3 месяца, Linux получили детали 5 Сентября, и пофиксили за 4 дня (патч: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e860d2c904d1a9f38a24eb44c9f34b8f915a6ea3)

Там ошибка с переполнением происходит в момент сериализации каких то блютузных структур в буфер для отправки. Так вот размер буфера выделяется где то вначале процедуры сериализации либо 64 либо 128 байт (как я глянул в коде) потом происходит его наполнение разными данными, которые являются разными структурами, через if/else и switch/case, соответсвенно заранее спрогнозировать нужный размер буфера не возможно и получаем потенциальную возможность выхода за пределы массива.
В патче теперь добавили проверку при каждой записи в этот буфер на переполнение и соответсвенно теперь по всему коду передается не только указатель но дополнительным аргуметом размер. Это является самым удобным представлением массива по мнению сишников.
Вполне возможно стандарт синего зуба предполагает фиксированный размер пакета, но доказать то что любая комбинация тех самых if/else и switch/case выдает на выходе меньше чем N байт никто не удосужился, потому что цитата "протокол bluetooth сложный". А оказывается что ребята из armis придумали как подобрать такие параметры запроса чтобы "инвариант" нарушился.


P.S. я не специальист по ядру и тем более блютузу так что все выше изложенное сказано на правах дилетанта

Если я правильно понял описание атаки, то для ее инициации надо знать bluetooth адрес атакуемого устройства. Если оно не находится в режиме обнаружения — то узнать его может быть не так уж и просто. Хорошо, если он совпадает с WiFi MAC адресом (так бывает), тогда будучи в одной сети можно получить его методом сканиварония. Если же нет — то потребуется специализированное устройство Ubertooth. То есть опасаться, что телефоны сами будут друг друга заражать наверное все же не стоит.
Далее, для меня атака делится на две интересных части:

1. Это ассоциация с bluetooth жертвы без участия жертвы, что само по себе уже круто (и без дальнейшего взлома можно так подключить устройство вывода аудио, или устройство ввода)
2. Собственно shell-доступ с привилегированным пользователем (я так понял из демки, что пользователь bluetooth имеет очень широкие возможности доступа к памяти устройства)

Очень хотелось бы взглянуть на PoC
Обновление прилетело и ладно
image
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.