29% вебсайтов уязвимы для DOS-атаки даже одной машиной (CVE-2018-6389)

https://thehackernews.com/2018/02/wordpress-dos-exploit.html
  • Перевод


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

В платформе 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.
Cloud4Y 250,94
#1 Корпоративный облачный провайдер
Поделиться публикацией
Комментарии 42
  • 0
    скрипт для админки? Basic auth спасет
    • +1
      Зачем? Перепишите путь к папке админа и всё. Это вообще первое, что надо делать после установки WP.
      • 0
        Она же захардкорена в ядре, красиво это не делается
        • 0
          Ну запретить тогда просто доступ к этому пути, а открыть доступ по другому пути, перенаправляющим на старый путь (рирайтами, симлинками, try_files, etc). Хотя если в ссылках есть что-то типа "/xxxxxxxxxxx", то не поможет. Наверное, это и подразумевалось под «захардкорено»?
      • 0
        После basic auth у вас на фронтенде вылезут окошки с просьбой ввести пароль, потому что аякс делает туда запросы.
        • 0
          а браузер не запомнит заголовок авторизации для последующих запросов?
          • 0
            Если вывесить обьявление для посетителей сайта с просьбой вводить этот логин и пароль, то зампомнит конечно. От гостя же запросы тоже идут.
            • 0
              По задумке разработчиков, файл load-scripts.php предназначен только для администраторов…

              Не знал, исходил из текста статьи
              • 0
                в папке wp-admin не только load-scripts.php лежит, так же и admin-ajax.php к котрому идет аякс от гостя. Не знаю как на голом движке, но с плагинами безопасности или с какими то еще точно вываливается запрос на ввод пароля гостям. Так бы давно бы все позакрывали… эх.
      • +2
        Сразу после установки WP надо изменить путь к wp-admin. Это первая строчка в азбуке по WP.
        • +4
          Это первая строчка в азбуке по WP.
          я так полагаю и пруф есть на азбуку? Прямо так на чистом британском называется с большой буквы «Азбука» наверное.
          Выше написали
          Хотя если в ссылках есть что-то типа "/xxxxxxxxxxx", то не поможет. Наверное, это и подразумевалось под «захардкорено»?

          потому что не надо раздавать советы патчить вендорные библиотеки если особенно в этом не разбираешься, тем более параллельно выдумывать источники где это рекомендуется.

          Basic auth тоже не спасет потому что вот допустим закрыл я им доступ к каталогу /wp-admin/ и сразу же поломаются все ajax запросы на сайте ибо для них точкой входа служит /wp-admin/admin-ajax.php и самое прекрасное что будучи админом послушав такого ценного совета я скорее всего пароль сразу введу и сайт только для пользователей поломается, админ будучи авторизованным и не заметит, можно конечно все понять правильно и закрыть доступ ко всем файлам за исключением admin-ajax.php но это тоже не серебряная пуля ибо все равно есть предпосылки для возможных проблем и вводить два пароля минимум ниже человеческого достоинства. Надеюсь в Cloud4Y так не сделано.

          И я бы еще понял если бы такие советы давали в кометах на фейсбуке или вконтаче но никак не на хабре при этом многие комменты заплюсовали, единственное нормальное решение которое бы стоило бы упомянуть это настроить fail2ban никто не вспомнил, хотя настроить его чуть ли не проще чем Basic auth прикрутить и он точно спасет от ддоса одной машиной, cloudflare тоже никто не догадался посоветовать )) В качестве совета, если вдруг кается что в интернете ты умнее всех со своим костыльными решениями то сходи в места где общаются профессионалы в этой конкретной области будь то сисадмины или разработчики не важно и это быстро пройдет
          • 0
            Согласен с Вами, я лично только доступ по параметру делаю в админку для авторизации, не закрывая все эти файлы. Кстати там выложили вроде как решение которое правит файлы wp для устранения уязвимости, Вы пробовали это? Я пока думаю как это решить, но планировал прикрывать на уровне сервера, а тут увидел в конце статьи ссылочку на исправление.
            • +1
              ну баш то башем )) на уровне сервера все же лучше решать такие проблемы, сделал и забыл )) каждый раз когда прилетело обновление баш дергать что-ли
              • 0
                Да я как бы сам такого мнения), я вообще серверщик, не программер). Так решил уточнить, может у Вас будет другое мнение. Вдруг конкретно эти файлы к примеру очень редко подвержены обновлениям.
                • 0
                  Ну так CDN самое простое решение в лоб cloudflare там какой нибудь, наверняка может закешировать ответ и от одной машины точно сайт не ляжет)) а так уже за те пару дней что я пишу эти комменты wordpress дважды выпустил обновления, будь я администратором пары десятков сайтов, уже бы замучился проверять не сломалось ли чего
        • +6
          Мне кажется, больше 50% сайтов в интернете можно положить просто запросами с одного компьютера…
          • +2
            Вообще, есть сейчас довольно забавная проблема, когда существует очень много сервисов, которые скачивают файлы по ссылкам, делают превью, разные документы и тому подобное. Если правильно применять эти сервисы, то можно запрашивать файлы с атакуемого сервера с очень большой скоростью и загружать несколько CPU. Мой рекорд на тестовом сервере — 2.5 гигабит в секунду. После исправлений по Bug Bounty собираюсь опубликовать детали, хотя сама идея известная и довольно простая.
              • +2
                Таблицы Гугл тоже так умеют.
                Пишем в ячейку
                SomeSite.ru?v=1
                Протягиваем вниз, что бы получилось
                SomeSite.ru?v=2
                SomeSite.ru?v=3
                SomeSite.ru?v=n
                И вуаля, сервера гугл ддосят сайт.
                Чисто гипотетически.
                • 0
                  Да, примерно так и есть. Сейчас есть список из 50+ разных крупных сервисов, которые позволяют сделать нечто подобное.
                  • 0
                    Огласите весь список, пожалуйста
                    image
                    • 0
                      Подожду исправления или ответа от компаний, что не считают это проблемой, тогда уже напишу статью.
                      • 0
                        Ok. Но вообще такой трафик же легко отсечь. Например, с google-таблиц приходит
                        «Mozilla/5.0 (compatible) Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)»
                        Прогнал около 50000 запросов — основных айпишников с которых идут запросы 3-4.
                        • 0
                          В целом да, это не универсальное средство. Опасно для небольших сайтов с ограничениями на ресурсы, так как позволяет легко загонять их в блокировку, сервисов со слабыми админами и для маскировки, если кто-то выполняет платные для хостинга запросы, вроде отправки СМС. Сейчас такая ситуация, что злоумышленнику для того, чтобы сгенерировать несколько гигабит трафика, не нужно ничего, кроме браузера и чего-то вроде Charles.
              • +1
                Я думаю что треть сайтов можно и не на вордпресе положить, просто дергая самые долгие запросы в параллель.
                К примеру домашнюю страницу с рандомной частью в урле.
                И еще какой-то процент сайтов будет больше денег списывать за хостинг
                На одном из проектов делали нагрузочное тестирование в 500 потоков с одной виртулаки
                Время ответов вырастало с секунд до десятков секунд. А ждать 20-30 секунд ответа от сайта будет на порядок меньше людей
                Причем на 5хх может быть нотификация у админа
                А на падении аудитории с дневных 1000 человек на ночные 100 в середине рабочего дня далеко не у всех админов
                Да и отдел продаж, к примеру, инет магазина далеко не сразу начнет волноваться
                Общее положение с безопасностью очень грустное
                • +1
                  А вторая половина движки вообще не обновляет как были подняты на версии WP-4.0
                  так и все ок
                  • 0

                    Главное открестится от всего и сказать, что это должно решатся на сетевом уровне или на уровне сервера

                    • 0
                      Гм… а результат этой сборки не кэшируется разве после первого запроса?
                      • 0

                        подозреваю, кэш можно будет обойти поменяв порядок имен файлов в ссылке, даже если он реализован.
                        Сколько перестановок у 181 имён файлов? :)

                        • 0
                          Я тоже об этом в первую очередь подумал, но не смог сходу придумать варианта, когда одни и те же js файлы должны подключаться в разном порядке на разных страницах. Так что при составлении ключа кэша названия вполне можно отсортировать.
                          • +1
                            Даже если сочетать за раз, например, 170 из 181 возможных, без повторений, и считать одинаковыми те, где меняется только порядок, это все равно огромное число.
                            • 0

                              Можно, только нужно учитывать, что порядок имен может иметь значение (например наличие зависимостей), поэтому это может быть вредным — составление хэш-ключа по отсортированному списку.

                              • 0
                                Так на порядок элементов в кэшированном файле эта сортировка не влияет — названия сортируются только при генерации ключа.
                                Но, в общем-то, решением это действительно не является, так как требует от атакующего совсем немного изобретательности.
                                • 0

                                  То есть, допустим на входе "c,b,a" и "a,c,b"… сортируем и получим "a,b,c" от которого и возьмем хэш — для двух вариантов одинаковый хэш?

                        • 0
                          Как раз думаю как сделать броньку для своих серверов по анализу входящих логов, т.е. если «пассажир» пришел не по стандартному маршруту или идет перебор левых путей, то вышеозначенный «пассажир» добавляется в список для редиректа ошибку 503 или еще куда, если хочет повалить сервер путь думает что сделал. Правда есть много камней, которые я еще не увидел. База с адресами для нескольких серверов одна. Анализ интенсивности нападок, а тем более нападок на несколько своих серверов будет приводить к длительному отлучению от своих ресурсов. Основной косяк, который я пока вижу — медленная реакция на нападку, но думаю и это тоже решится. Может кто предложит что по-лучше?
                          • 0
                            Думали о некой «бомбе» против таких сайтов. Сайт А размещает на своих страницах JS код или ещё что-то (генерация запросов с помощью картинок, стилей, скриптов), что вызывает кучу подозрительной активности на сайте конкурента — пользователь банится на сайте конкурента/конкурентов. Если пытается пойти к конкурентам, то видит ошибку/сообщение о бане и уходит.
                            • 0
                              Весь прикол в том что анализируя логи сервера я заметил что в логах один ip адрес дергает 1-3 ссылки и на большенстве ресурсов под моей ответственностью, вот только ip адресов которые «щупают» сайт\сервер — много, очень походит на обширную бот сеть с управлением. Можно конечно и на фаерволе килять любую активность с серых адресов, но не всегда удобно. Вариант прикинуться «жмуриком» для меня показался лучшим. Хотя только время сможет показать правильность решения.
                              • 0
                                К — конкуренция. :))
                                А вы не демали продукт лучше сделать?
                                Или процесс оптимизировать?
                                Или ускорить изготовление? Или хотя бы маркетинг провести почему другой сайт лучше вашего?
                                Мне кажется в долгосрочной перспективе можно достичь лучших результатов и не потерять «лицо» перед клиентами
                                • 0
                                  Да уж, с такими подходами 50% доли амазона будет только началом.
                                  • 0
                                    К счастью, я таким не занимаюсь) Это, скорее, концепция достаточно странного способа (хотя, мне рассказывали, что некоторые сайты использовали что-то подобное, плюс завал СМС).
                                • 0

                                  Плюнул, нарисовал кастомную конфигурацию ф2бан. в пике атаки в iptables в правиле висело под сотню адресов.
                                  И это при том, что самый посещаемый сайт на том сервере генерировал около 10-20 гигабайт трафика в месяц на ответах

                                • 0
                                  Это просто фиаско!!! по поводу сайтов
                                  Если делаешь то двежки обновляй и обновляй ТЗИ
                                  Просто взялся работай бери =D

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

                                  Самое читаемое