Читаем Спецвыпуск журнала «Хакер» #47, октябрь 2004 г. полностью

Всегда думай о своей безопасности! Никогда не мешает использовать соксы для подключения к удаленной системе. Если у тебя возникнут затруднения с выбором терминала для этих целей, я посоветую тебе PuTTY: он умеет работать через прокси– и сокс-сервера, а также имеет множество полезных функций, которые наверняка тебе пригодятся. Не нужно забывать чистить логи, ведь они – доказательство присутствия в системе. Не забудь почистить .bash_history, если ты зашел как обычный пользователь через стандартный ssh или telnet. Этот файлик обычно находится в домашней директории пользователя и, как ты уже заметил, является скрытым (перед именем файла стоит «.»). В хистори содержатся все команды, которые ты выполнял. И запомни: хистори записывается в файл только после того, как ты сделаешь лог-аут. Есть и другой вариант решения этой проблемы: после входа в систему выполнить команду «UNSET .HISTFILE».

Где же брать эксплоиты

Эксплоиты не растут на эксплоитном дереве и сами к тебе не прилетят (за исключением fake :)). Лучше сливать их с популярных ресурсов, таких, какhttp://packetstormsecurity.nl, http://security.nnov.ru.

ССЫЛКИ

www.securitylab.ru, www.security.nnov.ru, www.packetstormsecurity.nl – самые лучшие ресурсы по безопасности, самые свежие багтраки, секьюрити-репорты и обсуждения.

www.nsd.ru – тут ты тоже сможешь почерпнуть много интересного.

www.bugtraq.ru – хороший багтрак, часто обновляется.

www.google.ru – превосходный поисковик. Наш выбор.

www.xakep.ru – мегаресурс ;).

Не компилится?

Да, часто такое бывает. В большинстве случаев это вина программистов – они не сумели грамотно заточить конечный продукт под все версии компиляторов. Также причинами могут являться отсутствие необходимой библиотеки и сборка с неправильными флагами. Иногда эксплоит требуется подправить ручками, поэтому необходимы хотя бы элементарные навыки программирования на C.

Если изначально нет никакого доступа к хостингу, можно просто купить на нем аккаунт на месяц. А если денег совсем нет, можно попробовать закардить или побрутать :).

Теоретически в сети нет ни одного неуязвимого сервера. Весь вопрос заключается только в умении.

Будь предельно осторожен, проверь командой finger и w, нет ли в системе активных администраторов.

Скрипты, написанные на Perl, следует заливать в текстовом режиме и устанавливать на них chmod 755 или 777. Для того чтобы эксплоит выполнился, его тоже необходимо проchmod’ить как +x (chmod xploit +x).

<p>Невидимость в *nix / Обзор stealth-механизмов бэкдоров</p>

Адиль Хаштамов (adi1@ok.kz,)

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

Давай подумаем, чем простейший бэкдор может выдать свое присутствие.

Во-первых, он существует как файл. Администратор спосоен запросто обнаружить его с помощью элементарной утилиты ls и просто-напросто стереть, что нас ни в коей мере не устраивает.

Во-вторых, если бэкдор запущен и работает, то он присутствует в системе как процесс. Соответственно, может быть обнаружен админом с помощью утилиты ps, вываливающей в консоль список процессов.

В-третьих, черный ход «висит» на каком-то порту и ждет входящего соединения для того, чтобы открыть командный шелл взломщику, из-за чего может быть обнаружен массой различных способов, самым простым из которых является анализ результата работы утилиты netstat.

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

Прячем процесс и файл

Алгоритмы сокрытия бэкдора от утилит ps и ls практически идентичны, поэтому я разберу только случай маскировки процесса. Надеюсь, что с маскировкой файла у тебя трудностей не возникнет.

Есть ощущение, что администраторы смотрят первым делом именно в вывод утилиты ps, когда у них возникает подозрение, что их системой пользуется тот, кто не имеет права этого делать. Наша задача сделать так, чтобы админ не обнаружил в списке процессов ничего подозрительного. Есть множество способов решить эту задачу, но мы рассмотрим самые популярные.

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

Перейти на страницу:
Нет соединения с сервером, попробуйте зайти чуть позже