Это самый худший взлом в истории WordPress?
BBetter Stack
Internet TechnologyBusiness NewsComputing/Software
Transcript
00:00:00В WordPress недавно обнаружена серия уязвимостей, причём последняя настолько серьезна,
00:00:04что позволяет хакерам получить полный контроль над админ-панелью. Речь идет о SQL-инъекциях, выполнении
00:00:09команд оболочки — всё очень плохо. Возможно, вам всё равно на WordPress, но на нём работает более 44%
00:00:14всех сайтов в мире, так что многие ресурсы, с которыми вы взаимодействуете и куда передаёте данные,
00:00:19вполне могут работать на уязвимой версии WordPress. В общем, работает это примерно так:
00:00:25У меня локально установлена стандартная чистая версия WordPress, и я могу запустить этот
00:00:29первый скрипт, чтобы проверить наличие уязвимости. Как видите, мы получаем ответ
00:00:34HTTP 207, что означает: да, сайт действительно уязвим. Это значит, что теперь мы можем выполнить вторую проверку,
00:00:41а именно войти в интерактивную оболочку. Скрипт выполняет SQL-инъекцию, создаёт нового администратора
00:00:47и затем загружает вредоносный плагин, который позволяет мне взаимодействовать с любым файлом на этом сайте.
00:00:52Так что давайте разберём проблему и посмотрим, как именно она работает.
00:00:58Этот репозиторий показывает, как именно проводить SQL-инъекцию на уязвимых сайтах WordPress —
00:01:06это любые сайты с версиями от 6.90 до 6.94 или от 7.00 до 7.01. Атака начинается с вызова нетребующего авторизации
00:01:14эндпоинта batch v1, который позволяет объединять в пакет другие запросы, проходящие валидацию и проверку прав.
00:01:20У обработчика пакетов есть два параллельных массива, которые должны синхронизироваться: validation и matches.
00:01:26Но из-за бага, когда функция wp pass URL сбоит из-за некорректного пути, обновляется только validation.
00:01:33В итоге один и тот же индекс для обоих массивов даёт рассогласованные результаты. PoC использует это:
00:01:41отправляет пакет всего с одним запросом — POST на эндпоинт v2 post, который сам по себе содержит тело запроса.
00:01:48Поскольку родительский запрос был успешно валидирован как POST, любой запрос внутри тела обходит белый список методов,
00:01:56позволяя отправлять GET-запросы. Затем внутри этого вложенного пакета идет GET-запрос к несуществующему посту, что вызывает
00:02:02ранее упомянутую рассинхронизацию. WordPress отправляет тот же запрос в функцию get items, где поле author
00:02:10exclude сопоставляется с author not in, которое уязвимая сборка подставляет в SQL как строку. Из-за того, как всё это работает,
00:02:18SQL не экранируется. PoC использует серию запросов, которая в конечном итоге позволяет POST-запросу к v2 users создать
00:02:25новую учётную запись админа. В репозитории подробно описаны все эти шаги. Первые пять выполняются до авторизации и используют баг, а шаг 6 — это обычное поведение WordPress для
00:02:35авторизованных пользователей: загрузка вредоносного плагина. Итак, как уже упоминалось, это стандартная чистая версия WordPress, уязвимость не связана с какими-то сторонними плагинами.
00:02:46Можно просто установить стандартный WordPress. Сначала запускаем скрипт проверки, который проверяет,
00:02:52применима ли уязвимость. Затем можно выполнить, например, команду чтения, которая покажет такие данные, как
00:02:57пользователь и имя базы данных. Мы также можем выполнять SQL-запросы к сайту, чтобы узнать, например,
00:03:03какая версия базы данных используется. И всё это ещё не самое худшее. Вот действительно опасный
00:03:07момент: мы создаём аккаунт администратора с правами на загрузку вредоносного плагина. В данном
00:03:15случае он называется web shell. Это даёт доступ к оболочке сайта, то есть к любому
00:03:22файлу на этом веб-сайте. И эта атака происходит именно так, как мы разбирали ранее в видео.
00:03:27После создания администратора загружается плагин, а затем этот пользователь удаляется. В итоге наличие
00:03:34плагина и сам факт взлома остаются незаметными. Чтобы показать, насколько всё серьёзно, я сделал отдельный скрипт,
00:03:38который создаст админа и оставит его в системе.
00:03:40Вот у меня есть логин и пароль. Возвращаюсь на сайт, перехожу по адресу wp-login, ввожу
00:03:47логин и пароль, нажимаю «Войти» — и теперь у меня есть полный доступ к панель администратора. Если всё это звучит запутанно, не волнуйтесь:
00:03:54мне тоже потребовалось много времени, чтобы разобраться. Утверждается, что получившаяся цепочка эксплойта была настолько
00:04:00сложной, что эксперту по безопасности потребовались бы недели, если не месяцы, чтобы обнаружить её
00:04:05и собрать воедино. Ни один исследователь не смог бы найти и построить эту цепочку
00:04:10за 10 часов без помощи ИИ. И это пугает, ведь злоумышленники могут использовать ботов для сканирования
00:04:17репозиториев и проверки URL в ожидании уязвимостей, чтобы взламывать их в рекордные сроки с помощью ИИ.
00:04:23Один пользователь на Reddit написал, что его сайт взломали всего через два дня после обнаружения бага.
00:04:27А так как они обновляются только по выходным, атакующий успел создать админа и войти. Для тех,
00:04:33кто уязвим: эксплойт исправили в версии 7.0.2, так что обновляйтесь. Но история действительно сумасшедшая.
00:04:40Ссылка на репозиторий и статью, с помощью которых я запускал PoC, будет в комментариях. И почему бы
00:04:46не подписаться на Better Stack, чтобы быть в курсе всех новостей технологий? Надеюсь, вам понравилось, друзья, и,
00:04:50как всегда, увидимся в следующем видео.