Уязвимость Exim ставит под угрозу половину почтовых серверов Сети

Уязвимость Exim ставит под угрозу половину почтовых серверов Сети

Уязвимость Exim ставит под угрозу половину почтовых серверов Сети

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

Вся проблема кроется в Exim, агенте пересылки сообщений, используемом в операционных системах семейства Unix. Это программное обеспечение работает на серверах и отвечает за отправку и получение электронных писем.

Согласно опросу, проведенному в марте 2017 года, 56 % всех почтовых серверов в интернете используют Exim, на тот момент активными были более 560 000. А в более свежем отчете утверждается, что насчитываются миллионы таких серверов.

Уязвимость обнаружил исследователь безопасности из Тайваня по имени Мех Чанг (Meh Chang), о чем сообщил команде Exim 2-го февраля. Команда Exim выпустила версию 4.90.1 спустя восемь дней, в ней исправлена брешь, которая может позволить удаленно выполнить код.

Отслеживаемая под идентификатором CVE-2018-6789, может позволить злоумышленнику обмануть сервер электронной почты Exim и запустить вредоносные команды до того, как злоумышленник должен будет пройти проверку подлинности на сервере.

Ошибка представляет собой однобайтное переполнение буфера в функции декодирования base64 и влияет на все выпущенные версии Exim. Чанг подробно описал баг в своем блоге.

В официальном заявлении команда Exim публично признала эту проблему.

«В настоящее время мы не до конца уверены, что проблема критична. На наш взгляд, эксплуатировать эту уязвимость достаточно сложно», — заявили представители Exim.

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

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

Расширения Chrome могут слить секреты URL через атаку по стороннему каналу

Как оказалось, расширения Chrome можно использовать для слива кодов авторизации, сеансовых ID и других секретов из URL любой открытой вкладки. Никаких специальных разрешений для этого не понадобится, только доступ к declarativeNetRequest API.

Этот механизм, пришедший на смену webRequest API, позволяет расширениям сообщать браузеру, что следует изменить или заблокировать на загружаемой странице (заголовки, реклама, трекеры).

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

Исследователь Луан Эррера (Luan Herrera) обнаружил, что блокировку, диктуемую правилами, Chrome производит почти мгновенно, за 10-30 мс, а остальные запросы выполняются дольше (~50-100ms) — из-за сетевых подключений. Эту разницу во времени расширение может использовать для бинарного поиска с целью посимвольного слива URL.

// extensions/browser/api/web_request/extension_web_request_event_router.cc:1117-1127
case DNRRequestAction::Type::BLOCK:
  ClearPendingCallbacks(browser_context, *request);
  DCHECK_EQ(1u, actions.size());
  OnDNRActionMatched(browser_context, *request, action);
  return net::ERR_BLOCKED_BY_CLIENT;

Оракул для подобной тайминг-атаки строится с использованием chrome.tabs.reload для перезагрузки страницы и перехватчика chrome.tabs.onUpdated, помогающего отследить событие status === "complete". Замер времени между reload и завершением загрузки покажет, заблокирован запрос или успешно обработан.

Повторение проверок и бинарного поиска позволяет получить полный URL (с довеском после «?»), затратив на каждый знак строки несколько прогонов. Таким образом, можно незаметно для пользователя украсть включенные приложением в адрес секреты — токены OAuth и сброса пароля, API-ключи, ссылки на контент, закрытый для поисковых систем.

Проверка PoC проводилась на Windows 11 24H2 с использованием Chrome разных версий:

  • 144.0.7559.97 (Stable)
  • 145.0.7632.18 (Beta)
  • 146.0.7647.4 (Dev)
  • 146.0.7653.0 (Canary)

В Google подтвердили возможность подобной атаки по стороннему каналу, но заявили, что решить проблему нереально.

RSS: Новости на портале Anti-Malware.ru