Author: Patrick Sauer

Penetrationstest Anbieter: Das Unternehmen binsec GmbH als Ihr Dienstleister für Pentests aus Frankfurt am Main

Leave a Comment

Die binsec GmbH ist ein von mir im Jahr 2013 mitgegründetes Beratungsunternehmen für Informationssicherheit aus Frankfurt am Main. Ich bin seit der Gründung der Geschäftsführer der binsec GmbH. Wir führen als Dienstleister Penetrationstests durch und beraten unsere Kunden auch in den Bereichen Sicherheitsmanagement und IT-Sicherheit.

Die binsec GmbH liegt über die binsec group GmbH vollständig in der Hand der drei Gesellschafter: Patrick Sauer, Florian Zavatzki und Dominik Sauer. Wir sind an der langfristigen Zufriedenheit unserer Kunden und Mitarbeiter interessiert: Kurzfristige Umsatz- und Gewinnmaximierung ist nicht unser Ziel.

Mein Team besteht aus erfahrenen, zertifizierten Spezialisten. Unser Fokus ist immer die Sicherheit der geschäftskritischen IT-Systeme und Informationen. Auch wenn wir Penetrationstests durchführen, behalten wir die Business-Aspekte im Blick.

Als Anbieter für Penetrationstests und Sicherheitsberatung sind wir in den letzten Jahren zur Top-Adresse als Pentest Dienstleister gerade im Großraum Frankfurt am Main geworden.

Mehr Information über unser Unternehmen und Dienstleistungen als Anbieter für Pentesting gibt es auf https://www.binsec.com.

Penetrationstests beim MPA Content Security Program

Leave a Comment

Das Content Security Program der Motion Picture Association (MPA) legt in ihren Content Security Best Practices Common Guidelines (Version 4.10 vom 8. Februar 2022) Sicherheitsanforderungen in drei Bereichen fest:

  • Management System
  • Physical Security
  • Digital Security

In den Anforderungen an das Management System wird in der Nummer MS-2.1 in der Kategorie Risk Management die Durchführung von Schwachstellen-Scans und externen Penetrationstests durchgeführt. Hierbei wird auf die Anfordeurngen DS-1.8 und DS-1.9 verwiesen.

In der Anforderung DS-1.9 (Firewall / WAN / Perimeter Security) wird die Durchführung jährlicher Penetrationstests aller externen IP-Adressen und Systemen verlangt. Die DS-1.8 verlangt zusätzlich die monatliche Durchführung von Schwachstellen-Scans.

Weiterhin findet man zusätzlich die Anforderung zur Durchführung von Webanwendungs-Penetrationstests (DS-15.9, Client Portal). Hier werden etwas detailreichere Anforderungen gestellt:

  • Der Pentest soll auch eventuelle APIs beinhalten.
  • Der Test soll sowohl mit als auch ohne valide Zugangsdaten durchgeführt werden.
  • Die typischen Guidlines wie z.B. die Veröffentlichungen von OWASP sollen beachtet werden, sodass auch XSS, SQL Injections, und CSRF gefunden werden kann.

Es wird dabei allgemein empfohlen, dass die Penetrationstests von einer unabhängigen dritten Stelle durchgeführt werden.

i-Kfz: Anforderungen an Penetrationstests vom Kraftfahrt-Bundesamt (KBA)

Leave a Comment

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:

  • IS-Kurzrevision (wenn keine ISO 27001/IT-Grundschutz-Zertifizierung vorhanden)
  • IS-Webcheck
  • IS-Penetrationstest

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.

Vergleich von PCI DSS 3.2.1 und 4.0: Anforderungen für Penetrationstests

Leave a Comment

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:

  • basierend auf branchenweit akzeptierten Penetrationstestansätzen
  • Abdeckung des gesamten CDE-Perimeters und kritischer Systeme
  • Tests von innerhalb und außerhalb des Netzwerks
  • Validierung jeglicher Segmentierungs- und Scope-reduzierenden Kontrollen
  • Testen der Netzwerkschicht und der Anwendungsschicht
  • einschließlich Überprüfung und Berücksichtigung von Bedrohungen und Schwachstellen, die in den letzten 12 Monaten aufgetreten sind
  • alle 12 Monate und nach jeder wesentlichen Änderung muss der externe und der interne Pentest durchgeführt werden, sowie der Segmentierungstest
  • Service Provider müssen alle 6 Monate einen Segmentierungstest durchführen

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:

  • PCI v3.2.1 inkludiert Requirement 6.5 für Anwendungstests um folgende Punkte zu prüfen:
    • injection flaws (e.g. SQL, LDAP, OS Commant, XPath)
    • buffer overflows
    • insecure crypto storage, insecure communications
    • improper error handling
    • XSS
    • improper access controls
    • CSRF
    • broken authentication and session management
    • sowie aktuellere Best Practices (e.g. OWASP Top 10)
  • PCI v4.0: inkludiert Requirement 6.2.4, sodass für Anwendungstests mindestens folgendes durchgeführt wird
    • injection attacks (including SQL, LDAP, XPath, command parameters, object fault or injectiontype flaws)
    • attacks on data and data structures (for example manipulating buffers, input data)
    • attacks on cryptography usage
    • attacks on business logic including XSS and CSRF
    • attacks on access control mechanisms

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.

Warum Penetrationstests bei ISO27001-Zertifizierungen?

Leave a Comment

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.

Anforderungen an DiGa-App-Pentests – Penetrationstest für digitale Gesundheitsanwendungen im Fast-Track-Verfahren

Leave a Comment

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.
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.

https://www.bfarm.de/SharedDocs/Downloads/DE/Medizinprodukte/diga_leitfaden.pdf
(Stand: 18.03.2022)

Im Prinzip kann man die Anforderungen an einen DiGa-Pentest somit wie folgt zusammen fassen:

  • Durchführungskonzept für Penetrationstests des BSI
  • OWASP Top-10
  • für alle Komponenten
  • anforderungsbezogen zu wiederholen (z. B. neue Schnittstellen)

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.

DDoS Erpresser-E-Mail: black shadow group

Leave a Comment

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!
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.

Mail black-shadow@protonmail.com

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.

Umstrukturierung der binsec-Gruppe

Leave a Comment

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.

security.sauer.ninja wird international

Leave a Comment

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.