Ключевые слова:html, form, web, security, (найти похожие документы)
From: jkeks <jkeks@mail.ru.>
Newsgroups: email
Date: Mon, 20 Sep 2004 18:21:07 +0000 (UTC)
Subject: Несанкционированная передача данных через WEB формы
Все о передаче данных через формы
0. Введение
1. Принцип работы
2. Обход файрволов (бесплатный интернет)
3. Технология для троянов и вирей
4. Трудности реализации
5. bruteforce - как средство передачи информации
6. Ресурсы
Введение.
В нашем жестоком мире сложно сейчас придумать что-то новое, потому что многое
уже придумано, а чтобы придумать что-то совершенно новое, надо как минимум знать то что уже
придумали. Однако сколько интересного приносит знание, когда начинаешь ими уже
свободно владеть.
Мы будем говорить о хитроумном способе передаче данных. Таком хитроумном, что
сложно так вот сходу придумать ему применение, однако нижеизложенная техника -
это факт, и неизвестно что она принесет миру, а возможно так и останется жить
только в теории и да у маньяков с плохим зрением.
Чтож, ближе к делу ?
Принцип работы.
Условимся, что на на странице
http://www.server.com/cgi-bin/formParsing.pl есть некая форма с
параметрами: nick, message и кнопкой отправки введенных данных.
Примерно следующего содержания:
<form action="http://www.serevr.com/cgi-bin/formParsing.pl" method="post">
<input type="text" name="nick"> nick<br>
<textarea name="message"></textarea> message<br>
<input type="submit"><br>
</form>
После ввода данных эти данные печатаются на этой же странице сверху
(грубо говоря, это урезанный чат).
Любой человек в интернете может ввести туда данные и отправить их на обработку серверу.
Если мы введем: : "жду тебя вася в 19-00 у Ленина",
тогда тот вася, который ждал этого сообщения, увидев эту надпись может пойти к
Ленину к 19-00, если посчитает это нужным.
Теперь спроецируем это все на программы (cgi скрипты)
Если один из серверов в интернете периодически читает эту страницу и ищет на ней
определенную сигнатуру, а другой сервер в интернете посылает эту сигнатуру на
эту страницу, а после нее посылает определенный блок данных, то первый
определив сигнатуру, может получить и те данные, которые были посланы вторым.
Допустим на вышеуказанную страницу мы отсылаем
name="robot19jkeks"
message="robot19jkekshttp://www.anotherserver.com/cgi-bin/AnotherFormParsing.pl(nick[20]message[300])"
Первый сервер определяет сигнатуру "robot19jkeks", после чего начнает искать
сигнатуру дальше, после чего уже знает что находятся данные, а данные уже вот
эта строка:
http://www.anotherserver.com/cgi-bin/AnotherFormParsing.pl(nick2[20]message2[300])
эти данные могут означать например то что это ссылка на друую страницу, где
аналогичн можно оставлять данные в параметрах nick2 и message2, причем для
nick2 - длинна данных может быть до 20 символов, а для поля message2 300 байт.
Это и есть основной принцип работы, пусть достаточно медленный, однако
принципиально возможный.
Обход firewalls.
Технология предоставляет дополнительную универсальную возможность обхода
firewalls. Почему принципиальную ? Потому что чтобы устранить эту возможность
потребуется анализ данных, однако никогда нельзя будет точно утверждать, что
это написал человек, а это машина. Аналогичная проблемма с анализом писем на
предмет спама.
Проблемма реализации в том, что необходима динамическая страничка доступная с
как со стороны внутренней сети, так и со стороны внешней сети.
Только в этом случае это будет универсальным методом обхода firewalls.
Теперь на примере, на урале один из провайдеров предоставляет доступ в
интернет, но при этом предоставляет услугу просмотра статистики и изменения
кое-каких параметров бесплатно, если зайти с диалапа под открытыми для этого логином и
паролем.
Вот эта форма, подверженная уязвимости:
<FORM ACTION="/cgi-bin/account2.cgi" METHOD="POST">
<table width="500" border="0" cellspacing="0" cellpadding="0">
<tr>
<td width="196">Имя электронного ящика</td>
<td width="304">
<input type="text" name="email4state" value="">
</td>
</tr>
<tr>
<td width="196">Периодичность</td>
<td width="304">
<SELECT NAME="type4state">
<OPTION VALUE=0 SELECTED>0.Не получать
<OPTION VALUE=1 >1.В конце месяца
<OPTION VALUE=2 >2.Еженедельно
<OPTION VALUE=3 >3.Ежедневно
</SELECT>
</td>
</tr>
</table>
<div><br>
<INPUT NAME="oper" TYPE="submit" VALUE=" Запомнить ">
<INPUT NAME="oper" TYPE="submit" VALUE=" Получить ">
<INPUT NAME="oper" TYPE="submit" VALUE=" Выход ">
<INPUT NAME="logi" TYPE="hidden" VALUE="myusername">
</div>
</FORM>
Заполнив форму и отправив ее, сервер провайдера запоминает адрес электронной
почты и периодичность, при следующем просмотре этой страницы, мы увидим эти
параметры в этой же форме, что нам и требуется.
Эту страницу можно посетить как из интернета, так и с бесплатного доступа к
статистике. Теперь нам осталось написать
сервер и клиент, и можно, пусть на медленной скорости, передавать/получать
данные.
Технологии для троянов вирусов и червей
Сразу же надо подчеркнуть, что тут нет пропаганды, а лишь открываются
факты подтверждающие возможности.
Известная группа gray-world утверждает (точнее один из ее рускоязычных
участников), что эта технология будущего для вирей
или троянов. Давайте немного поразмыслим.
На чем основаны нынешние вирусы и черви ? Правильно на последних ошибках, но как
быстро пишутся черви ? Проходит достаточное время, плюс к тому иногда проблеммой
может стать точка старта для червяка, так же редко бывает что червя поддерживает
анонимная группа, что плюсов в распространении его не делает.
И многие другие проблеммы решает именно
эта технология (уж неговоря об обходе firewalls)
Давайте немного рассмотрим поближе эту интересную технологию.
Итак, изначально червь представляет из себя код, который при своем запуске
сканирует известные для него сайты подверженные описанной выше уязвимости, на
предмет сигнатур, по которым определяется положение дополнительных модулей и
дополнительных баз уязвимостей. Если найдена сигнатура, определяется
пространство и скачивается модули и базы, просле чего сканируются новые базы,
после чего исполняются дополнительные модули.
Таким образом червь по сути своей не является червем, а это просто программа
выкачивающая и запускающая данные. И тут впринципе нельзя обвинить автора в
написании червя.
Сами же модули могут представлять из себя все что угодно, дополнительный код
размножения, реклама, деструкторы, движки для морфинга, и самоуничтожения и
всего чего не придет в голову.
Что из себя представляют базы уязвимостей ?
Если объяснять на пальцах, то это строки примерно следующего содержания:
1|URL1|URL2|имя_элемента_input1|объем_данных1|имя_элемента_input2|объем_данных2|имя_элемента_input3|объем_данных3|..
2|URL1|URL2|имя_элемента_input1|объем_данных1|имя_элемента_input2|объем_данных2|имя_элемента_input3|Объем_Данных3|..
...
где
1,2,.. - идентификаторы записей
URL1 - адрес, куда необходимо отправить запрос, чтобы данные сохранились по
адресу URL2
имя_элемента_input1 - атрибут name у элемента формы, который будет отображаться
по адресу URL2
объем_данных1 - объем данных помещающихся в этой форме, т.е. сколько данных мы
можем передать через этот элемент.
Кроме чтения баз уязвимостей вирус/червь, может сканировать случайные адреса на
предмет возможности оставить данные и а так же возможно определение объема
сохраняемых данных.
Благодаря этому будет крайне сложно оставноить червь, который сможет
использовать ресурсы необслуживаемых сайтов, шаблонные проекты навроде
PHPbb.
Чтобы обезвредить вирус, потребуется невероятные усилия, обращение к
администрации сайтов с просьбой отключить определенный проект и много
других проблемм, либо боротьбся с вирусом его же средствами. Изобретать
защиту можно сколько угодно, но проблемма останется навсегда по одной
простой причине: это принципиальная возможность!
Если мы можем оставлять где-то данные, почему бы нам не использовать это
в своих целях ? Хотя как мне как-то сутра пришла в голову одна
интересная мысль: А что если при написании формы, рядом показать
рисунок, например рисунок цветка, и требовать ввести пользователя: Что
нарисовано на картинке ? В этом случае, автоматизировать процесс будет
крайне сложно, однако об этой технологии я нигде не слышал, и на данный
момент проблемма актуальна. С другой стороны, опять-таки все интернет
сайты не смогут сделать подобную защиту. Часть ресурсов отпадет, но
другая часть останется.
Тем самым мы решили проблемму места, где могут хранить вирусы информацию
и в том числе и себя самих. Никто не мешает использовать последние дыры,
и факт того что их может добавть любой в интернете, поместив
определенную сингатуру на несколько общедоступных сайтов с форумами.
Так же мы решили проблемму групповой разработки и поддержки вируса/червя.
Трудности реализации
А проблемм достаточно много, назовем некоторые из них:
1.Универсальное ядро должно уметь анализировать канал передачи, сколько бит
приходится на 1 байт
2.Упаковка данных
3.Процесс UUEncode или аналогичный ему
4.Нет уверенности, что сигнатура будет совпадать с чем-то иным, нужна устойчивая
схема определения СВОИХ данных, и система повтора отправки данных, грубо говоря
нужна разработка целого протокола.
Рассмотрим решения проблемм.
Анализ канала передачи должно сводиться к созданию единого универсального
запроса (unicode пока не учитываем) состоящего из 256 байт.
Результатом должно быть сообщение с вырезанными символами, либо отрицательный
результат. Если результат есть, тогда тогда исключаются символы в радиусе до 2^x
где x<=8.
Если результат отрицательный, тогда используются лишь безопасный набор символов,
и так же анализируется на целостность.
Можно поступить по иному. Изначально разбить символы на группы: Безопасная (32-128), микро
(a-zA-Z0-9_), основные (32-256), все (0-256)
Тогда каждая группа будет подбираться для определенной уязвимости.
Все это поместиться в заголовок из двух бит.
b.01 00 00 00 11
__
^ эти 2 бита отвечают за ширину канала передачи данных
Упаковка данных представляет из себя специализированный алгоритм сжатия
небольших объемов данных.
--------------Вырезка из теста упаковки-------------
Содержимое файла ass (512 байт):
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasas
Упаковщик Объем упакованного файла
GZ 48
BZ2 51
LZH 54
RAR 98
ZIP 118 // winrar zip
7Z 119
ARJ 121
ZIP 130 // 7z zip
--------------Вырезка из теста упаковки-------------
Как видите все результаты говорят за GZ
Процесс UUEncode - тут очень специфичный и скорее должен быть свой, т.к. у нас
задача втиснуться в ширину канала, никто заранее не сможет сказать, что пройдет,
а что не пройдет.
Но принцип UUEncode в качестве примера подходит как никогда.
И насчет надежности протокола.
Если передавать информацию от сервера к серверу, тогда протокол обязывает
разбить на передачу команд и данных, все это должно быть похоже на telnet
протокол.
Первые 2 бита указывают на ширину канала, 2 бита под код опреации (читаем ниже).
остальные биты певого байта - пустые.
b.01 00 00 00
__ __ <определяет ширину канала
^ Определяет код операции (читаем ниже)
Остальное под данные.
Как показала практика на деле достаточно под код опреации назначить всего 2
бита.
Это состояния:
00-дефолт
01-можно сделать запрос ?
10-разрешение (да можно !)
11-подтверждение операции
Этот минимум необходим для полноценной работы сервера и клиента.
Следующие 1-4 байта идут под контрольную сумму данных, легко организуется по
принципу CRC16.
h.40 43 47 7А (заголовок с контрольной суммой CRC16 умещенные в канал 32-255)
Для одностороннего получения информации с сайтов нужен примерно аналогичный
формат, однако необходимо так же учитывать расщепление данных на несколько
частей.
Для этого необходимо ввести счетчик, например первый из 13 пакетов, второй,
третий, и т.п.
Сколько отводить пож это места уже нужно решать диначмически.
Если это движек для вируса, необходимо выделить еще байта 4 под сигнатуру.
Больше необычных проблемм быть не должно.
bruteforce - как средство передачи информации
Данная техника кажется более универсальна, т.к. формы с логинами и паролями -
вещь значительно более распространенная чем какая-либо форма для чата или
форума или для чего-то сверхестественного.
Итак представляем, что у нас есть страница, где нужно залогиниться.
У нас есть свой аккаунт.
И теперь мы реализцем протокол в рамках угадывания пароля.
Изначально пароль равен 0. Дефолтовая ситуация.
Если пароль равет 1, значит это запрос на передачу данных.
Если пароль равен 2, значит это подтверждение
Далее, при установлении соединения, есть три комбинации:
пароль равен 0 - передан бит 0
1 - передан бит 1
2 - конец передачи (деволтовая ситуация)
Таким образом перебирая/устанавливая с двух сторон новый и угадывая
постоянно пароль возможно передавать информацию.
Да что и говорить скорость тут будет просто ужасной, но факт в том, что она
будет!
Ресурсы
Теперь хотелось бы сказать, что когда я придумал всю эту кашу, и даже когда
писал об этом на различные сайты я еще не знал о существовании разработок в этом
плане, и считал себя первооткрывателем 8), однако чуть позже я наткнулся на сайт
группы gray-world, где перед моими глазами открылся проект firepass.
Данная программа написана на Perl, и частично реализовывает тот описанный выше
функционал (к вирям,червям и троянам этот проект никак не относится) и даже кое-что
свое.
Что меня очень удивило дак это то что формы сайтов используются как туннель для
передачи TCP протокола, это означает, что настроив всю систему, и найдя нужную
уязвимость, возможно через обычный браузер ползать по интернету, качать почту, и
все все что дуже будет угодно.
А вот что пишет один из авторов проекта:
-------------кусок письма---------------
jmr> Вы писали 12 января 2004 г., 9:57:08:
jmr> слушай, мог бы ты рассказать историю написания проекта FirePass.
jmr> Я пишу небольшую статью про этот вопрос, буду рад любой исторически важной
jmr> информации, а и технической особенно.
http://gray-world.net/projects/firepass/ : firepass README - english
http://www.hackzona.ru/modules.php?name=News&file=print&sid=433 : мини
статья с void.ru - русский язык. 3 параграф посвящен firepass.
Ключевая особенность firepass или зачем он был написан : на самом деле
это концептуальная программа, демонстрирующая возможность
туннелирования произвольных сессий базирующихся на TCP или UDP
в протоколе уровня приложений - HTTP. Программа уникальна тем, что
серверная часть реализована как CGI скрипт, как следствие не
требуется "слушать" какой-либо порт на компьютере-сервере. Аналоги
такой архитектуры туннеля могут существовать, но мне не известны.
Все что надо для того, чтобы "пробить" туннель из-за защищенной сети
наружу с использованием firepass и HTTP - это иметь снаружи веб сервер
и возможность доступа к его /cgi-bin (любой хостинг провайдер?)
Если будут какие-либо конкретные вопросы - буду рад ответить!
Alex
-------------кусок письма---------------
Сам я так же публиковал материал по этой теме не раз, и его вы сможете почитать
тут:
http://www.bugtraq.ru/library/programming/brute.htmlhttp://jkeks.far.ru
Так же я получал подтверждение о публикации материала (одной из нескольких
доработок матриала) на xakep.ru от PigKiller по рекомендации securitylab.ru
За что всем огромное спасибо.
Ну и я безконечно рад проекту opennet.ru, где мои материалы публикуются
периодически.
И если кому особенно интересна данная тема посетите сайт http://gray-world.net,
есть частичный перевод и вообще много материала про различные методы передачи
данных.
Если кому интересны мои личные проекты:
http://jkeks.far.ruhttp://revda.biz
И на этом заканчиваю эту пяткощипательную тему.
