Die binsec startet ihr binsec wiki. Unterteilt in die Kategorien „Hack & Attack“ sowie „Defend“ werden in englischer Sprache Artikel, How-Tos und Best Practices zu technischen IT-Sicherheitsthemen veröffentlicht. Als erster Wiki-Artikel wurde veröffentlicht: OpenVPN: configure 2FA
Die „Mindestsicherheitsanforderungen an dezentrale Portale und Zulassungsbehörden“ zur „internetbasierten Fahrzeugzulassung (i-Kfz)“ vom Kraftfahrt-Bundesamt (KBA) sind außerordentlich umfangreich. Sie beinhalten neben der Architektur des i-Kfz-Systems, seiner Schnittstellen und daraus abgeleiteten Sicherheitsanfordeurngen unter anderem auch Anforderungen an die Durchführung eines Penetrationstests.
Zur Prüfung der Wirksamkeit der implementierten Sicherheitsmaßnahmen verlangt das KBA als Penetrationstest die Durchführung von:
Alle o.g. Tests sind dabei als White-Box-Test durchzuführen und es darf nur fachlich qualifiziertes und unabhängiges Personal eingestetzt werden.
Als IS-Wecheck ist dabei ein nicht invasiver Schwachstellenscan (definierte Prüftiefe) mit manueller Validierung der Schwachstellen vorgesehen. Hierbei soll auf die OWASP Top 10 geprüft werden sowie die entsprechenden Module vom IS-Webcheck durchgeführt werden: „Modul 1 – Schwachstellensuche“, „Modul 2 – Schwachstellentest“, „Modul 3 – Logische Fehler/Konfigurationsfeher“ sowie „Modul 4 – Exploits (optional)“. Der Test ist dabei über das Internet durchzuführen und die Filterung eines vorgeschalteten Sicherheitsgateways ist dabei zu deaktivieren.
Im IS-Penetrationstest wird primär die technische Angriffsoberfläche einer Institution nach außen hin untersucht. Als Prüftiefe ist hier ein technischer Sicherheitsaudit in Kombination mit einem nicht-invasiven Schwachstellen-Scan definiert. Im Scope sind dabei mindestens alle Netzwerkelemente, Sicherheitsgateways, Server, Webanwendungen, relevante Clients und Infrastruktureinrichtungen zu prüfen, sofern technisch möglich und sinnvoll. Dabei sind folgende Module durchzuführen: „Modul 1 – konzeptionelle Schwächen“, „Modul 2 – Umsetzung Härtungsmaßnahme“, „Modul 3 – Bekannte Schwachstelle“ und „Modul 4 – Exploits (optional)“.
Hierbei ist zu erwähnen, dass die geforderte Prüftiefe erfahrungsgemäß eher als nicht-invasiver Penetrationstest ausgelegt werden sollte. Der Einsatz eines typischen automatisierten Schwachstellen-Scanners ist zur Analyse der gestellten Anforderungen technisch nicht ausreichend.
Die aktuelle Version 3.2.1 und die neuere Version 4.0 des Sicherheitsstandards PCI DSS erfordern die Durchführung von Penetrationstests. Der PCI-Standard legt detaillierte Anforderungen fest, die ein Penetrationstest erfüllen muss. In PCI DSS 3.2.1 ist die Anforderung in Anforderung 11.3 und in PCI DSS 4.0 in Anforderung 11.4 geregelt.
Diese Anforderungen sind in beiden Versionen 3.2.1 und 4.0 grundsätzlich identisch:
Es gibt zwei Bereiche, bei die beiden Standard-Versionen auseinander gehen, während PCI 4.0 die ausgereiftere Version darstellt. So hat PCI 4.0 einen etwas anderen Ansatz für seine Anforderungen an den Penetrationstest der Anwendungsschicht:
In PCI 4.0 muss der Segmentierungstest auch die Bestätigung der Wirksamkeit jeglicher Verwendung von Isolationstechniken für verschiedene Sicherheitsstufen umfassen (siehe Anforderung 2.2.3).
Natürlich muss der angewendete Penetrationstestansatz das Beheben und erneute Testen aller relevanten Schwachstellen umfassen, die zuvor identifiziert wurden – unabhängig von der Version des PCI-Standards.
Im Rahmen der ISO 27001-Zertifizierung wollen Auditoren immer regelmäßiger den Bericht eines Penetrationstests sehen. Aber woher kommt diese Anforderung, wenn im Text der ISO 27001 das Wort Pentest oder Penetrationstest gar nicht vorkommt?
Die ISO 27001 ist die internationale Norm für den Aufbau und Betrieb eines ISMS (Informationssicherheits-Managementsystem). Im Anhang A enthält dieser Standard Kontrollziele bzw abstraktere Maßnahmen zur Umsetzung. Eine konkretere Erläuterung der einzelnen Punkte findet man in der Norm ISO 27002, diese entspricht in ihrem strukturellen Dokumentenaufbau den Kontrollzielen vom Anhang A der ISO 27001.
Im Anhang A der ISO 27001 findet man nun in Abschnitt A.18.2 die Anforderung „Information security reviews“ durchzuführen. In der ISO27002-Implementierungsrichtlinie für diese Maßnahme findet man nun die Durchführung von Schwachstellen-Scans und/oder Penetrationstest als Möglichkeit, dieser Anforderung gerecht zu werden.
Um in das Verzeichnis erstattungsfähiger digitaler Gesundheitsanwendungen (DiGa) aufgenommen zu werden, muss das Fast-Track-Verfahren beim BfArM durchlaufen werden. Mit dem Digitale–Versorgung–und–Pflege–Modernisierungs–Gesetz (DVPMG) kam in den entsprechenden Leitfaden die Anforderung hinein, dass Antragsteller einen Penetrationstest für ihre DiGa-Anwendung durchführen lassen müssen.
Im DiGa-Leitfaden selbst findet man die konkreten Anforderungen an den eigentlichen Penetrationstest:
Penetrationstests: Mit dem DVPMG wurde diese Anforderung für alle DiGA in die DiGAV aufgenommen. Die Sicherheit der Daten über den gesamten Anwendungsprozess und alle erdenklichen Nutzungsszenarien hinweg sicherzustellen, ist essentielle Anforderung an DiGA.
https://www.bfarm.de/SharedDocs/Downloads/DE/Medizinprodukte/diga_leitfaden.pdf
Penetrationstests ermöglichen die Nachbildung möglicher Angriffsmuster und können so dazu beitragen, Sicherheitslücken aufzudecken. Für die Produktversion, für die eine Aufnahme in das DiGA-Verzeichnis beantragt wird, muss für alle Komponenten ein Penetrationstest durchgeführt worden sein. Diese Tests sind anforderungsbezogen zu wiederholen, z. B. wenn neue Schnittstellen in das Internet hinzukommen. Als Basis für die Testkonzeption sind das Durchführungskonzept für Penetrationstests des BSI sowie die jeweils aktuellen OWASP Top-10 Sicherheitsrisiken heranzuziehen. Dem BfArM muss auf Verlangen ein Nachweis über die Durchführung der entsprechenden Tests vorgelegt werden.
(Stand: 18.03.2022)
Im Prinzip kann man die Anforderungen an einen DiGa-Pentest somit wie folgt zusammen fassen:
Jetzt hatte ich bereits mehrere Diskussionen mit Herstellern von DiGA-Apps, dass diese nur die eigentliche Mobile App (also in der Regel die iOS und die Android-Version) prüfen lassen wollen. Nicht im Scope enthalten soll jedoch eine dahinterliegende API sein, über die teilweise Business-Funktionalität realisiert wird, die Nutzer-Authentifizierung abwickelt und als zentraler Speicherort für Gesundheitsdaten dienen soll.
Klar, eine „App“ und eine „API“ sind zwei unterschiedliche Dinge und die Verordnung spricht von digitalen Gesundheitsanwendungen (ergo Apps). Allerdings führt diese Auslegung der Verordnung nicht ans Ziel und ist einfach falsch. Der Penetrationstest soll „die Sicherheit der Daten über den gesamten Anwendungsprozess“ hinweg sicherstellen und der Penetrationstest muss für „alle Komponenten“ durchgeführt werden. Das heißt natürlich, dass auch Backend-Systeme und APIs im Hintergrund im Scope des Penetrationstest sind und nicht nur die eigentliche Mobile App aus dem Android- oder Apple-Store.
Es kann sehr fesselnd sein, in der Rolle eines Angreifers in fremde IT-Systeme einzudringen. Als Penetrationstester sollte dabei jedoch nie das eigentliche Ziel aus den Augen verloren werden: die Identifikation aller Einstiegspunkte bzw. Sicherheitslücken in einem Zielsystem. Die Liste von Schwachstellen kann sehr lang und unübersichtlich werden. Um einem Auftraggeber aber mitzuteilen, welche Schwachstellen zuerst adressiert bzw. behoben werden sollten, müssen die ermittelten Schwachstellen nach ihrem Risiko geordnet werden.
Grundsätzlich kann das Risiko einer Schwachstelle über zwei verschiedene Arten dargestellt werden. So kann entweder ein konkreter Zahlenwert ermittelt (bspw. 1.034,99 Euro) werden oder eine Aussage über die Schwere des Risikos getroffen (wie gering, mittel, hoch) werden. Der konkrete Zahlenwert ist das Ergebnis einer quantitativen Risikoanalyse. Diese eignet sich beispielsweise zur Bestimmung des Risikos eines Festplattenausfalls, da Festplatten einen konkreten Preis und eine durchschnittliche Lebensdauer haben. Im Gegensatz dazu liegen einem Pentester bei Schwachstellen von IT-Systemen normalerweise nicht genug Informationen dieser Art vor, sodass diese Form der Risikoanalyse nicht empfehlenswert ist. Stattdessen kann aber eine qualitative Risikoanalyse vorgenommen werden, da immer Aussagen über die Eintrittswahrscheinlichkeit und das mögliche Schadensausmaß einer Schwachstelle getroffen und somit die Schwere des Risikos abgeschätzt werden kann. Wie bei einer Schätzung üblich, werden verschiedene Pentester zu unterschiedlichen Risikobewertungen gelangen, da ihre Wahrnehmung und Erfahrungen uneinheitlich sind – selbst, wenn sie sich auf dasselbe Bewertungsschema beziehen.
Jedoch benötigen gerade regulatorische Stellen wie das Regierungspräsidium Darmstadt ein einheitliches System, da sie konkrete Anforderungen und Maßnahmen definieren müssen. Infolgedessen fordern sie von Pentestern eine Risikobewertung nach dem Common Vulnerability Scoring System (CVSS) durchzuführen. Bei diesem handelt es sich um ein metrisches Bewertungsschema, welches einer Schwachstelle eine Punktzahl bzw. einen Score zwischen 0 und 10 zuweist – je höher der Score desto gravierender ist das Risiko einer Schwachstelle. Auch wenn das Risiko einer Schwachstelle beim CVSS anhand einer Vielzahl von Parametern berechnet wird (s. https://www.first.org/cvss/calculator/3.1), liegen Kenngrößen wie die Auswirkung einer erfolgreich ausgenutzten Schwachstelle auf die Integrität im Ermessen der Pentester. Somit können Risikoangaben wie der CVSS Score einem Auftraggeber zwar als Richtwert dienen, jedoch sollte intern immer eine eigene Schwachstellenbewertung vorgenommen werden.
Aktuell bei einem Kunden reingekommen, eine Erpresser-E-Mail der black shadow group:
FORWARD THIS MAIL TO WHOEVER IS IMPORTANT IN YOUR COMPANY AND CAN MAKE DECISION!
Mail black-shadow@protonmail.com
We are the BLACK SHADOW hacker group.
Your network will be DDoS-ed starting 12:00 UTC+1 on 08 May 2021 if you don’t pay protection fee – 10 Bitcoins @ 1FfmbHfnpbZjKFvyi1okTjJJusN455paPH
If you don’t pay by 12:00 UTC on 08 May 2021, attack will start, your service will go down permanently. Price to stop will increase up 5 BTC for every day of attack.
This is not a joke. We are the BLACK SHADOW liberty hackers.
Our attacks are extremely powerful – sometimes over 1,3 Tbps per second. And we pass CloudFlare, Link11 and others DDoS protections! So, neither cheap or expensive protection will help.
Try to reply, we will not read. Pay and we will know its you.
Tatsächlich kamen ca 200GBits auf dem Uplink herein. Hauptsächlich UDP-Traffic. Wir mussten die angegriffenen IP-Adressen aus dem Netzwerk blackhoolen und haben neue IPs auf die Services gelegt. In einer Stunde war alles wieder online, als der Traffic im DeCIX von deren Routern aufgrund der Null-Route weggeworfen wurde. Glücklicherweise hat der Angreifer da nicht auf unsere Ausweich-Technik reagiert.
Der vor Kurzem durchgeführte Hackerangriff auf die Uni Gießen hat vielen Menschen vor Augen geführt, dass die Bedrohung durch Angreifer aus dem Internet stetig zunimmt. Um aus solchen Sicherheitsvorfällen lernen zu können, benötigt es IT-Forensiker, die den 7 W-Fragen der Kriminalistik nachgehen: Wer (Täter), was (Straftat), wann (Tatzeitpunkt), wo (Tatort), wie (Tathergang) womit (Werkzeuge) und warum (Motiv). So versuchen sie über die vom Angreifer hinterlassenen digitalen Spuren den Sicherheitsvorfall zu rekonstruieren und den Täter – im Idealfall – zu überführen.
Über Hochschulkontakte bot sich mir im Wintersemester 19/20 die Gelegenheit das Modul „Digitale Forensik“ im Masterstudiengang der Wirtschaftsinformatik an der Technischen Hochschule Mittelhessen (THM) anzubieten. Mit der Sichtweise eines Angreifers auf IT-Systeme, beschäftigte es mich als Pentester ohnehin, welche Spuren bei einem Angriff hinterlassen werden und wie diese verschleiert werden können. Dahingehend standen für mich folgende Themen auf der Agenda:
Getreu dem Zitat von Sunzi – „Du musst deinen Feind kennen, um ihn besiegen zu können“ -, wechselte ich je nach Vorlesungseinheit die Perspektive zwischen den beiden Kontrahenten und ließ die besprochenen Inhalte im nachstehenden Szenario von den Studierenden anwenden:
Die Dubius Payment Ltd. ist ein vor Kurzem gegründeter Zahlungsdienstleister, welches Kreditkarteninformationen in seinen Systemen speichert, verarbeitet und weiterleitet. Seit dem 14. November 2019 gegen 16:45 Uhr (Donnerstag) verzeichnet das Produktionssystem Ausfälle und ihr Intrusion Detection System meldet in regelmäßigen Abständen einen ungewöhnlich hohen Netzwerkverkehr über ihr Payment Gateway. Aus Angst vor einem Hackerangriff haben sie den Studierenden als IT-Forensiker beauftragt, den Fall zu analysieren.
In ihrer praktischen Arbeit stellten die Studierenden über das Sammeln und der Analyse von digitalen Spuren auf dem Livesystem fest, dass ein Mitarbeiter des Unternehmens in regelmäßigen Zeitabständen Kreditkartendaten aus der Datenbank abzieht. Wie in der Realität üblich, blieb es nicht bei dieser Schlussfolgerung, sondern die Studierenden mussten nun über eine anschließende Datenträgeranalyse des Arbeitscomputers vom Tatverdächtigen die Zweifelsfrage klären, ob der Nutzer das Opfer eines Hackerangriffs geworden ist oder tatsächlich die Schuld am Datendiebstahl trägt. Ihre Ergebnisse hielten sie in Form eines Gutachtens fest.
Natürlich lief im ersten Durchlauf nicht alles reibungslos. So hatte ich beispielsweise mit dem Aufbau meines geplanten Labors zu kämpfen: Damit die Studierenden lernen ihr eigenes Toolkit auf einem kompromittierten System zu verwenden, sollte das Linuxprogramm „/usr/bin/ls“ mit folgendem „Schadcode“ auf dem Livesystem ersetzt werden:
#include <iostream>
#include <cstdlib>
using namespace std;
int main() {
cout << "I've got ya! ;)" << endl;
system("sleep 1");
system("sudo reboot");
return 0;
}
Da “ls” jedoch auch von Init-Skripten aufgerufen wird, führte die Schadsoftware im Falle eines Neustarts zu einer Endlosschleife. Die Verwendung eines Aliases in Linux lieferte hier Abhilfe. Umso erfreulicher ist die positive Resonanz der Studierenden, welche sich in den Anmerkungen der Lehrveranstaltungsevaluation abzeichnet (s. Evaluationsergebnis).
“Es ist das spannendste Modul im gesamten Wirtschaftinformatik Studium, es fesselt und macht viel Spaß anzuwenden/zu lernen“
Student/in
So hat beispielsweise der vorige Kommentar mit dazu beigetragen, dass ich mir als Ziel genommen habe, einen neuen Online-Kurs für die binsec academy zu entwerfen: Das “Digital Forensics Training”, welches zukünftig Teilnehmer als Binsec Academy Certified Digital Forensic Professional (BACDFP) zertifizieren soll.
Die binsec hat sich umstrukturiert: Der von den drei Gesellschaftern Patrick Sauer, Florian Zavatzki und Dominik Sauer Ende 2019 gegründete binsec group GmbH gehört seit Januar 2020 nun offiziell die binsec GmbH sowie die binsec academy GmbH.
Unser deutsche Blog security.sauer.ninja wird international: Durch den großen Erfolg des Blogs im deutschsprachigen Raum haben wir uns dazu entschieden, Blogeinträge zukünftig auch in einer englischen Variante zur Verfügung zu stellen. Zudem werden wir einige ältere, ausgewählte Einträge in die englische Sprache übersetzen.
