The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Индекс форумов
Составление сообщения

Исходное сообщение
"Kernel.org подвергся взлому"
Отправлено Аноним, 02-Сен-11 12:46 
> Есть уже прототипы, которые себя в BIOS пишут. Не любой матери —
> но большинства распространённых.

Ну cih стирал только мамки с чипсетом Intel TX. Это был самый популярный в тот момент и принесло некоторую известность. На остальных фокус не работал, разумеется.

> BIOS'ы нынче на x86 жирные и не сильно отличающиеся у одного производителя пошли,

Чипсеты и чипы флеш-памяти весьма разнообразны. А чтоб в них таких еще и запатчить что-то, попутно не угробив систему до unbootable - высший пилотаж. А если учесть что ядро и его загрузчики постоянно меняются да еще и по разному сделаны в разных пингвинах и прочих... не, ну теоретически вроде можно, но практически такое дикое количество сочетаний получается, что кодить убьешься. К тому же всякие асусы и гигабайты, да и не только - очень любят кастомизировать биосы (и их прошивалки) под себя. Поэтому оно хоть и на основе стандартного, но имеет кучу левых особенностей, делающих их не всегда совместимыми с стандартными утилитами и прочая. Т.е. сделать нечто на 1 случай не вопрос. А вот чтобы работало более-менее универсально, с разными ос и версиями/апдейтами оных - вот это уже ж--а.

К тому же просто вписаться - недостаточно. Биосы имеют свойство проверять чексумы или даже подписи.

Об этом хотелось бы поподробнее заметить. В современных BIOS замечена инфраструктура для проверки цифровых подписей. Вам это о чем-то говорит? Кстати, в полной версии trusted computing нелегитимная модификация биоса приведет к просто отказу предыдущей части его запускать, так что сие потеряет смысл в качестве трояна. Правда, "небольшая" проблема лишь в том, что нынче данный вид технологии, будучи способен защитить юзера от хакеров очень кардинальными, термоядерными средствами, на практике гораздо чаще защищает производителя и медиа-барыг. От пользователя. Который считается чем-то типа хакера. В общем абсолютный максимум до чего можно довы... - до активации trusted computing в каждом компе, а с этим лично я вас не поздравлю, т.к. есть риск что после этого вы вообще будете кушать Единственно Правильную Систему (tm), "для вашего же блага", ту которую "минздрав" одобрит. Ну как в ифоне примерно. Там trusted boot уже реализован и активирован. И заставляет следовать генеральной линии компартии^W яблочной секты. С другой стороны, это очень мощное средство контроля целостности и построения системы которая доверяма на все сто. Только вот не принято мощные инструменты в неандертальские лапы отдавать.

> несколько килобайт места найти не проблема.

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

> Универсальные прошивальщики, знающие о многих BIOS'ах разом, видели? Дальше, думаю, понятно.

Видел. Flashrom называется. Есть в пакетах линя, даже с исходниками.
Но даже он...
- На знает все чипы флеша.
- Не все чипсеты поддерживает.
- Ряд мамок, особенно от гигабайта - с двойным биосом. Чип с базовой версией перешить проблематично, насколько я знаю.
- На куче мамок нынче обитает кастомная "полуаппаратная" защита от незапланированной записи в флеш: до того как получится писать в флеш, надо поменять состояние некоего I/O пина чипсета, посаженного на вывод "write protect" флешки, например. При том, каждый производитель мамок норовит поюзать тот пин чипсета который удобен лично ему (в плане его разводки по плате или просто по вкусу левой пятке). Как делать разрешение записи - ну родной фирменный прошиватор знает. Учтя что это знание актуально в рамках только 1 чипсета, 1 производителя мамки и едва ли нескольких моделей мамки - довольно сложно набрать базу на вообще все мамки в мире. Тот же flashrom например умеет шить далеко не все, очень много - совершенно без гарантий и "ну попробуйте, на свой страх и риск, если у вас есть рядом второй PC и программатор".

Кстати, на подумать: например у интела в ноутах "BIOS" по факту содержит намного больше чем BIOS. В той же флешке низкоуровневые конфигурационные параметры ранней инициализации, фирмваре небольшого служебного системного процессора управляющего питанием/вентилями/прочая, фирмваре сетевой карты, etc, etc. А то что видно как BIOS - лишь часть этого айсберга на самом деле.Формально, чипсет вообще не дает доступа в эти области на запись (теоретически). А вот как оно там практически (а также что делают эти фирмвары и нет ли там багов и бэкдоров) - другой вопрос.

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

Что значит - поздновато? Пакет с кривой подписью можно поставить если вручную это форсануть. Ну если вы это форсанули - вы наверное знали на что шли, или где?!

> Ежедневные (или даже ещё более частые) проверки целостности — уже лучше,

В случае именно руткита - может и не помочь, поскольку злобный руткит вполне может немного "поправить" системные вызовы. Допустим подшили вы себя (руткит) к некоему файлу. Ну допустим в хвост. Пусть добавив еще 2Кб. Тогда при вопросе какой размер файла - надо соврать на 2 кб, а при чтении более чем (истинный размер - 2кб) - врать что там ошибка чтения. Ну и запись заодно можно перехватить. Или не выполнять ее в этот файл совсем но наврать что успешно записали, или перезаписать файло, но опять дописаться в хвост - в зависимости от лени, наглости и фантазии автора руткита :). Реально чуть сложнее, но я думаю идея понятна. При правильной реализации - файл будет при своем старте сперва выполнять руткита, а потом уже полезную прогу. А вот при попытке чтения будет видно только полезную прогу. Без пришитого к ней руткита. Очевидно, при идеальной реализации хуков на сисколы, чексум файла окажется без изменений :). И единственный метод заметить грабли - это читать физический девайс, парсить файловую систему в проге-сканере самостоятельно и смотреть совпало ли содержимое файла с тем что через сисколы ОС видится. Примерно так некоторые антивирусы и делают. Только вот опять же - руткит может и чтение физического девайса перехватить, в принципе, и или виртуализануть и его, или просто самоликвидироваться на всякий пожарный, избежав поимки и изучения. Ну, можно конечно и это обойти, прямым программированием железа в обход дров ОС вообще, но крайне грабельно, клещится с ОС и вообще полный головняк, хотя некоторые антивирусы и такое тоже делали, но это уже начинает попахивать изобретением своей операционки. ИМХО чем все эти извращения, проще и надежнее просто загрузиться с ридонли носителя и заведомо чистой ОС ;).Хотя с программингом железа через регистры пожалуй даже самый злостный вирь в биосе ничего поделать не сможет. Сложно это - понять что вы сектора с руткитом попросили вон теми записями в регистры и перехватить все это.

Из особо неожиданных методов могу предложить хакинг PCI девайсов. У них во первых часто есть option ROM (иногда прошиваемые, довесок к BIOS) а сам девайс умеет вбабахивать DMA "куда попросишь" зачастую. Так что если удалось сломать фирмваре контроллера девайса (это не BIOS!) - можно попробовать убедить девайс сделать запись в память через DMA, например. Кстати FireWire по этой причине можно официально считать бэкдор-разъемом. Интерфейс умеет DMA и тот кто к нему приаттачился потенциально контролирует содержимое оперативы, со всеми вытекающими. Еще наверное очень смешно пропатчить фирмвару винча или сидюка чтобы тот в нужный момент подпихивал "неправильный" сектор. Только представьте себе - вирус который упорно воскресает после лечения :). Или который появляется на CD, независимо от того какой CD в привод засунули :). Правда в силу очень разного железа, постоянных перетрясов модельных рядов и прочее - опять же: сделать PoC - можно. Сделать что-то универсальное - сомнительно.

Кстати могу предложить метод поимки пакости переписывающей BIOS "на живца" - "виртуальная флешка BIOS". Берем микроконтроллер, пишем на оном эмулятор SPI-флеша. Который не только отдает по SPI чипсету образ bios в нужный момент, но и логгит подозрительные потуги записи и вообще может издеваться над вредителями как хочет. Руткит может и не знать, но флеха которую он собирается переписать - тоже как-то не обязана быть доверяемой и играющей по именно его правилам и вполне может быть гнусной эмуляцией. Можно его даже обмануть что мы тут типа записали ваш новый биос, аж два раза. А отдавать старый образ из загашников все-равно :P. Таким наглым маневром можно вероятно обдурить даже фирменные утилиты-флешеры, которые поверят в то что они, типа, заапдейтили. Особо злые софтварщики могут написать эмулятор эмулирующий чипсет и флеху и сделать то же самое но чисто программно. Для отлова и изучения пакости сойдет, хотя реализовывать чипсет с докой на ~1000 страниц немного утомительно, разумеется :).

Ну как, теперь паранойя не даст вам спать? :)))

> особенно если заблокировать изменение файлов, отвечающих за выполнение проверок,

Если ядро взято под контроль руткитом, реализуемые им системные вызовы могут возвращать НЕДОСТОВЕРНЫЕ данные. Не соответствующие истинной картине. Покуда ваша программа написана стандартным методом ака "делаем сискол - разгребаем результаты" - она имеет все шансы быть обдуреной. Т.е. чтение файла может и не показать изменений. Но это не значит что то же самое фактически прочлось при первом запуске этого файла, ну а потом оно пропатчило сисколы и стало всем радостно врать что там ничего нет ;). Теоретически вы можете конечно написать программу - дисковый ревизор, который прямым доступом к диску в обход сисколов прочитает сектора, распарсит их сам вместо ядра и драйвера ФС, но по-моему, проще и надежнее перегрузиться с readonly диска. Где то же самое сделает заведомо исправная копия ядра и ОС и не будет шансов что руткит обнаружит проблемы :)

> для всех, включая рута.

Вы хотите запретить ядру что-то делать? При том что оно же эти запреты расставляет и контролирует? Хотеть не вредно ;P. Если вы еще не поняли, наиболее проблемный класс руткитов - это которые меняют обработку сисколов ядром (а поскольку RAM в общем то по природе своей read-write, всегда остается ненулевая вероятность что образ ядра в памяти тем или иным методом будет слегонца запатчен в случае взлома).

> Правда, обновление системы при этом станет более гиморным, особенно
> в большинстве Linux-дистрибутивов, где система вся состоит из пакетов. Ну да
> это уже совсем отдельная тема....

Уж простите конечно, но ваши понятия о руткитах - на уровне пещерного человека.

>> кондовый бэкдор. Гентушники даже успели его пересобрать и раздать :))
> Да таких случаев уже не так и мало. В своё время даже
> исходники OpenSSH подменяли — взломали ftp.openbsd.org

В этом плане подменять готовые пакеты на сервере явно сложнее - они подписаны и проверка при установке делается. Что пакетов с бинарями, что с сырцами. И такие номера - не катят.

> (проекту OpenBSD он не принадлежит и поэтому не контролируется;

За отмазку не считается. Тоже мне безопаснички, без своего сервера. Ну вашу двадцать, если вы бомжуете, денег едва хватило на последние штаны, а на сервак уже не осталось - киньте клич! Сообщите про это! Попросите, блин, адресно задонейтить - на цель "сервак и его оплата". Учтя количество юзеров SSH - денег накидают, ИМХО.

> работает машина, кажется, на Солярке). Инцидент оставался
> незамеченным около пары суток.

Sh... happens. Но по-моему, когда безопаснички отвечают за чужие FAILы - это идиотизм чистой воды.

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
  Введите код, изображенный на картинке: КОД
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру