Корневой эксплойт Apache/PHP
Из-за небезопасной обработки загруженных файлов злоумышленник смог запустить php-код на моем сервере (CentOS 5.4). Эта проблема была исправлена, но пока он был подключен, он, похоже, изменил файл, принадлежащий пользователю root (file perms 644), заменив его на принадлежащий пользователю apache. Существуют ли apache или php-эксплойты, которые могли бы включить это?
В ответ на первые комментарии, которые запрашивают дополнительную информацию - злоумышленнику было бы достаточно плохо загружать файлы на мой сервер и, возможно, отправлять пользователям вредоносный контент в моем домене. Однако он / она также мог редактировать файлы. Результатом этого стало то, что мой сайт был изменен таким образом, чтобы отправлять всю информацию от регистрации новых пользователей на адрес электронной почты.
Я не уверен, с чего начать, и прошу помощи в этом. Кроме очевидных прав доступа к каталогам (не разрешать загрузку файлов в каталоги, где может выполняться код php; не выполнять код php в пользовательских каталогах загрузки). Я не знаю, что изменить, чтобы этого больше не повторилось. Насколько я понимаю, если файл принадлежит пользователю root, другой пользователь не сможет его изменить. Очевидно, это не было правдой.
Если бы это был ваш сервер, где бы вы посмотрели?
2 ответа
Насколько я понимаю, если файл принадлежит пользователю root, другой пользователь не сможет его изменить. Очевидно, это не было правдой.
Если разрешения для этого файла доступны для записи "group" или "other", то любой в этой группе (например, "apache") или любой пользователь (в случае "other") может перезаписать его и / или изменить собственность
Другая вещь, которую я бы искал, так как это инъекция файлов, это php-файлы, которых там не должно быть, или файлы, которые вы не создавали. Их можно было бы назвать относительно безобидными, например, "index.php" или "help.php", но если вы посмотрите на код, вы увидите большие глобусы данных, закодированных в base64 (чтобы скрыть, что они на самом деле делают). Посмотрите также на "wsh.php".
Иногда эти файлы представляют собой "веб-оболочки", написанные на php, которые предоставляют подобный оболочке доступ к файловой системе с использованием разрешений процесса php / apache. Они смогут редактировать / удалять / загружать / копировать / перемещать файлы, в том числе те, которые принадлежали пользователю root, но с плохими разрешениями (см. Первый абзац).
Эти файлы могут выглядеть так:
<?PHP
//Authentication
$login = ""; //Login
$pass = ""; //Pass
$md5_pass = ""; //If no pass then hash
eval(gzinflate(base64_decode('7b17f9vG0TD6d/v75TusEaYmE5KiZOcmWXJkSY59alt+JLlpXtmH
// etc etc
Может быть, вы можете сделать что-то вроде:
find www_root -name '*.php' -exec grep -l 'eval' {} \;
И посмотрите на эти файлы и убедитесь, что они законны.
Просто общий совет о том, как избежать этого в будущем:
Патч свой сервер. CentOS 5.4 - это EoL уже довольно давно. В настоящее время мы находимся на CentOS 5.7!
Обратите внимание, что в CentOS 5.5 также было обновление PHP.
Это обновление PHP содержало множество исправлений безопасности.
Для веб-сервера вы должны использовать (как минимум) трех пользователей и одну группу:
root - владелец основного процесса (не обязательно, если вы используете непривилегированный порт)
wwwrun - пользователь, под которым запускаются http-подпроцессы, группа www
wwwadmin - пользователь, у которого есть доступ на запись к файлам веб-серверов (обычно htdocs или в вашем случае - php-base-dir), также группа www.
Группа www должна была иметь доступ для чтения, но не для записи в htdocs.
Выберите ваши собственные имена пользователей / групп по желанию, это всего лишь пример.
Вы также можете укрепить httpd, запретив TRACE, TRACK, PUT и DELETE (если ваше приложение позволяет это). Это может быть достигнуто с помощью mod_rewrite.