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

         

о дырах появляются постоянно. Стоит


Сообщения о дырах появляются постоянно. Стоит только заглянуть на www.securityfocus.com и… ужаснуться. Каждый день приносит по 10-20 новых дыр, затрагивающих практически весь спектр аппаратно-программного обеспечения. Вы до сих пор пользуетесь Лисом, считая его безопасным? Да как бы не так! За свое недолгое время существования он успел обрасти полусотней дыр, в том числе и критических. Ладно, оставим Лиса в покое и возьмем Оперу — почти два десятка ошибок (из которых 17 зарегистрировано на одном лишь securityfocus'е) быстро прочищают мозги от рекламной шелухи, позиционирующей Оперу не только как самый быстрый, но и по настоящему безопасный браузер. Уязвимости встречаются даже в текстовых браузуерах наподобие Lynx. Про Internet Exploder лучше вообще не вспоминать! Стоит ли после этого удивляться, что черви размножаются со скоростью лесного пожара и регулярно кладут целые сегменты сети, если не весь Интернет!
Программное обеспечение ненадежно. Это факт! Предоставленное самому себе, без ухода и надзора администратора оно быстро становится жертвой хакерских атак, превращаясь в рассадник вирусов и червей. Если уязвимость затрагивает те компоненты системы, без которых можно в принципе и обойтись (например, Message Queuing или RPC DCOM), их можно отключить или оградить брандмауэром. В противном случае, необходимо установить заплатку от "родного" производителя или сторонних поставщиков. Проблема в том, что официальные обновления зачастую выпускается лишь через несколько месяцев после официального же признания дыры. А сколько дыр так и остаются "непризнанными"?
Производителей программного обеспечения можно понять: ведь, прежде, чем признавать дыру дырой, необходимо убедиться, что это именно дыра, а вовсе не "авторское видение функциональности" и добиться устойчивого воспроизведения сбоя. У многих компаний существует политика замалчивания дыр и уязвимость либо молча устраняется с выходом очередной версии продукта (кумулятивного пакета обновления), либо не исправляется вообще! Яркий пример тому — уязвимость "MS IE (mshtml.dll) OBJECT tag vulnerability", обнаруженная 23 апреля 2006 (см. lists.grok.org.uk/pipermail/full-disclosure/2006-April/045422.html), все еще не признанная Microsoft.


Чтобы администратор мог спать спокойно и не дергался каждые пять минут, пытаясь обнаружить в логах брандмауэра "что-то необычное", первым делом необходимо выяснить — действительно ли вверенная ему система уязвима? Далеко не всем сообщениям о дырах можно верить. По общепринятой практике, первооткрыватель дыры должен подтвердить свои слова программой, демонстрирующий наличие уязвимости, но не совершающей ничего деструктивного. В зарубежной литературе она называется 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-код к своей системе, корректируя фиксированные адреса при необходимости.
Формально, администратор не обязан быть программистом и знания ассемблера от него никто требовать не вправе, но... жизнь заставляет!

Содержание раздела