Kenne deinen Feind - download.e-bookshelf.de...Netzwerk-Sicherheit mit RCE, IDS, Honeypots u.a....

Netzwerk-Sicherheit mit RCE, IDS, Honeypots u.a. Deutsche

Ausgabe

Cyrus Peikari & Anton ChuvakinDeutsche Übersetzung von Peter Klicman,

Andreas Bildstein & Gerald Richter

Kenne deinen FeindFortgeschrittene Sicherheitstechniken

376.book Seite II Mittwoch, 23. Mai 2007 11:49 11

Beijing ·

Cambridge ·

Farnham ·

Köln ·

Paris ·

Sebastopol ·

Taipei ·

Tokyo

Kenne deinen FeindFortgeschrittene Sicherheitstechniken

Cyrus Peikari & Anton Chuvakin

Deutsche Übersetzung von Peter Klicman,Andreas Bildstein & Gerald Richter

376.book Seite III Mittwoch, 23. Mai 2007 11:49 11

Die Informationen in diesem Buch wurden mit größter Sorgfalt erarbeitet. Dennoch können Fehler nicht vollständig ausgeschlossen werden. Verlag, Autoren und Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für eventuell verbliebene Fehler und deren Folgen.Alle Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt und sind möglicherweise eingetragene Warenzeichen. Der Verlag richtet sich im Wesentlichen nach den Schreibweisen der Hersteller. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung,Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

Kommentare und Fragen können Sie gerne an uns richten:O’Reilly VerlagBalthasarstr. 8150670 KölnTel.: 0221/9731600Fax: 0221/9731608E-Mail: [email protected]

Copyright der deutschen Ausgabe:© 2004 by O’Reilly Verlag GmbH & Co. KG1. Auflage 2004

Die Originalausgabe erschien 2004 unter dem TitelSecurity Warrior bei O’Reilly Media, Inc.

Die Darstellung von Sumo-Ringern im Zusammenhang mit dem Thema Netzwerksicherheit ist ein Warenzeichen von O’Reilly Media, Inc.

Bibliografische Information Der Deutschen BibliothekDie Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

Übersetzung und deutsche Bearbeitung: Peter Klicman, Andreas Bildstein & Gerald RichterLektorat: Michael Gerth, KölnFachgutachten: Gerald RichterKorrektorat: Oliver Mosler, KölnSatz: Tung Huynh, reemers publishing services gmbh, Krefeld; www.reemers.deUmschlaggestaltung: Edie Freedman & Emma Colby, BostonProduktion: Karin Driesen & Stephanie Buckstegge, KölnBelichtung, Druck und buchbinderische Verarbeitung: Druckerei Kösel, Krugzell; www.koeselbuch.de

ISBN 3-89721-376-1

Dieses Buch ist auf 100% chlorfrei gebleichtem Papier gedruckt.

376.book Seite IV Mittwoch, 23. Mai 2007 11:49 11

Dr. Cyrus Peikari verneigt sich in Demut vor Bahá’u’lláh,der Herrlichkeit Gottes. Er dankt auch seinen Studenten,

Lehrern und Weggefährten auf der Suche nach Erkenntnis.Dr. Peikari ist auch seiner Familie dankbarfür ihre Unterstützung und ihren Rückhalt.

– Dr. Cyrus Peikari

Der Teil des Buches, für den ich verantwortlich bin,ist Olga gewidmet, die es ertrug, dass ich all die Abende

mit dem Schreiben dieses Buches verbrachte,und die mich sogar ermunterte weiterzuschreiben,

wenn ich träge zu werden begann.

– Dr. Anton Chuvakin

376.book Seite V Mittwoch, 23. Mai 2007 11:49 11

376.book Seite VI Mittwoch, 23. Mai 2007 11:49 11

| VII

Inhalt

Vorwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

XIII

Teil I:

Software-Cracking

1

Assembler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Assembler-Opcodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2

Windows Reverse Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

Geschichte des RCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Reversing-Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Reverse-Engineering-Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3

Linux Reverse Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

Grundlegende Tools und Techniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Eine gute Disassemblierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Problembereiche. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Neue Tools entwickeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

4

Windows CE Reverse Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

125Windows CE-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Grundlagen des CE Reverse Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

CE Reverse Engineering in der Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

376.book Seite VII Mittwoch, 23. Mai 2007 11:49 11

VIII | Inhalt

Reverse Engineering von serial.exe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

5

Überlauf-Attacken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

171Pufferüberläufe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Puffer verstehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173Den Stack zerstören . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Heap-Überläufe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176Pufferüberläufe verhindern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Eine Live-Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Teil II:

Netzwerk-Angriffe

6

TCP/IP-Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

189Eine kurze Geschichte von TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Kapselung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196RARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

BOOTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

TCP/IP-Handshake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197Verdeckte Kanäle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

IPv6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199Ethereal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

Paket-Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202Fragmentierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

7

Social Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

211Hintergrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212Durchführen der Angriffe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

Fortgeschrittenes Social Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

376.book Seite VIII Mittwoch, 23. Mai 2007 11:49 11

Inhalt | IX

8

Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

226

Online-Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

Schlussfolgerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

9

Betriebssystem-Fingerprinting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

241Telnet Session Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

TCP-Stack-Fingerprinting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242Spezialeinsatzwerkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

Passives Fingerprinting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246Fuzzy-OS-Fingerprinting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

TCP/IP-Timeout-Erkennung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

10

Spuren verwischen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

253Vor wem verstecken Sie sich?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253Aufräumarbeiten nach einem Angriff. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

Forensische Spuren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261Versteckten Zugang pflegen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Teil III:

Plattform-Angriffe

11

Unix-Verteidigung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

279Unix-Passwörter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280Zugriffsrechte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

System-Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287Netzwerkzugriff bei Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290

Das Härten von Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294Verteidigung des Unix-Netzwerks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325

12

Unix-Angriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

327Lokale Angriffe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

Entfernte Angriffe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336Denial-of-Service-Angriffe unter Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352

Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

376.book Seite IX Mittwoch, 23. Mai 2007 11:49 11

X | Inhalt

13

Angriffe auf Windows-Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

361Denial-of-Service-Angriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361

Entfernter Zugriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371Remoteunterstützung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376

Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382

14

Angriffe auf Windows Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

383Release-History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383

Kerberos-Authentifizierungs-Angriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384Übersicht über die Kerberos-Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . 384

Den Pufferüberlauf-Schutz besiegen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389Lücken von Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391

PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392Smart Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393

Änderungen am Encrypting File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397Verschlüsselung durch Drittanbieter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399

Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402

15

Sicherheit bei SOAP-XML-Webservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

403XML-Verschlüsselung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403XML-Signaturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406

Referenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407

16

SQL-Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

408

Einführung in SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408SQL-Injection-Angriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411

SQL-Injection-Schutzmaßnahmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418PHP-Nuke-Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422

Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425

17

Sicherheit im WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

426

Reduzierung der Signalstreuung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426Probleme mit WEP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428

WEP knacken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428Praktisches WEP-Cracking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434

VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435TKIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436

SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437

376.book Seite X Mittwoch, 23. Mai 2007 11:49 11

Inhalt | XI

Wireless-Viren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438

Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442

Teil IV:

Fortgeschrittene Verteidigung

18

Prüfspuren-Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

445Grundlagen der Protokollanalyse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445

Protokollbeispiele. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446Protokollierungszustände. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455

Wann sollte nach den Protokollen gesehen werden? . . . . . . . . . . . . . . . . . . . . . . 456Protokoll-Überflutung und -Aggregation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458

Schwierigkeiten bei der Protokollanalyse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458Security Information Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459

Globale Protokoll-Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461

19

Intrusion-Detection-Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

462

IDS-Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463

Bayessche Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469Angriffe durch IDS-Systeme hindurch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475

Die Zukunft von IDS-Systemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477Snort IDS-Fallstudie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480

IDS-Einsatzprobleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486

20

Honeypots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

488

Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490

Aufbau der Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490Einfangen von Angriffen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501

Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502

21

Incident Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

503Fallstudie: Wurmchaos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503Definitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504

Incident-Response-Rahmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507Kleine Netzwerke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510

Mittelgroße Netzwerke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517

376.book Seite XI Mittwoch, 23. Mai 2007 11:49 11

XII | Inhalt

Große Netzwerke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519

Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523

22

Forensik und Antiforensik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

525Hardware-Review. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525

Informationsmüll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527Forensische Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528

Bootbare forensische CD-ROMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534Evidence Eliminator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538

Forensische Fallstudie: Ein FTP-Angriff. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555

Teil V:

Anhang

Anhang: Nützliche SoftICE-Befehle und -Breakpunkte . . . . . . . . . . . . . . . . . . . . . . . .

559

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

565

376.book Seite XII Mittwoch, 23. Mai 2007 11:49 11

| XIII

Vorwort

... Jeder Samurai sollte sich zweifellos dem Studium der Wehrwissenschaft widmen.Aber aus diesem Studium wird Schlechtes hervorgehen, wenn man es dazu

verwendet, sein eigenes Ich aufzuwerten und seine Kameraden durch eine Mengehochtrabender, aber falscher Argumente herabzusetzen, die die Jungen nur in die

Irre führen und ihren Geist verderben. Denn diese Sorte Mensch hält oft wortreicheReden, die korrekt und dem Thema angemessen erscheinen, aber eigentlich geht es

ihm nur um den Effekt und seinen eigenen Vorteil, was letzten Endes zur Auflösungseines Charakters und zum Verlust des wahren Samurai-Geistes führt. Dieser

Fehler rührt von einer oberflächlichen Beschäftigung mit dem Thema her, deshalbsollten sich jene, die ein solches Studium beginnen, niemals damit zufrieden geben,

nur den halben Weg zu gehen, sondern so lange durchhalten, bis sie alleGeheimnisse verstehen, und nur dann sollen sie zu ihrer ursprünglichen Einfachheit

zurückkehren und ein ruhiges Leben führen ...–Daidoji Yuzan

Der Kodex des Samurai 1

Dieses Buch stellt einmalige Methoden vor, um Ihre Informations-Sicherheitstechniken zuverbessern. Der typische Leser ist ein erfahrener Praktiker. Aber wer von uns ist schontypisch? Jeder von uns geht das Thema Informationssicherheit mit unterschiedlichen Erfah-rungen und Fähigkeiten an. Dennoch, bevor Sie Ihr hart verdientes Geld für dieses Buchausgeben, wollen wir versuchen, den Leser zu beschreiben, an den sich dieses Buch richtet.

So könnten Sie dieses Buch beispielsweise genießen, wenn Sie bereits Erfahrung mitNetzwerken haben und in ein oder mehreren Sprachen programmieren können. IhrInteresse an der Informationssicherheit ist vielleicht relativ neu, aber Sie haben bereitseinige technische Bücher zum Thema gelesen, etwa Practical UNIX & Internet Securityvon O’Reilly. Sie fanden diese Bücher informativ und würden gerne mehr lesen, würdenaber gerne etwas über neuere Themen erfahren, und das auch auf fortgeschrittenerEbene. Anstelle einer einführenden Übersicht zu Sicherheitsfragen aus Sicht der verteidi-genden Seite würden Sie die Sache gerne mit den Augen des Angreifers sehen.

1 Die englischsprachige Originalfassung dieses Samurai-Zitats wurde freundlicherweise zur Verfügung gestelltvon http://www.samurai-archives.com.

376.book Seite XIII Mittwoch, 23. Mai 2007 11:49 11

XIV | Vorwort

Sie sind bereits mit grundlegenden Netzwerkangriffen wie Sniffing, Spoofing und Denial-of-Service vertraut. Sie lesen Sicherheitsartikel und Vulnerability-Mailinglisten online,und Sie wissen, dass das die beste Möglichkeit ist, Ihr Wissen zu erweitern. Nun suchenSie aber einen einzelnen Titel, der Ihren Wissensstand direkt um einige Grade erhöhenkann.

Anstelle einer einfachen Aufstellung der Software-Tools würden Sie lieber tiefer in die zu-grunde liegenden Konzepte, etwa Paket-Fragmentierung, Überlaufangriffe und Betriebs-system-Fingerprinting, eintauchen. Ebenso wollen Sie mehr über Forensik, Honeypotsund die psychologischen Grundlagen des Social Engineering erfahren. Sie könnten auchSpaß an neuen Herausforderungen haben, wie etwa die Implementierung eines Intru-sion-Detection-Systems und die Verteidigung gegen durch die Luft übertragene »Wire-less-Viren«. Bevor Sie sich der Microsoft Trustworthy Computing-Initiative anvertrauen,wollen Sie mehr über Windows XP-Angriffe und die Schwächen von Windows Serverwissen.

Das sind einige der von uns behandelten Themen. Obwohl einige Teile für erfahreneBenutzer notwendigerweise eine Wiederholung sein werden, behandelt dieses Buch aucheinmalige Themen, die selbst erfahrene Veteranen befriedigen sollten. So behandeln wirzum Beispiel das Reverse Code Engineering (RCE), einschließlich der eher esoterischenBereiche des Linux- und Embedded-RCE. RCE ist unentbehrlich, wenn man bösartigenCode analysieren, Spyware entlarven und Lücken in Anwendungen aufspüren will, undwurde in der gedruckten Literatur bis zu diesem Buch nur dürftig behandelt.

Das Buch ist an kein bestimmtes Betriebssystem gebunden, weil viele von Ihnen norma-lerweise für den Schutz eines gemischten Netzwerks verantwortlich sind. Wir behandelndas Thema Sicherheit aus Sicht des Angreifers, nicht aus Sicht der verteidigenden Seite.Ein guter Weg zum Aufbau einer effektiven Verteidigung besteht darin, möglicheAngriffe zu verstehen und vorherzusehen.

Wir haben versucht, unsere persönlichen Meinungen im gesamten Text nicht allzu sehrdurchscheinen zu lassen. Allerdings ließ sich das bis zu einem gewissen Grad nicht ver-meiden, da Sie anderenfalls nicht mehr als eine Sammlung trockener Fakten vorliegenhätten. Verzeihen Sie uns also unsere Schulmeisterei, die weder maßgebend ist noch rich-tig sein muss. Die Meinungen des Menschen sind verschieden und notwendigerweisefehlerhaft. Zumindest hoffen wir, bei einem kontroversen Thema einen Gegenpol zuIhren eigenen Ansichten zu schaffen. Wir geben auch einige anekdotenhafte Beispiele,um die etwas schwereren Themen leichter verständlich zu machen.

Wir haben uns bemüht, Sie am Ende jedes Kapitels mit hilfreichen Referenzen zu versor-gen. Diese erlauben es uns, einigen der klassischen Informationssicherheitsquellenunsere Hochachtung zu erweisen, und sie ermöglichen es Ihnen, tiefer in die für Siebesonders interessanten Themen einzusteigen. Dies ist keineswegs eine umfassende Ein-führung in die Netzwerksicherheit. Vielmehr handelt es sich um eine Anleitung, um IhrWissen in verschiedenen Schlüsselbereichen schnell auf den neuesten Stand zu bringen.Wir hoffen, dass Sie das Buch genauso gerne lesen, wie wir Spaß hatten, es zu schreiben.

376.book Seite XIV Mittwoch, 23. Mai 2007 11:49 11

Vorwort | XV

Der Aufbau dieses BuchesSie müssen dieses Buch nicht von Anfang bis Ende durchlesen. Allerdings ziehen es vieleLeser vor, ein technisches Buch von vorne bis hinten durchzuarbeiten. Wir haben daherversucht, dem Buch eine sinnvolle Struktur zu geben. Die folgenden Abschnitte umrei-ßen die Hauptteile des Buches und zeigen einige Glanzlichter der jeweiligen Kapitel auf.

Teil I: Software-CrackingDer erste Teil dieses Buches konzentriert sich im Wesentlichen auf das Software ReverseEngineering, auch als Reverse Code Engineering oder kurz RCE bekannt. Wie Sie erfahrenwerden, spielt das RCE eine wichtige Rolle bei der Netzwerksicherheit. Allerdings wurdediesem Thema bis zu diesem Buch in der Literatur nur wenig Aufmerksamkeit gewidmet.Im ersten Teil beschäftigen wir uns nach einer kurzen Einführung in die Assembler-Spra-che (Kapitel 1) mit den RCE-Tools und -Techniken für Windows-Plattformen (Kapitel 2)sowie einigen recht einmaligen Cracking-Übungen. Danach wenden wir uns dem etwasesoterischeren Feld des RCE unter Linux zu (Kapitel 3). Wir führen dann in das RCE fürEmbedded-Plattformen ein (Kapitel 4) – insbesondere das Knacken von Anwendungenfür Windows Mobile-Plattformen (Windows CE, Pocket PC, Smartphone) mit ARM-basierten Prozessoren. Abschließend behandeln wir Überlaufangriffe (Kapitel 5) und nut-zen unser in den vorherigen Kapiteln gewonnenes RCE-Wissen, um einen Pufferüberlaufauszunutzen.

Teil II: Netzwerk-AngriffeTeil II schafft die Grundlagen für das Verständnis der später in diesem Buch vorgestelltenNetzwerkangriffe. In Kapitel 6 untersuchen wir die Sicherheitsaspekte von TCP/IP,inklusive IPv6, und behandeln Tools und Techniken für Fragmentierungsangriffe. Kapi-tel 7 verfolgt einen einmaligen Ansatz beim Social Engineering, der psychologische Theo-rien nutzt, um mögliche Angriffe zu erkunden. Kapitel 8 widmet sich der Netzwerk-Aufklärung (Reconnaissance), während wir uns in Kapitel 9 dem Betriebssystem-Finger-printing widmen, einschließlich des passiven Fingerprintings und neuen Tools wieXProbe und Ring. Kapitel 10 bietet einen tieferen Einblick, wie Hacker ihre Spuren ver-wischen. Hier gehen wir auch auf Anti-Forensik und die Umgehung von IDS-Systemenein.

Teil III: Plattform-AngriffeTeil III beginnt mit einer kurzen Einführung in die Sicherheitsgrundlagen von Unix(Kapitel 11), bevor wir uns Unix-Angriffen zuwenden (Kapitel 12). Im Unterschied dazubehandeln die beiden Windows-Kapitel (Kapitel 13 und Kapitel 14) Client- und Server-Angriffe, da Exploits für diese beiden Plattformen so ihre Eigenarten haben. So zeigen wir

376.book Seite XV Mittwoch, 23. Mai 2007 11:49 11

XVI | Vorwort

zum Beispiel für Windows XP, wie man Lücken im Remote-Zugriff nutzen kann, wäh-rend wir für Windows Server zeigen, wie man die Kerberos-Authentifizierung theoretischknacken kann. Kapitel 15 behandelt die Sicherheit von SOAP-XML-Webservices undKapitel 16 beschreibt SQL-Injection-Angriffe. Zum Schluss widmen wir uns der Sicher-heit drahtloser Systeme (Kapitel 17), einschließlich WLANs und Embedded-Malware.

Teil IV: Fortgeschrittene VerteidigungIn Teil IV behandeln wir fortgeschrittenere Techniken der Netzwerkverteidigung. Sobehandelt Kapitel 18 zum Beispiel die Protokollanalyse, einschließlich der Log-Aggrega-tion und -Analyse. Kapitel 19 betritt Neuland, indem es eine neue praktische Methodevorstellt, die das Bayessche Theorem auf die Implementierung von Netzwerk-IDS-Syste-men anwendet. Kapitel 20 enthält eine schrittweise Anleitung zum Aufbau eines eigenenHoneypot-Systems, mit dem Sie Angreifern eine Falle stellen können. Kapitel 21 führt indie Grundlagen des Incident Response (Reaktion auf Vorfälle) ein, und Kapitel 22 wid-met sich den forensischen Tools für Unix und Windows.

Teil V: AnhangAbschließend enthält der Anhang am Ende des Buches eine Liste nützlicher SoftICE-Befehle und -Breakpunkte.

Typografische KonventionenIn diesem Buch werden folgende typografische Konventionen verwendet:

KursivschriftKennzeichnet neue Begriffe, URLs, E-Mail-Adressen, Dateinamen, Dateierweiterun-gen, Pfadnamen, Verzeichnisse und Unix-Einrichtungen.

NichtproportionalschriftKennzeichnet Befehle, Optionen, Schalter (Switches), Variablen, Attribute, Funk-tionen, Typen, Klassen, Namensräume, Methoden, Module, Eigenschaften, Parame-ter, Werte, Objekte, Ereignisse, Ereignis-Handler, XML-Tags, HTML-Tags,Makros, Dateiinhalte oder Befehlsausgaben.

Nichtproportionalschrift fettKennzeichnet Befehle oder anderen Text, die bzw. der vom Benutzer wörtlich einge-geben werden sollte(n).

Nichtproportionalschrift kursivKennzeichnet Text, der vom Benutzer durch auf seine Verhältnisse angepassteWerte ersetzt werden soll.

KAPITÄLCHEN

Kennzeichnen Menütitel, Menüoptionen und Menü-Schaltflächen (Buttons).

376.book Seite XVI Mittwoch, 23. Mai 2007 11:49 11

Vorwort | XVII

Dieses Symbol kennzeichnet einen Tipp, Vorschlag oder allgemeinenHinweis.

Dieses Symbol kennzeichnet eine Warnung.

Verwendung von CodebeispielenDieses Buch soll Ihnen bei der Ausübung Ihres Berufs behilflich sein. Im Allgemeinendürfen Sie den Code aus diesem Buch in Ihren Programmen und Dokumentationen ver-wenden. Sie brauchen uns nicht um Erlaubnis zu fragen, außer Sie kopieren einenbeträchtlichen Teil des Codes. Beispielsweise bedarf es keiner Erlaubnis unsererseits,wenn Sie ein Programm schreiben, das verschiedene Codeteile aus diesem Buch verwen-det. Wenn Sie aber eine CD-ROM mit Beispielen aus O’Reilly-Büchern verkaufen odervertreiben, brauchen Sie dafür unsere Erlaubnis. Wenn Sie Zitate und Beispielcode ausdiesem Buch zur Beantwortung einer Frage heranziehen, brauchen Sie dafür keineErlaubnis.

Dieses Buch hat eine eigene Webseite, auf der wir Fehler, Beispiele und andere zusätzli-che Informationen aufführen. Sie erreichen diese Seite unter folgender Adresse:

http://www.securitywarrior.com

Sie können die Autoren direkt per E-Mail erreichen:

Cyrus Peikari: [email protected] Chuvakin: [email protected]

DanksagungenBevor wir weitermachen, wollen wir den zahlreichen Experten danken, die uns mit Vor-schlägen, Kritik und Anregungen zur Seite standen. Insbesondere möchten wir den bei-den mitwirkenden Autoren Seth Fogie und Mammon_ danken, ohne deren Beiträgedieses Buch nicht zu dem geworden wäre, was es ist. Colleen Gorman und Patricia Pei-kari übernahmen das Korrekturlesen. Ebenso danken wir den technischen Gutachternbei O’Reilly, von denen jeder einzelne wertvolles Feedback lieferte. In keiner bestimmtenReihenfolge waren dies Jason Garman, John Viega, Chris Gerg, Bill Gallmeister, Bob Byr-nes und Fyodor (der Autor von Nmap).

Cyrus Peikari und Anton Chuvakin

376.book Seite XVII Mittwoch, 23. Mai 2007 11:49 11

376.book Seite XVIII Mittwoch, 23. Mai 2007 11:49 11

TEIL I

I.

Software-Cracking

Der erste Teil dieses Buches konzentriert sich im Wesentlichen auf das Software ReverseEngineering, auch als Reverse Code Engineering oder kurz RCE bekannt. Wie Sie erfahrenwerden, spielt das RCE eine wichtige Rolle bei der Netzwerksicherheit. Allerdings wurdediesem Thema bis zu diesem Buch in der Literatur nur wenig Aufmerksamkeit gewidmet.Im ersten Teil beschäftigen wir uns nach einer kurzen Einführung in die Assembler-Spra-che (Kapitel 1) mit den RCE-Tools und -Techniken für Windows-Plattformen (Kapitel 2)sowie einigen recht einmaligen Cracking-Übungen. Danach wenden wir uns dem etwasesoterischeren Feld des RCE unter Linux zu (Kapitel 3). Wir führen dann in das RCE fürEmbedded-Plattformen ein (Kapitel 4) – insbesondere das Knacken von Anwendungenfür Windows Mobile-Plattformen (Windows CE, Pocket PC, Smartphone) mit ARM-basierten Prozessoren. Abschließend behandeln wir Überlaufangriffe (Kapitel 5) und nut-zen unser in den vorherigen Kapiteln gewonnenes RCE-Wissen, um einen Pufferüberlaufauszunutzen.

376.book Seite 1 Mittwoch, 23. Mai 2007 11:49 11

| 3

KAPITEL 1

Assembler

Dieses Kapitel enthält eine kurze Einführung in die Assembler-Sprache (ASM), um einesolide Grundlage für die Reverse-Engineering-Kapitel in Teil I zu schaffen. Dies ist keineumfassende Einführung in Assembler, sondern nur eine kleine Wiederauffrischung für alldiejenigen, die mit dem Thema bereits vertraut sind. Erfahrene Assembler-Programmie-rer können direkt mit Kapitel 2 fortfahren.

Aus Sicht des Crackers müssen Sie in der Lage sein, Assembler zu verstehen, müssen abernicht unbedingt darin programmieren können (auch wenn das natürlich sehr wün-schenswert wäre). Assembler ist eine Stufe über der Maschinensprache angesiedelt undwird als die niedrigste Sprache betrachtet, die für normale Menschen lesbar ist. EinAssembler ermöglicht Ihnen ein hohes Maß an Kontrolle über die CPU und ist daher einausgezeichnetes Werkzeug, um sich durch die Tücken des Binärcodes zu kämpfen.Erfahrene Cracker träumen in Assembler.

In seiner natürlichen Form ist ein Programm eine Folge von Nullen und Einsen. Zwar stelleneinige Betriebssysteme diese Zahlen in einem hexadezimalen Format dar (das wesentlicheinfacher zu lesen ist als eine Folge binärer Daten), aber wir Menschen benötigen eine(Esels-)Brücke, um effektiver programmieren oder kompilierten Code verstehen zu können.

Liest ein Prozessor eine Programmdatei ein, wandelt er die Binärdaten in Befehle(Instruktionen) um. Diese Instruktionen werden vom Prozessor verwendet, um mathe-matische Berechnungen mit den Daten durchzuführen, um Daten im Speicher hin- undherzubewegen und um Daten von und an Ein- und Ausgabeeinheiten wie Tastatur undBildschirm zu übertragen. Allerdings sind Umfang und Funktionsweise des Befehlssatzesvom Prozessortyp und dessen Leistungsfähigkeit abhängig. Zum Beispiel besitzt ein Intel-Prozessor wie der Pentium 4 einen sehr umfangreichen Befehlssatz, während dieser beieinem RISC-Prozessor vergleichsweise beschränkt ist. Aspekte wie Arbeitsspeicher, Leis-tung und Wärmeentwicklung werden abgewogen, bevor ein Prozessor für ein Gerät aus-gewählt wird. Bei Handheld-Geräten zum Beispiel sind RISC-basierte Prozessoren wieder ARM zu bevorzugen. Ein Pentium 4 würde nicht nur die Batterie in wenigen Minutenentladen, der Benutzer müsste auch hitzebeständige Handschuhe tragen, um das Gerätüberhaupt halten zu können.


4 | Kapitel 1:

Assembler

RegisterEs ist einem Prozessor zwar möglich, Daten direkt aus dem bzw. in das RAM (oder sogarden Cache) zu lesen und zu schreiben, aber das würde zu einem Flaschenhals führen. Umdieses Problem zu beheben, besitzen Prozessoren kleine Mengen internen Speichers. Die-ser Speicher wird Platzhaltern zugeordnet, die als Register bezeichnet werden. Je nachProzessor kann jedes Register zwischen 8 und 128 Bit an Informationen aufnehmen,wobei 32 Bit im Moment am häufigsten sind. Die Information in einem Register kanneinen Wert enthalten, der direkt vom Prozessor verwendet wird, etwa eine Dezimalzahl.Der Wert könnte auch eine Adresse im Speicher repräsentieren, in der der nächste auszu-führende Code steht. Die Fähigkeit, Daten lokal zu speichern, bedeutet, dass der Prozes-sor Lese- und Schreiboperationen mit dem Speicher einfacher durchführen kann. DieseFähigkeit erhöht wiederum die Geschwindigkeit eines Programms, indem die Anzahl derSchreib/Lese-Operationen zwischen RAM und Prozessor reduziert wird.

Bei einem typischen x86-Prozessor gibt es verschiedene Schlüsselregister, mit denen Sie beimReverse Engineering arbeiten werden. Abbildung 1-1 zeigt einen Schnappschuss der Registereiner Windows XP-Maschine mit Hilfe des Befehls debug -r (das Flag -u zeigt den disassemb-lierten Code an).

Die folgende Liste erläutert, wie jedes Register verwendet wird:

AXHauptregister für arithmetische Berechnungen. Häufig als Akkumulator bezeichnet,wird AX meist verwendet, um die Ergebnisse arithmetischer Berechnungen zu akku-mulieren.

Abbildung 1-1: Register eines x86-Prozessors, ausgegeben über den Befehl debug -r unter Windows XP


Register | 5

BX (BP)Das Basisregister wird üblicherweise genutzt, um die Basisadresse des Programmszu speichern.

CXDas Zählerregister (count register) enthält häufig einen Wert, der festlegt, wie oftein Prozess wiederholt werden soll.

DXDas Datenregister nimmt einfach allgemeine Daten auf.

SI und DIDie Quell- (source) und Zielregister (destination) werden als Offset-Adressen ver-wendet, die es einem Register ermöglichen, auf verschiedene Elemente einer Listeoder eines Arrays zuzugreifen.

SS, CS, ES und DSDie Stacksegment-, Codesegment-, Extrasegment- und Datensegment-Register wer-den genutzt, um ein Programm in einzelne Bereiche aufzuteilen. Bei der Ausführungwerden den Segmentregistern die Basiswerte für jedes Segment zugewiesen. Danachwerden Offset-Werte verwendet, um auf jeden Befehl im Programm zuzugreifen.

SPEnthält die Adresse des Stacks (stack pointer). Der Stack nimmt von einem Pro-gramm benötigte temporäre Werte auf. Während sich der Stack füllt, wird SP ent-sprechend angepasst. Wird ein Wert vom Stack benötigt, wird dieser vom Stackgenommen (pop-Operation) oder über eine SP + Offset-Adresse referenziert.

IPDer Anweisungszeiger (instruction pointer) zeigt auf den als Nächstes auszuführen-den Befehl.

Die Liste der hier vorgestellten Register gilt nur für den x86. Obwohl es viele Ähnlichkei-ten gibt, arbeiten doch nicht alle Prozessoren gleich. Zum Beispiel nutzt der ARM-Pro-zessor, der in vielen Handheld-Geräten eingesetzt wird, einige der gleichen Register-typen, verwendet aber andere Namen. Ein Beispiel für die ARM-Register finden Sie inAbbildung 1-2. (ARM Reverse Engineering wird in Kapitel 4 behandelt.)

In Teil I dieses Buches werden Sie lernen, wie diese Register eingesetzt werden und wieman sie für Angriffe wie Pufferüberläufe missbrauchen kann. Es ist sehr wichtig, mit derFunktionsweise der Register vertraut zu sein. Beim Reverse Engineering können Sie biszu 80% Ihrer Zeit damit verbringen, die Werte von Registern zu betrachten und darausabzuleiten, was der Code basierend auf diesen Werten macht.

Den Stack verstehenDie Menge der Daten, die ein Prozessor innerhalb seiner Register vorhalten kann, iststark beschränkt. Um diese Beschränkung zu umgehen, wird Speicher des RAM (oderdes Caches) verwendet, um von einem Programm benötigte Informationen aufzuneh-men.


6 | Kapitel 1:

Assembler

Der Stack (Stapel) ist nichts anderes als ein Bereich des RAM, in dem vom Prozessor ver-wendete Daten gespeichert werden. Sobald ein Programm Informationen speichernmuss, legt es sie über eine so genannte push-Operation auf dem Stack ab. Muss das Pro-gramm die Informationen wieder abrufen, werden sie über eine pop-Operation wiedervom Stack genommen. Diese Methode der Aktualisierung des Stack wird als »last in, firstout« (LIFO) bezeichnet. Um diese Methode zu verdeutlichen, stellen Sie sich einen Stapeldieser kostenlosen AOL-CD-ROMs vor, die man so wunderbar als Untersetzer verwen-den kann. Sobald neue CDs mit der Post kommen, legen Sie sie oben auf dem Stapel ab.Wenn Sie einen Untersetzer brauchen, nehmen Sie die neueste CD vom Stapel herunter.

Der Stack wird zwar einfach nur verwendet, um Daten aufzunehmen, aber der Grund fürseine Existenz ist doch etwas komplizierter. Während der Ausführung des Programmswird in zahllose Subroutinen verzweigt, die für das Hauptprogramm kleinere Funktionenübernehmen. Zum Beispiel führen viele Kopierschutzverfahren eine Prüfung der Serien-nummer durch. Zu diesem Zweck verzweigt das Programm kurzfristig, um festzustellen,ob die Seriennummer korrekt eingegeben wurde. Um diesen Prozess zu ermöglichen,wird die Adresse der nächsten Codezeile des Hauptprogramms (zusammen mit allenbenötigten anderen Werten) auf dem Stack abgelegt. Nachdem die Subroutine ausge-führt wurde, wird die Rücksprungadresse (und die anderen Werte) vom Stack genom-men und die Ausführung des Hauptprogramms fortgesetzt.

Es ist wichtig zu erkennen, dass die LIFO-Struktur des Stack dafür sorgt, dass Prozedu-ren andere Prozeduren aufrufen können, die wiederum weitere Prozeduren aufrufen, unddass der Stack dabei trotzdem immer auf die richtigen Informationen verweist. Sobald

Abbildung 1-2: Die Register ARM-basierter Prozessoren unterscheiden sich von denen des x86


Register | 7

eine Prozedur abgearbeitet wurde, werden die Werte vom Stack entfernt, die vorher dortabgelegt wurden. Abbildung 1-3 zeigt, wie der Stack verwendet wird.

AdressierungEs ist wichtig, die Konzepte der Adressierung zu verstehen, wenn man sich mit ReverseEngineering beschäftigt. So wird zum Beispiel beim ARM-Prozessor häufig ein Offset ver-wendet, um Daten vom Stack zu laden. Wenn Sie nicht genau wissen, wie der Offset ver-wendet wird oder auf welchen Wert im Stack er tatsächlich verweist, sind Sie schnellverloren. Im Fall des ARM-Prozessors lädt der folgende Befehl das Register R1 mit demWert, der an der Adresse des Stackpointers + einem Offset von 8 Byte gespeichert ist:

LDR R1, [SP, 0x8]

Um die Verwirrung noch zu steigern, muss der in R1 geladene Wert kein »echter« Wertsein; es kann sich auch um einen Zeiger handeln, der auf einen anderen Ort verweist, derden Zielwert enthält, nach dem Sie eigentlich suchen.

Es gibt zwei Hauptmethoden, eine Adresse explizit zu ermitteln. Die erste besteht in derVerwendung einer Segmentadresse zusammen mit einem Offset. Die Segmentadressedient als Basisadresse für einen Speicherbereich, der von einem Programm verwendetenCode oder Daten enthält. Ein etwas direkterer Ansatz besteht in der Verwendung dereffektiven Adresse, das heißt der tatsächlichen Adresse, die durch ein Segment und eineOffset-Adresse repräsentiert wird.

Wie bereits erläutert, verwendet ein Programm verschiedene Schlüsselregister, um Datenfestzuhalten und die Programmausführung zu kontrollieren. Werden diese Registerzusammen eingesetzt, verfügt der Prozessor über den direkten und einfachen Zugriff aufeine große Menge von Daten. Zum Beispiel wird das BX-Register häufig verwendet, umeine Basisadresse zu speichern. Diese Adresse wird als definierter Punkt im Speicher ver-wendet, von dem aus Werte abgerufen werden können. Muss ein Programm beispiels-weise auf ein Array oder eine Liste von Daten im Speicher zugreifen, dann kann BX aufden Anfang dieser Liste verweisen. Verwenden Sie diese BX-Adresse in Kombination miteinem SI- oder DI-Wert, wird die gesamte Werteliste für den Prozessor über eine BX+DI-

Abbildung 1-3: Funktionsweise eines Stack


8 | Kapitel 1:

Assembler

Referenz zugänglich. Reicht Ihnen diese Kontrolle nicht aus, können Sie auf ein Elementim Array über einen Offset wie BX+DI+8 zugreifen. Wie Sie sehen, kann die Adressie-rung sehr verwirrend sein, solange Sie nicht genau wissen, wie die Register verwendetwerden.

Assembler-OpcodesNachdem Sie wissen, was Register sind und wie man auf Speicher zugreift, wollen wirIhnen noch kurz zeigen, wie man Opcodes verwendet. Dies ist nur eine kurze Zusam-menfassung, weil jeder Prozessortyp und jede Prozessorversion einen anderen Befehlssatzverwendet. Einige Unterschiede sind kleinerer Natur, etwa die Verwendung von JMP(jump) oder B (branch) für einen Sprungbefehl. Andere Unterschiede, etwa die Anzahlder dem Prozessor zur Verfügung stehenden Opcodes, haben einen wesentlich größerenEinfluss darauf, wie ein Programm funktioniert.

Opcodes sind die tatsächlichen Instruktionen, die ein Programm ausführt. Jeder Opcodewird durch eine Codezeile repräsentiert, die den Opcode und die von ihm verwendetenOperanden enthält. Die Anzahl der Operanden hängt vom Opcode ab. Die Größe einerZeile ist aber immer auf eine bestimmte Länge im Programmspeicher beschränkt. Ein16-Bit-Programm könnte zum Beispiel einen 1-Byte-Opcode und einen 1-Byte-Operan-den verwenden, während ein 32-Bit-Programm mit einem 2-Byte-Opcode und einem2-Byte-Operanden arbeiten könnte. Beachten Sie, dass das nur eine mögliche Konfigura-tion ist, die nicht für alle Befehlssätze gilt.

Wie bereits früher erwähnt, wird die Gesamtmenge der einem Prozessor zur Verfügungstehenden Opcodes als Befehlssatz (instruction set) bezeichnet. Jeder Prozessor besitztseinen eigenen Befehlssatz. Sie müssen mit dem Befehlssatz des Prozessors vertraut sein,bevor Ihnen ein Reverse Engineering für ein entsprechendes Gerät möglich ist. Ohne dieLaunen zwischen den Opcodes zu verstehen, werden Sie endlose Stunden damit verbrin-gen herauszufinden, was ein Programm genau macht. Das kann recht schwierig werden,wenn man mit so verwirrenden Opcodes wie UMULLLS R9, R0, R0, R0 konfrontiert wird(der Befehl wird in Kapitel 4 erläutert). Ohne mit dem ARM-Befehlssatz vertraut zu sein,werden Sie wohl kaum erraten, dass hier eine vorzeichenlose long-Multiplikation durch-geführt wird, wenn das LS-Flag gesetzt ist (wobei die Status-Flags nach der Ausführungentsprechend aktualisiert werden).

Noch ein letzter Hinweis: Werden Programme disassembliert, variiert die Syntax derAssembler-Ausgabe je nach verwendetem Disassembler. Ein bestimmter Disassemblerkönnte die Operanden in genau der umgekehrten Reihenfolge eines anderen Disassemb-lers anordnen. Bei vielen Linux-Beispielen in diesem Buch erscheint der Befehl

mov %edx,%ecx

unter Windows als:

mov ecx,edx

weil die beiden im Text genannten Disassembler unterschiedlich arbeiten.


Referenzen | 9

Referenzen• The Art of Assembly Language (http://webster.cs.ucr.edu/Page_asm/ArtOfAsm.html)

• Assembly Language Step-by-Step: Programming with DOS and Linux (with CD-ROM) von Jeff Duntemann. John Wiley & Sons, Mai 2000.

• An Assembly Language Introduction to Computer Architecture: Using the Intel Pen-tium von Karen Miller und Jim Goodman. Oxford University Press, März 1999.

• IA-32 Intel® Architecture Software Developers Manual (http://www.intel.com/design/Pentium4/manuals/24547012.pdf)

• Intel® XScale™ Microarchitecture Assembly Language Quick Reference Card(http://www.intel.com/design/iio/swsup/11139.htm)


10 | Kapitel 2:

Windows Reverse Engineering

KAPITEL 2


Das Software Reverse Engineering, auch Reverse Code Engineering (RCE) genannt, ist dieKunst des Sezierens unbekannter Binäranwendungen, deren Quellcode nicht offen liegt(»closed source«). Im Gegensatz zur Open Source-Software, die theoretisch einfacher aufSicherheitslücken untersucht werden kann, präsentiert Closed Source-Software demBenutzer eine »Blackbox«. Historisch gesehen wurde RCE auf Windows-Plattformendurchgeführt, aber es gibt nun auch einen wachsenden Bedarf an professionellem Linux-Reverse-Engineering, wie wir in Kapitel 3 noch erläutern werden.

Das RCE erlaubt es Ihnen, in diese Blackbox hineinzusehen. Indem Sie eine Binäranwen-dung disassemblieren, können Sie die Ausführung des Programms auf unterster Ebenebeobachten. Sobald eine Anwendung auf Maschinensprache heruntergebrochen werdenkonnte, kann ein erfahrener Praktiker die Operation jeder Binäranwendung verfolgen,ganz egal, wie gut der Software-Entwickler sie zu schützen versucht hat.

Warum sollte man als Sicherheitsexperte RCE lernen wollen? Der Hauptgrund ist dasReversing von Malware wie Viren und Trojanern. Die Antivirus-Industrie ist von der Fähig-keit abhängig, Binaries zu analysieren, um diese Schädlinge diagnostizieren, desinfizierenund verhindern zu können. Darüber hinaus führt die Verbreitung von ethisch fragwürdigerkommerzieller Spyware und von »nach Hause telefonierenden« Kopierschutzmechanismenzu ernsthaften Verletzungen der Privatsphäre.

In diesem Kapitel arbeiten wir mit Windows-Betriebssystemen für denDesktop. Weil Windows eine geschlossene und häufig feindselige Platt-form ist, hat Darwinscher Druck dazu geführt, dass das Windows-RCE dieSpitze der Entwicklung darstellt. In den nachfolgenden Kapiteln stellen wirRCE für andere Plattformen vor, darunter Linux und Windows CE, wosich RCE noch in den Kinderschuhen befindet.

Die Legalität des RCE ist in vielen Bereichen immer noch fraglich. Ein Großteil der kom-merziellen Software wird mit einer Endbenutzer-Lizenzvereinbarung (end-user licenseagreement, kurz EULA) ausgeliefert, durch die man sich einfach nur »durchklicken«muss. Nach Ansicht der Software-Hersteller akzeptieren Sie deren Lizenzbedingungen,


| 11

sobald Sie bei der Software-Installation »Ich stimme zu« anklicken. Die meisten EULAsenthalten eine Klausel, die dem Endbenutzer (mit Hinweis auf den Schutz intellektuellenEigentums des Herstellers) ein Reverse Engineering der Anwendung untersagen. Tat-sächlich sieht der amerikanische Digital Millennium Copyright Act (DMCA) für einigeArten des Reverse Engineering harte Strafen vor.1

Zum Beispiel waren wir als Konferenzredner auf der Defcon 9 zur Computersicherheitschockiert und verzweifelt, hören zu müssen, dass einer unser Kollegen verhaftet wurde,nur weil er über seine akademischen Forschungen sprach. Nach seiner Rede über dieSicherheit von E-Books wurde Dmitry Sklyarov, ein 27 Jahre alter russischer Doktorand,auf dem Gelände des Alexis Park Hotels verhaftet. Die vom FBI durchgeführte Verhaf-tung wurde durch eine Beschwerde von Adobe Systems veranlasst, dem Hersteller derfraglichen E-Book-Software.

In einem Schritt, der einen neuen Präzedenzfall zu schaffen schien, behauptete der aus-führende FBI-Agent bei der Beantragung des Haftbefehls, dass die Defcon als »Hacker«-Konferenz angekündigt worden sei und dass die Sprecher daher Kriminelle sein müssten.Allerdings vergaß dieser FBI-Agent zu erwähnen, dass andere hochrangige Gesetzesver-treter, Mitglieder des Militärs und sogar einige FBI-Kollegen auf der gleichen »Hacker«-Konferenz (und deren Vorgänger Black Hat) als Sprecher angekündigt waren. Tatsäch-lich sprach Richard Clarke, Sonderberater von Präsident Bush für die Sicherheit imCyberspace, im folgenden Jahr auf der Defcon.

Sklyarov half seinem russischen Arbeitgeber Elcomsoft bei der Entwicklung des Advan-ced eBook Processor (AEBPR). Laut Elcomsoft ermöglicht es diese Software den Besit-zern von E-Books, das sichere E-Book-Format von Adobe in das weit verbreitete PortableDocument Format (PDF) umzuwandeln. Da die Software nur mit legal erworbenenE-Books funktioniert, unterstützt sie nicht direkt die Verletzung von Urheberrechten. DieSoftware ist nützlich, um gültige Datensicherungen wertvoller Daten anzulegen.

Sklyarov wurde angeklagt, ein Produkt vertrieben zu haben, das entwickelt wurde, umein Kopierschutzverfahren zu umgehen, was laut DMCA (auf das wir später in diesemKapitel eingehen) eine Straftat darstellt. Ein breiter Aufschrei ging durch die akademischeWelt und die Anhänger der individuellen Handlungsfreiheit, und die Proteste machtensich sogar weltweit vor den Büros von Adobe Luft. Adobe, das seinen gravierenden Feh-ler zu ahnen begann, ruderte sofort zurück – aber es war zu spät. Der Schaden war schonpassiert.

Sklyarov wurde schließlich gegen eine Kaution von $50.000 freigelassen und durfte Kali-fornien nicht verlassen. Im Dezember 2001 durfte er mit seiner Familie nach Russland

1 Auch in Europa kann jeder nicht gestattete Eingriff in eine Software strafbar sein. Abgesehen von zivilrechtli-chen Ansprüchen der Hersteller ist Reverse Software Engineering in Deutschland (wie in der ganzen EU) prin-zipiell verboten. Siehe hierzu unter anderem das »Gesetz über Urheberrecht und verwandte Schutzrechte«(UrhG, http://bundesrecht.juris.de/bundesrecht/urhg/) mit Stand vom September 2003. Relevant sind darin vorallem: Teil 1, Urheberrecht, Abschnitt 8, Besondere Bestimmungen für Computerprogramme. In § 69e,Dekompilierung, werden die Bedingungen genannt, unter denen Reverse Engineering erlaubt ist (zur »Inter-operabilität mit anderen Programmen«). – Anm.d.V.


12 | Kapitel 2:


zurückkehren, allerdings nur unter der Bedingung, auf Abruf in die USA zurückzukehrenund gegen seinen Arbeitgeber Elcomsoft auszusagen. Nach einem ärgerlichen Rechts-streit wurden sowohl Sklyarov als auch Elcomsoft schließlich vollständig rehabilitiert.

Der DMCA gibt einem immer noch einen gewissen Spielraum, da das Gesetz »Sicher-heitsexperten« in eingeschränktem Maß erlaubt, Schutzmechanismen zu umgehen, umderen Sicherheit zu prüfen. Allerdings ist die Interpretation dieser Klausel nach wie vorsehr nebulös.

Geschichte des RCEDas »moderne« RCE begann mit Programmierern, die den Kopierschutz klassischerComputerspiele umgingen, etwa solchen, die in den frühen 1980ern für den Apple II ent-wickelt wurden. Auch wenn dieser Trend dazu missbraucht wurde, raubkopierte Soft-ware zu vertreiben, blieb doch ein Kern von Experten übrig, die sich dem Thema RCEallein aus akademischen Gründen widmeten.

Eine der legendären Figuren dieser spannenden Zeit war Old Red Cracker (+ORC).+ORC war aber nicht nur ein genialer Software-Reverser, sondern auch ein produktiverAutor und Lehrer. Seine klassischen Texte werden heute noch als grundlegende Lektürefür alle RCE-Interessierten betrachtet.

Um die RCE-Entwicklung voranzubringen, gründete +ORC die High Cracking Univer-sity (kurz +HCU). Das »+«-Zeichen oder »Handle« neben dem Namen war ein Erken-nungszeichen der Mitglieder der +HCU. Zu den +HCU-»Studenten« zählte ein Großteilder weltweit besten Windows-Reverser. Jedes Jahr veröffentlichte die +HCU eine neueReverse-Engineering-Aufgabe (eine so genannte »Challenge«), und die Autoren einerHandvoll der besten Antworten wurden als Studenten für das neue Schuljahr eingeladen.

Einer der Professoren, bekannt als +Fravia, pflegte eine bunt gemischte Website namens»+Fravia’s Pages of Reverse Engineering«. In diesem Forum stellte +Fravia Programmie-rern nicht nur Challenges zur Verfügung, sondern forderte die Gesellschaft selbst auf, dieGehirnwäsche eines korrupten und wild wuchernden Materialismus einem »ReverseEngineering« zu unterziehen. Auf dem Höhepunkt wurden auf +Fravias Site abermillio-nen Hits pro Jahr verzeichnet, und sein Einfluss war überall spürbar.

Heutzutage hat ein Großteil der alten +HCU-Recken Windows den Rücken gekehrt, umsich der weniger okkulten Linux-Plattform zu widmen. Nur einige wenige wie +Tsehpbeschäftigen sich noch mit dem Reverse Engineering von Windows-Software. Eine neueGeneration von Reversern hat die alten Texte wiederentdeckt und damit begonnen, diealte Wissenschaft wieder voranzubringen. +Fravia selbst kann man noch immer in seinerendlosen Bibliothek unter http://www.searchlores.org herumwandern sehen.


Kenne deinen Feind - download.e-bookshelf.de...Netzwerk-Sicherheit mit RCE, IDS, Honeypots u.a....

Documents

Transcript of Kenne deinen Feind - download.e-bookshelf.de...Netzwerk-Sicherheit mit RCE, IDS, Honeypots u.a....