[Конкурс 2023] Аппаратные и микропрограммные проблемы чипсетов x86 и не только. Часть I.

Введение
Модель угроз
*****U, процессор
IME, чип удаленного управления
NIC, сетевая карта
EC, встроенный контроллер
GPU, видеокарта
RAM, оперативная память
HID, устройства ввода/вывода
HDD/SSD, жесткие диски
CD card, карта памяти
CD/DVD, оптические диски
TPM, аппаратный чип безопасности и общие рекомендации по усилению защиты платформы
Вывод

Итак, приступим. Как многие читатели знают, платформы на основе архитектуры x86, коих сейчас подавляющее большинство в сегменте десктопных компьютеров и ноутбуков, достаточно серьезно напичканы тем, что называется "блобами". То есть участками закрытого (проприетарного) кода. Блобы могут располагаться в ОС, в прошивке, в драйвере, в прикладной программе. Где угодно, вообще-то!

Казалось бы, ну закрыта часть кода и закрыта, что с того-то?
А проблема весьма проста - закрытые участки кода достаточно сложно проверить (Далее вы, читатель, узнаете, что некоторые блобы защищены криптографически и не поддаются обратной разработке (Обратная разработка - методы получения исходного кода из готового бинарного файла. Читай - из .exe на Windows и elf на Linux)).

Функционал блобов может быть весьма обширен, вплоть до вмещения в себя полноценной скрытой ОС, гипервизора, ведь даже в десяток-другой килобайт можно без особенных трудностей вместить полноценный многофункциональный троян. Что и говорить о более объемных блобах.

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

С наличием недоверенных частей определились. Теперь про нюансы их внутреннего устройства. Не все, но многие из них содержат собственный процессор, RAM, энергонезависимую память и по сути представляют из себя компьютер-в-компьютере. Практически на каждом из них есть прошивка и бывает она двух видов: встроенная и загружаемая. Первая наиболее опасна, так как иногда бывает неперезаписываемой, работает внутри, не контроллируется ОС и открытых альтернатив не имеет. Второй вид, загружаемая прошивка, гораздо более удобен: её и с уровня ОС можно проверить и защитить, и открытые альтернативы у такой прошивки есть, и какой-никакой контроль за её действиями можно организовать.

Что же в итоге? Большое количество в основном неподдающихся обратной разработке участков проприетарного кода (или целых анклавов), обладающих неизвестным функционалом и неоднократно пойманных на вредоносных или как минимум подозрительных действиях, заполонили все x86 компьютеры и ноутбуки. Эти блобы и анклавы обладают широким списком возможностей, вызывающих серьезные опасения у заинтересованных в безопасности людей, они достаточно уязвимы, а платформа вполне может функционировать и без них, однако количество таких проблемных участков по самым разным причинам растет с каждым годом. Причем некоторые из блобов нельзя удалить штатными (а иногда и не очень) методами!

Ну а сегодня мы постараемся узнать истинное лицо зверя и найти против него серебряную пулю!

Начать стоит непременно с неё, мы ведь взрослые люди серьёзные безопасники, правда?
Модель угроз представляет собой последовательный и обоснованный ответ на ряд вопросов:
I. Что мы защищаем?
II. От кого мы это что-то защищаем?
III. Как именно мы это защищаем?
IV. Какова вероятность попытки атаки нашего сокровенного "чего-то"?


I. Защищает каждый что-то свое, однако есть некоторые наиболее распространенные объекты защиты:

• Рабочие аккаунты в мессенджерах, в которых происходит общение с клиентами/товарищами/продавцами.
• Криптовалютные кошельки.
• Ключи GPG, использующиеся для двухфакторной авторизации или шифрования.
• База паролей.
• Различные данные, хранящиеся в зашифрованной системе. Данные любого характера, к которым не применяется дополнительное шифрование.
• Данные, к которым, напротив, применяется дополнительное шифрование. Различные криптоконтейнеры, зашифрованные архивы и т.д.

---


На системном уровне в общем случае защищается следующий массив данных:

• Компоненты загрузочной цепочки: загрузочная прошивка (BIOS/UEFI), прошивки прериферийных компонентов системы (анклавов), ядро, initrd, модули ядра, система инициализации,
• Пароль root и непривилегированного пользователя.
• Пароль шифрования жесткого диска.
• Настройки системы.

II. От школьников, установивших Kali Linux на время каникул, от местного гестапо, стремящегося устранить неправомерный бизнес, от соседа, который не прочь получить секреты, о наличии которых услышал, сидя со стаканом у стены, от тайных структур, желающих получить биткоины "шелкового пути" восстановить порядок в земле государевой и от иных недоброжелателей.

Абстрактная модель нарушителя, согласен, но я сейчас всё объясню. Подоплёка такого размытого обозначения врага состоит в широком распространении технологий и наличии простых инструкций к ним. Настолько простых, что, при желании, и сосед, и школьник, и не больно умный, но о-о-о-очень в народе уважаемый сотрудник гестапо смогут осуществить различные атаки, описанные ниже. Особенно при условии наличия легко доступных эксплоитов к различным уязвимостям и яркого нежелания пользователей производить регулярные обновления.

Из этого следует, что злоумышленник может быть абсолютно любым. Часть атак, конечно, относится разве что к возможностям рептилоидов, жидомассонов, иллюминатов тайных служб, поскольку уж больно они мудрёные, но остальные методы вполне могут реализовать и злоумышленники попроще.

III. Защищать нужно, соотносясь с некоторыми общими положениями, которые я здесь и изложу. Точные и детальные описания будут изложены в самой статье, здесь только "идейный каркас".
Собственно вот он:

• Defence-in-Depth. Это принцип защиты в глубину или многослойной защиты. Он подразумевает наличие нескольких слоёв защиты против данного вектора атаки.


• Принцип нулевого доверия или Zero Trust model. Как понятно из названия, означает отсутствие доверия к кому-либо внутри системы или за её пределами, что предполагает постоянные проверки всего и вся (в данном случае - в рамках защищаемой рабочей станции), контроль доступа, принцип наименьших привилегий.


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


• Внедрение открытых систем и прогамм. Повсеместное внедрение open source как черты, повышающей доверие к ПО. Это, конечно же, не гарантия и наилучшим будет наличие открытого кода и аудита этого кода от доверенной аудиторской компании, но такое разве что в сказке встречается. Если есть желание, можно воспользоваться различными сканерами исходного кода, показывающими примерное наличие потенциально опасных возможностей, для самоуспокоения.


• Принципы Керкгоффса. Их шесть, но мы используем только четыре:

I. Система должна быть практически, если не математически невзламываемой. Это значит, что с прикладной стороны информационная система должна быть либо трудновзламываемой, либо совсем невзламываемой, даже если со стороны теоретической математики взломать её всё же можно.
II. Система не должна требовать сохранения её в тайне и попадание её в руки врага не должно вызывать проблем.
III. Система должна быть портативной и не должна требовать для своей работы более одного человека.
IV. Система не должна требовать соблюдения большого количества правил для своей работы.

IV. Реальная вероятность атаки описанными ниже способами не больно-то и велика. Эти методы задействуются либо массово и автоматически, либо точечно, но только при отсутствии других путей атаки цели.

Лично я считаю, что опасаться атаки по описанным далее векторам реальна только при максимально возможной защите более тривиальных векторов атаки. Тем не менее, знать о подобных методах атаки необходимо при построении действительно защищенных систем.

О вероятном использовании нижеизложенных методов стоит говорить лишь в отношении форензики, которая также будет частично затронута в некоторых разделах.

Представим, однако, что пользователь защитил свою систему на высоком уровне от самых различных атак, но прогрессирующая параноидальная шизофрения не позволила ему успокоиться и аноним задумался о построении настоящей сетевой цитадели.

Процессор или *****U (Central Processing Unit). Я полагаю, что все знают, чем он занимается и зачем нужен. И он является одним из самых проблемных компонентов в системе, поскольку контроллирует все происходящее в ней.

Однако, перед началом моего рассказа о нем, следует поведать о системе колец власти. Девять колец было отдано людям, семь - гномам... Ладно, речь, конечно, о кольцах защиты. Это теоретический принцип разделения привилегий в современных операционных системах. В рассматриваемых мной системах выделяется семь колец защиты:

3 - пользовательские приложения, непривилегированный код. Наименее привилегированный уровень
2 - службы, "демоны", фоновые приложения.
1 - драйвера устройств.
0 - ядро и привилегированный код, исполняемый в пространстве ядра.
-1 - уровень гипервизора. Речь об аппаратной виртуализации и гипервизорах первого типа. VirtualBox к ним отношения не имеет, поскольку мы рассматриваем систему колец защиты оснвной ОС.
-2 - уровень SMM или System Management Mode. Это наиболее привилегированный режим в рамках процессора.
-3 - уровень IME (Intel Management Engine). Эта подсистема расположена на отдельном SPI чипе и к самому процессору имеет весьма опосредованное отношение, а потому в данном разделе рассматриваться не будет. Это наиболее привилегированный режим в рамках всей платформы.

Так вот, приступим, наконец, к рассмотрению неприятных особенностей этого компонента системы. Их существует весьма представительное количество и, в зависимости от OEM (Original Equipment Manufacturer или, по-простому, вендор), они отличаются, поэтому эта глава будет разделена на две подглавы.

Intel ME (Intel Management Engine) является наверное самым известным бэкдором в платформах на базе x86. Впервые он появился в 2005 году, а значит все устройства, произведенные в этот год или после, необходимо проверять на наличие IME, поскольку в абсолютно все чипсеты Intel эта подсистема встраивается только начиная с 2010 года.
Эта подсистема является представителем уровня привилегий -3, самого существенного из существующих, так как расположенные на этом уровне компоненты не являются частью какого-либо анклава, они расположены на выделенном чипе, представляя собой еще один анклав, самый опасный очаг болезни.
ME на современных платформах расположен в GMCH (Graphic and Memory Controller Hub), в северном мосту, если по-русски.
Контроллер может работать в двух режимах: в привилегированном и непривилегированном. Первый предполагает расширенный доступ к аппаратным ресурсам и памяти. Он используется ядром и драйверами, включенными в состав прошивки. Обычным модулям и службам отводится ограниченный непривилегированный режим.
Структура IME достаточно сложна, однако её стоит описать для лучшего понимания болезни.

• Контроллер ME. Обычно тридцатидвухразрядный чип архитектуры RISC (в разные моменты это был ARC, SPARC, а потом и вообще x86), содержащий ROM, C-Link и SRAM.
• ME ROM является отдельной неперезаписываемой энергонезависимой памятью, в которой содержится начальный загрузчик ME, запускающий все остальные модули и выступающий своего рода Root-of-Trust, корнем доверенной загрузки, проверяющим, вероятно, все остальные модули.
• SRAM оперативная память, которую ME контроллер может использовать при недоступности основной (До её инициализации, например. Или на выключенном компьютере).
• C-Link есть отдельная шина, по которой ME может взаимодействовать с периферийным аппаратным обеспечением. К счастью, только на выключенном (S5) или находящемся в режиме сна (S3) компьютере.
• Помимо прочего, контроллер содержит в себе таймер, контроллер памяти, аппаратный генератор случайных чисел, криптографический ускоритель, контроллер DMA, особый интерфейс для взаимодействия с внешним миром (MEI) и много чего еще.
• Для ME выделен отдельный пятимегабайтный регион в памяти BIOS, в SPI. Там хранится прошивка ME с самыми различными модулями, о которых ниже. Прошивка, разумеется, подписана и защищена от изменений.
• MEI (Management Engine Interface). Единственный канал связи исполняющихся на процессоре программ с ME.
• Выделенный внеполосный доступ к сети. Это делает все подключения IME невидимыми с уровня OS.
• Отдельный, доступный только для ME, раздел RAM, размером около тридцати двух мегабайт.
• Модули BIOS, инициализирующие часть оборудования и сообщающие в ME контроллер о результатах своей работы.
• Начиная с одиннадцатой версии ME, на контроллере работает основанная на Minix полноценная операционная система (ThreadX), что технически является истинным хозяином платформы.

Возможности этой подсистемы не менее обширны:

• Полный DMA доступ к RAM.
• SOL (Serial-Over-Lan) - виртуальный COM-порт, позволяющий через сеть включать/выключать/перезагружать/менять настройки BIOS. Конечно же, без ведома пользователя.
• IDE-R (IDE-Refirection) - функция загрузки платформы с удаленного диска с готовым образом системы.
• Веб-сервер для управления и просмотра информации (хоть https недавно ввели и то хорошо!).
• KVM доступ (только в модуле AMT, подробнее о котором ниже). Возможность управлять мышью/клавиатурой компьютера и видеть экран пользователя. При этом на экране появляется заметная красная рамка, но при некоторых усилиях её, я уверен, можно отключить. Подключение может быть как зашифрованным, так и нет.
• Объемный раздел энергонезависимой памяти (часть MFS, ME File System, общей файловой системы, содержащей раздел в ME контроллере, раздел в SPI памяти), в которую можно поместить сторонние приложения. Не всем подряд, конечно, а только корпорациям по санкции Intel. Эти приложения/модули пишутся на Java, а в ME работает JVM (Java Virtual Machine).
• AMT - это та самая Advanced Management Technology, в которой реализуется удалённое администрирование, KVM и другие, самые опасные функции ME.
• IBG или Intel Boot Guard. Его работу я описал в отдельном подразделе в секции *****U.
• PAVP (Protected Audio Video Path) - технология DRM, воспроизводящая защищенный зашифрованный контент только при наличии ключей от него в ME. Это также еще один аргумент в сторону того, что всё происходящее в RAM и на экране постоянно мониторится ME в реальном времени, что как минимум необходимо для работы этой технологии. Имеется она в ME начиная с четвертой версии.
• ME Ignition - компонент прошивки, отвечающий за инициализацию оборудования.
• fTPM. Это программная реализация TPM, firmware Trusted Platform Module. Он реализует все функции обычного, аппаратного TPM на уровне прошивки, что принуждает доверять реализации ME и её полностью закрытому коду в деле манипуляций с чувствительными данными.
• IPTT (Intel Platform Trust Technology) - аналог M$ Pluthon, о нем говорилось в секции, посвещённой *****U.
• AT, Anti-Theft Technology. В настоящее время не используется, есть только на старых платформах.
• TXT, Trusted eXecution Technology, технология доверенного исполнения. Рассказывать о ней можно долго, это отдельная большая тема, но, вкратце, она реалищует среду доверенного выполнения специальных приложений в отдельном, зашифрованном разделе ОЗУ, ключи к которому хранятся в регистрах процессора, а само исполнение происходит за счет ME. Опять же, доверенной такая технология может являться только при условии доверия ME, которое, как, вероятно, ясно читателю, исключено как таковое.

Подробнее про архитектуру ME на сайте libreboot и в подробной статье. А также, конечно, в документации.
Модули эти описаны в специальной таблице, которая подписывается RSA 2048 от Intel. В таблице содержится также хеш-сумма SHA256 для каждого модуля. К сожалению, свои ключи добавить не получится, так как в ROM содержится SHA256 сумма подписывающего таблицу модулей ключа. Помимо этой защиты, всю файловую систему ME, MFS, защищают четыре разных ключа, которые делятся на две группы: два ключа ключа для защиты содержимого MFS (Intel и Non-Intel Configentiality Key) и два ключа для защиты целостности содержимого MFS (Intel и Non-Intel Integrity Keys).

Как, думаю, читатель уже догадался, с ME можно проделывать самые различные фокусы.
В частности, для ME можно активировать JTAG, что позволит получить полный доступ к этой подсистеме.
Есть и более серьёзные проблемы. Например, CVE-2018-3628, являющаяся RCE, уязвимостью исполнения произвольного кода. Осуществить сие можно без учетной записи AMT, удалённо, без всякой авторизации. Этого уже хватит для полной компрометации платформы, но, постойте, список только начался!
CVE-2018-3655 позволяет получить все четыре защищающих MFS ключа и получить таким образом доступ к содержимому модулей и всему коду, что позволяет модифицировать его произвольным образом. Такая модификация позволяет установить вредоносное программное обеспечение, устойчивое к переустановке ОС и программной прошивке BIOS. Удалить его можно будет только с помощью программатора, специального устройства для прошивки микросхем.
Кстати, на чипсете версии ниже Q45 можно установить так называемый ring -3 rootkit, работающий на основе перераспределения защищенной памяти, в которой работает код ME. Эта вредоносная программа является кейлоггером, работающим всегда, когда есть питание на платформе, что подразумевает компрометацию всего ввода на платформе.
Атака, называемая "Silent Bob is Silent" или CVE-2017-5689, позволяет аутентификацию с пустым паролем в аккаунт администратора AMT.
Zero-Touch provisoning позволяет похитить передающиеся в открытом виде пароли при использовании IDE-R и SOL, что были описаны выше.
Применяющееся в AMT, IDE-R и других технологиях шифрование также не больно-то внушает чувство защищенности, так как в SSL/TLS были найдены многочисленные уязвимости, иногда критические, которые позволяют считать потенциально скомпрометированным любое соединение, работающее без сильной дополнительной криптографии, как это реализовано в I2P, TOR или другой распределённой сети. Уязвимая реализация шифрования также добавляет дополнительную угрозу захвата контроля над платформой или получения любых конфиденциальных данных. Реализовано это может быть, exempli gratia, чтением произвольного участка RAM (атака HeartBleed) удалённо, что вполне возможно, так как ME анализирует все поступающие на платформу пакеты и работает даже тогда, когда компьютер выключен, что позволяет полагать подобную угрозу допустимой.

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

Что же с этим делать? Удалить ME? Не выйдет! Без прошивки платформа либо не инициализируется и не загружается, либо загружается и работает тридцать минут, после чего выключаясь.
Есть вариант с выставлением HAP (High Assurance Platform, высокодоверенная платформа) бита. При активном бите платформа инициализируется, после чего ME переходит в неактивное состояние, но с полным функционалом. Лично я бы ему не доверял.
А есть лишь два действительных варианта защиты от такого счастья:

• Купить ноутбук или PC, в котором еще нет этого чуда техники, либо в которых можно полностью удалить ME firmware, прошивку контроллера. Это, например, модели ThinkPad X200/T400/T500/W500. Они поддерживаются Libreboot, установить который будет очень даже несложно. Инструкция есть на сайте проекта.

Проблемы такого подхода весьма и весьма немалые:
Малая мощность устройств. Максимальная конфигурация будет иметь восемь гигабайт ОЗУ и Core 2 Quad на четыре ядра.
Преклонный возраст устройств, что подразумевает отсутствие поддержки на уровне микрокода, например.
Отсутствие аппаратной поддержки важных технологий защиты, таких как, например, IOMMU и VT-d, что, в свою очередь, подразумевает невозможность реализации самых масштабных и мощных стратегий защиты.

Лично я склоняюсь к избеганию подобного варианта из-за слишком больших издержек, приходящихся на полное отсутствие ring -3...
Ах, да, не полное - контроллер-то никто с платы не убирал и ROM оттуда не удалял, а устройства совсем без IME либо слишком старые и совсем уж маломощные, либо дорогие и редкодоступные, такие как, например, TALOS II, посторенные на процессорах POWER9 и открытых (в целом) технологиях.


• Ограничение IME с помощью известного инструмента. Он удалит все модули, кроме необходимых для загрузки платформы, устраняя таким образом большую часть опасности. В версиях ME до одинннадцатой размер прошивки уменьшается до девяноста килобайт, а в одиннадцатой, где ввели целую операционную систему, он сокращается только до шестисотпятидесяти.
Но этого нам мало, вспомните модель угроз! Мы дополнительно включим проверку целостности образа ME в coreboot, ограничим запись и чтение в регион ME всем, скроем интерфейс ME от ОС, включим measured boot и его проверку в initrd, запретим к загрузке модуль взаимодействия с ME в настройках modprobe. Все это, кроме настроек modprobe, находится в разделе "Chipset" в конфигурации coreboot.
Помимо прочего, в этом варианте необходимым является удаление внутренней сетевой карты, дабы исключить доступ Management Engine к сети. Сеть будет использоваться через внешний адаптер, который, помимо прочего, дарует возможность подключить антенну и расширить зону покрытия и функционал адаптера (удобное подключение мощной дальнобойной антенны для атак на удалённые сети, более точечная регулировка мощности, различные режимы работы, отсутствующие во встроенной сетевой карте).

Таким образом, ME будет максимально ограничен, во встроенных возможностях. Атакующие также не смогут получить над ним контроль, поскольку весь возможный доступ к нему с уровня ОС будет исключен, чтобы избежать описанных выше атак. Прошивка программными методами также будет невозможна, что хотя и является некоторого рода неудобством, но серьезно повышает безопасность. А о возможностях неудалённых модулей можно не беспокоиться, доступа к сети у контроллера все равно нет.

Перейдем, пожалуй, к NIC (к Network Interface Controller или, если по-простому, сетевой карте). Как известно, существует два типа подключения к интернету: проводной и беспроводной. Нас, в основном, интересует последний, однако несколько слов будет сказано и о старом добром Ethernet. Также будет немного затронут Bluetooth, так как он нередко находится на одном и том же чипе.

EC (или embedded controller) - это небольшой SPI чип, который также присутствует практически во всех компьютерах, произведенных за последние десять-пятнадцать лет.

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

Этот контроллер, как и SPI чип BIOS, работает даже в выключенном устройстве, поскольку он же и отвечает за его включение. Однако, выделенного питания не имеет и гарантированно отключается с отсутствием батареи, тогда как память BIOS все еще получает питание.

Embedded controller имеет несколько важных свойств:

• Контроллирует ввод с клавиатуры.
• Снимает показатели с датчиков температуры.
• Контроллирует скорость вращения кулеров системы охлаждения.
• Регулирует яркость экрана и соответствующие особые клавиши, если таковые имеются.
• Тачпад также полностью в его ведении.
• Контроль состояния крышки ноутбука и, следовательно, перехода в режим сна, в SMM, о чем и было сказано выше, также лежит на его хрупких транзисторных плечах.
• В некоторых системах, EC находится на той же шине, что и TPM.
• Влияет на контроллер батареи и заряда, кнопку запуска системы, отвечает за запуск компьютера, как, думаю, уже ясно.
• Работает даже в выключенном устройстве.
• Запускается раньше BIOS (точнее, инициализирует часть оборудования, передает управление BIOS и продолжает работать всегда, пока есть питание). Подробнее тут.
• Содержит ARM или MIPS ядро, немного собственной RAM (к основной памяти он доступа не имеет, а значит DMA атаки невозможны) и около 200 килобайт памяти, чего вполне достаточно для внедрения самых разных функций.
• Ворох специальных клавиш, вроде выделеных кнопок для контроля звука, яркости экрана, Wi-Fi, Bluetooth и других систем также в его ведении. Также, этот чип может сам включать и отключать соответствующие компоненты системы.

Выходит, что в чипсете имеется еще одна микросхема, которая, как ясно из ее функционала, вступает в работу самой первой, даже раньше BIOS, в той или иной степени контроллирует взаимодействие пользователя с системой, а также системы с внешним миром, что ведет к ряду гипотетических атак:
Кейлоггер в прошивке EC, отправляющий своему хозяину пароли пользователя, вводимые с клавиатуры. Тут даже хваленый PS/2 тип подключения не поможет, поскольку данные поступают в EC без учета типа подключения, а дальше рассылаются ширковещательными UDP запросами. Пример подобной атаки. И более подробное объяснение.

Если в устройстве чип TPM подключается к той же шине, что и EC, последний может похитить ключ, там хранящийся, поскольку видит все, что по этой шине пересылается. Отправить данные можно тем же путем, что и в предыдущем случае.

Он может также предпринимать попытку деанонимизировать пользователя парой фантастических методов:
Например, вирус в прошивке EC может замерять скорость печати пользователя, от чего не спасет известный инструмент kloak, поскольку таковой защищает лишь от атаки с уровня ОС. Из браузера, например.

Как вариант, деанонимизация возможна путем отслеживания позиции (x, y координат) и скорости движения курсора специальным JS-скриптом. Но ведь принято отключать JS в целях анонимизации? Не забывайте, EC контроллирует тачпад, а про trackpoint я напишу чуть ниже. Эта атака реализуется и на более низком уровне, отключение JS не поможет.

Манипуляции с Bluetooth и Wi-Fi, при некотором развитии вышеописанной техники, помогут попробовать заполучить данные о системе и аппаратном обеспечении пользователя и отправить их куда следует.

Существует подтвержденная атака с использованием вредоносной зарядной станции. В результате, злоумышленник может с высокой точностью узнать, какие приложения запущены на атакуемом устройстве и даже какие сайты открыты в браузере лишь по расходу энергии. Данный чип может изнутри узнать, какие приложения использует пользователь в данный момент по расходу батареи. Доказательство концепции имеется для похожей атаки, однако с вирусом в прошивке EC даже вредоносная зарядная станция не нужна, все работает в автономном режиме!

Это все, конечно, хорошо, но как атакующий скомпрометирует прошивку, если она находится на независимом контроллере? Также, как и многие другие прошивки - через BIOS. Обновляться-то она все равно как-то должна, а механизм обновлений реализован через память BIOS. Значит, есть вероятность занести заразу несколькими путями:

• С обновлением (атака на цепочку поставок или ложное обновление).
• С обновлением в режиме SMM, в котором, как сказано выше, достаточно много уязвимостей.
• Через уязвимость в BIOS (CVE-2019-6171, например). Подробнее тут.
• С помощью физической перепрошивки, выполненой программатором (или через UART).

Но ведь должна быть какая-то аутентификация данных? Может быть TPM проверяет обновления прошивки EC? В том-то и дело, что реализация алгоритма проверки целостности есть разве что в написанных под windows утилитах для обновления, да и то не во всех. Это еще сильнее упрощает атакующему работу.

А как данные попадут наружу, если нет Wi-Fi/Bluetooth или атаковать их не получается? Вот тут все куда необычнее, чем в прошлых разделах - через атаки по сторонним каналам. Поясню подробнее: раз EC контроллирует скорость вращения кулеров и яркость экрана, он может реализовать как минимум две атаки - передачу данных через специальные малозаметные [url]мигания экрана[/url] или через создание шумов путем изменения скорости вращения кулеров, что и позволит передать закодированные, например, азбукой Морзе, данные.

Как же от такого можно защититься? На самом деле, реальный метод передачи данных только один - через Wi-Fi, поскольку остальные не работают на дальних расстояниях, а даже этот работает только при содействии роутера или другого зараженного устройства в той же сети. Другие же методы протестированы разве что в лабораторных условиях и в реальности вряд ли могут быть полноценно использованы. Следовательно, достаточно почитать электронную схему своего устройства, какие-нибудь документы от вендора или Hardware Manual и посмотреть там, имеет ли EC доступ к Wi-Fi адаптеру. Если имеет, то сетевую карту следует заменить на внешнюю и подключать по USB, это преградит даже зараженному устройству путь наружу. Да и вообще, это защищает и от других атак, а потому следует всегда удалять все внутренние сетевые карты и пользоваться только внешними USB адаптерами.

Помимо прочего, можно применить методы защиты режима SMM. Прошивка BIOS и перевод чипа в read-only спасет от вредоносных обновлений с уровня OS, но сломает вообще любые обновления EC, что как бы нивелирует путь проникновения угрозы в прошивку. Добавлю, что прошивка хранится в самом EC, поскольку он вступает в работу до BIOS, а значит проверка целостности secure boot тут не поможет.

А можно ли что-то сделать с самим EC? В основном, нет. Отказаться от него невозможно, удалить или ограничить прошивку также нельзя без потери работоспособности устройства. Свободных прошивок широкого профиля не существует в природе. Однако, есть несколько примеров чипов, производители которых открыли код своих прошивок:
В модульных ноутбуках Framework.
В ноутбуках фирмы System76.
В ноутбуках Google (Chromebook).
Проект Zephyr также разрабатывает открытую прошивку EC, но только для одноплатных компьютеров.
Если хочется побольше защиты от всяких низкоуровневых атак, следует присмотреться к вышеозначенным устройствам.

В некоторых ноутбуках Lenovo Thinkpad можно патчить оригинальную прошивку EC. Инструкция в репозитории. Подобная модификация позволяет установить классическую семирядную клавиатуру и отключить вендорлок на батареи, удаляя whitelist. Вероятно, на просторах сети можно найти и расшифрованные образы прошивок EC различных ноутбуков.

В этой части, как и в следующей, будет мало текста, так как об этих компонентах информации не так уж и много.
Проблемы у видеочипа следующие:

• Наличие закрытой прошивки для внешних видеокарт, а нередко еще и драйверов. Прошивка загружаемая, хранится в BIOS, у проекта coreboot есть свободная её реализация. Драйвера же, в свою очередь, были частично открыты для видеокарт Radeon и Nvidia, в GNU/Linux есть также свободная реализация (novueau).
• Угроза (CVE-2019-14615) от встроенной в процессор видеокарты, iGPU. Угроза серьезна, так как позволяет атакующему узнать, какой сайт посещает пользователь, получить ключи AES. Угроза, конечно, давно устранена, однако это не значит, что подобного не возникнет вновь. Я лишь призываю с осторожностью относится к GPU как доверенному вычислительному устройству.
• VGA bios blob. Этот блоб отвечает за инициализацию графического стека системы там, где отсутствует нативная поддержка, реализованная в coreboot. Может быть заменен свободной альтернативой при установке вышеупомянутого coreboot.
• DMA. Все та же проблема с чтением секретов из оперативной памяти.
• Обильное количество вычислительных ресурсов внутри видеочипа и собственное изолированное (от ОС) вычислительное пространство, позволяющее расширить захваченную область системы, как это было описано в части про NIC.

Пути устранения проблем весьма тривиальны и частично описаны в предыдущих частях: включение IOMMU на уровне coreboot, перепрошивка BIOS на чистый coreboot с заменой закрытой прошивки для видеочипа на свободную, использование только открытых драйверов на уровне ОС, верификация цепочки загрузки, помогающая упредить атаки на вышеописанную схему.
Для усложенения других атак стоит отказаться от использования PCI видеокарты, если это возможно исходя из целеполагания и/или модели угроз. При работе с криптографией или другими вычислениями, требующими максимально доверенной среды, следует отказаться от использования видеокарт вообще.
Если говорить об анонимности, то видеочип участвует в Canvas fingerprint. Это к теме статьи не относится и говорить об этом подробно не будем, но при настройке браузера не стоит об этом забывать.
Открытые проекты в этой сфере также развиваются. Существует открытая реализация CUDA, попытка создания открытой видеокарты.
Про открытые драйверы novueau для проприетарного железа Nvidia, думаю, все знают и без меня.

Вероятно, все знают, за что отвечает этот компонент, поэтому распыляться здесь особенно не буду.
У оперативной памяти есть ровно два минуса и один плюс:

⊖ Минусы:

• Наличие так называемого MRC или Memory Reference Code, который в этом списке идет следом за Intel ME. Исполняется на *****U, занимается инициализацией памяти и USB, другие его функции неизвестны. Ни одного случая атаки на этот модуль мне неизвестно, реверс-инжинеринг также не проводился, информация о нем в целом практически отсутствует. На чипсетах IvyBridge и некоторых более старых поддерживается так называемый Native Raminit, позволяющий отказаться от этого блоба (с помощью установки coreboot, конечно же). Хорошиe ноутбуки на этом чипсете - Thinkpad T430, X230, W530.
• Гипотетическая возможность сохранения полных секретов или их частей. Exempli gratia, это может быть ключ шифрования диска или различные следы, оставшиеся после работы ОС. Рекомендуется перед каждым завершением работы очищать всю оперативную память, что можно сделать утилитой memwiper, smem или pandorabox.
Интересным вариантом очистки памяти будет модуль alzheimer, который полностью принудительно очищает память, вызывая тем самым зависание устройства и удаление всего содержимого RAM. Этот модуль можно использовать через подключение его к скриптам вроде usbdeath или этого.
Coreboot же позволяет зачищать оперативную память при каждом включении устройства, что тоже не помешает, а также дополнительно защитит от вредоносного кода, который копируется в системную память при загрузке.


---


⊕ Плюс:

• Возможность аппаратного исправления ошибок при использовании ECC памяти. Это защитит содержимое RAM от повреждения и от атак изменения битов.

Существует также PCIe-устройство для быстрой выкачки содержимого оперативной памяти через уязвимый порт. Злоумышленники могут воспользоваться чем-то подобным и похитить спрятанные в RAM секреты, что дает еще один повод к защите (или уничтожению) потенциально опасных разъемов на корпусе устройства.
Если у читателя имеется дополнительная информация об MRC или о RAM в целом, то прошу предоставить её в комментарии.

К этому классу устройств я отнес всю периферию компьютера: динамики, микрофоны, клавиатуры, мыши, мониторы и тому подобное. И да, здесь тоже есть немало проблем с безопасностью, как бы необычно это не было слышать.

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

Несмотря на блобы, которые есть не во всех моделях, у динамиков и микрофонов есть одна очень интересная особенность, позволяющая менять их местами. Следовательно, постоянно включенные колонки могут вас подслушивать!

В исследователями приведены следующие чипсеты Realtek, поддерживающие двойное назначение разъёмов, однако список этот, само собой, не полный:

• ALC892
• ALC889
• ALC885
• ALC888
• ALC663
• ALC662
• ALC268
• ALC262
• ALC267
• ALC272
• ALC269
• ALC3220

Программная же смена назначения разъема имеется в спецификации Intel HDA. Также, есть информация, что АНБ использовала эту методику для организации прослушки. Не стоит забывать и об относительности эффективности "аппаратных" переключателей, поскольку единственный по-настоящему аппаратный переключатель это тот, что способен физически отключить подачу питания на устройство. Все остальное неэффективно и подвержено различным атакам. Чего стоит только возможность включения микрофона или динамиков без световой индикации и без какого либо уведомления для ОС, так как отвечающий за эти функции драйвер (и, уж тем более, прошивка!) работает, как, вероятно, помнит внимательный читатель из моего описания колец защиты, уровнем ниже и может подделывать передаваемую информацию.

Другим примером использования подобной техники отслеживания является Cross-Device tracking. Эта атака основывается на предполагаемом наличии у пользователя двух устройств, способных воспринимать и проигрывать звуки. Суть атаки в передаче звуков, которые воспроизводятся при попадании пользователя на определенный сайт или открытии приложения. Далее, программа снимает отпечаток системы пользователя и формирует на его основе особый звук, передающийся в неслышимом для человека диапазоне. Этот звук воспринимается динамиком другого устройства - телефона, например. Затем, это самое другое устройство воспринимает звук и, например, показывает тот же контент, что интересовал пользователя на первом аппарате.

Exempli gratia, это позволяет связать анонимную и неанонимную личность, "белую" и "черную" идентичность, как это иногда называют на слэнге. Причем, опасность только возрастает, учитывая факт неотключаемости микрофона и динамиков на смартфонах штатным образом. Причем, какого-то заражения вредоносными программами не требуется, звук может воспроизводится одним лишь браузером.

Еще один случай атаки предполагает улавливание звука нажатых клавиш и похищения паролей, логинов, кодов двухфакторной авторизации и вообще любых вводимых данных. ПО для такой атаки находится в открытом доступе. Запуск этой программы не требует root, а значит полная компрометация системы даже не требуется, нужно только заполучить доступ к системному непривилегированному пользователю и доставить один файл на атакуемую платформу. Дальше узнать пароли будет делом техники. Учитывая количество различных зависимостей в современных пакетах на python, go и подобных языках, а также возможность загружать в устанавливаемых пакетах скомпилированные бинарные файлы на других языках, попадание таких вирусов в пользовательскую систему кажется весьма и весьма простым.

Но не будем забывать о людях с параноидальной шизофренией в терминальной стадии! Некоторые заявляют, что микрофоны и колонки могут улавливать специальные звуки, что не слышимы человеческим ухом. Эти звуки позволяют Intel ME общаться с внешним миром. Сигнал, покидая даже изолированный "воздушным зазором" компьютер через аудиоаппаратуру, улавливается, например, телефоном, который изолированным не является и быть в стандартном случае не может, а далее уже передается оным через обычную сеть на управляющий сервер, который может обратным путем отправить какую-либо команду обратно.

Cui bono? Атаки подобного типа просты, даже проще, чем фишинг, а количество зараженных пакетов в PyPi, npm и других подобных репозиториях только растет, как, собственно, и вероятность заражения более крупного проекта, использующего что-то из тех репозиториев в качестве зависимости.

Таким образом, высокая степень анонимности требует отсутствия небезопасных устройств рядом с рабочими. Следовательно, следует повышать количество свободных и безопасных устройств. Можно прошить телефон, установить GNU/Linux, не держать рядом "умных" устройств: колонок вроде Алисы от Яндекса, смарт-браслетов, не прошитых телефонов, ноутбуков, мышек и всего остального.
Поскольку атака требует исполнения JS-кода и доступа к аудиоаппаратуре, следует изолировать от доступа к ним все приложения с помощью Apparmor или SeLinux.

Прошитый смартфон можно дополнительно защитить от участия в такой атаки с помощью PilferShush Jammer, который доступен в F-Droid. В качестве ультимативной меры, можно демонтировать микрофоны и динамики. В десктопах с этим проще: отключил подобные устройства и все тут. При надобности их можно включить снова. А вот в ноутбуках ситуация хуже - не везде эти компоненты в принципе можно снять, где-то придется отпаивать. Потому следует выбирать ноутбуки подходящие не только под свободные версии BIOS, но и под описанную выше модификацию. В любом случае, при необходимости можно воспользоваться наушниками.

Из открытых проектов в этой сфере на ум приходят разве что наушники Ploppy, распечатанные на 3D-принтере и использующие в работе Raspberry PI Pico, а также сертифицированный фондом свободного ПО USB микрофон ThinkPenguin TPE-USBMIC.

Веб-камера не так уж разнообразна и опасна, как звуковая аппаратура, однако, от нее исходит даже более серьезная угроза - подсматривание за пользователем, а не только подслушивание. Также, у нее есть собственная прошивка (конечно же закрытая и не имеющая открытых альтернатив), память, небольшой контроллер и иногда световой индикатор работы. Думаю, читателю уже понятно, что индикацию при атаке можно и отключить, а подсматривать за пользователем очень долго и незаметно, пряча записи, например, в bad blocks, зарезервированное дисковое пространство или на скрытую файловую систему.

Одной из предполагаемых атак может быть возможное улавливание звука клавиш встроенным микрофоном, но это актуально только для внешних камер, поскольку в ноутбуках эти компоненты часто разделены, хоть и не всегда. Лучше проверить. Или же, веб-камера может засечь ввод конфиденциальных данных пользователем, если в кадр попадает клавиатура. Id est, даже простого подглядывания достаточно для судорожного выпиливания камеры из всех своих устойств.

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

Клавиатура, является основным способом ввода данных в любую систему, а значит является желанной целью для атак. Строение современных клавиатур вызывает некоторые опасения, поскольку многие из них содержат небольшие микроконтроллеры, что-то вроде Raspberry Pi pico, которые отвечают за обработку нажатий клавиш, сохранение макросов, настроек подсветки и тому подобного. Id est, это касается только внешних клавиатур, так как в ноутбуках за это отвечает EC, прошивка которого еще на этапе производства индивидульно настроена под каждую модель и содержит вышеперечисленный функционал, но иногда и там встречаются встроенные в клавиатуру микроконтроллеры.

Такое строение системы ввода, а также распространенное подключение по USB грозит пользователю, например, кейлоггером, который может быть встроен в контроллер. Это позволит абсолютно незаметно для анонима записывать все нажатия клавиш во встроенную память. Такое уже случалось с клавиатурами фирмы Corsair, которые в случайный момент времени самопроизвольно печатали ранее набранные пользователем сообщения. Компания заявила, что данный функционал не является кейлоггером, а связан с неполадкой в работе штатной функции записи макросов, но, как говорится, осадочек остался.

Сейчас про тип подключения. Есть три основных: Radio, USB, PS/2.
В списке они расположены по убыванию опасности. Первый, Radio, означает подключение либо по Bluetooth, либо непосредственно по радиоканалу, по различным проприетарным протоколам. Это позволяет атакующему удаленно контроллировать весь клавиатурный ввод на компьютере, похищать данные, изменять их, добавлять свои. Злоумышленник может украсть ваши учетные данные, удаленно ввести какую-либо команду или изменить вводимую вами команду. Обычно такие атаки работают только на близкой дистанции, где-нибудь в общественном транспорте или кафе, однако с использованием антенны зона досягаемости атакующего сильно повышается. Пример взлома беспроводной клавиатуры. Также, беспроводное подключение клавиатуры позволяет относительно незаметно посылать записанные контроллером данные на контрольный сервер. Как вариант, беспроводная клавиатура, как, впрочем, и проводная, может записывать скорость печати пользователя, что является биометрическим идентификатором, а также работает ниже уровня защиты инструмента kloak, вновь обходя его защиту.
Следует отказаться от использования беспроводных клавиатур вовсе, полагаться на какую-либо защиту в этом вопросе слишком рискованно.

Следующий тип, USB, помимо проводного подключения, имеет также и отношение к беспроводному, так как рессивер подключается именно в порт USB. Проблема состоит в двух неприятных чертах спецификации USB: в возможности эмуляции всего подряд при подключении устройства и в большой кодовой базе. Первая неприятная черта, например, позволяет, подключая клавиатуру, дополнительно эмулировать и сетевое устройство, скрытое от пользователя. Оно-то как раз и будет перенастраивать внутренние маршруты трафика таким образом, чтобы все сетевые коммуникации шли через новое устройство. Эта атака уже позволяет вмешиваться во все сетевые соединения, а не только в клавиатурный ввод, получать весь незашифрованный трафик, теоретически вмешиваться даже в зашифрованный трафик, внедряя свой корневой сертификат. Немаловажной остается и атака BadUSB, суть которой состоит в подключении USB устройства, которое прикидывается клавиатурой и выполняет определенную последовательность действий без ведома пользователя.

И, наконец, последний стандарт ввода, PS/2, самый безопасный. Он самый старый из приведенных здесь, у него отсутствует возможность эмуляции других устройств, доступен только ввод данных с клавиатуры и, следовательно, сильно уменьшенная кодовая база. Он лишен недостатков предыдущего дуэта и, вдобавок, не имеет привилегий в системе пользователя и может работать с уровня SMM, если в ОС нет соответствующей реализации ввода. Кстати, в поддерживаемых Coreboot моделях Lenovo Thinkpad (T400-T430, например) клавиатура подключается как раз по PS/2, что добавляет им еще один плюс в копилку баллов безопасности.

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

Для защиты USB следует перенаправить все порты в виртуальную машину первого типа, аппаратно изолированную от всей остальной платформы и сделать её незапоминающей изменения при перезапуске. Также, эта ВМ должна останавливаться при блокировке экрана. Ввод же следует осуществлять через PS/2 клавиатуру и мышь (или тачпад). Также, следует контроллировать все подключающиеся USB устройства чем-то вроде USBKill или SilkGuardian, а такжее проверять сетевые маршруты и сертификаты на целостность. Помимо прочего, в новых ядрах версии 6.* появилась экспериментальная поддержка userspace-драйверов, то есть драйверов, работающих в пространстве непривилегированного пользователя, а не ядра.

Существует и клавиатура с открытой прошивкой- проект TMK, а также полностью открытая (на программном и аппаратном уровне) клавиатура Launch.

Мышь в плане опасности похожа на клавиатуру - в современных её версиях также нередко присутствует контроллер с памятью для макросов и несколько дополнительных кнопок, на которые их можно назначить. Плюсы мыши для атакующего состоят в её размерах - туда поместится несколько микроконтроллеров с самыми различными функциями. А сценарий атаки, по большому счету, тот же: запись кликов, BadUSB, эмуляция сетевого оборудования. Но есть и специфические для мыши атаки - запись биометрических показателей, таких как скорость движения мыши, хаотичность и дрожание курсора, быстрота кликов и тому подобное, а также интересная атака по стороннему каналу. Последняя позволяет сделать из мыши микрофон! Да, мышь может записывать звук, читателю не показалось. Справедливости ради, атака пока не развита и звук записывается разве что впритык и от мощной колонки, при условии высокой чувствительности сенсора мыши, но, как я и сказал во введении, не все атаки на данный момент полностью развиты и представляют по-настоящему серьезную опасность.

---

TrackPoint. Это альтернатива мыши, присутствующая в ноутбуках серии ThinkPad. Представляет собой джойстик, управляющий курсором. Поверхность атаки у него куда меньше, чем у мыши, но прошивка внутри все равно есть, а значит биометрия точно также может собираться и... все! TrackPoint изолирован по-максимуму. Хоть прошивка и проприетарная, доступа она ни к чему не имеет, поскольку клавиатура подключается по PS/2, а в самой клавиатуре она доступа не имеет. Места в нем для какого-то вредоносного модуля не хватит. Это значит, что передать собранную информацию наружу может только система, зараженная и на уровне TrackPoint, и на уровне внутреннего периметра. В целом, хоть опасность этого джойстика и невелика, знать о ней все же нужно.

Гипотетически, что-то вредоносное засунуть можно и в монитор, но пишу я о нем не поэтому. С этим компонентом компьютера связано две вещи: атака по сторонним каналам и возможность создать забавный монитор, изображение на котором будет видно только в специальных очках.

Начнем с первого. Атаки на монитор мне известно три: Side-Channel атака с использованием SDR, она же, но с использованием регулировки яркости экрана, о которой я говорил в разделе про EC, а также атака через передачу полезной нагрузки в порт.
Первая атака основана на электромагнитных волнах, которые испускает монитор, отрисовывая каждый пиксель. Улавливая их, можно воссоздать изображение с использованием одного только SDR-приемника. Есть [url=https://github.com/martinmarinov/TempestSDR]PoC[/ur], подтверждающий эту атаку.

Вторая атака передает информацию через незначительные изменения яркости экрана, которые могут улавливаться, например, камерой. PoC был, но ссылку я потерял =) Добавлю, если найду. Защитой послужит специальная пленка, позволяющая видеть изображение, только находясь непосредственно перед экраном. Часто её называют Privacy Filter.

Третья атака подразумевает наличие у жертвы зараженного монитора или кабеля. При подключении монитора либо в DisplayPort, либо через VGA, либо по HDMI, он передает компьютеру список разрешений, которые поддерживаются дисплеем. Проблема тут в том, что монитор может передать определенную структуру данных, которая, при наличии в модуле modsetting driver уязвимости, может вызвать, например, переполнение буффера или исполнение кода в пространстве памяти ядра, что звучит достаточно страшно, так как передать эту полезную нагрузку можно и не через монитор, а через микроконтроллер с соответствующим разъемом, который можно быстро подключить в соответствующий порт, просто проходя мимо. Описана соответствующая атака здесь паримерно на двадцать пятой минуте.

Защитой могут послужить специальные накладки на уязвимые порты, затрудняющие доступ к портам. Если паранойя мучает, можно залить их эпоксидной смолой, смешанной со стеклом, железными опилками и чем-нибудь горючим. А если хочется полноценной защиты, можно без потерь отключить эти порты физически, как описано в приведенном мной докладе, так как в ноутбуке разъемы VGA/HDMI/DisplayPort обычно не нужны (по крайней мере я ими ни разу не пользовался). Как вариант, можно ограничить "общение" по этим портам вместо полного их отключения, но все также паяльником.

Второй же пункт скорее развлекательный, но все же может пригодится, если вдруг вы используете LCD монитор. Из него можно удалить поляризационную пленку, вырезать из последней линзы для очков и, вуаля - теперь изображение видно только в этих очках. Подробнее тут. Со стороны будет выглядеть так, будто вы смотрите в белый экран. Звучит, конечно, забавно, но все же эта техника может быть использована в качестве альтернативы Privacy Filter, ограничивающей угол обзора пленке.

Играют роль энергонезависимой памяти, на которой в обычном случае хранится OC и большая часть данных.
HDD представляют собой вращающийся диск со специальными бороздами, так называемыми дорожками, на которые путем намагничивания записывается информация. Читается она, соответственно, путем считывания магнитного заряда с конкретной дорожки диска.

SSD хранит данные на flash памяти, то есть на чипе, состоящем из большого количества транзисторов, имеющих заряд 1 или 0. В зависимости от наличия или отсутствия заряда в систему передается единица или ноль соответственно.
В обоих видах дисков есть также своя отдельная память, в которой хранится прошивка, в нормальных условиях контроллирующая скорость вращения головки HDD, передачу заряда на транзисторы, считывания намагниченности и другие важные функции. Важно отметить, что на жестких дисках прошивка не загружаемая, она записана в самом диске и всегда хранится там же. Помимо памяти, хранящей firmware, на диске есть также маломощный чип с одним-двумя mips/arm/risc ядрами и небольшим количеством оперативной памяти. На этих ядрах и исполняется прошивка.
Еще до полноценного разбора всяческих вирусов и аппаратных атак, я хотел бы разобрать методы зачистки дисков, поскольку это важный этап в жизни каждого человека любого анонима и тоже своего рода низкоуровневая атака.

Так вот, в стандартной ситуации хороших способов есть три:

• Перезапись диска dd (/bin/sync && /bin/dd if=/dev/urandom of=/dev/sd* status=progress)
• Перезапись диска стандартной утилитой shred (/bin/shred -n 3 --random-source=/dev/urandom -f /dev/sd* && /bin/sync && /bin/shred -n 3 --random-source=/dev/urandom -fuz /dev/sd*). Плюс этого метода в том, что shred является частью coreutils, а значит содержится в любом дистрибутиве GNU/Linux.
• Перезапись диска srm в качестве альтернативы shred (/bin/sync && /bin/srm -D /dev/sd* или /bin/sync && /bin/srm -G /dev/sd*) -G перезаписывает методом Гутмана, в тридцать пять проходов, что на данный момент излишне, хватит и семи проходов с ключом -D в первой команде.
Дальше более экзотические методы:

• Загрузка в специальную ОС для зачистки данных. Примером этого может служить ShredOS или DBaN (проект широко известен сообществу, но уже не развивается, примите это во внимание).
• Использование надежного полнодискового шифрования, которое обеспечивает возможность безвозвратного удаления данных при удалении ключа шифрования (заголовка в том числе) и всех резервных копий оного.
• Применение технологии, которая обычно называется как-то вроде "Secure Erase" и является опцией в штатных BIOS компаний Lenovo, HP, Dell и других.
• Ту же технологию удаления можно использовать и с уровня операционной системы, что удобно при прошивке coreboot. С этим поможет команда hdparam или nvme-cli.
• Внешний диск можно полностью обнулить командой blkdiscard.

Команда sync необходима для синхронизации кэшей из памяти с кэшами на диске. Это поможет избежать сохранения удаляемых данных в памяти и автоматической записи частей этих данных (или данных целиком) на диск уже после удаления.

Где же здесь проблема? Она лежит, как это часто бывает, в фундаменте, в самой основе технологий HDD и SSD.
Первый хранит данные только на магнитной головке и в своей оперативной памяти во время их обработки. Больше нигде. Нет магнитной головки - большая часть данных удалена. И удаляется информация с HDD простым перезаписыванием случайными данными в несколько проходов и финальным проходом с нулями. Так конкретный LBA (logical block address, адрес логического блока, адрес блока данных на диске) точно затирается, поскольку система взаимодействует с ним напрямую через контроллер, который просто транслирует указания ОС на диск ввиде вращения головки и считывания/записи заряда на нее.

Во втором случае, в случае использования SSD, ситуация совсем иная. Там ОС также посылает команду удаленрия данных с конкретных LBA, но они только помечаются как удаленные и операционная система их не видит, а в самом SSD происходит магия.

Так вот, SSD были созданы как быстрая, долговечная и безопасная альтернатива HDD, а потому в них была реализована технология "перемешивания данных". Как понятно из названия, она регулярно перемещает данные по секторам для равномерного износа flash памяти. Вторая технология называется Trim и занимаетсяона очисткой блоков данных, помеченных ОС как неиспользуемые, заполняя их нулями. Операцию Trim можно производить консольной командой, а можно и не производить, так как диск в любом случае делает её сам. Реализована она для ускорения диска, поскольку незанятые диски работают быстрее, чем заполненные.
Однако тут, как всегда, не без проблем. Во-первых, реализация этих технологий может хромать, а значит и производимые операции могут выполняться с ошибками или не выполняться как ожидалось. В особенности это касается следующей, третьей технологии, о которой речь пойдет чуть ниже. Во-вторых, перемешивание может мешать действительному удалению данных, поскольку программа удаления уровня ОС перезаписывает область, где хранятся данные, а они в этот момент были перемещены в другое место целиком или частично, что, соответственно, помешало их абсолютному удалению.

Казалось бы, сам диск должен пометить данные как мусор, а Trim уж с ними разберется в автоматическом режиме... но не тут-то было! Вторая проблема, которая частично нивелирует попытки удаления или восстановления данных состоит в схеме работы двух вышеописанных технологий. Если конкретнее - диск включается сразу после подачи на него питания и встроенная прошивка начинает работать, даже если не было команды с уровня OC, даже если диск просто подключен через адаптер в USB порт и никаких манипуляций с ним не производится. При этом, действительные операции с данными контроллирует также прошивка, самостоятельно решая, когда и каким образом исполнять команды системы. Следовательно, "удаленные" данные могут оставаться на диске еще долгое время, не будучи затронутыми операциями Trim.

С удалением и двумя из трех технологических нюансов разобрались, теперь поговорим третьей важной технологии в SSD дисках. Да, относится она только к SSD, поскольку HDD с ней я не встречал. Речь о так называемых SED или Self-Encrypting-Disks. Суть их в наличии дополнительного аппаратного компонента, шифрующего все поступающие на диск данные. Обычно AES-128 или AES-256, но встречаются и другие алгоритмы. Эта схема позволяет изолировать данные от системы в "доверенном и безопасном" анклаве, проводя операции шифрования на этом самом чипе, позволяет доставлять на диск только зашифрованные данные и "абсолютно надежно защитить данные пользователя". Это, конечно же, не так.

Более того, по ряду нижеизложенных причин все проприетарные (а открытых-то и нет!) Self-Encrypting Disks есть не более чем клоунада, не имеющая ничего общего с безопасностью.
Во-первых, этот класс устройств особенно чувствителен к реализации криптографических примитивов, которые, как показывает практика, весьма и весьма уязвимы: то XOR вместо AES подсунут, то во всех прошивках используют один заданный на заводе ключ шифрования, то мастер-пароль один на всех оставят.
Во-вторых, диск можно переподключить к другому устройству после расшифровки, так как ключ остается в памяти диска и при переносе никуда оттуда не исчезает. К атакующему, таким образом, попадет уже расшифрованный диск. Пример атаки.
В-третьих, как я уже упоминал, открытых реализаций ни на программном, ни, уж тем более, на аппаратном уровне не существует.
В-четвёртых, поддержка их в GNU/Linux все ещё остается на весьма плачевном уровне. В частности, при использовании SED не работает S3 sleep, режим сна системы.
В-пятых, производителем всегда является коммерческая компания, имеющая, вероятно, намеренно оставленные в прошивке уязвимости или так называемые мастер-пароли, позволяющие восстановить данные при утере пароля.

Кстати, в спецификации OPAL 2, в которую входят и SED, есть возможность создавать области диска, доступные на чтение/запись/совсем недоступные. Манипуляция такими областями доступна только с паролем администратора диска. Даже если это звучит надежно, я, в свете изложенного выше (и ниже), на месте читателя не стал бы доверять производителям дисков и надежности их работы.

Теперь наконец-то поговорим об атаках. Первая атака весьма очевидна. Состоит она в протроянивании прошивки диска, что приведет к гипотетической компрометации системы и/или данных на диске. Пример повествует о взломе прошивки HDD через Debug разъем, который почему-то не был закрыт. Замененная через аппаратную перепрошивку firmware позволяет проводить самые различные манипуляции с диском: менять данные (например, пароли, ключи), похищать их, компрометировать цепочку загрузки, добавлять вредоносные модули в систему.

Тем не менее, атака эта практически не опасна при учете использования правильного полнодискового шифрования и IOMMU, которые одновременно заблокируют возможный DMA и не позволят изменять данные каким-либо образом.
Следующая атака уже относится к SSD и основана она на механизме изменения соотношения доступного пользователю объёма дискового пространства (user capacity) и общего объема дискового пространства (raw capacity). Соотношение это регулируется в зависимости от нагрузки на диск (выше я описывал, что пустые SSD работают быстрее, чем заполненные хотя бы наполовину). При этом, поскольку SSD есть отдельный анклав, работающий, грубо говоря, сам по себе, область вне доступной пользователю не видна системе и работающему в ней антивирусу или подобному сканеру. Атакующий, регулируя нагрузку на диск, а значит и доступный операционной системе объем данных, может разместить свою вредоносную программу на границе доступной и недоступной области и спрятать её от обнаружения антивируса. Эксплуатация спрятанной угрозы совершенно различна.

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

Следующая проблема в ненадежности зачистки жестких дисков. Если конкретно, то вне зависимости от выбранного способа заполнения запоминающего устройства случайными данными, очищается не весь диск - некоторые участки не затрагиваются и в них может сохранится как вредоносный файл, так и ключ шифрования, что в равной степени опасно. Таких областей существует четыре: DFA, HPA, raw capacity и DCO. Подробнее тут. Про третью мы говорили в предыдущем абзаце про атаки на диски, а вот про DFA, HPA и DCO поговорим подробнее.
Суть трех этих областей в отделении части общего дискового пространства под нужды диска или платформы.

При этом HPA (Host Protected Area) присутствует и в HHD, и в SSD. Она выделяется диском или BIOS для нужд системы: для резервных копий, кэша, диагностики загрузки, восстановления системы, для нужд прошивки конкретного OEM. Эта область не видна с уровня операционной системы штатными средствами и не отображается как неразмеченная область. Её будто бы просто не существует. Тем не менее, эта область может сохранять части данных с диска, там могут обитать rootkit'ы (В частности, созданная NSA вредоносная программа SWAP использует BIOS и HPA для исполнения своего кода до загрузки операционной системы), там можно что-либо вредоносное спрятать. То, что в нужный момент сработает или будет использовано. Обнаружить такую область можно командой hdparam -N /dev/sdX*

Тем не менее, использовать эту область можно и в своих нуждах. Можно сделать там свой собственный зашифрованный скрытый раздел, который не будет виден с уровня ОС. Правда я не думаю, что криминалисты совсем уж глупцы и не смогут обнаружить это с помощью автоматических инструментов. Следовательно, наилучшим вариантом будет затереть весь диск, отключить HPA, надежно зашифровать весь диск и использовать систему как обычно. Также, лучше шифровать диск полностью и сразу, дабы исключить попадание незашифрованных данных в HPA.

DCO (Device Configuration Overlay) присутствует только на HDD (как я понимаю, параметры диска хранятся в прошивке и выдаются ей же). Она, как раз наоборот, не должна взаимодействовать с пользователем, поскольку она нужна для конфигурации диска и создана OEM. В неё записывается реальный размер диска, поддерживаемые им функции, команды контроллера и так далее. Как вариант, можно сделать резервную копию этой области, если диск достаточно доверенный. При случае, можно её восстановить вместе с остальными действиями по удалению вируса, исключив таким образом сохранение угрозы на диске. Тем не менее, удалять эту область нельзя, она, в отличии от HPA, необходима для работы HDD.

Третья закрытая область диска, DFA (Disk Firmware Area. Иногда её называют также service area), как ясно из её названия, используется прошивкой в некоторых дисках для хранения части своих модулей в недоступной области диска. Это могут быть модули для SMART, для манипуляций с Bad Blocks, с поврежденными блоками, модули P-list и G-list (содержат сервисную информацию о блоках, секторах, их использовании и т.д.). Удалять её тоже не рекомендуется, даже если есть возможность.

Таким образом, удаленные и даже затертые данные и на HDD, и на SSD могут быть на самом деле сохранены в потайных областях диска, либо в видимой области диска благодаря технологиям SSD. Self-Encrypting Disks ненадежны и использовать их не стоит. Сами по себе диски представляют из себя маленькие компьютеры, в случае с SSD работающие практически сами по себе. Нередко происходят заражения прошивок различным вредоносным ПО, не зависящим от установленной ОС и эту самую установку переживающим.
К большому сожелению, готовых открытых прошивок для HDD/SSD не существует. Однако, есть еле живой проект OpenSSD.
Для защиты дисков необходимо удалить HPA (если она есть), включить IOMMU, надежно зашифровать весь диск целиком, проверять целостность прошивки (прошивки диска и прошивки контроллера, если таковая есть) и драйверов.

Многие думают, что MicroCD являются отличным решением для хранения как зашифрованных секретов, так и данных в целом. А что такого? Они маленькие, очень даже ёмкие, относительно быстрые и дешевые, при случае легко ломаются даже пальцами которые ещё не сломаны молотком господ криптоаналитиков. Эти преимущества действительно неоспоримы, но есть, как говорится, один нюанс.

Оный состоит в строении этого вида носителей. Если точнее, то абсолютно все подобные носители памяти являются небольшими микроконтроллерами, имеющими, в основном, ARM процессоры с частотой около 100 Мгц, что хоть и небольшие, но все же хоть какие-то мощности. Это, как и в случае с SSD дисками, означает, что при подаче питания на носитель, включается небольшой компьютер со своей прошивкой, имеющей закрытый исходный код и самые различные возможности, обоснованные типом подключения - корпусный разъем для cd карт, который также имеет DMA доступ. Вдобавок, существуют cd карты с встроенным Wi-Fi (документированный), внутри которых находится полноценный GNU/Linux, который может быть взломан и в любой локальной сети файлы на таком носителе могут быть легко и незаметно скомпрометированы.
При этом, уже было проведено исследование, доказывающее опасность прямого подключения данных устройств.

В качестве защиты рекомендую подключать microcd исключительно через USB адаптер, что обеспечит изоляцию этого микрочипа от основной системы, а при наличии соответствующего порта на корпусе, залить таковой эпоксидной смолой и, найдя соответствующий контакт на схеме ноутбука, отпаять его, отключив разъем насовсем, поскольку, как уже было упомянуто, смола не является полноценно надежной защитой. Также, во избежание проблем с DMA, в очередной раз упомяну о необходимости наличия должным настроенного IOMMU. Само собой, следует избегать карточек с встроенным Wi-Fi, либо прошивать их и защищать от атак встроенный GNU/Linux. Для большей степени защиты от атак с использованием внешних USB устройств таковые стоит монтировать в виртуальную машину, куда при запуске компьютера перенаправляются соответствующие порты, как это реализовано в Qubes OS. Это, в сочетании с этим инструментом (позволяет считывать данные с носителя без монтирования) и подключением cd карт через адаптер, позволит добиться наилучшей изоляции внешних носителей от основной системы.

При уничтожении памяти, необходимо ломать сам чип, поскольку даже если у microcd нет разъемов для подключения, даже если она не монтируется в системе совсем и даже если данные на ней были надежно затерты, атакующий может припаять провода к коннекторам на самом чипе и попытаться восстановить данные, к возможности восстановления которых следует относиться также, как и к таковой на SSD, поскольку тип памяти один и тот же, а технология смешивания применяется на многих современных micro cd. Таким же образом можно подменить и прошивку, поскольку она часто хранится на том же чипе, что и данные.

До сего момента мной были описаны основные типы современных носителей информации, однако остался еще один, наиболее предпочтительный для чувствительных данных.

Как бы странно это не звучало, но у данной формы хранения данных есть ряд неоспоримых плюсов:

• Дешевизна. Самые технологичные диски стоят в пределах доллара-двух за штуку.
• Заметность дисковых операций. На CD/DVD невозможно незаметно записать информацию, как и прочитать её. Даже не самый внимательный аноним элементарно услышит звук вращения диска, что при отсутствии легитимных операций с ним означает возможную компрометацию данных.
• Невеликая поверхность атаки. Оптические диски практически не уязвимы к DMA, поскольку, при подключении их по протоколу SATA, direct memory access возможен исключительно через специальный запрос к контроллеру, что можно легко ограничить с помощью IOMMU. Также, SATA-дисководы не могут быть использованы для HID атак, поскольку данный тип подключения подразумевает исключительно передачу данных и ничего более - BadUSB и HID с ним просто не сработают в силу аппаратной ограниченности контроллера и протокола.
• Малое количество уровней абстракции. Тут в пример могу привести отсутствие файловой системы как таковой, что также несколько снижает поверхность атаки.
• Сам диск представляет из себя простую болванку, не несущую в себе никакой угрозы и, более того, никаких активных компонентов.
• В дисководах не реализовано вышеописанных технологии смешивания данных и TRIM, а диск легко сломать или повредить при надобности. Это гарантирует надежное удаление данных.

Тем не менее, все не так однозначно. В дисководе все еще присутствует прошивка с закрытым исходным кодом, открытых аналогов которой мне найти не удалось. Сам же дисковод представляет собой небольшой компьютер, запускающийся при подаче питания на него. Точно также, как в случае с HHD и SSD. Вредоносная прошивка может попробовать совершить DMA атаку (Если не настроен IOMMU) или злонамеренные манипуляции с незашифрованным содержимым диска (подмена, кража, модификация). Firmware дисковода может быть модифицирована при наличии root-доступа на целевом хосте с помощью инструмента flasher, например.

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

Здесь пойдет речь, как ясно из названия, об общей защите платформы, различных портах, имеющих проблемы с безопасностью, о нейтрализации атак по сторонним каналам и о новых атаках этого типа. Без лишних слов приступаем.

Сначала поговорим о чипе безопасности, о Trusted Platform Module или TPM. Это небольшой чип, располагающийся на шине LPC, который обладает собственной закрытой прошивкой, оперативной и энергонезависимой памятью, собственными часами, криптографическим модулем и генератором случайных чисел. Здесь речь пойдет только об отдельном аппаратном компоненте платформы, так как fTPM был рассмотрен ранее, в разделе об IME, а о sTPM я расскажу в следующей части.

Ряд проблем TPM вполне понятен:

• Код прошивки закрыт, в силу чего провести её аудит не получится. Следовательно, полностью доверенным он быть не может.
• Реализация криптографии на уровне прошивки также не проходила аудит.
• Чип TPM может использоваться в DRM, то есть в блокировке защищенного авторским правом контента.
• Криптографические алгоритмы TPM версии 1.2 устарели и непригодны для надежной защиты информации. SHA-1 был взломан еще в 2005, а RSA в будущем спасует перед квантовыми компьютерами.
• Aппаратная структура чипа также полностью закрыта и не исключает наличия закладок.
• Aппаратный генератор случайных чисел может быть либо реализован с проблемами, либо содержать намеренно оставленные уязвимости, что позволяет атаковать производимое в чипе шифрование даже при гипотетическом наличии альтернативной прошивки и надежной реализации криптографических примитивов. То же касается реализации отдельного компонента TPM, занимающегося криптографическими вычислениями.
• "Общение" TPM с остальной платформой может быть скомпрометировано с помощью LPC сниффера, который и похитит находящиеся там данные.
• При наличии физического доступа и достаточного количества времени TPM может быть успешно атакован.

При этом, все не так плохо. Программная часть существует в разных вариантах с открытым исходным кодом: от Microsoft и от свободного сообщества.
Также, все ключи можно сгенерировать самостоятельно, можно задать сильный пароль и настроить доступ к чипу. По сути "захватить" TPM под свой контроль и запретить дальнейшую смену владельца, соответствующим образом настроив чип.
RSA пока что не сломали, а значит подписанные TPM данные в целом можно считать защищенными.
От LPC сниффинга тоже можно защититься, о чем далее.

Помимо ранее сказанного, TPM интересен нам наличием PCR или регистров, которых там немало даже в версии 1.2. В эти регистры записываются логи measured boot (есть в разделе "security" меню coreboot). Эти логи показывают целостность прошивки и различных компонентов загружаемой платформы. Это позволит проверить целостность системы на уровне initrd например (так можно делать только в случае настройки vboot и переведения SPI памяти в режим read-only. То есть проверять лог TPM исключительно для собственного успокоения, поскольку во всех других случаях платформа может быть скомпрометирована, а проверка логов на таком позднем этапе разве что уведомит пользователя об этом).
Либо, можно настроить linux payload в coreboot и проверять лог measured boot в самом начале загрузки, что позволит предотвратить ввод пароля в скомпрометированной среде, однако расширит поверхность атаки, о чем пойдет речь в разделе про BIOS, который будет уже во второй части.
Также, в памяти TPM можно хранить пользовательские данные. Например, можно хранить часть ключа на флешке с разделом /boot, а часть - в TPM, что позволит разделить ответственность за хранение ключа между как минимум двумя технологиями (упомянутый в модели угроз Defence-in-Depth во всей красе) и усложнит жизнь атакующему.

Теперь об уязвимых портах. Таких достаточно в каждой платформе. Ipso facto, проблемы всё те же: торчащий наружу DMA, новые порты с более быстрым DMA (быстрее порт - быстрее доступ к вашим ключам!), взаимодействие с структурами ядра путем получения данных из внешнего устройства, атаки по сторонним каналам.

Одна из самых опасных шин - PCI. На ней находятся разъемы m2, pci-e, pci-x, express card slot, cd card slot, thunderbolt, firewire. Эти порты, как уже было сказано, имеют прямой доступ к памяти, а значит подлежат отключению/физическому уничтожению.
Уничтожить порты можно несколькими способами:

Предупреждение! Говорил об этом ранее, но скажу еще раз. Внесение тех или иных модулей в черный список может нарушить штатную работу системы. Сделайте полную резервную копию и подойдите к вопросу со всем возможным тщанием, не нужно использовать "метод научного тыка"!

• Добавить в черный список драйвер, отвечающий за тот или иной порт.

Делается это путем создания файла с расширением .conf в /etc/modprobe.d/
В файл записываются строки вида:
install название_модуля /bin/true
Это исключит задействование модуля пока эта строчка есть в конфигурационном файле.

Есть и более мягкий способ:
blacklist название_модуля
Этот способ запретит автоматическое добавление модуля, но при специальном его использовании команой modprobe он будет использован.



Подлежат удалению модули:
Firewire:

• firewire-core
• firewire-ohci
• firewire_ohci
• firewire-sbp2
• firewire_sbp2
Thunderbolt:

• thunderbolt
Express Card:

• pcmcia_core
• pcmcia_rsrc
Cd card slot:

• tifm_sd
• tifm_core
VGA:

• modesetting


Проверьте через lsmod и lspci используемые вашей платформой модули. Если кто желает исследовать вопрос с отключением модулей более подробно, то модули ядра расположены в /lib/modules/версия ядра/kernel/drivers/. Там все распределено по папкам, сложности с поиском вряд ли возникнут.

• Залить порт (контакты порта) эпоксидной смолой.
• Отпаять контакты, отвечающие за подачу питания на порт или за его взаимодействие с системой.

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

Атаки на порты могут быть реализованы с помощью различных специализированных устройств. Такие продают компании Keelog и Hak5. В ассортименте есть переходники-кейлоггеры для USB, Ethernet, DVI/VGA/HDMI. Причем последние даже видео в FullHD записывают и имеют встроенную память на 16 Gb. Все работает без каких бы то ни было драйверов, настроек и абсолютно кроссплатформенно. В разделе о RAM есть описание еще одного устройства.

Есть еще известные USB Rubber Duck, EvilCrow, BashBunny, LAN Turttle и другие, но о них многие и без меня знают. Функционал у них схожий: устройство программируется для эмуляции устройства ввода, чаще всего клавиатуры, а при подключении в атакуемый компьютер оно исполняет установленные заранее команды, заражая компьютер жертвы. Сценарий атаки может быть абсолютно любым, поскольку на обычных ОС такой ввод ничем не ограничен, а права доступа слишком мягкие.

[qoute]
Также, в сети есть информация, полученная якобы из опубликованных Сноуденом документов, описывающие подобные устройства, использующиеся АНБ. Выглядит сомнительно, но можно почитать здесь.
[/quote]

Защититься можно скриптами вроде usbdeath или модулем ядра silk guardian при работе в недоверенной среде. При более мягких условиях работы хватит и usbguard, который просто блокирует работу со всеми недоверенными usb-устройствами, но не исполняет никакого панического сценария с зачисткой оперативной памяти и перезагрузкой.

Помимо портов, на платформе есть также несколько контроллеров. Мы рассмотрим USB и SATA.
Первый, как известно, отвечает за работу с USB устройствами и проблем в нем как таковых нет. Нюанс в возможном требовании закрытой прошивки. Я с таким не сталкивался, обычно встроенная в coreboot или в ядро GNU/Linux-libre прошивка для USB справляется. USB в целом является одним из самых безопасных протоколов, если не учитывать возможные проблемы в драйверах, но, как я уже упомянул выше, достаточно изолировать стек USB с помощью Xen и использовать userspace-драйвера, экспериментальная поддержка которых уже есть в новых ядрах версии 6.*.

Второй контроллер отвечает за работу с SATA-дисками. DMA в штатной ситуации он не имеет, но подключенный к нему диск может отправить запрос для DMA.



Для защиты стоит либо использовать USB диски, либо внутренние, но с сильным IOMMU, желательно запускающемся на уровне инициализации coreboot, то есть почти сразу после включения. Важно также включить очистку RAM в процессе загрузки (Есть в разделе "security" в настройках coreboot) при использовании таких дисков дабы исключить попадание зловредного кода в оперативную память полностью загруженной ОС.

Теперь пара слов об общей защите от атак по сторонним каналам и от анализа платформы.

• Для защиты от различного излучения, распространяющего информацию вовне, требуется экранировать либо комнату, в которой проходит работа, либо корпус устройства сеткой Фарадея или чем-то подобным. Да, звучит как излишняя паранойя, но не забываем об описанной в начале статьи модели угроз.
• Для защиты от анализа платформы и оборудования следует:
• Cтереть маркировку всех микросхем (предварительно её записав на шифрованный носитель, вам-то самому она понадобится чуть что!).
• Залить все важные чипы (TPM, BIOS flash ROM, чип с прошивкой диска (находится на нём самом) эпоксидной смолой. Некоторые советуют ещё заливать смолой ОЗУ, но я не думаю, что это необходимо, хотя каждый сам делает выбор.
• Удалить паяльником или залить эпоксидной смолой все отладочные контакты (UART, например), контакты чипов и дорожки к ним. Это поможет против LPC-сниффинга и подобных атак, когда злоумышленник припаивает анализирующую аппаратуру к чипам или дорожкам и получает секретные данные с её помощью.
• Балансировать энергопотребление. Это поможет против некоторых side-channel атак и против некоторых видов криптоанализа, в том числе и внешнего.
• В дополнение к предыдущему пункту я бы посоветовал использовать алгоритмы шифрования из группы AEAD (доступны в LUKS2), которые выбирают для каждого блока случайный вектор инициализации. Exempli gratia, это может быть алгоритм morus или aegis, доступные в ядре GNU/Linux (возможно, придется пересобрать и включить их при сборке в разделе Crypto API).

И последний пункт в этом разделе. Одна side-channel атака, отнести которую к другим разделам не представляется возможным. Она представляет собой заражение ОС специальным вирусом, который передает похищенные данные через аудиоканал путем приложения особой нагрузки на блок питания, что и заставляет его "пищать" эти самые данные наружу. Находящийся рядом оператор может уловить... ах, да, оператор никакой и не нужен, у многих ведь рядом с рабочим устройством лежит смартфон! Он с этим прекрасно справится. Еще одна форма Cross-Device tracking получилась.

Что же, в этой, надо признать, досаточно объёмной статье мы разобрались со многими аппаратными и микропрограммными проблемами безопасности, о которых мало кто говорит. Надеюсь, что читать это графоманство было интересно и полезно всем обратившим на него внимание.

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

Итак, для защиты требуется:

На аппаратном уровне:

• В идеале, необходимо собрать рабочую станцию с учётом проблем безопасности, а значит на не-x86 архитектуре. На RISC-V или POVER9, как вариант. ARM, кстати, также доверенным не является, но о нём в следующей части.
• Использовать платформу со свободной и поддерживаемой прошивкой для EC.
• Также, необходимо удалить из платформы динамики, микрофоны, веб-камеры, встроенную сетевую карту, дискретную видеокарту.
• Замена встроенной NIC на внешний адаптер.
• Все ненужные и опасные порты необходимо либо залить эпоксидной смолой, либо ограничить физически, с помощью пайки.
• Нужно cтереть маркировку всех микросхем, залить той же смолой все важные чипы безопасности, такие как TPM и SPI.
• Использовать для важных данных CD/DVD диски.
• Для MicroCD применять USB-адаптеры.
• Использовать PS/2 клавиатуру и мышь/touchpad.
• Исключить использование SED или дополнять их программным шифрованием.
• Применять специальные резиновые накладки на порты.
• Использовать NIC без поддержки BlueTooth.
• Настроить TPM со своими ключами, сильным паролем и настройками.
• Обновлять microcode процессора или использовать последнюю доступную версию.

---


На уровне BIOS/UEFI:

• Требуется прошить coreboot с соответствующими настройками, организовать Root-of-Trust для доверенной загрузки.
• Настроить vboot, measured boot.
• Применить очистку оперативной памяти при загрузке.
• Перевести чип в режим read-only.
• Настроить проверку подлинности ядра, initrd c помощью grub2.
• Генерировать GBE и Flash Descriptor самому, настраивать в последнем права доступа.
• Уменьшить ME, ограничить к нему доступ на всех уровнях.
• Включить Chipser Lockdown.
• Отключить Ethernet (в ноутбуках).
• Включить STM.

---


На уровне гипервизора:

• Организовать изоляцию крупных отделов ядра посредством виртуализации, как это реализовано, например, в Qubes OS. Для этого требуется изучить Xen и так называемые Driver VM.
• Применить технику dom0 disaggregation, подразумевающую максимальное облегчение административной виртуальной машины Xen.
• Разделять свои разные сетевые личности по разным виртуальным машинам.

---


На уровне ОС:

• Включить все возможные аппаратные технологии защиты, такие как IOMMU. Делается это в /etc/default/grub в строке CMDLINE_LINUX_DEFAULT. Для IOMMU параметры такие: intel_iommu=on strict_iommu=1
• Балансировать элекртопитание. PowerTop и подобные утилиты в помощь.
• Использовать FDE (полнодисковое шифрование). По-хорошему, это должен быть Plain dm-crypt с одним-двумя разными шифрами (проверенными временем, вроде AES, Twofish, Serpent), а в нём LUKS2 с шифром AEAD (Aegis, morus). Это позволит добиться бессигнатурного шифрования с разными шифрами, устойчивого к расшифровке и недоказуемого (в плане его наличия в принципе). Также, имеется возможность простой смены ключа и быстрого приведения системы в негодность, поскольку для этого достаточно затереть заголовки раздела LUKS2.
• Дополнить доверенную загрузку технологиями IMA/EVM и подписью модулей ядра.
• Использование SELinux для изоляции приложений. Хотя бы самых опаcных, воде браузера и PDF-читалки.
• В идеале, применять source-based дистрибутивы, такие как Gentoo и GNU/GUIX и компилировать всю систему с безопасными параметрами, минимизирующими вероятность различных бинарных уязвимостей: переполнения стека, кучи, Use-After-Free и других.
• Применять GNU/Linux-libre.
• Использовать свободные реализации ПО везде, где это только возможно.
• Удалять вредные или опасные модули в modprobe. Для этого в файл /etc/modprobe.d/modules.conf записываем строки install название /bin/true. Сами модули есть в статье.
• Отключать HPA на дисках.
• Настроить остановку VM при блокировке экрана.
• Применять LuksSuspend при блокировке экрана.
• Настроить защиту USB портов. SilkGuardian, usbdeath.
• Монтировать недоверенные USB носители через usbSAS.
• Настроить мониторинг не только USB, но и любых других портов.
• Применить GNU/Linux hardened ядро.
• Проверять лог measured boot на уровне initrd.
• Использовать открытые реализации драйверов, прикладного ПО для TPM.
• Проверять подписи всех программ и обновлений.
• Запускать программы от отдельного, непривилегированного пользователя.
• Сделать систему "невидимой" в локальной сети.
• Отключить шифрование средствами NIC, перевести его на процессор.
• Использовать Red Pill.

Есть мнение от уважаемого ЕУ, что, помимо виртуализации в целом, нужно делать так:

цитата:

Хакерский подход: берём виртуализатор на принципе динамической трансляции кода и эмулируем компьютер внутри компьютера, таким образом чтобы внешнее железо
и софт не могло определить что вообще происходит внутри. Считаем ВСЮ систему адом с чертями и внутри делаем кусочек изолированного вычислительного пространства.
Это примерно то-же что в примере с телефоном, только вывернуто наизнанку, чёрный ящик находится снаружи а не внутри. Чисто хакерский, а не инженерный подход.
Получаем падение производительности в 2-5 раз от аппаратной, вполне преемлемо. Кое-кто когда-то давно в такой среде даже игры запускал, для теста. Надо будет написать на эту тему статью...

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

• BIOS/UEFI, загрузочные прошивки.
• IPMI, BMC, чипы удаленного управления.
• Более подробный разбор AMD в целом и PSP в частности.
• Системный уровень ОС и нехорошие его детали. Polkitd, DBus, SystemD и тому подобное.
• Ядро GNU/Linux и его проблемы.
• Подробный разбор рабочих станций на альтернативных, не-x86, архитектурах.
• Разбор GSM модуля и встроенных PCI WWAN модемов в ноутбуках и PC.
• 3G/4G модемы.
• Android и нюансы безопасности его аппаратной и программной части.
• Аппаратные токены безопасности. Nitrokey, Ybikey и другие.
• Роутеры и их прошивки, аппаратные проблемы.
• Принтеры и их проблемы.
• Проблемы безопасности драйверов и ring1.

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

Также, у меня есть небольшое обращение к администрации. Даже если мои труды не сочтут значимыми и я не получу часть конкурсного вознаграждения, я бы хотел получить статус участника на форуме, дабы почитать скрытые от моего взора разделы/раздел.