Серьёзная уязвимость в osCommerce 2.2 RC 2a
Возможность выполнения произвольного PHP-кода с правами web-сервера
Сегодня один из моих клиентов пожаловался, что его online-магазин (на базе osCommerce) в очередной раз взломали и записали закодированный файл q_boot.php в каталог images. Хотя с osCommerce я сталкивался только один раз в жизни (подчищал вирус наподобие этого), меня этот случай очень заинтересовал: уязвимость, которая позволяет злоумышленнику залить на сервер произвольный файл — это очень серьёзно.
Естественно, что от техподдержки клиента я не смог получить лог доступа к сайту (взломали неделю назад), чтобы посмотреть, с каких IP-адресов обращались к этому images/q_boot.php и проследить историю запросов. Это было бы слишком легко. Пришлось копаться в коде панели администрирования.
В частности, один из скриптов, который позволяет загружать файлы — это admin/banner_manager.php. Я начал с него, стал анализировать все включаемые файлы. Дыра нашлась за три минуты.
В admin/includes/application_top.php есть такой вот уязвимый код:
- // redirect to login page if administrator is not yet logged in
- if (!tep_session_is_registered('admin')) {
- $redirect = false;
- $current_page = basename($PHP_SELF);
- if ($current_page != FILENAME_LOGIN) {
- if (!tep_session_is_registered('redirect_origin')) {
- tep_session_register('redirect_origin');
- $redirect_origin = array('page' => $current_page,
- 'get' => $HTTP_GET_VARS);
- }
- $redirect = true;
- }
- if ($redirect == true) {
- tep_redirect(tep_href_link(FILENAME_LOGIN));
- }
- unset($redirect);
- }
Уязвимость не очевидна, если не знать разницу между $_SERVER['SCRIPT_NAME'], $_SERVER['SCRIPT_FILENAME'] и $_SERVER['PHP_SELF'].
В частности, PHP_SELF содержит
The filename of the currently executing script, relative to the document root. For instance,$_SERVER['PHP_SELF']in a script at the addresshttp://example.com/test.php/foo.barwould be/test.php/foo.bar.
Константа FILENAME_LOGIN определена как login.php.
Таким образом, обращение к /admin/banner_manager.php/login.php приведёт к тому, что в $_SERVER['PHP_SELF'] будет /admin/banner_manager.php/login.php, исполняться будет /admin/banner_manager.php, а basename($_SERVER['PHP_SELF']) будет — правильно, login.php. Условие в строке 138 не выполнится, и злоумышленник благополучно минует авторизацию.
Теперь эксплуатация уязвимости в картинках (изображения можно и нужно кликать):
Первый скриншот демонстрирует возможность обхода авторизации и получения доступа к скриптам панели администрирования.
Второй скриншот демонстрирует изменение URL’а формы (при помощи FireBug) и загрузку PHP-файла.
На третьем скриншоте мы видим, что файл был успешно загружен (хотя мы и были перенаправлены на форму авторизации). А ведь все пользовательские данные нужно тщательно проверять!
На четвёртом скриншоте мы видим, что загруженный PHP-файл можно успешно выполнить 
Что и требовалось показать
Теперь о том, как это всё исправить.
А исправляется всё очень просто: исправляем
на
А еще лучше — отказываемся от osCommerce в пользу чего-нибудь нормального, так как эта уязвимость — не единственная.
К слову, текущая Alpha osCommerce 3 тоже уязвима, только по-другому… Делайте выводы.
Связанные записи
Автор: Vladimir; опубликовано в: Безопасность; метки: osCommerce, взлом, уязвимостьДек
2009
Меня зовут Владимир, я программист-фрилансер, специализирующийся на Web-программировании и програмировании под Linux.
По совместительству занимаюсь администрированием LAMP/LNMP-серверов и техническим переводом.
Подобный баг нашли в ZenCart 1.3.8, который как раз является форком osCommerce. Проверил osCommerce 2.2 Milestone 2, в ней уязвимости нет. А вообще это просто ужас, что сейчас будет. Вам бы следовало сообщить разработчикам, прежде, чем выкладывать такие вещи. Благо некоторые админы закрывают доступ к папке admin через .htaccess и запрещают выполнение скриптов в images.
Разработчики знают. А уязвимость уже очень активно эксплуатируется (по моим прикидкам, как минимум с начала ноября), а исправлять никто не торопится, хотя делов на пять минут
В последней альфе osCommerce 3 уязвимость тоже существует, но через XML RPC.
Уязвимость присутствует во всех версиях osCommerce, находящихся по ссылке на официальном сайте: http://www.oscommerce.com/about/news,129
PS — а еще её спамеры эксплуатируют
Действительно часто папку с картинками закрывают через .htaccess
но в данном случае проще не залить php скрипт , а завести нового администратора
может действительно стоило сначала разработчикам отписать, перед тем как выкладывать в паблик данную уязвимость
Отписал я разработчикам. Еще неделю назад. Дата публикации статьи и дата написания очень отличаются
Вообще на том сервере, где я закрывал дырку, эта уязвимость использовалась:
mod_securityи «параноидальные» требованияsuphp).хотя погуглив нашел эксплойт датированный [2009-08-31] . Что-то разработчики явно не спешат закрывать дыры
Гугл выдал ссылка на хакер.ру Запись датируется 2006 годом, так что разрабы особо не шевелятся.
На xakep.ru несколько другая уязвимость — XSS (выполнение произвольного кода в браузере посетителя). А эта уязвимость позволяет творить разные нехорошие вещи уже на самом сервере.
А разработчики на самом деле не шевелятся