Kodsweb Security Team

MENU

  :::: Main
  :::: Archive
  :::: Programs
  :::: Texts
  :::: Proxies
  :::: Wordlists
  :::: E-Books
  :::: Rfc
  :::: Our Projects
  :::: About
  :::: Forum
  :::: Exploits
  :::: Friends
  :::: Services
  :::: Feedback
  :::: Misc

FEEDS

KodsWeb.ru - Forum
KodsWeb.ru - Project News
KodsWeb.ru - IT & Scene News
KodsWeb.ru - Defaces Bugtraq Exploits

SEARCH



WHOIS

FRIENDS

--{ team void }--

gfs-team

XakNotDie - Security, Coding and IT.

all networks hacking and security research

COUNTERS





Рейтинг@Mail.ru

Rambler's Top100 Rambler's Top100



[ Food vs Anti-Flood::Аспекты защиты::Алгаритм Флуд-атаки. ]


Date: 13.11.02

В этой статье речь пойдет о Флуде и о том, как с ним бороться.

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

Основные особенности, которые я заметил, проводя свое исследование:

1. В 70% случаев все параметры в гостевых книгах устанавливаются по дефолту, что облегчает поиск уязвимостей. Достаточно достать исходный код, посмотреть на то, как все расположено по умолчанию и воспользоваться этим. В нескольких гостевых книгах по умолчанию файл паролей от этих гостевых располагался в доступном для чтения месте: например, в файлах
/guest/passwd.txt
/gb/administrator.txt
/wwwbook/admin.txt
Один раз я даже сам "вслепую" нашел файл паролей путем тупого перебора нескольких наиболее популярных вариантов.

Кроме того в дефолтовых установках зачастую установлены на "Включено по умолчанию" такие опции, которые админ и думать не думал использовать, иногда даже не подозревая, что они есть. Такие опции как правило подразумевают вставку в сообщение html тегов и включение опции отправки письма автору сообщения с благодарностью, что потенциально опасно.

2. Большинство книг не имеет защиты от флуда. То есть один человек (один IP) может неоднократно постить сообщения в гостевой книге. В некоторых гостевых книгах достаточно только один раз запостить сообщение и затем просто обновлять главную страницу гостевой книги в браузере -> в результате этого с каждым обновлением будет повторяться пересылка первого сообщения. Таким образом, нажав на кнопку 30 раз получаем флуд.

Но как правило, когда говорят о флуде, то подразумевают отправку большого количества сообщений без особых усилий со своей стороны. Именно для этого и пишутся сплоиты. Исследуя гостевые книги я написал 4 сплоита, различные вариации с кодом которых позволяют зафлудить книгу, как самое безобидное последствие, или привесть к DoS атаке, когда книга вообще слетит.

Эксплоиты построены по двум направлениям:
~ Отправка большого количества сообщений (кто знает как поведет себя книга, получив 20000 сообщений)
~ Атака "Большими словами" (дело в том, что многие книги не имеют ограничение на размер вводимых слов, поэтому сформирова программно постинг слова вида LOX x 10000 приведет к тому, что гостевая книга сразу станет нечитабельной, а при продолжение атаки в цикле опять слетит).

Сами сплоиты можно скачать из раздела Our Projects:
k0dsweb BulletGB DOS exploit
k0dsweb BNB Book DOS
k0dsweb MWGB Flooder
k0dsweb GC DOS

3. В некоторых книгах ввод не фильтруется на метасимволы, это может быть не так опасно в messages field, но когда появляется возможность передачи нефильтруемого ввода в командную строку, безопасность сводится на нет.

4. Еще одно замечание касается авторских прав, которые абсолютно не соблюдаются при написании гостевых книг. Я исследовал исходники целой кучи книг и могу сказать, что 80% из них составлены по исходникам 2-х 3-х книг. Зачастую просто изменялся автор и цвет книги, да я про font, а автор приписывался новый. Это факт говорит еще и о том, что некоторые ошибки характерны для большого количества книг, потому как просто "передирается" исходный код со всеми его ошибками.

Flood-алгаритм:

- Формируется один пакет (одно сообщение) различного объема (в зависимости от типа атаки).
- Пакет ставится в цикл, которым можно легко управлять
- Таким образом получаем возможность программной отправки неограниченного количества сообщений на удаленный хост в гостевую книгу.

Борьба с флудом:

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

Делается это следующим образом:

Для метода GET:


# Скрипт, подделывающий заголовок Referer
#
#!/usr/bin/perl -w
use Socket;
$proto=getprotobyname('tcp');
socket(Socket_Handle, PF_INET, SOCK_STREAM, $proto);
$port=80;
$host="www.victim.com";
$sin=sockaddr_in($port,inet_aton($host));
connect(Socket_Handle,$sin);
send Socket_Handle, "GET /cgi-bin/env.cgi?".
			"param1=val1¶m2=val2 HTTP/1.0\n",0;
send Socket_Handle,"Referer: any referer you wish\n",0;
send Socket_Handle,"User-Agent: my agent\n",0;
send Socket_Handle,"\n",0;
while ()
{
	print;
}
close (Socket_Handle);

Для метода POST тоже не существует особых проблем:
Делается это путем направленной посылки значения переменной $referer на сервер при формировании заголовка пакета:



$submit = "POST $path HTTP/1.0\r\n Referer: $url\r\n".
	   "User Agent: Mozilla/4.07 (Win95; I)\r\n".
	   "Content-type: application/x-www-form-urlencoded\r\n".
	   "Content-length: $length\r\n\r\n$content\r\n";

Переменная Referer в данном случае задается как $url="www.evil.com";
Таким образом данный способ защиты сводится к нулю.

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

Имена

В настоящий момент наиболее хорошую защиту от DoS-флуда имеют следующие гостевые книги:


~ WOguest Final Edition
~ CW GuestBook v2.4
~ Vizbook v2.0
~ Guest Book 98.1.0 Personal Version
~ Ardzhan Guest Book

ЗАКЛЮЧЕНИЕ

В заключение хочу сказать, чтобы вы были предельно внимательны, устанавливая любой скрипт на свой сайт. А если он ко всему прочему взамодействует с почтовой программой, если результаты заполненной посетителейм формы могут быть переданы потенциально опасным функциям, таким как system, exec, eval, unlink, rename и др., то необходимо проверить исходник скрипта на предмет обнаружения потенциально опасных мест. Желательно также самому протестировать свой скрипт на то, как он будет себя вести при нестандартных действиях удаленного пользователя.





{dr}{NerVe}     [KODSWEB]
!!! Статья является собственностью команды KODSWEB !!!
!!! Любое распространение без нашего разрешения строго запрешено !!!



 Copyright © 2001-2007 Kodsweb. All rights reserved.

Лучше Мы сделаем ремонт за Вас: сайдинг металлический.

>