Defaced by… или немного о взломе сайтов
Идет время, и общество становится виртуальным. Как понимать? В прямом смысле. Службы обмена мгновенными сообщениями, социальные сети, форумы, чаты, блогерство, файлообменные сети, электронные журналы и интернет-магазины – зачем вообще выходить из квартиры/дома? :) Звучит немного диковато, но факт. Недавно запустил свой pidgin и обнаружил у друга статус "В тюрьме столько не сидят, сколько мы в Интернете", и это прямо в точку, скажу я вам. К чему я это веду? А к тому, что свой сайт есть даже у моей собаки. Все, кому не лень, создают блоги, при этом как на бесплатных сервисах, так и тратят денежки на платные хостинги и красивые домены. Стоит вспомнить бум социальных сетей, в которые хлынула вся общественность в последний год-два. Гостевой доступ от уже ставшего народным провайдера РУП "Белтелеком" (кто не в курсе подробностей – торговая марка ByFly) обрастает разного рода ресурсами с такой скоростью, что не успеваешь следить.
Все дело в том, что купить хостинг, доменное имя, залить на сервер движок, повесить скин – не значит стать веб-мастером. Именно такие администраторы и забывают про безопасность как таковую. Большинство просто считают, что хостер за них позаботится о защите их сайта. Однак, реальность далека от таких вот мыслей. Администратор сайта – человек, на котором в первую очередь висит задача "защитить".
В общем, сегодня я хотел бы пробежаться по двум способам взлома, которые наиболее часто встречаются. Дать немного советов по увеличению уровня защищенности информации на сервере, БД SQL и, собственно, скриптов. Как-то я писал в КГ про межсайтовый скриптинг (XSS), статья была достаточно полная, поэтому я не буду сегодня повторяться и опущу этот способ атаки. А расскажу я про аналитический способ, а также ошибку, которая достаточно часто имеет место при обработке запросов, направленных к БД SQL при авторизации пользователя. Давайте приступим.
Аналитика
Если смотреть внимательно, то практически ни один взлом сайта не обходится без аналитики, потому что так или иначе хакеру необходимо анализировать полученную информацию. Но я хочу описать ситуацию, когда есть сайт и о нем ничего неизвестно. Именно отсюда и начинается аналитический способ взлома.
Предположим, что перед глазами взломщика есть ресурс, который он видит в первый раз. О нем ничего неизвестно, а нужно его взломать. Страница ресурса сразу же прокручивается вниз, так как многие, отдавая дань используемому движку, оставляют надпись типа "Powered by …" или же "Сайт работает на …", и очень часто в такой строчке имеется версия движка. Вспомним достаточно популярный движок для форумов Invision Power Board, по дефолту в его функции <%COPY%> написана версия. Строка выглядит вот таким образом: "Форум IP.Board 2.3.6 2009 IPS, Inc.". Взломщик видит, что движок на форуме-жертве, пока потенциальной, версии 2.3.6, и его путь теперь прямиком лежит в багтрак, а точнее, в поиск по нему. Задача взломщика просмотреть все записи об уязвимостях, и если есть подходящий на эту версию баг, отвечающий задачам взломщика, то последний скачает эксплойт (или напишет его исходя из информации, изложенной в описании бага) и будет использовать.
Если же нет ничего подходящего, либо нет даже косвенно подходящего, то начинается анализ кода заглавной страницы, хотя и не обязательно заглавной, можно анализировать, коль уже мы заговорили про форум, страницу с ошибкой авторизации или чистую страницу авторизации.
Ниже я приведу пример формы, которая может дать кое-какую информацию:
<FORM NAME="authF" ACTION="/includes/login.php" METHOD="post">
<INPUT TYPE="text" NAME="username" VALUE="">
<INPUT TYPE="password" NAME="passwd" VALUE="">
<INPUT TYPE="submit" VALUE="Вход">
</FORM>
Из этого кода взломщик почерпнет следующую информацию: на сервере есть каталог includes, авторизация пользователя осуществляется при помощи скрипта login.php с использованием POST-запроса. Дальше, если нужна еще информация о каталогах на сервере, то есть резон обратиться к файлу robots.txt. Обычно значение этого файла, по мнению многих, сводится к корректировке действий поисковых spider'ов, однако если его просмотреть, то можно узнать много интересного:
User-Agent: *
Disallow: /wp-admin/
Disallow: /wp-includes/
Disallow: /wp-content/languages/
Отсюда можно понять, что движок – Wordpress и/или на сервере находятся каталоги wp-admin, wp-includes, wp-content, а также подкаталог languages, находящийся в каталоге wp-content.
Анализируя полученные данные, взломщик различными способами получает все больше и больше информации, пока не натыкается на то, что надо :). Этим "то, что надо" может служить, например, скрипт login.php, который выдает ошибку
Warning: Failed opening '/home/www/login.inc' for inclusion (include_path='') in /home/www/login.inc on line 21
Это говорит о том, что используется сценарий login.inc, а поскольку разрешение не php, а inc, то вполне возможно, что сервер выдаст его содержимое (если не отключен дебаг-режим у php на сервере). Просматривая выведенную информацию, можно найти много интересного, на что и надеется взломщик.
Кроме того, анализируя информацию о движке, можно попробовать открыть файл конфигурации. Если речь идет о IPB, то это conf_global, если о Wordpress – wp-config. В файлах подобного рода находится информация о базе данных, а именно логин, пароль, имя, хост, префикс таблиц и т.п. Вот вам и доступ к содержимому сайта. При этом, даже если взломщик и не знает, какие именно файлы необходимо искать, он может это понять, просматривая добытую информацию, которая будет включать список файлов движка, залитые на сервер.
Обращение к SQL Data Base
На рисунке показана схема работы простейшего интерфейса, который может использоваться для авторизации пользователя на ресурсе.
Запрос, отправляемый формой к базе данных, должен иметь логин и пароль пользователя. После совпадения контрольных сумм (не обязательно именно такой способ авторизации) база данных выдает информацию о запрашиваемом пользователе. Скрипт, в свою очередь, оформляет результаты в виде html и отправляет браузеру. Ниже я привожу фрагмент скрипта, в котором показано обращение к базе данных. Пример типичен и не имеет особенностей.
<?php
$result = mysql_db_query("database","select * from userTable where
login = '$userLogin' and password = '$userPassword' ");
while($row = mysql_fetch_array($result)) {
echo $row["fullname"];
echo $row["email"];
echo $row["password"];
}
mysql_free_result($result);
?>
Как видим, логин и пароль, введенные пользователем, содержатся в переменных $userLogin и $userPassword. Содержимое этих переменных вставляется в запрос для отфильтровки информации именно об этом пользователе. Фильтр задается с помощью опции where команды select SQL. В данном случае запрос выглядит таким образом: select * from userTable where login = '$userLogin' and password = '$userPassword', где userTable - имя таблицы, содержащей нужную информацию. Если переменные логина и пароля содержат значения vanya и vasya соответственно, то запрос, отсылаемый БД, примет такой вид: select * from userTable where login = 'vanya' and password = 'vasya'. Понятно, что если в базе данных отсутствует запись, в которой логин равен vanya, а пароль - vasya, то запрос не пришлет ни одной строчки из БД, и скрипт ничего не выдаст. Вот такой вот алгоритм исключает использование информации конкретного пользователя субъектом, не обладающим верным логином или паролем.
С первого взгляда алгоритм непробиваем, однако все не так безоблачно, как кажется. Логика программистов, создававших приведенный выше пример, подразумевает, что введенные пользователем логин и пароль будут содержаться внутри одинарных кавычек, которые жестко забиты в теле запроса. Однако на такое развитие событий можно рассчитывать только в том случае, когда на сайте орудует пользователь с одним только желанием – авторизоваться, а вот если сайт попал в поле зрения взломщика или хакера, то ситуация меняется. А если вставить еще одну кавычку, в не предназначенном для этого месте? Пусть он (логин/пароль) имеет значение vas'ya, тогда запрос примет вид: select * from userTable where login = 'vanya' and password = 'vas'ya'. В такой ситуации возникнет ошибка. Все очень просто, кавычка в средине пароля закрыла первую в запросе, и окончание пароля – ya' так и осталось висеть вне запроса.
А если вставить в качестве пароля такую строку: ' or 1=1 ', то запрос станет таким: : select * from userTable where login = 'vanya' and password = '' or 1=1 '' и не будет содержать синтаксических ошибок. Зато логическое выражение станет тождественно истинным, и в ответ на этот запрос SQL выдаст всю базу данных пользователей =).
Таким образом, используя символ апострофа, можно проникнуть в тело SQL запроса и сделать так, чтобы проверяемое условие было истинным. Если взломщика интересует конкретный пользователь vanya, то для получения информации о нем можно воспользоваться такой строкой пароля: ' or login = 'vanya. При этом запрос станет таким: select * from userTable where login = 'vanya' and password = '' or login = 'vanya'. Как вы понимаете, в результате взломщик получит информацию именно о vanya.
Описанная уязвимость сервисов, основанных на SQL, не ограничивается несанкционированным получением информации. Поскольку в таких системах используется, как правило, MySQL, то имеется возможность не только модифицировать условное выражение в команде select, но и выйти за пределы этой команды, и выполнить другую команду БД. Поскольку в MySQL допускается несколько команд в одном запросе, разделенных ;, то мы можем выполнить любую из этих команд, введя в поле пароля следующий код: ' ; <командаSQL> где в качестве <командаSQL> можно указать любую допустимую команду. Так, например, такой код: ' ; drop table 'userTable просто напросто уничтожит таблицу userTable из базы данных.
Заключение
Не так давно по Сети прокатилась волна взломов, которые были реализованы на необычайно низком уровне. Конечно, о поиске уязвимостей и речи тут быть не может. Недавний всплеск был обусловлен исключительно халатным отношением администраторов к своим детищам. Под этим я подразумеваю использование паролей на фтп и cms типа '123' или 'qwerty'. Банально, однако это имело место. Не скупитесь на сложные пароли, используйте символы и чередование регистров – это аукнется тем, что дефейса вашего сайта не будет. А еще, как я уже говорил выше, просмотрите разрешения для файлов и папок на вашем сервере. Полный доступ (т.е. 777) может быть выставлен исключительно на папку для загрузок (например, upload), иначе на сайте хозяином будет кто угодно, только не вы сами.
В материале я рассмотрел принципы некоторых атак, об особенностях их реализации писать не стал – во-первых, объем статьи получился бы великоват, а во-вторых – сегодня же вечером статья проверялась бы на "правдивость" каким-нибудь ребенком-хакером :). Предоставленного материала более чем достаточно для того, чтобы понять алгоритм и прикрыть все норки. На этом – все, желаю удачи в развитии вашего ресурса и грамотных идей по оптимизации/продвижению. E-mail для ваших вопросов – q@sa-sec.org
P.S. Вся информация, представленная в статье, носит исключительно ознакомительный характер и предназначена во имя добра. :) Автор не несет ответственности за возможное использование статьи в противозаконных целях.
Евгений Кучук SASecurity gr.
Все дело в том, что купить хостинг, доменное имя, залить на сервер движок, повесить скин – не значит стать веб-мастером. Именно такие администраторы и забывают про безопасность как таковую. Большинство просто считают, что хостер за них позаботится о защите их сайта. Однак, реальность далека от таких вот мыслей. Администратор сайта – человек, на котором в первую очередь висит задача "защитить".
В общем, сегодня я хотел бы пробежаться по двум способам взлома, которые наиболее часто встречаются. Дать немного советов по увеличению уровня защищенности информации на сервере, БД SQL и, собственно, скриптов. Как-то я писал в КГ про межсайтовый скриптинг (XSS), статья была достаточно полная, поэтому я не буду сегодня повторяться и опущу этот способ атаки. А расскажу я про аналитический способ, а также ошибку, которая достаточно часто имеет место при обработке запросов, направленных к БД SQL при авторизации пользователя. Давайте приступим.
Аналитика
Если смотреть внимательно, то практически ни один взлом сайта не обходится без аналитики, потому что так или иначе хакеру необходимо анализировать полученную информацию. Но я хочу описать ситуацию, когда есть сайт и о нем ничего неизвестно. Именно отсюда и начинается аналитический способ взлома.
Предположим, что перед глазами взломщика есть ресурс, который он видит в первый раз. О нем ничего неизвестно, а нужно его взломать. Страница ресурса сразу же прокручивается вниз, так как многие, отдавая дань используемому движку, оставляют надпись типа "Powered by …" или же "Сайт работает на …", и очень часто в такой строчке имеется версия движка. Вспомним достаточно популярный движок для форумов Invision Power Board, по дефолту в его функции <%COPY%> написана версия. Строка выглядит вот таким образом: "Форум IP.Board 2.3.6 2009 IPS, Inc.". Взломщик видит, что движок на форуме-жертве, пока потенциальной, версии 2.3.6, и его путь теперь прямиком лежит в багтрак, а точнее, в поиск по нему. Задача взломщика просмотреть все записи об уязвимостях, и если есть подходящий на эту версию баг, отвечающий задачам взломщика, то последний скачает эксплойт (или напишет его исходя из информации, изложенной в описании бага) и будет использовать.
Если же нет ничего подходящего, либо нет даже косвенно подходящего, то начинается анализ кода заглавной страницы, хотя и не обязательно заглавной, можно анализировать, коль уже мы заговорили про форум, страницу с ошибкой авторизации или чистую страницу авторизации.
Ниже я приведу пример формы, которая может дать кое-какую информацию:
<FORM NAME="authF" ACTION="/includes/login.php" METHOD="post">
<INPUT TYPE="text" NAME="username" VALUE="">
<INPUT TYPE="password" NAME="passwd" VALUE="">
<INPUT TYPE="submit" VALUE="Вход">
</FORM>
Из этого кода взломщик почерпнет следующую информацию: на сервере есть каталог includes, авторизация пользователя осуществляется при помощи скрипта login.php с использованием POST-запроса. Дальше, если нужна еще информация о каталогах на сервере, то есть резон обратиться к файлу robots.txt. Обычно значение этого файла, по мнению многих, сводится к корректировке действий поисковых spider'ов, однако если его просмотреть, то можно узнать много интересного:
User-Agent: *
Disallow: /wp-admin/
Disallow: /wp-includes/
Disallow: /wp-content/languages/
Отсюда можно понять, что движок – Wordpress и/или на сервере находятся каталоги wp-admin, wp-includes, wp-content, а также подкаталог languages, находящийся в каталоге wp-content.
Анализируя полученные данные, взломщик различными способами получает все больше и больше информации, пока не натыкается на то, что надо :). Этим "то, что надо" может служить, например, скрипт login.php, который выдает ошибку
Warning: Failed opening '/home/www/login.inc' for inclusion (include_path='') in /home/www/login.inc on line 21
Это говорит о том, что используется сценарий login.inc, а поскольку разрешение не php, а inc, то вполне возможно, что сервер выдаст его содержимое (если не отключен дебаг-режим у php на сервере). Просматривая выведенную информацию, можно найти много интересного, на что и надеется взломщик.
Кроме того, анализируя информацию о движке, можно попробовать открыть файл конфигурации. Если речь идет о IPB, то это conf_global, если о Wordpress – wp-config. В файлах подобного рода находится информация о базе данных, а именно логин, пароль, имя, хост, префикс таблиц и т.п. Вот вам и доступ к содержимому сайта. При этом, даже если взломщик и не знает, какие именно файлы необходимо искать, он может это понять, просматривая добытую информацию, которая будет включать список файлов движка, залитые на сервер.
Обращение к SQL Data Base
Запрос, отправляемый формой к базе данных, должен иметь логин и пароль пользователя. После совпадения контрольных сумм (не обязательно именно такой способ авторизации) база данных выдает информацию о запрашиваемом пользователе. Скрипт, в свою очередь, оформляет результаты в виде html и отправляет браузеру. Ниже я привожу фрагмент скрипта, в котором показано обращение к базе данных. Пример типичен и не имеет особенностей.
<?php
$result = mysql_db_query("database","select * from userTable where
login = '$userLogin' and password = '$userPassword' ");
while($row = mysql_fetch_array($result)) {
echo $row["fullname"];
echo $row["email"];
echo $row["password"];
}
mysql_free_result($result);
?>
Как видим, логин и пароль, введенные пользователем, содержатся в переменных $userLogin и $userPassword. Содержимое этих переменных вставляется в запрос для отфильтровки информации именно об этом пользователе. Фильтр задается с помощью опции where команды select SQL. В данном случае запрос выглядит таким образом: select * from userTable where login = '$userLogin' and password = '$userPassword', где userTable - имя таблицы, содержащей нужную информацию. Если переменные логина и пароля содержат значения vanya и vasya соответственно, то запрос, отсылаемый БД, примет такой вид: select * from userTable where login = 'vanya' and password = 'vasya'. Понятно, что если в базе данных отсутствует запись, в которой логин равен vanya, а пароль - vasya, то запрос не пришлет ни одной строчки из БД, и скрипт ничего не выдаст. Вот такой вот алгоритм исключает использование информации конкретного пользователя субъектом, не обладающим верным логином или паролем.
С первого взгляда алгоритм непробиваем, однако все не так безоблачно, как кажется. Логика программистов, создававших приведенный выше пример, подразумевает, что введенные пользователем логин и пароль будут содержаться внутри одинарных кавычек, которые жестко забиты в теле запроса. Однако на такое развитие событий можно рассчитывать только в том случае, когда на сайте орудует пользователь с одним только желанием – авторизоваться, а вот если сайт попал в поле зрения взломщика или хакера, то ситуация меняется. А если вставить еще одну кавычку, в не предназначенном для этого месте? Пусть он (логин/пароль) имеет значение vas'ya, тогда запрос примет вид: select * from userTable where login = 'vanya' and password = 'vas'ya'. В такой ситуации возникнет ошибка. Все очень просто, кавычка в средине пароля закрыла первую в запросе, и окончание пароля – ya' так и осталось висеть вне запроса.
А если вставить в качестве пароля такую строку: ' or 1=1 ', то запрос станет таким: : select * from userTable where login = 'vanya' and password = '' or 1=1 '' и не будет содержать синтаксических ошибок. Зато логическое выражение станет тождественно истинным, и в ответ на этот запрос SQL выдаст всю базу данных пользователей =).
Таким образом, используя символ апострофа, можно проникнуть в тело SQL запроса и сделать так, чтобы проверяемое условие было истинным. Если взломщика интересует конкретный пользователь vanya, то для получения информации о нем можно воспользоваться такой строкой пароля: ' or login = 'vanya. При этом запрос станет таким: select * from userTable where login = 'vanya' and password = '' or login = 'vanya'. Как вы понимаете, в результате взломщик получит информацию именно о vanya.
Описанная уязвимость сервисов, основанных на SQL, не ограничивается несанкционированным получением информации. Поскольку в таких системах используется, как правило, MySQL, то имеется возможность не только модифицировать условное выражение в команде select, но и выйти за пределы этой команды, и выполнить другую команду БД. Поскольку в MySQL допускается несколько команд в одном запросе, разделенных ;, то мы можем выполнить любую из этих команд, введя в поле пароля следующий код: ' ; <командаSQL> где в качестве <командаSQL> можно указать любую допустимую команду. Так, например, такой код: ' ; drop table 'userTable просто напросто уничтожит таблицу userTable из базы данных.
Заключение
Не так давно по Сети прокатилась волна взломов, которые были реализованы на необычайно низком уровне. Конечно, о поиске уязвимостей и речи тут быть не может. Недавний всплеск был обусловлен исключительно халатным отношением администраторов к своим детищам. Под этим я подразумеваю использование паролей на фтп и cms типа '123' или 'qwerty'. Банально, однако это имело место. Не скупитесь на сложные пароли, используйте символы и чередование регистров – это аукнется тем, что дефейса вашего сайта не будет. А еще, как я уже говорил выше, просмотрите разрешения для файлов и папок на вашем сервере. Полный доступ (т.е. 777) может быть выставлен исключительно на папку для загрузок (например, upload), иначе на сайте хозяином будет кто угодно, только не вы сами.
В материале я рассмотрел принципы некоторых атак, об особенностях их реализации писать не стал – во-первых, объем статьи получился бы великоват, а во-вторых – сегодня же вечером статья проверялась бы на "правдивость" каким-нибудь ребенком-хакером :). Предоставленного материала более чем достаточно для того, чтобы понять алгоритм и прикрыть все норки. На этом – все, желаю удачи в развитии вашего ресурса и грамотных идей по оптимизации/продвижению. E-mail для ваших вопросов – q@sa-sec.org
P.S. Вся информация, представленная в статье, носит исключительно ознакомительный характер и предназначена во имя добра. :) Автор не несет ответственности за возможное использование статьи в противозаконных целях.
Евгений Кучук SASecurity gr.
Компьютерная газета. Статья была опубликована в номере 17 за 2009 год в рубрике безопасность
