Абсолютно безопасных систем не бывает. Это же касается и баз данных. Но зачем напрягаться, компилируя кучу эксплоитов, и, почесывая лысину, искать ошибки по всему компьютеру, на котором и хранится база данных, если можно совершить взлом, используя только внутренние возможности сервера базы данных. И такая техника взлома называется SQL Injection. Об этом и поговорим.
Это просто
При словах "База данных" у многих людей в первую очередь возникают ассоциации с вшивыми бородатыми программистами, ваяющими программы для всяких мелких контор. Да и вообще, бытует мнение, что БД - редкая вещь, которая используется разными извращенцами для своих извращенческих нужд. Это не так. Базы данных в Интернете используются повсеместно, хранится в них все что угодно, начиная от сообщений в гостевой книге и заканчивая номерами кредитных карт. Но раз есть базы данных, значит - есть и ошибки в них.
Самое интересное: когда программисты пишут cgi-приложения, то в основном делают упор на безопасность работы именно самого приложения (т.е. чтобы не было всяких там \..\ и прочих морально устаревших глюков), но, как показывают статистические исследования, пока мало кто обращает внимание на безопасность обмена информацией между приложением и базой данных. Если подумать глобально, то эту информацию можно перехватить только используя снифферы, но в 99% процентах случаев возможности установить их на атакуемой машине нет.
И не надо сейчас расстраиваться, речь пойдет вовсе не о снифферах, разговор будет обо всех странных возможностях серверов баз данных, позволяющих получить любую информацию на атакуемой машине (да-да, ты узнаешь, какого цвета админ носит трусы
. Рассматривать все возможности всех типов баз данных в одной статье просто теоретически невозможно, и поэтому я остановлюсь на самом популярном типе БД - SQL.
Сама SQL имеет длинную историю и огромное количество фенечек, фишечек и прибамбасов, и о всех них не знают даже сами разработчики SQL (файл changelog в дистрибутиве весит 130 кб). Но чаще всего о них не знают горе-программисты, пишущие приложения для работы с такой базой данных.
По статистике в Интернете около 60% приложений, работающих с различного рода БД, подвержены атакам, позволяющим модифицировать запрос к БД и заставить ее работать не совсем корректно. И этот класс атак называется SQL Injection атаками. Эта уязвимость не просто повсеместно распространена, она есть даже в таких неприступных крепостях, как серверы статистики многих провайдеров - у одного крупного воронежского прова эта уязвимость не просто есть, она у него в классическом виде, именно в таком, в каком ее использовать сможет абсолютно любой человек. (Оффтопик: Да, дибилизм - это заразно. Мало того, что у него дырявая база данных, так у него еще и НТ четвертая вместе со всеми примерами и сэмплами поставлена. Не знаю, лечится ли это, но в данном случае скорее всего - нет.)
Действуем
Ну да ладно, немного я увлекся. Для проверки приложения на вшивость (например, скрипта какого-нибудь онлайн-магазина) сначала корректно заполни все поля для ввода, а потом по очереди подставляй в конец каждого поля кавычку ('). Если после отправки заполненной таким корявым образом формы на сервер тебе выпрыгнет сообщение об ошибке
или что-нибудь очень похожее, то мы на верном пути и флаг нам в руки.
Теперь представим, как идет обмен данными между SQL-сервером и нашим глючным приложением. Вот тебе уязвимый кусочек asp-кода, не запрещающий sql injection:
var sql = "select * from users where
username = '" + username + "' and password = '" + password + "'";
Таким образом, если username=vasya и password=pupkin, то все сработает корректно и без ошибок и asp-скрипт передаст SQL-серверу команду
select * from users where username='vasya' and password='pupkin'
Но ежели мы наглым образом сделаем своим именем пользователя vasya', то команда станет такой:
select * from users where username='vasya'' and password='pupkin'
После этого запроса SQL глюканет и выдаст нам ошибку, мол мы кавычек слишком много насажали. Теперь будем думать логически: нам нужно обойти проверку имени и пароля в этом скрипте, т.е. отбросить кусок запроса "and password='pupkin'". Разработчики SQL все уже придумали до нас, и нам всего лишь остается закомментировать этот хвост. В языке SQL все комментарии начинаются с двух минусов (--), и все, что идет после них, сервер в расчет не берет; т.е. чтобы заставить рассмотренный выше кусочек asp'a пустить нас без пароля вместо юзернейма "vasya", надо будет вписать вот такую байду:
"vasya'; -- " (без кавычек, естественно)
Теперь разберемся, какой символ что тут означает. Кавычка после vasya закрывает поле username; точка с запятой говорит, что в данный момент у нас это конец всей команды; а два минуса показывают, что можно забить на все идущее после них.
Смотрим кишки базы
Так, без пароля нас уже пускают, но это еще не все, что можно сотворить с атакуемой машиной. Для начала нам нужно узнать, какие базы данных есть на удаленной машине. Чтобы это узнать, возвращаемся к нашему полю для ввода username'a и пишем туда такую вещь:
"vasya'; show databases; --" (опять же без кавычек)
Если после отправки такой формы на сервер тебе вывалится списочек, чем-то похожий на этот:
mysql> show databases;
+----------+
| Database |
+----------+
| MYSQL |
| TEST |
| voy |
+----------+
3 rows in set (0.00 sec)
то мы не просто на верном пути, мы лошадиными шагами движемся к получению свопа всех баз данных на сервере. Я думаю, посланную команду подробно разбирать не надо, тут все не сложно, только одна маленькая заметка: в языке SQL в одной строчке может быть несколько команд, разделенных точками с запятыми. Этим-то мы в основном пользоваться и будем.
После того как мы узнали список баз данных, нам нужно увидеть список таблиц в каждой из них. Чтобы осуществить такую задумку, в поле username пишем:
"vasya'; use mysql; show tables; -- "
"vasya'; use test; show tables; -- "
"vasya'; use voy; show tables; -- "
Команда use в данном случае заставляет SQL переключиться на заданную базу данных, а команда show tables показывает нам список всех таблиц в этой базе данных.
Тащим любые файлы с сервера
Так, структуру БД на удаленной машине узнали, теперь осталось поиметь всю информацию. Для осуществления этого противозаконного действия опять в поле username пишем:
"vasya'; select * from table1; -- " (где table1 - существующая таблица в БД)
И вот таким макаром по очереди сливаем информацию из каждой таблицы.
В принципе на такой удаче можно остановиться, но SQL - безграничное поле для всяких извращений. Ее можно заставить вытворять все, что душе пожелается - от чтения любого файла с диска до работы с реестром в виндах.
Для первого раза попробуем схватить какой-нибудь файл с диска. Для этого тебе нужны будут права на создание таблиц и запись в них. Сначала создадим подопытную таблицу, при помощи которой будем хватать любой файл с диска. Создаем ее уже привычным способом: в поле username пихаем:
"vasya'; create table dead_gibbon (tab1 varchar(200), tab2 varchar(200), tab3 varchar(200));
Вот мы создали таблицу с тремя столбцами. Небольшой комментарий: выражение "tab1 varchar(200)" говорит, что надо создать столбец с именем tab1 и максимальным значением 200. Теперь осталось воткнуть в свежесозданную таблицу требуемый файл
"vasya'; load data infile "/../../../../boot.ini" into table dead_gibbon; -- "
и посмотреть, что же у нас получилось:
"vasya'; select * from dead_gibbon; -- "
Конечно, файл в таблице окажется не в лучшем своем состоянии, каждая новая строчка файла будет эквивалентна каждой новой строчке в таблице, но в принципе даже этого хватает, чтобы таскать с сервера не очень большие файлы.
Выполняем любые команды
Файлы с диска читать научились, теперь осталось добиться командной строки на сервере. Такую задачу можно достичь только на SQL-серверах небезызвестной компании Microsoft. Именно при помощи MsSQL любой версии на удаленной машине можно исполнять любые команды. Для этого нужно отослать на сервер команду
exec master..xp_cmdshell 'dir'
и этим самым увидеть листинг текущей директории. Но это еще не все! Ребятки из Майкрософта постарались на славу и даже подключили к серверу возможность работы с реестром. Например:
exec xp_regread HKEY_LOCAL_MACHINE, 'SYSTEM\CurrentControlSet\Services\lanmanserver\parameters', 'nullsessionshares';
Это всего лишь пример, а вот список всех команд, позволяющих творить с реестром такие кренделя, которые сам создатель на этапе компиляции не задумывал:
xp_regaddmultistring (добавляем строковый параметр)
xp_regdeletekey (удаляем ключ)
xp_regdeletevalue (удаляем значение ключа)
xp_regread (читаем ключ)
xp_regremovemultistring (удаляем строковый параметр)
xp_regwrite (пишем информацию в реестр)
Это далеко не весь список заподлянских команд. Все остальные ты сможешь прочитать в документации к серверу.
Защита
Так, хватит мусолить классические случаи SQL-injection атак, ведь в природе есть люди, пытающиеся защититься от такого рода атак. Но опять же язык SQL имеет такое количество исключений и примочек, что запретить их все просто теоретически нельзя. Есть только один метод защиты - разрешить для ввода только символы ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghigklmnopqrstuvwxyz1234567890, а также запретить ключевые слова SQL "select, use, drop, insert и т.д.
По моему мнению, так и только так должна выглядеть защита от SQL-injection атак. Остальные методы (например, запрещение только ключевых слов и метасимволов ";" и "'") обходятся достаточно грациозно. Если скрипт отфильтровывает какой-либо символ, то его можно заменить конструкцией +char(0xКОД_СИМВОЛА)+. Теперь конструкция для вывода содержимого БД без использования кавычек будет выглядеть так:
select user from user where char(0x27)+user+char(0x27)=char(0x27)+char(0x27);
что абсолютно эквивалентно вот этой вещи:
select user from user where 'user'='';
Ну, я думаю, для первого раза хватит. Если вдруг тебе мало, то можешь схватить небольшую подборку статей на эту тему у меня на сайте www.voy85.org. После того как переваришь всю полученную информацию, запомни, что базы данных используются в самых желанных местах для взломщиков - SQL встречается в музыкальных архивах, у провайдеров, в онлайн-магазинах, в банках... Дальше список продолжать? Базы данных - это всегда лакомый кусочек, который никто не прочь урвать.
И еще на будущее: об SQL injection слышали далеко не все админы, так что если найдешь таковую уязвимость на каком-нибудь более-менее крупном сайте, то не спеши устраивать акты вандализма на месте преступления. После всего напиши админу письмо с описанием того, как ты совершил взлом. Админы - они хоть иногда и свиньи, но все же они люди, и помощь им никогда не бывает лишней.
Это просто
При словах "База данных" у многих людей в первую очередь возникают ассоциации с вшивыми бородатыми программистами, ваяющими программы для всяких мелких контор. Да и вообще, бытует мнение, что БД - редкая вещь, которая используется разными извращенцами для своих извращенческих нужд. Это не так. Базы данных в Интернете используются повсеместно, хранится в них все что угодно, начиная от сообщений в гостевой книге и заканчивая номерами кредитных карт. Но раз есть базы данных, значит - есть и ошибки в них.
Самое интересное: когда программисты пишут cgi-приложения, то в основном делают упор на безопасность работы именно самого приложения (т.е. чтобы не было всяких там \..\ и прочих морально устаревших глюков), но, как показывают статистические исследования, пока мало кто обращает внимание на безопасность обмена информацией между приложением и базой данных. Если подумать глобально, то эту информацию можно перехватить только используя снифферы, но в 99% процентах случаев возможности установить их на атакуемой машине нет.
И не надо сейчас расстраиваться, речь пойдет вовсе не о снифферах, разговор будет обо всех странных возможностях серверов баз данных, позволяющих получить любую информацию на атакуемой машине (да-да, ты узнаешь, какого цвета админ носит трусы
. Рассматривать все возможности всех типов баз данных в одной статье просто теоретически невозможно, и поэтому я остановлюсь на самом популярном типе БД - SQL.Сама SQL имеет длинную историю и огромное количество фенечек, фишечек и прибамбасов, и о всех них не знают даже сами разработчики SQL (файл changelog в дистрибутиве весит 130 кб). Но чаще всего о них не знают горе-программисты, пишущие приложения для работы с такой базой данных.
По статистике в Интернете около 60% приложений, работающих с различного рода БД, подвержены атакам, позволяющим модифицировать запрос к БД и заставить ее работать не совсем корректно. И этот класс атак называется SQL Injection атаками. Эта уязвимость не просто повсеместно распространена, она есть даже в таких неприступных крепостях, как серверы статистики многих провайдеров - у одного крупного воронежского прова эта уязвимость не просто есть, она у него в классическом виде, именно в таком, в каком ее использовать сможет абсолютно любой человек. (Оффтопик: Да, дибилизм - это заразно. Мало того, что у него дырявая база данных, так у него еще и НТ четвертая вместе со всеми примерами и сэмплами поставлена. Не знаю, лечится ли это, но в данном случае скорее всего - нет.)
Действуем
Ну да ладно, немного я увлекся. Для проверки приложения на вшивость (например, скрипта какого-нибудь онлайн-магазина) сначала корректно заполни все поля для ввода, а потом по очереди подставляй в конец каждого поля кавычку ('). Если после отправки заполненной таким корявым образом формы на сервер тебе выпрыгнет сообщение об ошибке
Code:
Microsoft OLE DB Provider for ODBC Drivers (0x8004CC14)
[Microdoft][ODBC SQL Server Driver][SQL Server][Unclosed
quotation mark before the character string ")'.
/default.asp, line 239или что-нибудь очень похожее, то мы на верном пути и флаг нам в руки.
Теперь представим, как идет обмен данными между SQL-сервером и нашим глючным приложением. Вот тебе уязвимый кусочек asp-кода, не запрещающий sql injection:
var sql = "select * from users where
username = '" + username + "' and password = '" + password + "'";
Таким образом, если username=vasya и password=pupkin, то все сработает корректно и без ошибок и asp-скрипт передаст SQL-серверу команду
select * from users where username='vasya' and password='pupkin'
Но ежели мы наглым образом сделаем своим именем пользователя vasya', то команда станет такой:
select * from users where username='vasya'' and password='pupkin'
После этого запроса SQL глюканет и выдаст нам ошибку, мол мы кавычек слишком много насажали. Теперь будем думать логически: нам нужно обойти проверку имени и пароля в этом скрипте, т.е. отбросить кусок запроса "and password='pupkin'". Разработчики SQL все уже придумали до нас, и нам всего лишь остается закомментировать этот хвост. В языке SQL все комментарии начинаются с двух минусов (--), и все, что идет после них, сервер в расчет не берет; т.е. чтобы заставить рассмотренный выше кусочек asp'a пустить нас без пароля вместо юзернейма "vasya", надо будет вписать вот такую байду:
"vasya'; -- " (без кавычек, естественно)
Теперь разберемся, какой символ что тут означает. Кавычка после vasya закрывает поле username; точка с запятой говорит, что в данный момент у нас это конец всей команды; а два минуса показывают, что можно забить на все идущее после них.
Смотрим кишки базы
Так, без пароля нас уже пускают, но это еще не все, что можно сотворить с атакуемой машиной. Для начала нам нужно узнать, какие базы данных есть на удаленной машине. Чтобы это узнать, возвращаемся к нашему полю для ввода username'a и пишем туда такую вещь:
"vasya'; show databases; --" (опять же без кавычек)
Если после отправки такой формы на сервер тебе вывалится списочек, чем-то похожий на этот:
mysql> show databases;
+----------+
| Database |
+----------+
| MYSQL |
| TEST |
| voy |
+----------+
3 rows in set (0.00 sec)
то мы не просто на верном пути, мы лошадиными шагами движемся к получению свопа всех баз данных на сервере. Я думаю, посланную команду подробно разбирать не надо, тут все не сложно, только одна маленькая заметка: в языке SQL в одной строчке может быть несколько команд, разделенных точками с запятыми. Этим-то мы в основном пользоваться и будем.
После того как мы узнали список баз данных, нам нужно увидеть список таблиц в каждой из них. Чтобы осуществить такую задумку, в поле username пишем:
"vasya'; use mysql; show tables; -- "
"vasya'; use test; show tables; -- "
"vasya'; use voy; show tables; -- "
Команда use в данном случае заставляет SQL переключиться на заданную базу данных, а команда show tables показывает нам список всех таблиц в этой базе данных.
Тащим любые файлы с сервера
Так, структуру БД на удаленной машине узнали, теперь осталось поиметь всю информацию. Для осуществления этого противозаконного действия опять в поле username пишем:
"vasya'; select * from table1; -- " (где table1 - существующая таблица в БД)
И вот таким макаром по очереди сливаем информацию из каждой таблицы.
В принципе на такой удаче можно остановиться, но SQL - безграничное поле для всяких извращений. Ее можно заставить вытворять все, что душе пожелается - от чтения любого файла с диска до работы с реестром в виндах.
Для первого раза попробуем схватить какой-нибудь файл с диска. Для этого тебе нужны будут права на создание таблиц и запись в них. Сначала создадим подопытную таблицу, при помощи которой будем хватать любой файл с диска. Создаем ее уже привычным способом: в поле username пихаем:
"vasya'; create table dead_gibbon (tab1 varchar(200), tab2 varchar(200), tab3 varchar(200));
Вот мы создали таблицу с тремя столбцами. Небольшой комментарий: выражение "tab1 varchar(200)" говорит, что надо создать столбец с именем tab1 и максимальным значением 200. Теперь осталось воткнуть в свежесозданную таблицу требуемый файл
"vasya'; load data infile "/../../../../boot.ini" into table dead_gibbon; -- "
и посмотреть, что же у нас получилось:
"vasya'; select * from dead_gibbon; -- "
Конечно, файл в таблице окажется не в лучшем своем состоянии, каждая новая строчка файла будет эквивалентна каждой новой строчке в таблице, но в принципе даже этого хватает, чтобы таскать с сервера не очень большие файлы.
Выполняем любые команды
Файлы с диска читать научились, теперь осталось добиться командной строки на сервере. Такую задачу можно достичь только на SQL-серверах небезызвестной компании Microsoft. Именно при помощи MsSQL любой версии на удаленной машине можно исполнять любые команды. Для этого нужно отослать на сервер команду
exec master..xp_cmdshell 'dir'
и этим самым увидеть листинг текущей директории. Но это еще не все! Ребятки из Майкрософта постарались на славу и даже подключили к серверу возможность работы с реестром. Например:
exec xp_regread HKEY_LOCAL_MACHINE, 'SYSTEM\CurrentControlSet\Services\lanmanserver\parameters', 'nullsessionshares';
Это всего лишь пример, а вот список всех команд, позволяющих творить с реестром такие кренделя, которые сам создатель на этапе компиляции не задумывал:
xp_regaddmultistring (добавляем строковый параметр)
xp_regdeletekey (удаляем ключ)
xp_regdeletevalue (удаляем значение ключа)
xp_regread (читаем ключ)
xp_regremovemultistring (удаляем строковый параметр)
xp_regwrite (пишем информацию в реестр)
Это далеко не весь список заподлянских команд. Все остальные ты сможешь прочитать в документации к серверу.
Защита
Так, хватит мусолить классические случаи SQL-injection атак, ведь в природе есть люди, пытающиеся защититься от такого рода атак. Но опять же язык SQL имеет такое количество исключений и примочек, что запретить их все просто теоретически нельзя. Есть только один метод защиты - разрешить для ввода только символы ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghigklmnopqrstuvwxyz1234567890, а также запретить ключевые слова SQL "select, use, drop, insert и т.д.
По моему мнению, так и только так должна выглядеть защита от SQL-injection атак. Остальные методы (например, запрещение только ключевых слов и метасимволов ";" и "'") обходятся достаточно грациозно. Если скрипт отфильтровывает какой-либо символ, то его можно заменить конструкцией +char(0xКОД_СИМВОЛА)+. Теперь конструкция для вывода содержимого БД без использования кавычек будет выглядеть так:
select user from user where char(0x27)+user+char(0x27)=char(0x27)+char(0x27);
что абсолютно эквивалентно вот этой вещи:
select user from user where 'user'='';
Ну, я думаю, для первого раза хватит. Если вдруг тебе мало, то можешь схватить небольшую подборку статей на эту тему у меня на сайте www.voy85.org. После того как переваришь всю полученную информацию, запомни, что базы данных используются в самых желанных местах для взломщиков - SQL встречается в музыкальных архивах, у провайдеров, в онлайн-магазинах, в банках... Дальше список продолжать? Базы данных - это всегда лакомый кусочек, который никто не прочь урвать.
И еще на будущее: об SQL injection слышали далеко не все админы, так что если найдешь таковую уязвимость на каком-нибудь более-менее крупном сайте, то не спеши устраивать акты вандализма на месте преступления. После всего напиши админу письмо с описанием того, как ты совершил взлом. Админы - они хоть иногда и свиньи, но все же они люди, и помощь им никогда не бывает лишней.
