Впрочем, сделать это будет не так уж и просто. Необходимо иметь опыт программирования на Perl/PHP и знать, как может выглядеть та или иная форма запроса и как чаще всего именуются поля таблицы, в противном случае интерполяция ни к чему не приведет. Непосредственной возможности определения имен полей и таблиц у хакера нет, и ему приходится действовать методом слепого перебора (blinding).

Однако большинство администраторов и Web-мастеров слишком ленивы, чтобы разрабатывать все необходимые им скрипты самостоятельно, и чаще они используют готовые решения, исходные тексты которых свободно доступны в сети. Причем, большинство этих скриптов дырявы как ведро без дна. Взять, к примеру, тот же PHP Nuke, в котором обнаруживаются все новые и новые уязвимости.

Приблизительная стратегия поиска дыр выглядит так. Скачиваем исходные тексты PHP Nukе (или любой другой портальной системы), устанавливаем их на свой локальный компьютер, проходимся глобальным поиском по всем файлам, откладывая в сторонку все те, что обращаются к базе данных (вызов типа mysql_query/mysql_db_query или типа того). Далее прокручиваем курсор вверх и смотрим – где-то поблизости должна быть расположена строка запроса к базе (например: $query = «SELECT user_email, user_id FROM ${prefix}_users WHERE user_id = '$cookie[0]'»). Определяем имена переменных, подставляемых в базу, находим код, ответственный за передачу параметров пользовательского ввода и анализируем условия фильтрации.

В качестве наглядного примера рассмотрим одну из уязвимостей PHP Nuke 7.3, связанную с обработкой новостей. Соответствующий ей URL выглядит так: modules.php?name=News&file=categories&op=newindex&catid=1. По его внешнему виду можно предположить, что значение catid передается непосредственно в строке запроса к БД, и, если разработчик скрипта забыл о фильтрации, у нас появляется возможность модифицировать запрос по своему усмотрению. Для проверки этого предположения заменим catid с 1, допустим, на 669. Сервер немедленно отобразит в ответ пустой экран. Теперь добавим к нашему URL следующую конструкцию «'or'1'1='1» (полностью он будет выглядеть так: modules.php?name=News&file=categories&op=newindex&catid=669'or'1'='1). Сервер послушно отобразит все новостные сообщения раздела, подтверждая, что SQL-инъекция сработала!

Еще можно попытаться вызвать ошибку SQL, подсунув ей заведомо неправильный запрос (например, символ одиночной кавычки), и тогда она может сообщить много интересного. Отсутствие ошибок еще не означает, что скрипт фильтрует пользовательский ввод: быть может, он просто перехватывает сообщения об ошибках, что является нормальной практикой сетевого программирования. Также возможна ситуация, когда при возникновении ошибки возвращается код ответа 500 или происходит переадресация на главную страницу. Подобная двусмысленность ситуации существенно затрудняет поиск уязвимых серверов, но отнюдь не делает его невозможным!

Анализ показывает, что ошибки фильтрации встречаются в большом количестве скриптов (включая коммерческие), зачастую оставаясь неисправленными годами. Естественно, дыры в основных полях ввода давным-давно заткнуты, а потому рассчитывать на быстрый успех уже не приходится. Запросы, передаваемые методом POST, протестированы значительно хуже, поскольку передаются скрыто от пользователя и не могут быть модифицированы непосредственно из браузера, отсекая армаду начинающих «хакеров». Между тем, взаимодействовать с Web-сервером можно и посредством netcat (telnet), формируя POST-запросы вручную.

SQL-инъекции в очередной раз продемонстрировали миру, что программ без ошибок не бывает. Однако не стоит переоценивать их значимость. Мавр сделал свое дело, мавр может удалиться. Администраторы и девелоперы знают об опасности, и количество уязвимых сайтов тает с каждым днем. Реальную власть нас системой дают лишь принципиально новые методики атак, неизвестные широкой общественности. Найти их – наша с тобой задача. Освободи свой разум, перешагни грань неведомого и зайди на сервер с той стороны, с которой на него еще никто не заходил.

Вскрытие скрипта

Нормально работающий Web-сервер никогда не выдает исходный код скрипта, а только результат его работы. Между тем, вездесущие ошибки реализации приводят к тому, что код скрипта в некоторых случаях все-таки становится доступным, причем виновником может быть как сервер, так и обрабатываемый им скрипт. Естественно, в скриптах ошибки встречаются намного чаще, поскольку их пишут все кому не лень, порой не имея никакого представления о безопасности. Серверы же проходят более или менее тщательное тестирование, и основные дыры обнаруживаются еще на начальной стадии.

Подробнее об этом можно прочитать в моей статье «Безопасное программирование на языке Perl» (kpnc.opennet.ru/safe.perl.zip).

Исследуя тело скрипта, можно нарыть немало интересного, например, имена полей, названия таблиц, мастер-пароли, хранящиеся открытым текстом, и т.д.

ЛИСТИНГ

…

if ($filename eq «passwd») #проверка имени на корректность

…

Определение наличия SQL

Прежде чем начинать атаку на SQL-сервер, неплохо бы определить его присутствие, а в идеале – еще и распознать тип. Если сервер расположен внутри DMZ (где ему находиться ни в коем случае нельзя), то атакующему достаточно просканировать порты.

Противодействие вторжению

Когда ручной поиск дыр надоедает, взломщики, в сердцах обложив всех Web-программистов смачным матом, запускают свое средство автоматического поиска уязвимостей и идут на перекур.

Одним из таких средств является Security Scanner, разработанный компанией Application Security и официально предназначенный для тестирования MySQL на стойкость к взлому. Ну, хакерам официоз не грозит. Как и всякое оружие, Security Scanner может использоваться и во вред, и во благо.

Он позволяет искать дыры как в самом сервере БД, так и в Web-скриптах. При этом БД проверятся на предмет уязвимости к атакам типа Denial of Service, наличия слабых паролей, неверно сконфигурированных прав доступа и т.д. В скриптах сканер позволяет обнаружить ошибки фильтрации ввода, позволяющие осуществлять SQL-инъекции, что значительно упрощает атаку.

Никита Кислицин, редактор рубрики «Взлом» журнала «Хакер»:

«Базы данных всегда были лакомым кусочком для хакеров. И в этом нет ничего удивительного: в них можно найти миллионы номеров кредитных карт, пароли к сетевым ресурсам, конфиденциальную информацию и даже планы террористических организаций по захвату цивилизованного мира. Увы, порой администраторы сетевых баз данных не уделяют должного внимания безопасности, часто их подводят и программисты, разрабатывающие программные интерфейсы. Следует знать, что в более чем половине случаев взлома SQL-серверов используется технология SQL-инъекции в разных ее проявлениях, то есть эти проблемы лежат на совести Web-программистов. Однако бывают и вовсе комические случаи. За примером далеко ходить не надо. „Xакер“ недавно писал о взломе cygwin.com и экспроприации оттуда вкуснейшей базы данных. Высокопрофессиональный админ этого сервера почему-то решил не указывать вообще никакого пароля к администраторскому аккаунту MySQL, что и позволило нашему партизану при помощи детского бага в скрипте совершить столь дерзкую вылазку».

Размещать сервер базы данных на одном узле с Web-сервером категорически недопустимо не только по техническим, но и по юридическим соображениям.

Сервер БД, как и любой другой сервер, подвержен ошибкам проектирования, среди которых доминируют переполняющиеся буфера.

Многие сервера хранят информацию об авторизации в кукисах (cookie), находящихся на машинах удаленных пользователей.

Почти 30% всех скриптов в сети подвержены ошибке SQL-инъекции.