Heute schon gehackt (worden)
Werbung
Spiq: Heute schon gehackt (worden) ? 1. März 2012 Dr. Steffen NORBERT, CISA, OSCP & OSCE ([email protected] ) 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 Daten werden zu Code ➔ 6 von 30 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 10 von 30 Autopsie: Was ist passiert und warum ● ● ● ● ● . . . ?type=../../../../../xampp/apache/logs/access.log%00 . . . $_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 hidden fields stammen ● sie aus Cookies stammen ● sie aus dem Header stammen ● ● sie aus einem Formular-Feld mit Beschränkungen 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! 15 von 30 Drittes Beispiel: Stack Buffer Overflow ● 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 132 Bytes: logline 132 Bytes: logline 4 Bytes: saved framepointer ESP EBP 4 Bytes: return address 4 Bytes: char *user Frame of calling program higher addresses Ein etwas älteres, aber “real world” Beispiel sehen wir uns nun an: warftpd exploit 17 von 30 Autopsie: Was ist passiert und warum ● ● ● ● 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) # buf2 = pack('L',0x77c4ebc9) buf2 += pack('L',0xfefefefe) buf2 += pack('L',0xfefefefe) buf2 += pack('L',0x7c90192c) buf2 += pack('L',0x0124fc3e) buf2 += pack('L',0x77eb82c7) buf2 += pack('L',0x77c3a77e) buf2 += pack('L',0x7c81106f) * 4 buf2 += pack('L',0x77c3a77e) buf2 += pack('L',0x7c81106f) * 4 buf2 += pack('L',0x77c3a77e) buf2 += pack('L',0x7c81106f) * 4 buf2 += pack('L',0x77c3a77e) 20 von 30 # prepare the 4 parms of VirtualProtect: # POP EAX; POP EBP; (RET) # EAX # EBP # POP EBX; (RET) # EBX # ADD EBX,EBP; (RET) # ADD [EBX],EAX; (RET) # INC EBX ; (RET) *4 # ADD [EBX],EAX; (RET) # INC EBX; (RET) *4 # ADD [EBX],EAX; (RET) # INC EBX; (RET) *4 # 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 ● ● ● 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: ● ● ● ● ● 21 von 30 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 stack buffer overflows 22 von 30 (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) 23 von 30 Achtung vor Fehleinschätzungen (1) 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 24 von 30 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. LinkTime 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 ➔ 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 27 von 30 Portforwarding / Tunneling ● 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” WebServer 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”. Literatur Liste 29 von 30 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! [email protected] Ihr Fazit?
