Zum einen werten wir die bisher gesammelten Informationen aus und zum anderen gehen wir noch einen Schritt weiter und suchen mit Vulnerability-Scannern und ähnlichen Tools nach Schwachstellen. Auch hier kann uns z.B. Nmap erneut unterstützen – dank NSE helfen uns viele kleine Nmap-Skripts bei der weitergehenden Schwachstellenanalyse.
Darüber hinaus gibt es eine Menge Programme, die genau für diese Aufgabe konzipiert sind. Im Einzelnen haben wir in diesem Kapitel folgende Themen für Sie:
Neben der Vorstellung einiger ausgesuchter Tools möchten wir Ihnen in diesem Kapitel auch ein wenig die Praxis des Vulnerability-Scannings und des organisatorischen Rahmens eines Vulnerability-Assessments aus unterschiedlichen Blickwinkeln näherbringen.
9.1 Was steckt hinter Vulnerability-Scanning?
Dazu zunächst eine andere Frage: Wo stehen wir jetzt? Wir haben die Zielsysteme gescannt und möglichst viele Informationen ermittelt, unter anderem:
Welche Systeme sind im Netzwerk aktiv?
Welche Ports sind offen?
Welche Betriebssysteme werden verwendet (inkl. Patch-Stände, wenn möglich)?
Welche Dienste in welcher Software-Version laufen auf den einzelnen Systemen?
Welche Informationen liefern die Dienste? (Stichwort: Enumeration)
Damit haben wir bereits einen guten Überblick über vorhandene Komponenten, Software inklusive deren Versionen und über diverse bereitgestellte Ressourcen, wie Benutzer, Gruppen, Freigaben etc. Als Ethical Hacker interessieren uns nun mögliche Schwachstellen, die sich daraus ergeben. Hierzu müssen wir feststellen, ob eine bestimmte Komponente angreifbar ist oder nicht. Dies leistet das Vulnerability-Scanning. Es kann manuell, teil- oder vollautomatisiert erfolgen. Auf der anderen Seite können wir die Schwachstellen auch direkt identifizieren, z.B. durch eine Internet-Recherche.
An dieser Stelle beschränken wir uns auf bekannte Schwachstellen und vorhandene Exploits. Die hohe Kunst des Reverse Engineerings und die Suche nach neuen, noch unbekannten Schwachstellen durch Source-Code-Analyse ist außerhalb der Zielstellung dieses Buches und des CEH-Curriculums. Im Rahmen der Malware-Analyse werden wir später im Buch jedoch noch ein wenig näher auf das Reverse Engineering eingehen.
Die Schwachstellenanalyse schließt sich den bisher vorgestellten Scanning-Methoden fließend an und gehört inhaltlich noch zur Scanning-Phase.
9.1.1 Vulnerabilities und Exploits
Wir unterscheiden in Vulnerabilities (Schwachstellen) bzw. Exposures auf der einen Seite und Exploits auf der anderen Seite. Während die Vulnerabilities und Exposures (letzterer Begriff wird eher selten verwendet) die prinzipielle Verwundbarkeit einer IT-Komponente (in der Regel einer Software) beschreiben, stellen Exploits eine konkrete Möglichkeit dar, diese Schwachstellen auszunutzen (engl. to exploit = ausnutzen). Dies umfasst meistens ein Stückchen Programmcode und ggf. einen Prozess, um die Schwachstelle effektiv für einen Angriff auszubeuten.
Genauso wie es Vulnerabilities für alle denkbaren IT-Komponenten und Programme gibt, so unterscheiden wir bei den Exploits in verschiedene Kategorien bzw. Klassifikationen:
Lokale Exploits: Ermöglichen das Ausnutzen einer Schwachstelle auf dem lokalen Computer.
Remote-Exploits: Verschafft dem Angreifer Zugang zu einem System über das Netzwerk.
DoS-Exploits: Ermöglichen Denial-of-Service-Angriffe, bei denen das angegriffene System seinen Dienst einstellt.
Command-Execution-Exploits: Dadurch können Angreifer die Ausführung des Programms auf dem Zielsystem steuern, um in der Regel eigenen Programmcode aufzurufen, der z.B. eine Remote-Shell bereitstellt.
SQL-Injection-Exploits: Diese Kategorie stellt einen Angriff auf SQL-basierte Datenbank-Systeme dar, wobei z.B. durch gezielte Falscheingabe Informationen aus der Datenbank extrahiert werden können, die über das gewünschte Maß hinausgehen.
Zero-Day-Exploits: Bezeichnen einen Exploit beliebiger Klassifizierung, der eine noch nicht bekannte Sicherheitslücke ausnutzt und daher extrem schwer zu vermeiden bzw. zu bekämpfen ist.
Schauen Sie sich die obige Liste genau an und prägen Sie sich die Begrifflichkeiten am besten jetzt schon einmal ein – wir kommen an verschiedenen Stellen im Buch später wieder darauf zurück.
9.1.2 Common Vulnerabilities and Exposures (CVE)
Bei den CVE handelt es sich um einen Industriestandard, um Schwachstellen und Sicherheitslücken in Computersystemen eindeutig zu identifizieren und zu beschreiben. Dazu erhält jede gefundene Sicherheitslücke eine eindeutige Bezeichnung (CVE ID genannt), die sich aus der Jahreszahl der Aufdeckung sowie einer mindestens vierstelligen Nummer ableitet, z.B. CVE-2018-0224. Jeder CVE-Eintrag verfügt über eine Beschreibung (Description) sowie Referenzen, die auf Webseiten mit weiteren Informationen führen. Die originale CVE-Datenbank finden Sie derzeit noch unter https://cve.mitre.org.
Unter Search CVE List können Sie nach CVE-Einträgen zu einer gewünschten Komponente oder einem Hersteller suchen, z.B. durch Eingabe von »Windows 10« oder Ähnliches.
Der Vorteil ist, dass diese zentrale Erfassung von Schwachstellen und Sicherheitslücken eine Vereinheitlichung und eindeutige Identifizierung ermöglicht, auf die verschiedene Unternehmen und Institutionen verweisen können.
Die zentrale Erfassung von Schwachstellen heißt allerdings nicht, dass Software-Hersteller nicht auch eigene Bezeichnungen für die Schwachstellen ihrer Produkte verwenden. So wurden z.B. die bekannten Sicherheitslücken von Microsoft-Produkten bis 2017 im Security-TechCenter (auch: Security-Bulletin), https://docs.microsoft.com/de-de/security-updates/securitybulletins/securitybulletins, veröffentlicht. Hier erhalten sie z.B. eine ID in der Form MS17-019. Oft gibt es aber auch eine Referenz auf die entsprechende CVE-ID, wobei insbesondere bei Microsoft auch die MS-IDs sehr gängig sind. Seit 2018 verweist Microsoft nur noch auf die CVE-IDs.
Die Website befindet sich zum Zeitpunkt Mitte 2023 in einer Migrationsphase auf www.cve.org.
9.1.3 CVE- und Exploit-Datenbanken
Die Website https://cve.mitre.org ist nicht unbedingt mit Benutzerfreundlichkeit gesegnet. Eine Reihe weiterer Datenbanken bietet ähnliche Informationen, teilweise besser oder zumindest anders aufbereitet. Die Website www.cvedetails.com liefert z.B. diverse Perspektiven auf die CVEs nach unterschiedlichen Kriterien sortiert und enthält zusätzliche Informationen, wie z.B. Links zu Exploit-Code oder die Angabe der entsprechenden Metasploit-Module.
Eine weitere Quelle ist https://nvd.nist.gov. Diese Seite wird vom NIST, dem National Institute of Standards and Technology, bereitgestellt. Sie liefert über den Menüpunkt General | NCD Dashboard einen Blick auf die neuesten Schwachstellen und bewertet diese.
Wer direkt nach einem Exploit-Code für eine bestimmte Schwachstelle suchen möchte, ist bei www.exploit-db.com richtig – diese Datenbank wird von Offensive Security, dem Herausgeber von Kali Linux, gepflegt und enthält geprüfte und verifizierte Exploits.
Natürlich existieren noch weitere Quellen, von denen entsprechende Exploits bezogen werden können. Die Suchmaschine https://sploitus.com eignet sich gut für eine einfache Suche, aber auch auf https://github.com sind meist Payloads und Codes für die Ausnutzung einer Schwachstelle zu finden.
Von Rapid7, dem Entwickler und Herausgeber des bereits bekannten Hacking-Frameworks Metasploit, kommt eine »Vulnerability & Exploit Database«, die Sie unter www.rapid7.com/db finden. Auch diese Plattform bietet diverse weiterführende Infos und Links zu bekannten Schwachstellen.
Es lohnt sich, diese Webseiten einmal ausführlicher zu studieren und insbesondere die Suchfunktionen kennenzulernen. Im weiteren Verlauf dieses Buches geht es an vielen Stellen darum, gezielt Schwachstellen auszunutzen, um sie zu verifizieren und »False Positives« ausschließen zu können. Darüber hinaus sind die hier genannten Anbieter keineswegs die einzigen, sodass Sie durchaus auch auf weitere Quellen stoßen könnten.
9.1.4 Vulnerability-Scanner
In vielen Fällen ist es zu aufwendig und zu langwierig, manuell nach Schwachstellen zu suchen. Daher gibt es darauf spezialisierte Software, die ein System bzw. ein Netzwerk nach Schwachstellen absucht – sogenannte »Vulnerability-Scanner«. Sie verwenden dabei, ähnlich wie Virenscanner, entsprechende Plug-ins und prüfen damit die Systeme auf bekannte Schwachstellen. Die Informationen dazu stammen ebenfalls aus CVE-Datenbanken.
Dabei gehen sie prinzipiell folgendermaßen vor:
Der Pentester legt eine Zieladresse bzw. ein Zielnetzwerk fest, das gescannt werden soll.
Es wird eine Scanning-Policy ausgewählt, die bestimmt, in welcher Art der Scan durchgeführt werden soll.
Der Vulnerability-Scanner prüft die Zielsysteme und versucht zu ermitteln, ob das jeweilige Betriebssystem oder die Software Schwachstellen aufweist.
Anschließend wird ein Report erzeugt, der dem Anwender gefundene Schwachstellen – in der Regel nach Priorität sortiert – aufzeigt.
Es gibt allgemeine Vulnerability-Scanner und solche, die sich auf bestimmte Bereiche, z.B. Webapplikationen, spezialisiert haben. Der Vorteil ist, dass der Penetration-Tester hier eine schnelle und umfassende Übersicht erhält. Doch es gibt durchaus auch den einen oder anderen Nachteil:
Der Scan ist sehr »laut«. Das bedeutet, dass die Scanning-Aktivität mit hoher Wahrscheinlichkeit bemerkt werden wird – entweder durch IDS/IPS oder durch SIEM-Systeme (SIEM = Security Information and Event-Management), die Logfiles korrelieren und Angriffe über typische Kommunikationsmuster erkennen können. Damit sind umfangreiche Scans selten sinnvoll im Rahmen eines effektiven Hacking-Angriffs und eher im Rahmen von Vulnerability-Assessments der Organisation selbst anzutreffen.
Die Durchführung eines solchen Scans nimmt in der Regel viel Zeit in Anspruch. Je mehr Informationen Sie allerdings bereits über Ihre Ziele haben, umso genauer kann der Scan konfiguriert werden. Nach einem vorhergehenden Ping-Scan können Sie nur erreichbare Systeme nach Schwachstellen scannen und sparen dadurch Zeit.
Das Ergebnis ist teilweise ungenau: Aufgrund des automatischen Scans werden häufig False Positives erzeugt und natürlich auch einige False Negatives, wenn der Scanner irrtümlich davon ausgeht, dass das System oder der Dienst nicht angreifbar ist. Das bedeutet, die Ergebnisse müssen meistens in der einen oder anderen Form verifiziert werden.
Bei umfangreichen Scans kann unter Umständen die Stabilität und Integrität des Netzwerks gefährdet werden, da nicht nur reguläre Datenpakete, sondern auch Testpakete mit nicht-konformen Inhalten gesendet werden. Einige Systeme reagieren hier erstaunlich sensibel und versagen ggf. den Dienst – und auch wenn das eigentlich peinlich für den Hersteller ist, so werden hier doch oftmals die Penetration-Tester zur Rechenschaft gezogen.
Fassen wir also zusammen: Vulnerability-Scanner ermöglichen es, automatisiert einzelne Systeme oder ganze Netzwerke auf Schwachstellen zu scannen. Je nach Konfiguration (Policy) gehen sie dabei mehr oder minder brachial zu Werke und erzeugen viel »Krach«. In diesem Zusammenhang kann die Integrität einzelner Systeme oder des Netzwerks in Mitleidenschaft gezogen werden. Die Ergebnisse sind nicht immer zuverlässig und müssen verifiziert werden.
Im Ergebnis ist der Einsatz von Vulnerability-Scannern also keineswegs ein »Selbstläufer«, bei dem der unerfahrene Admin oder Penetration-Tester einfach mal auf den Start-Button klickt – jedenfalls nicht ohne Konsequenzen. Die Chance, unerkannt zu bleiben, ist – abhängig vom Szenario – eher gering. Der Einsatz von derartigen Scannern will also sowohl von Penetrationstestern als auch von Hackern wohlüberlegt und geplant werden. Mehr dazu in Abschnitt 9.5. Jetzt wollen wir uns erst mal der technischen und praktischen Seite widmen.
9.3 Nessus
Nessus war ursprünglich ein Kentaur aus der griechischen Mythologie. Er begehrte Deianeira, die Frau von Herkules. Das fand dieser jedoch nicht so toll und brachte ihn daher um, indem er ihn mit einem vergifteten Pfeil erschoss. Durch einen Trick sorgte Nessus vor seinem Tod dafür, dass Deianeira das Hemd von Herkules mit dem vergifteten Blut des sterbenden Nessus tränkte – das wiederum sorgte später dafür, dass Herkules unermessliche Qualen litt und sich auf einem Scheiterhaufen verbrennen ließ. Inwieweit diese Geschichte für die Entwickler des Vulnerability-Scanners inspirierend war, sodass sie ihrer Software diesen Namen gaben, ist nicht ganz geklärt – wir überlassen es Ihnen, hier einen Zusammenhang herzustellen. Fakt ist jedoch, dass Nessus der mittlerweile beliebteste Vulnerability-Scanner ist und weltweit eingesetzt wird.
9.3.1 Installation von Nessus
Nessus wird vom Unternehmen Tenable bereitgestellt. Unter www.tenable.com/downloads/nessus können Sie die Software für verschiedene Plattformen herunterladen – unter anderem diverse Linux-Distributionen, aber auch Windows und macOS. Für Kali Linux nutzen Sie die Debian-Version. Achten Sie auf die richtige Plattform, 32 oder 64 Bit.
Die Installation der vorgefertigten Pakete auf der jeweiligen Plattform ist denkbar einfach. Bleiben wir beim Beispiel Kali Linux. Der folgende Befehl installiert Nessus nach dem Download, den Pfad und Namen der Datei müssen Sie natürlich ggf. anpassen:
dpkg -i Nessus-10.5.2-ubuntu1404_amd64.deb
Anschließend starten Sie den Nessus-Daemon, wie in der Ausgabe der Installationsroutine beschrieben:
systemctl start nessusd.service
Nessus bindet sich standardmäßig an den Port 8834. Verbinden Sie sich mit dem Frontend über einen Browser mit der Adresse https://127.0.0.1:8834.
Da Nessus ein selbst signiertes Zertifikat verwendet, müssen Sie dafür im Browser eine Ausnahme-Regel erstellen, da die Verbindung ansonsten nicht als vertrauenswürdig eingestuft wird.
Als Erstes können Sie nun eine Nessus-Variante auswählen. Hier wird zwischen Nessus Essentials, Professional und Nessus Expert unterschieden. Die kostenfreie Essentials-Version ist beschränkt auf 16 scanbare IP-Adressen und daher für einen professionellen Einsatz nicht geeignet. Zum Lernen ist dies jedoch perfekt, daher wählen Sie an dieser Stelle am besten Nessus Essentials.
Im folgenden Schritt werden Sie aufgefordert, einen Activation Code zu beantragen. Diesen bekommen Sie nach der Registrierung angezeigt. Am besten notieren Sie diesen in einem Password-Safe.
Bevor Sie dann loslegen können, müssen Sie noch einen Benutzer als Administrator festlegen.
Im Anschluss beginnt die Initialisierungsphase, die recht lange dauern kann. Sie beinhaltet den Download der sogenannten »Plug-ins«. Analog zu den Pattern-Dateien der Virenscanner benötigen Vulnerability-Scanner bestimmte Informationen, welche Schwachstellen wie geprüft werden können. Genau genommen steht und fällt ein Vulnerability-Scanner mit diesen Plug-ins.
Schließlich sind wir startbereit. Die Nessus-Oberfläche präsentiert sich zunächst sehr schlicht.
Erst wenn die drehenden Fortschrittspfeile oben rechts im Bild verschwunden sind und etwas später dann auch der Button New Scan anklickbar ist, wurden die Plugins kompiliert und wir können nachfolgend gemeinsam einen Nessus-Scan konfigurieren und diesen ausführen.
9.3.2 Vulnerability-Scanning mit Nessus
Jetzt etwas Praxis zum Mitmachen: Klicken Sie auf New Scan rechts bzw. den Link in der Mitte Create a new scan. An dieser Stelle präsentiert Nessus Ihnen seine Scan-Templates, wie in Abbildung 9.10 zu sehen.
Sie finden hier diverse Schablonen für verschiedene Zwecke. Einige sind jedoch nur in der Professional- oder Expert-Version verfügbar, zu erkennen an dem Hinweis Upgrade.
Möchten Sie alle Einstellungen selbst vornehmen, erhalten Sie über Advanced Scan die volle Kontrolle über alle relevanten Einstellungsmöglichkeiten. Davon existieren bei Nessus sehr viele, die wir im Rahmen dieser Einführung jedoch nicht im Detail durchgehen werden.
Stattdessen klicken Sie auf Basic Network Scan. Nun können Sie nach Bedarf einige Einstellungen vornehmen. Die obligatorischen Eingabefelder enthalten einen Hinweis Required. Füllen Sie die Felder unter dem Register Basic|General passend aus, wie in Abbildung 9.11 beispielhaft gezeigt.
Unter Discovery wählen Sie als Scan Type den Eintrag Port Scan (all ports). In der Default-Einstellung werden nur die häufigsten Ports gescannt, analog zu Nmap.
Nun klicken Sie auf Save, um den Scan zu speichern. Im Anschluss wird der konfigurierte Scan unter My Scans angezeigt.
Klicken Sie auf das Play-Symbol, um den Scan zu starten. Im Anschluss können Sie sich den Fortschritt anzeigen zu lassen, indem Sie auf die Zeile des Scans klicken.
Sie können hier auch »live« verfolgen, wie der Scan neue Vulnerabilities entdeckt. Jeder gescannte Host erhält eine eigene Zeile. Klicken Sie auf den Balken in der Spalte Vulnerabilities, um sich die Details für die Fundstellen dieses Hosts anzeigen zu lassen.
Auch hier wird die Anzeige regelmäßig aktualisiert, solange der Scan läuft. Ist er abgeschlossen, sehen Sie die finale Liste der gefundenen Vulnerabilities.
Ist der Scan abgeschlossen, können Sie einen Bericht erstellen. Dazu markieren Sie die gewünschten Objekte, klicken auf den Report-Button und wählen das gewünschte Format aus.
Zum Abschluss dieser Einführung exportieren Sie nun das Scanergebnis für den Metasploitable-Host als HTML-Datei.
Haben Sie den Export abgeschlossen, können Sie die HTML-Datei mittels Browser öffnen.
Sie werden feststellen, dass diese Form des Reports sehr lang ist. Eine knappe Übersicht stellt da die »Complete List of Vulnerabilities by Host« dar. Dieses Report-Format wird gewöhnlich für die Geschäftsleitung oder andere, nicht-technische Zielgruppen erstellt, um eine schnelle Übersicht über die Ergebnisse zu erhalten, ohne zu sehr in die technischen Details eintauchen zu müssen.
Damit sind wir am Ende unseres kleinen Einstiegstutorials angelangt, das Sie bei Ihren ersten Schritten mit Nessus begleiten sollte. Nun sind Sie an der Reihe: Testen Sie Nessus aus, experimentieren Sie und lernen Sie diesen Vulnerability-Scanner möglichst gut kennen. Er ist der Platzhirsch unter den Scanner-Produkten und wird Ihnen in der Praxis vermutlich häufiger begegnen.
9.3.3 Nessus versus OpenVAS
Das Projekt OpenVAS (VAS steht für Vulnerability Assessment System) wurde 2005 von Nessus abgespalten, da die Betreiber von Nessus auf die kommerzielle Schiene wechselten und das Produkt mit einer proprietären Lizenz weiterbetreiben wollten. Greenbone OpenVAS ist dagegen Open Source und im Wesentlichen unter der GPL lizenziert. Es handelt sich um ein Framework aus verschiedenen Diensten und Tools für das Vulnerability-Scanning.
Warum sollten Sie nun aber neben OpenVAS zusätzlich noch Nessus verwenden? Reicht nicht der eine oder andere Scanner?
In der Praxis empfiehlt es sich, grundsätzlich mehrere Vulnerability-Scanner einzusetzen, da die Fundstellen selten komplett übereinstimmen. Tatsächlich unterscheiden sich die Fundstellen von OpenVAS und Nessus teilweise drastisch, sodass Sie hier erheblichen Zusatznutzen erhalten.
Aus Platzgründen haben wir den Praxis-Workshop für OpenVAS ausgelagert. Sie können die Schritt-für-Schritt-Anleitung als Zusatzmaterial unter www.hacking-akademie.de/buch/member herunterladen.
9.4 Rapid 7 Nexpose
Ein weiterer, sehr häufig eingesetzter Vulnerability-Scanner ist Nexpose von Rapid 7. Das Spannende ist, das Rapid 7 auch für das Metasploit-Framework verantwortlich ist, mit dem konkrete Exploits für Vulnerabilities eingesetzt und getestet werden können.
Dementsprechend gut ist natürlich die Integration von Nexpose und Metasploit. Für Nexpose gibt es eine Trial-Version, mit der Sie zeitlich begrenzt testen können.
Da Nexpose ganz ähnlich wie OpenVAS und Nessus aufgebaut ist und verwendet wird, verzichten wir an dieser Stelle auf eine detaillierte Beschreibung der Installation und eine Einführung in den praktischen Einsatz. In jedem Fall sollten Sie sich einmal mit Nexpose beschäftigen. Unter www.rapid7.com/products/nexpose/download finden Sie eine Möglichkeit, die Testversion herunterzuladen.
Herausragend bei Nexpose ist die Integration von Exploits, die Metasploit bereitstellt. Zu jeder Fundstelle erfahren Sie im Report zum einen, ob es bekannte Malware gibt, die die Schwachstelle ausnutzt, und zum anderen, ob es einen Metasploit-Exploit dafür gibt. Dies ist nicht nur für einen echten Angreifer relevant, sondern auch für Sie als Pentester, da Sie jede Fundstelle verifizieren müssen, um False Positives auszuschließen.
Analog zu Nessus können Sie auch bei Nexpose aus einer Reihe von Scan-Templates auswählen, wobei auch hier die Möglichkeit besteht, den Scan umfassend manuell zu konfigurieren. Auch hier gilt wieder, dass die Scan-Ergebnisse von vielen Faktoren abhängen und teilweise deutlich von denen anderer Produkte abweichen können.
9.5 Vulnerability-Scanning in der Praxis
Sie haben nun diverse Ansätze für das Vulnerability-Scanning mit verschiedenen, einschlägigen Tools kennengelernt. Dabei haben wir uns primär auf die Funktionalität und die technische Seite konzentriert. An dieser Stelle möchten wir Ihnen noch ein paar grundsätzliche Überlegungen mit auf den Weg geben, die Sie beim Vulnerability-Scanning im Rahmen von Penetration-Tests und Ethical Hacking berücksichtigen sollten.
9.5.1 Vulnerability-Assessments
Vulnerability-Assessments werden aufgrund unterschiedlicher Ausgangsszenarien durchgeführt. Unternehmen, die Anwendungen selbst entwickeln, werden zwecks Qualitätssicherung in der Regel ein Vulnerability-Management implementiert haben. In diesem Rahmen werden dann zum einen regelmäßige Audits der vorhandenen Systeme durchgeführt und zum anderen vor der Einführung neuer Anwendungen oder Versionen diese entsprechend auf Schwachstellen untersucht.
Daneben haben viele größere Unternehmen auch ein regelmäßiges Vulnerability-Assessment zum Prüfen ihrer IT-Infrastruktur eingerichtet. Hier werden auch die Standard-Systeme, wie Server und Netzwerk-Komponenten, auf Schwachstellen geprüft.
Dabei sind Vulnerability-Scanner nur ein Tool von mehreren im Rahmen dieses Prozesses. Denn hier spielt auch das Patchmanagement eine Rolle und natürlich das regelmäßige Informieren der betreffenden Mitarbeiter und Entwickler über aktuelle Schwachstellen. Insgesamt betrachtet, laufen Vulnerability-Scans im Rahmen des Vulnerability-Managements häufig mit einer gewissen Routine und über Scan-Templates periodisch und weitgehend automatisiert ab.
Ein Penetrationstest ist gegenüber einem Vulnerability-Assessment oft zielgerichteter und hinsichtlich seiner Zielsetzung individueller. Oftmals geht ein Penetrationstest tiefer als ein Vulnerability-Assessment. Anders herum kann das Vulnerability-Assessment jedoch auch Bestandteil oder Grundlage eines Penetrationstests sein. Bevor wir uns jetzt aber in philosophischen Betrachtungen verlieren, kommen wir lieber noch einmal auf die Organisation eines Vulnerability-Assessments zurück.
Das Vulnerability-Assessment ist kein einzelner, abgeschlossener Schritt, sondern ein kontinuierlicher Prozess, der aus mehreren Prozessschritten besteht. Diese werden von Herstellern und Dienstleistern teilweise unterschiedlich bezeichnet und aufgegliedert, sinngemäß ist der Vorgang jedoch immer ähnlich. Abbildung 9.19 zeigt eine Darstellung der Prozessschritte im Rahmen des Vulnerability-Assessment-Lifecycles.
Zunächst wird eine Baseline erstellt, um den aktuellen Stand der IT-Infrastruktur, der eingesetzten Applikationen und Dienste und anderen Ressourcen zu erfassen. Das umfasst auch die getroffenen Sicherheitsmaßnahmen, Security Policys und Standards der Organisation. Die Baseline stellt die Grundlage dar und hilft bei der Planung des Vulnerability-Assessments.
Es folgt das eigentliche Vulnerability-Assessment, also die Schwachstellenanalyse. Neben dem Einsatz von Vulnerability-Scannern umfasst dieser Prozessschritt auch die Prüfung der Sicherheitsmechanismen, die physische Sicherheit und die Einhaltung und Umsetzung der Security Policys.
Der nun folgende Schritt des Risk-Assessments (zu Deutsch: Bedrohungsanalyse) analysiert die gefundenen Schwachstellen und bewertet sie im Kontext der IT-Infrastruktur und Tätigkeit des Unternehmens. Hier geht es also darum, die Schwachstellen zu gewichten und deren Behebung zu priorisieren. In einigen Fällen kann diese Analyse auch zu dem Schluss führen, dass das Risiko von der Geschäftsführung akzeptiert wird und die Schwachstelle bestehen bleibt, z.B. weil der Aufwand für eine Beseitigung als zu hoch bzw. die Eintrittswahrscheinlichkeit als zu niedrig eingeschätzt wird. Es kommt aber auch vor, dass gewisse Systeme aus Kompatibilitätsgründen nicht gepatcht werden können. In diesem Fall müssen dann alternative Vorkehrungen getroffen werden, wie z.B. das Ändern des Netzwerkdesigns. Das System kann durch zusätzliche Firewalls oder einen abgetrennten Netzbereich geschützt werden, um das Risiko, die Schwachstelle auszunutzen, zu minimieren.
In den meisten Fällen schließt sich jedoch die Beseitigung der Schwachstellen (engl. Remediation) an. Entsprechend der im Risk-Assessment festgestellten Priorisierungen werden die Schwachstellen durch Patchen, Konfigurationsanpassungen oder ähnliche, geeignete Maßnahmen behoben.
Ob eine Maßnahme effektiv war, müssen wir über eine erneute Prüfung der Schwachstelle (engl. Verification) feststellen. Dieser Schritt ist sehr wichtig, da es nicht selten vorkommt, dass sich die Verantwortlichen in falscher Sicherheit wiegen, da eine Schwachstelle vermeintlich beseitigt wurde.
Der letzte Schritt ist eigentlich ein permanenter Prozess. Wir meinen hier Monitoring, die laufende Überwachung des Netzwerks und der Traffic-Analyse. Damit können Sie die IT-Infrastruktur, also Systeme und das Netzwerk beobachten, um ungewöhnliches Verhalten bzw. ungewöhnlichen Traffic zu entdecken und die Bedrohungslage besser einzuschätzen.
9.5.2 Einsatz von Vulnerability-Scannern im Ethical Hacking
Ob ein Vulnerability-Scanner in der Scanning-Phase eines Penetration-Tests zum Einsatz kommt, hängt vom Szenario ab. In vielen Fällen hilft ein Vulnerability-Scanner dem Penetration-Tester dabei, schnell verwertbare Ergebnisse zu produzieren. Hier ist es jedoch wichtig, dass der genaue Zeitpunkt des Scans mit dem Auftraggeber abgestimmt wird, da sich ein umfassender Vulnerability-Scan auf die Stabilität und Performance des Produktivnetzwerks und seiner Systeme auswirken kann.
Da Vulnerability-Scanner ziemlich laut sind, wird sich ein echter Angreifer sehr gut überlegen müssen, was er wann und in welcher Form scannt. Hier kommt es insbesondere darauf an, zuvor möglichst viele Informationen über das Zielsystem bzw. -netzwerk zu sammeln. Denn je genauer der Angreifer das Ziel kennt, umso spezifischer kann er den Vulnerability-Scan konfigurieren, um gezielt zu suchen.
Machen wir uns klar: Jedes Plug-in oder ein anderes Test-Modul, das ausgeführt wird und fehlschlägt, erzeugt ggf. Aufmerksamkeit durch Einträge in Logfiles oder im Worst-Case sogar durch ausgefallene Dienste. Für moderne SIEM-Tools (SIEM = Security Information and Event Management) ist es ein Leichtes, aus den Logfile-Einträgen und sonstigen Events einen Angriffsversuch zu erkennen und entsprechend zu reagieren.
Mit einem möglichst zielgerichteten Scan wird die Wahrscheinlichkeit der Entdeckung reduziert, was für einen (echten) Angreifer essenziell ist. Aber auch im Rahmen des Ethical Hackings kann es – je nach Szenario und Auftrag – durchaus notwendig sein, möglichst unentdeckt zu bleiben.
Somit ist also der Einsatz eines Vulnerability-Scanners zwar ein vielversprechender Ansatz, automatisiert Schwachstellen zu finden. Allerdings muss ein Angreifer immer abwägen, ob der mögliche Nutzen nicht vom erzeugten Krach, den der Scanner produziert – und damit die Gefahr einer Entdeckung –, aufgewogen wird.
9.5.3 Credentialed Scan vs. Remote Scan
In der Grundform eines Vulnerability-Scans wird davon ausgegangen, dass der Angreifer keinerlei Kenntnis über das Zielsystem hat. Dies entspricht dem Szenario eines Scans von betriebsfremden Personen. Daher wird dieser Scan-Typ auch als »Remote Scan« bezeichnet. Der Angreifer verfügt über wenig oder keinerlei Insider-Wissen, das er nutzen könnte.
Es ist naheliegend, dass ein Scan, der auf Benutzer-Login-Daten (Credentials) zurückgreifen kann, um sich an bestimmten Diensten anzumelden, deutlich höhere Chancen hat, Schwachstellen zu finden. Dies wird als »Credentialed Scan« bezeichnet. Der Penetration-Tester definiert für verschiedene Dienste, wie z.B. SSH, Windows-Anmeldung oder Cloud-Dienste, passende Login-Daten, die der Scanner verwendet, um sich anzumelden. Dadurch geht ein Credentialed Scan naturgemäß weiter als ein Remote Scan. Er repräsentiert das Szenario eines internen Mitarbeiters, der das System angreift.
Je nach Zielstellung werden Remote oder Credentialed Scans eingesetzt. Wichtig ist, sich über die jeweilige Aussagekraft klar zu werden: Wenn der Penetration-Tester die Login-Daten des Domänen-Admins nutzen kann und somit Administrationsprivilegien auf einem Active-Directory-Domänencontroller erlangt, dann sind natürlich alle Türen und Tore zum Netzwerk offen. Das kann dann nicht als »Finding« erkannt und im Report verarbeitet werden. Andererseits ist es oft nützlich, zu sehen, wie weit ein regulärer Benutzer im Netzwerk kommen kann, wenn er nur mit seinen normalen Login-Daten arbeitet.
9.5.4 Verifizieren der Schwachstelle
Automatisierte Vulnerability-Scans haben viele Vorteile: Ohne große Recherche-Arbeit werden die Schwachstellen eines Systems übersichtlich in einem hübschen Report präsentiert. Dieser enthält in der Regel Links zu entsprechenden Quellen, die die Schwachstelle im Detail beschreiben. Dazu kommt, dass die meisten Scanner auch Vorschläge zur Beseitigung der Schwachstelle unterbreiten und somit die Arbeit des Penetration-Testers effektiv unterstützen.
Auf der anderen Seite sind derartige Scans auch fehleranfällig und produzieren False Positives, also führen Vulnerabilities auf, die im betreffenden Szenario nicht zutreffen. Außerdem gibt es diverse Schwachstellen, die nur unter ganz bestimmten Bedingungen ausgenutzt werden können und vielleicht im konkreten Fall gar nicht relevant sind.
Um dies herauszufinden, müssen die gefundenen Vulnerabilities verifiziert werden. Als Penetration-Tester prüfen Sie also, ob die jeweilige Schwachstelle im konkreten Szenario tatsächlich zu einem Problem wird, und bewerten sie im Kontext des Szenarios. So ist z.B. die Gefahr eines Remote-Angriffs auf einen bestimmten Dienst nur dann relevant, wenn dieser von außen erreichbar ist. Wurde der Dienst (z.B. ein Datenbank-Server) so konfiguriert, dass er nur von ganz bestimmten Systemen aus dem vertrauenswürdigen, internen Netzwerk angesprochen werden kann, aber nicht aus dem Internet, könnte sich die Fundstelle als nicht relevant herausstellen.
Andere Schwachstellen erfordern eine bestimmte, oft spezielle Konfiguration des Dienstes, um angreifbar zu sein. So sind z.B. bestimmte SSL/TLS-Angriffe, wie Poodle, nur dann möglich, wenn der Webserver für ein entsprechendes Fallback auf eine schwache bzw. veraltete SSL-Version konfiguriert ist.
9.5.5 Exploits zum Testen von Schwachstellen
So individuell, wie die Schwachstellen sind, so unterschiedlich ist auch das Vorgehen bei der Feststellung, ob eine Schwachstelle ausgenutzt werden kann oder nicht. Manchmal stellt es sich sehr simpel dar, z.B. wenn Default-Login-Daten verwendet werden. In diesem Fall ist sowohl die Prüfung als auch die Beseitigung der Schwachstelle keine große Angelegenheit.
In anderen Fällen bietet es sich jedoch an, die Schwachstelle konkret zu testen. Dies erfolgt in der Regel zunächst in einer möglichst identischen Testumgebung und nicht am produktiven System. Hierzu existieren oftmals sogenannte »Exploits«. Wie bereits eingangs in diesem Kapitel erwähnt, handelt es sich meistens um ein Stückchen Code in einer beliebigen Programmiersprache, der dazu genutzt werden kann, die Schwachstelle auszunutzen. Dabei geht es häufig darum, eine Shell auf dem Zielsystem zu erhalten, also z.B. die Bash auf Linux oder cmd.exe auf Windows-Systemen.
Das Ziel des Angreifers ist es also, Zugang zum Opfer-System (Victim) zu erhalten, um via Befehlszeile weitere Schritte zu unternehmen, um sich im Opfer-System festzusetzen. Oft umfasst dies die Installation einer »Backdoor«, um auch zu einem späteren Zeitpunkt erneut auf das System zu gelangen. Und nicht selten dient ein erstes System lediglich als Sprungbrett für den Zugang auf weitere Systeme im Netzwerk.
Doch so weit wollen wir an dieser Stelle noch nicht gehen. Wichtig ist, dass die im Internet verfügbaren Exploits häufig als Proof-of-Concept bereitgestellt werden, um die Schwachstelle in der Praxis zu verdeutlichen. Diese werden nicht nur von echten Angreifern, sondern auch von Penetrationstestern und Ethical Hackern eingesetzt. Hierbei ist allerdings Vorsicht anzuraten, da viele Exploits aus unsicheren Internet-Quellen auch Malware beinhalten und damit den Hacker zum Opfer machen.
Black Hats werden dagegen im Deep Web und Darknet fündig, wo Zero-Day- und andere Exploits zu noch unbekannten Schwachstellen verkauft werden. Diese haben natürlich eine höhere Aussicht auf einen erfolgreichen Angriff, da es schwierig ist, sich gegen etwas zu schützen, was man noch nicht kennt.
Unabhängig von der Intention des Hackers gibt es Frameworks, die die Arbeit mit Angriffscode erleichtern. Hier ist insbesondere Metasploit zu nennen, mit dem eine umfassende Exploit-Bibliothek inklusive einer ausgereiften Benutzerschnittstelle bereitgestellt wird. Einen ersten Exploit haben Sie ja bereits in diesem Kapitel in Abschnitt 9.2.2 kennengelernt. Wir werden jedoch im Laufe des Buches immer wieder auf Exploits zurückgreifen, die wir über Metasploit zum Einsatz bringen.
9.5.6 Spezialisierte Scanner
Neben den allgemeinen Vulnerability-Scannern existieren spezialisierte Scanner, die sich auf bestimmte Anwendungen oder Plattformen fokussieren. So ist Nikto2 z.B. ein sehr bekannter und beliebter Scanner für Webserver. Obwohl er seinen Zenit überschritten hat und einige Funktionen nicht mehr aktiv genutzt werden können – namentlich die Datenbankverweise auf die nicht mehr existierende Open Source Vulnerability Database (OSVDB) –, ist er noch immer beliebt und wird gern für das Testen von Webservern genutzt. Die letzte stabile Version stammt von 2012, daher ist sein Nutzen aus unserer Sicht beschränkt. Wir kommen in Kapitel 23 Web-Hacking – Grundlagen darauf zurück.
9.6 Zusammenfassung und Prüfungstipps
Werfen wir einen Blick zurück: Was haben Sie gelernt, wo stehen Sie und wie geht es weiter?
9.6.1 Zusammenfassung und Weiterführendes
In diesem Kapitel haben wir uns mit den Grundlagen des Vulnerability-Scannings beschäftigt. Dabei haben Sie verschiedene Tools und Ansätze kennengelernt und für einige dieser Tools im Rahmen eines Workshops auch praktische Einsatzbeispiele erfahren.
Neben Nmap mit diversen nützlichen NSE-Skripts existieren Vulnerability-Scanner, die genau zu diesem Zweck bereitgestellt werden. Sie offenbaren diverse Schwachstellen der Zielsysteme, wobei die Fundstellen jedoch manuell verifiziert werden müssen, um False Positives zu vermeiden.
Der Einsatz von Vulnerability-Scannern bietet sich nicht in jedem Szenario gleichermaßen an, da die Verwendung der Tools zum einen sehr leicht zu entdecken ist und zum anderen die Systemstabilität beeinträchtigen kann. In vielen Unternehmen werden die Scanner von internen Security-Mitarbeitern regelmäßig bzw. zu bestimmten Anlässen im Rahmen des Vulnerability-Managements eingesetzt. Hier spielen andere Überlegungen eine Rolle als beim (Ethical) Hacking, da die Scans offiziell angekündigt und abgestimmt werden können und damit nicht versteckt werden müssen.
Ein Angreifer wird sich dagegen immer überlegen müssen, inwieweit er Vulnerability-Scanner zum Auffinden von Schwachstellen nutzen möchte, da die Gefahr der Entdeckung groß ist. Je mehr Informationen der Angreifer über das Zielsystem in Erfahrung bringt, desto genauer und zielgerichteter kann der Scan durchgeführt werden. Dementsprechend verringert sich die Entdeckungsgefahr.
Im nächsten Schritt wird es Zeit, sich mit dem konkreten Angriff auf das System zu beschäftigen: Wir kennen die Schwachstellen und müssen diese nun ausnutzen. Dazu gibt es diverse Möglichkeiten, abhängig von der jeweiligen Schwachstelle. Eines der wichtigsten Werkzeuge hierzu ist das Metasploit-Framework. Dieses mächtige Werkzeug werden wir im Laufe des Buches immer wieder zum Einsatz bringen.
9.6.2 CEH-Prüfungstipps
Das CEHv12-Curriculum hat ein eigenes Modul »Vulnerability Analysis« eingeführt, um die Bedeutung dieses Prozesses zu unterstreichen. Dementsprechend ist hier auch zukünftig mit neuen Fragen zu rechnen. Stellen Sie sicher, dass Sie die CVE-Thematik beherrschen. Unter Umständen werden auch Fragen in Bezug auf Nmaps »Vuln«-Kategorie der NSE-Skripts auftauchen, da Nmap einer der ganz besonderen Lieblinge der Entwickler der CEH-Prüfung ist.
Es ist wichtig, die Prozessschritte des Vulnerability-Assessment-Lifecycles zu verstehen. Hier ist mit Fragen zu rechnen. Außerdem sollten Sie das Konzept und die Grundlagen der Funktionsweise von Vulnerability-Scannern verstanden haben.
9.6.3 Fragen zur CEH-Prüfungsvorbereitung
Mit den nachfolgenden Fragen können Sie Ihr Wissen überprüfen. Die Fragestellungen sind teilweise ähnlich zum CEH-Examen und können daher gut zur ergänzenden Vorbereitung auf das Examen genutzt werden. Die Lösungen zu den Fragen finden Sie in Anhang A.
Sie wurden von Ihrem Unternehmen beauftragt, ein technisches Security-Assessment eines Kundennetzwerks durchzuführen. Welche der folgenden Optionen ist der effektivste Weg, um Schwachstellen auf Windows-basierten Computer zu ermitteln?
Auf https://cve.mitre.org nach den neuesten CVE-Findings zu recherchieren.
Ein Scanning-Tool wie Nessus verwenden.
Windows-eigene Tools wie den Microsoft Baseline Security Analyzer (MBSA) verwenden.
Ein Disk Image einer frischen Windows-Installation erstellen und mit dem Zielsystem vergleichen.
Eine neu entdeckte, noch nicht behobene Sicherheitslücke ist welche Art von Vulnerability?
Input Validation Error
HTTP Header Injection Vulnerability
Zero-Day Vulnerability
SQLi Vulnerability
Welches der folgenden Programme ist nicht für das Vulnerability-Scanning geeignet?
Nexpose
Netstat
OpenVAS
Nessus
Nmap
Nina befindet sich in einem Vorstellungsgespräch als Security-Analystin. Herr Langschmidt, der anwesende Mitarbeiter der IT-Abteilung, fragt Nina nach dem Unterschied zwischen einem Vulnerability-Assessment und einem Penetrationstest. Welche Antwort beschreibt den Unterschied am besten?
Vulnerability-Assessment ist ein anderes Wort für Penetration-Test, inhaltlich gibt es keine Unterschiede.
Vulnerability-Assessments werden regelmäßig intern durchgeführt, Penetration-Tests dagegen nur einmalig. Für einen Penetration-Test wird immer ein externer Consultant beauftragt.
Vulnerability-Assessments nutzen automatisierte Tools wie Nessus oder OpenVAS, während Penetration-Tests manuell durchgeführt werden.
Vulnerability-Assessments sind standardisiert und teils automatisiert, während Penetration-Tests zielgerichteter und individueller ablaufen. Dabei geht ein Penetration-Test oft tiefer als ein Vulnerability-Assessment.
Was ist der erste Schritt im Vulnerability-Assessment-Prozess?
Erstellung einer Baseline
Durchführung eines Risk-Assessments
Durchführung einer Schwachstellenanalyse
Prüfung der Schwachstellen
Monitoring der laufenden Prozesse
Welche Aussage in Bezug auf Vulnerability-Scanner trifft zu?
Es sollte grundsätzlich nur ein Vulnerability-Scanner verwendet werden. Mehrere Produkte einzusetzen, verfälscht das Ergebnis.
Ergebnisse eines Vulnerability-Scanners müssen vom Security-Verantwortlichen nur überprüft werden, wenn die gefundene Schwachstelle für die IT-Umgebung der Organisation relevant ist.
Zu einem Penetration-Test gehören Vulnerability-Scanner obligatorisch dazu.
Vulnerability-Scanner werden nur im Rahmen von Vulnerability-Assessments eingesetzt. In Penetration-Tests werden die Schwachstellen durch den Penetration-Tester gesucht.
Sie diskutieren mit Ihrem Auftraggeber den Rahmen eines Penetration-Tests. Sie fragen ihn, ob er einen Remote Scan oder eher einen Credentialed Scan durchführen lassen möchte. Ihr Gegenüber fragt Sie, was er sich unter einem Credentialed Scan vorstellen muss. Welche der folgenden Antworten trifft auf den Credentialed Scan zu?
Ein Credentialed Scan wird immer in Ergänzung zu einem Remote Scan durchgeführt. Der Scan wird nach der Anmeldung eines Administrators am Scanner durchgeführt.
Es handelt sich um einen speziellen Scan-Typ. Bei einem Credentialed Scan geht es darum, möglichst viele Credentials, also Zugangsdaten und Form von Benutzernamen und Passwörtern zu ermitteln.
Bei einem Credentialed Scan werden nur Anwendungen geprüft, die eine Anmeldung verlangen. Andere Systeme werden nicht betrachtet.
Ein Credentialed Scan steht im Gegensatz zu einem Remote Scan und nutzt bereitgestellte Credentials, um einen Angreifer zu simulieren, der Zugriff auf interne Anmeldedaten hat.
![[Bild]](../Images/Kap09_cve.jpg)
![[Bild]](../Images/Kap09_cve-details.jpg)
![[Bild]](../Images/Kap09_cve-nist.jpg)
![[Bild]](../Images/Kap09_exploit-db.jpg)
![[Bild]](../Images/Kap09_vulns.jpg)
![[Bild]](../Images/Kap09_nse.jpg)
![[Bild]](../Images/Kap09_exploit.jpg)
![[Bild]](../Images/Kap09_nessus.jpg)
![[Bild]](../Images/Kap09_nessus_start.jpg)
![[Bild]](../Images/Kap09_scan-templates.jpg)
![[Bild]](../Images/Kap09_Basic_Network_Scan.jpg)
![[Bild]](../Images/Kap09_Scan_starten.jpg)
![[Bild]](../Images/Kap09_Scan_Progress.jpg)
![[Bild]](../Images/Kap09_vulnerabilities.jpg)
![[Bild]](../Images/Kap09_export_nessus.jpg)
![[Bild]](../Images/Kap09_export2.jpg)
![[Bild]](../Images/Kap09_report_nessus.jpg)
![[Bild]](../Images/Kap09_nexpose.jpg)
![[Bild]](../Images/Kap09_va-lifecycle.jpg)