Bruteforce як засіб передачі інформації

Bruteforce як засіб передачі інформації

Це дуже схоже на звичайні побутові ситуації, коли одна людина не говорить про те, про що у нього питають, відповідаючи однозначно "так" або "ні", а відповідає завжди "ні", і лише в один з вдалих моментів відповідає "так".

Технологія передачі інформації за рахунок перебору являє собою передачу щодо невеликого обсягу інформації, можливо, що дає ключ до більш широких перспектив. Наприклад, ми можемо собі уявити перебір пароля на архів. Якщо ми його дізнаємося, то, власне кажучи, ми зробимо саме те, що хотіли, а заодно і дізналися ті кілька байт, які були для нас перешкодою - пароль!

Односторонній перебір.

Перебір архіву є прикладом одностороннього перебору, тобто ми одного разу підібравши пароль втрачаємо весь інтерес до подальшого перебору або перебору з самого початку. Такий перебір дає нам обмежену інформацію розміром навряд чи більше 16 байт, а швидше близько 2-8. Подібний перебір не становить особливого інтересу.

Двосторонній перебір.

Наша з вами завдання - отримувати інформацію за допомогою перебору. Двосторонній перебір має на увазі під собою знання того ж початкового пароля і як наслідок -- його використання.

Наприклад, уявімо собі інтернет-сайт із доступом до нього тільки після аутентифікації. Аутентифікаційні пароль може складатися тільки з одного байта, так що при використання латинського алфавіту ми маємо. 66 комбінацій (a-zA-Z0-9). Отже, ми зможемо за 65 запитів однозначно дізнатися пароль, після чого можемо встановити свій.

Ось тут включається друга сторона і проводить аналогічні дії: перебирає пароль і максимум через 65 спроб впізнає його, після чого знову ж таки встановлює свій.

У цей час сам пароль буде носієм інформації. Тобто якщо наш перебір зупинився на 'j', значить, ми отримали 6 6іт інформації. Який інформації - можна встановити за заздалегідь виготовленим таблиць або алгоритмам.

Найпростіший варіант - a = 1, b = 2, c = 3, ...

Застосування даного способу можна знайти наступне.

Існує внутрішній корпоративний сайт з обмеженим доступом в інтернет. У нього існує власна сторінка, яка доступна як з боку внутрішньої мережі, так і з боку інтернет. Сайт дозволяє робити аутентифікацію для перегляду деяких даних. Маючи Web інтерфейс для зміни пароля доступу до станиці і право на це, можна власне і влаштувати передачу інформації через форму введення пароля.

Подібні ситуації виникають нерідко. Наприклад, провайдер може надавати безкоштовний доступ до сторінки перегляд статистики, при цьому нічого крім цієї сторінки не працює. Такий же фокус використовують деякі підприємства, допускаючи всіх корпоративних користувачів лише до єдину сторінку.

Цей спосіб є найбільш універсальний, однак створює значно більш вузький канал, ніж інші способи передачі даних через Web форми (та й будь-які інтерактивні елементи, що дозволяють зберігати будь-яку інформацію на стороні сервера, або будь-яких його посередників).

Уявімо собі наступну ситуацію: ви діалапнік, у вашого провайдера є сторінка з доступом до статистики і її деяким налаштувань, що зберігається на сервері, наприклад, пункт про періодичність розсилки зі станом вашого рахунку. Для передачі інформації вам вже немає необхідності здійснювати перебір для перегляду цього параметра, тому що він висвічується як елемент ваших особистих налаштувань. Завдяки цьому ваша швидкість з передачі даних значно збільшується.

Що значить синхронізація передачі даних? Подумайте, як ви будете передавати інформацію, якщо у вас немає безпосереднього зв'язку з вашим скриптом. Інформацію треба через ЩОСЬ передавати. Ось тут ми і розглянемо механізми синхронізації передачі даних. У нас є серверна частина (з боку інтернет) і клієнтська (зі боку корпоративної мережі). Серверна частина виконує наші запити, команди, а клієнтська їх задає. В обов'язки обох сторін відносяться відслідковування стану. Візьмемо наш метод передачі даних через поле пароля.

Розглянемо наступний варіант. Умовимося, що пароль

"1" означатиме дефолтовую ситуацію, коли нічого не передається

"2" -- початок передачі даних, запит.

"3" -- підтвердження передачі, успішна передача.

З боку мережі встановлюємо пароль "2" (за замовчуванням був встановлений пароль "1") та періодично перевіряємо пароль.

Сервер, побачивши, що пароль став "2", у свою чергу підтверджує це установкою пароля "3". Це означає, що він прийняв наш сигнал і готовий до отримання запиту.

Ми перевіряємо ця подія перевіркою пароля, і якщо пароль дорівнює "3", то тепер настала черга передачі даних. За один раз ми передамо 1 біт, а запит може бути, наприклад, з 20 байт. Ми встановлюємо пароль "a".

З боку сервера відбувається наступне. Сервер проводить перевірку, чи встановлений пароль "a" або "b" (якщо жоден з них не підходить, то перевіряється пароль "1", що означає кінець передачі даних). Виходячи із значення пароля, робиться висновок, прийшов біт 1 або 0 - тобто ми передали серверу 1 біт.

Після перебору сервер встановлює пароль "2" - сигнал, що потрібно передати Наступне біт.

Передається Наступне біт.

По закінченні передачі клієнт встановлює пароль "1" і тепер починає працювати в режимі сервера.

У цей час сервер, отримавши запит, виконує його (наприклад, завантажує вказаний урл).

Після скачування даних сервер виставляє пароль "2", а клієнт чекає цього пароля.

Отримавши пароль "2", клієнт встановлює пароль "3".

Server, визначивши, що вже встановлений пароль "3", починає побітового передачу. А ми підтверджуємо кожен біт установкою пароля "3".

Існує дуже багато можливостей реалізувати даний трюк, проте всі ці можливості настільки різноманітні, що написати якийсь універсальний движок буде досить складно. Наприклад, для одного з місцевих провайдерів існує спосіб передачі до себе інформації по каналу шириною в 2 бита за 1 запит, а в зворотний бік, можна використовувати досить широкий канал шириною близько 24 байти.

Передісторія знаходження такого збоченого методу передачі інформації досить невесела. Вечорами і ночами я працював у місті Норильську, обслуговуючи одну з місцевих контор, план робіт давно закінчив, а робити було нічого, от і згадав про провайдерів далекого Уралу.

До даної техніці намагався написати движок на Perl, але часу не вистачило, проте дещо залишилося.

При передачі інформації таким чином необхідно:

Шифрувати інформацію

упаковувати

Звичайно ж використовувати 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

asasasasasasasasasasas

Режим движка "Очікування запиту".

Алгоритм Наступне:

Запускається модуль, що виробляє очікування запиту (все залежить від типу пароля або методу передачі (не виключена можливість передачі засобами XSS атаки, як це реалізоване в одного з Уральських провайдерів)).

При отриманні запиту відбуваються операції, аналогічні 4-8.

Виконується запит в Інтернет (так, ці пункти скоріше будуть у движку, тому що вони виробляються звичайним способом, наприклад, за допомогою бібліотеки LWP).

Приймається відповідь з Інтернету.

Упаковуються дані.

зашифровуються дані.

Запускається модуль відправки результату, який і приймає відповідні дані.

Бібліотеки, які я вам раджу для розробки: LWP, Compressed:: ZLib, MIME:: Base64.

Мабуть на цьому можна зупинитися. Хочеться додати лише приклади збочених методів передачі:

передача інформації за рахунок лічильників відвідувань (потрібен контроль за правильністю передачі, адже не виключені заходи інших користувачів);

аналіз затримок відповіді сервера (можна штучно створювати незначні затримки з будь-якою боку різними методами);

в деяких випадках передачу даних можна здійснювати за рахунок сесій (номери яких зазвичай зберігаються у клієнта в куках).

Список літератури Для підготовки даної роботи були використані матеріали з сайту http://www.bugtraq.ru/ (adsbygoogle = window.adsbygoogle || []).push({});

Список літератури
Для підготовки даної роботи були використані матеріали з сайту http://www.bugtraq.ru/