Непереодическое удаление php файлов из корня сайта - Joomla 1.5: Установка и обновление

Обращаюсь к коллегам с нетипичной проблемой.
Настроил проект на локалке, всё работало замечательно. Перенёс на тестовый полигон (хостер infobox.ru)
И начал замечать странную особенность: время от времени (т.е. без переодичности, чтобы можно было говорить о срабатывании червя в заданное время), при навигации по сайту, удаляются все php файлы в корне:
CHANGELOG.php
configuration.php
COPYRIGHT.php
CREDITS.php
index.php
index2.php
LICENSES.php

Что самое немаловажное: в логах сервера пусто. На запрос служба поддержки хостинга дала ответ следующего содержания: "Вы используете бесплатную CMS и вполне вероятно, в ядре или расширениях есть уязвимости. Проверьте компьютер антивирусом и не храните пароли в FTP".
По поводу уязвимости: 99% она не при чем, т.к. даже если в Joomla 1.5.9 есть еще не найденная дыра, то её по просту не кому было найти, т.к. проект не запущен и находился на тестовом полигоне. Антивирусником комп прогнал (NOD32), но снова не ясно, как потенциально зараженный комп может повредить структуру сайта, если пароли не хранятся в FTP?

В общем, проект доделал и перенёс на сервер заказчика (nichost.ru). Фокусы с нерегулярным удалением php файлов из корня наблюдаются и здесь. Делаю вывод: причина не в хостере.
Вот такая вот ситуация. Первый раз сталкиваюсь за свою практику с подобным.

Сайт: http://muslimedu.ru

Конфигурация:

Платформа:     FreeBSD web20.nic.ru 6.2-RELEASE-p8 FreeBSD 6.2-RELEASE-p8 #0: Thu Oct 11 18:46:20 MSD 2007 root@hdad.nic.ru:/usr/obj/usr/src/sys/HNIC-SMP-ULE i386
Версия MySQL:    4.1.22
Сравнение БД:    utf8_general_ci
Версия PHP:    4.4.9
Веб-сервер:    Apache/1.3.37 (Unix) mod_ssl/2.8.28 OpenSSL/0.9.7e-p1 PHP/4.4.9
Интерфейс веб-сервер -> PHP:    apache
Версия Joomla:    Joomla! 1.5.9 Production/Stable [ Vatani ] 9-January-2009 23:00 GMT (Legacy режим)

Расширения:
JoomFish 2.0.2 (установлены языки: русский, английский, арабский)
Community Builder 1.2 stable
Agora Pantheon 2.5.5
EventList 1.0 RC
Groupjive pre-RC Testing version 29a
JComments 2.0.0.17
MorfeoShow release 1.2.0 (компонент галереи)
Phoca Download 1.0.5
Seyret 0.2.8.4
SOBI2 RC 2.9.1.0 (плюс платные модули SOBI GEO category 2.3 и SOBI search module 1.6)
uddeIM 1.5
Xmap 1.2
ARI Quiz (коммерческая лицензия; глюки с удалением возникали еще до установки этого расширения)

Варез не используется. Все модули и расширения либо GNU/GPL, либо платные.

Ради эксперимента можно попробовать убрать права доступа к этим файлам у php (допустим через FTP). Другой вариант - провести тотальную проверку сайта на наличие сторонних скриптов - вполне возможно давным давно сайт был атакован, но не все вычищено.

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

Ради эксперимента можно попробовать убрать права доступа к этим файлам у php (допустим через FTP).

Выставить на файлы права r-r-r?

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

Хммм, перелопатить 5 тыс. файлов кажется мне проблематичной задачей. Может быть, последовательно, перезаписать core файлы и все компоненты из оригинальных дистрибутивов?

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

Очень хороший совет. Попробую просканнировать компоненты. О результате отпишусь.

В целом, удаление файлов возникает во время навигации по сайту. При этом выкидывает на страницу:  http://muslimedu.ru/installation/index.php - папки installation, естественно, не существует...

Чтобы отследить эту версию, необходимо пройтись по всему сайту и найти все строчки, где используются функция unlink. И временно добавить перед ее вызовом запись имени удаляемого файла в некий файл лога. И потом посмотреть, кто это грохает.

Вполне разумная мысль. Команда unlink должна встречаться редко, наверняка удаление идет через ядро (JFolder::delete и JFile::delete), так что достаточно найти эти места вставить перед
что-то вроде
Наличие debug_backtrace в errorlog'е позволит почти сразу же локализовать ошибку.

Хммм, перелопатить 5 тыс. файлов кажется мне проблематичной задачей. Может быть, последовательно, перезаписать core файлы и все компоненты из оригинальных дистрибутивов?

ну это не решит проблемы, если по каким-то причинам на сервере находится какой-то "левый" файл...

Вполне разумная мысль. Команда unlink должна встречаться редко, наверняка удаление идет через ядро (JFolder::delete и JFile::delete)

если речь идет о родных компонентах для 1.5, то да... Но посмотри список - там полно расширений, которые работают в режиме совместимости, а значит наверняка там именно unlink.

Проблема обнаружена и решена.
Причина скрывалась в плагине автоматического удаления кэша Clear old cache. Physicist уже выложил обновленную версию здесь. Спасибо, Денис!

Т.е. мое предположение:

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

оказалось верным?

оказалось верным?

Да.