Несколько месяцев назад исследователь Траммел Хадсон (Trammel Hudson) создал эксплойт под названием Thunderstrike, который мог инфицировать компьютеры Mac через устройства, подключенные через разъем Thunderbolt. При подключении к зараженному компьютеру новых устройств червь записывался на них, таким образом под угрозой оказывались и другие машины.
Apple исправила уязвимость в OS X версии 10.10.2, однако, как сообщает издание Wired, Хадсон и еще один ИБ-исследователь Ксено Кова (Xeno Kovah) разработали новую версию эксплойта и опубликовали буткит и червя, заражающего компьютеры Mac.
Как и предшественник, Thunderstrike 2 распространяется главным образом через зараженные Thunderbolt-устройства. Однако в отличие от первой версии червя, теперь для проведения атаки злоумышленнику не нужен физический доступ к компьютеру.
По словам исследователей, вредоносный софт может попасть на компьютер с помощью «фишингового email-сообщения или специального сайта». После попадания на компьютер, червь заражает устройства, которые используют для подключения Option ROM (например, адаптер Thunderbolt и Gigabit Ethernet, внешний SSD или даже RAID-контроллер). После того, как червь записан на устройство, он может атаковать любой Mac, к которому его подключат.
Главная опасность зловредов, действующих на уровне прошивки, заключается в том, что в настоящий момент антивирусный софт и другие инструменты для обеспечения безопасности фокусируются на работе с RAM и файлами, хранящимися на компьютере. Поэтому червя, вроде Thunderstrike 2 крайне сложно обнаружить. При этом, специфика атаки, делает возможным ее осуществление даже для устройств, не подключенных к интернету, говорит Кова:
Допустим, у вас есть завод по производству центрифуг для переработки урана, который, само собой, не подключен ни к каким сетям. Но люди приносят свои ноутбуки или внешние накопители и, возможно, подключают их к внутренней сети по Ethernet, чтобы перебросить данные. В этих SSD есть Option ROM, который потенциально может быть заражен. Если мы говорим о хорошо защищенной сети, то там вряд ли используется WiFi, все подключено через Ethernet-адаптеры. В них тоже есть Option ROM, прошивка которых может быть заражена.
Исследователь вспоминает знаменитого червя Stuxnet, который атаковал иранские ядерные объекты и распространялся с помощью USB-флешек (мы публиковали исследование уязвимостей промышленных систем управления). В тот раз атакующие использовали уязвимости нулевого дня в Windows, что оставляло специалистам пути для отслеживания атаки. «Все знают, куда нужно смотреть в таких случаях», — говорит Кова. Но червь в прошивке — это совем другое дело, потому что сама прошивка контролирует то, что видит в ней операционная система (а значит, червь может перехватывать соответствующие запросы и выдавать в ответ «чистые» копии кода).
Производители прошивок могли бы повысить безопасность своей продукции, если бы они начали криптографически подписывать софт и его обновления, кроме того, устройства, работающие с помощью этой прошивки, должны уметь проверять эти подписи. Кроме того, не помешал бы и «переключатель» чтения/записи, чтобы предотвратить несанкционированную перезапись прошивки. Впрочем, это поможет защититься от хакеров-одиночек, но не от специалистов, работающих на могущественные спецслужбы (которые могут просто похитить мастер-ключ производителя софта и подписать свой вредоносный код с его помощью). Ранее в прессу попадала информация о том, что активную работу по взлому различных прошивок ведет Агентство по национальной безопасности США.
Исследователи предлагают производителям добавить возможность проверки контрольной суммы, которая показывала бы, менялся ли софт после установки на компьютер. Однако вендоры вряд ли будут заниматься чем-то подобным, поскольку подобные нововведения потребуют значительных изменений в архитектуре систем, а пользователи в данный момент еще не задумываются о том, что нужно думать и о безопасности прошивок.
В 2014 году Кова и его коллега по компании Legbacore Кори Калленберг обнаружили целый ряд уязвимостей прошивок, которым подвержены до 80% всех PC (включая продукцию Dell, Lenovo, Samsung и HP). Впоследствии исследователи выяснили, что аналогичные атаки можно осуществить и на компьютеры Mac.
CodeRush
Все это возможно только потому, что производители оборудования для конечного пользователя не видят никакой необходимости заботиться о безопасности своих EFI-совместимых прошивок, в результате ошибки, обнаруженные пару лет назад, на большинстве систем так и не исправлены, а о новых и говорить нечего. К примеру, представленная на 31C3 в декабре 2014 атака на S3 BootScript (а именно ее использует упомянутый в статье червь) все еще работает на подавляющем большинстве систем с EFI/UEFI.
По настоящему безопасностью UEFI займутся только тогда, когда атаки на него выйдут из PoC-песочницы (момент уже очень близок), либо когда Intel и MS перестанут сертифицировать продукты, не проходящие валидацию Chipsec'ом и тестирование HSTI. Пока не произошло ни то, ни другое, поэтому нужно либо пользоваться системами тех, кому «не пофиг», вроде Dell или HP, либо брать безопасность в свои руки и все патчить самостоятельно. Про второй вариант я попробую рассказать на конференции ZeroNights 2015, если доклад одобрят.
khim
EFI? Проблемы появились заметно раньше (и опять, что характерно, в интерфейсе придуманным Apple). Но вообще эти чудеса — относительно недавнее изобретение: я хорошо помню что материнка для Pentium!!! продавалась ещё с аппаратной защитой от перепрошивки (просто джампер замкни — и ни один червь не прорвётся), а когда через год она умерла и я купил точно такую же, то там этот джампер был выкушен. Ещё через пару лет об этом уже все забыли (на более новых материнках джампер уже даже не предусмотрен конструкцией) — а теперь у нас, видите ли, черви появляются. Раньше нужно было думать.
CodeRush
Такую аппаратную защиту можно сделать и сейчас, ничего не мешает, только вот спроса на нее практически нет — никому снова нет дела до безопасности прошивки, а две микросхемы SPI (чтобы разделить изменяемые части вроде регионов GbE, ME и NVRAM от собственно региона BIOS) ставить дороже, чем одну. Более того, система с RO-прошивкой все равно подвержена эксплуатации через уязвимости в S3 и SMM, только приподит она не к персистентности, а «всего лишь» к повышению привелегий до уровня SMM-кода, что тоже весьма неплохо.
Что дейсвтительно надо сделать, так это, во-первых, планомерно уменьшать attack surface путем выкидывания из прошивки всего лишнего (а не добавления всего отдаленно показавшего нужным, как происходит сейчас), а во-вторых — проводить аудит, проверять и перепровеять прошивку перед выпуском. И если со вторым еще более-менее неплохо стало в последнее время (Chipsec, LUV, FWTS, HSTI, вот это все), то с первым у EFI и всей индустрии большие проблемы, которые никто не спешит решать.
Ivan_83
Это всё полумеры.
Порядок настанет тогда, когда:
1. будет аппаратный переключатель RO для биоса
2. будет открытый исходный код биос или как они его там сейчас называют, чтобы каждый мог лично собрать и убедится
3. возможно появятся какие то аппаратные средства для проверки содержимого биос (микрухи) без извлечения, типа цепанулся к специальному jack кабелем и сдампил/залил новый биос.
А всякие ЭЦП, контрольные суммы — они вообще никакой гарантии не дают, и могут спасти разве что от совсем пионеров.
Я думаю, что производители счасливы от того что это UEFI у них просто работает, какой уж там безопасность, важнее гуй красивее сделать и отрезать у проца фичи через msr или как его там.