Комментарии 51
Пользователи Android должны дождаться исправлений безопасности для своих устройств, так как это зависит от производителя конкретного устройства. Пока можно установить приложение «BlueBorne Vulnerability Scanner» (созданное командой Armis) из Google Play Store, чтобы проверить, уязвимы ли ваши устройства для атаки BlueBorne или нет.
Пока можно установить приложение «BlueBorne Vulnerability Scanner» (созданное командой Armis) из Google Play Store, чтобы проверить, уязвимы ли ваши устройства для атаки BlueBorne или нет.
При полностью выключенном (а не скрытом от всех) блютусе программа говорит, что устройство уязвимо. Отличнo.
Вообще все приложение — красивые анимашки, а в код посморишь, там 1 класс на всю логику(com.armis.blueborne_detector.VulnerabilityUtils).
Для проверки устройств по близости, приложение по маку устанавливает производителя, ось и название устройства, на основе этих данных градирует устройста на 3 категории.
Такой вопрос: а если «Режим модема» у меня выключен в настройках, BNEP и PAN же должны быть отключены, и RCE невозможно, только менее опасные уязвимости. Или всё-таки нет?
Ну и какая утечка через наушники(на которые не будет обновлений)? Замена передаваемого трафика на свой: сигнал на динамики, сигнал с микрофона?
Внедрение кода в атаке «человек посередине» главным образом применяется для захвата уже авторизованной сессии, выполнения собственных команд на сервере и отправки ложных ответов клиенту.
Атака «человек посередине» позволяет криптоаналитику вставлять свой код в электронные письма, SQL-выражения и веб-страницы (то есть позволяет осуществлять SQL-инъекции, HTML/script-инъекции или XSS-атаки), и даже модифицировать загружаемые пользователем бинарные файлы для того, чтобы получить доступ к учетной записи пользователя или изменить поведение программы, загруженной пользователем из интернета.
Итак, в чём проблема? Bluetooth сложный.Проблема-то очевидна, но решение её «не продаваемое».
Как только авторучку вы подключите к интернету, тут же у юристов прибавится работы с легитимностью подписей и утечкой кофиденциальной рукописной информации. Выход один — не подключать авторучку к интернету, но разве маркетологи на это пойдут?!
Решение уязвимости блютуза прибавит еще тысчонку страниц в его спецификации, и все на голубом глазу будут думать, что это уменьшит уязвимость…
Только идиоты делают одно и то же, всякий раз надеясь на другой результат. Если не ошибаюсь, слова приписывают Эйнштейну. Могучий старик.
Только идиоты делают одно и то же, всякий раз надеясь на другой результат.
Человек набирает один и тот же номер и получает короткие гудки.
Идиот! Там всегда будет занято.
Я, конечно, понимаю, что имелось ввиду, но что сказано (или написано), то и имеем.
И это общая проблема подобных громких абсолютных фраз
> Безумие — это точное повторение одного и того же действия. Раз за разом, в надежде на изменение. Это есть безумие.
Во-вторых, не важно всегда ли будет занято. Лучше найти другой номер.
Полагаю, достаточно стандартной является ситуация ожидания события, когда понять факт наступления события позволяет только выполнение некоторой процедуры проверки.
Ожидание освобождения абонента путем периодического набора его номера — только один из вариантов этой ситуации (я знаю о существовании телефонов с автоматическим дозвоном, но случаи бывают разные).
Надежда — это про всего лишь про отсутствие гарантий ожидаемого.
В примере с дозвоном пациент каждый раз надеется, что именно в этот раз поведение системы наконец изменится. При этом необходимость дозвониться до данного конкретного абонента заставляет набирать номер раз за разом несмотря на ненулевую вероятность полной невозможности дозвониться (например, абонент забыл положить трубку и неизвестно, когда заметит этот факт и заметит ли вообще).
"Периодически" и "раз за разом" на самом деле не так уж и далеко друг от друга.
Если совсем уж формально, то "периодически" — это "раз за разом с некоторым интервалом между событиями". Но в реальной жизни слово "периодически" не всегда означает наличие определенного периода, а потому можно считать, что смысл достаточно близок.
Надежда — это при отсутствии объективных причин ожидать «ожидаемого».
> заставляет набирать номер раз за разом несмотря на ненулевую вероятность полной невозможности дозвониться
Мне кажется тут уместен только один вопрос: на которой итерации забирать в психушку?
При отсутствии объективных причин (за объективную причину вполне проходит отличная от нуля вероятность) мы имеем безнадежную ситуацию.
А насчет психушки после некоторого числа итераций (количество допустимых итераций определяется ситуацией) согласен. Раз за разом не означает бесконечное число попыток, а потому не вижу противоречий со своей позицией.
Каким образом хакер перенаправит трафик через «злонамеренный интерфейс», если в устройстве, например, просто нет возможности расшарить интернет по BT? Или вовсе не реализовано PAN.
Естественно, что наибольшему риску взлома подлежат наиболее интересные с точки зрения хакера устройства, а не все подряд. Вряд ли кто будет специально ковырять байду ради сферической возможности взломать байду. Главное, что принципиально показан метод, а уж степень риска каждый определяет для себя сам.
У владельцев iOS устройств как я понял проблем уже нет
Armis раскрыл Apple сведения об этой атаке. Эксплойт был устранён в версии IOS 10 и версии Apple TV выше 7.2.2, однако эта уязвимость по-прежнему представляет большой риск для любого iOS-устройства до версии 10. Уязвимость может быть использована злоумышленником для выполнения кода с повышенными привилегиями.
то есть это нельзя понимать однозначно?
С iOS 10 нет. Более старые версии подвержены.
Проблема с тем же buffer overflow это несовершенство инструментов, а не просто сложность спецификации. Какой бы сложной спецификация не была, программа не должна позволять buffer overflow. Для этого есть rust например. Но йожики будут продолжать писать на C/C++ ведь на C/C++ пишут все. Как впрочем никто не будет ломать обратную совместимость чтобы сделать язык более статически анализируемым.
Bluetooth сложный
То, что BT сложный заметно на практике, т.к. перебирая разные комбинации телефонов и BT-гарнитур у меня ни одна из них не работала на 100% без проблем. То здесь, то там всплывали разные косяки. То долгое подключение, то заикания звука, то какие-то странные подвисания.
Небезопасный код можно написать на любом языке.
Компания Microsoft выпустила обновления для системы безопасности в июле.
Может кто-нибудь подсказать конкретные номера обновлений?
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. я не специальист по ядру и тем более блютузу так что все выше изложенное сказано на правах дилетанта
Далее, для меня атака делится на две интересных части:
1. Это ассоциация с bluetooth жертвы без участия жертвы, что само по себе уже круто (и без дальнейшего взлома можно так подключить устройство вывода аудио, или устройство ввода)
2. Собственно shell-доступ с привилегированным пользователем (я так понял из демки, что пользователь bluetooth имеет очень широкие возможности доступа к памяти устройства)
Очень хотелось бы взглянуть на PoC
Эксплойт BlueBorne на Android, iOS, Linux и Windows: более 8 миллиардов устройств критически уязвимы