Алексей Вдовин (Все сообщения пользователя)

вот я про это и говорю, на сколько я понимаю /upload/tmp/ не есть директория для временного хранения файлов в понятиях PHP
но используется Битриксом как директория для временного хранения файлов (но уже на каком то своём уровне)
сомневаюсь, что её можно вытащить за пределы сайта

хотя могу ошибаться ...

почему Вы так решили?
на сколько я понимаю там несколько другой механизм задействован - т.е. /upload/tmp/ это не = директория хранения временных файлов

по хорошему с интерфеса бы, простому "смертному" зачем знать о таблицах?

если посмотреть исходники, то всё проясняется

if (file_exists(LOCK_FILE)){
 if (!($time = file_get_contents(LOCK_FILE)))
    RaiseErrorAndDie('Can\'t read file: '.LOCK_FILE, 1);

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

судя по информации в статьях из предыдущего поста - с большой долей вероятности вас взломали через уязвимость html_editor_action.php - все симптомы взлом "на лицо"

на сайте, где в данный момент занимаюсь этой проблемой обнаружил тоже самое
"снос" данной папки Вам вообще ничего не даст - это следы взлома, нужно защищать html_editor_action.php либо обновляться

забавно - на мой вопрос, скинули мне решение из моего блога
надо было когда решил вопрос сюда самому запостить  ...

Дак это ж всё - сразу "Привет"
Скрипт будет выполняться от рута, со всеми вытекающими ...

Зачем кому-то это делать?

Алексей Чебанов, Вас оскорбляли?

Так и не понял, чем решение для vps будет отличаться от решения для шаред хостинга

Алексей Чебанов, поясните этот момент . В чем разница?

Какие именно виды атак на свежей сборки прошли?
Какие дыры Вы залатали?

видимо вирусный - на других не взломанных сайтах его не было

он точно вирусный?
не похоже по коду - выглядит как штатный

Гит покажет вам все изменения в файлах, именно это ведь и требуется.

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

Да, гит отличное решение.
Но обычно как раз битриксовый движек исключают из гита, но в данном случае наверное лучше весь сайт (кроме upload и кеша) туда бахнуть.
В принципе можно в исключения всякую статику добавить типа картинок и архивов.

первые сообщения в консоли какие? на что ругается?

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

поищи по вхождению

aHR0cHM6Ly9zdG9yZWpzY2RuLnB3L2pxdWVyeXVpLmpz
и
storejscdn

может тот же файл, только в другом месте иньекция

тут не понял ...  где и что я должен видеть
у меня был такой код и админка поднялась

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

Такая же проблема с админкой

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

но я бы рекомендовал всё таки найти дыру

ну коли Вы так точно знаете время заражения - анализируйте логи, какие скрипты "дёргали" в это время
скорее всего это POST запрос

коли это не ваше - выкидывайте смело

У сайта есть пол?

PS
Обращаться в саппорт либо к специалистам.

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

Сам проект в гите должен быть (для быстрого отлова изменений), плюс можно и ядро в гит запихать (пока не уладится с вируснёй).

как временное и костыльное решение - поставить права на файлы куда иньекция проходит, чтобы под пользователем под которым крутится веб-сервер на было возможности записать
вообще нужно анализировать логи и устранять причину заражения, иначе никак

вообще судя по файлам -  это не через vote, думаю это что то из более раннего