наверно можно, но я и так точно знаю, что это урл-ы другого хоста. На сервере все мои сайты и я четко знаю их структуру. Между собой они никак не перелинкованы.
конечно. В сайтмепе все правильно и у каждого хоста свой сайтмеп, беков на эти страницы нет.
Сайты на разных IP.
ТС создал сайт с торрентами. Система, установленная на ДЛЕ, действительно работает: сиды и пиры могут слегка отличаться от реальных, но как уверил меня ТС - к ним приближенные, все остальные данные (имя файла, размер) - реальные.
ТС любезно ответил на все мои многочисленные вопросы по поводу функционирования и наполнения такого сайта.
Сотрудничеством доволен на все 100.
Еще отпишу после попадания сайта в индекс.
Спасибо за команду, сейчас пройдусь.
Да, в нем все чисто. Очевидно favicon.ico используют чисто для идентификации уязвимости. Это выгодно делать, потому что такая картинка есть практически на любом сайте.
а как это сделать, если их десятки тысяч аватарок?
Отключается, но не помогает.
Вы знаете, на этом сервере действительно падает постепенно траф практически на всех сайтах. Причину установить не могу, тем более позиции на месте. С вами можно как-то связаться, может у вас есть какие-то подходы к обнаружению сабжа. За помощь естественно готов заплатить.
сейчас там его нет, но не факт что был раньше и его уже удалили. Да и вообще при таком раскладе отлично срабатывал шелл вшитый в картинку - я проверял, так что другого скрипта и не надо.
Да, советы прочитал, подправил конфиги. Но конечно гарантии нет, что если уязвимость уже используется, какие-то манипуляции ее перекроют.
Reise добавил 21.11.2011 в 03:40
Вот еще интересная последовательность запросов:
Обратите внимание на размер ответа - каждый раз разный, чтобы это значило?
При это к картинке foto_107953.jpg дописан код:
Если открывать через браузер, выдает:
Если скачать этот файл и просмотреть, то так и остается 123<?php phpinfo(); ?>. Но я же говорю - сейчас php там не выполняется, но тогда точно выполнялось.
Reise добавил 20.11.2011 в 23:46
интересно, так и сделаю :)
Правда сейчас как я понимаю уже надо 2 настройки: cgi.fix_pathinfo=1 в /etc/php5/fpm/php.ini и убрать отдельный локейшен uploads из конфига nginx, чтобы php там выполнялся.
Reise добавил 21.11.2011 в 00:04
Проверил. Результаты не порадовали.
Достаточно не запрещать обработку php в папке uploads - и по урлу /uploads/fotos/foto_110011.png/1.php срабатывает шелл и открывается файлменеджер.
Причем по урл-у /uploads/fotos/foto_110011.png благополучно открывается картинка.
И что интересно, это никак не зависит от настройки cgi.fix_pathinfo.
П.С. Вот блеать хакеры - руки отрывал бы за такое...
Reise добавил 21.11.2011 в 00:09
Спасибо, уже читаю.
Я это уже убрал, но только вчера, а заливка шелла состоялась гораздо раньше.
Может быть сис-админы? :)
Это шелл самый настоящий, я просто привел часть кода, если кому интересно прикрепляю его код.
Сейчас наверно уже не исполняет, сделал cgi.fix_pathinfo=0 в php.ini, а по умолчанию то как раз Default is 1.
Спасибо за наводку, так и делаю, может еще что найду.
Reise добавил 20.11.2011 в 23:17
у меня именно nginx + php-fpm, но cgi.fix_pathinfo было 1 - это как я понимаю дает возможность делать такие трюки.
сейчас там его нет, но может тогда и был, у меня только сегодня дошли руки до логов.
Да, проверил foto_110011.png vim'ом - и офигел, сверху идет очевидно действительно код картинки (не читабельные символы), а ниже тупо php-код, который начинается так:
Reise добавил 20.11.2011 в 23:12
Да, спасибо, есть код, файл пока удалил от греха подальше. Я так понимаю это шелл, только как его можно вызывать, если это png-картинка?
