![]() |
Несколько методов защиты Web-ресурсов
Несколько методов защиты ресурсов базирующихся на популярных движках. Автор: kuzya, 22/07/2007, www.inattack.ru [INTRO] Здравствуйте. Плавно с темы взлома я решил перейти на тему защиты. Наверняка у каждого второго читателя есть свой собственный сайт, и так же, у каждого второго, сайт не самописный, а базируется на каком ни будь популярном движке. C форумами же дела обстоят намного хуже. Я сильно сомневаюсь в том что хотя бы 5% читателей могут, просто могут, написать свой форум, для своего сайта. Конечно же намного проще скачать phpBB, IPB или любой другой форумный движок. Единственное неудобство – каждый день надо следить за багтраками что бы быть в курсе самых последних уязвимостей используемого Вами продукта, и во время ставить патчи, предотвратив тем самым взлом ресурса. Но тут может получиться небольшая развилка. Возьмём к примеру форум Invision Power Board (далее IPB). Этот продукт платный, а как известно – у нас в стране правит пиратство. Чем то это и может быть хорошо но сразу после сообщения об уязвимости врятли можно достать патч не являясь легальным покупателем IPB.1. Когда уязвимость обнаружена Получается что у пользователя есть 2 выхода: а)самому пропатчить форум. б)Облазить интернет в поисках патча, либо совета по способу закрытия дыры. Лучше всего, конечно же, первый вариант, так как он надёжнее, но тоже не всегда. Хорошо бы если уязвимость SQL-иньекция и Вы точно знаете какие именно и куда должны поступать данные. Для устранения дыры Вам просто нужно прогнать опасную переменную через функцию intval() или addslashes(). А если уязвимость связана с выполнением произвольного php-кода? Например через функцию preg_replace(). Далеко не каждый может просто понять что нужно фильтровать, к тому же после ручного исправления форум может начать работать не так как раньше, выплёвывая море ошибок. Вообщем картина удручающая. Даже если взять phpBB который полностью бесплатен. Кто Вам гарантирует то что Вы узнаете об уязвимости первее чем человек который зол на Вас? Представим следующую ситуацию: Вы ложитесь вечером спать, в 3 утра находят уязвимость, в 4 атакующий полностью разобрался с эксплойтом и задефейсил Ваш сайт. В 10 Вы встаёте, в 10.30 узнаёте о уязвимости, бежите за патчем, а форум уже взломан. Согласитесь - такая ситуация может быть с каждым и никто от этого не застрахован. Ниже я попытаюсь обьяснить как же всётаки защитить свой ресурс от неизвестных атак, а объяснять я буду на примере форумов IPB и phpBB. В принципе описанные методы подходят не только к форумам, но и почти к любому веб-приложению, будь то лента новостей или CMS. Так же хочу обратить Ваше внимание на следующее: ниже описан пример безопасного расставления прав для файлов форума/сайта, но прежде чем поставить такие права у себя на ресурсе проверьте совпадают ли условия описанные мной с Вашими. 2. Правильная расстановка прав Если Вы занимаетесь взломом то наверняка знаете что для дефейса сайта можно получить каким-либо образом выполнение команд(например вызвав функцию system() через уязвимость) и просто выполнить командуPHP код:
1.Запретить запись в любые файлы и директорию форума вообще всем. 2.Запретить чтение пользователям из Вашей группы (на хостингах чаще всего пользователей объединяют в одну группу). 3.Разрешить чтение всем другим пользователям. Звучит глупо но пользователя под которым работает веб-сервер чаще всего держат одного в отдельной группе. К тому же на хороших хостингах все пользователи делятся на 2 основные группы: администраторы и пользователи хостинга, а mysql, apache и другие программы стартуют от своего пользователя у которого своя группа. Так как PHP действует с правами веб-сервера (соответственно от имени его пользователя) то для стабильной работы сайта он должен прочитать все php-файлы чтобы сайт нормально работал. Следовательно запретив чтение файла другим пользователям Вы блокируйте работу сайта. Исходя из этого есть администраторы, пользователи хостинга, и программы, имеющие своих пользователей и группы, которых боятся не стоит. Получается что права для Вас, как для владельца файла должны быть 7 (исполнение, чтение, запись), для группы – 0 (запрещено всё), для остальных пользователей 4 (чтение) и выполнение (1). Исходя из этого, что бы установить такие права на папку форума нужно выйти в корень сайта и выполнить команду: PHP код:
и здесь: http://www.linuxcenter.ru/lib/books/slackbook/use_2.phtml 3. Сокрытие реальных конфигурационных данных. Если атакующий не сможет провести дефейс то скорее всего он полезет к базе (если с самого начала этого не сделал). То есть его главной целью становиться config.php или conf_global.php . Читать данные из этих файлов взломщик может спокойно. Соответственно атакующий, имея данные для подключения к базе, может попытаться подключиться удалённо, либо выполнить php-код который подключиться к базе и возьмёт пароли всех пользователей. А что если данные для подключения к БД спрятать совершенно в другом месте? Давайте перепрячем их.phpBB2 Наc интересует db.php (он лежит в папке includes). Найдите строку PHP код:
PHP код:
PHP код:
В IPB Вам надо всего лиш подредактировать файл ips_krenel/class_db_mysql.php В нём есть функция connet (строка 91) где нужно прописать данные для подключения к БД, пример: PHP код:
4. Защита от неизвестных SQL-injection. Давайте посмотрим как работают эксплойты для получения хэша пароля через SQL-иньекцию. Самое первое что они делают – получают префикс. Без префикса никуда, ведь что бы взять что то из таблицы надо знать её полное название.Invision Power Board. Для эксперимента я взял IPB 2.1.4 и эксплоит для IPB 2.1.6 от RST/CGH. Я запустил эксплоит и достал member_login_key администраторского пользователя: http://www.inattack.ru/images/art/11...p_image002.jpg (слева результат эксплойта, справа – вырезка из phpMyAdmin) Значения совпадают, эксплоит работает нормально. Теперь, давайте разберёмся как эксплойты получают префикс таблиц. Они просто вызываются ошибочный запрос и появляется ошибка, из текста которой они отфильтровывают префикс: http://www.inattack.ru/images/art/11...ge002_0000.jpg Для вывода ошибки я открыл index.php и добавил кавычку в строки 182-185: PHP код:
Вы можете сделать как вам заблагорассудится. А можете вообще ничего не делать так как ниже всё описано со скрин-шотами. Как видно из ошибки – префикс ibf_ . В IPB За показ ошибки отвечает функция fatal_error() находящаяся в скрипте class_db.php. Давайте рассмотрим её код: PHP код:
PHP код:
Давайте чуть-чуть изменим скрипт и перед строками: PHP код:
$the_error = '' ''; Получится следующий код: PHP код:
http://www.inattack.ru/images/art/11...p_image004.jpg Как видите – самого запроса, как и префикса, здесь нет. Теперь попробуем запустить эксплоит: http://www.inattack.ru/images/art/11...p_image006.jpg Эксплоит не получил префикс таблиц, следовательно он не рабочий! Даже если форум не пропатчен то атакующий ничего не получит. Но можно пойти другим путём – в тексте ошибочного запроса заменить настоящий префикс на поддельный. У меня был префикс ibf_. Для того что бы осуществить нашу задумку нам нужно сделать следующее – определить какой у нас префикс и в переменной $the_error просто заменить его на поддельный. Вот код который это сделает: PHP код:
PHP код:
http://www.inattack.ru/images/art/11...p_image008.jpg Наш префикс – fuck_! Что же нам скажет эксплоит? Получение префикса: http://www.inattack.ru/images/art/11...p_image010.jpg Получение данных: http://www.inattack.ru/images/art/11...p_image012.jpg Как видите – всё получилось! phpBB. Теперь тоже самое проделаем с phpBB. Для вызова ошибки я перешёл на строку 113 в файле index.php и изменил код на следующий: PHP код:
http://www.inattack.ru/images/art/11...p_image014.jpg Префикс в ней есть. Теперь посмотрим какой код генерирует эту ошибку: далеко ходить не надо(строка 119): PHP код:
PHP код:
PHP код:
PHP код:
Для того что бы подменить префикс можно опять же использовать str_replace(): PHP код:
http://www.inattack.ru/images/art/11...p_image018.jpg Всё прошло успешно. 5. Заключение. Вот такими не сложными методами Вы можете защитить свой сайт от множества атак. Единственные атаки которые смогут пройти нормально – DoS через SQL-иньекцию. Но мне кажется что лучше уж DoS с последующим исправлением дыры, чем дефейс или кража паролей. Помните что такими методами Вы сможете защитить практически любой проект, просто изменяя тексты ошибок или правильно расставляя права. А те люди, которым хостинг предоставляется с отдельным файлом php.ini вообще могут занести system() и подобные ей функции в категорию запрещённых. И никаким эксплойтом через форум командную строку не получишь. Так же не оставляйте префиксы таблиц по умолчанию, меняйте на что ни будь типа 'er24g34' что бы даже в ручную подобрать было практически невозможно. Удачи.22/07/2007 ----------------------------------- Автор: kuzya, www.inattack.ru PS Я думаю статья будет интересна, как тем, кто ставит себе эти борды, так и тем, кто их пытается ломать ;) |
Просто писец... Короче метод защиты называется испорти своё двигло... Может тогда просто снять все права с каталога в котором находится пага? Многие движки используют кеширование, запись сессий в файлы, аплоад файлов (что предусматрвает наличие прав на запись)... Если начать налево и направо запрещать запись скрипту, то двигло просто рухнет! Это не выход! Это вредительство! Насчёт подмены данных доступа к базе в конфиге - это вообще умора... Такой движок потом не удастся проапдейтить стандартными скриптами, при установке каких-то модулей, если они требуют доступа к базе, в них тоже нужно вносить соответствующие изменения... Короче полезность статьи под вопросом... Ушатывание движка это не метод защиты от веб-атак... Отключите на системном уровне все сообщения об ошибках, отключите в форумах вывод ошибок! В чём сложность? Если у человека прямые руки и в голове что-то есть, то он найдёт способ закрытия дыры, а не будет херачить движок...
|
| Время: 00:58 |