GlasBlog

Seit dem Changeset[159] unterstützt der Glastopf individuelle Antworten auf bestimmte Anfragen. Im Grunde genommen schauen wir nach, ob die Anfrage des Angreifers einer vorher definierten Seite entspricht.

Anfrage:

GET http://www.honey.pot/hackme/

Pseudo:

if custompage enabled:
    pageList = listdir("res/custompages")
        for p in pageList:
             if reqpath == p:
                 page = open(p.html)
                 send.page

res/custompages/hackme.html:

Hackme Custom Template
Template Content

Im Prinzip sind die Custom Pages simple HTML Files, können jedoch auch Listen mit bestimmten Dorks sein.

Nun bekommt der Angreifer eine seiner Anfrage entsprechender und durch den Benutzer definierte Seite geliefert. Das direkte Vergleichen von Anfrage und Name der Files ist etwas grob und vermutlich nicht immer zweckdienlich, aber ich denke, um die Funktion einzuführen, zumindest anschaulich.

Mögliche Anwendung: Dieses Feature ist eigentlich für Anfragen gedacht, die keinen direkten Angriff enthalten. So könnte man in den Requests nach Anzeichen für die Suche nach einem Mail Web Interface schauen und dem Angreifer ein entsprechendes liefern. Durch eine Erweiterung des Abgleichs von Anfrage und vorhandenen Custom Pages könnte man verschiedenen Suchmaschinen unterschiedliche Dork Listen liefern und daraus auf Teile der Angreifer-Methodik schließen. Ich denke es gibt noch weitere Möglichkeiten die evtl. interessante Anwendungsgebiete liefern  und bin gespannt, ob ich diesbezüglich Feedback bekomme.

Seit dem Changset[166] ist der Glastopf wieder in der Lage LFI Angriffe zu verarbeiten und sie in die Datenbank zu schreiben.
Per Regulären Ausdrücken schauen wir nach LFI Anfragen und servieren dem Angreifer die entsprechend von ihm aufgerufene Datei. Hierfür haben wir bisher statische Abbilder der Originaldateien die in Zukunft wohl etwas variabler gestaltet werden sollten. Das richtig Beantworten der Angreifer Anfrage bietet uns  die Möglichkeit, weitere Angriffe auf den Glastopf zu provozieren.
Die detaillierte Reaktion der Angreifer muss noch analysiert werden und könnte uns weitere Einblicke in LFI- und womöglich auch RCE-Angriffe (Remote Code Execution) geben. Bei letzterem versucht der Angreifer zuvor eingeschleusten und lokal auf dem Server abgelegten Code auszuführen. Eingeschleust kann der Code hierbei z.B. über Log Einträge beim Abspeichern der Anfrage oder Header des Angreifers. Auch das Fehler Log eignet sich hierfür.

Die dynamische Dork Liste, oder dyndork (Liebhaber nennen sie auch “Liste des Grauens”) ist eine Erweiterung des Grundprinzips von Glastopf. Als ein kleverer Mensch entdecke, dass man nicht aufwendige Templates, sondern lediglich die Pfade/Files in Klartext vorliegen haben muss, damit eine inurl:/path/to/file.php Anfrage an eine Suchmaschine uns trifft, war die Grundidee für den Glastopf gelegt. Die dyndork erweitert diese Idee durch mehr Masse. Angenommen, wir werden als Ziel auserkoren, dann belässt es der gewöhnliche Scanner nicht dabei, nach der gesuchten Schwachstelle zu schauen, sondern er macht sich die Mühe, so ziemlich alles Möglichkeiten in seinem Repertoire durch zu spielen, selbst solche, hätte er nach ihnen gesucht, wir wären nicht gefunden worden. Wir nehmen all diese Versuche, schreiben sie in eine Datenbank und erhalten damit eine relativ große Sammlung verwundbarer Web Anwendungen. Kommt nun ein Suchmaschinen Crawler bei uns vorbei, liefern wir ihm eine lange Liste, mit all diesen Datenbank Einträgen. Nun sehen wir für eine inurl Anfrage so aus, als hätten wir so ziemlich alles installiert, was es an verwundbaren Web Applikationen gibt. Was zu folge hat, das unsere Attraktivität für Angreifer durchaus ansteigt!
weiterlesen »

Die Jungs von DShield haben ihren Web Honeypot in den Beta Status gehoben. Viel Arbeit wurde mittlerweile in die Homepage des Projekts gesteckt. Hier kann man nun die wichtigsten Informationen nachschlagen und sich ausführlich mit den Hintergründen beschäftigen. Die einzelne Teams scheinen auch bestrebt aufzuzeigen, wohin das Projekt gehen möchte.
Die aktuelle Version kann man wie immer über svn erhalten.

Gestern wurde die Joebox 1.3.5 released. Hier, das offizielle Changelog:

• Now all executable files formats are analysed (exe, sys, dll, doc, pdf …)
• Some internal updates which speed up the abstraction process
• Added new chronological function section to analysis file
• Added possiblity to get raw csv and pcap data
• Added possiblity to queue submission if analysis machine is down

Heute habe ich endlich die Arbeit der letzten 10 Tage “ernten” können. Nach einer 5 stündigen Bug Session bin ich der Meinung man kann meine aktuelle unstable Version auf die Öffentlichkeit los lassen (changeset). Es gibt viel Neues und jede Menge Änderungen unter der Haube. Ich versuche hier und jetzt das Wichtigste in wenige Sätze zu fassen.

Folgende neue Module wurden implementiert:

Twitter Modul: Wie schon berichtet verwende ich eine Schnittstelle zu Twitter um aktuelle Statistiken aus der Datenbank zu “tweeten”. Das Modul ist noch sehr statisch, aber das Prinzip steht und wird nun kontinuierlich erweitert. Aktuelle Zahlen aus der zentralen Datenbank können hier abonniert werden.

IRC Modul: Quasi identisch zum Twitter Modul, mit dem Unterschied, dass man hier die Daten direkt abrufen kann. Das Modul formt aus der Anfrage ein MySQL Query und Antwortet mit dem Ergebnis. Dies bedeutet, wir haben keine endlosen Zeilen mit einzelnen Log Einträgen, sondern klar definierte Anfragen mit kompakten Antworten.

LFI Handler: Irgendwann ist er verschwunden und hiermit hauch ich ihm neues Leben ein. Glastopf ist nun wieder in der Lage Locale File Inclusions zu behandeln. Ich erhoffe mir dadurch Zahlen um die Häufigkeit der unterschiedlichen Angriffsmethoden vergleichen zu können. Des Weiteren möchte ich nach Remote Code Execution (RCE) Angriffen Ausschau halten. Hierfür ist die Emulation von LFIs unerlässlich.

Splash Modul: Endlich ein schöner Output beim Starten des Glastopfs!

Änderungen an bestehenden Modulen:

DynDork Modul: Bisher wurde die dynamische Dork Liste live bei jeder Abfrage durch eine Suchmaschine generiert. Dies kann 1. zu Timeouts und 2. zu einer steigenden Belastung der Datenbank führen. Um dies zu umgehen, kann die Dork Liste nun in definierten Zeitabständen generiert werden.

Unter anderem habe ich mich an die Säuberung des Codes gemacht. Ich bin jedoch mit den Zeilenumbrüchen noch nicht ganz glücklich, mal sehen ob sich da noch was ändert.

Pläne für die nächste Zeit:

Die aktuelle zentrale Datenbank wird um eine Zwischenstufe zur Validierung von eingesendeten Daten erweitert. Vermutlich ein Client/Server Setting.
Die Vulnerability Datenbank muss teilweise gereinigt werden und die Grundlage für eine Analyse der Daten sollte geschaffen werden.
Ich strebe eine geografische Auswertung der Angreifer IPs aus, Hilfe wurde mir bereits versprochen.
Der wichtigste Punkt ist die Überarbeitung des Vulnerability Emulators. Die Arbeiten sind schon weit fortgeschritten und ich strebe eine Implementierung in den nächsten zwei Wochen an.

Dionaea ist der direkte Nachfolger von Nepenthes. Wie bereits berichtet, soll Dionaea die Idee von Nepethes aufgreifen, erweitern und verbessern. Hierzu gehört eine Python Schnittstelle für Vulnerability Module, libemu um Shellcode zu identifizieren, IPv6 Support und die Unterstützung von TLS.

Informationen zur Installation findet man auf der Homepage von Dionaea. Im folgenden Text habe ich kleine Änderungen bei der Installation unter Debian dokumentiert. Der Entwickler war so freundlich meiner Unwissenheit zur Seite zu stehen.

Dionaea unter Debian:
weiterlesen »