Польский ИБ-специалист Давид Голунски (Dawid Golunski) рассказал о том, что еще летом 2016 года ему далось обнаружить проблему в WordPress, которая позволяет атакующему инициировать сброс пароля жертвы. Уязвимость до сих пор не исправлена, но эксперт устал ждать реакции от разработчиков популярной CMS и решил действовать сам, предупредив пользователей об опасности и предоставив им шанс защитить себя.
Уязвимость получила идентификатор CVE-2017-8295 и была обнаружена в июле 2016 года. Проблема опасна для всех версий WordPress, включая 4.7.4, и касается того, как CMS осуществляет сброс пароля. Согласно данным исследователя, атакующий может составить вредоносный HTTP-запрос, подставив в него кастомную переменную SERVER_NAME, к примеру, «домен-атакующего.com». В итоге запрос спровоцирует обнуления пароля, но когда WordPress будет определять значения From и Return-Path, они примут вид «wordpress@домен-атакующего.com».
Хотя на первый взгляд кажется, что эта уязвимость не принесет злоумышленникам никакой выгоды (казалось бы, что выиграет хакер, отправив легитимному владельцу сайта письмо о сбросе пароля?), Голунски объясняет, что это не так.
Эксперт описывает несколько теоретических сценариев атаки. К примеру, атакующий может устроить настоящую флуд-атаку на почтовый ящик владельца сайта. Рано или поздно огромное количество поддельных писем о сбросе пароля вызовет переполнение ящика жертвы, после чего почтовый сервер вернет письмо отправителю, используя Return-Path, то есть email получит сам атакующий.
Также исследователь пишет, что можно дождаться, когда администратор сайта решит взять отпуск. Если на время своего отсутствия он активирует автоответчик, у атакующего так же будет отличный шанс заполучить копию письма о сбросе пароля, так как автоответчик обычно прикладывает к своим сообщениям копию оригинального послания.
Другие описанные Голунски сценарии атак ничем не сложнее этих, но они потребуют применения хитрости и социальной инженерии.
Так как за прошедшие десять месяцев разработчики WordPress так и не представили патч для данной проблемы, Голунски советует администраторам сайтов защищаться самостоятельно. В качестве временного решения проблемы эксперт предлагает включить UseCanonicalName, чтобы принудить переменную SERVER_NAME оставаться статической. Пользователи Reddit, где уже активно обсуждают другие способы обхода проблемы, предложили и другое решение: создать подставной vhost и адресовать на него все запросы с подозрительными host header’ами.
