Важно отметить, что использование этой уязвимости является незаконным, если только у вас нет разрешения владельца веб-сайта.
В платформе WordPress CMS была обнаружена простая, но очень серьезная уязвимость, связанная с атаками типа «отказ в обслуживании» (DoS) на уровне приложений, которая позволяет любому пользователю приводить в нерабочее состояние большинство веб-сайтов WordPress даже с помощью одной машины. Происходит это без необходимости задействовать огромное количество компьютеров для переполнения полосы пропускания, как это требуют DDoS-атаки, но с достижением того же результата.
Поскольку WordPress Foundation отказали в исправлении проблемы, уязвимость (CVE-2018-6389) остается без патча и затрагивает почти все версии WordPress, выпущенные за последние девять лет, включая последнюю стабильную (WordPress версия 4.9.2).
Barak Tawily, израильский исследователь в области безопасности, обнаружил уязвимость, суть которой заключается в том, что «load-scripts.php», встроенный скрипт в WordPress CMS, обрабатывает и пользовательские запросы.
По задумке разработчиков, файл load-scripts.php предназначен только для администраторов и создан, чтобы помочь сайту повысить производительность и загрузить страницу быстрее, объединив (на сервере) несколько файлов JavaScript в один запрос.
Однако, чтобы «load-scripts.php» работал на странице входа администратора (wp-login.php) до входа в систему, разработчики WordPress не предусматривают механизма аутентификации, в результате чего функция доступна для всех.
В зависимости от плагинов и модулей, которые вы установили, файл load-scripts.php выборочно вызывает необходимые файлы JavaScript, передавая их имена в параметр «load», разделяемые запятой, например, следующий URL-адрес:
https://your-wordpress-site.com/wp-admin/load-scripts.php?c=1&load=editor,common,user-profile,media-widgets,media-galleryПри загрузке веб-сайта «load-scripts.php» пытается найти каждое имя JavaScript-файла, указанное в URL-адресе, добавить его содержимое в один файл и затем отправить в браузер пользователя.
Как работает WordPress DoS Attack
По словам исследователя, можно заставить load-scripts.php вызывать все возможные файлы JavaScript (всего 181 скрипт) за один проход, передавая их имена в указанном выше URL-адресе. Это сделает работу целевого сайта немного медленнее, потребовав высоких затрат со стороны процессора и памяти сервера.
«Существует четко определенный список ($ wp_scripts), который может быть запрошен пользователями как часть параметра load []. Если запрошенное значение существует, сервер выполнит необходимые операции чтения ввода-вывода», — говорит Tawily.Хотя одного запроса было бы недостаточно, чтобы «положить» весь сайт для всех посетителей, Tawily использовал сценарии на python для создания proof-of-concept (PoC). Созданный им doser.py делает большое количество одновременных запросов на один и тот же URL в попытке использовать как можно больше ресурсов CPU сервера и свести к минимуму доступные для других пользователей ресурсы.
Hacker News проверила подлинность DoS-эксплойта, успешно «положив» один из демо-сайтов WordPress, работающих на VPS среднего размера.
«load-scripts.php не требует никакой аутентификации, любой анонимный пользователь может это сделать. После около 500 запросов сервер больше не отвечал или возвратил статус 502/503/504 ошибок в коде, — говорит Tawily.Тем не менее, атаки с одной машины с подключением до 40 Мбит/с было недостаточно, чтобы вызвать отказ в обслуживании у еще одного демонстрационного веб-сайта, работающего на выделенном сервере с высокой вычислительной мощностью и большим объемом памяти.
Это не означает, что недостаток не эффективен против веб-сайтов WordPress, работающих на мощном сервере, так как атака на уровне приложений обычно требует гораздо меньшего количества пакетов и пропускной способности для достижения цели злоумышленников.
Таким образом, хакеры с большей пропускной способностью канала связи или несколькими ботами могут использовать эту уязвимость, чтобы атаковать большие и популярные веб-сайты WordPress.
Патча нет — Руководство по смягчению последствий
Наряду с полным раскрытием Tawily также предоставил видео-демонстрацию атаки. Вы можете посмотреть видео, чтобы увидеть атаку в действии.
Зная, что уязвимости DoS выходят за рамки bug bounty program для WordPress, Tawily ответственно сообщил об этой DoS-уязвимости команде WordPress через платформу HackerOne.
Однако компания отказалась признать эту проблему, заявив, что такая ошибка находится вне контроля WordPress и «должна смягчаться на уровне сервера или на сетевом уровне, а не на уровне приложения».
Уязвимость кажется серьезной, потому что около 29% сайтов в Интернете используют WordPress. Это делает миллионы сайтов уязвимыми для хакеров и потенциально недоступными для своих пользователей.
Для сайтов, которые не могут позволить себе услуги, предлагающие защиту от атак на уровне приложения, исследователь предоставил WordPress forked version, которая содержит патч этой уязвимости. Тем не менее, следует учитывать риски установки модифицированной CMS, даже если вы считаете источник надежным. Помимо этого, исследователь также выпустил простой bash-сценарий, который исправляет проблему в уже установленном WordPress.
Комментарии (39)
ilyaplot
05.02.2018 17:57+3Сразу после установки WP надо изменить путь к wp-admin. Это первая строчка в азбуке по WP.
vovasik
06.02.2018 11:23Это первая строчка в азбуке по WP.
я так полагаю и пруф есть на азбуку? Прямо так на чистом британском называется с большой буквы «Азбука» наверное.
Выше написали
Хотя если в ссылках есть что-то типа "/xxxxxxxxxxx", то не поможет. Наверное, это и подразумевалось под «захардкорено»?
потому что не надо раздавать советы патчить вендорные библиотеки если особенно в этом не разбираешься, тем более параллельно выдумывать источники где это рекомендуется.
Basic auth тоже не спасет потому что вот допустим закрыл я им доступ к каталогу /wp-admin/ и сразу же поломаются все ajax запросы на сайте ибо для них точкой входа служит/wp-admin/admin-ajax.phpи самое прекрасное что будучи админом послушав такого ценного совета я скорее всего пароль сразу введу и сайт только для пользователей поломается, админ будучи авторизованным и не заметит, можно конечно все понять правильно и закрыть доступ ко всем файлам за исключением admin-ajax.php но это тоже не серебряная пуля ибо все равно есть предпосылки для возможных проблем и вводить два пароля минимум ниже человеческого достоинства. Надеюсь в Cloud4Y так не сделано.
И я бы еще понял если бы такие советы давали в кометах на фейсбуке или вконтаче но никак не на хабре при этом многие комменты заплюсовали, единственное нормальное решение которое бы стоило бы упомянуть это настроить fail2ban никто не вспомнил, хотя настроить его чуть ли не проще чем Basic auth прикрутить и он точно спасет от ддоса одной машиной, cloudflare тоже никто не догадался посоветовать )) В качестве совета, если вдруг кается что в интернете ты умнее всех со своим костыльными решениями то сходи в места где общаются профессионалы в этой конкретной области будь то сисадмины или разработчики не важно и это быстро пройдет
castomi
06.02.2018 12:15Согласен с Вами, я лично только доступ по параметру делаю в админку для авторизации, не закрывая все эти файлы. Кстати там выложили вроде как решение которое правит файлы wp для устранения уязвимости, Вы пробовали это? Я пока думаю как это решить, но планировал прикрывать на уровне сервера, а тут увидел в конце статьи ссылочку на исправление.
vovasik
06.02.2018 12:21ну баш то башем )) на уровне сервера все же лучше решать такие проблемы, сделал и забыл )) каждый раз когда прилетело обновление баш дергать что-ли
castomi
08.02.2018 11:02Да я как бы сам такого мнения), я вообще серверщик, не программер). Так решил уточнить, может у Вас будет другое мнение. Вдруг конкретно эти файлы к примеру очень редко подвержены обновлениям.
vovasik
08.02.2018 11:12Ну так CDN самое простое решение в лоб cloudflare там какой нибудь, наверняка может закешировать ответ и от одной машины точно сайт не ляжет)) а так уже за те пару дней что я пишу эти комменты wordpress дважды выпустил обновления, будь я администратором пары десятков сайтов, уже бы замучился проверять не сломалось ли чего
SirEdvin
05.02.2018 18:08+2Мне кажется, больше 50% сайтов в интернете можно положить просто запросами с одного компьютера…
pyrk2142
05.02.2018 18:43+1Вообще, есть сейчас довольно забавная проблема, когда существует очень много сервисов, которые скачивают файлы по ссылкам, делают превью, разные документы и тому подобное. Если правильно применять эти сервисы, то можно запрашивать файлы с атакуемого сервера с очень большой скоростью и загружать несколько CPU. Мой рекорд на тестовом сервере — 2.5 гигабит в секунду. После исправлений по Bug Bounty собираюсь опубликовать детали, хотя сама идея известная и довольно простая.
zemavo
06.02.2018 00:40Есть статья от ValdikSS об этом — DDoS любого сайта с использованием заметок Facebook
drinkmaker
06.02.2018 03:35Таблицы Гугл тоже так умеют.
Пишем в ячейку
SomeSite.ru?v=1
Протягиваем вниз, что бы получилось
SomeSite.ru?v=2
SomeSite.ru?v=3
SomeSite.ru?v=n
И вуаля, сервера гугл ддосят сайт.
Чисто гипотетически.
pyrk2142
06.02.2018 14:46Да, примерно так и есть. Сейчас есть список из 50+ разных крупных сервисов, которые позволяют сделать нечто подобное.
stas404
08.02.2018 02:20Огласите весь список, пожалуйста
pyrk2142
08.02.2018 16:48Подожду исправления или ответа от компаний, что не считают это проблемой, тогда уже напишу статью.
stas404
08.02.2018 20:41Ok. Но вообще такой трафик же легко отсечь. Например, с google-таблиц приходит
«Mozilla/5.0 (compatible) Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)»
Прогнал около 50000 запросов — основных айпишников с которых идут запросы 3-4.
zxxc
06.02.2018 07:53Я думаю что треть сайтов можно и не на вордпресе положить, просто дергая самые долгие запросы в параллель.
К примеру домашнюю страницу с рандомной частью в урле.
И еще какой-то процент сайтов будет больше денег списывать за хостинг
На одном из проектов делали нагрузочное тестирование в 500 потоков с одной виртулаки
Время ответов вырастало с секунд до десятков секунд. А ждать 20-30 секунд ответа от сайта будет на порядок меньше людей
Причем на 5хх может быть нотификация у админа
А на падении аудитории с дневных 1000 человек на ночные 100 в середине рабочего дня далеко не у всех админов
Да и отдел продаж, к примеру, инет магазина далеко не сразу начнет волноваться
Общее положение с безопасностью очень грустное
arsenenko
06.02.2018 07:53А вторая половина движки вообще не обновляет как были подняты на версии WP-4.0
так и все ок
trigun117
06.02.2018 07:53Главное открестится от всего и сказать, что это должно решатся на сетевом уровне или на уровне сервера
Loki3000
06.02.2018 10:31Гм… а результат этой сборки не кэшируется разве после первого запроса?
remzalp
06.02.2018 12:35подозреваю, кэш можно будет обойти поменяв порядок имен файлов в ссылке, даже если он реализован.
Сколько перестановок у 181 имён файлов? :)Loki3000
06.02.2018 12:39Я тоже об этом в первую очередь подумал, но не смог сходу придумать варианта, когда одни и те же js файлы должны подключаться в разном порядке на разных страницах. Так что при составлении ключа кэша названия вполне можно отсортировать.
Alex7Kom
06.02.2018 13:03Даже если сочетать за раз, например, 170 из 181 возможных, без повторений, и считать одинаковыми те, где меняется только порядок, это все равно огромное число.
jMas
06.02.2018 13:12Можно, только нужно учитывать, что порядок имен может иметь значение (например наличие зависимостей), поэтому это может быть вредным — составление хэш-ключа по отсортированному списку.
Loki3000
06.02.2018 13:17Так на порядок элементов в кэшированном файле эта сортировка не влияет — названия сортируются только при генерации ключа.
Но, в общем-то, решением это действительно не является, так как требует от атакующего совсем немного изобретательности.jMas
07.02.2018 02:58То есть, допустим на входе "c,b,a" и "a,c,b"… сортируем и получим "a,b,c" от которого и возьмем хэш — для двух вариантов одинаковый хэш?
LexX80
06.02.2018 12:48Как раз думаю как сделать броньку для своих серверов по анализу входящих логов, т.е. если «пассажир» пришел не по стандартному маршруту или идет перебор левых путей, то вышеозначенный «пассажир» добавляется в список для редиректа ошибку 503 или еще куда, если хочет повалить сервер путь думает что сделал. Правда есть много камней, которые я еще не увидел. База с адресами для нескольких серверов одна. Анализ интенсивности нападок, а тем более нападок на несколько своих серверов будет приводить к длительному отлучению от своих ресурсов. Основной косяк, который я пока вижу — медленная реакция на нападку, но думаю и это тоже решится. Может кто предложит что по-лучше?
pyrk2142
06.02.2018 14:52Думали о некой «бомбе» против таких сайтов. Сайт А размещает на своих страницах JS код или ещё что-то (генерация запросов с помощью картинок, стилей, скриптов), что вызывает кучу подозрительной активности на сайте конкурента — пользователь банится на сайте конкурента/конкурентов. Если пытается пойти к конкурентам, то видит ошибку/сообщение о бане и уходит.
LexX80
06.02.2018 15:09Весь прикол в том что анализируя логи сервера я заметил что в логах один ip адрес дергает 1-3 ссылки и на большенстве ресурсов под моей ответственностью, вот только ip адресов которые «щупают» сайт\сервер — много, очень походит на обширную бот сеть с управлением. Можно конечно и на фаерволе килять любую активность с серых адресов, но не всегда удобно. Вариант прикинуться «жмуриком» для меня показался лучшим. Хотя только время сможет показать правильность решения.
zxxc
06.02.2018 17:30К — конкуренция. :))
А вы не демали продукт лучше сделать?
Или процесс оптимизировать?
Или ускорить изготовление? Или хотя бы маркетинг провести почему другой сайт лучше вашего?
Мне кажется в долгосрочной перспективе можно достичь лучших результатов и не потерять «лицо» перед клиентамиpyrk2142
08.02.2018 16:51К счастью, я таким не занимаюсь) Это, скорее, концепция достаточно странного способа (хотя, мне рассказывали, что некоторые сайты использовали что-то подобное, плюс завал СМС).
EjIlay
скрипт для админки? Basic auth спасет
aPiks
Зачем? Перепишите путь к папке админа и всё. Это вообще первое, что надо делать после установки WP.
Alexufo
Она же захардкорена в ядре, красиво это не делается
vitaliy2
Ну запретить тогда просто доступ к этому пути, а открыть доступ по другому пути, перенаправляющим на старый путь (рирайтами, симлинками, try_files, etc). Хотя если в ссылках есть что-то типа "/xxxxxxxxxxx", то не поможет. Наверное, это и подразумевалось под «захардкорено»?
Alexufo
После basic auth у вас на фронтенде вылезут окошки с просьбой ввести пароль, потому что аякс делает туда запросы.
EjIlay
а браузер не запомнит заголовок авторизации для последующих запросов?
Alexufo
Если вывесить обьявление для посетителей сайта с просьбой вводить этот логин и пароль, то зампомнит конечно. От гостя же запросы тоже идут.
EjIlay
Не знал, исходил из текста статьи
Alexufo
в папке wp-admin не только load-scripts.php лежит, так же и admin-ajax.php к котрому идет аякс от гостя. Не знаю как на голом движке, но с плагинами безопасности или с какими то еще точно вываливается запрос на ввод пароля гостям. Так бы давно бы все позакрывали… эх.