Ключевые слова:web, (найти похожие документы)
From: jkeks <[email protected]>
Newsgroups: email
Date: Mon, 24 Oct 2003 14:31:37 +0000 (UTC)
Subject: bruteforce - как средство передачи информации. Принципиальная дыра.
bruteforce - как средство передачи информации. Принципиальная дыра.
Автор статьи : jkeks ( http://jkeks.far.ru )
Это очень похоже на обычные бытовые ситуации , когда один человек не говорит о
том , о чем у него спрашивают, и отвечает однозначно: Да или НЕТ.
А скорее он отвечает всегда нет, и лишь в один из удачных моментов отвечает
да.
Технология передачи информации за счет перебора понимает под собой передачу
относительно небольшого объема информации, возможно дающей ключь к более
широким перспективам. Скорее мы можем себе представить перебор пароля на
архив. Если мы его узнаем, то собственно говоря мы сделаем именно то что
хотели, а заодно и узнали те несколько байт, которые были для нас преградой -
пароль!
Односторонний перебор.
Перебор архива является примером одностороннего перебора, т.е. мы единожды
пообрав пароль теряем весь интерес к дальнейшему перебору или перебору с
самого начала. Такой перебор дает нам ограниченную информацию размером вряд ли
более 16 байт, а скорее около 2-8. Подобный перебор не представляет особого
интереса.
Двусторонний перебор.
Наша с вами задача - получать информацию посредством перебора. Дак вот
Двусторонний перебор подразумевает под собой знание того же изначального
пароля и как следствие - его использование.
Например, представим себе интернет сайт с доуступом к нему только после
аудентификации. Аудентификационный пароль может быть только из одного байта
т.е. 66 комбинаций.(a-zA-Z0-9) Итак мы сможем за 65 запросов однозначно узнать
пароль, после чего можем установить свой.
Вот тут включается вторая сторона и производят аналогичные действия, т.е.
перебирвает пароль и максимум через 65 попыток узнаем пароль, после чего
устанавливаем опять свой.
В это время сам пароль будет носителем информации.
т.е. если наш перебор остановился на 'j',значит мы получили 6 6ит информации.
Какой информации - можно установить по заранее изготовленным таблицам либо
алгоритмам.
Самый простой вариант:
a=1, b=2, c=3, ...
Прменение данному способу можно найти следующее:
Существует внутренний корпоративный сайт с ограниченным доступом в интернет. У
него существует собственная страница, которая доступна как со стороны
внутренней сети, так и со стороны интернет. Сайт позволяет производит
аудентификацию для просмотра некоторых данных. Имея Web интерфейс для
изменения пароля доступа к станице и право на это, можно собственно и устроить
передачу информации через форму ввода пароля.
Подобные ситуации воничают нередко, например бесплатный доступ к странице
провайдера для просмотра статистики, при этом ничего кроме этой страницы не
работает, такой же фокус используют некоторые предприятия, допуская всех
корпоративных пользователей лишь к единственной странице и не более.
Данный способ наиболее универсален одако имеет значительно уже канал нежели
иные способы передачи данных через Web формы (да и любые интерактивные
элементы позволяющие хранить любую информацию на стороне сервера, либо
каких-либо его посредниках).
Представим себе следующую ситуацию, вы диалапник, у вашего провайдера имеется
страница с доступом к статистике и ее некоторым настройкам, хранящимся на
сервере, например пункт о периодичности рассылки с состоянием вашего счета.
Для передачи информации вам уже нет необходимости осуществлять перебор для
просмотра этого параметра, т.к. он высвечивается как элемент ваших личных
настроек. Благодаря этому ваша скорость по передаче данных значительно
увеличивается.
Что значит синхронизация передачи данных ?
Подумайте, как вы будете передавать информацию, если у вас нет
непосредственной связи с вашим скриптом на одном в инете.
Ведь вам необходимо передавать информацию через ЧТО-ТО, вот тут мы и рассмотрим
механизмы синхронизации передачи данных.
У нас есть серверная часть(со стооны интернета) и клиентская(со стороны
корпоративной сети).
Серверная часть выполняет наши запросы, команды, а клиентская их задает.
В обязанности обоих сторон входит отслеживание состояния. Возьмем наш метод передачи
данных через поле пароля.
Рассмотрим вариант:
Давайте обусловимся, что пароль
"1" будет означать деволтовую ситуацию, когда ничего не передается.
"2" - начало передачи данных, запрос.
"3" - подтверждение передачи, успешная передача
1. теперь со стороны сети, устанавливаем пароль "2".
(по умолчанию установлен пароль "1") и периодически проверяем пароль.
2. Итак сервер увидел, что пароль "2", в свою очередь подтверждает это установкой
пароля "3", это значит, что она принял наш сигнал и готов к получению запроса.
3. Мы проверяем это событие проверкой пароля, и если пароль = "3",
то теперь настала очередь передачи данных. За один раз мы передадим 1 бит,
а запрос может быть из 20 байт например. Мы устанавливаем пароль "a".
4. Со стороны сервера происходит следующее.
Сервер производит проверку, установлен пароль "a" или "b".
(если ни один из них не подходит, то проверяется пароль "1", что значит конец передачи данных),
Исходя из того какой из двух вариантов пароль, соответственно делается вывод,
пришел бит 1 или 0, а значит мы передали серверу 1 бит.
5. После перебора, сервер устанавливает пароль "2", что значит, что нужно передать
следующий бит.
6. Передается следующий.
7. По окончании передачи клиент устанавливает
пароль "1" и теперь начинает работать в режиме сервера.
8. В это время сервер
получив запрос, выполняет его (например скачивает указанный УРЛ).
9. После скачивания данных сервер выставляет пароль "2", а клиент ждет этого
пароля.
a. Получив пароль "2" клиент устанавливает пароль "3".
b. Сервер определив, что уже установлен пароль "3" начинает побитовую передачу.
А мы подтверждаем каждый бит установкой пароля "3".
....
ну и наконец, существует оочень много возможностей реализовать данный трюк,
однако все эти возможности настотлько разнообразны, что написать какой-то
универсальный движек будет достаточно сложно. Например для одного из местных
провайдеров существует способ передачи к себе шириной в 2 бита за 1 запрос, а в
обратную сторону можно использовать достаточно широкий канал шириной около 24
байта.
Предистория нахождения подобного извращенного метода передачи информации
достаточно невеселая, вечерами и ночами я работал в городе Норильске, обслуживая
одну из местных кантор, план работ давно закончил, а делать было нечего, вот и
вспомнил про провайдеров далекого Урала.
К данной технике пытался написать движек на Perl, но времени не хватило, однако
кое что осталось:
При передаче информации такким путем необходимо:
1.Шифровать инфу
2.Упаковывать
Коноечно же использовать rar для такого не будешь и поэтому мне помог друг и
провел тесты архиваторов:
Потестил архиваторы от нечего делать, результат предсказуем:
ASS GZ 48
ASS BZ2 51
ASS LZH 54
ASS RAR 98
ASS_ ZIP 118 // winrar zip
ASS 7Z 119
ASS ARJ 121
ASS ZIP 130 // 7z zip
ASS 512
Содержимое файла ass:
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasas
Режим движка "Ожидание запроса":
Алгоритм следующий:
1. Запускается модуль, производящий ожидание запроса (все зависит от типа пароля
либо метода передачи (не исключена возможность передачи средствами XSS атаки, как
это реализуемо у одного из Уральских провайдеров))
2. При получении запроса происходят аналогичные операции с 4-8.
3. Выполняется запрос в Интернет (да, эти пункты скорее будут в движке, т.к. они
производятся обычным образом, например с помощью библиотеки LWP)
4. Принимается ответ из Интернета
5. Упаковываются данные
6. Зашифровываются данные
7. запускает модуль отправки результата, который и принимает ответные данные
Библиотеки, которые я вам советую для разаботки:
LWP, Compressed::ZLib , MIME::Base64.
Пожалуй достаточно, хочется добавить лишь примеры извращщеных методов передачи:
- Передача информации за счет счетчиков посещений (требуется контроль за
правильностью передачи, ведь не исключены заходы других юзеров)
- анализ задержек ответа сервера (можно искуственно создавать незначительные
задержки с любой стороны, различными методами)
- в некоторых случаях передачу данных можно осуществлять за счет сессий
(номера которых обычно сораняются у клиента в куках)
Данная статья может свободно распространяться, как сама 8)), так и при помощи
хороших людей и проектов, для чего собственно и была написана.
Автор статьи : jkeks ( http://jkeks.far.ru )
Ну и наконец, ищите в инете проект ret WebOS.
