Forums / National / Russian / взлом cotonti

Ничто не исключено. На моей памяти большинство взломов было из-за кражи пароля от FTP (тема про ftp-трояны довольно известна), реже из-за взлома сервера и ещё реже из-за уязвимости движка. Подробнее о последнем: чтобы залить шелл и сделать дефейс, надо иметь доступ на запись файлов, а не только базы. То есть XSS или SQL-инъекции тут недостаточно, нужна дырка посерьёзней для заливки PHP-скрипта. Например, такое бывало у несчастных владельцев плагина TPL Editor ещё в Seditio. Через PFS залить не могли, потому что там есть нужные проверки на заливку скриптов.

А куда залит шелл? Пароль админа не изменили? Какие файлы затронуты дефейсом?

Имена и содержимое файлов не помешало бы. Права на скин футер какие были? Да, похоже ломанули движок. PFS юзерам на сайте доступен?

#31580 Fox:

А по логах сервера может чтото найти можно?

Гдето 2 мес назад я накакомто зарубежном сайте нашел что у какойто версии 0.9.Х есть уязвимость XSS. Типа вам отправили письмо с описанием дырки но вы на него неответили. Больше ниче непонял потомучто переводил через гогл

Добавлено 30 минут спустя:

Может актуально

_http://www.exploit-db.com/exploits/17958/_
_http://packetstormsecurity.org/files/105656_
_http://www.cmsmatrix.org/matrix/cms-matrix/cotonti_
_http://securityvulns.ru/docs26215.html_
_http://securityreason.com/wlb_show/WLB-2011100054_

Во-первых, это в сиене, в генуе этих проблем нет. Во-вторых, письмо никакое нам никто не отправлял. В-третьих, воспользоваться этими уязвимостями для взлома фактически невозможно (кроме xss). В-четвертых, исправление оставшихся будет в 0.9.6.

Я понял, просто довожу до сведения всех, у кого сиена :)

Заливка каких расширений файлов разрешена? Включена ли проверка заливаемых файлов (в конфигурации Мои файлы)? Каково значение allow_url_fopen и allow_url_include в php.ini/phpinfo()? Используются ли плагины, заливающие или редактирующие файлы движка?

Похоже, схема была следующая: через некую уязвимость злоумышленник залил на сайт скрипт и смог выполнить его. Этот скрипт распаковал заранее залитый архив с шеллом (session.php может быть скриптом для кражи пользовательских сессий). Далее через шелл с правами вебсервера модифицировал футер и индекс, поскольку права на эти файлы позволили.

Экстренные меры: поменять пароли, в том числе mysql и администраторов на сайте; отключить pfs и другие модули с заливкой файлов; запретить изменение файлов движка вебсервером.

По поводу уязвимости сказать трудно, но судя по локализации в datas/users, уязвимость всё-таки в pfs. Больше пока ничего сказать не могу.

99% залили файлик в pfs, переименовали и выполнили из браузера.

Надо средствами http-сервера запрещать исполнение php в папке, куда аплоадятся картинки. В .htaccess прописать php_flag engine 0

Разрешённые к закачке типы файлов в datas/extensions.php. Важно: все эти типы должны быть известны вебсерверу Apache (если используется оный), иначе можно получить довольно известную проблему, когда какой-нибудь myfile.php.xyz выполняется как php поскольку тип xyz неизвестен.

Дай угадаю, доступ к datas/defaultav был 777? Движок никогда не заливает файлы в эту папку.

Вообще картина складывается следующая: записывают файлы, к которым есть доступ на запись; заливают файлы туда, где есть доступ на добавление файлов в папку. В том числе и туда, куда файлы из веба попасть не могут. О чём это говорит? О том, что у злоумышленника есть доступ от другого аккаунта в системе (но не root, что уже хорошо) через SSH, FTP или через скрипты.