Сценарий PHP: злонамеренный код JavaScript в конце

Question

Сценарий PHP: злонамеренный код JavaScript в конце

Проблема:

На моем webspace существуют файлы PHP который весь конец с этим:

Перед этой строкой в файлах существует также HTML-код.

Вывод в браузере заканчивается этим, конечно:

Но вчера, был некоторый вредоносный код в конце, внезапно. Вывод моего index.php был:

Я открыл файл на своем webspace (загруженный через FTP), и я видел, что кто-то исправил этот код в файл!

Как это могло произойти?

Единственными путями я могу вообразить:

Кто-то получил мой пароль FTP. Но он не только поместил бы его в один файл. Он, возможно, нанес намного больше ущерба. Таким образом, я не могу вообразить дело обстоит так.
У меня есть вирус на моем ПК самого. Я использую Блокнот ++ для редактирования и FileZilla для загрузки. Возможно, эти программы были загрязнены также, и я загрузил вредоносный код - без знания.
Кто-то использовал дыру в системе безопасности (XSS) для помещения того кода в страницу. Но он, возможно, не исправил его в файл, не так ли?

Признаки:

Пользователи сообщили о синей панели, открывающейся в Firefox. Это попросило, чтобы они установили плагин. Теперь у некоторых из них есть Использование. Java. CVE-2010-0886.a на их ПК.

Действительно ли это происходит из-за вредоносного кода? Что код делал точно?

Можно ли помочь мне?

Помогите мне, я являюсь действительно отчаянным.

Возможно, один дополнительный вопрос, если Вы знаете, как у меня мог быть он: Как я мог предотвратить что-то вроде этого в будущем?

Редактирование № 1:

Я нашел файл названным "x76x09.php" в корневом каталоге моего webspace. Это имеет размер файла 44,281 байта. Я загрузил его и попытался открыть его. Но мое антивирусное программное обеспечение сказало, что это - троянец (троянец. Сценарий 224490). Я думаю, что этот файл был выполнен и добавил вредоносный код к "index.php" в каждом каталоге. Это помогает? Как троянец мог приехать в мой webspace? Действительно ли это - известный вирус?

Редактирование № 2:

Мой hoster говорит, что он может теперь быть уверен, что файл не был загружен через FTP. Таким образом, заражения не произошло через FTP. Согласно моему hoster, это должны быть небезопасные сценарии.

Редактирование № 3:

Дыры в системе безопасности по данным PHPSecInfo:

allow_url_fopen = 1
allow_url_include = 1
expose_php = 1
file_uploads = 1 (виноват в этом злонамеренный "x76x09.php" файл?)
group_id = 99
user_id = 99

Редактирование № 4:

Я проанализировал файл, который был выполнен на моем веб-сервере. Вот результаты.

Таким образом, этот вирус, кажется, известен как:

Некоторые из них могли вызвать злонамеренный файл на моем webspace, который добавил вредоносный код?

17

php javascript security virus

задан caw 1 August 2010 в 20:02

10 ответов

Если у вас статический ip - вы можете запретить ftp-доступ с не вашего IP

0

ответ дан 30 November 2019 в 12:06

Похоже, ваш сервер был скомпрометирован, вы также находитесь на общем хосте?

Вы можете узнать конфигурацию безопасности вашего сервера с помощью:

PhpSecInfo

_{(источник: phpsec.org )}

7

ответ дан 30 November 2019 в 12:06

У кого вы размещаетесь? У некоторых хостеров есть утечки безопасности, которыми можно воспользоваться.

Используете ли вы WordPress? Также было зарегистрировано несколько вспышек. Лучше всего погуглить и поискать людей с похожими проблемами, что также приведет к поиску причины, а это приведет к поиску решений.

3

ответ дан 30 November 2019 в 12:06

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

1

ответ дан 30 November 2019 в 12:06

phsource является ближайшим.

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

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

Скорее всего, вам следует изменить все ваши файлы на 755 или 644 разрешения. Ты будешь спать лучше по ночам.

И после того, как вы его очистите, убедитесь, что Google не пометил вас как вредоносный сайт. Очистить это не так уж и плохо, но тем временем это может уменьшить ваш трафик.

1

ответ дан 30 November 2019 в 12:06

Это случилось со мной некоторое время назад по-разному. Рабочая учетная запись была взломана через phpBB с помощью взлома кода. Каким-то образом они даже добавили себя в таблицу пользователей базы данных mySQL. Это заставило нас полностью удалить программу и прекратить использование.

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

Мой текущий рабочий сервер "обнюхивается" для phpMyAdmin более 1000 раз в час во время некоторых пиковых попыток взлома. Плохие парни работают сверхурочно!

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

0

ответ дан 30 November 2019 в 12:06

Как предположили другие, уязвимость, скорее всего, находится в каком-то скрипте, который вы используете, возможно, что-то, что вы написали сами, или в известном приложении, которое имеет известные уязвимости. Это может быть уязвимость в скрипте загрузки, но я хочу отметить, что также возможно "загрузить" файлы через SQL-инъекцию, смотрите следующий поток для более подробной информации

3

ответ дан 30 November 2019 в 12:06

Некоторое время назад мы столкнулись с проблемой, подобной этой, с одним из наших основных веб-ресурсов. То, что сказал ваш веб-хостинг, было правильным: вероятно, это было связано не с ДОСТУПОМ к FTP, а с небезопасным скриптом, который каким-то образом позволял модифицировать произвольные файлы. В нашем случае уязвимость в старом phpMyAdmin допустила изменения в некоторых PHP скриптах.

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

cd web_files_directory
chown -R some_not_web_server_user:some_not_web_server_group .
find . -type f | xargs chmod 644
find . -type d | xargs chmod 755

2

ответ дан 30 November 2019 в 12:06

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

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

http://www.qualys.com/products/qg_suite/was/

Эти службы стоят денег, но обычно вы можете получить "бесплатную пробную версию", чтобы посмотреть, будут ли они полезны. Удачи!

1

ответ дан 30 November 2019 в 12:06

Другие вопросы по тегам:

php javascript security virus

Похожие вопросы:

score 16 · Accepted Answer

Я не думаю, что проблема в том, что вы используете общий хост, потому что я нашел шесть других ( degmsb , Benvolio , joomla01 , DJ-Alien , valerione1979 и Kars ), на веб-сайты которых был добавлен тот же сценарий. Кроме того, сомнительно, что какие-либо из ваших файлов будут доступны для записи другим пользователям, потому что файлы, которые загружаются через FTP, подчиняются битовой маске режима создания файлов.

Я предполагаю, что кто-то взламывает веб-сайты, используя известные эксплойты или эксплойты против распространенных уязвимостей, и что этот человек определяет вероятные цели с помощью взлома Google . Веб-сайт Wordpress degmsb и веб-сайт Burning Board Lite Benvolio, вероятно, были взломаны с помощью известных эксплойтов (возможно, известных эксплойтов плагинов для этих программных баз, таких как TinyMCE), и ваш сайт, поскольку вы написали его самостоятельно, вероятно, был взломан с помощью эксплойта против обычного веб-сайта слабость.

Учитывая, что вы разрешаете загрузку файлов (один из ваших сценариев PHP принимает и сохраняет файлы, загруженные вашими пользователями), я бы рассмотрел вариант CWE-434: неограниченная загрузка файлов опасного типа . Эксплойт CWE-434 работает следующим образом: предположим, вы разрешаете пользователям загружать изображения или изображения аватаров. Сценарий, в который отправляются загруженные изображения, может сохранить файл в / images , используя то же имя файла, что и пользователь. Теперь представьте, что кто-то загружает x76x09.gif.php (или x76x09.gif.asp , x76x09.gif.php4 и т. Д.).Ваш сценарий послушно сохранит эту загрузку в /images/x76x09.gif.php , и все, что нужно взломщику для запуска этого сценария на сервере, - это перейти в /images/x76x09.gif. php . Даже если файл называется x76x09.php.gif , некоторые веб-серверы выполнят этот файл.

Другая возможность состоит в том, что имя файла загрузки, которую получает PHP, $ _ FILES ['upload'] ['name'] , что является значением filename в ] Отправляемый заголовок Content-Disposition был создан для чего-то вроде .. \ modules \ x.gif . Если ваш скрипт сохранил только что загруженный файл в str_replace ('\\', '/', '/ images /'. Basename ($ _ FILES ['upload'] ['name'])) , или / images /../ modules / x.gif на хосте, отличном от Windows ( http://codepad.org/t83dYZwa ), и пользователь мог чтобы заставить один из ваших PHP-скриптов включить или , требуется любой скрипт в каталоге modules (скажем, index.php? module = x.gif & action = blah ), тогда взломщик сможет выполнить произвольный PHP.

РЕДАКТИРОВАТЬ: Это похоже, что x76x09.php - это своего рода неограниченный браузер каталогов и загрузчик файлов. Если пользователю удастся загрузить это на ваш сервер, он сможет делать все, что вы можете делать с вашим FTP-доступом. Удалить.

РЕДАКТИРОВАТЬ2: Найдите копии этого исходного кода PHP (часть gzuncompress (base64_decode ("HJ3H ... geFb // eeff / 79z / 8A")); ). Удалите его из всех ваших PHP-скриптов.

РЕДАКТИРОВАТЬ3: Погуглили части сценария PHP, я нашел несколько веб-страниц, где этот источник указан дословно, и все эти страницы имеют какое-то отношение к функциям загрузки файлов для соответствующих веб-сайтов. Поэтому весьма вероятно, что хакер вашего веб-сайта использовал эксплойт CWE-434.