День начался как и все остальные ничем не приметные дни. Придя на работу и выпив чашечку капучино от китайской кофе машины сел шерстить сайты. Вот напоровшись на одного из них, долго изучая исходный код наткнулся на разметку, характерную для широко известного WYSIWYG редактора — FCK. Кто хоть раз сталкивался с проблемами подобного рода редакторов наверняка хорошо его знают.
Собственно сам продукт ничем по себе не интересен и полезен только администраторам сайта, т.к. позволяет редактировать наглядно страницы на сайте. Но меня он заинтересовал с точки зрения — на сколько безопасно его внедрение в CMS, особенно в связи с тем что он обладает набором функционала по UPLOAD'у картинок на сайты.
И о чудо, разработчики CMS на ровном месте совершили сразу несколько критических ошибок, сразу предоставив доступ к выполнению исходного кода на сайте!
Итак, что они же натворили?
1. Установив продукт из коробки, настроив 2 значения в конфигурации они посчитали что продукт готов к использованию, абсолютно не обратив внимание на то что продукт идет с богатым комплектомдыр примеров. Так например был доступен скрипт закачки по весьма предсказуемому адресу /fckeditor/editor/filemanager/connectors/php/upload.php да еще к нему и тестилка прилагалась, идущая в стандартном комплекте
2. Скрипт есть — значит он работает! Делаем небольшую проверочку и вуаля — картинка оказывается на чужом хосте. Взлом? Вроде и нет, но уже на шаг ближе к цели. Пробуем закачать PHP и облом… скрипт ругается что это неразрешенный тип контента.
3. Начинаем гуглить и находим пару статеек про то, как можно воспользоваться уязвимостью… Первый пост косвенно подталкивает нас к идеи закачать файл .htaccess с правилами обработки например .gif файлов как php5. Пробуем — опа… опять неудача — опять неразрешенный тип контента. Идем за кофе чтоб думать дальше
4. Бегло замечаем статейку про то что якобы был какой то баг в FCKEditor'е позволяющий закачать файл в произвольную директорию. Начинаем копать и находим еще несколько статей, сводящихся к тому, что если закачать файл с расширением php.txt и в качестве Source директории указать директорию с нуль-байтом на конце, то это вызовет внутреннею диарею функции проверки, за счет чего она съест расширение. Собираем на коленках и о чудо — оно на самом деле так!
В итоге — профит! Мы без проблем можем закачивать .php файлы на хост и выполнять их! Уязвимость? Скорее Дыра!
Разумеется я умышленно не привожу сюда список сайтов и название уязвимой CMS. Как аргумент скажу что она весьма популярна в узких кругах. Как факт — множество сайтов на данной CMS оказались дырявыми. Многим из них я отправил письма с информацией об уязвимости, но как показывает практика — хорошо если хотя бы 10 процентов прочитают и один процент озаботится данной проблемой.
Так о чем это я — Никогда, Никогда и еще раз никогда не ставьте дистрибутив компоненты не изучив его на наличие «блох». Закачивая какие либо данные позаботьтесь о том, чтоб они шли в директорию, в которой веб сервер не будет выполнять их (в апаче отключается в .htaccess). Именно эта компонента в дальнейшем может служить для злоумышленника парадной дверью.
В целях само пиара обращаю внимание что есть прототип стандарта, разработанный при участии уважаемых коллег с Хабра (https://docs.google.com/document/d/1sbDhyX8Reu8vgEHzhyltXH6dQYzG4lQV7Lmw2ryjsX0/edit ), который призывает защитить от подобного рода оплошностей программистов. Но наши реали таковы что пока гром не грянет — картошка не прорастет :)
Собственно сам продукт ничем по себе не интересен и полезен только администраторам сайта, т.к. позволяет редактировать наглядно страницы на сайте. Но меня он заинтересовал с точки зрения — на сколько безопасно его внедрение в CMS, особенно в связи с тем что он обладает набором функционала по UPLOAD'у картинок на сайты.
И о чудо, разработчики CMS на ровном месте совершили сразу несколько критических ошибок, сразу предоставив доступ к выполнению исходного кода на сайте!
Итак, что они же натворили?
1. Установив продукт из коробки, настроив 2 значения в конфигурации они посчитали что продукт готов к использованию, абсолютно не обратив внимание на то что продукт идет с богатым комплектом
2. Скрипт есть — значит он работает! Делаем небольшую проверочку и вуаля — картинка оказывается на чужом хосте. Взлом? Вроде и нет, но уже на шаг ближе к цели. Пробуем закачать PHP и облом… скрипт ругается что это неразрешенный тип контента.
3. Начинаем гуглить и находим пару статеек про то, как можно воспользоваться уязвимостью… Первый пост косвенно подталкивает нас к идеи закачать файл .htaccess с правилами обработки например .gif файлов как php5. Пробуем — опа… опять неудача — опять неразрешенный тип контента. Идем за кофе чтоб думать дальше
4. Бегло замечаем статейку про то что якобы был какой то баг в FCKEditor'е позволяющий закачать файл в произвольную директорию. Начинаем копать и находим еще несколько статей, сводящихся к тому, что если закачать файл с расширением php.txt и в качестве Source директории указать директорию с нуль-байтом на конце, то это вызовет внутреннею диарею функции проверки, за счет чего она съест расширение. Собираем на коленках и о чудо — оно на самом деле так!
В итоге — профит! Мы без проблем можем закачивать .php файлы на хост и выполнять их! Уязвимость? Скорее Дыра!
Разумеется я умышленно не привожу сюда список сайтов и название уязвимой CMS. Как аргумент скажу что она весьма популярна в узких кругах. Как факт — множество сайтов на данной CMS оказались дырявыми. Многим из них я отправил письма с информацией об уязвимости, но как показывает практика — хорошо если хотя бы 10 процентов прочитают и один процент озаботится данной проблемой.
Так о чем это я — Никогда, Никогда и еще раз никогда не ставьте дистрибутив компоненты не изучив его на наличие «блох». Закачивая какие либо данные позаботьтесь о том, чтоб они шли в директорию, в которой веб сервер не будет выполнять их (в апаче отключается в .htaccess). Именно эта компонента в дальнейшем может служить для злоумышленника парадной дверью.
В целях само пиара обращаю внимание что есть прототип стандарта, разработанный при участии уважаемых коллег с Хабра (https://docs.google.com/document/d/1sbDhyX8Reu8vgEHzhyltXH6dQYzG4lQV7Lmw2ryjsX0/edit ), который призывает защитить от подобного рода оплошностей программистов. Но наши реали таковы что пока гром не грянет — картошка не прорастет :)