Грядёт новая волна буткит и руткит кода с физическим распространением через USB.

До Нового года ребятами из Positive Technologies была обнаружена и опубликована уязвимость отладочного интерфейса DCI новых процессоров Intel семейств от Skylake и выше.

https://youtu.be/6soT3hZK_T4

https://youtu.be/QuuTLkZFsug

https://habrahabr.ru/company/pt/blog/318744/

https://xakep.ru/2017/01/19/intel-dci-problem/

http://safe.cnews.ru/news/top/2016-12-29_protsessory_intel_mozhno_vzlomat_po_usb

Недавно после поездки в Китай и участия в азиатском неформальном митапе по кибер-безопасности знакомый и коллега из Гонконга, работающий вместе со мной в проекте в Шеньчжене, рассказал мне об этой уязвимости, после чего в наших светлых (или не очень 🤘👹) умах возникла интересная идея над которой мы работали последние несколько недель и вот буквально сегодня добились первых практических результатов, которые мягко говоря ужасают. 🙀

При помощи буткита, системного приложения (написанного на Rust с использованием NDK/Bionic), на Android устройстве и при подключении такого заражённого аппарата на "зарядку" через интерфейс MHL USB OTG и USB 3.0 порт к лэптопу на Skylake, через активированный несколькими инструкциями кода отладочный DCI интерфейс процессора удалось доставить руткит прямо в нужную область памяти лэптопа для внедрения кода в модули гипервизора ядра Linux используя инструкции и возможности виртуализации процессора Skylake, Intel VT (VT-x, VT-d), код руткита при этом будет исполняться в пространстве привелегий ядра и иметь доступ (как модули ядра или драйвера) к памяти всех процессов, реальной адресации, системным вызовам ядра, файловой системе и устройствам. Далее после доставки код по программе копировал сам себя (asm-quine trick) в памяти и размножал, записывал свои копии в загрузочные сектора (gpt, бутсектора системного раздела, в т.ч. резервные), разделы ФС (/boot, добавлялся в системный загрузчик для загрузки до ядра, добавлялся внешним модулем ядра как виртуальный драйвер, дампил себя в swap), записывал и скрывал свой код в резервных и скрытых блоках ФС и главное, код записывался как модуль в UEFI BIOS! Таким образом избавиться от всех копий руткита будет очень сложно - слишком много точек управления для передачи кода на загрузку.
Сам код работоспособен уже после передачи и внедрения на машину, даже без необходимости её перезагрузки.
Но чтобы убедиться что цепочка загрузки работоспособна после копирования было сделано так, что код вгоняет процессор в лимб (halt state), после чего есть только один вариант - перезагрузка (с загрузкой всех модулей руткита разумеется 😁).

Функциональность руткита.

Сразу возникла идея слушать помещение через микрофон веб-камеры (все веб-камеры имеют унифицированный интерфейс управления через USB шину - и да при активации сенсора камеры светодиод можно не включать 😉) и регулировать параметры чувствительности микрофона более высокоуровневыми системными вызовами, через ALSA и PulseAudio.
Обмозговали и сделали.
После перезагрузки и активации всех модулей для работы руткита, активировался микрофон лэптопа, снимал с него данные и отправлял их по сети в виде потокового фонового шумового трафика (не более 32 Kbit/s).

Красота!

После этого стало действительно страшно от осознания в насколько опасном технологическом мире мы с вами сейчас живём, не только софт, но и железо уязвимо и уже не до наших гикерских шуток - на ядрах архитектуры Skylake уже поставляются серверные процессоры Xeon, имеющие как виртуализацию так и отладку через DCI. Никто не знает, кто и что коннектит через USB к VPS/VDS серверам вашего проекта на удалённом виртуальном хостинге при их обслуживании (live usb flash, iLo usb, firmware updates) или регулярном мониторинге имея физический доступ к серверам.

Хоть я и не верю уже давно в святость американских корпораций (наверняка это сделано специально для упрощения распространения зловредов спецслежбами 😆) - тем не менее мы наваяли отчёт в Intel и её подразделение безопасности McAfee, приложили код.
Будем надеяться что пофиксят, обновлением bios firmware microcode update.