GlasBlog

Mit der neue Schnittstelle wurde die Möglichkeit geschaffen, eigene Plugins für den Glastopf zu schreiben. Folgende Punkte sind zu beachten um ein funktionierendes Plugin zu erstellen:
Die Plugins werden in glastopf_root/plugins abgelegt und in glastopf_root/conf/glastopf.cfg in der Sektion [plugins] durch Kommas getrennt an den Punkt dataplugins gereiht:

[plugins]
#data handling plugins comma separated
dataplugins: surfids.py,mysql.py,newplugin.py

Das Plugin sollte die Funktion dbwrite(data): haben. data sieht folgendermaßen aus:

data = method, domain, sourceip, sourceport, destip, destport, attime, tzone, req, ref, agent, via, forwardedfor, xforwardedfor, xvia, onspdusr, host, alive, filename, victim

Alles weitere ist dem Entwickler des Plugins überlassen.

Seit dem Changeset 177 besitzt der Glastopf eine Plugin Schnittstelle. Das MySQL Modul wurde in ein Plugin umgeschrieben und das alte Modul kümmert sich nun um das Laden der Plugins und das weiterreichen der Angriffs-Daten. Außerdem habe ich mit der Hilfe von Kees Trippelvitz das SURFids Plugin fertig gestellt. Hiermit können nun die gesammelten Daten in die SURFids Datenbank geschrieben werden.

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.

Jan hat die neue Version von Amun veröffentlicht.

Changes in v0.1.8:
– added ulm shellcode handler
– added bergheim shellcode handler
– added langenfeld connectback2
– added leimbach encoded tftp command detection
– added pexalphanumeric b64encoded plain url detection
– added new amun smb handler
– fixed netdde vulnerability
– fixed missing socket import for log-blastomat module
– fixed reply function to send all bytes
– fixed amun crash on already used port/address
– fixed anubis submission module
– fixed amun ftp NAT download
– modified ftp_download_core to handle broken pipe on push command
– modified vuln-http to serve images from folder
– modified log-surfnet configuration to accept database port
– modified vuln-arc to no reply
– modified md5 to hashlib (deprecated warning)
– modified popen2 to subprocess (deprecated warning)
– removed conn= parameter prefix for asynchat.async_chat.__init__

Ich habe dem Glastopf eine Schnittstelle zum einfachen Hinzufügen von Plugins spendiert. Vorerst nur Plugins welche die Daten eines Angriffs verarbeiten. Standardmäßig schreibt der Glastopf in eine SQL Datenbank. Möchte man die Daten nun zusätzlich oder ausschließlich woanders ablegen, lässt sich dies sehr einfach über die neue Schnittstelle realisieren:

Die Plugins werden in der glastopf.cfg aufgelistet. Hier ein Beispiel für das surfids Plugin:

[plugins]
#data handling plugins comma separated
dataplugins: surfids.py

Die dort gelisteten Plugins werden im dbmysql Modul geladen:

dataplugins = plugins_opts["dataplugins"].split(",")
datapluginlist = []
for plugin in dataplugins:
    pluginname = plugin.strip().partition(".py")[0]
    importname = __import__(pluginname)
    datapluginlist.append(importname)

Haben wir nun einen neuen Datensatz eines Angriffs, übergeben wir diesen an alle geladenen Module:

if datapluginlist:
        for plugin in datapluginlist:
            data = method, domain, sourceip, sourceport, destip, destport, attime, tzone, req, ref, agent, alive, filename, victim
            plugin.dbwrite(data)

Aktuell arbeite ich mit Kees an dem SURFids Plugin. Außerdem würde ich aus dem MySQL Kram auch gerne ein Plugin machen um die Ganze Geschichte etwas zu entwirren.

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 »

BitBlaze ist ein Malware Analysis Service für PE Files. Auf dem virtuellen System laufen drei Dienste die für die komplette Analyse zuständig sind:

• Renovo: Hidden Code Extractor (Unpacker)
• HookFinder: Malware Hooking Behavior Detector
• Panorama: System-wide Information Tracking

Renovo kümmer sich, grob gesagt, um das lokalisieren und sammeln von eigentlich gepacktem Code. Dafür überwacht er den Arbeitsspeicher und macht sich dabei zu nutzen, dass jeder gepackte Code während seiner Laufzeit, irgend wann ungepackt vorliegt.
Publication: “Renovo: A Hidden Code Extractor for Packed Executables.”, Min Gyung Kang, Pongsin Poosankam, and Heng Yin. In The 5th ACM Workshop on Recurring Malcode (WORM), Oct 2007 [PDF]

Hookfinder detektiert hooking Verhalten der Malware.
Publication: “HookFinder: Identifying and Understanding Malware Hooking Behaviors”, Heng Yin, Zhenkai Liang, and Dawn Song. In Proceedings of the 15th Annual Network and Distributed System Security Symposium, February 2008. [PDF]

Panorama ist für die Überwachung des gesamten Systems zuständig. Hierbei wird nach sogenanntem Malicious IAP (Information Access and Processing) Verhalten Ausschau gehalten.
Publication: “Panorama: Capturing System-wide Information Flow for Malware Detection and Analysis.”, Heng Yin, Dawn Song, Manuel Egele, Christopher Kruegel, and Engin Kirda. In Proceedings of ACM Conference on Computer and Communication Security, Oct 2007.[PDF]

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.