Easy hack хакерські секрети простих речей
Зібрати інформацію по заголовкам email
Ти навіть сам можеш відправити лист, використовуючи ncat або Telnet. Все, що потрібно, - це чотири команди: HELO, MAIL TO, RCPT TO, DATA (хоча є ряд обмежень в залежності від налаштувань сервера). Також варто відзначити, що кожен лист має заголовки і тіло повідомлення. Заголовки тільки частково відображаються кінцевому користувачеві (наприклад, «Subject:") і використовуються, наприклад, при поверненні листи з-за проблем в кінцевому MTA.
Підсумок. Відправляємо один лист секретарці в якусь компанію, та нам відповідає. І ми вже знаємо, що й до чого у них там :).
Отримати список доменів
Продовжимо збір інформації. Давай уявимо собі компанію, яку ми хочемо поламати зовні. Одна з перших завдань для пентеста через інтернет - отримати список доменних імен / віртуальних хостів. Методів багато, і вони старі як світ: зворотний ні перетворювати IP, перебір імен, гуглохакінг. І жоден з них не дає повного результату, так що спробуємо використовувати їх всі разом, попутно додавши чогось новенького :).
«Новеньке» - це збір інформації про імена за допомогою SSL. Отже, давай згадаємо основу. При підключенні по SSL до будь-якого сервера він повертає нам свій сертифікат. Сертифікат - це набір полів (в тому числі і відкритий ключ сервера), підписаний кореневим центром сертифікації. У ньому також є поле CN (Common Name), де міститься ім'я сервера, на який видано цей сертифікат. Це вже щось.
Але це ще не все. Є ще одне маловідоме поле того ж сертифіката - SubjectAltName. Воно дозволяє задавати альтернативні імена. Тобто фактично один ключик може бути використаний для зовсім різних імен. Дивись малюночки, і все стане ясно.
Виходить, що начебто з «сек'юріті» -фішкі ми дістаємо крупиці цікавить нас інформації. Зазначу ще з особистого досвіду, що іноді в сертифікати потрапляє інформація і про внутрішні іменах хостів.
Атакувати з використанням техніки session puzzling
Логічні уразливості - це завжди весело. Вони бувають простими і складними, але їх об'єднує одне - необхідність правильно подумати. Ось тільки є з ними і невелика проблема: їх якось не особливо типізують (можливо, як раз-таки тому, що вони всі такі різноманітні :)). Ну да ладно. Хочу розповісти тобі про цікавій техніці (або вигляді вразливостей, це вже як подивитися), яку презентували відносно недавно, пару років назад. Назва їй - session puzzling або session variable overloading (за версією OWASP).
- Юзер входить на сайт.
- Юзер вводить логін і пароль і відправляє на сервер.
- Сервер перевіряє ці дані і, якщо все вірно, пускає його у внутрішню частину, при цьому відправляючи користувачеві cookie в HTTP-відповіді.
- Коли користувач переходить на якусь ще сторінку, браузер додає до запиту куки. Сервер по даній Кука розуміє, що юзер вже аутентифікований, і працює відповідно до цією думкою.
Все виглядає цілком чітко, але тут пропущений важливий момент. Він полягає в тому, що сервер зберігає у себе інформацію про сесії конкретного користувача. Тобто приходить кука від користувача, він бере її і дивиться (в пам'яті, в БД - в залежності від ПО), а що ж до неї у нього «прив'язане». Найпростіший приклад: він може зберігати ім'я користувача в сесії. І по Кука отримувати з сесії ім'я і точно знати, хто до нього звернувся в даний момент.
Взагалі, в сесії зберігають зазвичай «тимчасову» інформацію, а щось більш-менш постійне - вже в БД. Наприклад, логічно зберігати ім'я користувача в сесії, а ось його «роль» можна зберігати в БД і запитувати тільки за потребою. Тут, насправді, багато що залежить від конкретного додатка і розробника ПЗ.
Наприклад, зберігання великого обсягу даних в сесії може привести до вичерпання або пам'яті веб-сервера (Tomcat), або вільного місця на жорсткому диску (PHP). З іншого боку, звернення до БД вимагають більше часу. Обумовлений вибір зазвичай продуктивністю, і про безпеку тут рідко думають (звичайно, адже як можна вплинути на те, що зберігається на серверній стороні?).
І ось ми підійшли до самої суті даної атаки: в певних ситуаціях ми можемо впливати на те, що зберігається на сервері. У яких конкретно - це теж залежить від ситуації. Найчастіше нам потрібні кілька різних точок входу в додатки, дані з яких потрапляють в одну і ту ж змінну сесії.
Я приведу класичний приклад, і все буде ясно. Та ж ситуація, що описана вище. Клієнт, який може входити в приватну зону на сайті через сторінку логіна. Сайт, який зберігає ім'я клієнта в сесії, а доступ до приватних сторінок перевіряє по імені користувача з сесії.
Але додамо до цього сторінку з відновленням пароля, на якій ти повинен ввести своє ім'я (1), а система у відповідь задасть секретне питання (2), на який ти повинен будеш ввести правильну відповідь для скидання пароля (3). І, як ти ймовірно вже зрозумів, для того щоб провести по цій послідовності тебе (від 1 до 3), сервер повинен також скористатися сесією і зберігати в ній своє ім'я користувача.
Так ось, атака буде полягати в тому, що, коли ми заходимо на сторінку відновлення і вводимо ім'я користувача адміністратора, сервер в сесії зазначає, що юзер - адмін, і виводить для адміна секретне питання. Усе! Ми можемо нічого не вводити, а просто перейти на приватний розділ сайту. Сервер подивиться сесію, побачить, що ім'я користувача адміністратора, і дасть нам доступ. Тобто під час відновлення пароля ми «поставили» необхідне нам значення і далі пішли борознити приватні частини. Бага тут і в тому, що сайт використовує одне ім'я змінної і при аутентифікації, і при відновленні пароля.
Спочатку може здатися, що даний тип вразливості - рідкість. Насправді це не так. Я особисто знаходив такі в досить поширених продуктах. Ось тільки не знав тоді, що це так називається.
До речі, крім обходу аутентифікації, використовувати дану техніку можна для підвищення привілеїв чи перескоку кроків на багатокрокових операціях ...
Як шукати такого типу баги? Фактично якийсь суперметодікі для цього немає. Але в якості початку необхідно вишукати вхідні точки в додаток, що мають потенційну можливість впливати на значення в сесійних змінних. А далі - мозок, руки і тести, тести, тести.
Провести атаку з підробкою Host
Ще один приклад майже логічної веб-уразливості. Вона заснована на можливості підробки заголовка Host HTTP-запиту. Точніше, на відсутності його перевірки веб-сайтом при його подальшому використанні. Але по порядку.
Взагалі, з точки зору безпеки, це трохи дивна, але безпечна ситуація. Здавалося б, так, підставивши своє доменне ім'я в Host, ми можемо зробити так, щоб на ресурс завантажилися б наші JS-скрипти (вважай - XSS). Але змусити чужий браузер зробити те ж саме (тобто вставити невірний Host), по суті, неможливо. Так що з точки зору SOP тут все начебто цілком нормально.
Але все ж у цій атаці щось точно є.
поламати UPnP
Universal Plug and Play (UPnP) - це набір мережевих протоколів, які були створені для спрощення взаємного знаходження різними девайсами, а також для їх взаємодії. Девайсом в даному випадку може бути майже все що завгодно: роутер, принтер, smartTV, якісь сервіси Windows ... І хоча, можливо, термін UPnP здається тобі незнайомим, фактично він дуже і дуже поширений.
З точки зору прикладу взаємодії можна подивитися в сторону Skype або BitTorrent і Wi-Fi-роутерів. Перші за допомогою UPnP можуть знайти роутер і відправити йому набір команд на кидок якогось зовнішнього порту всередину. Дуже зручно виходить: ніяких проблем з налаштуванням port forwarding'а.
UPnP ґрунтується на декількох протоколах, а також, що важливіше, на певній логічній послідовності:
Крім прослушки 239.255.255.250, ми «насильно» можемо посилати M-SEARCH запити на той же 1900-й порт. UPnP-сервери повинні будуть відповісти на даний запит. Відповідають все тим же Notify-пакетом.
Отже, перше завдання - це, по суті, отримання списку UPnP-серверів, а також URL'ов до XML'ек, з повним описом функціональних можливостей кожного з сервісів сервера. Це важливо, тому що і порт, і URL'и можуть бути різними у різних виробників.
Визначення можливостей. Отже, з SSDP ми отримуємо список сервісів з посиланням на їх опис в форматі XML. Для доступу до них вже використовується звичайний HTTP. В даному файлі йде опис кожного з сервісів, а також посилання на XML-файли зі списком можливих дій для кожного з них. Тобто в даному випадку XML'кі - це просто статичні описи всіх можливостей сервісів, а також перелік вхідних точок в сервіси і необхідних даних для виконання дій.
Контроль. Отримавши дані XML'кі, ми вже можемо створювати SOAP-пакети і посилати їх на сервер по HTTP, виконуючи, таким чином, якісь дії на сервері.
Аутентифікація, як я вже говорив, відсутня, і сервер виконає всі дії, які йому прийдуть в SOAP-запиті.
На жаль, даний спосіб більше не працює: з тих пір стала жорсткішою пісочниця Flash'а і ми вже не можемо посилати довільні POST-запити (найголовніше, нам треба додати ще заголовок SOAPAction) на будь-який інший хост (так як спочатку відбудеться запит на дозвільні правила в crossdomain.xml).
Отже, тепер, я думаю, ми бачимо, як це все працює. Давай ще подивимося, що можна з цим зробити.
По-перше, це прошиті можливості SOAP'а. Крім прикладу з кидок портів, є випадки, коли ми можемо змінити налаштування роутера і виставити свій DNS-сервер. А це вже ого-го! Тут все залежить від конкретного пристрою, сервісів і нашої фантазії.
По-третє, ми можемо поламати самі сервіси. Рік тому Rapid7 зробили прикольні дослідження UPnP. Вони просканілі інтернет на SSDP і на SOAP (через загальні порти), пофінгерпрінтілі їх. Виявилося, що більшість UPnP-серверів побудовано на чотирьох SDK. З них виділяються MiniUPnP і Portable UPnP (libupnp), на яких «тримається» більше половини. Але що важливіше, майже всі сервери використовують застарілі версії бібліотек, в кожній з яких є пучок вразливостей, в тому числі що призводять до RCE. Причому і в SOAP'е, і в SSDP.
Крім того, в цьому дослідженні показано, як насправді багато таких пристроїв стирчить назовні, хоча б SSDP. Тобто навіть якщо той же SOAP закритий, ми можемо захопити віддалений контроль над пристроєм через SSDP.
Звичайно, тут треба відзначити, що з віддаленим сплоітінгом може бути не дуже просто, так як пристрої ці часто побудовані на всяких MIPS, ARM, що точно все ускладнює. До того ж доведеться боротися ще й з механізмами захисту пам'яті ОС (той же ASLR). Але все-таки це можливо.
Що ж нам треба, щоб все поламати?
Тулз на ділі трохи. У метасплоіте є модуль для пошуку UPnP (і детектив CVE по ним). Плюс є два «комбайна», що дозволяють виконувати SOAP-команди. Це Miranda і Umap. Обидва написані на Python'е, тільки під * nix і при цьому не дуже добре працюють.
Сподіваюся, прочитане наповнило тебе ентузіазмом і жагою до життя, так що якщо є бажання поресерчіть - пиши на ящик. Завжди радий :). І успішних знань нового!
Покажи цю статтю друзям: