В WordPress найдена 0-day уязвимость, позволяющая получить ссылку для сброса пароля

Эксперт по безопасности из Польши, Давид Голунский, обнаружил уязвимость нулевого дня в механизме сброса пароля WordPress, которая позволит злоумышленнику получить ссылку сброса пароля при определенных обстоятельствах.

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

Как устроена уязвимость?

Ошибка безопасности, получившая идентификатор CVE-2017-8295, затрагивает все версии WordPress и связана с тем, как сайты WordPress создают письма для изменения пароля.

По данным Голунского, злоумышленник может создать вредоносный HTTP-запрос, который запускает операцию сброса пароля с помощью инъекции изменённой переменной SERVER_NAME, например, со значением attacker-domain.com.

Это означает, что когда на сайте WordPress создается создаётся письмо для изменения пароля, значения From и Return-Path будут в формате wordpress@attacker-domain.com.

И чем же она опасна?

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

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

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

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

Другие сценарии, описанные Голунским, требуют применения социальной инженерии, поэтому их использование маловероятно.

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

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

Для этого есть несколько способов. Голунский предложил:

В качестве временного решения пользователи могут включить UseCanonicalName для применения статического значения SERVER_NAME.

На Reddit владельцам сайтов порекомендовали «создать фиктивный виртуальный хост, который будет перехватывать все запросы с нераспознанными заголовками Host».

В зависимости от вашего технического мастерства вы также можете поэкспериментировать с другими вариантами, обсуждаемыми в этом посте на Reddit — по крайней мере, пока команда WordPress не исправит эту проблему.

Стоит отметить, что Голунский также сообщил дополнительные подробности об обнародованной ранее RCE-уязвимости в PHP Mailer, библиотеке, встроенной в WordPress по умолчанию.