Комментарии 28
Как вариант — закрыть на basic auth доступ к этому скрипту. А лучше ко всей админ-зоне.
Выглядит примерно так:
location ~ \.php$ {
location ~ ^/wp-admin/ {
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
}
...
}
с целью усугубить проблему, basic auth как нельзя лучше подойдет, а так не лучше так не делать, а так вобще лучше никогда не закрывать admin-ajax.php от внешних запросов
Не делать как? Обновлять версию сайта до последней актуальной?
Автор пишет, что у него 5.1
Только как у него актуальная 5.1 и он обновляет постоянно — это закадка…
Автор пишет, что у него 5.1
On March 13, 2019, WordPress 5.1.1 was released to the public.
Только как у него актуальная 5.1 и он обновляет постоянно — это закадка…
Все выходящие обновления для движка, плагина и темы устанавливаются вовремя. Плагины только из официального репозитория, тема тоже.
а так вобще проблема в этом WP Security Audit Log плагине как уже ниже написали, и он как не прискорбно лежит в в официальном репозитории вот — plugins.trac.wordpress.org/browser/wp-security-audit-log/trunk/sdk/freemius/includes/class-freemius.php#L3060 просто удалить WP Security Audit Log и никогда его не ставить поможет
Конечно нужно постоянно обновлять плагины и ставить обновления ядра сразу же после выхода, хоть в данном случае это и не спасет все же делать это нужно всегда потому что сэкономить много времени и нервов в дальнейшем.
А еще вот так
лучше всего вобще никогда не делать ибо плагины и темы часто обращаются к wp-admin/ admin-ajax.php из своих яваскиптов, и скажем к примеры если закрыть этот файл авторизацией могут не запросто перестать работать такие вещи как формы заказа, обратной связи комментарии и вобще что угодно, причем админ сайта скорее всеговведет пароль и не заметит проблем в то время посетители увидят поломанный сайт. Плохо что авторы таких крутых в кавычках советов этого не понимают. Это вобще худшее что можно посоветовать
А еще вот так
location ~ \.php$ {
location ~ ^/wp-admin/ {
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
}
...
}лучше всего вобще никогда не делать ибо плагины и темы часто обращаются к wp-admin/ admin-ajax.php из своих яваскиптов, и скажем к примеры если закрыть этот файл авторизацией могут не запросто перестать работать такие вещи как формы заказа, обратной связи комментарии и вобще что угодно, причем админ сайта скорее всеговведет пароль и не заметит проблем в то время посетители увидят поломанный сайт. Плохо что авторы таких крутых в кавычках советов этого не понимают. Это вобще худшее что можно посоветовать
Пост был в песочнице, написан был в марте. За актуальными версиями слежу, постоянно обновляют.
Аналогично. Но вот сайт кладут стабильно раз в неделю. Несколько подзадолбало
ну что можно сказать, всему виной легаси и варезные плагины и темы обычно )) (хотя в статье описан не такой сценарий заражения) нужно избавляться от сомнительного кода если совсем нет возможности разбираться с этим можно на pressjitsu.com переехать, там сам хостер следит за такими инцидентами, может поможет в данной ситуации. А так только газами просматривать все обновления и код плагинов даже если они из проверенных источников, к несчастью иного пока не дано
Для начала попробуйте переопределить ajax функцию на этот action fs_set_db_option
Как бороться, кроме как выключить регистрацию и удалить подозрительных пользователей – решения пока не нашел.
Отказаться от WordPress? Честно говоря, совершенно не понимаю его использования в современных реалиях для хоть сколь-нибудь крупного и важного проекта. Критические уязвимости обнаруживаются с регулярностью, которой можно только позавидовать. Вся система в целом — отличный пример собрания худших практик.
Не холивара ради, но я правда этого совершенно не могу понять
Какая к черту уязвимость ядра WordPress и чистая инсталляция, это же бага sdk под freenius — https://github.com/Freemius/wordpress-sdk/blob/master/templates/debug.php.
Ищите по названию события fs_set_db_option.
Вы бы хоть разобрались в сути вопроса. Хайпануть хотели нахаляву)))
Сейчас проверил логи пары инстансов WP — запросы с fs_set_db_option идут достаточно массово, с разными кандидатами на siteurl, но паттерн один:
https://{hostname}/{file}.js?someparam=1&
Использования данного SDK в лице уязвимого класса на инстансах не нашел (find. -name 'class-freemius.php', подставьте путь по выбору), но выдал команду админам смотреть в оба.
https://{hostname}/{file}.js?someparam=1&
Использования данного SDK в лице уязвимого класса на инстансах не нашел (find. -name 'class-freemius.php', подставьте путь по выбору), но выдал команду админам смотреть в оба.
Прочитай внимательно то что по ссылке xsash поймёшь откуда ноги растут у уязвимости и как бороться
Прочитал. Нашел уязвимую функцию:
Беглый греп Freemius нашел ее в файле, упомянутом выше. Далее, git blame этого файла легко находит фикс:
github.com/Freemius/wordpress-sdk/commit/7ec1932961e51c14f4ec4b8e0381f6d74f7b3a0b#diff-47823070110c192139bd0d3591110cbb
Т.к. уязвимость была найдена и исправлена в этом файле, можно считать, что отсутствие данного файла может говорить об неиспользовании данного SDK как минимум в уязвимой к данной проблеме версии. Таким образом, бороться не с чем.
Не могли бы вы пояснить, что имелось в виду в вашем комментарии?
static function _set_db_option()Беглый греп Freemius нашел ее в файле, упомянутом выше. Далее, git blame этого файла легко находит фикс:
github.com/Freemius/wordpress-sdk/commit/7ec1932961e51c14f4ec4b8e0381f6d74f7b3a0b#diff-47823070110c192139bd0d3591110cbb
Т.к. уязвимость была найдена и исправлена в этом файле, можно считать, что отсутствие данного файла может говорить об неиспользовании данного SDK как минимум в уязвимой к данной проблеме версии. Таким образом, бороться не с чем.
Не могли бы вы пояснить, что имелось в виду в вашем комментарии?
Struam, вы не желаете исправить пост и заголовок в соответствии с комментариями? Вы вводите людей в заблуждение.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Критическая уязвимость в admin-ajax.php