Уязвимость Joomla! CVE-2023-23752: от кода к выполнению

Защита от CSRF-атак

Межсайтовая подделка запроса (Сross Site Request Forgery – CSRF) позволяет злоумышленнику выполнить какие-либо действия на уязвимом сайте от лица жертвы.

Предположим, что супер-пользователь залогинен на сайте, и посещает взломанную страницу на другом сайте, который включает в себя поддельное изображение со следующим источником:

http://example.com/administrator/index.php?option=com_yourcomponent&task=deleteall

Обозреватель попытается загрузить это поддельное изображение, и, делая это, удалит данные в базе данных компонента (здесь мы предполагаем, что к задаче deleteall привязана функция по удалению данных).

Joomla включает в себя встроенную защиту от таких вещей в виде токена сессии. Для использования этой возможности в вашем расширении вы должны включать токен в любую форму, которое использует ваше расширение:

Далее вы делаете проверку этого токена (например, в контроллере):

See also

Автоматическое обновление Joomla 3.x

В случае, если Вы используете последнюю версию Joomla и не вносили изменений в ядре (все Ваши правки ограничились только шаблоном сайта), то обновиться до последней версии можно с помощью встроенных средств обновления, нажав кнопку “Обновить сейчас”:

Ручное обновление Joomla 3.x

Если автоматическое обновление не проходит или Ваша Joomla имеет значительные изменения в ядре, то обезопасить себя от угрозы взлома можно и без автоматического обновления. Для этого необходимо в файле: libraries/joomla/session/session.php найти участок кода:

// Check for client address
if (in_array('fix_adress', $this->_security) && isset($_SERVER))

Заменить на:

// Check for client address
if (in_array('fix_adress', $this->_security) 
&& isset($_SERVER)
&& filter_var($_SERVER, FILTER_VALIDATE_IP) !== false)

Найти и удалить блок:

// Check for clients browser
if (in_array('fix_browser', $this->_security) && isset($_SERVER))
{
     $browser = $this->get('session.client.browser');
     if ($browser === null)
 {
     $this->set('session.client.browser', $_SERVER);
 }
elseif ($_SERVER !== $browser)
 {
     // @todo remove code:  $this->_state = 'error';
     // @todo remove code:  return false;
 }
}

Найти:

// Record proxy forwarded for in the session in case we need it later
if (isset($_SERVER))
 {
     $this->set('session.client.forwarded', $_SERVER);
 }

Заменить на:

// Record proxy forwarded for in the session in case we need it later
if (isset($_SERVER) 
&& filter_var($_SERVER, FILTER_VALIDATE_IP) !== false)
{
    $this->set('session.client.forwarded', $_SERVER);
}

Используйте только официальные компоненты, модули и плагины, а также последние версии CMS Joomla – это позволит Вам в автоматическом режиме защищать свой сайт от угроз.

За информацию спасибо сайту: http://seolt.ru/blog/uyazvimost-joomla-15-25-34 и https://docs.joomla.org/Security_hotfixes_for_Joomla_EOL_versions

Intro

Joomla is one of the most popular CMS-es with over 1.5 million installations world-wide. We pentested Joomla 3.9.24 and found a password reset vulnerability which we chained with a set of vulnerabilities and features to achieve full compromise of the underlying server.

Joomla has a strong OOP architecture and a large codebase. Strong input validation is applied everywhere, prepared statements are used to protect against sql injections and also type casting is used where integers are required. In addition, by reviewing the code we noticed that defense in depth measures are applied in many places, which is a good sign from a defensive perspective. However, it also means we will have to work harder to achieve our goals.

Защита от PHP-инклюдинга

PHP-инклюдинг (PHP file inclusion) – это уязвимость, позволяющая выполнить произвольный PHP-код на уязвимом сервере.

Предположим, что вы используете вот такой код для подключения файла разметки:

Тогда взломщик может использовать URL в параметре layout для подключения удаленного файла, например вот так:

http://www.example.com/com_yourcomponent/views/yourview?layout=http://www.bad.site/code.php

Как же от этого защититься?

Самым простым способом будет использование абсолютного пути при подключении файла, чтобы исключить неоднозначность для PHP при поиске файла:

или

Константы и недоступны для манипуляции злоумышленником.

Однако лучшим способом будет фильтрация пользовательского ввода, используя класс JInput, а не чистый массив .

По умолчанию JInput применяет к пользовательскому вводу фильтр CMD, который разрешает только следующие символы: a-z, 0-9, нижнее подчеркивание, точку и тире. Такая фильтрация предотвращает также обход по директориям, когда взломщик пытается манипулировать путем для включения файла на этом же сервере (локальное подключение файла). Если вы хотите использовать другие фильтры, то более подробное описание класса JInput вы можете найти в нашей документации.

К слову, удаленное включение файлов работает только на тех системах, на которых включена PHP настройка . Но так как эта опция необходима некоторым программам, её выключение не всегда является хорошей идеей. Так что вы не должны полагаться на то, что будет выключена, и вместо этого писать более безопасный код.

Итак, чтобы обезопасить ваш код от удаленного подключения файлов, вы должны убедиться в том, что вы не используете непроверенный пользовательский ввод при включении файлов. Вы никогда не должны использовать чистые массивы и , вместо этого используйте класс JInput для фильтрации пользовательского ввода.

Будьте предельно осторожны с вызовами функций, которые подключают файлы, такие как: , , , , . Если вам действительно необходимо подключать файлы с именами переменных, убедитесь в том, что вы валидировали все эти переменные, а также пытайтесь ограничить диапазон разрешенных значений.

Подробнее об уязвимости

Сколько всего порядков SQL-инъекций существует?

• Два. Инжект первого порядка выполняется сразу, а второго требует дополнительных запросов
• Выделяют два порядка плюс латеральные инжекты, при которых подменяются значения переменных среды
• Не ограничено по числу использованных запросов

Загрузка …

Из анонса уязвимости можно узнать, что корень проблемы — в отсутствии приведения типов переменной в информационных сообщениях темплейта Hathor (Hathor postinstall message).

Анонс уязвимости в Developer Network

Hathor — это название одного из предустановленных бэкенд-шаблонов административной панели, с которым поставляется Joomla.

Настройка шаблонов панели администрирования в Joomla

По умолчанию используется темплейт isis (на всякий случай: он назван в честь богини Исиды, а не запрещенной в РФ организации), но пользователю разрешено вручную менять его в настройках профиля. Находится эта страничка по адресу .

Настройка профиля текущего пользователя

Теперь настало время зарыться в дебри исходников. Но где искать? Отправную точку, как обычно, ищем в коммите, который решает проблему.

Коммит с патчем для SQLi

Как видишь, нам необходимо заглянуть в файл .

/administrator/templates/hathor/postinstall/hathormessage.php

После патча переменная приводится к , значит, она нам и нужна. Строка 40 говорит нам о том, что значение переменной — это результат работы метода из класса .

/libraries/src/User/User.php

Параметры () текущего пользователя — это экземпляр класса .

/libraries/src/User/User.php

При инициализации пользователя, сохранении данных профиля и прочих манипуляциях с пользовательскими настройками данные попадают в эту переменную. В том числе и нужный нам . Нам остается лишь задать ему значение. Выше я уже писал, где находится редактирование профиля текущего юзера.

Давай включим сниффер и сохраним данные профиля. В пойманном пакете будет атрибут с названием . Так как в запрос попадает первый элемент массива, то добавляем каноничную кавычку.

Продолжение доступно только подписчикам

Материалы из последних выпусков можно покупать отдельно только через два месяца после публикации. Чтобы продолжить чтение, необходимо купить подписку.

Подпишись на «Хакер» по выгодной цене!

Подписка позволит тебе в течение указанного срока читать ВСЕ платные материалы сайта. Мы принимаем оплату банковскими картами, электронными деньгами и переводами со счетов мобильных операторов. Подробнее о подписке

Экономия 1400 рублей!

25-30 статей в месяц

Уже подписан?

Заблуждение № 3: ваш клиент не заинтересован в том, чтобы работать по рекомендациям по обеспечению безопасности, то это прекрасно, можно оставить все как есть

Можно подумать

Если клиент не хочет применять советы безопасности для защиты сайта на Joomla, то вам нечего делать с этим. Можно не париться, ведь теперь если его сайт взломали, то это будет его вина.

Но, на самом деле

Твоя задача выполнять поручения клиента, но не все время. Многие клиенты не хотят платить за апгрейд своих сайтов на Joomla 3.x, потому что их сайты работают отлично. Они считают, что если нет проблемы запуска текущей версии Joomla и сервер защищен, то зачем им нужно беспокоиться об обновлении?

Просто не позволяйте им забывать о безопасности

Ваш клиент не хочет больше тратить время (и деньги) на модернизацию или обслуживание, потому что он не понимает важность этой задачи. И когда они столкнутся со взломом или сбоем сайта, они просто вернутся к вам

В конце концов, это все-таки ваша работа. А очистить взломанный сайт не так легко, как предотвратить попытку взлома. Да и в конце концов, вы можете получить порцию негатива от клиента, который не понял, что вы ему предлагали.

Будьте мудрым разработчиком, который строго соответствует требованиям безопасности и отвечает за любые веб-сайты на Joomla, которые строит (лично я думаю, что это должна быть Клятва Гиппократа для всех разработчиков).

Но на самом деле:

К сожалению, это неправда. Даже если ты ветеран на Joomla.

Почему?

Правда в том, что не существует идеального решения для защиты от хакеров. И даже если вы являетесь экспертом в том, что делаете, ваш сайт по-прежнему под угрозой взлома. Существует множество факторов, влияющих на его безопасность, так что не существует одного единственного универсального решения для комплексной защиты сайта.

Я не говорю, что те “лучшие советы” и “фишки” – это все вранье. Это просто решения, которые могут защитить ваш сайт от того или иного способа взлома. Либо усложнить злоумышленнику взлом. Хороший разработчик поможет Вам с принятием правильных решений для защиты именно вашего сайта Joomla, но не сделает его изолированным от любых атак хакеров.

Joomla password reset vulnerability

To set up the stage, let’s discuss a bit about user roles in Joomla. There are 2 interesting roles, one is “admin” and the other one is “super admin”. As you guessed it’s the “super admin” we really want in the end, but there are a couple of steps in order to get there. We decided to target the password reset functionality. However, you can’t reset the password of a “super admin” the way you would reset it for all other users. The Joomla developers have already thought of that, and they completely removed the password reset functionality for “super admin”. Reducing the attack surface is always a good idea, so kudos to them.

However, we can still reset the password for any other user that is not a “super admin”. Let’s target a regular “admin” in that case. We obviously did a quick Burp scan and found nothing there….not really surprising, right? Most probably everyone else ran a Burp scan before we did and, all those low hanging fruits have been eliminated.

So, we started doing code reviews. Reviewing Joomla source code is not exactly easy, due to the complex OOP architecture and large codebase.  You have to dig really deep in order to find something. So, the truth is we were ready to give up and move on when we remembered about albinowax‘ old technique of poisoning the password reset links. The password reset process starts in the reset.php model:

We need to dig deep and check how the domain is added to the reset link.