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.
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.
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.
Die dreiste Abzocke bei Firmengründungen nimmt zu. Im Jahr 2013 hatten wir bei der Gründung der binsec eine Zahlungsaufforderung erhalten, die uns zur Zahlung für die Eintragung in ein Register motivieren sollte. Bei der Gründung der binsec group GmbH im Oktober 2019 wurden wir vom Notar schon darauf hingewiesen, dass wir „falsche Rechnungen“ für Eintragungen in das Registergericht bekommen würden. Ich dachte da.. jaja, kennen wir schon…
Am 15. November kam vom Amtsgericht Frankfurt die korrekt „Kostenanforderung“ für die Eintragung einer GmbH i.H.v. 150€. Am 29. November wurde die Gesellschaft im Amtsgericht Frankfurt eingetragen und die Eintragung wurde veröffentlicht. Der 29. November war ein Freitag. Am Dienstag waren dann gleich mehrere dreiste Zahlungsaufforderungen im Briefkasten:
Frechheit. Die Handels Union Deutschland hätte es gerne gleich im jährlichen Abo und die DZHR GmbH möchte fast 1.000€. Vermutlich existieren die Firmen noch nicht einmal:
In Deutschland ist nur eine HGR GmbH eingetragen und diese sitzt in Düsseldorf. Die Rechnung kommt aber laut Schreiben aus Berlin und die IBAN stammt aus Belgien.
Das Deutsche Register für Handel hat erst gar keine Rechtsforum, gibt aber ein Konto bei der Postbank an.
Die DZHR GmbH hat zwar eine Rechtsform, aber keine Anschrift. Dafür auch ein Konto bei der Postbank. Auf der Internet-Seite dzhr.info steht „nur Wartungsarbeiten“. Vor der DSGVO hätte man wenigsten den Whois-Eintrag zur Domain ziehen können.
Eine HRZ GmbH kennt das deutsche Registerportal auch gar nicht erst. Zur Abwechslung wird ein Konto von der Sparkasse Rhein-Maas benutzt. Auf der Internet-Seite hrz-online.de steht vielsagend: „Diese Seite befindet sich derzeit im Aufbau.“
Die Handels Union Deutschland gibt sogar eine Firma an, die Boncheck GmbH. Das Konto liegt bei der Sparkasse Herford. Es gibt tatsächlich einen Internetauftritt unter www.handels-union.de. Dort im Impressum steht auch eine Boncheck GmbH als verantwortlich, vertreten durch ihren Geschäftsführer Herr Tolga Akcay. Und.. relativ ungewöhnlich.. im Impressum steht auch gleich die zuständige Anwaltskanzlei „Kanzlei Senol, Herr Rechtsanwalt Ali Senol, Friedrichstraße 24, 33615 Bielefeld“.
Folglich sind die ersten vier Schreiben komplett Fake, dafür erhält man beim letzten Schreiben sogar eine Leistung. Und wenn man die Leistung der „Handels Union Deutschland“ bzw. Boncheck GmbH annimmt, weil man sie vielleicht mit dem offiziellen Register verwechselt, bekommt man auch gleich die Anwaltskanzlei mitgeteilt, die von der Boncheck GmbH vertreten wird. Das ist Service.
Ab sofort erhalten Studenten 20% Preisnachlass auf alle Online-Schulungen der binsec academy GmbH: Einfach unter https://binsec-academy.com/de/promo/student/ (unverbindlich) mit der studentischen E-Mail-Adresse der Hochschule registrieren und automatisch einen 20%-Gutschein erhalten. Der Gutschein ist nach der Registrierung 30 Tage gültig.
