Black Hat Europe 2010 – wie isses?

Aus der beliebten „wie isses“ Reihe, diesmal die Black Hat Europe 2010 in Barcelona. Während des Kongresses wird der Artikel unregelmäßig aktualisiert.

Black Hat Europe 2010 in Barcelona. Wer auf deutlich besseres Wetter gehofft hatte (so wie ich), der wurde enttäuscht.

Day 1: Regen..

Ansonsten mal wieder super Organisation. Keine Vorabendveranstaltung, nicht mal ein Treffpunkt, der angekündigt wurde. Zumindest das war letztes Jahr noch möglich und der Abend damals – sagen wir mal sehr nett. Ob und wo es Frühstück geben würde, war bis zum Gang zum Fahrstuhl heute morgen nicht klar. Es gab eines und nicht nur Continental. Made my day.

Eröffnung durch Jeff Moss

Das Erste war ein Nokia N900 bashing. Großartig wäre die Möglichkeit nmap, metasploit, etc zu nutzen, aber die Telefonie-Funktionen sind nichts. Dies ist also die größte Blackhat Europe, die es jemals gab, dieses Jahr 100 Leute mehr, als letztes Jahr. 53 Deutsche sind da, 58 Amerikaner und sogar einer aus Australien, aha.
Danach sprach er über Geotagging von IP-Adressen. Derzeit kann man anhand der Adresse nicht zwingend sagen, wo ein Angriff wirklich herkommt. Daher: „get some agents in there, and spy ‚em“, sehr old school. Technische Lösungen springen hier nach Jeff zu kurz. Spannender Ansatz für eine Techie-Konferenz.

Keynote Max Kelly, CSO Facebook
Die Einführung durch Jeff Moss war eine Lobrede auf Facebook, leider kein Wort zu der aktuellen Diskussion bzgl. der Weitergabe von Nutzerdaten. Viele der Sicherheitsmechanismen von Facebook seien sehr spezifisch:
Axiom 11 (angelehnt an Zombieland): that feature can be used in a way that you didn’t think of. try and find out what it is.
Vor Jahren wurde die „Friend Finder“ Funktion ausgenutzt. Man konnte dabei Mailadressen etc hochladen. Einer hat eine Spamliste von Mailadressen hochgeladen und dabei feststellen können, dass unter der Mailadresse ein Facebook-Account existiert. Nice 🙂
Lösung: Nicht technisch, sondern „legal methods“. Sehr l33t. Wir schalten das Feature nicht ab, auch wenn es mißbraucht werden kann und künftig suchen wir jeden, der das macht. Aber: Das war zu teuer. 50.000 USD um einen zu bekommen, der ein Feature mißbraucht. Aber man macht es weiterhin so: „we will pursue attackers of any type“, etc, etc, etc – gruselig.. In erster Linie sagt also der CSO von Facebook, dass man in erster Linie sich mit der Androhung von Klagen verteidigen will. Dafür werden natürlich massiv Daten benötigt, IP-Adresse, Zeitstempel, User-Agents, Requests..
Aber wir respektieren das Vertrauen, dass die User in uns setzen..
Was bei Facebook wichtig ist, wir sind immer noch sehr wenig Leute (~1.200) und können nicht alles lösen, was wir eigentlich wollen. Deshalb arbeitet man mit der „Security Community“ zusammen. Wenn man also einen Bug findet, der sich auch für einen Angriff ausnutzen lässt, bekommt man nicht nur Credit, aber – heyhey – wir werden Dich nicht vor Gericht zerren..

Axiom 23: Intelligent is king, make every user interction give you some sort of intel. Then, build the tools on it and act on it. Ergo: Sammle Daten, mehr Daten, mehr Daten. Speichere sie, werte sie aus. Es sei toll, wie einfach es ist auf Basis der Art, wie ein Nutzer Facebook nutzt, diesen zu identifizieren. Toll.

Axiom 12: compliance isn’t security
Put it off as long as you can. If you’re doing things right, it wont be hard to codify.
Also: Wenn man klein ist: Renn nicht Compliance hinterher, das ist Zeitverschwendung. Erstaunlich kurz gesprungen, wenn man Compiance nachträglich etablieren will, wird es aus unserer Erfahrung heraus um ein Vielfaches teurer und schwieriger, da „Freestyle“ kein gemeinsames Sicherheitsverständnis etabliert werden kann, Compliance ist nicht alles, sicherlich, aber es hilft unglaublich, alle Mitspieler zu identifizieren.

Anstatt auf Threats und Vulnerabilities zu schauen, soll man sich lieber die Angriffe anschauen. Warum? Um auf die Angreifenden zu kommen. Denn wenn man die Angreifer erwischt, gibts keine Angriffe mehr. Klar oder?
Wie macht man das?
– ignore vulnerabilites
– know about threats, but be realistic
– spend your time watching attacks
– target the actors, frustrate them by making their attacks too hard

Axiom 31: ask your users for help. they want to,
Ich glaube, das macht derzeit Facebook recht erfolgreich. Der User hat den Eindruck, er darf mitmachen. So werden die User z. B. zur Übersetzung von Inhalten benutzt. Also eine Art FSJ für Facebook 🙂
Das Gleiche macht man für Spam-Erkennung. Wenn nur genug User einen Spammer melden, ist es wohl einer. Aber tatsächlich kommen hier auch technische Methoden zum Einsatz, z. B. rate limiting, anomaly detection, etc.

Legal-Arsenal
Man, man, so ne Angstmacherei: Jede gesendete Spam-Nachricht kostet 100 USD nach amerikanischer Rechtssprechung. Das mag sein, aber „der Feind“ ist nicht da und es dürfte ihn vermutlich auch wenig interessieren..

Spam-Bekämpfung
Man braucht einen Account mit Freunden, um über Facebook zu spammen. Den man kann ja Nachrichten nur an seine virtuellen Freunde senden. Nach Aussage von Max erkennen die FB-Systeme einen Angriff erst dann, wenn die Nachrichten versendet werden. Da man davon ausgehen kann, dass die Übernahme von Accounts leichter zu erreichen sein dürfte, als einen Fake-Account mit Freunden voll zu bekommen,  ist folgender Schluss zumindest zulässig: Die Übernahme von FB-Accounts ist aufgrund schlechter proaktiver Absicherung derzeit häufige Realität.

Wenn Script-basiert Spam versendet wird, wird natürlich der Sender mit der aller Härte des Gesetztes verfolgt, aber auch versucht, die Scripte zu identifizieren und damit ausschließen zu können. Und nicht zu vergessen: Die User informieren FB ja über Spam.
Die gezeigten Facebook-Sucess-Stories waren allesamt gewonnene  Gerichtsverfahren gegen Spammer. Und eines sogar in Kanada. Das ist doch toll oder?

Fragen
Geil war die Nachfrage: Macht Ihr mehr Bugs, damit Euer Geschäftsmodell Spammer zu verklagen besser aufgeht? Ich hab mal kräftig applaudiert.
Antwort: Nein, wir sehen das Geld ja meistens nicht.
Frage: Wieviele Leute habt Ihr im Security-Department?
Antwort: Core-Security Team sind ca 20 Leute. In weiterem Sinne wohl ca. 20% der Firma.
Frage: Wie gut ist die Beziehung zwischen Security und CEO?
Antwort: Wir sind sehr klein, die Beziehung ist gut, wir berichten regelmäßig an das Management.
Frage: Macht Ihr Werbung mit Hilfe von Third-Party-Networks?
Antwort: Ja.
Frage: Wie verklagt Ihr Angreifer aus anderen Ländern?
Antwort: Zuerst verklagen wir ihn in Kalifornien, wenn das Urteil steht, gehen wir in das Land des Spammers und versuchen ihn dort ebenfalls zu verklagen.
Frage: Ist bei FB Security und Privacy zusammen organisatorisch aufgehängt?
Antwort: Ja. Da Security und Privacy sehr nah zusamen liegen, sind wir auch für Privacy zuständig.
Nachfrage: Wie stehst Du zu Sharing Data mit Dritten?
Antwort: „Sharing Data is not what a security guy should support“, aber es ist Teil des Business Models.

Insgesamt wirklich wenig technische Infos, aber Max Kelly hat sehr klar gemacht, wie Facebook tickt. Daten sammeln, auswerten und statt proaktiv zu verteidigen, reaktiv Angreifer vor Gericht stellen. Der User als „Schwarm-IDS“. Sehr, sehr grußelig Mr. Kelly.

FX: Defending the Poor
Es geht um Flash-Security. Der Vortrag wurde auf dem 26C3 bereits gehalten (auch interessant, dass auf der Black Hat Europe 2010 bereits gehaltene Vorträge akzeptiert werden), da war ich aber nicht, also los 🙂
Zuerst gabs mal zur Abwechslung eine Lobeshymne auf das BSI – sie kümmern sich mehr um den Enduser, als um die „Government-Networks“ 🙂
Für wen ist Flash Security also interessant? Für Enduser, wie die armen Mac-User, die einen G3 nutzen und ab jetzt keine Updates mehr von Adobes für den Flash-Player bekommen, aber auch für die Webseiten-Betreiber natürlich.
Basics: Wer den Flash-Plugin nutzt, nutzt ihn erstmal unabhängig vom Browser. Der Speicher, der genutzt wird, ist der von Flash, nicht der des Browsers. Es gibt zwei Sandboxes, local und remote. Diese sind aber nicht separiert. Flash Code kann die Same Origin Policy von Browsern durch die remote Sandbox aufweichen.
Was kann der User machen: Nicht viel – der FlashApp Rechte zuweisen, z. B. Audio/Video und Flash aktuell halten. Es gibt jedoch leider keine Möglichkeit, Flash-Code zu signieren.
Was gibt es für Schwachstellen gegen Flash: Aufgelistet recht alte Beispiele, wie z. B. Daten in den Zwischenspeicher kopieren. Erfolgreiche Angriffe der Vergangenheit sind u. A DNS rebinding, Cklickjacking, HTTP-Header Injection, etc.

Im Folgenden gabs noch eine Auflistung von Flash Malware Typen, die tatsächlich verbreitet worden sind: Banner advertisements, Browser forwarder, arbitary code execution

Was ist also das Problem mit Flash, andere Software ist ja auch buggy. Flash malware wird derzeit von Antivirus-Software schlecht erkannt. Bei Virustotal werden bekannte Exploits nur zwischen 30% und 70% erkannt. Sobald man den Flash-Code leicht ändert, geht die Rate dramatisch runter. Weiteres Problem: Zig Versionen der Flash-Spezifikationen werden aktiv verwendet, ähnlich wie bei PDF. Darüber hinaus gibt es zwei virtuelle Maschinen innerhalb von Flash, AVM1 und AVM2. AVM1 ist sehr alt und historisch gewachsen. Ca. 80-90% der Seiten, die Flash nutzen (u. A. auch youtube), nutzen AVM1, da die AVM2 von Actionscript >=3 verwendet wird.

Intern spannend ist z. B. die Möglichkeit mittels function declaration eine Funktion über den Stack zu definieren. Also „spring an diese Stelle im Stack, da ist Deine Funktion“. Auch interessant: FX hat bei seinen Nachforschungen ein if-Statement mit einem großen Body geschrieben, welches niemals zur Ausführung kommen sollte (also z. B: if (1=2)). Was passierte: Aufgrund fehlender Sicherheitsmechanismen lief der Speicher mit dem Body der if-Funktion, die nicht TRUE wurde voll und der Rest wurde ausgeführt.

Vor was will man sich also schützen:
– böse SWF Daten, die buffer overflows verursachen
– gute SWF Daten, die die Player API zu bösen Zwecken nutzen

Da niemand einen „sicheren“ Flash-Player bauen möchte, parsed man vor der Ausführung beim Client compliance und schreibt ein neues, normalisiertes Flash-File. Dieses wird dann zur Ausführung gebracht. Dadurch kann man auch Policies verteilen, was in Flash passieren darf und was nicht.
FX und Co haben ein Tool namens Blitzableiter in C# geschrieben, welches genau das implementiert. Die Folien mit den Details finden sich hier.

Mein Fazit: Adobe (PDF und Flash) entwickelt sich derzeit zum größten „Malware-Verteil-Helfer“ aller Zeiten. Ob man dem Problem schlechter Software mit weiterer Software wirklich Herr werden kann, sei mal dahin gestellt.

Roelof Temmingh: Unveiling Maltego 3.0
Die neue Version von maltego wurde vorgestellt. Das Tool ermöglicht es, passive information gathering von Hosts im Internet durchzuführen. Es stellt die Informationen grafisch dar. Im Endeffekt ein nettes Frontend für Tools wie robtex oder ähnliche. Hierfür werden Informationen wie Netblocks, Links, etc genutzt. Mit den neuen Funktionen, kann z. B. auch twitter-Nachrichten monitoren und in Verbindung setzen.
Dank custom entities kann man z. B. auch eine pcap-Datei importieren und grafisch darstellen.
In der ersten Demo wurde Maltego mit CIPRO (ein Index aller Firmen in Südafrika) gekoppelt. Man erstellt zunächst ein neues Datenfeld mit verschiedenen Datentypen (String, Date, Bool, etc).
Vorgestellt wurde anschließend das Konzept von Named Entitiy Recognition (NER): Ein Tool markiert Entitäten wie Namen, Firmennamen, Telefonnumern, etc. Im Beispiel wurde ein Nachrichtenmeldung aus Afrikaans genommen und per Google Translate in Englisch übersetzt. Dann in ein NER-Tool (hier OpenCalais) geparsed und die schlechte Übersetzung analysiert. Dabei wurden das Thema, Personen, Firmen und Events & Facts analysiert. Wer braucht sowas? Also Sprache in Text, in Englisch übersetzen, NER laufen lassen und die Entitäten in NER in eine DB schreiben und die Ergebnisse in Beziehung setzen. Man nimmt als Quellen OpenSource-Quellen Fernsehen, Radio und Internet und Closed Source Quellen wie Telefongespräche und SMS. Durch die Möglichkeit die Daten in Verbindung zu setzen, erhalten Dienste eine hervorragende Möglichkeiten öffentlich dokumentierte Ereignisse mit privater Kommunikation zu korrellieren.
In Maltego nutzt man NER um Sätze zu typisieren und damit die Frage „wer/was/wer steht in Verbindung mit dieser oder jeder Aussage“ zu beantworten. Beispiel: Man nimmt „uranium enrichment“ als Text in PDFs und dieses Wort ist auf diesen und diesen Webseiten angeführt (Quasi eine Google-Suche nach „uranium enrichment“ filetype:pdf). Aus dem Ergebnis extrahiert man die URLs, auf denen die PDFs liegen und diese werden analysiert, um Verbindungen aufzuzeigen. Das Ergebnis ist eine große, große Fülle an Informationen. Diese kann man z. B. auswerten nach Referrer, so kann man z. B. auf Personennamen, Länder filtern. Das Ergebnis, welche Länder mit „uranium enrichment“ in Verbindung stehen aufgrund einer Webanalyse ist sehr nah an der Realität.
Warum also NER für maltego? Das gleiche Prinzip kann man auf WHOIS Informationen anwenden. Die Demo (leider alles Videos) zeigte als Beispiel bmw.com, dann wurden die Webseiten angezeigt, auf IP-Adressen aufgelöst und man sieht welche IP-Adressen verwendet werden. Damit kann man z. B. erkennen, welche IPs für mehrere Webseiten genutzt werden und welche mit nur wenigen URLs in Verbindung stehen. Man löscht nun alle „BMW“-Informationen aus den verbleibenden WHOIS-Einträgen und man erhält die verbleibenden.
Nächstes Beispiel ist facebook: Facebook will leider nicht mehr, dass maltego den Code released, um Verbindungen zwischen den FB-Usern aufzuzeigen. Man könnte die FB-API nutzen, diese hat aber Limitierungen. Man durchsucht also FB, mit einem Scrape-Tool gehts aber auch nicht. Man nimmt also die Facebook Query Language, nimmt mobile Seiten und die Ajax Calls. Es gab einen Bug, mit dem man alle Verbindungen über einen Ajax-Call aufrufen konnte. Mehrfach wurde darauf hingewiesen, dass man das nicht machen soll, da FB mit Anwälten droht. Das hab ich heute schonmal gehört.
Als Satz nimmt man asl Suche „gmail.com facebook contact“, man erhält 12 Mailadressen, daraus kann man die Facebook-Accounts extrahieren. Daraus kann man die Freunde auslesen und in Verbindung setzen. Maltego macht sogar Thumbnails der Bilder.
Nimmt man nun NER dazu. Neue Suche nach „Blackhat Briefings“. Als Ergebnis eine Liste der Seiten mit dem Suchbegriff. Daraus extrahiert man die URLs, nimmt diese und extrahiert alle Personen, Orte etc. Man erhält als Ergebnis der Orte alle Orte, an denen es Blackhats gibt/gab, aber auch Länder von Personen, die auf den Black Hat Briefings sprechen. Extrahiert man die Personen, kann man diese in Facebook nachschlagen und wiederrum Beziehungen erkennen. Damit kann man z. B. häufige Namen aufgrund der Freunde zuordnen, ob sie wirklich die Gesuchten sind.

Insgesamt recht spannend, für die Analyse von Zusammenhängen von WHOIS-Records sehr gut geeignet.

Paul Stone: Next Generation Clickjacking
Das Konzept hinter ClickJacking ist, dass ein Script in der Lage ist, Informationen aus anderen Seiten (oder gar lokalen Daten) abzuziehen. Das Same-Origin-Prinzip in Browsern verhindert eigentlich, dass Scripte dies durchführen können. Ein Beispiel: Klickt jemand auf einen manipulierten Twitter-Tweet Button, bringt man seinen Code zur Ausführung. Legt man einen unsichtbaren Click-Button über den eigentlichen Button.
XSS gibt einem Angreifer volle Kontrolle über die Session und die Daten des Benutzers, CSRF erlaubt nur das Ausführen eines Requests, die Antwort sieht der Angreifer nicht. Mit ClickJacking führt man Klick aus, so dass man z. B. Warnmeldungen bei Änderungen des Datenstroms „für den Nutzer“ anklickt. Man muss als Angreifer also genau wissen, wo sich der Button, den der Benutzer eigentlich klickt, befindet, um den eigenen Button darüberlegen zu können. Um dies zu vereinfachen, nutzt man element-ids aus HTML (z. B. anchors wie lala.html#ueberschrift1). Sobald eine element-id vorliegt, kann man diese einfach finden.

Beispiel 1: Text Field Injection
Die Drag&Drop API – in HTML 5 spezifiziert – hat keinen Schutz nach dem Same-Origin-Prinzip. Somit kann man per Drag&Drop Daten zwischen zwei Seiten hin und her kopieren. Man benötigt hierzu wieder den transparenten Button mit einem eigenen Iframe, dann verschiebt der Nutzer die Daten, der Angreifer setzt den „bösen“ Code und dieser wird zur Ausführung gebracht. Im Beispiel wird damit ein Spiel realisiert, in dem man einen Frosch hin und herschiebt. Damit kann man z. B. eine andere Seite laden und etwa ein Twitter-Update posten. Webmailer sind ein weiteres Beispiel.

Beispiel 2: Text Selections
Wenn man einen Benutzer dazu bringt, sensitiven Text zu markieren, kann man diesen extrahieren. Man benötigt jedoch zwei Drag&Drops durch den User. Praxisrelevanz: Naja.

Beispiel 3: Forced Drag and Drop
Die Java DnD API in Java Applets kann aus einem Klick heraus die Maus bewegen. JS kann das erzwingen. Damit kann man mit einem Klick des Users permanent C&P durchführen. Nice.

Gegenmaßnahmen:
Für alle Angriffe werden hidden-iframes genutzt. Daher kann man die X-Frame-Option (eingeführt durch Microsoft in IE 8!) bzw. JavaScript nutzen. Allerdings ist diese Methode nicht 100%-sicher.

Wirklich Neues hat der Vortrag nicht gezeigt, lediglich die Nutzung des JavaApplets für automatisches Drag&Drop war mir neu. Auch hier (wie beim Harvesting-Teil von Maltego) war die Message: Am verwundbarsten sind die mobilen Seiten (wie etwa die von Facebook, Twitter, Xing, Gmail, etc). Am Einfachsten kann man die Anfälligkeit prüfen, ob eine Seite in einem Iframe lädt, oder nicht. Hierfür hat Paul das Content Application Tool geschrieben. Ebenso ein Angriffs-Tool namens „Clickjacking Tool“ – sehr kreativer Name, aber dennoch einen Blick wert.

Mariano Nuñez Di Croce: SAP Backdoors: A ghost at the heart of your business
Angegriffen werden soll der SAP IT Application Layer, (also nicht Logic Layer, Datenbanken oder Betriebssystem-Ebene). Problem Nummer 1: Rückwärtskompatbilität
Die Passwörter können von 8-Zeichen MD5-Hashes bis zu 40-Zeichen SHA-1 Hashes reichen. Wenn ein altes System mit einem neuen verbunden werden soll, greifen nur die schwachen Mechanismen. Also gibt es im User Master beide Hash-Tabellen. Es gibt also mehr als einen Hash pro User. Das System entscheidet anhand eines Parameters, welcher Hash verwendet werden soll. Der Parameter muss dafür privelegiert sein.
Demo: Der bereits privelegierte Nutzer greift auf die Passwort-Hashes des SAP*-Users zu. Im Debug-Mode kann er den Code verändern, so dass eines der beiden Passwort-Felder verändern kann. Durch das Ändern des Login-Parameters kann sich der Administrator mit seinem eigenen Passwort anmelden, der Angreifer ebenfalls mit seinem eigenen Passwort, da ein Fallback existiert, so dass wenn ein Hash nicht passt, wird der zweite Hash genommen.

Eine weitere Demo: Ein priveliegierter Benutzer lädt remote ein neues ABAP-Programm in die Datenbank und anschließend werden alle Bankdaten auf den Angreifer umgebogen. Dafür muss die DB allerdings remote erreichbar sein, der Angreifer Schreibrechte auf der DB haben und einen SAP-Benutzer unter seiner Kontrolle haben. Naja.

Einige kritische ABAP Programme wie Transaktion SE80 sind in der Datenbank, in der der Source-Code liegt, geschützt. Das ganze läuft über eine harte Routine im Kernel. Aber: Der Check läuft anhand des Programmnamens. Also kopiert man den Inhalt von z. B. SAPMSYST (verantwortlich für den Login) in der Datenbank. Allerdings muss man dafür den SAP-Server neu starten. Dafür braucht er auch wieder hohe Privilegien im SAP-System. Und „from an attackers point of view, it might be a little bit noisy“. Tools hierfür werden in der kommenden Woche veröffentlicht.

Weiterhin interessantes und heißes Thema, aber für die gezeigten Angriffe benötigt man sehr viele Privelegien im Vorfeld.

Enno Rey & Daniel Mende Hacking Cisco Enterprise WLANs
Ziel des Researches von ernw war die Implementierung der kryptografischen Elemente des Cisco Enterprise WLAN. Das Hauptproblem ist, dass Cisco verschiedene Elemente (LEAP, WLCCP) kombiniert hat und Schwächen versucht hat, mit weiteren Elementen auszugleichen.
Wenn man kabelgebunden-Zugriff auf das WLAN erhält, z. B. an einem AP, identifiziert man den WLCPP master (Management-Protokoll) und snifft den Intra-AP-Traffic. In der Demo haben die APs sich bereits einen WLCPP master ausgesucht. Mit einem eigenen Tool „loki“ wird der Traffic mitgeschnitten. Um die Inter-AP Kommunikation mitzuschneiden, wird die Kommunikation zwischen Master und den beiden APs per ARP-Poisoning mitgeschnitten. Dann wird ein zweiter Master mit höherer Priorität vom Angriffssystem gestartet. Die Clients verlieren daduch den Kontakt zum Master. Da der neue Master nicht antwortet, läuft ein Fallback und eine Neuanmeldung an den eigentlichen Master. Durch den MitM-Angriff kann man die Anmeldedaten mitlesen. Damit erhält man alle notwendigen Daten für das Mitschneiden des Traffics und das verschlüsselte Management-Passwort. Da dieses mit LEAP verschlüsselt ist: Kein Problem.

Das aktuelle Cisco-Produkt Cisco Unified Wireless Network CUWN nutzt das bekannte CAPWAP-Protokoll. Der RFC sagt, wenn CAPWAP in Ipv4 Netzwerken eingesetzt wird, muss die Checksum null sein. CAPWAP nutzt Zertifikate und erwies sich die letzten Jahre als recht robust und sehr weit verbeitet. In der Implementierung von Cisco wurde eine sehr alte Implementierung von OpenSSL verwendet. Die Zertifikate werden während der Herstellung der Geräte verteilt. Auf der Management-Station ist SNMP standard-mäßig aktiviert mit den Community-Strings public/private 🙂 Ein HTTP(S) ist ebenfalls verfügbar. Syslog-Nachrichten werden standardmäßig gebroadcastet m(.
Durch Veränderungen am HTTP-Datenstrom kann man die Kiste zum Abschuss bringen.

Insgesamt nettes Cisco-Bashing und das zurecht (auch wenn beim Q&A Wert darauf gelegt wurde, dass es kein Cisco-Bashing ist). Teure Enterprise-Lösungen sind verwundbar gegenüber einfachsten Angriffen. Das Q&A der Hersteller muss dringend verbessert werden. Vielleicht mal ein paar Pentester/Researcher einkaufen, damit solche Probleme nicht bei Kunden-Assessments auftreten 😀

Ende Tag 1, Tag 2 kann kommen..

Tag 2: Sonne..
So, Tag 2 der Black Hat Europe 2010 in Barcelona. Der Abend war sehr launig, ich danke den Anwesenden. Da hat mir es fast nichts mehr ausgemacht, 8,50 EUR für ein Bier an der Bar zu bezahlen. Der Schwabe in mir hat rebelliert, aber gut. Das Frühstück war gut, der Internet-Zugang heute nacht allerdings sehr langsam. Sowohl mit als auch ohne ptunnel. Wenigstens war das Canceln der 8 EUR/Stunde kein Problem 🙂

Thai Duong & Juliano Rizzo: Practical Crypto Attacks Against Web Applications
Erster Vortrag, heute nicht in Kongresszentrum, sondern direkt im Hotel. Eigentlich egal, aber hier gibts weniger Platz. Die beschriebenen Angriffe drehen sich zunächst um Verschlüsselung mit Padding-Verfahren. Wie findet man Tools, die das nutzen? Klar, google. Keywords z. B. javax.crypto.BadPaddingException.
Das Padding Oracle Exploitation Tool (wird bald released), soll das Ganze vereinfachen.
Das Verfahren, dass die beiden demonstrieren, eignet sich auch zur Umgehung von Captchas, je nach deren Implementierung. In diesem Fall eben nicht durch OCR-Mechanismen, sondern Crypto-Analyse, so dass der Inhalt des Bildes keine Rolle mehr spielt. Eine Demo ging lokal gegen den ViewState von JavaServerFaces (JSF). Der Viewstate wurde verändert (AAA), so dass durch eine Fehlermeldung klar wurde, dass der Input 16 Byte lang sein muss. Mit dem Tool wird jeder Block einzeln entschlüsselt, online per HTTP-Request. Dabei wurde das Padding letztlich brute-forced, um die einzelnen Blöcke zu entschlüsseln. In einer Demo wurde das Captcha auf www.bidz.com mit Hilfe eines lokalen Javascripts erfolgreich brute-forced. Auch hier wieder Block-By-Block. Die Performance ist nicht sonderlich hoch, aber für Angreifer auf jeden Fall besser, ein paar Rechner laufen zu lassen, als manuell etwas einzutippen. Ein Video sollte bald im Youtube Channel von Thai Duong zu finden sein.

Die Demos haben leider nur teilweise funktioniert, der Vortrag wirkte leicht konfus. Schade, die Reaktion des Publikums (keine?) zeigte mal wieder, dass eben genau bei Kryptographie ein sauberer Vortragsstil notwendig ist. Das Tool ist sehr hübsch. Und: Das Gemurmel der beiden bei Problemen hat mich sehr an the one and only Bob Ross erinnert 🙂 The Joy of Hacking. Nuja.

Christian Papathanasiou: Abusing JBoss

Ja da bin ich ja mal gespannt, ob der Christian mehr erzählen kann als was zu ungeschützten Admin-Interfaces.
Zunächst nichts Neues, jmx-console per Default offen, JBoss läuft meist als root/SYSTEM-Benutzer und juhuuu, wir werden eine neue Version des uralten Exploits von RedTeam sehen. Läuft auf einer ungeschützten JBoss-Installation, sehr l33t. Der Upload war übrigens eine Shell, ebenfalls von jemand anderem geschrieben.
Das Tool jboss-autopwn automatisert das ganze. Man nehme einen ungeschützten JBoss-Server, lade mit msfencode mehrfach encodete Reverse-Shell hoch (natürlich auch aus metasploit) und klick, ist man root. Wow – ein Script um Public-Domain-Wissen und schon spricht man auf der Black-Hat.
Zweiter Teil, Tomcat: Wenn man einem Tomcat Default-User die Rolle Manager gibt, ist der Server unsicher. Um es nochmal klar zu sagen: Nimmt man einen Standardbenutzer und ein Standardpasswort, ist der Tomcat unsicher. Spätestens jetzt bin ich geflashed. Knaller. Achja, es gibt natürlich auch tomcat-autopwn.

Fazit: Das ist mal ein wirklich selten enttäuschender Vortrag. Aber gut, Trustwave ist ja Sponsor, da sollte man wohl drüber hinweg sehen, oder doch nicht?

Steve Ocepek & Wendel G. Henrique: Oracle, Interrupted: Stealing Sessions and Credentials
Der nächste Vortrag von Trustwave, aber Wendel hat mir nach dem lahmen JBoss Vortrag seines Kollegen versprochen, dass mein Fazit hier besser sein wird. Also gut.
thicknet injection ist ein Tool, um in Oracle-Session einzugreifen. Mit Hilfe eines eigenen ARP-Poisoners (warum nicht arpspoof bleibt offen). Also toll, man startet, danach thicknet und erhät eine Shell im Tool. Baut jemand eine Verbindung zum Oracle-Server auf, übernimmt das Tool die Session und man kann eigene SQL-Kommandos in der Session absetzen, z. B. einen neuen User einrichten. Da die Session übernommen wurde, ziehen die Rechte desjenigen, der ursprünglich die Verbindung aufgebaut hat.
Nachdem uns gesagt wurde, dass ARP-Poisoning in den 80ern cool war, wurde es nochmal ausführlich erklärt. Ich zweifle, dass es für irgendwen interessant war, aber ok. Achja, der TCP 3-Way Handshake wurde ebenfalls erklärt, wohoo again. TCP-Hijacking in a nutshell: Wenn man in einer bestehenden Verbindung „mitreden“ möchte, kann man entweder Pakete modifizieren oder die Verbindung übernehmen. Jaja. Beim Übernehmen der Verbindung muss der eigentliche Client ausgesperrt werden und die Sequence-Numbers, etc übernommen werden.
Will man nun eine Oracle-Verbindung übernehmen, sieht man erstmal nur TNS (in Wireshark), aber nicht die Payload in Net8 (nicht bekannt, keine Parser). Darauf fokussierte der Research. Drei Requests in Net8 wurden erkannt, User-to-Server bundled call, Piggyback calls (Management-Pakete) und User-to-Server fetch. Die Sequence-Numbers von Net8 werden sequentiell hochgezählt. Nun wartet man auf ein Paket vom Client mit Payload (z. B. SELECT) und modifiziert dieses. Was natürlich verändert werden muss, ist das IP length field, sowie Sequence-Number, Acknowledgement-Number, etc. Das Tool passt im Data-Layer noch in das TNS length-field und zwei Net8 length fields und den Einstiegspunkt des SELECT Statements. Wie von Steve ausgeführt wurde, hat dies den unschlagbaren Vorteil, das man das Protokoll nur rudimentär verstehen muss. Mit dem Tool lassen sich auch Verbindungen automatisch downgraden – wiederrum basierend auf einem alten Tool, und das ist dennoch total up2date, weil kaum einer seinen JDBC-Client aktualisiert. Is klar. Bei neuen Versionen funktioniert der Angriff nicht mehr und die Verbindung würde bei einem Angriff abbrechen. Aber, und das ist neu, man kann einem Oracle Full Client erzählen, dass man ein 8er Server sei, egal welche Version der Server eigentlich hat. Klappt aber auch nur mit dem alten 9.2.0.6er Oracle Full Client, bei 10 und 11 nicht.
Mit einem neuen Angriff lässt sich jedoch die aktuelle Version übertölpeln. Am Anfang einer Session tauschen Client und Server Versionsinformationen über die möglichen Protokolle aus. Tauscht man 0x06 gegen 0x05 im Datenstrom aus, ist die Session ebenfalls downgegraded.
Daher lassen sich die Hashes mit worauthbf brechen – das Tool ist natürlich wieder 3rd party.
Fazit: Wendel lag leider falsch, ganz nett, aber mittlerweile verschlüsselt „man“ ja generell seine Datenbankverbindungen und nutzt Tools gegen ARP-Spoofing. Oder? Achja: Alle Demos wieder als Video..

David Lindsay & Eduardo Vela Nava: Universal XSS via IE8s XSS Filters
Wie gestern schon auf einem Vortrag gesagt wurde: XSS ist mittlerweile lame, aber immer noch nicht lame genug offensichtlich. Da der IE XSS Filter implementiert und damit WAF-ähnliche Aufgaben wahrnimmt, war ich dennoch an Evasion-Techniken interessiert.
Die generischen XSS Filter funktionieren in drei Schritten
1. Outbound Anfragen (z. B. POST) werden mit heuristischen Filtern untersucht
2. wenn die Filter matchen, werden dynamische Signaturen erstellt
3. wenn die Signaturen matchen, werden sie weggeworfen

Das ganze basiert auf 23 regular expressions, z. b. , eine Liste haben die beiden hier http://p43.us/ue8xss/filters02.txt bereitgestellt. Bei der Neutralisierung werden einzelne Character ersetzt (beim IE durch #) und das Ergebnis gerendert.
Wie kommt man nun an dem Filter vorbei? Man nutzt die Schwächen von RegEx-Definitionen aus. Alternativ nutzt man die Filter-Funktion selbst aus und macht dem # den Garaus. Damit kann man z. B. HTML-Code injecten. Beispiel:
http://0x.lv/simple.html vs. http://0x.lv/simple.html?foo=<script>. Durch den Filter des Browsers kann man eigen sein XSS „einbauen“. So wie <script> neutralisiert wird, wird auch ein Gleich-Zeichen neutralisiert. Verwundbar sind dadurch viele Anwendungen, siehe http://0x.lv/attr.php

Gegenmaßnahmen: = wird nicht mehr durch IE8 neutralisiert, der Nutzer könnte die Filter abschalten, was aber natürlich nicht sinnvoll ist. Also kann der Nutzer erstmal nichts machen 🙂 Als Webseiten-Betreiber kann ein X-XSS-Header gesetzt werden, um den Filter serverseitig auszuschalten.
Fazit: Jap, sehr nette Präse, nettes Demos, manchmal war Eduardo etwas rasch.

Den letzten Track Virtual Forensics kann ich nur noch kurz anschauen, ich muss dann gleich zum Flieger.

Fazit
Erschreckend wie arm manche Vorträge waren. Das Hotel war nicht sonderlich toll (aber teuer), das Essen gut und die Leute im Auditorium interessant. Nächstes Jahr sicherlich wieder, in der Hoffnung auf insgesamt bessere Vorträge.

/gt