Спам уязвимость сайта через UserPay+PWA инструмент

InstantCMS 2.X
#1 16 декабря 2019 в 21:47
Сегодня обнаружил, что через сайт идут редиректы
78.132.253.255 — - [16/Dec/2019:20:43:32 +0300] "GET /templates/default/controllers/userpay/js/redirect.js HTTP/2.0" 200 5701 "www.dsdnr.ru/sw.js" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36 OPR/65.0.3467.72"
178.120.7.238 — - [16/Dec/2019:20:44:56 +0300] "GET /templates/default/controllers/userpay/js/redirect.js HTTP/2.0" 200 5701 "dsdnr.ru/sw.js" "Mozilla/5.0 (Linux; Android 9; Redmi 7A) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.79 Mobile Safari/537.36"
145.255.1.56 — - [16/Dec/2019:20:45:15 +0300] "GET /templates/default/controllers/userpay/js/redirect.js HTTP/2.0" 200 5701 "www.dsdnr.ru/sw.js" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 YaBrowser/19.10.3.281 Yowser/2.5 Safari/537.36"
109.126.128.218 — - [16/Dec/2019:20:45:50 +0300] "GET /templates/default/controllers/userpay/js/redirect.js HTTP/2.0" 200 5701 "dsdnr.ru/sw.js" "Mozilla/5.0 (Linux; Android 9; Redmi 8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Mobile Safari/537.36"
Отключение компонента UserPay не помогло и я удалил redirect.js, который входит в комплект инсталляции. После этого получил следующие строки в логе
37.79.97.103 — - [16/Dec/2019:20:49:47 +0300] "GET /templates/default/controllers/userpay/js/redirect.js HTTP/2.0" 404 547 "www.dsdnr.ru/sw.js" "Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.79 Safari/537.36"
194.226.8.31 — - [16/Dec/2019:20:49:51 +0300] "GET /templates/default/controllers/userpay/js/redirect.js HTTP/2.0" 404 547 "dsdnr.ru/sw.js" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"
178.44.244.115 — - [16/Dec/2019:20:51:32 +0300] "GET /templates/default/controllers/userpay/js/redirect.js HTTP/2.0" 502 552 "www.dsdnr.ru/sw.js" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36 OPR/65.0.3467.72"
213.222.228.133 — - [16/Dec/2019:20:54:44 +0300] "GET /templates/default/controllers/userpay/js/redirect.js HTTP/2.0" 404 547 "www.dsdnr.ru/sw.js" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 YaBrowser/18.1.1.839 Yowser/2.5 Safari/537.36"
Здесь видно, что НЕКТО получил ошибку 404. Но с той стороны видимо сидит НЕКТО контролирующий процесс и прекрасно знающий Инстант, потому, что далее вижу такие строки в логе
31.173.27.185 — - [16/Dec/2019:21:21:04 +0300] "GET /redirect?url=https://nsportal.ru/detskiy-sad/matematika/2019/03/27/konspekt-zanyatiya-po-femp-tema-shar-i-kub HTTP/1.1" 200 38639 "www.dsdnr.ru/metodraz/224928-plan-konspekt-zanjatija-po-matematike-srednjaja-gruppa-konspekt-zanjatija-po-femp-tema-shar-i.html" "Mozilla/5.0 (iPhone; CPU iPhone OS 12_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/72.0.3626.101 Mobile/15E148 Safari/605.1"
31.173.27.185 — - [16/Dec/2019:21:21:07 +0300] "GET /templates/default/controllers/redirect/styles.css?1525302731 HTTP/1.1" 200 388 "www.dsdnr.ru/redirect?url=https://nsportal.ru/detskiy-sad/matematika/2019/03/27/konspekt-zanyatiya-po-femp-tema-shar-i-kub" "Mozilla/5.0 (iPhone; CPU iPhone OS 12_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/72.0.3626.101 Mobile/15E148 Safari/605.1"
31.173.27.185 — - [16/Dec/2019:21:21:08 +0300] "GET /cache/static/js/scripts.13df3b0f2e313ca24b21bf3746196c53.js?1525302731 HTTP/1.1" 200 65229 "www.dsdnr.ru/redirect?url=https://nsportal.ru/detskiy-sad/matematika/2019/03/27/konspekt-zanyatiya-po-femp-tema-shar-i-kub" "Mozilla/5.0 (iPhone; CPU iPhone OS 12_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/72.0.3626.101 Mobile/15E148 Safari/605.1"
Это говорит, что НЕКТО, знал о включенном объединении CSS и JS и воспользовался КЕШем. После очистки КЕША редиректы прекратились! Забыл добавить, что из настроек Service worker, компонета PWA, удалил строку с подключения файла redirect.js.

Вот так два безобидных компонета стали мостом, через который НЕКТО решил поспамить.

Возможно это не спам, а обычный "наезд" на сайт, но серверу от этого не легче…
#2 17 декабря 2019 в 06:59

Это говорит, что НЕКТО, знал о включенном объединении CSS и JS и воспользовался КЕШем

vikont
Все скрипты сайта записаны в head шаблона.
К ним идут обращение и записываются в access.log в том виде, которые показали выше.

Не пугайте людей, проблему с site.ru/redirect?url=site.com уже обсуждали ранее, решение вроде было в включение или отключении проверки HTTP_REFERER
Ищите тему
#3 17 декабря 2019 в 12:20
В компоненте Редиректы галочки стоят. Другого решения не видел.
Вашим компонентом PWA воспользовались как транспортом, прямой целью был файл redirect.js от UserPay/
Наше сообщество ничем не испугаешь! smile
Увидев такое безобразие, я должен был поделиться со всеми. Вдруг спецы, что то для себя новое узнают и сделают противоядие.
#4 17 декабря 2019 в 13:56

Спамм уязвимость сайта через UserPay+PWA инструмент

vikont
А где вы увидели спам уязвимость собственно? Что в логах навело вас на эту мысль? Вы уверены, что вы правильно читаете логи?

Это говорит, что НЕКТО, знал о включенном объединении CSS и JS и воспользовался КЕШем. После очистки КЕША редиректы прекратились! Забыл добавить, что из настроек Service worker, компонета PWA, удалил строку с подключения файла redirect.js.

vikont

Все скрипты сайта записаны в head шаблона.
К ним идут обращение и записываются в access.log в том виде, которые показали выше.

Evanescence

Именно.

Увидев такое безобразие, я должен был поделиться со всеми.

vikont
Какое?

Вдруг спецы, что то для себя новое узнают и сделают противоядие.

vikont
Я сделал противоядие. Совет. Не делайте то, в чем не разбираетесь.

По итогу вы оговорили указанный вами компонент.
#5 17 декабря 2019 в 15:53

По итогу вы оговорили указанный вами компонент.

Fuze
компонент или компоненты?
#6 17 декабря 2019 в 16:12

Я сделал противоядие

Fuze
Что вы называете противоядием? Чек-бокс Проверять HTTP referer? Так он включен.

По итогу вы оговорили указанный вами компонент

Fuze
Не оговорен ни один компонент, даже не ставил такую цель.

А где вы увидели спам уязвимость собственно? Что в логах навело вас на эту мысль? Вы уверены, что вы правильно читаете логи?

Fuze
Ниже, в главном посте я писал

Возможно это не спам, а обычный "наезд" на сайт, но серверу от этого не легче...

vikont
НЕКТО, позарился на название файла redirect.js и устроил не хилую нагрузку на сервер. Собственно это главное, что я хотел донести до сообщества. И никакие противоядия не помогли пока не применил "грубую силу". Так что без обид. Думаю о таких моментах люди должны знать.
#7 17 декабря 2019 в 16:20

Чек-бокс Проверять HTTP referer? Так он включен.

vikont
Это означает, что при переходе по
  1. https://www.dsdnr.ru/redirect?url=https://nsportal.ru/detskiy-sad/matematika/2019/03/27/konspekt-zanyatiya-po-femp-tema-shar-i-kub
Получим ошибку 404 и поисковики не посчитают, что Ваш сайт якобы ссылается на другой сайт.
Проблем нет.

НЕКТО, позарился на название файла redirect.js и устроил не хилую нагрузку на сервер

vikont
Тогда отключите access log, для чего они нужны? я бы понял если бы error.log включили, но access бесполезная нагрузка и занимает память хостинга
#8 17 декабря 2019 в 17:37

Ниже, в главном посте я писал

vikont
Я в ваших логах кроме как обычное, штатное обращение к файлам, не увидел ничего.

НЕКТО, позарился на название файла redirect.js и устроил не хилую нагрузку на сервер.

vikont
Повторяю свой вопрос, с чего вы это решили? Какая нехилая нагрузка на сервер? В ваших логах обычные запросы, какие и должны быть. Если у вас get запросы к js файлам вызывают нехилую нагрузку, то это вопрос не к CMS точно.
#9 17 декабря 2019 в 18:45

Я в ваших логах кроме как обычное, штатное обращение к файлам, не увидел ничего.

Fuze
Это понятно. Я же не весь лог показал с тысячей (а кто их считал точно) запросов и от множества различных IP числящихся как спамм адреса. И все это в небольшой промежуток времени.

Какая нехилая нагрузка на сервер?

Fuze
Когда прекратил эти запросы, сервер вздохнул. Такого раньше просто не было. как будто какой то автомат работал…
Впрочем, я понимаю, что для более мощных серверов это семечки не стоящие внимания, но при моем минимализме (4 ядра по 3ггц и 7 гб оперативки) это было заметно.
#10 17 декабря 2019 в 19:45

с тысячей (а кто их считал точно) запросов и от множества различных IP числящихся как спамм адреса. И все это в небольшой промежуток времени.

vikont
Спам — одна "м" на конце smile

И все это в небольшой промежуток времени.

vikont
Так проблема не с этими файлами. А с редиректом. О чем в логах у вас и написано. Рефер к этим файлам (как и к другим вашим js и css файлам) со страницы переадресации. Указанные строки в приведённой вами выдержке из логов НЕ показывают, что имеются редиректы, инициированные указанными вами компонентами. Отключите компонент "Редиректы" и будет вам счастье.

но при моем минимализме (4 ядра по 3ггц и 7 гб оперативки) это было заметно.

vikont
Это неплохая конфигурация. Вы бы поменьше читали сомнительные статьи по увеличению производительности сервера, типа phpfpm и прочего. И если не верите мне, то хотя бы просто прочитайте те же интервью разработчика Nginx.
Запросы к статичным файлам Nginx обрабатывает мгновенно и в огромных количествах. Но как у вас настроено, никто не знает. Чем меряете/отслеживаете нагрузку?

www.dsdnr.ru/sw.js

vikont
Кстати, что это за файл?

p.s. на сайт ваш зайти невозможно
#11 17 декабря 2019 в 20:35

Чем меряете/отслеживаете нагрузку?

Fuze
Для этого у панели Brainy есть мониторы, например этот типа бара

Кстати, что это за файл?

Fuze
www.dsdnr.ru/sw.js — это файл создает PWA инструмент.(Progressive Web Apps для InstantCMS)

p.s. на сайт ваш зайти невозможно

Fuze
Есть такое дело, то ли сам малость накосячил, то ли "помогли", сижу исправляю. Сейчас заработает
#12 17 декабря 2019 в 23:51

Для этого у панели Brainy есть мониторы, например этот типа бара

vikont
Это пять. Т.е. вы даже не выяснили что давало нагрузку.

то ли сам малость накосячил

vikont
Есть сомнения? joke
#13 18 декабря 2019 в 00:02

Это пять. Т.е. вы даже не выяснили что давало нагрузку.

Fuze
Конечно выяснял, описанное в посте, это часть общей нагрузки (тем более что проявилось сразу как только убрал файл). Нагрузка упала сразу на 25-30%. Есть и другие причины… редиректят мне один домен по черному, так же много спамеров и левых ботов...
Если честно, то иногда мне сложно выявить, что именно валит сервер. Приходится действовать методом исключения.

Кой какие меры по защите сервера я предпринял, особенно после последнего случая. Соберусь с духом, опубликую все наработки и находки. Возможно всем сообществом сможем усовершенствовать…
#14 18 декабря 2019 в 00:10

Если честно, то иногда мне сложно выявить, что именно валит сервер.

vikont
Откройте для себя консоль и команды top/htop, iotop и подобные.

Приходится действовать методом исключения.

vikont
Этот метод (метод научного тыка) крайне плохой в данном случае.
#15 18 декабря 2019 в 00:47

Соберусь с духом, опубликую все наработки и находки.

vikont
Стойте!
Вы не можете отвечать в этой теме.
Войдите или зарегистрируйтесь, чтобы писать на форуме.
Используя этот сайт, вы соглашаетесь с тем, что мы используем файлы cookie.