|
Рубрика:
Безопасность /
Расследование инцидентов
|
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
|
 ВИЗИТКА
Моисей Сутулин,
любопытный инженер, автор курсов, разработчик, mosesutulin@ya.ru
Теневая сторона ELF
Часть 2: защитные механизмы и проверка интерпретатора
Можно ли доверять этому бинарнику? Проверяем PT_INTERP, NX, RELRO и Build ID штатными средствами Linux
В первой части цикла мы разобрали, как извлечь рабочую программу из ELF-файла даже при поврежденной таблице секций. Теперь, когда «скелет» программы у нас в руках, переходим к криминалистическому анализу: как проверить, не подменил ли злоумышленник динамический компоновщик и работают ли штатные механизмы защиты ядра.
Введение
В предыдущей статье мы научились извлекать рабочую программу из ELF-файла даже тогда, когда таблица секций повреждена или намеренно удалена злоумышленником. Формула max(p_offset + p_filesz) для сегментов PT_LOAD дала «минимальный рабочий бинарник», который ядро Linux загрузит и выполнит. Мы доказали через сравнение карт памяти /proc/[pid]/maps, что извлеченный файл ведет себя идентично оригиналу: одинаковое количество регионов, одинаковые права доступа, одинаковые относительные смещения.
Теперь переходим к следующему шагу: проверке служебных сегментов. Файл access.log изъят, рабочая программа извлечена. Осталось проверить интерпретатор и убедиться в работе защитных механизмов.
<...>
Ключевые слова: ELF, формат ELF, PT_INTERP, динамический компоновщик, NX bit, RELRO, Build ID, расследование инцидентов, киберкриминалистика, анализ вредоносного ПО, подмена интерпретатора, readelf, strings, dd, безопасность Linux, Astra Linux, РЕД ОС, ALT Linux, системное администрирование, защита бинарных файлов
Полную версию статьи читайте в журнале
Подпишитесь на журнал
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
|
Теневая сторона ELF. Часть 2: защитные механизмы и проверка интерпретатора
