GlasBlog

Das Honeynet Project hat das erste Forensic Challenge für das Jahr 2010 veröffentlicht. In diesem von Tillmann Werner erstellten Challenge geht es um ein pcap attack trace den es zu analysieren gilt. Genaue Informationen und den Trace gibt es auf der Projektseite.

Immer wieder stößt man beim Durchsehen der RFI Angriff Logs auf Dateien, die bei sogenannten PasteBin oder NoPaste Hostern abgelegt wurden. Die Angreifer verwenden die Funktion, dass man dort abgelegten Code losgelöst vom Webinterface ansehen und somit auch in eine Web Anwendung einbinden kann. Die Anbieter solcher Dienste versuchen zwar derartigen Missbrauch zu verhindern, jedoch nicht immer Erfolgreich. Hier ein Beispielt, welches sich prinzipiell nicht filtern lässt: http://pastesite.com/plain/3736.txt Die Datei enthält:

<?
echo 'OWNED BY ME';
?>

Es gibt jedoch auch genug PHP Bots, Flooder und Scanner. Um weiteren Missbrauch zu vermeiden, könnte man die mit Glastopf gesammelten Daten auswerten und die Pastebin Provider über Missbrauch ihres Services informieren.

Eine der Hauptarbeiten die in Zukunft angestanden wären, ist das Anpassen des Parsers an neue RFI Angriffe. Der alte Parser suchte, vereinfacht gesagt nach einem “echo” Aufrufe, analysierte diesen per Reguläre Ausdrücke und generierte eine passende Antwort. Das Warten dieser Herangehensweise ist sehr aufwendig, besonders wenn die Echos in einer Funktion gepackt werden. Um die Arbeit deutlich zu vereinfachen, möchte ich den neuen Parser so weit entwickeln, dass ich weitestgehend ohne Verwendung von vordefinierten Patterns auskomme.
Der erste Schritt in diese Richtung ist geschafft, der neue Parser ist in der Lage Funktionen zu erkennen und diese auf Ausgaben zu untersuchen. Bedeutet, findet er eine Funktion die Echos enthält, werden die Funktionsaufrufe auf bekannte Muster untersucht und die Antwort für den Angreifer generiert.

Pseudo Beispiel:

if "function fu(bar)" in line:
    store function into functionlist
for function in functionlist:
    if "echo" in function:
        function = "echofunction"
for line in injected_file:
    if name_of_function in line:
        sent the line to the echo_parser

Okay, nun haben wir quasi alle Zeilen in einer Datei die potentiell etwas ausgeben. Einmal gewöhnliche Echos:

<?php echo "Glaslos was here..."; ?>

Und Echos die über einen Funktionsaufruf erstellt werden:

<?php
function echothis($e) {echo "$e";}
echothis("Glaslos was here...");
?>

Haben wir nun ein Echo folgender Form:

<?php
$xyz = get_xyz_from_system();
echo "xyz: $xyz<br />";
?>

müssen wir wissen, was get_xyz_from_system() ausgibt. Bisher habe ich xyz: mit bekannten Mustern verglichen und dann $xyz durch Werte ersetzt. Hier setzt nun die kommende Arbeit an: Sämtliche Aufrufe der Form get_xyz_from_system() müssen behandelt werden und an der richtigen Stelle der Antwort stehen. Hierfür gilt es die Variablen Definition und ihre spätere Verwendung zu erfassen und zu verarbeiten.

Oder ausgeschrieben: Request for Comments [en:wiki:rfc]: Remote File Inclusion [en:wiki:rfi]. Durch fortschreitender Beschäftigung mit Web Honeypots wurde mir immer bewusster, wie vielen die Definition einiger Standards helfen würde. Aktuell schlagen sich alle Lager mit Fehleranfälligkeit, unklaren Deklarationen und tausend Zeilen Exception Handler herum. Hier weiß ein Angreifer nicht mehr, was er hören will und der Webserver ist überfordert beim parsen kryptischer Anfragen. Kommen wir nun zu meinem Vorschlag:

Titel: Remote File Inclusion Richtlinien
Author: Lukas Rist
Installation: Glastopf Project
Datum: 21. Juli 2009
weiterlesen »

Basierend auf einem Vortrag von Or Katz (Präsentation, Whitepaper) hat Ryan Barnett eine kurze Zusammenfassung der Ergebnisse geschrieben. Thema ist das Erstellen einer Regel um RFI Attacken aus Webserver Anfragen zu filtern. Um False Positives möglichst zu verweiden, werden verschiedene Erkenntnisse aus der Analyse von RFI Angriffen kombiniert. Der Artikel ist verständlich geschrieben und enthält die wichtigsten Punkte übersichtlich dargestellt.

Seit langen spiele ich schon mit dem Gedanken, dem Glastopf Web Honeypot ein IRC Log Bot zu verpassen. An sich eine nicht all zu schwere Aufgabe:
Im Folgenden möchte ich kurz erläutern, wie ich mir das vorstelle und worauf ich meine Lösung aufbaue.

class ircbot():
    """IRC client class"""
    def __init__(self):
        self.s=socket.socket()
        self.s.connect((server, port))
        self.s.send(nick)
        self.s.send(ident)

Hier definiere ich Variablen und verbinde zum IRC Server.

    def ircthread(self):
        """IRC client"""
        readbuffer = ""
        while True:
            readbuffer=readbuffer+self.s.recv(1024)
            temp=readbuffer.split("\n")
            readbuffer=temp.pop()
            for line in temp:
                line=line.rstrip()
                line=line.split()
                print line
                if(line[0]=="PING"):
                    self.s.send(PONG)

Dies ist der Prozess, der sich um die Kommunikation mit dem IRC Server kümmert.

    def sendfunc(self, message):
        """Sends the message to the IRC channel"""
        while True:
            if self.joined == True and message != "":
                self.s.send(message)
                message = ""
                time.sleep(2)
                break

Hiermit sende ich die Nachricht vom Glastopf an den IRC Channel.

if __name__ == '__main__':
    # Wir erstellen eine Instanz...
    bot = ircbot()
    # Starten die Kommunikation mit dem Server...
    ircthread = threading.Thread(target=bot.ircthread)
    ircthread.start()
    # Und schreiben in den channel:
    bot.sendfunc("Send this to the channel!")
    bot.sendfunc("Log this!")

Die ist das ungefähre Prinzip meines IRC Log Bots. Ich muss mir noch Gedanken über: Quits: glastopfbot (glastopfbot@ip) (Excess Flood) machen und wie der Bot reagiert, wenn er mit dem Senden von Nachrichten an den Server nicht mehr hinterher kommt. Da wir immer ein time.sleep() brauchen, kann, je nach Platzierung der Log Nachrichten, der Bot die Antwort an den Angreifer verzögern oder es könnte zum Timeout kommen.

Ein Aspekt bei der Analyse von Malware ist der verwendete Packer (wiki:en:Runtime Packer). Sofern ein Windows System als Analyse Gerät dient, ist wohl PEID (Projekt Seite) mit einer Trefferrate von ca.  60% bis 70% die erste Wahl. Mit Mandiant Red Curtain (Tool Page) hatte ich eine Trefferquote von ca. 18% und packerid.py von Jim Clausing (Artikel bei SANS.org), welcher pefile (google Code Projekt Seite) verwendet, kam auf knappe 10%. Verwendet wurde hierbei einer Signaturen Datenbank von Panda Security (Link zur db).

Ein weiteres, leider nicht frei verfügbares Tool, entwickelt von Toni Koivunen (Malware-Blog) ist Sigbuster. Verwendet wird es zum Beispiel von Anubis und Shadowserver. Letzterer veröffentlicht die gewonnenen Ergebnisse hier.

Das VRT (Vulnerability Research Team) hat vor kurzer Zeit ein neues Feature auf ClamAV.net veröffentlicht: Der “Active Malware Report” (Direktlink). Hier werden aktuelle Daten zu übersichtlichen Toplists und Grafiken zusammengefasst und hiermit ein schneller Überblick über aktuelle Ereignisse gegeben.
Die gesammelten Daten bestehen aus den Einsendungen von Freshclam (man freshclam) dem Aktualisierungsprogramm für ClamAV.

Schnucki versucht mehr über das Verhalten und die Methode von sogenannten Mail-Harvester (en:Wiki Web-Crawler) zu sammeln. Hierfür wird eine Liste mit generierten Mail Adressen erstellt, die alle mit einer anderen Methode verschleiert wurden. Weiterhin enthalten sie Informationen über den Zeitpunkt und die IP des Harvesters.

Schnucki der Universität Mannheim: Schnucki Mannheim
Christian Gorecki: Schnucki Gorecki
CCC Köln: Schnucki CCC

An der Universität Mannheim hat man den Entschluss gefasst, anstatt auf vielen Servern Honeypots zu installieren, einfach RFI Versuche auf einen einzelnen Honeypot/Server um zu leiten. Hierfür erweitert man seinen Apachen einfach um eine .htaccess Datei, die alle Anfragen die “=http://” enthalten auf http://link.informatik.uni-mannheim.de weiterleiten.