3. http://securitylab.ru. Еще один отечественный портал по безопасности. Он имеет плюсы двух предыдущих сайтов. Во-первых, на страницах этого сайта содержится подробное описание бага на русском языке (как на хаkер.ru). Во-вторых, сайт обладает весьма функциональным поисковым скриптом, который найдет уязвимость по любым ключевым словам (как на security.nnov.ru). Наконец, ты можешь подписаться на рассылку этого сайта и всегда быть в курсе новых багов.

4. http://packetstormsecurity.nl. Из англоязычных ресурсов ПакетШторм – самый лучший. Мне нравится то, что весь софт разбит на категории. Это означает, что помимо эксплоитов ты можешь найти бэкдоры, сниферы, логвайперы и многое другое. О поиске я вообще молчу – ответ на стандартный запрос может содержать 30 страниц ссылок, грамотно отсортированных по ревалентности.

5. http://securityfocus.org. Еще один зарубежный ресурс, который существует очень давно. На его страницах ты всегда найдешь новые эксплоиты и описания свежих багов. Лично я обращаюсь к страницам этого портала только за разъяснением той или иной бреши в сервисе. В остальных случаях мне хватает других источников.

ProFTPD и Wu-ftpd – самые дырявые сервера. Но несмотря на это администраторы продолжают их использовать.

В последнее время в публичных источниках трудно найти хороший эксплоит.

О том, как админы подменяют баннеры своих сервисов, ты можешь узнать, прочитав статью в этом номере.

Очень часто авторы эксплоитов умышленно допускают ошибки в коде. Чтобы эксплоит функционировал, тебе придется их найти и исправить.

Если ты пробил защиту какого-нибудь маршрутизатора, ищи бажные сервисы в локальной сети. Поверь, там их очень много :).

Чтобы узнать, какие модули подключены к Web-серверу, отправь простой WWW-запрос. Информация о библиотеках содержится в строке «Server:».

Атака брутфорсом очень действенна. Правда, такой взлом может продолжаться несколько часов. Все зависит от пропускной способности.

Трудно представить себе более простую штуку, чем компьютерный вирус. Тетрис и тот посложнее будет. Однако программирование вирусов вызывает у начинающих большие трудности: как внедрить свой код в файл, какие поля необходимо изменять, а какие лучше не трогать, чем отлаживать вирусы и можно ли использовать языки высокого уровня? Ответы на эти и многие другие вопросы, связанные с созданием вирей под *nix, я постарался дать в этом материале.

Первые вирусы, поражающие ELF-файлы (основной формат исполняемых файлов под *nix), были зарегистрированы в конце 90-х, а теперь их популяция насчитывает свыше полусотни представителей (см. коллекцию вирусов на vx.netlux.org). Антивирусная Энциклопедия Евгения Касперского (www.viruslist.com/viruslist.html?id=3166) сообщает лишь о четырнадцати из них, что наводит на серьезные размышления о качестве AVP и добросовестности его создателей.

По умолчанию, UNIX запрещает модификацию исполняемых файлов, и успешное распространение вирусов возможно только на уровне root, который либо присваивается зараженному файлу администратором, либо самостоятельно захватывается вирусом через дыры в ядре системы. При правильной политике разграничения доступа и оперативном наложении заплаток угроза вирусного заражения сводится к минимуму. К тому же, времена тотального обмена софтом давно позади. Сейчас уже никто не копирует исполняемые файлы друг у друга, скачивая их напрямую из интернета. Даже если вирус ухитрится поразить центральный сервер, дальше первого поколения его распространение не пойдет и вторичные заражения будут носить единичный характер.

Файловые вирусы уже неактуальны, и отсутствие крупных эпидемий наглядно подтверждает этот факт. Тем не менее, накопленные методики внедрения отнюдь не стали бесполезными – без них жизнь троянов и систем удаленного администрирования была бы весьма недолгой. Захватить управление атакуемым компьютером и заполучить права root'а – все равно что бросить зернышко на раскаленный асфальт. Хакер должен укорениться в системе, цепляясь за все исполняемые файлы, что встретятся ему на пути. Но и тогда он не может быть ни в чем уверен, поскольку существует такое понятие, как резервное копирование, позволяющее восстановить пораженную систему, как бы глубоко вирус ни был внедрен.

Считается, что вирусы, внедряющиеся в исходные тексты, более живучи, однако в действительности это не так. Исходные тексты требуются небольшому числу пользователей, а девелоперы активно используют системы контроля версий, отслеживающих целостность программного кода и позволяющих делать многоуровневый «откат». Было зарегистрировано несколько попыток заражения исходных текстов операционной системы LINUX и сервера Apache, но все они с треском провалились.

То же самое относится и к вирусам, обитающим в интерпретируемых скриптах, таких, как sh, Perl, PHP. В *nix скрипты вездесущи и их модификация по умолчанию разрешена, что создает благоприятные условия для размножения вирусов. Если бы пользователи обменивались скриптами, юниксоидный мир погрузился бы в эпоху ранней MS-DOS, когда новые вирусы выходили едва ли не каждый день, а так вирусы остаются внутри пораженного компьютера, не в силах вырваться наружу.

Разумеется, вирус может распространяться и через интернет, но тогда это будет уже не вирус, а червь. Некоторые исследователи считают червей самостоятельными организмами, некоторые – разновидностью вирусов, но, как бы там ни было, черви – тема отдельного разговора.

Настоящие хакеры признают только один, максимум, два языка – C и Ассемблер, причем последний из них стремительно утрачивает свои позиции, уступая место Бейсику, Delphi и прочей дряни, на которой элегантный вирус невозможно создать в принципе.

А что на счет Си? С эстетической точки зрения, это – чудовищный выбор, и вирусмэйкеры старой школы его не прощают (однако написать код на ассемблере сравнимый с тем, что выдают современные оптимизирующие C-компиляторы вроде Microsoft C Compiler, – дело для новичка не такое уж простое – прим. AvaLANche'а). С другой стороны, будучи низкоуровневым системно-ориентированным языком, Си неплохо походит для разработки вирусов, хотя от знания Ассемблера это все равно не освобождает.

Код, генерируемый компилятором, должен: быть полностью перемещаемым (то есть независимым от базового адреса загрузки), не модифицировать никакие ячейки памяти, за исключением стекового пространства, и не использовать стандартные механизмы импорта функций, либо подключая все необходимые библиотеки самостоятельно, либо обращаясь в native-API. Этим требованиям удовлетворяет подавляющее большинство компиляторов, однако от программиста тоже кое-что потребуется.

Нельзя объявлять главную функцию программы как main: встретив такую, линкер внедрит в файл start-up код, который вирусу не нужен. Нельзя использовать глобальные или статические переменные: компилятор принудительно размещает их в сегменте данных, но у вирусного кода не может быть сегмента данных! Даже если вирус захочет воспользоваться сегментом пораженной программы, он будет должен, во-первых, самостоятельно определить адрес его «хвоста», а, во-вторых, растянуть сегмент до необходимых размера. Все это тривиально реализуется на Ассемблере, но для компилятора оказывается чересчур сложной задачей. Кроме того, нужно хранить все данные только в локальных переменных, задавая строковые константы в числовом виде. Если написать char x[] = «hello, world», коварный компилятор сбросит «hello, world» в сегмент данных, а затем динамически скопирует его в локальную переменную x. Можно сделать так: x[0]='h', x[1]='e', x[2]='l'… или преобразовать char в int, осуществлять присвоение двойными словами, не забывая о том, что младший байт должен располагаться по наименьшему адресу, что разворачивает строку задом наперед.