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

Просто с бесконечным множеством CMS систем, платных, бесплатных или же самописных, по сети распространилось и бесконечное множество всевозможных дыр и уязвимостей. Если еще десятилетия тому назад, в эру HTML, приходилось искать уязвимость непосредственно в HTTP-сервере, то теперь благодаря неудачливым программистам или "слабым" системным администраторам процесс упростился донельзя.

Я не буду описывать методику взлома абстрактных интернет-ресурсов, так как смысла в этом не вижу. На примере нескольких сайтов я расскажу, как выглядят типовые ошибки программистов и чем они могут обернуться.

Самописный интернет-магазин

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

Дабы ознакомиться с тем, чем торгует фирма, я решил узнать адрес сайта. Заполучив заветную ссылку, гуляя по страницам с товарами, я заметил одну ошибку, закравшуюся в скрипт отображения миниатюр картинок. Она сильно смутила меня. Дело в том, что ошибка довольно распространенная, и выглядит она как script.php?file=file, где script.php - файл скрипта в строке адреса, а file - собственно файл для просмотра на сервере.

Ради интереса в адресной строке, я набрал следующее script.php?file=index.php (это значит, что я попросил скрипт просмотреть файл index.php - заглавную страницу сайта). В обычной ситуации такой скрипт должен проверять расширение запрашиваемого файла и не давать возможности пользователю ресурса создавать подобные запросы для php. Но штатный программист в той компании не знал об этой особенности, и оставил эту уязвимость доступной.

Далее все проходило быстро. Узнав, что компания использует Vbulletin в качестве движка форума, я скачал сходную версию, чтобы узнать пути к файлам конфигурации. Затем написал запрос в адресной строке браузера script.php?file=/forum/includes/config.php и, увидев сообщение с ошибками, открыл исходный код страницы в Opera, получив файл конфигурации форума.

Что это означало? У меня были развязаны руки. Можно было закачать, например, phpshell - файловый менеджер, написанный на PHP, и полностью получить доступ ко всему серверу. Но задача человека состоит не в разрушении, а в созидании. Поэтому я опубликовал в форуме новость от имени администрации с просьбой связаться со мной для устранения ошибки.

Я написал длинное письмо о том, что необходимо исправить. Дело в том, что на том CMS-движке базировался не один сайт, а не менее десяти в разных регионах Украины. И если бы данную ошибку обнаружил какой-нибудь "ошпаренный" товарищ, то последствия для имиджа фирмы и ее клиентов могли быть неизгладимо печальными.

Бесплатная галерея

Существует очень хороший сайт, посвященный старым фотографиям городов. Но беда этого ресурса была в том, что его администратор не смог сконфигурировать бесплатный скрипт галереи 4gallery правильно. А это значило, что бэкапы SQL хранились в стандартном каталоге backup, доступном к просмотру через банальный листинг директорий. Что это значило? А это означало то, что имея дамп базы данных, я мог спокойно войти под учетной записью администратора.

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

К сожалению, автор сайта не использовал пароль должной сложности, и поэтому подобрать пароль по словарю MD5 оказалось просто. Войдя на сайт от лица администратора, я написал на титульной странице об уязвимости и о том, как со мной связаться, чтобы ее устранить.

Подводя итоги

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

К сожалению, формат статьи "Компьютерных Вестей", не позволяет мне рассмотреть наиболее типовые ошибки, возникающие в ходе настройки http-серверов и CMS. Но, для размышления подброшу читателям вот такую вот ссылку: www.exploit-db.com. Задумайтесь, возможно, эксплойт на вашу CMS уже опубликован там.

Роман КАРПАЧ,
консультант по проблемам ИТ,
www.fdd5-25.net