Hier bin ich, Mensch, hier schreib ich’s rein: KI textet täuschend echt

Dieser Digest wurde für Sie wie immer von David Fuhr und diesmal auch Robert Waniek geschrieben. Sicher? Sind wir uns selbst ganz sicher? Die künstliche Intelligenz (KI) hat beim Verfassen von Texten jüngst die Schwelle überschritten, vor der sie durch uns Menschen leicht als Maschine zu erkennen war. Das maschinell an Millionen von Texten trainierte Modell GPT-3 des von Tesla-Gründer Elon Musk und Microsoft finanzierten Unternehmens Open AI kann Texte unterschiedlicher Art produzieren, welche oft auf den ersten und zweiten Blick nicht von denen menschlicher Autoren zu unterscheiden sind. 
Neben einer riesigen Menge nützlicher bis lustig-alberner oder auch sinnloser Anwendungsszenarien fallen in Security-Denke geschulten Zeitgenossen sofort mögliche Missbrauchsszenarien ein. Wie viel besser kann hiermit das Schreiben täuschend echter Phishing-Mails skaliert werden? Wie viel vertrauenswürdiger können nigerianische Prinzen wirken, wenn sie jede/n Autor/-in und jeden Stil perfekt imitieren können? Und wie sehr können wir der Wahrheit noch trauen, wenn jeder sie auf Knopfdruck mit einem Meer von Fiktion überschwemmen kann?
Noch ist die KI mit ihren eigenen Mitteln leicht zu schlagen, und die Fälschungen sind technisch gut zu erkennen, wenn man denn weiß wie und den Aufwand betreibt. Aber diese Kinderkrankheiten werden im üblichen Katz- und Maus-Spiel bald immer weiter ausgemerzt. Wir tun gut daran, uns bei Texten schon heute langsam einen wachsenden Skeptizismus anzutrainieren, wie wir dies auch mit Bildern lernen mussten und zukünftig verstärkt alternative Herkunfts- und Wahrheitsbeweise einzufordern, wie wir es etwa in der Kryptografie tun.

https://www.spiegel.de/netzwelt/web/gpt-3-die-eloquenteste-kuenstliche-intelligenz-der-welt-a-dd3b3423-d214-4a2f-bc51-d51a2ae22074

OAuth-Phishing

Im Rahmen von COVID-19 wurden viele neue Phishing-Kampagnen verzeichnet – darunter auch sogenannte OAuth-Phishing-Angriffe gegen Office 365. Hierbei werden Phishing-Mails an Benutzer gesendet, die, wenn sie auf den in der Mail enthaltenen Link klicken, gefragt werden, ob sie Berechtigungen an eine App übergeben wollen. Mit der Bestätigung autorisiert der Benutzer dann die App für den Zugriff auf seine Daten. Der Ablauf des OAuth-Phishings ist in der untenstehenden Abbildung dargestellt.

Ablauf OAuth-Phishing

Doch die Vorgehensweise ist nicht neu. Bereits 2017 kam es zu einer großen Phishing-Welle, die Google Docs-Benutzer dazu einlud, ein geteiltes Dokument aufzurufen. Für diese Angriffe mittels OAuth-Apps werden die Funktionalitäten des OAuth-Protokolls genutzt. Mit OAuth kann ein Benutzer einer Anwendung den Zugriff auf seine Daten erlauben, die von einem anderen Dienst bereitgestellt werden. Der Zugriff der Anwendung erfolgt dabei ohne Benutzerkennung und Passwort. Somit können auch eine Passwortänderung oder die Einführung einer Multifaktorauthentifizierung die Vergabe der Berechtigungen nicht mehr rückgängig machen.

Es wird hier also keine Schwachstelle im OAuth-Protokoll ausgenutzt. Stattdessen wird der Benutzer dazu gebracht, Berechtigungen zu übergeben, ohne dass ihm dies bewusst ist. Hierzu werden Links mit zu Office 365 oder Google G Suite ähnlich klingenden Domainnamen verwendet, und auch die App-Namen werden so gewählt, dass ein unbedarfter Benutzer diese mit dem jeweiligen Cloud-Dienst assoziiert.

Ein OAuth-Phishing-Angriff ist im Nachhinein schwer erkennbar, da kein schadhafter Code ausgeführt wird. Stattdessen können Daten gelesen und je nach Berechtigung auch geändert oder gelöscht werden. So kann ein Angriff unbemerkt bleiben oder wird erst dann bemerkt, wenn in einer weiteren Angriffsphase Daten verschlüsselt wurden oder ein CEO-Fraud begangen wurde.

Damit es erst gar nicht zu einem Zugriff mittels OAuth-Phishing kommt, sind folgende Maßnahmen zu empfehlen:

  1. Schulung der Mitarbeiter, um OAuth-Phishing-Angriffe zu erkennen
  2. Drittanbieter-Apps nur mittels Whitelisting zulassen oder die Nutzung ganz untersagen
  3. In Office 365 können Drittanbieter-Apps mittels der CASB-Lösung von Microsoft (Cloud App Security) überwacht werden. Dieses Feature steht jedoch nur in der E5-Lizenz zur Verfügung.

Falls man vermutet, dass man mittels einer OAuth-App kompromittiert wurde, dann kann man dies in Office 365 über das von Microsoft für Office 365 veröffentlichte Vorgehen[1] nachvollziehen und die Berechtigungen der jeweiligen App deaktivieren. Grundsätzlich sollte die verdächtige App deaktiviert werden und es sollten die Berechtigungen entzogen werden. Anschließend sollten die Zugriffsprotokolle überprüft werden, um den Umfang der Kompromittierung zu verstehen.


[1] https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants

Malen ohne war einmal: Malware für Macs

Es hat sich über die letzten Jahre langsam herumgesprochen: Auch für Apples macOS gibt es Schadsoftware. So kommt es nicht unerwartet, dass sich auch bei Mac-Malware steigende Softwarequalität durchsetzt. Ein Ransomware-Schädling namens EvilQuest verbreitet sich derzeit über Raubkopien und Software-Updates aus fragwürdigen Quellen. Eine kostengünstige Entsperrung der verschlüsselten Daten wird bereits für 50 US-Dollar in Bitcoin angeboten. Doch der Service Gedanke trügt: Die Ransomware ist nur ein Puzzleteil einer umfangreichen Supply-Chain.
Selbst wenn der Nutzer zahlt, endet damit nicht der Service der Schadsoftware-„Hersteller“, denn EvilQuest beherrscht auch die Suche nach Virenscannern und Tools zur Verwaltung von Kryptowährungen sowie die Installation eines Keyloggers und einer Fernsteuerung für den Angreifer (Reverse Shell). Zudem setzt sich die Malware tief im System fest und überträgt Nutzerdaten auf den Server des Angreifers.
Um derlei Risiken zu reduzieren, sollte man vertrauenswürdige Download-Quellen verwenden –sowohl bei der Installation als auch bei Updates – um die eigene Supply-Chain sauber zu halten. Denn auch wenn der macOS-interne Schutz XProtect die Malware inzwischen blockiert und gegen die mangelhafte Verschlüsselung ein Tool existiert, bleiben drei Fragen offen, die Nutzer aller Betriebssysteme vereint: Ist der Angreifer noch da? Wo sind meine persönlichen Daten? Habe ich ein aktuelles Offline-Backup meiner wichtigsten Daten?

https://www.heise.de/news/Neue-Mac-Ransomware-kursiert-in-illegalen-Kopien-4800485.html

https://www.heise.de/news/Mac-Malware-EvilQuest-ThiefQuest-Entschluesselungs-Tool-soll-helfen-4839435.html

Ruck ohne Hau – Corona-Warn-App kein Security-Albtraum

Es geht diese Tage ein Ruck durch das Neuland – und zwar kein Hau-Ruck, den viele gleichwohl befürchtet hatten, als sich abzuzeichnen drohte, dass auch die deutsche Corona-Warn-App bei Datenschützenden und anderen IT-Justice Warriors von Anfang an in Ungnade stehen würde. Nun staunt der Laie – und selbst der Chaos Computer Club und sein Umfeld wundern sich: Ist die Macht der Datenverbraucherschützer wirklich so groß geworden, dass Behörden sich wandeln und plötzlich agile Open Source produzieren (lassen)? Anscheinend haben das Schreiben offener Briefe und das Führen hitziger Diskussionen in den sozialen Medien diesmal zwei Großkonzerne und mehrere Behörden dazu gebracht, in entscheidenden (auch datenschutz- bzw. sicherheitskritischen) Fragen umzusteuern. Das sind wir nicht gewöhnt!

Gezeigt hat sich auf jeden Fall schon jetzt: Die frühzeitige und umfassende Einbindung, gerade auch kritischer Kunden- und Gesellschaftsgruppen hat der Verbreitung der App zumindest nicht geschadet. Ob dies auch massenhafte Nutzung garantiert, steht auf einem anderen Blatt. Aber in einer idealen Welt wird auch dieser Prozess wie alle anderen gesellschaftlich relevanten Veränderungen von einer informierten und kritisch-produktiven Öffentlichkeit begleitet und wenn notwendig in die richtige Richtung gestupst. Auch angesichts einiger anderer Meldungen in diesem Digest: Zu Tode gesiegt hat sich die digitale Bürgerrechtsbewegung noch lange nicht.

Von Penetrationstests bis Konfig-Review

Eine Beschreibung gängiger Testtypen

Als technisches Audit wird gemeinhin die Untersuchung eines IT-Systems auf Schwachstellen und Sicherheitslücken mithilfe technischer Mittel beschrieben. Doch Penetrationstest ist nicht gleich Penetrationstest. Es gibt viele verschiedene Arten bzw. Typen von Tests, die jeweils unterschiedliche Arten von Fehlern aufdecken können. Die Testtypen unterscheiden sich insbesondere durch die Zugriffsmöglichkeiten, welche dem Testteam eingeräumt werden. So können durch Penetrationstests unterschiedliche Angriffsszenarien überprüft werden, von externen Angreifern bis hin zu Angreifern im internen Netzwerk der zu testenden Infrastruktur. Diese Übersicht soll die unterschiedlichen Typen von Penetrationstests voneinander abgrenzen sowie ihre Möglichkeiten und Einsatzbereiche beschreiben. Ziel ist dabei nicht, eine vollständige Übersicht aller existierenden Testtypen zu schaffen, sondern die gängigsten Typen vorzustellen und zu einzuordnen.

Testtypen

Externer Penetrationstest

Bei einem externen Penetrationstest versetzt sich das Testteam in die Position eines externen Angreifers. Das Team kann nur öffentlich zugängliche Bereiche eines Netzwerkes erkunden und muss in vielen Fällen interne Strukturen erraten, um Sicherheitslücken auszunutzen. Um die Testdauer zu reduzieren, werden Intrusion-Prevention-Systeme für externe Penetrationstests häufig deaktiviert.
Externe Penetrationstests eignen sich gut, um gängige Schwachstellen aufzudecken, welche über das Internet erreichbar sind und somit von einer Vielzahl potentieller Angreifer ausgenutzt werden könnten.

Interner Penetrationstest

Bei einem internen Penetrationstest wird das Testteam in die Lage eines Angreifers versetzt, der Zugang zum internen Netz der zu testenden Umgebung besitzt. Das Team verfügt daher über viele Zugangsmöglichkeiten und teilweise auch Informationen zu internen Strukturen. Durch diesen Testtyp können Probleme aufgedeckt werden, welche versehentlich durch Fehler in internen Abläufen auftreten können oder gezielt von einem Angreifer hervorgerufen werden, welcher sich bereits Zugang zu dem Netz verschafft hat.
Interne Penetrationstests eignen sich gut, um Schwachstellen in der internen Infrastruktur aufzudecken. Zwar ist die Anzahl der potentiellen Angreifer geringerer, da diese sich zunächst Zugang zur internen Infrastruktur verschaffen müssen. Die möglichen Folgen der Schwachstellen sind jedoch in vielen Fällen besonders schwerwiegend.

Web-Penetrationstest

In Web-Penetrationstests werden Webseiten und Webanwendungen aus externer Sicht getestet. Dem Testteam stehen die Möglichkeiten eines externen Angreifers zur Verfügung. Häufig sind keine internen Strukturen bekannt. Um die Testdauer zu reduzieren, werden Intrusion-Prevention-Systeme für Web-Penetrationstests wie etwa eine Web Application Firewall (WAF) teilweise deaktiviert. Web-Penetrationstests eignen sich, um gängige Schwachstellen in Webanwendungen aufzudecken, welche über das Internet von einer Vielzahl potentieller Angreifer ausgenutzt werden könnten.

Applikations- oder API-Test

In Applikations- oder API-Test werden Anwendungen und Programmierschnittstellen untersucht. Durch die Offline-Untersuchung können die Tester umfangreiche Informationen sammeln. Dieser Testtyp eignet sich besonders gut, um Schwachstellen in Architektur, Design und Implementation von Anwendungen oder Schwachstellen zu finden.

Konfigurations- oder Architekturaudit

Bei diesem Testtyp wird die Konfiguration und/oder die Architektur einer Anwendung für die individuellen Anwendungszwecke überprüft. Die Tester nehmen eine interne Rolle ein, da sie Zugang zu Konfigurationsdateien und Architekturinformationen haben. Sie können somit eine detailliertere Prüfung als über einen externen „Black-Box“-Test vornehmen und konkretere Empfehlungen aussprechen. Dieser Testtyp eignet sich gut, um Probleme in Architektur und Betrieb der internen Software-Landschaft zu finden.

Dokumentations- oder Organisationsaudit

Bei dieser Art von Test tritt das Testteam in einer internen Rolle auf. Durch die Überprüfung von Organisationsprozessen und Dokumentationen kann es bestehende Probleme identifizieren und konkrete und individuelle Verbesserungsvorschläge abgeben.

Dieser Testtyp ist gut geeignet, falls Abläufe überprüft werden sollen, die über die eigentliche Softwareentwicklung und -wartung hinausgehen.

Fazit

Welche Art von Penetrationstest sich empfiehlt, hängt stark von der Umgebung ab, welche untersucht werden soll. Darüber hinaus ist das übergeordnete Ziel des Audits zu beachten, das mit den Sicherheitszielen der Organisation im Einklang stehen sollte. Insbesondere kommt es dabei auf die Exposition des Systems und somit die zu erwartenden Angriffsvektoren an. In der von der HiSolutions AG veröffentlichten Pentest-Statistik 2020 werden die Schweregrade der Schwachstellen betrachtet, welche von unterschiedlichen Testtypen aufgedeckt werden. Allgemein lässt sich dabei aussagen, dass schwerere Befunde entdeckt werden, je mehr Zugriffsrechte dem Testteam gewährt werden. Während für die meisten Systeme lediglich externe Tests durchgeführt werden, betont der Bericht somit die Relevanz interner Systemprüfungen.

Übrigens: Hier finden Sie das Angebot der HiSolutions zu Penetrationstests.

HiSolutions Schwachstellen-Report 2020

Dominik Oepen, Team Manager Penetrationstests & Tom Breitkopf, Consultant, HiSolutions AG

[Whitepaper als PDF]

HiSolutions führt jedes Jahr eine große Anzahl von unterschiedlichen Penetrations- und Schwachstellentests durch. Immer wieder taucht dabei die Frage auf, wie die Ergebnisse des einzelnen Tests im Vergleich mit „typischen“ Pentest-Ergebnissen einzustufen sind und ob die identifizierten Probleme bei anderen Unternehmen in ähnlicher Form und Schwere bestehen.

Wir haben diese Fragen zum Anlass genommen, die von uns in den letzten Jahren durchgeführten Tests jahresweise auszuwerten und die jeweils identifizierten Schwachstellen nach Schweregrad und Kategorien zu analysieren. Diese Aggregation erlaubt uns, einerseits die Vertraulichkeit der Projektergebnisse gegenüber unseren Kunden zu wahren, andererseits aber Aussagen über typische Testergebnisse und Problembereiche abzuleiten, die entweder besonders häufig auftauchen oder besonders schwerwiegende Lücken darstellen. Durch die Fortschreibung der Auswertung über die Jahre hinweg werden dabei auch interessante Trends und wichtige Entwicklungen in der Sicherheitslage deutlich.

Vorgehen

Dieser Report beruht auf einer Auswertung der Ergebnisse aus insgesamt 90 Penetrations- und Schwachstellentests, die im Jahr 2019 durchgeführt wurden. Zusätzlich haben wir die Befunde mit den Ergebnissen unserer Schwachstellenreports der Jahre 2013 bis 2018 verglichen.

Die Tests betreffen verschiedene Zielumgebungen, von Netzwerkinfrastrukturen über Web-Anwendungen bis hin zu einzelnen Systemen und Verfahren, sind also nicht direkt miteinander vergleichbar. Durch die Kategorienbildung bei den Schwachstellen lassen sich dennoch interessante Beobachtungen ableiten.

Für die Kategorien haben wir uns zunächst an den „OWASP Top 10“ orientiert. Diese Veröffentlichung des OWASP-Projektes aus dem Jahr 2017[1] umfasst eine Systematik der schwerwiegendsten Schwachstellen für Web-Anwendungen, die dort auf der Grundlage einer Berechnung der Schweregrade auf der Basis von Häufigkeiten und Auswirkungen erstellt wurde. Die Kategorien lassen sich dabei zum Teil auch auf andere Testziele gut übertragen, decken jedoch nicht alle unsere Befunde vollständig ab, sodass wir einige eigene Kategorien ergänzt haben. Diese umspannen den gesamten Zyklus der Softwareentwicklung und des Betriebs von Architektur und Design über Implementierung bis hin zur Systempflege. Dadurch lassen sich auch entsprechende Sicherheitslücken jenseits von Web-Anwendungen feingranular einordnen.

In diesem Jahr wurden die Kategorien gegenüber den Vorjahren aktualisiert, um vollständig mit der aktuellsten „OWASP Top 10“-Liste übereinzustimmen. Die Kategorien „Insecure Direct Object Reference (OWASP A4)“ und „Missing Function Level Access Control (OWASP A7)“ wurden zu der Kategorie „Broken Access Control (OWASP A5)“ zusammengefasst. Die Kategorie „Client-Side (OWASP A3/ A8) Injection“ wurde in „Cross-Site Scripting (OWASP A5)“ umbenannt. Diese Kategorie fasste in Vorjahresberichten die Kategorien „Cross-Site Scripting“ und „Cross-Site Request Forgery“ zusammen. Da letztere jedoch aus der OWASP Top 10 Liste verschwunden ist, wird sie nicht mehr separat aufgelistet. Neu hinzugekommen ist des Weiteren die Kategorie „Insufficient Logging and Monitoring (OWASP A10)“. Nicht geführt werden die Kategorien „XML External Entities (OWASP A4)“ und „Insecure Deserialization (OWASP A8)“, da diese selten zur Einteilung verwendet wurden.

Die Aggregation der Daten bringt einige praktische Schwierigkeiten mit sich: Wegen der Unterschiedlichkeit der durchgeführten Tests ließen sich keine relevanten Aussagen zur Häufigkeit von Schwachstellen in einem bestimmten System oder einer Anwendung ermitteln. Auch fassen wir in den Projektberichten gleichartige Schwachstellen auf verschiedenen Systemen häufig zu einem Befund zusammen, so dass eine Zählung der Befunde hier ebenfalls nur begrenzte Aussagekraft hat. Wir haben uns daher entschlossen, als Maß die relative Häufigkeit von Projekten, in welchen ein Befund der entsprechenden Kategorie auftauchte, zu verwenden. Dadurch wird deutlich, welchen Schwachstellen wir in unterschiedlichen Projekten besonders häufig begegnen, und welche eher selten oder nur in besonderen Zielumgebungen auftauchen.

Für die Bewertung der Relevanz einer Schwachstelle verwenden wir in unseren Prüfberichten ein standardisiertes Schema, in dem wir aus der Bewertung der Komplexität des Angriffs und des zu erwartenden Schadens zu einer Einordnung in die folgenden Kategorien kommen:

  • CRITICAL (C): Die getesteten Systeme sind akut gefährdet, umgehendes Handeln ist (in der Regel noch während der Testdurchführung) erforderlich.
  • HIGH (H): Die Schwachstelle hat eine hohe praktische Relevanz und sollte priorisiert behoben werden.
    MEDIUM (M): Die Schwachstelle besitzt ein relevantes Schadenspotenzial, dieses kann aber nur in bestimmten Umständen oder in Verbindung mit anderen Problemen realisiert werden.
  • LOW (L): Die Schwachstelle stellt für sich keine unmittelbare Gefahr dar, kann jedoch Angriffe über andere Schwachstellen erleichtern oder verstärken.

Rein informative Befunde (z. B. festgestellte funktionale Fehler ohne Sicherheitsbezug) wurden in der Auswertung nicht berücksichtigt.

Ergebnisse

Die Erkenntnisse der Auswertung aller Penetrationstests des letzten Jahres sollen im Folgenden vorgestellt werden. Dazu werden die durch Tests aufgedeckten Sicherheitslücken im Kontext der Entwicklungen über die letzten Jahre betrachtet. Verwendet wird dafür die Kategorie und der Schweregrad jeder Schwachstelle.
Erstmals wird in diesem Jahr auch die Art des durchgeführten Tests berücksichtigt und die Effizienz der im Anschluss an Penetrationstests durchgeführten Maßnahmen bewertet.

Abbildung 1 zeigt die Entwicklung des Schweregrads von Sicherheitslücken von 2013 bis 2019. Dieser Schweregrad wird im Folgenden auch als Kritikalität bezeichnet. Für die Generierung der Werte wurde jedem durchgeführten Penetrationstest die maximale Kritikalität aller von ihm aufgedeckten Sicherheitslücken zugeordnet. Ein Penetrationstest, welcher eine kritische Sicherheitslücke aufgedeckt hat, wird daher als kritisch eingestuft. Dies ist dadurch zu begründen, dass eine einzige Lücke des entsprechenden Schweregrades ausreicht, die Sicherheit des gesamten Systems zu beeinträchtigen.
Seit 2013 sind Schwankungen ohne eindeutige Tendenz in der Entwicklung der Kritikalität von Penetrationstests zu verzeichnen. Nach einem Rückgang der als kritisch oder hoch eingestuften Penetrationstests von 2015 bis 2018 war im letzten Jahr erstmals wieder ein deutlicher Zuwachs zu erkennen. Nur im Jahr 2015 lieferte ein größerer Anteil der Tests schwerwiegende Befunde. Dies liegt im Rahmen der kurzeitigen Schwankungen und muss nicht auf einen Negativtrend verweisen. Dennoch weist es darauf hin, dass trotz der erhöhten öffentlichen Aufmerksamkeit für das Thema IT-Sicherheit aus den betrachteten Untersuchungen keine grundlegende Verbesserung in diesem Bereich über die letzten Jahre abgeleitet werden kann.

Abbildung 1: Entwicklung der Kritikalität von 2013 bis 2019

Um die Sicherheit von bestehenden Systemen zu verbessern und Sicherheitsaspekte im Entwurf neuer Systeme zu berücksichtigen, ist es wichtig zu verstehen, welche Art von Sicherheitslücken besonders häufig auftritt und welche Auswirkungen dies haben kann.
In Abbildung 2  wird daher zunächst die Entwicklung des Auftretens bestimmter Fehlerklassen in den letzten Jahren gezeigt. Dargestellt wird der Anteil der Penetrationstests, welche mindestens einen Befund der Kategorie erzeugt haben. Abbildung 3 zeigt die schwere der Befunde dieses Jahres aufgeschlüsselt nach Kategorie.  Angegeben wird dabei der Anteil der unterschiedlichen Kritikalitätswerte an den Gesamtbefunden der jeweiligen Kategorie.

Auch für das Jahr 2019 konnten viele verschiedene Probleme bei der Entwicklung, Konfiguration und dem Betrieb von Software beobachtet werden.
Die Häufigkeit, mit der sensible Daten preisgegeben wurden, nahm im Vergleich zu den Vorjahren deutlich ab. Dennoch traten diese Fehler weiterhin in über der Hälfte aller Tests auf. Deutlich zugenommen hat im Jahr 2019 erneut die Anzahl der Penetrationstests, welche fehlerhafte Konfigurationen mit Folgen für die Sicherheit eines Systems aufdecken konnten. In neun von zehn Tests wurde eine derartige Fehlkonfiguration gefunden. Zwar entstanden aus beiden Kategorien meist lediglich geringe Sicherheitsrisiken, doch sind bei groben Fehlern auch schwerwiegende Auswirkungen möglich.
Sowohl OWASP A3 als auch OWASP A6 sind typische Fehlerklassen, welche aus Fehlern im Betrieb von Software und nicht in deren Entwicklung entstehen. Die erhoffte Verbesserung im Umgang mit IT-Systemen kann also bedauerlicherweise nicht oder nur in Teilen beobachtet werden.

Abbildung 2: Häufigkeit der Kategorien von 2016 bis 2019

Besonders bedenklich ist die deutliche Zunahme der Häufigkeit, mit der Komponenten mit bekannten Schwachstellen eingesetzt wurden von 41% auf 66%. Da Informationen zu diesen Schwachstellen und in vielen Fällen darüber hinaus Exploits, welche sie ausnutzen, öffentlich verfügbar sind, haben Fehler dieser Art besonders häufig kritische oder schwere[2] Auswirkungen auf die Sicherheit eines IT-Systems. Diese Schwachstellen entstehen in der Regel durch ein mangelhaftes Patch-Management, welches sicherstellen sollte, dass verwundbare Software aktualisiert wird. Die Etablierung eines funktionierenden Patch-Managements bzw. einer kontinuierlichen Systempflege stellt also weiterhin eine Herausforderung für viele Unternehmen dar. Dies verdeutlicht auch die Kategorie „mangelnde Systempflege“, welche allgemeine Fehler dieser Art beinhaltet, und in mehr als der Hälfte aller Tests gefunden wurde, wobei häufig kritische oder schwere Sicherheitslücken dadurch entstanden.

Auch Schwachstellen, welche durch Fehler im Entwurf und in der Entwicklung von Softwaresystemen entstehen, wurden durch Penetrationstests im Jahr 2019 aufgedeckt. Besonders eine ungeeignete Systemarchitektur führt dabei zu schwerwiegenden Fehlern. Dennoch konnte eine solche in 41% aller Penetrationstests festgestellt werden. Ähnlich häufig treten Implementierungsfehler auf. Design-Fehler konnten in etwa einem Viertel aller Penetrationstests festgestellt werden. Wie schwerwiegend die Folgen fehlerhafter Softwareentwicklung sein können verdeutlich die Kategorie fehlerhafte Zugriffskontrolle, welche über die letzten Jahre in etwa 40% der Penetrationstests zu finden war und wenn vorhanden in mehr als 40% der Fälle als kritisch oder hoch eingestuft wurde.

Laut unserer Erfahrungen aus Sicherheitsaudits werden Sicherheitsfragen in IT-Projekten häufig erst im Zuge der Betriebseinführung betrachtet, also nachdem vormals genannte Probleme bereits entstanden sind. Dies ist besonders problematisch, da die Auswirkungen von Fehlern schwerer sind, je früher der Entwicklungsschritt ist, in dem sie auftauchten. So wiegen im Mittel Fehler in Architektur und Design deutlich schwerer als solche in der Implementierung.

Abbildung 3: Kritikalität der Befunde nach Kategorie

Unzureichendes Monitoring und Logging wird im diesjährigen Bericht erstmals betrachtet. Es tritt in lediglich 10% der Tests auf und birgt stets lediglich geringes bis mittleres Risiko. Es kann jedoch das Aufspüren von Angriffen und deren Aufklärung deutlich verzögern und erschweren und sollte daher nicht vernachlässigt werden.

Die meisten kritischen Sicherheitslücken nach absoluten Zahlen waren eine Folge von mangelnder Systempflege. Auf den nächsten Plätzen folgt die Verwendung von Komponenten mit bekannten Sicherheitslücken und die Preisgabe sensibler Informationen. Auch Fehlkonfigurationen, Fehler bei der Authentifizierung und eine ungeeignete Systemarchitektur führten häufig zu kritischen Sicherheitsproblemen.
Betrachtet man ebenfalls Sicherheitsprobleme mit einer hohen Kritikalität, so liegen eine fehlerhafte Zugriffskontrolle und eine ungeeignete Systemarchitektur noch vor der Nutzung unsicherer Komponenten und mangelnder Systempflege.

Auch in Betrachtung der Einzelkategorien ist über die letzten Jahre keine Verbesserung der Sicherheitseigenschaften von IT-Systemen zu beobachten. Es bestehen weiterhin eine Vielzahl unterschiedlicher Fehlerquellen, welche die Sicherheit von Systemen beeinträchtigen können. In der Aufteilung der Fehlerkategorien setzen sich die Trends der Vorjahre fort. Es ist deutlich zu beobachten, dass es bei Konfiguration, Betrieb und Wartung von IT-Systemen zu den meisten sicherheitskritischen Fehlern kommt. Probleme in diesem Bereich werden wie in den Vorjahren in fast jedem Penetrationstest festgestellt. Auch Probleme in der Entwicklung bleiben eine Gefahrenquelle mit großen Schadenspotential. Sie konnten zwar in weniger Penetrationstests aufgedeckt werden, bergen jedoch, falls vorhanden, teilweise gravierende Risiken.

Auswertung nach Testtyp

Die HiSolutions AG bietet eine Vielzahl unterschiedlicher Sicherheitsüberprüfungen an. Besonders häufig werden externe Penetrationstests und Web-Penetrationstests ausgeführt, bei denen das Testteam die gleichen Möglichkeiten wie externe Angreifer besitzen. Es werden jedoch auch interne Penetrationstests vorgenommen. Bei diesen stehen dem Testteam wesentlich mehr Möglichkeiten zur Verfügung, da sie sich im internen Netz des Auftraggebers befinden. Auch die Überprüfung von Quellcode, Architektur und Konfiguration von IT-Systemen wird von der HiSolutions angeboten. Ebenso können fertige Applikationen oder Betriebsstrukturen und Dokumentationen erprobt werden.

Abbildung 4 zeigt die Kritikalität abhängig von dem Typ des durchgeführten Tests. In einem Penetrationstest können mehrere Überprüfungen unterschiedlicher Art vorhanden sein. Für die Auswertung werden die einzelnen Testbestandteile aller Penetrationstests betrachtet. Die in Abbildung 4 dargestellte Kritikalitätsverteilung ergibt sich, indem, wie in vorherigen Auswertungen, jedem Testbestandteil die maximale Kritikalität zugeordnet wird, welche er enthält. Für eine bessere Vergleichbarkeit werden relative Häufigkeiten dargestellt.

Verallgemeinert lässt sich die Auswertung der Befunde reduzieren auf die Aussage: Je mehr Zugang das Testteam hat, desto kritischer die aufgedeckten Sicherheitslücken. In internen Penetrationstests konnten in etwas weniger als 40% der Fälle kritische und in knapp 80% der Fälle mindestens schwere Sicherheitslücken entdeckt werden. Auch in Dokumentations- oder Organisationsaudits und Applikations- oder API-Tests wurden häufig kritische Schwachstellen aufgedeckt.  Auch wenn Konfigurationsaudits oder Architekturreviews in verhältnismäßig wenigen Fällen kritische Sicherheitslücken aufgedeckt haben, so konnten sie doch eine erhebliche Anzahl schwerer Mängel finden. Externe und Web-Pentests, bei welchen das Testteam deutlich weniger Zugriffsrechte hat als in den vorangegangenen Testtypen, konnten in deutlich weniger fällen kritische oder schwere Sicherheitslücken aufdecken. Dennoch wurden auch bei diesen Tests in etwa 30% bis 40% der Fälle kritische oder schwere Sicherheitslücken gefunden, sodass ihre Effektivität nicht zu unterschätzen ist. Lediglich in einer sehr kleinen Anzahl von Tests wurden keine Befunde festgestellt.[3]

Abbildung 4: Kritikalität nach Testtyp

Auswertung der Nachtests

Anbieter von Penetrationstests empfehlen in der Regel eine Verifikation der im Anschluss umgesetzten Maßnahmen als wirkungsvolles Mittel zur Verbesserung der Sicherheitseigenschaften von IT-Systemen. Die tatsächliche Wirksamkeit wird im Folgenden überprüft. Zu diesem Zweck werden Befunde betrachtet, bei denen ein Nachtest stattgefunden hat, also eine Überprüfung der nach dem Penetrationstest implementierten Maßnahmen. Abbildung 5 zeigt die Anzahl der Befunde und deren Kritikalität nach Kategorien. Der obere Balken bezieht sich dabei auf die Befunde im Penetrationstest, der untere auf die Befunde im Nachtest.[4]

Alles in allem ist eine Abnahme der Kritikalität von ursprünglichem Penetrations- zu Nachtest zu erkennen. Insbesondere sicherheitskritische Fehlkonfigurationen und Fehler bei der Zugriffskontrolle wurden häufig vollständig beseitig, da dies in vielen Fällen mit geringem Aufwand möglich ist. Dahingegen kam die Preisgabe sensibler Informationen auch in vielen Nachtests weiterhin zum Tragen. Allgemein kann beobachtet werden, dass ein Befund eher behoben oder zumindest teilweise behoben wurde, je höher seine Kritikalität eingestuft war.

Insgesamt wurde gut die Hälfte aller Sicherheitsmängel bis zum Nachtest komplett beseitigt. Die Anzahl der kritischen und schweren Befunde reduzierte sich auf weniger als ein Dritter der ursprünglichen Befunde. Es lässt sich also bestätigen, dass mit Hilfe von Penetrationstest die Sicherheitseigenschaften einer Systemlandschaft deutlich verbessert werden können. Zu beachten bleibt jedoch, dass knapp die Hälfte der entdeckten Sicherheitslücken bis zum Nachtest nicht befriedigend geschlossen wurde. Dies zeigt, dass in einigen Fällen die Risiken der durch den Penetrationstest offengelegten Schwachstellen ernster genommen werden müssen und schneller reagiert werden muss.

Abbildung 5: Kritikalität von Penetrationstest zu Nachtest

Injection (OWASP A1)

Ähnlich wie bei Cross-Site-Scripting-Angriffen bringt bei der Injection ein Angreifer eigenen Programmcode in eine Anwendung ein, der hier jedoch auf der Serverseite ausgeführt wird und dadurch ein besonders hohes Schadenspotenzial hat. Der nach wie vor überwiegende Anteil besteht dabei in SQL-Injections, bei denen der Angreifer Datenbankabfragen der Anwendung manipuliert und sich so unbefugten Zugriff auf Daten und Funktionen verschafft.

Broken Authentication (OWASP A2)

In diese Kategorie fallen Fehler, die mit fehlerhafter Authentifizierung oder Sitzungsverwaltung zusammenhängen. Durch diese wird es Angreifern erlaubt Passwörter, Schlüssel oder Sitzungs-Tokens zu kompromittieren oder auf andere Weise temporär oder permanent eine falsche Identität anzunehmen. In den letzten Jahren konnten über 30 verschiedene Arten von Einzelbefunden identifizieren können. Besonders schwerwiegend sind Session-Tokens in URLs, Session-Fixation-Angriffe sowie in bestimmten Fällen mangelhaft geschützte Session-Cookies, unsichere SSH-Schlüssel, zu wenig Entropie in Session-IDs oder in Einzelfällen Logins mit Default-Credentials oder gar ohne jede Zugangskontrolle.

Sensitive Data Exposure (OWASP A3)

Unter diese Kategorie fallen alle Schwachstellen, die zu einem mangelhaften Schutz sensibler Daten führen. Dazu gehören neben einer fehlerhaften Konfiguration der Transportsicherheit (SSL) auch ein mangelhafter Schutz von Passwörtern und anderen sensiblen Daten durch eine fehlende Verschlüsselung oder den Einsatz veralteter Verschlüsselungsverfahren. Gerade die Anwendung kryptografischer Algorithmen hält viele Fallstricke bereit, die von Angreifern ausgenutzt werden können. Allerdings sind solche Schwachstellen nur selten als kritisch zu bewerten, da sie zumeist nur unter bestimmten Umständen oder mit einem erheblichen Aufwand ausnutzbar sind.

Broken Access Control (OWASP A5)

Fehler dieser Kategorie entstehen, falls Restriktionen was authentifizierte Nutzer tun und nicht tun dürfen nicht korrekt umgesetzt werden. Angreifern ist es dadurch möglich auf unerlaubt auf Daten oder Funktionen zuzugreifen. So kann es ihnen möglich sein die Daten anderer Nutzer einzusehen oder zu verfälschen, andere sensible Dateien zu lesen oder Zugriffsrechte zu manipulieren.

Security Misconfiguration (OWASP A6)

Diese Kategorie umfasst alle Arten von Konfigurationseinstellungen, die zu Schwachstellen oder Angriffspunkten führen, und ist daher in sich sehr heterogen – wir haben über 60 ver­schiedene Arten von Befunden dieser Kategorie zugeordnet. Viele der Konfigurations­probleme führen jedoch auch nur zu geringen Risiken, so dass die meisten Einstufungen hier niedrig bis mittel ausgefallen sind. Kritisch sind lediglich bestimmte Fälle der Preisgabe von Informationen über technischen Konfigurationsdaten, Directory-Listings oder nicht gelöschte Beispiel- und Hilfedateien, die in den entsprechenden Fällen jeweils einen unmittelbaren Ansatzpunkt für Angriffe gegeben haben.

Cross-Site Scripting (OWASP A7)

Cross-Site-Scripting-Angriffe basieren auf dem Prinzip, dass der Angreifer in die Anwendung Programmcode einbringt, der auf dem Client eines Anwenders ungewollt zur Ausführung gelangt. Dabei handelt es sich meist um reflektiertes XSS (also dem Anwender über einen Link untergeschobenes), vereinzelt auch um persistentes XSS (dauerhaft in die Anwendung eingebrachten Schadcode).

Using Components with Known Vulnerabilities (OWASP A9)

Unter diese Kategorie fällt eine Vielzahl von Schwachstellen, die insbesondere aus einem mangelhaften Software- und Patchmanagement resultieren: Veraltete Software, vom Betriebssystem über die Anwendungsserver, Frameworks, die Anwendungssoftware und Erweiterungen oder Plug-Ins, kann eine Vielzahl von Schwachstellen beinhalten, die nach der Veröffentlichung leicht von Angreifern ausgenutzt werden können. Wird die Software nicht sorgfältig gepflegt, können schnell Lücken entstehen, die ein großes Schadenspotenzial beinhalten.

Insufficient Logging & Monitoring (OWASP A10)

Unzureichendes Logging und Monitoring verzögert die Entdeckung einer Kompromittierung. Durch die zusätzliche Zeit ist es Angreifern möglich weitere Systeme zu infizieren, mehr Daten zu sammeln oder zu manipulieren. Des Weiteren wird die Identifizierung des Einfallstores eines Angreifers sowie des Angreifers selbst erschwert.

Anwendung: Design-Fehler

Designfehler in Anwendungen sind zum Glück selten, dann aber oftmals gefährlich. Die Ausprägungen sind unterschiedlich, Beispiele sind Datenbankzugriff mit administrativen Rechten, Zulassen trivialer Passwörter, unnötige Exportfunktionen, unsichere Schnittstellen oder die ungewollte Preisgabe von Nutzerinformationen.

Anwendung: Implementierungs-Fehler

Wie bei der Vielzahl und Vielfalt existierender Anwendungen zu erwarten, bilden die hier zusammengefassten gut zwei Dutzend Schwachstellen einen bunten Strauß an Dingen, die bei der Implementierung von Anwendungen falsch gemacht oder vergessen wurden – über die von den OWASP-Kategorien bereits erfassten Fehlermöglichkeiten hinaus. Besonders kritische Fälle stehen oft im Zusammenhang mit mangelnder Rechteprüfung beim Lesen oder Schreiben sowie beim Upload von Dateien.

Ungeeignete Sicherheitsarchitektur

Relativ häufig sind wir in unseren Projekten auf Sicherheitsarchitekturen gestoßen, die ihre Schutzfunktion nicht erfüllen. Dies begründet sich manchmal in fehlenden Schutzmechanismen (Firewalls), z. T. jedoch auch in vorhandenen, aber in der vorliegenden Konfiguration nicht wirksamen Sicherheitssystemen. Dieser Effekt ist besonders bei sogenannten Web Application Firewalls (WAF) häufiger zu beobachten. Ebenfalls in diese Kategorie haben wir eine aus Sicherheitssicht unzureichende Trennung von Produktiv- und Testumgebungen gezählt.

Mangelnde Systempflege

Mangelnde Systempflege kann auf verschiedene Weisen zu Sicherheitsproblemen in einem IT-System führen. Die Kategorie wird daher für eine Vielzahl von Fehlerarten, welche sich nicht in die bestehenden Kategorien einordnen lassen, genutzt. Besonders häufig treten Mängel im Patch-Management auf. Diese können wiederum zu Fehlern der Kategorie „Using components with known vulnerabilities (OWASP A9)“ führen. Weitere häufige Fehler bestehen im Weiterbetrieb von ungenutzten Systemen, Test- und Beispielsystemen oder Systemen, welche nicht nach außen offen sein sollten oder abgelaufene Zertifikate besitzen. Ebenso kommen ungenutzte und undokumentierte Firewall-Regeln, fehlerhafte Systemzeiten und Login-Möglichkeiten mit Standard-Zugangsdaten vor.

Fazit

Im Jahr 2019 bestand weiterhin eine Vielzahl unterschiedlicher Sicherheitsprobleme in den von der HiSolutions überprüften IT-Systemen. Besonders die Zahl der fehlerhaften Konfigurationen und die Häufigkeit, mit der verwundbare Komponenten eingesetzt wurden, haben sich in diesem Jahr deutlich erhöht.  Abgenommen hat hingegen die Anzahl der Fehler, bei denen sensible Informationen preisgegeben wurden oder die Authentifizierung nicht korrekt funktionierte. Trotz dieser Abweichungen ergibt sich in Summe ein ähnliches Bild wie über die letzten Jahre.

Schwere und kritische Sicherheitslücken wurden im vergangenen Jahr nach leichtem Rückgang 2018 wieder häufiger festgestellt. Es gab keinen einzigen Penetrationstest, welcher keine Befunde hervorgebracht hat. Insgesamt besteht folglich kein Grund für Entwarnung. Ganz im Gegenteil besteht weiterhin akuter Handlungsbedarf beim Schutz von IT-Systemen.

Für die kommenden Jahre ergibt sich insbesondere die Notwendigkeit, den Entwicklungsprozess von Software weiter zu optimieren. Besonders schwerwiegende Probleme treten bei Fehlern in der Architektur oder im Design auf. Es ist daher dringend ratsam, IT-Sicherheitsexperten am Entwicklungsprozess zu beteiligen und möglichst früh in die Planung mit einzubeziehen. Um Implementierungsfehler zu reduzieren, können ein Secure Development Lifecycle, Entwicklertrainings und Source-Code-Reviews probate Mittel sein.

Mehr denn je bestehen die größten Herausforderungen in der korrekten Konfiguration und Wartung von Software. Insbesondere ist es für die kommenden Jahre für viele Unternehmen besonders drängend, das Patch-Management zu verbessern. Wird vermieden, dass Systeme hinter den aktuellen Stand der Entwicklung zurückfallen, können schwerwiegende Risiken durch öffentlich bekannte Schwachstellen verhindert werden.

Durch die Diversität der Probleme und den Varianten­reichtum der in der Praxis vorgefundenen Schwachstellen wird ein einfaches und schnelles Auffinden beispielsweise durch automatisierte Verfahren erschwert. Das Testen auf ausgewählte „Top-10“-Lücken erweist sich weiterhin als nicht hinreichend.

Welche Schwachstellen durch einen Penetrationstest aufgedeckt werden, hängt auch von der Art des Tests ab. Im vergangenen Jahr wurden durch die HiSolutions besonders häufig externe und Web-Penetrationstests durchgeführt. Die Auswertung zeigt jedoch, dass viele besonders schwerwiegende Sicherheitslücken erst aufgedeckt werden können, wenn dem Testteam mehr Zugangsrechte eingeräumt werden. Für viele Unternehmen kann es daher für die Zukunft sinnvoll sein, über eine externe Untersuchung der Systeme hinaus zu gehen und auch interne Strukturen prüfen zu lassen.

Der Bericht verdeutlicht, dass anhand von Penetrationstests viele Sicherheitsprobleme in IT-Infrastrukturen erkannt werden können, welche ohne externe Kontrolle (bis zu einem Angriff) verdeckt geblieben wären. In vielen Fällen wurde auf Befunde korrekt reagiert. So wurden insbesondere kritische und schwere Sicherheitslücken bis zu einem Nachtest drastisch reduziert. Insgesamt haben sich die Sicherheitseigenschaften der getesteten Systeme nach einem Penetrationstest unbestreitbar verbessert.

In anderen Nachtests wurde jedoch deutlich, dass Sicherheitslücken teilweise nicht adäquat geschlossen werden. Außerdem können sich die Sicherheitseigenschaften eines Systems über die Zeit verändern. Daher sehen wir wiederholte Penetrationstests mit wiederholter Überprüfung gefundener Sicherheitslücken und der zu ihrem Schließen eingesetzten Sicherheitsmaßnahmen als einen wichtigen Schritt zu mehr Sicherheit in IT-Systemen.

Kontakt: HiSolutions AG


[1] https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

[2] Schwachstellen oder Sicherheitslücken, welche mit der Kritikalität „hoch“ eingestuft wurden, werden im Folgenden häufig auch als „schwere Sicherheitslücken“ oder „Sicherheitslücken mit (potentiell) schweren Folgen“ bezeichnet.

[3] Differenzen zu Abbildung 1, in welcher kein einziger Penetrationstest ohne Befund zu verzeichnen ist, sind dadurch zu erklären, dass ein Penetrationstest aus mehreren Teilen bestehen kann und somit lediglich ein Teil des Tests ergebnislos geblieben sein kann.

[4] Da lediglich Befunde betrachtet werden, für welche ein Nachtest stattgefunden hat, können nur etwa 20% der Befunde verwendet werden. Es kann daher zu Abweichungen zu Abbildung 3 kommen, da für diese mehr Datenpunkte zur Verfügung stehen. Die Kategorie „Insufficient Logging & Monitoring (OWASP A10)“ wird mangels Daten nicht berücksichtigt.

Death by Datenschutz? Die Grenzen der Anonymität

Einer der traurigen Corona-Hotspots, die sich als Fußabdrücke eines wild gewordenen, unsichtbaren Random Walkers wie ein sich verdichtender Flickenteppich durch die Lande ziehen, ist das Potsdamer Bergmann-Klinikum. Aufgrund eines zu spät begrenzten Corona-Ausbruchs haben sich dort fast jeder zehnte Mitarbeiter und überdurchschnittlich viele Patienten mangels Testung und Isolation infiziert, etliche sind verstorben. Ein wichtiger Grund: Im Corona-Krisenstab des Klinikums war zunächst der Betriebsarzt nicht vertreten – die einzige Person, die erfahren durfte, woran erkrankte Mitarbeiter leiden. So konnte nicht festgestellt werden, wo infizierte Mitarbeiter gearbeitet haben und wie Infektionsketten verlaufen sind. Man muss nicht so weit gehen, die verursachten Todesfälle alle auf das Konto des (Gesundheits-)Datenschutzes zu schreiben. Allerdings scheint hier eine starre Regel aus einer anderen Zeit schlimme Nebenwirkungen gehabt zu haben. Nun sind wir alle aufgerufen, uns schnellstens Lösungen zu überlegen, die bei der – auch informationellen – Einhegung der Pandemie helfen.

Dabei ist die Aushebelung des Datenschutzes in der Regel gar nicht das, was benötigt wird. Im obigen Fall hätte eine relativ einfache Regeländerung die geeigneten Erkenntnisse rechtzeitig erbringen können, ohne die Krankheitsdaten vieler Mitarbeiter einem größeren Kreis bekannt zu machen. Und auch bei der aktuell diskutierten #CoronaApp sind dezentrale Ansätze ausreichend (wenn auch mit einigen technischen Herausforderungen versehen), wie nach intensiver Beratung durch die Privacy-Community inzwischen auch die Bundesregierung eingesehen hat.

Die Frage ist also nicht: Wie können wir unseren Datenschutz schnellstmöglich aufweichen? Sondern: Wie können wir ihn agil so gestalten, dass er zunächst zu einem Mittel im Kampf gegen die Krise und dann im Idealfall zu einer Blaupause für das wird, was wir gemeinsam mit Big- und Crowd-Data zukünftig noch an Lebensqualitätsverbesserung erreichen können?

https://www.pnn.de/potsdam/coronakrise-im-bergmann-klinikum-der-ausbruch/25757776.html

Passwort-Audits

Seit vielen Jahren beobachten wir problematische Trends bei der Verwendung von Passwörtern. Ob bei Incident Response Einsätzen oder bei Penetrationstests – zu schwache Passwörter sind in den heutigen IT-Umgebungen noch viel zu häufig der entscheidende Knackpunkt, der zwischen Erfolg und Misserfolg eines Angriffs entscheidet.

Das wissen auch die Angreifer, und so ist wohl jeder über das Internet erreichbare Server ständigen Brute-Force-Angriffen ausgesetzt. Teilweise entwendet Schadsoftware auch nach einem erfolgreichen Angriff weitere Active Directory Passwort-Hashes, um zusätzliche Zugriffsmöglichkeiten in der Zukunft zu sichern, wie Anfang des Jahres bei Trickbot beobachtet wurde.

Leider bilden Passwörter aber noch bei vielen Systemen und Anwendungen den einzigen Schutz vor unbefugten Angreifern. Die im Windows Active Directory eingebauten Komplexitätsregeln bieten nur eine geringe Hilfestellung bei der Wahl eines sicheren Passworts und sind in der Praxis nicht ausreichend.

Auch wo theoretisch die Einführung von 2-Faktor-Authentifizierung möglich wäre, gestaltet sich die praktische Umsetzung oft schwieriger als erhofft und wird daher verschoben.

Um Kunden einen Überblick über die Passwort-Qualität der von den eigenen Mitarbeitern verwendeten Passwörter zu geben, führt HiSolutions deswegen praktische Prüfungen der Passwortqualität durch. Dafür verfügen wir über ein Labor mit Spezialhardware für das Durchführen von hochparallelisierten Angriffen zur Ermittlung von Kennwörtern. Das System wurde in einer Vielzahl von Penetrationstests und Passwort-Prüfungen erfolgreich eingesetzt. Der Angriffsprozess wird dabei stetig weiterentwickelt und an neueste technische und organisatorische Erkenntnisse angepasst. Das System ermöglicht es, mehrere hundert Milliarden Password-Kandidaten pro Sekunde auszuprobieren.

Bei einer praktischen Prüfung der Passwortqualität werden die Passwort-Hashes von den Domänen-Controllern extrahiert und auf das Spezialsystem bei HiSolutions übertragen. Dort wird dann versucht, in vorgegebener Zeitspanne so viele Passwörter wie möglich zu ermitteln. Bei Bedarf, z.B. wenn die Daten das Netzwerk unter keinen Umständen verlassen dürfen, kann das Spezialsystem der HiSolutions auch in die Räumlichkeiten des Auftraggebers transportiert und dort angeschlossen werden.

Dazu werden unter anderem eine Vielzahl an Wörterbüchern, öffentlichen Passwort-Listen, speziellen Passwort-Regeln und -Masken und eine Kombination verschiedener Angriffsmethoden verwendet. Die verwendeten Regelwerke und Angriffsmethoden werden in Abhängigkeit von den erzielten Ergebnissen kontinuierlich manuell nachjustiert. Zudem werden auftraggeberspezifische Informationen wie beispielsweise spezielle Wörterbücher und bereits ermittelte Passwörter in die weiteren Angriffe einbezogen.

Die Ergebnisse der Prüfung werden im Anschluss ausgewertet und bewertet. Die daraus getroffenen Einschätzungen und Ergebnisse werden mit geeigneten Handlungsempfehlungen zur Verbesserung der organisatorischen und technischen Vorgaben für den Passworteinsatz in einem Prüfbericht dokumentiert. Der Auftraggeber erhält zusätzlich die Liste der Accounts mit gebrochenen Passwörtern, damit diese im Anschluss geändert werden können. Die gewonnenen Klartext-Passwörter werden aus Datenschutzgründen und gegebenenfalls enthaltenen sensiblen Daten grundsätzlich nicht offengelegt. Alle Passwort-Hashes und Klartext-Passwörter werden nach Abschluss des Projekts von den Systemen der HiSolutions sicher gelöscht.

Der Mensch bleibt dem Menschen ein Wolf – Cyber in Zeiten von Corona

Wäre es nicht schön gewesen? Inmitten all der schlechten Nachrichten und Prognosen wenigstens den Trost zu haben, dass die Welt sich zusammenrauft und wir uns nicht zusätzlich mit Cyberangriffen und sonstigen IT-Vorfällen das fragile Leben schwer machen… Leider ein Traum. Zwar haben einige wenige Angreifergruppen versprochen, Gesundheitsinfrastruktur bis auf weiteres auszusparen – auch Black-Hat-Hacker brauchen immerhin im Zweifel Beatmungsgeräte. Insgesamt ist jedoch die Anzahl der Angriffe gestiegen – und nicht wenige Kampagnen nutzen gerade die Unsicherheit, das Chaos und den Stress aus, um ihren bekannten illegalen Geschäftsmodellen Auftrieb zu verleihen. Wir kämpfen nun also an zwei Fronten. Die große, wichtige: Corona. Das allein bindet alle unsere Ressourcen. Dazu gilt es aber, auch an der „Cyber-Front“ die Verfügbarkeit unserer kritischen Infrastrukturen sicherzustellen. Und das sind mehr (und andere), als wir das gemeinhin auf dem Schirm haben: Gesundheitsämter, Lieferdienste, Pflegeheime, Hersteller von Medizintechnik, Supermärkte, Logistikbranche, … 

Tun wir unseren Teil, um die Funktionsfähigkeit unserer Gesellschaft gerade auch in Zeiten des notwendigen Lockdown aufrechtzuerhalten. Die Security kann und muss ihren Teil hierzu beitragen.

Ich weiß, wo Du online Geld verdienst: Cyber-OK lernt dazu

Ransomware ist seit vielen Monaten die größte Geißel der IT – und zumindest derjenigen Menschen, die für diese verantwortlich sind. Erst letztens hatten wir berichtet, dass Emotet und Co. dazugelernt haben und statt mit dummen Standard-E-Mails in schlechter Übersetzung, nun frühere Kommunikationsstränge wiederverwerten, um so die Klickrate auf die Malware deutlich zu erhöhen. Unterdessen hat die im Hintergrund die Geschäftsprozesse spinnende organisierte Cyber-Kriminalität (Cyber-OK) anscheinend gelernt, dass es noch weitere gemeine Hebel gibt, um Opfer zur Zahlung zu bewegen. Es gilt schließlich für die Angreifer, die empfindlichste Stelle eines Unternehmens zu finden und auszunutzen. Denn je mehr Unternehmen auf starke Backup-Konzepte mit schreibgeschützten Sicherungen und realistischen, regelmäßigen Restoretests umstellen, desto mehr bewegt sich das Wettrüsten in Richtung anderer Erpressungsvektoren.

Mit salamitaktikhafter Veröffentlichung gestohlener Informationen haben Erpresser ebenfalls bereits gedroht (teils erfolgreich, teils nicht). Was lässt sich – möglichst (teil-)automatisiert, denn das Ganze soll ja skalieren – einem Unternehmen außer Datenkidnapping noch antun? Nun wurde eine weitere Masche in freier Wildbahn gesichtet: Für Publisher – „Verlage“, wie es in der alten Welt heißt – ist das Wertvollste die Schnittstelle zu ihren Anzeigenkunden, heutzutage meist vermittelt über Internetgiganten wie Google. Statt also die Webserver in Geiselhaft zu nehmen, haben Angreifer begonnen, die Anzeigen auf den Seiten derart oft klicken zu lassen, dass dies bei Google, Facebook & Co. als Werbemissbrauch gewertet wird und die dortigen Sicherheitsmechanismen den Werbeträger automatisch sperren. Bei Wiederholung droht sogar eine permanente Verbannung von der Werbeplattform – mithin der Entzug der Existenzgrundlage.

Selbstverständlich bietet die freundliche Gang von nebenan da zufälligerweise ein „Traffic Management“ an, das sich gegen Einwurf geeigneter Bitcoins gerne um dieses Problem kümmert und den Betrug-Betrug umgehend beendet.
Auf eine Art ist dies alles in der analogen Welt schon da gewesen. Überträge in die digitale ergeben trotzdem immer wieder neue und überraschende Gemengelagen.

https://krebsonsecurity.com/2020/02/pay-up-or-well-make-google-ban-your-ads

Dass Eingeweihte dies bereits seit langem wussten, dokumentiert sehr schön dieser Blog-Post von Security-Guru Bruce Schneier inklusive der Kommentare:

https://www.schneier.com/blog/archives/2020/02/crypto_ag_was_o.html