Во вторник 14 декабря команда разработки Joomla выпустила срочное обновление безопасности, закрывающее 0-day уязвимость, которая открывает злоумышленникам возможность удаленного исполнения кода. Хакеры уже активно пытаются атаковать уязвимые сайты.
Что случилось
По сообщению ИБ-компании Sucuri, эта ошибка уже эксплуатируется киберпреступниками — исследователям удалось обнаружить свидетельства успешных попыток ее использования еще 12 декабря. В лог-файлах веб-серверов скомпрометированных сайтов присутствовали следующие строки:
2015 Dec 12 16:49:07 clienyhidden.access.log
Src IP: 74.3.170.33 / CAN / Alberta
74.3.170.33 – – [12/Dec/2015:16:49:40 -0500] “GET /contact/ HTTP/1.1? 403 5322 “http://google.com/” “}__test|O:21:\x22JDatabaseDriverMysqli\x22:3: ..
{s:2:\x22fc\x22;O:17:\x22JSimplepieFactory\x22:0: .. {}s:21:\x22\x5C0\x5C0\x5C0disconnectHandlers\x22;a:1:{i:0;a:2:{i:0;O:9:\x22SimplePie\x22:5:..
{s:8:\x22sanitize\x22;O:20:\x22JDatabaseDriverMysql\x22:0:{}s:8:\x22feed_url\x22;s:60:..
В коде обработчика сессий Joomla пристутствует уязвимость, которая позволяет осуществить внедрение строки в синтаксис сериализованной сессии через HTTP-заголовки User-Agent и X-Forwarded-For. Эксплоит использует особенность MySQL при обработке utf8-символов из диапазона U+010000 — U+10FFFF. При вставке строки, в конце которой присутствует такой символ, MySQL обрежет данные. Это позволяет сформировать и записать в таблицу сессий строку, в которой присутствуют пользовательские PHP-объекты, без нарушения синтаксиса. В ходе десериализации сессии атакующего вызываются деструкторы классов Joomla, что ведет к выполнению произвольного кода?. Для того, чтобы данные не обрезались, в MySQL необходимо использовать кодировку utf8mb4?. ??
Как заявляют исследователи Sucuri, обнаруженные атаки осуществлялись со следующих IP-адресов:
- 74.3.170.33 (12 декабря);
- 146.0.72.83 (13 декабря);
- 194.28.174.106 (13 декабря);
14 декабря число попыток эксплуатации серьезно увеличилось — все «ловушки» (honeypot), созданные исследователями, были неоднократно атакованы.
Удаленное выполнение кода с помощью уязвимости Joomla
Участники сообщества пользователей фреймворка Metasploit на GitHub в режиме реального времени занимаются написанием эксплойта к обнаруженной уязвимости Joomla. По последним сообщениям участникам удалось создать работающий модуль для эксплуатации уязвимости:
Joomla 1.5 была выпущена в январе 2008 года — это означает, что уязвимость присутствует в этой и более поздних версиях системы уже почти на протяжении восьми лет. В настоящий момент нет данных о том, какое количество сайтов и веб-ресурсов были скомпрометированы вследствие эксплуатации этой бреши.
Как защититься
Уязвимость распространяется на версии Joomla 1.5 по 3.4.5 включительно. Всем пользователям CMS необходимо обновить свою систему — сделать это можно здесь. Пользователям старых неподдерживаемых версий 1.5.x и 2.5.x следует установить патчи, доступные по ссылке (инструкция по использованию фиксов представлена на английском языке здесь).
В качестве временной меры предосторожности исследователи Sucuri рекомендуют заменять потенциально опасные данные в заголовке HTTP User-Agent. Ниже представлен пример конфигурации для веб-сервера Apache:
RewriteCond %{HTTP_USER_AGENT} .*\{.* [NC]RewriteRule .* - [F,L]Кроме того, эксперты Positive Technologies рекомендуют использовать специализированные средства защиты от киберугроз — к примеру, межсетевой экран прикладного уровня PT Application Firewall успешно отражает возможные попытки эксплуатации указанной уязвимости:
Исследователи безопасности не в первый раз находят уязвимости в CMS Joomla. В октябре 2015 года была выпущена версия системы 3.4.5, в которой были устранены серьезные уязвимости (CVE-2015-7297, CVE-2015-7857, CVE-2015-7858), которые открывали злоумышленникам возможности, в том числе и осуществления SQL-инъекций.
Напомним также, что использование CMS с открытым кодом – вовсе не гарантия безопасности, если вы не проверяли эти коды на уязвимости. В прошлом году эксперты Positive Technologies, используя анализатор кодов PT Application Inspector, нашли множество багов в нескольких популярных CMS с открытым кодом, включая Joomla, Shopos, Yii и Jahia, а также в плагинах для Wordress. Разбор одного такого исследования, с уязвимостями системы InstantCMS, мы публиковали в начале года.
Комментарии (32)
Kain_Haart
16.12.2015 08:25+2Во вторник 14 декабря команда разработки Joomla выпустила срочное обновление безопасности, закрывающее 0-day уязвимость
Как уязвимость может быть 0-day если компания уже выпустила закрывающее ее обновление?
https://ru.wikipedia.org/wiki/%D0%A3%D1%8F%D0%B7%D0%B2%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D1%8C_%D0%BD%D1%83%D0%BB%D0%B5%D0%B2%D0%BE%D0%B3%D0%BE_%D0%B4%D0%BD%D1%8F
Sleuthhound
16.12.2015 09:18+20-day — это такое модное нынче слово для привлечения внимания, если в продукте есть 0-day — то все пропало, нужно срочно покупать дорогие межсетевые экраны типа PT Application Firewall, да и вообще лучше купить коммерческий Bitrix или NetCat, в них же типа нет дыр.
Экспертам из Positive Technologies следует обратить внимание и на коммерческие CMS, в которых зачастую за приличные деньги существует приличное количество дыр о которых умалчивается.
xRay
16.12.2015 09:58Судя по описанию о уязвимости стало известно аж 12-го декабря.
Уязвимость становиться не 0-day на следующий день после появления.
akirsanov
16.12.2015 13:14+10-day — уязвимость, к которой нет официальной заплатки. Публикация часто приводит к фиксу 0-day, т.к. разработчик выпускает патч. До момента патча уязвимость — нульдей.
istui
16.12.2015 10:02Судя по тому, что ей подвержены все версии, начиная с 1.5, она могла пробыть в статусе 0-day очень долго. Это сейчас нам стало о ней известно, но не факто что кто-то не знал о ней раньше…
akirsanov
16.12.2015 13:19Специфика современного интернета такова, что он напичкан ханипотами, ids различного уровня, waf`ами, поэтому массовая эксплуатация данной уязвимости годами маловероятна. Для примера — эксплуатацию этой уязвимости нашли Securi, они зафиксировали первую попытку эксплуатации как минимум за 2 дня до официального патча:
That is very concerning is that this vulnerability is already being exploited in the wild and has been for the last 2 days. Repeat: This has been in the wild as a 0-day for 2 days before there was a patch available.
Уязвимость была в статусе 0-day долгие годы, другое дело, знал ли кто о ней, эксплуатировал ли. Для этого нужно грепать старые логи.
defuz
16.12.2015 11:34+1При вставке строки, в конце которой присутствует такой символ, MySQL обрежет данные.
Коротко: MySQL в очередной раз ведет себя не как база данных, а как херня, написанная школьником. На этот раз это привело к критической уязвимости.
Raz0r
16.12.2015 15:45+1При STRICT_TRANS_TABLES=1 MySQL будет выдавать ошибку. Начиная с версии 5.7.5 строгий режим включен по умолчанию. И нельзя не отметить разработчиков Joomla, использующих неправильную кодировку для таблиц. Кстати, похожий баг был в WordPress: vagosec.org/2013/09/wordpress-php-object-injection
defuz
16.12.2015 16:56+1При STRICT_TRANS_TABLES=1 MySQL будет выдавать ошибку. Начиная с версии 5.7.5 строгий режим включен по умолчанию.
Это должно было быть поведением по-умолчанию с самого рождения MySQL. Я не большой специалист по базам данных, но даже мне это очевидно.
И нельзя не отметить разработчиков Joomla, использующих неправильную кодировку для таблиц.
Какую они использовали кодировку и какая правильная?
Кстати, похожий баг был в WordPress
Я боюсь, что «похожий баг» был не только в Wordpress, а вообще везде где используется MySQL. Просто где-то уже нашли как применить такое поведение MySQL, а где-то еще нет.Raz0r
16.12.2015 17:06В Joomla используется кодировка utf8, нужно использовать utf8mb4. Мой посыл в том, что необходимо знать, как правильно пользоваться инструментами, которые ты выбрал; сам инструмент не виноват, если его используют неправильно.
defuz
16.12.2015 17:24+3Чесно вам скажу, я пользуюсь MySQL не первый год, и я вообще первый раз слышу, что есть такая кодировка как utf8mb4. Конечно, это я мудак, «неправильно пользуюсь инструментом», но черт возьми, нахрена мне инструмент, который на каждом шагу подкладывает мне грабли под ноги?
Виноват MySQL. И разработчики MySQL тоже виноваты. Нужно всегда исходить из того, что разработчик не может знать все сразу, так что нечего на них спихивать проблему.Raz0r
16.12.2015 18:25Во-первых, разработчики Joomla допустили инъекцию в строку сериализованной сессии, так как не проверяют входящие данные, во-вторых, они не разбираются в особенностях работы базы данных. Другое дело, если бы это была уязвимость в самой базе данных.
Pinsky
16.12.2015 14:53Ждумля — это, вообще, кладезь дыр. От самого двигла, заканчивая шаблонами и модулями.
Divasoft
17.12.2015 23:26+1После выхода новости мы успели спасти ~15 проектов, но еще несколько успели заразиться… Самое интересное что часть взломов прошла через визуальный редактор JCE. Но заражение пошло не по плану, и обрушилась Mysql с ошибкой MySQL server has gone away
Зловред закопался в активный шаблон. Аккуратно добавив в начало index.php (шаблона) <?php include_once('ob_cache.php'); ?> и в конец <?php ob_end_flush(); ?>
Собственно сам код ob_cache.php http://pastebin.com/GUJc1vj8
Красиво сделали…
Shance
18.12.2015 18:52+1Это позволяет сформировать и записать в таблицу сессий строку без нарушения синтаксиса.
Синтаксис нарушается. Джумла пишет в таблицу сессии сериализованный массив __default|a:7:{...}, а при использовании данной уязвимости можно записать в свойство session.client.browser пайлоад, который начинается с }__test, чтобы закрыть массив default и открыть объект test, синтаксис которого валиден. Но при этом массив default получается невалидным по 3 причинам: количество его элементов(a:7) уже меньше 7, во-вторых параметр s:22:«session.client.browser»;s:435:" остаётся не закрытым, но и самая большая проблема, которую никак не обойти, в отличии от двух предыдущих, длина этого параметра равна длине нашей полезной нагрузки, то есть, в данном случае, 435.
Это чревато тем, что при попытке стартануть сессию PHP выдаст предупреждение:
session_start(): Failed to decode session object. Session has been destroyed
И, как вы можете видеть, уничтожит сессию.
Честно говоря, я не понимаю, от чего это зависит. Я думал, что это как-то связанно с версией PHP и уязвимостями CVE-2015-0231 или CVE-2014-8142, но собрав PHP 5.5.18 и попробовав на ней эксплоит не пришел ни к какому результату.
Может, кто-нибудь знает, почему иногда PHP забивает на невалидную сессию, а иногда нет?Shance
19.12.2015 03:17Скорее всего это связанно с CVE-2015-6835, но всё равно остаётся загадкой, почему php 5.5.18 остался непобежденным. Хотя соседний мак с мампом и такой же версией php пал с первой попытки.
istui
Автоматическая рассылка уведомлений об обновлениях, которая появится в версии 3.5, будет как нельзя кстати.
Alexufo
все важные секьюрити патчи должны ставится автоматом
Lopar
Как раз нет. Ибо тот, кто скомпрометирует сервер обновлений — автоматически пропатчит всех пользователей.
Alexufo
Так работает вордпресс и как то… спокойнее, зная что он хором по всей планете автопатчит серьезные уязвимости.
Так работает винда, антивирусы и куча другого софта. Этож нормально. А чтобы не скомпрометировали надо делать так чтобы не скомпрометировали :-)
Lopar
У меня как-то на древней-древней серверной убунте стояло автообновление. Много лет назад. И была там грустная история, когда вышла новая версия с опечаткой в ядре (или не в ядре, но в чём-то очень критичном). Опечатку оперативно испраили и образ новый перезалили минут через 40, но те у кого стояло автообновление его выкачать успели и уронили себе системы. С тех пор — лучше руками.
Alexufo
Вы описали момент в памяти.
Ну это же вид суеверия, при котором мы ожидаем ошибки и обходим её казалось бы правильным способом. Так проблема зачастую ошибок в их непредсказуемости. Ну не пользоваться чтоли теперь автообновлением али кто то когда то где то раз испортил ощущение безопасности сего функционала. Вы могли бы обновить руками в эти 40 мин. и получить тот же результат. Кто то наверняка так и сделал и теперь только добавил уровень стресса в работе с обновлением в ручную.
Не, касаемо обновлений бубунты каждый сам решает как ему удобнее. В принципе если вы не цель хакера номер 1который так и ждёт как бы подловить ваш сайт то снижение уровня стресса от непредсказуемости при автообновлении дело хорошее. Однако для cms это крайне важно.
Лучше случайно положить, чем дать дорогу спаму, массовых хаков, иддос атак. для тысяч серверов. То есть в случае прокола с автообновлением ответственный есть. И его можно страховать и побить). В случае новых дырок в старых системах поделать уже мало чего можно.
Lopar
В случае прокола с автообновлением как раз ответственного нет. Тот же wordpress «не несёт ответственности за…» и дальше по тексту. Если обновляться руками — то оператор как минимум должен убедиться, что всё будет работать до и после и весь процесс — под его ответственность. Если оператор бездумно клацает «NEXT-NEXT-NEXT», то это исключительно его проблемы, но не нужно пытаться доказать, что автоматическое обновление — это тот же процесс, только автоматизированный, тем самым приравнивая всех к таким вот операторам.
istui
аналогичный баг был с CentOS в январе этого года, правда не с ядром, а с несовместимостью стандартных пакетов после установки одного из них.
sashabeep
Вот ни разу не удивили. RSS с уведомлениями на главной странице в админке MODX была с момента ее появления, очень много лет назад.
istui
В Joomla! тоже уже несколько лет есть уведомления на главной странице админки, правда, не RSS.
Вот только показываются они (и кнопка обновления) только тем пользователям, у кого есть на обновление права.
Как часто вы заходите в админку сайта, если «все работает», а особенно — если наполняете сайт не вы, а редакторы, которым это уведомление не приходит?
Здесь же достаточно указать e-mail, который точно есть у каждого, и который и так указывается при конфигурации сайта, и получать обновления вместе с другими письмами с сайта. Не нужно никаких дополнительных подписок на рассылки ИБ на сайтах, настройки новостных лент (к тому же RSS пользуются не все).
Другой вопрос, что такую функциональность надо было сделать еще в версии 1.0 десять лет назад, а не вводить сегодня.