Коллектив авторов - Защита от хакеров корпоративных сетей

1; SELECT * FROM table WHERE y=5 #

приводит к выполнению запроса

… WHERE x=1; SELECT * FROM table WHERE y=5 # AND z=4

и заставляет сервер игнорировать выражение AND z=4.

В этих примерах было известно название атакуемой таблицы, что случается нечасто. Для составления правильного SQL-запроса нужно знать имя таблицы и названия столбцов. Обычно главная проблема в том, что эта информация недоступна пользователям. Но для злоумышленника не все так плохо. Разные системы управления базами данных обеспечивают различные способы получения системной информации о таблицах базы данных. Например, обращаясь с запросом к таблице sysobjects Microsoft SQL Server (с помощью запроса Select * from sysobjects запрос), можно получить информацию о всех зарегистрированных в базе данных объектах, включая хранимые процедуры и названия таблиц.

Занимаясь хакингом SQL, хорошо бы знать возможности серверов баз данных. Из-за особенностей хакинга SQL злоумышленник может не увидеть результатов своей работы, поскольку большинство приложений не предназначены для обработки вложенных запросов. Поэтому злоумышленнику может потребоваться много времени, прежде чем он удостоверится, что получил доступ к базе данных. К счастью, здесь нет легких решений, потому что для нормальной работы большинство команд SQL требуют задания имен таблиц. Следует творчески поработать, чтобы узнать их.

Вслепую или нет, но хакинг SQL возможен. Для этого может потребоваться понимание принципов работы серверов баз данных. Следует познакомиться с хранимыми процедурами и расширениями SQL анализируемого сервера. Например, сервер Microsoft SQL поддерживает хранимую процедуру рассылки результатов запроса по электронной почте. Это может пригодиться для просмотра результатов работы вложенных запросов. Сервер MySQL может сохранять результаты запросов в файле, позволяя впоследствии восстанавливать результат. Всегда следует попытаться использовать дополнительные возможности сервера базы данных с выгодой для себя.

Аутентификация приложений

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

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

Во-первых, ключ должен быть действительно случайным. Любая предсказуемость ключа повысит шансы злоумышленника вычислить его. Ключ не следует вычислять при помощи линейной возрастающей функции. Системные функции UNIX /dev/random и /dev/urandom могут не обеспечить необходимой случайности ключей, особенно при генерации ключей большого размера. Например, слишком быстрый вызов функций /dev/random или /dev/ urandom может отразиться на «случайности» генерируемых ключей, потому что в этом случае функции обращаются к предсказуемому генератору псевдослучайных чисел.

Во-вторых, ключевое пространство должно быть достаточно большим по отношению к числу ключей, необходимых в любой момент времени. Пусть ключ имеет 1 млрд возможных значений. Страшно даже подумать об атаке «грубой силы» на ключевое пространство в 1 млрд ключей. Но популярный сайт электронной коммерции может обслуживать около 500 000 открытых сессий каждый рабочий день. В этом случае у злоумышленника хорошие шансы найти подходящий ключ в каждой серии из 1000 проверенных ключей (в среднем) и его не отпугнет последовательный перебор 2000 ключей со случайно выбранного значения.

Рассмотрим некоторые современные схемы аутентификации. Какое-то время назад организация PacketStorm (www.packetstormsecurity.org) решила перепрограммировать на языке Perl программное обеспечение своего Web-форума после нахождения уязвимости в пакете wwwthreads.

authkey=rfp.23462382.temp&uname=rfp

Рассматривая систему аутентификации как «черный ящик» без малейшего представления о принципах его работы, была предпринята попытка найти закономерности работы системы при изменении входных данных параметров. Первый шаг состоял в изменении значения параметра authkey: сначала имени пользователя, а затем случайного числа и дополнительной величины «temp». Целью данных манипуляций было проверить возможность аутентификации пользователя с другими случайными недействительными значениями параметра. Не получилось. Затем значение параметра uname было изменено на другое правильное имя пользователя. В результате была получена строка вида

authkey=rfp.23462382.temp&uname=fringe.

После этого удалось зарегистрироваться под именем другого пользователя («fringe»). Исходя из этого, был восстановлен фрагмент программы аутентификации на языке Perl (заметим, что без знания истинного кода форума PacketStorm):

if (-e “authkey_directory/$authkey”) {

print “Welcome $uname!”;

# do stuff as $uname

} else {

print “Error: not authenticated”;

Таким образом, authkey – это файл, создаваемый при входе в систему с использованием случайного числа. Приведенный фрагмент программы позволяет любому пользователю, изменившему параметр uname, получить доступ к учетной записи иного пользователя, используя известный и правильный authkey (например, свой собственный).

Основываясь на форматах параметров authkey и uname, естественно было предположить, что значение authkey относится к файловой системе. Прежде всего потому, что значение параметра authkey в формате username.999999. temp не похоже на информацию, которую хранят в базе данных. Вполне возможно, что приложение разделяло параметр authkey на три части, используя для запроса к базе данных имя пользователя и случайное число. При этом отпадала необходимость в передаче через значение параметра uname имени пользователя, а постоянное окончание «.temp» становилось бесполезным и бессмысленным. Следуя интуиции и зная, что формат представления параметра authkey похож на задание имени файла, было высказано предположение, что значение параметра authkey определяет имя файла, как в итоге и оказалось.

if (-e “ authkey_directory/$authkey” && $authkey=~/^$uname/) {

print “Welcome $uname!”;