BlueBorne: критические дыры в Bluetooth без паринга и без касания экрана

В прошлую среду Armis Security выкатила детали BlueBorne - набора из восьми уязвимостей в стеке Bluetooth, покрывающих Linux, Android, Windows и iOS. Мы потратили пару дней на оценку и уже пошли по заказчикам с конкретными действиями. Пишем пока горячее.

Главное, что делает BlueBorne неприятнее обычного: атака не требует паринга. Классические Bluetooth-атаки предполагали, что устройства знакомы или хотя бы видят друг друга в режиме обнаружения. Здесь не нужно ничего - достаточно, чтобы Bluetooth был включён. Атакующий сканирует эфир, находит устройства, эксплуатирует уязвимость в стеке. Жертва ничего не нажимает, ни на что не соглашается, ни о чём не подозревает.

CVE-2017-1000251 в ядре Linux - переполнение буфера в l2cap (Logical Link Control and Adaptation Protocol), часть обработки Bluetooth-соединений. В Android - сразу несколько дыр в разных частях стека, включая утечку информации и RCE. Windows закрыла свою дыру в той же волне патчей от 12 сентября. На iOS затронуты версии до 10.3.3 - Apple закрыла уязвимость ещё в iOS 10.3.3 (июль 2017), так что актуальные устройства на iOS 10.3.3 уже с патчем.

Что это значит для инфраструктуры

Когда уязвимость в SSL или HTTP, периметр хотя бы понятен: смотришь на открытые порты, на публичные сервисы. Bluetooth - радиоканал, он не смотрит на firewall и не знает про VLAN. Любое устройство в физическом радиусе примерно 10 метров (классический BT) потенциально достижимо.

На серверах Bluetooth практически никогда не нужен. Но он может быть включён - особенно на железе, которое пришло с включённым BT по умолчанию, и никто не озаботился его отключить при инсталляции. Рабочие станции ситуация хуже: там BT включён у большинства пользователей, у многих постоянно, потому что гарнитура или мышь.

Нас особо насторожил сценарий с опенспейсом или конференц-залом: один скомпрометированный ноутбук с BT в режиме атаки может последовательно обработать всё, что оказалось в радиусе. Без сети, без HTTP-запросов, без следов в стандартных логах периметра.

Что сделали

Работу разбили на два параллельных потока.

Первое - отключение Bluetooth там, где он не нужен. На Linux-серверах через Ansible: сервис bluetooth останавливается и убирается из автозапуска, модуль btusb добавляется в blacklist через /etc/modprobe.d/. Это занимает минуты и не требует перезагрузки для остановки демона - хотя для полного выгрузки модуля перезагрузка нужна, её планируем в ближайшее maintenance. Задача в плейбуке вышла простая:

- name: disable bluetooth service
  systemd:
    name: bluetooth
    state: stopped
    enabled: false

- name: blacklist btusb module
  lineinfile:
    path: /etc/modprobe.d/blacklist-bluetooth.conf
    line: "blacklist btusb"
    create: yes

На рабочих станциях Windows отключение через групповую политику - Device Manager запрещает использование Bluetooth-адаптеров, или через Device Installation Restrictions по Hardware ID. Для машин, где BT реально используется (есть законные Bluetooth-периферия), - приоритет на патч, а не на отключение.

Второе - ускоренный патчинг. Microsoft закрыла свои CVE в плановом Patch Tuesday 12 сентября, патчи уже в WSUS. Мы переключили критические обновления безопасности на одобрение без дополнительного ревью для рабочих станций - обычно ждём неделю тестирования, здесь сократили до 48 часов на пилотной группе. Для Linux - ядерные патчи в дистрибутивах вышли быстро, Debian/Ubuntu уже закрылись, применяем через Ansible на всём парке.

Android - отдельная головная боль. У корпоративных устройств с кастомными прошивками производителей патч придёт когда придёт, и это не наша скорость. Для них пока единственное работающее решение - административно потребовать отключить BT вручную до получения обновления ОС.

Что осталось открытым

Инвентаризация Bluetooth-устройств в инфраструктуре - неожиданно нетривиальная задача. Мы привыкли инвентаризировать сетевые интерфейсы, но BT-адаптеры в стандартные CMDBшки часто не попадают. По ходу работы обнаружили несколько серверов, где BT был включён без каких-либо видимых причин - просто никто не выключал.

После недавней истории с Equifax и волны обсуждений про patch management у нас внутри опять всплыл вопрос про «тихие» векторы атаки - те, что не ломятся через периметр, а используют что-то, про что никто не думал как про поверхность атаки. В аудите именно такие вещи - включённый BT на сервере, открытый порт IPMI без пароля - стабильно оказываются самыми неожиданными для заказчика. Не потому что сложно, а потому что в модели угроз этого просто не было.

Пока работа не завершена: ждём подтверждения от всех заказчиков по статусу патчинга рабочих станций и доделываем Ansible-роль для унифицированного аудита состояния BT на Linux-парке. Об итогах напишем отдельно.