• XSS.stack #1 – первый литературный журнал от юзеров форума

Статья Horde Webmail — удаленное выполнение кода по электронной почте

вавилонец

CPU register
Пользователь
Регистрация
17.06.2021
Сообщения
1 116
Реакции
1 265
ОРИГИНАЛЬНАЯ СТАТЬЯ
ПЕРЕВЕДЕНО СПЕЦИАЛЬНО ДЛЯ xss.pro
$600 на SSD для Jolah Molivski ---> 0x5B1f2Ac9cF5616D9d7F1819d1519912e85eb5C09 для поднятия ноды ETHEREUM и тестов

1663208655417.png

Приложение веб-почты позволяет организациям размещать для своих членов централизованный почтовый клиент на основе браузера. Как правило, пользователи входят на сервер веб-почты со своими учетными данными электронной почты, после чего сервер веб-почты выступает в качестве прокси-сервера для почтового сервера организации и позволяет пользователям, прошедшим проверку подлинности, просматривать и отправлять электронные письма. С таким большим доверием к серверам веб-почты они, естественно, становятся очень интересной мишенью для злоумышленников. Если изощренный злоумышленник сможет скомпрометировать сервер веб-почты, он сможет перехватить каждое отправленное и полученное электронное письмо, получить доступ к ссылкам для сброса пароля и конфиденциальным документам, выдать себя за сотрудников и украсть все учетные данные пользователей, входящих в службу веб-почты.
Обсуждим уязвимость, обнаруженную командой разработчиков Sonar в веб-почте Horde. Уязвимость позволяет злоумышленнику полностью захватить экземпляр, как только жертва открывает электронное письмо, отправленное злоумышленником. На момент написания официального патча не было. / 31 мая 2022 г. прим.пер. /

Влияние

Обнаруженная уязвимость кода (CVE-2022-30287) позволяет аутентифицированному пользователю Horde выполнять произвольный код на базовом сервере.
Уязвимость можно использовать с помощью одного запроса GET, который можно активировать с помощью межсайтовой подделки запросов. Для этого злоумышленник может создать вредоносное электронное письмо и включить внешнее изображение, которое при отображении использует уязвимость без дальнейшего взаимодействия с жертвой: единственное требование — чтобы жертва открыла вредоносное электронное письмо.
Еще один побочный эффект этой уязвимости заключается в том, что учетные данные жертвы, запускающей эксплойт, в открытом виде передаются злоумышленнику. Затем злоумышленник может использовать их, чтобы получить доступ к еще большему количеству услуг организации. Это показано в нашем видео:

Предыстория — настройка адресной книги Horde

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

PHP:
$cfgSources['personal_ldap'] = array(
   // Disabled by default
   'disabled' => true,
   'title' => _("My Address Book"),
   'type' => 'LDAP',
   'params' => array(
       'server' => 'localhost',
       'tls' => false,
    // …

Как видно, эта конфигурация LDAP добавляется в массив доступных серверных частей адресной книги, хранящихся в $cfgSources . Сама конфигурация представляет собой массив ключей/значений, содержащий записи, используемые для настройки драйвера LDAP.

CVE-2022-30287 — отсутствие проверки типов в классе Factory

Когда пользователь взаимодействует с конечной точкой, связанной с контактами, ожидается, что он отправит строку, идентифицирующую адресную книгу, которую он хочет использовать. Затем Horde извлекает соответствующую конфигурацию из $cfgSources и управляет подключением к серверной части адресной книги.
Следующий фрагмент кода демонстрирует типичное использование этого шаблона:

PHP:
14 require_once __DIR__ . '/lib/Application.php';
 15 Horde_Registry::appInit('turba');
 16
 17 $source = Horde_Util::getFormData('source');
 18 // …
 19 $mergeInto = Horde_Util::getFormData('merge_into');
 20 $driver = $injector->getInstance('Turba_Factory_Driver')->create($source);
 21 // …
 30 $contact = $driver->getObject($mergeInto);

Фрагмент кода выше показывает, как параметр $source принимается и передается в метод () create драйвера Turba_Factory_Driver . Turba — это название компонента адресной книги Horde.
Все становится интереснее при взгляде на метод create() :

PHP:
51     public function create($name, $name2 = '', $cfgSources = array())
 52     {
 53     // …
 57         if (is_array($name)) {
 58             ksort($name);
 59             $key = md5(serialize($name));
 60             $srcName = $name2;
 61             $srcConfig = $name;
 62         } else {
 63             $key = $name;
 64             $srcName = $name;
 65             if (empty($cfgSources[$name])) {
 66                 throw new Turba_Exception(sprintf(_("The address book \"%s\" does not exist."), $name));
 67             }
 68             $srcConfig = $cfgSources[$name];
 69         }

Тип параметра $name проверяется. Этот параметр соответствует показанному ранее $source . Если это массив, он используется непосредственно как конфиг, задав для $srcConfig . Если это строка, с ней осуществляется доступ к глобальному $cfgSources соответствующая конфигурация.

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

Через несколько строк кода метод create() динамически создает экземпляр класса драйвера, используя значения из массива, контролируемого злоумышленником:

Код:
75  $class = 'Turba_Driver_' . ucfirst(basename($srcConfig['type']));
76    // …
112  $driver = new $class($srcName, $srcConfig['params']);


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

Создание экземпляра драйвера, позволяющего злоумышленнику выполнять произвольный код

Следующим шагом злоумышленника будет внедрение конфигурации драйвера, которая позволит ему выполнять произвольный код на экземпляре Horde, на который он нацелился.
Мы обнаружили, что Horde поддерживает подключение к серверу IMSP , который использует протокол, разработанный в 1995 году, но так и не доработанный, так как он был заменен ACAP протоколом. При подключении к этому серверу Horde получает различные записи. Некоторые из этих записей интерпретируются как сериализованные объекты PHP и затем десериализуются.
Следующий фрагмент кода из метода _read() класса драйвера IMSP показывается, как __members . Если он существует, он десериализуется:
Код:
223   if (!empty($temp['__members'])) {
224      $tmembers = @unserialize($temp['__members']);
225   }

Благодаря наличию viable PHP Object Injection gadgets, обнаруженных Стивеном Сили , злоумышленник может заставить Horde десериализовать вредоносные объекты, которые приводят к выполнению произвольного кода.

Эксплуатация уязвимости через CSRF

По умолчанию Horde блокирует любые изображения в электронных письмах в формате HTML, которые не имеют данных: URI. Злоумышленник может обойти это ограничение, используя теги HTML <picture> и <source> . Тег <picture> позволяет разработчикам указывать несколько источников изображений, которые загружаются в зависимости от размеров пользователя, посещающего сайт. Следующий пример обходит блокировку внешних изображений:

PHP:
<picture>
  <source media="(min-width:100px)" srcset="../../?EXPLOIT">
  <img src="blocked.jpg" alt="Exploit image" style="width:auto;">
</picture>

На момент написания официального патча не было. Поскольку Horde больше не поддерживается активно, мы рекомендуем рассмотреть альтернативные решения для веб-почты.
 


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх