Spiq: Heute schon gehackt (worden)? 1. März 2012 Dr. Steffen NORBERT, CISA, OSCP & OSCE (steffen.norbert@iseconsult.de)
2 von 30 Die unvermeidliche Folie über den Vortragenden Ich bin die Firma Iseconsult, ein freiberuflicher IT Security Berater seit etwa 10 Jahren. Davor bei verschiedenen Grossfirmen und zuletzt als Leiter der IT Security Architektur bei einer Schweizer Grossbank. Ca. 15 Jahre IT Security und insgesamt über 30 Jahre IT Berufserfahrung. Nach (zu) langer Zeit gedanklich ausschliesslich auf der Verteidiger Seite, seit erst etwa 3 Jahren mit neuem Schwerpunkt Offensive IT Sicherheit.
3 von 30 WARNUNG / Haftungsausschluss Hacking ist meistens strafbar! Zum Teil zeige ich Handlungen und Software die u.u. unterschiedlich von Land zu Land verboten sind Ich zeige das ausschließlich um die Abwehr von Hacking Angriffen zu stärken, bzw. zur Ausbildung Wenn Sie sich solche Software beschaffen und/oder meine Demos nachvollziehen, müssen Sie zuvor selbst sicherstellen, dass Sie dies im Einklang mit rechtlichen und (arbeits-) vertraglichen Regelungen tun und nicht dadurch zum Opfer werden Ich schließe jede Haftung aus, wenn Sie selbst Versuche unternehmen und dadurch Probleme bekommen! YOU HAVE BEEN WARNED!
4 von 30 Meine These die ich heute belegen will: Um sich gegen Spionage und Sabotage durch Hacker so weit als möglich und sinnvoll zu schützen, muss man zu aller erst wissen wie es geht. Firewalls, Virenschutz und Internet-Server Hardening reichen jedenfalls nicht aus. Mein Focus: Targeted attacks, d.h. Angriffe bei denen Schwachstellen in Erfahrung gebracht und dann ausgenutzt weden. (Also keine Massenware ). Wie es funktioniert und warum es leider oft sooo einfach ist. Schieben Sie den Gedanken aber ich bin doch kein Ziel einmal für 1 Stunde beiseite!
5 von 30 Bevor wir beginnen: Es erwartet Sie ein harter Abend mit live Demo und anstrengendem Vortrag Public Exploits: nichts wirklich Neues!. Keine neuen oder geheimen Tools, keine 0day Exploits, keine besonders gut geschützten Opfer. Aber über das Verstehen der Methoden möchte ich helfen Schutzmaßnahmen zu definieren die überleben. Bitte scheuen Sie sich nicht zu unterbrechen, wenn etwas unklar ist oder Sie ein wichtige Anmerkung haben; Vertiefungen und Diskussionen möchte ich aber gerne ans Ende schieben.
These: Hacken heißt 6 von 30 Daten werden zu Code Dazu brauchen wir 2 Dinge: Nicht (oder schlecht) überprüfter Input Input bestimmt den Ablauf Beispiele (die wir gleich vertiefen werden): PHP : include( /pfad/.$_get['sprache']. texte.php ); SQL: mysql_query( select * from tab where x =.$_POST ['auswahl']); C: chr lbuff[80]; gets(lbuff); // auch strcpy! C: chr lbuff[80]; sprintf(lbuff, Fehler, xyz: %s\n, eingabe); Dass damit Fehler bis hin zu Abstürzen möglich sind, ist Gemeinwissen, dass dies einem Hacker genügen kann, die volle Kontroll über den Computer zu übernehmen, werden wir sehen!
Ein Beispiel aus dem Leben 7 von 30 Nehmen wir an, wir finden bei einem Penetrationtest das Folgende vor: Jetzt suchen wir erst einmal, ob eine Vulnerability bekannt ist Die finden wir und gleich mit einer Anleitung, wie angreifen
Ein Beispiel aus dem Leben 8 von 30
Ein Beispiel aus dem Leben 9 von 30 lfi exploit
Autopsie: Was ist passiert und warum...?type=../../../../../xampp/apache/logs/access.log%00... 10 von 30 $_GET['type'] hat irgendwie den Weg in ein include oder require statement geschafft Mit einem NULL-Byte haben wir den String dahinter abgeschnitten (ab PHP 5.3.4 ist das vorbei --> immer patchen!) Mit../../../ (path-traversal) sind wir der vorgegebenen directory entkommen PHP führt allen Code aus der per include eingbracht wird! Aber woher bekommen wir ein passendes File? Es gibt viele Möglichkeiten, im Beispiel habe ich die Version über access.log und user agent gezeigt. Das ging nur, weil system() erlaubt war (kein safe mode!) und weil access.log gelesen sowie das File cmd.php geschrieben werden darf Berechtigungen! ABER: VORSICHT VOR DER CREATIVITÄT des HACKERS!
11 von 30 Ein verbreiteter Denkfehler : Oft werden Eingabedaten fälschlich als sicher erachtet, z.b. weil: sie durch (Java-) Skripte client-seitig geprüft wurden sie aus einem Formular-Feld mit Auswahl stammen sie aus einem Formular-Feld mit Beschränkungen stammen sie aus hidden fields stammen sie aus Cookies stammen sie aus dem Header stammen bei großen Programmen nicht so einfach zu erkennen ist, dass es Eingabedaten sind ABER: Alles was vom Client kommt, kann von einem böswilligen Benutzer manipuliert werden (wie das Beispiel gezeigt hat)!
12 von 30 Zweites Beispiel: SQL Injection Stellen Sie sich vor, Sie bekommen folgenden Code zu Gesicht: Das Problem: Code (hier SQL) und Daten sind vermischt UND die Daten (Eingabe) werden nicht überprüft! SQL injection
13 von 30 Autopsie: Was ist passiert und warum(1) $_POST['user'] wurde ohne Prüfung in eine SQL Query übernommen: Query = select from users where user ='.$POST['user']. ' and... Mit einem Einfach-Hochkomma haben wir den Benutzernamen geschlossen. Der Rest des Strings verändert die Query! Mit dem Kommentar String ( -- ) haben wir verhindert, dass der zweite Teil der Query (.. and ) angehängt wurde. So konnten wir uns einloggen ohne User-namen und Passwort zu kennen Durch Überlegen und Ausprobieren konnten wir sogar als Administrator einloggen! ABER wir konnten sogar ein File anlegen und so viel weiter kommen (2==>):
14 von 30 Autopsie: Was ist passiert und warum(2) Zwei Tricks : mit union select können wir eigene Daten einbringen Mit into dumpfile (oder outfile) können wir diese eigenen Daten in ein File schreiben, in diesem Falle ein php Skript Warum hat es funktioniert: Der technische Benutzer (mysql user) hatte das File Privileg (nicht sehr ungewöhnlich Reports) Der Benutzer unter dem mysql läuft, hat Schreibrechte auf einem Directory im Web-Server Dokumenten-Baum (ebenfalls nicht sehr ungewöhnlich) Sowie alles vom letzten Beispiel (z.b. kein safe mode) ABER der Ausgangspunkt bleibt SQL-Injection AUCH HIER, HACKERS CREATIVITÄT nicht unterschätzen!
Drittes Beispiel: Stack Buffer Overflow 15 von 30 Stellen Sie sich vor, Sie bekommen folgenden Code zu Gesicht: int logwriter(char *user) { char logline[132];... sprintf(logline,"benutzer: %s login failure",user); return (0); } Falls der Benutzer-Name nicht auf Länge geprüft wurde, kann das zu einem Stack Buffer Overflow führen. Wir sehen uns dazu den Stack (den Kellerspeicher) einmal (schematisch) an
16 von 30 Drittes Beispiel: Stack Buffer Overflow lower addresses Frame of subroutine Frame of calling program 132 Bytes: 132 Bytes: logline 4 Bytes: saved framepointer 4 Bytes: return address 4 Bytes: char *user ESP EBP higher addresses Ein etwas älteres, aber real world Beispiel sehen wir uns nun an: warftpd exploit
Autopsie: Was ist passiert und warum 17 von 30 sprintf(zielstring,formatstring,usereingabe-string) führte zu stack buffer overflow Da auch die return-adresse (Rücksprung aus dem aktuellen Unterprogramm) überschrieben wird, können wir dem Programm Ablauf entführen Wir entführten den Programmablauf in unsere Daten hinein! (Daten wurden Code!) Wenn DEP (=data execution prevention) angeschaltet gewesen wäre, hätte es so nicht funktioniert! ABER: Mittels ROP (= return oriented programming) kann man DEP schlagen Um ROP schwieriger zu machen, gibt es ASLR (=address space layout randomization) MS-WIN SYS-ADMIN: lerne im Detail wann DEP und ASLR eingeschaltet sind!
18 von 30 DEP und ROP Der gezeigte Stack Buffer Overflow führte dazu, dass Code auf dem Stack ausgeführt wurde. Schutz-Idee DEP (= data execution prevention): Der Stack wird nicht-ausführbar. Generalisierung: enge RWE-Rechte für alle Speicherbereiche eines Prozesses. DEP braucht Hardware: (AMD) NX oder (Intel) XD Bit Aushebeln von DEP ist ROP (=return oriented programming), Vorläufer = return2lib Grundidee von ret2lib: Man springt (ret) nicht auf den Stack sondern an den Beginn eines Unterprogramms, nachdem man auf dem Stack die Parameter hinterlegt hat. (Solche Aufrufe kann man verketten!) Verallgemeinerung ROP: Man springt zu einer Serie von passenden Stellen im Code (genannt Gadget ) die jeweils meist mit RET enden.
19 von 30 DEP und ROP (2) ROP heisst demnach eine Kette von GADGET-Adressen auf dem Stack zu hinterlegen (da ja Befehle nicht gehen NX!). Beispiele gängiger ROP-Strategien: Schalte DEP für den aktuellen Stack ab ( VirtualProtect) Kopiere den Shellcode über bestehenden Code ( WriteProcessMemory) Erstelle neuen Speicherbereich mit WE Berechtigung und kopiere Shellcode dort hin ( VirtualAlloc dann memcpy o.ä.) Ein reales Beispiel (aus einem privaten Exploit)
DEP und ROP (3) 20 von 30 # # prepare the 4 parms of VirtualProtect: buf2 = pack('l',0x77c4ebc9) # POP EAX; POP EBP; (RET) buf2 += pack('l',0xfefefefe) # EAX buf2 += pack('l',0xfefefefe) # EBP buf2 += pack('l',0x7c90192c) # POP EBX; (RET) buf2 += pack('l',0x0124fc3e) # EBX buf2 += pack('l',0x77eb82c7) # ADD EBX,EBP; (RET) buf2 += pack('l',0x77c3a77e) # ADD [EBX],EAX; (RET) buf2 += pack('l',0x7c81106f) * 4 # INC EBX ; (RET) *4 buf2 += pack('l',0x77c3a77e) # ADD [EBX],EAX; (RET) buf2 += pack('l',0x7c81106f) * 4 # INC EBX; (RET) *4 buf2 += pack('l',0x77c3a77e) # ADD [EBX],EAX; (RET) buf2 += pack('l',0x7c81106f) * 4 # INC EBX; (RET) *4 buf2 += pack('l',0x77c3a77e) # ADD [EBX],EAX; (RET) buf2 += pack('l',0x7c801ad4) # Virtual Protect buf2 += pack('l',0x7c874413) # JMP ESP, ( ESP is at += 10 at RET) # ARGS: ADDR Protect Size Protection (WE) Recv. old prot # 0x0023f000 0x00000fff 0x00000040 0x0023f000 buf2 += pack('l',0x0124f0e7) + pack('l',0x01011101) buf2 += pack('l',0x01010142) + pack('l',0x0124f102) # shellcode follows
Die Antwort auf ROP ist ASLR 21 von 30 ROP braucht die Adressen der GADGETS (und des Stacks) Schutz-Idee gegen ROP: Verhindern, dass die Adressen bekannt sind durch zufällige Wahl der Basisadressen aller Module & Sektionen ==> ASLR (=address space layout randomization) Aushebeln von ASLR: Brute force (es gibt Untersuchungen: nur in Sonderfällen eine Option) Information Disclosure Vulnerability: Wenn wir z.b. eine Formatstring-Vulnerability haben, ist das trivial Finden von nicht randomisierten Modulen ASLR ist nicht aktiv: Windows XP! oder alte library oder static linking FAZIT: Stack Buffer Overflow ist nicht so out wie man zunächst denkt!
Generalisierung des 22 von 30 stack buffer overflows (1) Wir (Hacker ) müssen SHELLCODE in die Eingabedaten einschmuggeln (2) Wir müssen dann den Programm-Ablauf entführen Dazu brauchen wir beispielsweise einen stack buffer overflow ODER Einen n-bytes write primitive d.h. Wenn wir an eine beliebige Stelle einige beliebige (von uns gewählte Bytes) schreiben können, dann können wir oft auch den Programm-Ablauf entführen! Die verbreitetsten Varianten sind: stack buffer overflow, heap buffer overflow und format string exploit (%n) Aber mit eingebetteten Skript sprachen (nota bene java script oder flash ) gibt es einen ganzen neuen Bereich von Möglichkeiten ( Heap Spray, ein Thema für weiteren Vortrag)
Achtung vor Fehleinschätzungen (1) 23 von 30 1) Mein Programm ist nicht gefährdet, weil es mit dem Netzwerk nichts am Hut hat : FALSCH, da die Daten auch anders, z.b. über Files vergiftet werden können. Bekannte Beispiele sind PDF Reader und Media Player 2) Mein Programm ist kein Server sondern ein (Netzwerk) Client und deshalb ist es sicher : FALSCH, da Client Programme besonders gefährdet sind, denn auch die Daten vom Server können manipuliert sein. Bekanntes Beispiel: Internet Explorer (aber auch andere Browser!) Stichwort: Client side exploits
Achtung vor Fehleinschätzungen (2) 3) Ich muss das Programm nicht sicher machen, denn auf meinen Server sind alle Sicherheitsmaßnahmen (DEP,ASLR,guard stack(/gs),safe-seh etc.) an FALSCH, da diese Maßnahmen z.t. Run-time, z.t. Link- Time oder Compile-Time Maßnahmen sind und z.t. pro Programm ein- oder ausgeschaltet werden und z.t. Hardware/BIOS abhängig sind. 4) Ich bin nicht gefährdet, denn ich habe eine Firewall BESONDERS FALSCH, denn alle gezeigten Angriffe kamen über Kanäle die Firewalls offen lassen müssen! 5) Ich bin nicht gefährdet, denn ich benutze ein (gutes) Anti-Viren Programm 24 von 30 FALSCH, denn die Signaturen von targeted attacks können noch nicht bekannt sein und die heuristischen Methoden können oft umgangen werden.
25 von 30 Wenn Zeit ist Ein Blick in Hackers Werkzeugkasten Nur eine sehr kleine Auswahl: Metasploit und Meterpreter: Hacker Framework und Postexploitation Werkzeug Socat Demo: Postexploitation, Firewalls schlagen mit portforwarding Ettercap (ARP & DNS Spoofing) man in the middle attack
26 von 30 Wenn Zeit ist Portforwarding / Tunneling Metasploit/ Meterpreter portfwd Portforwarding macht einen Port eines Rechners auf einem anderen erreichbar Tunneling überträgt ein Protokoll über ein anderes; d.h. (für uns sehr wichtig) überträgt auch PF, ggf. in beide Richtungen! Es gibt viele interessante Softwarepakete in dieser Sparte :, z.b: rinet.d, fpipe, plink, winrelay, netcat, socat, proxytunnel
Wenn Zeit ist Portforwarding / Tunneling 27 von 30 Zunächst ein kleiner Exkurs, was jeder der Kontrolle über einen Intranet -Rechner hat, tun kann: Portforwarding mit Socat Achtung bei Tests: Virenscanner schlagen bei mancher dieser Software evtl. Alarm Nicht gezeigt, aber ein Klassiker: Mitarbeiter die z.b. IRC am Arbeitsplatz nutzen wollen oder auf verbotene Web- Server zugreifen wollen (Netzwerk-) Sicherheitsverantwortlicher? ==> Lesen Sie unbedingt: http://proxytunnel.sourceforge.net/paper.php
28 von 30 Wenn Zeit ist Portforwarding / Tunneling Beispiel (aus der Socat Doku): Passing Friendly Firewall: Before leaving (company), start double client : socat ssl:priv-host:443,fork,forever,intervall=30, cert=...,cafile=...,verify tcp:protected-server:80 At home, start double server : socat tcp-l:80,fork ssl-l:443,reuseaddr, forever,cert=...,cafile=... With browser connect to double server (127.0.0.1:80) So kann jeder Mitarbeiter von zu Hause aus auf Intranet-Server zugreifen. Natürlich kann eine Hacker so auch von einem übernommenen Client aus im Intranet weiterarbeiten.
29 von 30 Literatur Liste Ich gebe hier einige von mir bessonders geschätzte Bücher und Quellen an und warne gleich: Das Gebiet ist nicht gut dokumentiert! Vielfach wird man viel Zeit und Schweiß investieren müssen oder braucht einen Mentor! Einsteiger-Literatur gibt es m.m.n. keine (lesenswerte): Bücher (eher für Fortgeschrittene ): The Shellcoders Handbook von Chris Anley, John Heasman, Felix "FX" Linder u. Gerardo Richarte The Webapplication Hackers Handbook von Dafydd Stuttard und Marcus Pinto (neue Auflage 2011!) The Database Hackers Handbook von David Litchfield, Chris Anley, John Heasman und Bill Grindlay (leider von 2005, aber gut!) Downloads (meist PDFs ): www.exploit-db.com/papers/13162 Smashing the modern Stack for fun and profit www.exploit-db.com/papers/10193 ff : Exploit writing Tutorial part 1 to 10 from Peter van Eeckhoutte www.blackhat.com/presentations/bh-usa-09/mcdonald /BHUSA09-McDonald-WindowsHeap-PAPER.pdf Suchen Sie selbst, beispielsweise in den Blackhat Archiven oder auf www.exploit-db.com
30 von 30 Mein Fazit Ich bin überzeugt, dass sich jeder Softwareentwickler und jeder System-Administrator intensiv(er) mit diesem spannenden und interessanten Thema beschäftigen sollte. Fragen & Diskussion gerne jetzt im Anschluss Bedarf für Ausbildung? Ich gebe spezielle Kurse! Bedarf für mehr Demo, Diskussion oder Beratung? ==> Bitte E-mail an mich! steffen.norbert@iseconsult.de Ihr Fazit?