Аудит и дизассемблирование exploit'ов


Введение - часть 2


Чтобы администратор мог спать спокойно и не дергался каждые пять минут, пытаясь обнаружить в логах брандмауэра "что-то необычное", первым делом необходимо выяснить — действительно ли вверенная ему система уязвима? Далеко не всем сообщениям о дырах можно верить. По общепринятой практике, первооткрыватель дыры должен подтвердить свои слова программой, демонстрирующий наличие уязвимости, но не совершающей ничего деструктивного. В зарубежной литературе она называется exploit proof-of-concept. Устоявшегося русского термина, увы, нет, поэтому приходится использовать то, что есть.

Часто к exploit'у прилагается перечень тестируемых (tested) и уязвимых (affected) платформ и все, что необходимо сделать — это запустить exploit на своей системе и посмотреть, справится ли он с ней или нет. Естественно, атаковать "живой" сервер или основную рабочую станцию может только самоубийца (или очень безответственный человек) и все потенциально опасные эксперименты следует выполнять на "копии" сервера/рабочей станции, специально предназначенной для тестовых целей. Под VM Ware и другими эмуляторами подобного типа exploit'ы лучше не запускать. Во-первых, ряд вредоносных exploit'ов распознает наличие виртуальных машин и отказываются работать. Во-вторых, вырваться из застенок виртуальной машины вполне реально (см. статью "побег из-под vm ware", которую можно скачать с моего мыщх'иного сервера ftp://nezumi.org.ru/pub/vm-escape.zip).

Отрицательный результат сам по себе еще ничего не доказывает. Даже если атака не удалась, у нас нет никаких оснований считать, что система находится в безопасности. Возможно, это просто exploit такой кривой, но стоит его слегка подправить, как список поражаемых систем заметно возрастет (тем более, что большинство exploit'ов закладываются на фиксированные адреса, варьирующие от версии к версии, поэтому exploit, разработанный для английской версии Windows 2000, может не работать в русской и наоборот).

К сожалению, зеркальная копия сервера есть не у всех, а ее создание требует денег, времени и т. д., поэтому сплошь и рядом exploit'ы запускаются на "живых" машинах. Но тогда хотя бы изучите код exploit'а, чтобы знать, что вы вообще запускаете, попутно устраняя ошибки, допущенные его разработчиками и адоптируя shell-код к своей системе, корректируя фиксированные адреса при необходимости.

Формально, администратор не обязан быть программистом и знания ассемблера от него никто требовать не вправе, но... жизнь заставляет!




Начало  Назад  Вперед



Книжный магазин