На официальном сайте WordPress закрыли две XSS-уязвимости

Эксперты RIPS Technologies рассказали о двух XSS-уязвимостях на сайте WordPress.org, которые были обнаружены еще в мае текущего года. Один из багов обладал потенциалом червя. В связи с этим исследователи в очередной раз напоминают, что компрометация всего одного плагина для популярной CMS может иметь очень масштабные последствия. Достаточно вспомнить недавний случай с плагином WP GDPR Compliance, уязвимость в котором использовали для захвата сайтов.

На этот раз исследователи обнаружили проблемы не в самих плагинах, но на сайте WordPress.org, в официальном репозитории. Первую уязвимость заметили почти случайно: специалисты работали над сервисом coderisk.com, и им понадобилось реализовать сортировку по всем доступным версиям плагинов для WordPress, представленным в официальном репозитории. Так как универсальной схемы контроля версий не существует, оказалось, что разработчики более чем 50 000 плагинов нумеруют свои продукты как придется (некоторые версионные схемы эксперты прямо называют «экзотическими»).

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

Как оказалось, в репозитории WordPress.org присутствовала так называемая stored XSS, то есть «хранимая» или «постоянная» XSS-уязвимость, связанная с полем, где отображается версия плагина.

Фактически, получив контроль над каким-либо плагином для WordPress, или создав свой собственный, злоумышленники могли внедрить в поле версии произвольный вредоносный код. Такая «закладка» могла срабатывать в контексте WordPress.org каждый раз, когда кто-то посещал страницу зараженного плагина. Хуже того, если во время атаки жертва была залогинена на WordPress.org и сама являлась разработчиком, то пейлоад мог, к примеру, скрыто прописать злоумышленника, как нового коммиттера для учетной записи жертвы, предоставив тому доступ к чужому плагину. Также уязвимость позволяла удалять уже существующих коммиттеров, в том числе и основного разработчика. По сути, преступники могли перехватить контроль над чужим продуктом и продолжить распространять угрозу далее, как червя. Для начала подобной атаки, достаточно было разместить на любом популярном форме для разработчиков ссылку на страницу вредоносного плагина в репозитории (и вряд ли такая ссылка вызвала бы у кого-то подозрения).

Обнаружив этот баг, исследователи решили проверить всю кодовую базу WordPress.org собственным статическим анализатором кода RIPS. Проверка позволила выявить на официальном сайте CMS еще одну XSS-уязвимость, на этот раз в дашборде по адресу WordPress.org/plugins. Баг представлял собой «отраженную» XSS (reflected XSS).

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

Источник