Использование уязвимости WordPress REST API продолжается

Прошло почти две недели с тех пор, как команда безопасности WordPress обнаружила уязвимость повышения привилегий без проверки подлинности в конечной точке REST API в версиях 4.7 и 4.7.1. Уязвимость была исправлена ​​незаметно, а раскрытие информации было отложено на неделю, чтобы дать владельцам сайтов WordPress преимущество при обновлении до версии 4.7.2. На прошлой неделе сотни тысяч уязвимых сайтов уже были испорчены, а отчеты о повреждениях продолжают поступать.

За выходные количество атак увеличилось, и фирмы, занимающиеся безопасностью WordPress, столкнулись с большим количеством попыток, заблокированных их брандмауэрами. Sucuri, фирма по обеспечению безопасности веб-сайтов, которая сообщила об уязвимости в WordPress, отслеживала кампанию «Hacked by w4l3XzY3» на прошлой неделе и оценила 66 000 дефейсов. Эта конкретная кампания уже прошла более 260 000 страниц, проиндексированных Google. Это одна из почти двух десятков кампаний по порче, нацеленных на уязвимость.

«За последние 24 часа мы наблюдали средний рост количества испорченных страниц в расчете на одну кампанию на 44%, — заявил в пятницу генеральный директор Wordfence Марк Маундер. «Общее количество испорченных страниц по всем этим кампаниям, проиндексированное Google, выросло с 1 496 020 до 1 893 690. Это на 26% больше общего количества испорченных страниц всего за 24 часа».

Маундер сослался на диаграмму Google Trends, которая, по его словам, демонстрирует успех кампаний по порче за последнюю неделю. Всплеск начался в тот день, когда WordPress раскрыл уязвимость.

Однако White Fir Design, еще одна компания, предлагающая услуги по обеспечению безопасности, оспаривает заявления Wordfence о том, что 1,8 миллиона страниц были взломаны. Цифра ~2 миллиона страниц приводится в отчетах BBC, The Enquirer, Ars Technica, CIO.com и других изданиях. White Fir Design утверждает, что взломанные страницы, проиндексированные Google, не являются точным представлением.

Технический директор Sucuri Дэниел Сид также не полностью согласен с оценкой ситуации Wordfence. Проведя небольшое исследование на выходных, Sucuri оценивает более 50 000 взломанных сайтов, при этом 20-30 страниц на каждом сайте испорчены. Это будет примерно миллион в нижней части оценки и колеблется до 1,5 миллиона.

Sucuri также начинает сталкиваться с более серьезными попытками уязвимости REST API в виде атак удаленного выполнения кода (RCE) на сайты с использованием плагинов, которые позволяют выполнять PHP из сообщений и страниц. Одна из таких кампаний пытается внедрить PHP, чтобы добавить контент со взломанного сайта, а затем внедрить бэкдор, скрытый в /wp-content/uploads.

«Порча не приносит экономической выгоды, так что, скорее всего, она скоро умрет», — сказал Сид. «Что останется, так это попытки выполнить команды (RCE), поскольку это дает злоумышленникам полный контроль над сайтом и предлагает несколько способов монетизации, а также спам SEO / партнерские ссылки / рекламные инъекции. Мы начинаем замечать их попытки на нескольких сайтах, и, вероятно, именно в этом направлении эта уязвимость будет использоваться не по назначению в ближайшие дни, недели и, возможно, месяцы».

Хакеры нацелены на любые сайты, которые не обновились до версии 4.7.2 — среди них нет никакой закономерности. Беглый взгляд на результаты Google для наиболее активных кампаний показывает, что скомпрометированные сайты включают блоги, СМИ, правительственные, образовательные, спортивные, медицинские и технологические веб-сайты.

Почему REST API включен по умолчанию

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

«Проблема безопасности заключается в функции, которую я не использую ни на одном из своих сайтов (REST API), и тем не менее, эта функция сначала включена по умолчанию, а во-вторых, начиная с WordPress 4.7, вам даже нужен плагин, который может создать дополнительные проблемы с безопасностью. отключить эту функцию?» один пользователь (@helios2121) прокомментировал пост. «Пожалуйста, пересмотрите свой подход к безопасности. Делайте функции, которые не всем нужны. Или, по крайней мере , дайте возможность отказаться, не требуя дополнительных плагинов».

Мортен Рэнд-Хендриксен открыл тикет, чтобы обсудить отключение REST API по умолчанию и включение его только тогда, когда его запрашивает администратор сайта или от него зависит тема или плагин.

Основной участник Сергей Бирюков подтвердил, что планируется добавить больше основных функций, основанных на REST API. «Отключение REST API похоже на отключение admin-ajax.php — и то, и другое сломает ваш сайт», — сказал Бирюков.

Рэнд-Хендриксен спросил, почему конечные точки контента не могут быть защищены по умолчанию, в то время как REST API может быть включен по умолчанию для целей администрирования. Другой пользователь спросил, почему конечная точка Users не защищена по умолчанию (например, https://news.microsoft.com/wp-json/wp/v2/users или https://www.obama.org/wp-json/wp). /v2/users), что «облегчает получение всех имен пользователей» на любом сайте, использующем версию 4.7+.

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

Найлен рекомендует плагин Disable JSON API для тех, кто хочет следовать этой рекомендации на сайтах, использующих WordPress 4.7+. Плагин в настоящее время имеет более 10 000 активных установок.

Команда безопасности WordPress усердно работала над предотвращением атак, помогая хостам и охранным фирмам установить защиту до того, как проблема стала достоянием общественности. Однако полное раскрытие уязвимости было скрыто в блоге Make/Core, сайте, который мало читается среди обычных владельцев сайтов WordPress. Ссылка на раскрытие была опубликована в качестве дополнения к предыдущему сообщению в новостном блоге WordPress неделю спустя.

«Хотя я ценю ответственное раскрытие этой проблемы и усилия по ее решению, я надеюсь, что вы рассмотрите возможность делать будущие объявления через новый пост на сайте новостей WordPress, а не просто добавляя обновление к предыдущему сообщению», — прокомментировал пользователь @johnrork. об официальном раскрытии. «Я, вероятно, не единственный, кто мог бы избежать компрометации, если бы это появилось в качестве нового элемента в моем RSS-ридере в среду».

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

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