Взломан. Хочу понять как

40

Кто-то во второй раз добавил кусок javascript к сайту, который я помогу запустить. Этот javascript захватывает Google AdSense, вставляя номер своего аккаунта и вставляя рекламу по всему.

Код всегда добавляется, всегда в одном конкретном каталоге (который используется сторонней рекламной программой), влияет на количество файлов в ряде каталогов внутри этого рекламного каталога (20 или около того) и вставляется примерно в одно и то же время. время. Аккаунт AdSense принадлежит китайскому веб-сайту (расположен в городе, который находится не в часе езды от того места, где я буду в Китае в следующем месяце. Может быть, я должен разориться ... шучу, вроде как), кстати ... вот информация на сайт: http://serversiders.com/fhr.com.cn

Итак, как они могли добавить текст в эти файлы? Это связано с разрешениями, установленными для файлов (в диапазоне от 755 до 644)? Пользователю веб-сервера (он на MediaTemple, поэтому он должен быть безопасным, да?)? Я имею в виду, что если у вас есть файл с правами доступа 777, я все равно не могу просто добавить к нему код по своему желанию ... как они могут это делать?

Вот пример реального кода для вашего удовольствия от просмотра (и, как вы можете видеть ... не так уж много. Настоящий трюк в том, как они его там получили):

<script type="text/javascript"><!--
google_ad_client = "pub-5465156513898836";
/* 728x90_as */
google_ad_slot = "4840387765";
google_ad_width = 728;
google_ad_height = 90;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>

Поскольку некоторые люди упоминали об этом, вот что я проверил (и под проверкой я имею в виду, что я посмотрел вокруг времени, когда файлы были модифицированы для любой странности, и я нашел файлы для операторов POST и обратного пути в каталогах:

  • access_log (ничего за это время, кроме нормального (т. е. чрезмерного) трафика бота msn)
  • error_log (ничего, кроме обычного файла, не существует ошибок для безобидно выглядящих файлов)
  • ssl_log (ничего, кроме обычного)
  • messages_log (здесь нет доступа к FTP, кроме меня)

* ОБНОВЛЕНИЕ: ** ОК, решил. Хакеры из Китая физически разместили на нашем сайте файл, который позволяет им выполнять всевозможные административные действия (доступ к базе данных, удаление и создание файлов и директорий, вы называете это, они имели доступ). Нам повезло, что они не сделали что-то более разрушительное. В обычных лог-файлах apache ничего не было, но я нашел другой набор лог-файлов в анализаторе логов веб-сервера, и доказательства были там. Они обращались к этому файлу с помощью своего собственного имени пользователя и пароля администратора, а затем редактировали все, что им нужно, прямо на сервере. В их файле «apache» установлен как пользователь, в то время как все остальные файлы на нашем сайте имеют другое имя пользователя. Теперь мне нужно выяснить, как они физически поместили этот файл в нашу систему. Я подозреваю, что вина за это в конечном итоге будет лежать на нашем веб-хостинге (Media Temple),

Lothar_Grimpsenbacher
источник
6
Я не знаю, ты дал кому-то свой пароль?
4
Если вы знаете, когда именно это происходит, поищите в своем access_log все необычное в это время. Особенно запишите все запросы POST: куда они идут, что они сделали.
sanmai
3
Thx WhirlWind ... очень полезно.
Lothar_Grimpsenbacher
2
На самом деле, если вы их знаете, почему бы не вставить их адресные данные на сайт для защиты от спама. Позвольте сети "говорить" с ними и дать им вкус их собственного лекарства. :-)
4
@ gaoshan88 - полезнее, чем вы думаете. Одним из векторов атак является троян, который перехватывает пароли от ftp-клиентов разработчиков.
Квентин

Ответы:

9

Прежде всего, chmod 744это НЕ то, что вы хотите. Задача chmod - отозвать доступ к другим учетным записям в системе. Chmod 700гораздо безопаснее, чем chmod 744. Однако для запуска вашего php-приложения Apache нужен только бит исполнения.

chmod 500 -R /your/webroot/

chown www-data:www-data -R /your/webroot/

www-данные обычно используются как учетная запись Apache, которая используется для выполнения php. Вы также можете запустить эту команду, чтобы увидеть учетную запись пользователя:

`<?php
print system("whoami");
?>`

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

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

ладья
источник
6
+1, избегайте FTP как чума. Троян анализатора паролей может заразить ваш компьютер и использовать ваши учетные данные для изменения файлов. Или это может заразить ваш роутер. Или компьютер вашего соседа в интернет-кафе с незащищенной сетью Wi-Fi. Отправка пароля в открытом виде - плохая, плохая идея.
Tgr
1
FTP это приходит с SSL, вы знаете.
grawity
1
@ grawity большинство людей не используют "ftps", но это не даст вам взломать. sftp более популярен.
Ладья
2
Www-данные НЕ должны владеть файлами в вашем веб-каталоге. Все, что www-данные могут быть обновлены плохо написанным сценарием на сервере.
Зоредаче
9

Мои учетные записи сервера Media Temple Grid неоднократно подвергались такому «взлому». Их безопасность очень плохая ... началась с PLAIN TEXT PASSWORDS в прошлом году и продолжается по сей день (вы можете позвонить в службу технической поддержки, и они скажут: «Какой у вас пароль?»). Я знаю, потому что я получаю ежемесячные электронные письма о том, как они изменили все пароли моей учетной записи, и они фактически заходят и меняют пароли базы данных для вас каждый раз, когда их взламывают. Эта компания выглядит чертовски блестящей на поверхности, но сервер грид - беспорядок. Я рекомендую переключиться немедленно .

Пожалуйста, смотрите этот пост прошлого года о первоначальном фиаско (предупреждение, это вас разозлит). Это пошло вниз оттуда. Я провел молебен в прошлом году от моей семьи и удаление порно ссылки из моих сайтов. Прекрасный.

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

typeoneerror
источник
ха - ха. мои сайты GS сейчас все в порядке. нет электронной почты. weblog.mediatemple.net/weblog/category/system-incidents/…
typeoneerror
2

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

Вы проверили crontab на что-нибудь странное?

Вы пытались переименовать каталог и ссылки на него (это может сломать сценарий оболочки)?

abarax
источник
переименование это хорошая идея. Я попробую это, как только увижу, как это повлияет на сайт. У Crontab была одна немного странная вещь: есть запись о времени изменения файлов, но это менеджер резервного копирования Plesk ... скомпилированное приложение. Если это будет скомпрометировано, то у Media Temple возникнут большие проблемы.
Lothar_Grimpsenbacher
1

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

Другой компонент отслеживает, как именно они изменяют ваши файлы. Проверка журналов доступа веб-сервера - это хорошее место для начала. Проверьте время последнего входа в систему для различных пользователей. Вы также можете установить скрипт, который отслеживает файлы на предмет изменений и уведомляет вас, чтобы вы могли попытаться поймать преступников с поличным!


источник
1

Это звучит очень знакомо для хакеров Wordpress, которые недавно поразили множество сайтов Network Solutions. Поскольку вы находитесь в Media Temple, возможно, вы оставили некоторые файлы видимыми для других пользователей, использующих ваш компьютер. Это объясняет отсутствие POST или следов журналов Apache. В таком случае было бы смертельно просто ввести код в командной строке.

редактор
источник
Журналы показывают трафик в то время, когда эти файлы были изменены, но это безобидные вещи, такие как: 207.46.13.43 - - [05 / May / 2010: 01: 42: 26 -0700] "GET /oped/bpr.php?edid= 211 & page = 4 HTTP / 1.1 "404 257" - "" msnbot / 2.0b (+ search.msn.com/msnbot.htm ) "
Lothar_Grimpsenbacher
Вы знаете, как работал этот взлом Wordpress? Могу сказать мне, как решить мою собственную проблему.
Lothar_Grimpsenbacher
2
Да, это были плохие разрешения для общих ящиков, возможно, вызванные неправильными настройками по умолчанию со стороны Network Solutions. Рекомендуемое исправление - блокировка разрешений 755 для папок и 644 для файлов.
1

Код всегда добавляется, всегда в одном конкретном каталоге

Это связано с разрешениями, установленными для файлов (в диапазоне от 755 до 644)? Пользователю веб-сервера

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

один используется сторонней рекламной программой

Или, возможно, эта программа имеет подвиг.

webbiedave
источник
Я предполагаю, что может быть, что сторонний код имеет эксплойт. Он находится на общем сервере, но я бы нашел все загруженные сценарии (если они не загрузили его, не использовали его, а затем удалили, но даже тогда я бы нашел что-то в файлах журналов, показывающих их соединение с ftp)
Lothar_Grimpsenbacher
1
Если ваши файлы доступны для записи на веб-сервере, возможно, они могли загрузить скрипт на любой веб-сайт на сервере и перезаписать ваши файлы. Но я бы также внимательно посмотрел на это стороннее приложение.
Код третьей стороны ... это исполняемый скрипт или просто фрагмент кода JavaScript? JavaScript не может изменять файлы на сервере.
Салман А
@Salman A - это коллекция PHP-скриптов, которые управляют рекламой.
Lothar_Grimpsenbacher
Хорошо, тогда я надеюсь, что вы исследовали этот код.
Салман А
1

Если у вас есть соответствующий доступ (и поддержка ядра), вы можете попытаться запустить демон мониторинга на основе inotify или dnotify для отслеживания изменений в ваших файлах, а затем (быстро) использовать «lsof», чтобы увидеть, в каком процессе файл открыт с помощью доступ для записи. Вы также можете использовать strace для мониторинга. Это должно дать представление о том, какой исполняемый файл используется.

outis
источник
1

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

Затем это может быть скрипт на вашем веб-сервере, который внедряет этот код. В сценарии с общим хостингом я думаю, что это возможно сделать cat /web/malicious.com/script.js >> /web/innocent.com/index.php. Это может работать при определенных условиях, таких как команда, выполняемая пользователем httpd, и файл index.php также принадлежит / доступен для записи этому пользователю. В этом случае у вас должен быть хостинг-провайдер, чтобы отслеживать учетную запись, используемую для внедрения скриптов.

Салман А
источник
1

Большинство файлов сайта должны быть доступны для чтения веб-сервером. На сайте, доступном только для чтения, веб-сервер должен записывать только журналы. назначить владельцем кого-либо, кроме используемого веб-сервером. Установите защиту 640 для всех файлов, кроме скриптов. Установите сценарии и каталоги 750. Для файлов или каталогов, которые должны быть записаны веб-сервером, вы можете сменить владельца на веб-сервер или установить chmod g + 2 для соответствующих файлов или каталогов.

BillThor
источник
Сценарии, отличные от CGI, часто могут иметь режим 600 или 640 (в зависимости от владельца файла и группы и от того, от какого пользователя работает веб-сервер), поскольку многие сценарии передаются интерпретатору.
вне
0

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

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

Tgr
источник
0

То же самое случилось со мной некоторое время назад. Насколько я знаю, Wordpress был единственным программным обеспечением, которое могло вызвать что-то подобное.

Джо Филлипс
источник
Никакая Wordpress не вовлечена здесь.
Lothar_Grimpsenbacher