Kategorie: Themen

SD-Speicherkarten
Advisories, Ransomware

Schutz gegen Ransomware: HiSolutions Selbsthilfe Offline-Backup

von Enno Ewers, Clara Eichel, Daniel Jedecke & Andreas Salm

Ransomware ist und bleibt die größte IT-Bedrohung für Unternehmen und öffentliche Einrichtungen. Alle Daten eines digitalen Systems können im Angriffsfall verschlüsselt werden – das schließt Sicherungskopien mit ein. Häufig werden diese sogar zuerst vom Angreifer gelöscht, gesperrt oder manipuliert. 

Beim klassischen Backup ist das oberste Ziel die schnelle Wiederherstellbarkeit für „normale“ Fehlfunktionen, daher sind die Backup-Daten oft „live“ im Zugriff durch die IT-Infrastruktur – und damit auch durch den Angreifer. Ein Ransomware-sicheres Backup verweigert dem Angreifer diesen Zugriff.

Aktuell ist die Gefahr durch HAFNIUM/ProxyLogon besonders groß.

Unser Selbsthilfe-Dokument Offline-Backup soll praktische Möglichkeiten zur Umsetzung insbesondere für kleine und mittlere Unternehmen aufzeigen.

HiSolutions Selbsthilfe Offline-Backup (v1.1, leicht geschärft):Herunterladen
Advisories, Hafnium, Incidents

HiSolutions entdeckt neue HAFNIUM/ProxyLogon IoCs

von Daniel Jedecke, David Fuhr und Vincent Rockenfeld

For English version of this advisory, please see here.

Bei der großen Menge an forensischen Untersuchungen zum Thema HAFNIUM/ProxyLogon, die wir aktuell durchführen, haben wir in mehreren Fällen gesehen, dass die Microsoft-Tools (Skripte bzw. Safety Scanner aka MSERT) nichts finden, da im HttpProxy-Log kein ProxyLogon zu sehen war, während der Zugriff im ECP Activity Log nachvollziehbar war.

Hier die Indikatoren für eine Kompromittierung (IoCs):

./ECP/Activity/ECPActivity_39844_20210303-1.LOG: 2021-03-03T06:43:32.531Z ,EX01, ,S:FE=EX01.FOOBAR.LOCAL;S:URL=https://ex01.foobar.local:444 /ecp/proxyLogon.ecp (https://owa.foobar.com/ecp/y.js);S:Bld=15.1.2106.2;S:ActID=def0-b0e6-2342-5e2c-23a8ff1962a1;Dbl:WLM.TS=0

./ECP/Activity/ECPActivity_39844_20210303-1.LOG: 2021-03-03T06:43:32.963Z, EX01,Request,S:PSA= administrator@foobar.com ;S:FE=EX01.FOOBAR.LOCAL;S:URL=https://ex01.foobar.local:444 /ecp/proxyLogon.ecp (https://owa.foobar.com/ecp/y.js)

Mit folgendem (Linux-/UNIX-)Befehl lassen sich die Protokolle auf die interessanten Einträge hin durchkämmen:

grep -ir “proxylogon“ ./ECP/Activity | sort -n

Um den Austausch von Researchern zu fördern und damit sich andere schneller schützen können, haben wir unsere Erkenntnisse auch auf Twitter geteilt. Siehe z. B. https://twitter.com/Jedi_meister/status/1372287075547017218

Bitte beachten Sie weiterhin unsere stetig aktualisierte HAFNIUM/ProxyLogon Selbsthilfe und unsere Empfehlungen zum Monitoring.

Advisories, Hafnium, Incidents

Hafnium – Eine Hilfestellung zur Überwachung Ihrer Systeme mit Loki

Da die Schwachstellen bereits durch mehrere unterschiedliche Gruppen ausgenutzt wird, reicht es aktuell nicht aus, nur nach einer bestimmten Malware oder Webshell zu suchen. Aus diesem Grund hat das BSI eine Übersicht veröffentlicht, welche weiteren Analysen auf den Systemen durchgeführt werden sollten.

Zur Vereinfachung der Anwendung haben wir uns entschlossen, Ihnen eine Hilfestellung bei der Nutzung des Scanners Thor-Lite zu geben, welcher ebenfalls in der Hilfe des BSI erwähnt wurde. Zudem verweisen wir auf einen guten Artikel zur Überprüfung Ihres Active Directories. Bitte beachten Sie auch die immer die aktualisierte „Selbsthilfe„.

UPDATE vom 24.03.2021: Empfehlung zur Dauer der Überwachung der Systeme nach Kompromittierung durch ProxyLogon ergänzt (12 Monate).

UPDATE vom 02.08.2022: Aufgrund der Lizenzbedingungen Scanner Thor entfernt, Scanner Loki empfohlen.

HiSolutions-Überwachen Ihrer SystemeHerunterladen

Feedback ist gerne erwünscht. Aufgrund der Kritikalität der Schwachstelle haben wir uns entschlossen, alle Informationen hierzu als TLP-White zu veröffentlichen. Das Dokument ist zudem lizenziert unter einer Creative Commons Namensnennung 4.0 International Lizenz.

Advisories, Hafnium

HAFNIUM/ProxyLogon bei Microsoft Exchange: Hilfe zur Selbsthilfe

[GTranslate]

UPDATE vom 24.03.2021: Empfehlung zur Dauer der Überwachung der Systeme nach Kompromittierung durch ProxyLogon ergänzt (12 Monate).

Aktualisierte HiSolutions-Selbsthilfe-HafniumHerunterladen

English version is here.

Feedback ist gerne erwünscht. Aufgrund der Kritikalität der Schwachstelle haben wir uns entschlossen, alle Informationen hierzu als TLP-WHITE zu veröffentlichen. Das Dokument ist zudem lizenziert unter einer Creative Commons Namensnennung 4.0 International Lizenz.

Für jeweils aktuelle Infos abonnieren Sie auch gerne unseren monatlichen Cybersecurity Digest.

UPDATE vom 17.03.2021: Wir haben die HAFNIUM-Selbsthilfe auf den neusten Stand gebracht und Tool- und Maßnahmenempfehlungen geschärft. Angesichts der zu erwartenden Angriffe über abgeflossene E-Mails und Kontakte haben wir auch unsere Empfehlungen zur Sensibilisierung vor Phishing-Angriffen konkretisiert.

UPDATE vom 14.03.2021: Wir haben am Wochenende parallel zur Incident Response weiteren Research betrieben und uns mit vielen Leuten ausgetauscht. Wir haben erste Erkenntnisse, dass die Angreifer Dateiberechtigungen verändern, um das Installieren von Patchen zu verhindern. Zudem stellen wir vermehrt Ransomware-Angriffe fest.

Auch haben wir ein Update bezüglich des Microsoft Support Emergency Response Tools (MSERT) eingearbeitet. Obwohl MSERT für diesen Anlass angemessen ist, raten wir aktuell zur Vorsicht bei der Nutzung. Das Tool löscht u. U. Shells und kann die vollständige Bereinigung nicht sicherstellen und die Forensik erschweren.

Zudem haben wir nun auch ein Dokument veröffentlich, um mittels Thor Lite die Systeme zu untersuchen und eine grundlegende Überprüfung des Active Directory durchzuführen.

UPDATE vom 12.03.2021 Teil 2: Wir haben die Maßnahmen (auch nach einer möglichen Kompromittierung) umfangreich angepasst. Sobald wir mehr Informationen über die aktuell verteile Ransomware haben werden diese noch nachsteuern. Das BSI hat seine Warnmeldung heute ebenfalls aktualisiert.

UPDATE vom 12.03.2021: Wir haben das Dokument erneut aktualisiert. Feedback gerne wieder an uns. Zudem haben wir einen Verweis auf den Datenschutz eingebaut sowie die Maßnahmen konkretisiert.

UPDATE vom 10.03.2021: Vielen Dank für das viele Feedback und die Anregungen. Wir haben das Dokument überarbeitet und die neusten Empfehlungen des BSI, Erkenntnisse aus der Forensik sowie einige Vereinfachungen im Bereich Monitoring eingearbeitet. Feedback weiterhin gerne an uns oder per Twitter an (@Jedi_meister).

Um unseren Kunden einen ersten Leitfaden zum Umgang mit der HAFNIUM/ProxyLogon-Thematik an die Hand zu geben, haben wir einen Leitfaden „Hilfe zur Selbsthilfe“ herausgebracht. Dieser kombiniert die Empfehlungen des BSI, unsere fachliche Expertise sowie Informationen des Herstellers Microsoft.

Der Leitfaden soll als erster Indikator dienen und eine einfach zu befolgende Checkliste darstellen. Wir aktualisieren das Dokument laufend mit den neusten Erkenntnissen aus unseren Fällen.

Aufgrund der Kritikalität der Schwachstelle verteilen wir den Leitfaden kostenfrei. Sofern Sie Microsoft Exchange nutzen, prüfen Sie bitte, ob Sie bereits alle Schritte durchgeführt haben. Beachten Sie, dass Microsoft am 09.03.2021, dem regulären Patch Tuesday, weitere kritische Lücken in seinen Produkten geschlossen hat!

Weitere Informationen unter:

Advisories, Hafnium

HAFNIUM/ProxyLogon: Akute Angriffswelle auf Microsoft Exchange

Seit in der Nacht zum Mittwoch, 3. März 2021, das Microsoft Threat Intelligence Center (MSTIC) über eine akute Angriffswelle auf Microsoft Exchange Server informiert hat, haben IT-Organisationen weltweit alle Hände voll zu tun, die ausgenutzten Schwachstellen (inkl. ProxyLogon) zu schließen, eine mögliche Kompromittierung abzuchecken und ggf. Aufräumarbeiten durchzuführen.

Auch wenn Microsoft umgehend Out-of-band Updates veröffentlich hat, wurde schnell klar, dass die vier beschriebenen Schwachstellen in Kombination bereits für zielgerichtete Angriffe verwendet wurden und vielerorts die Möglichkeit boten und bieten, Daten abzugreifen oder weitere Schadsoftware zu installieren.

https://blogs.microsoft.com/on-the-issues/2021/03/02/new-nation-state-cyberattacks/

Zu den Sofortmaßnahmen gehört neben dem umgehenden Einspielen der Patches die sofortige Deaktivierung der über HTTPS erreichbaren Dienste (OWA, ECP, UM, VDir, OAB). Eine erste Überprüfung auf Kompromittierung kann mittels eines von Microsoft bereitgestellten Scriptes oder durch Scannen des Microsoft Exchange Server mit dem Microsoft Support Emergency Response Tool (MSERT) erfolgen. Um die Möglichkeit der Angriffsdetektion zu verbessern, sollte außerdem die Protokollierung der Exchange-Server und des Active Directory ausgeweitet werden.

Im Falle der Detektion einer Kompromittierung (z. B. einer Webshell) müssen das System und je nach Berechtigungen ggf. weitere Systeme wie etwa das Active Directory näher untersucht werden. Hier muss darauf geachtet werden, ob es zum besagten Zeitraum zu Kontenerstellung, vermehrten Zugriffen oder ähnlichen Auffälligkeiten gekommen ist.

Unsere Handlungsempfehlungen

Weitere Ressourcen

Kritis

Hold My BIA: Vergiftet oder erfroren – Welche ist die KRITISchste Dienstleistung?

Zurzeit lohnt aus dem Gesichtspunkt KRITIS ein langer und tiefer Blick in die USA, wo sich innerhalb kürzester Zeit zwei Szenarien ereigneten, die einige jüngst noch als Panikmache bezeichnet hätten: Während dieser Tage ein Wintereinbruch in Texas und Umgebung Millionen von Haushalten von der Stromversorgung abschneidet, konnte Anfang Februar ein Angriff auf die Wasseraufbereitung in Florida abgewehrt werden, der potenziell das Trinkwasser der Kleinstadt Oldsmar hätte vergiften können.

Aus Security-Sicht scheint vor allem der zweite Fall interessant, aber es macht durchaus Sinn, beide im Vergleich anzuschauen. In der texanischen Katastrophe kommen mindestens vier Dinge zusammen: Unsere wohlbekannte Abhängigkeit vom Strom als der Grund-kDL (kritische Dienstleistung) des Informationszeitalters, die ebenfalls wohlbekannt wackelige Infrastruktur in diesem Bereich in den USA und anderswo, die Zunahme der Volatilität in komplexen Systemen, die wir zu sehr aus dem Gleichgewicht bringen (Stichwort Klimawandel) sowie möglicherweise auch ein stückweit der Hochmut lokaler Machthabender, zu meinen, das eigene Grid besser getrennt vom Rest des Landes betreiben zu können – so viel Föderalismus gibt es nicht einmal bei uns. Trotzdem müssen wir zugeben, dass es nicht möglich ist, eine Infrastruktur gegen jedes „Black Swan“-Risiko abzusichern. Oder sollte Nigeria jetzt schneesichere Kraftwerke bauen? Die Notfallbehandlung im südlichen US-Bundesstaat scheint wiederum, soweit sich das aus der Ferne beurteilen lässt, durchwachsen zu laufen.

Oldsmar hingegen scheint Stoff für Horrorfilme zu bieten: Ganze Kleinstadt ausgelöscht durch böse Terror-Hacker! Also fast! Dabei wird hier eher umgekehrt ein Schuh draus: Dass auch im Bereich Wasser Fernwartung inzwischen die Regel ist und Teamviewer und Co. nicht allerorten sicher konfiguriert sind, hat sich herumgesprochen. Insofern war das Szenario erwartbar – und wurde auch erwartet und entsprechend behandelt. Auf IT-Ebene ist der Angriff zwar geglückt, wurde aber umgehend detektiert (durch Admin) und wäre auch sonst aufgefallen, bevor ein Schaden hätte entstehen können (durch Technik und Prozesse). Aus Sicherheitssicht also ein nützlicher Wakeup-Call oder wenigstens Reminder – aber der unfreiwillige Red-Teaming-Test wurde in jeder Hinsicht bravourös bestanden.

Also doch den Blick wieder nach Texas: Wir müssen auch in der IT aufpassen, dass wir uns in möglichst wenige Situationen hineinmanövrieren, wo die Komplexität außen steigt (Was ist unser „Klimawandel“?*), während wir innen zu viel Energie mit Altlasten („technical debt“) binden. Auch das wird immer wieder einmal schiefgehen – siehe diese Digests der letzten Jahre – aber wir sollten die Gesamttrajektorie im Blick behalten.

https://www.wired.com/story/oldsmar-florida-water-utility-hack/

* Siehe z. B. Lesetipp „Security, Moore’s law, and the anomaly of cheap complexity“.

Red Teaming

Nicht über den Jordan gehen: TIBER-EU

TIBER-EU ist das europäische Framework für Threat Intelligence-basiertes Red-Teaming. Der zugehörige EU Leitfaden beschreibt, wie Behörden und Unternehmen mit Threat-Intelligence- und Red-Team-Anbietern zusammenarbeiten können, um die Cyber-Resilienz zu testen und zu verbessern.

Das TIBER-EU Framework

Bei Tests nach TIBER-EU werden Taktiken, Techniken und Vorgehensweisen (TTPs, Tactics, Techniques and Procedures) realistischer Angriffe auf die kritischen Funktionen eines Unternehmens und seine zugrundeliegenden Systeme simuliert, welche auf maßgeschneiderter Threat Intelligence basieren.

Daher gibt es als Ergebnis auch kein „bestanden“ oder „nicht bestanden“. Viel mehrsoll der Test die Stärken und Schwächen aufdecken und dem Unternehmen zu einer höheren Stufe des Cyber-Reifegrads verhelfen.

Rollen

  • Blue Team – die Mitarbeiter:innen des Unternehmens, das im Scope des Tests ist und dessen Präventions-, Erkennungs- und Reaktionsfähigkeiten ohne ihr Wissen geprüft werden
  • Anbieter Threat Intelligence – ein Unternehmen, das das Spektrum möglicher Bedrohungen untersucht und das Unternehmen von außen auskundschaftet
  • Anbieter Red-Teaming – ein Unternehmen, das den simulierten Angriff durchführt
  • White Team: ein kleines Team im Zielunternehmen, das als einziges vom Test weiß und diesen gemeinsam mit dem TIBER-Cyberteam leitet und verwaltet
  • TIBER-Cyberteam – Team innerhalb der Behörde, das für die Überwachung des Tests verantwortlich ist und sicherstellt, dass er die Anforderungen des TIBER-EU-Frameworks erfüllt (wichtig für die gegenseitige Anerkennung der Tests)

Quellen

Der Leitfaden für die Beschaffung von TIBER-EU-Dienstleistungen enthält weitere Details zur Auswahl und Beschaffung der Dienstleistungen von Bedrohungsdaten- und Red-Team-Anbietern. Die TIBER-EU White Team Guidance erklärt, wie das Team, das den TIBER-Test verwaltet, innerhalb der Zielinstanz eingerichtet wird.

KMU

Es steht so mittel: Mittelstand und IT-Sicherheit

Im Zuge der Digitalisierung werden immer mehr Informationen digital gespeichert, bearbeitet und verteilt. Während in kleineren Unternehmen oft eher eine verhältnismäßig geringe Menge an Daten verarbeitet wird und davon ein Großteil immer noch analog, verarbeiten mittelständische und große Unternehmen Informationen heute meist vorwiegend digital. Durch die Integration und automatisierte Verwaltung von – häufig sensiblen – Daten in Netzwerkstrukturen ergeben sich zwangsläufig Schwachstellen, die die Sicherheit der Informationen gefährden.

Die steigende Komplexität von Prozessen und Anwendungen führt fast unvermeidbar zu Fehlern in der Entwicklung, Wartung oder Handhabung. Zwar sind nicht alle Fehler sicherheitskritisch: Häufig greifen die Schutzmechanismen von Betriebssystemen und verwendeter Software, bevor ein Schaden entstehen kann. Doch mit der wachsenden Abhängigkeit von funktionierenden und vertrauenswürdigen Systemen wachsen auch die Risiken für deren Anwender*innen. 

Besondere Gefährdung des Mittelstands

Dabei sind mittelständische Unternehmen bzw. KMU besonders gefährdet: Den Grundstein hierfür legt die im Unternehmen verwendete IT-Infrastruktur. Sehr kleine Unternehmen, beispielsweise Einzelunternehmen, haben in der Regel keine eigens eingerichtete IT-Infrastruktur. Hier kommen häufig etwa Router zum Einsatz, wie sie auch in privaten Haushalten verwendet werden, um eine Verbindung zum Internet zu ermöglichen. Kommunikationswege wie etwa E-Mail oder eine Webseite werden meist von großen Anbietern wie Google Mail oder Strato bereitgestellt. Der Vorteil hierbei ist ein geringer Aufwand für die Unternehmen und eine relativ hohe Sicherheit durch die Verwendung von Systemen professioneller Anbieter, da diese starke Sicherheitskonfigurationen für ihre Geräte (etwa eine FritzBox) und Systeme (zum Beispiel Webhosting oder Webmail) bereitstellen und in der Regel auch die nötigen Ressourcen dazu haben. 

Nachteile bestehen in der Abhängigkeit vom Anbieter beziehungsweise von Dienstleistenden, die etwa bei der Einrichtung und Instandhaltung kontaktiert werden müssen. Zusätzlich ist eine derartig aufgebaute IT-Infrastruktur meist nicht sehr flexibel in ihren Konfigurationsmöglichkeiten oder bietet irgendwann nicht mehr alle Funktionen, die ein Unternehmen sich wünscht. Manche Unternehmen können oder wollen auch keinen Webmail-Anbieter einsetzen, da sie sich Sorgen um den Datenschutz machen, etwa wenn es sich um eine Arztpraxis handelt, die empfindliche Informationen verarbeiten muss.

Der nächste Schritt ist also der Einsatz flexiblerer IT-Systeme in einer gegebenenfalls wachsenden IT-Abteilung. Sich mit diesen Systemen auseinanderzusetzen stellt jedoch die meisten KMU vor Probleme. In diesem Fall wenden sich Unternehmen häufig an externe Dienstleister. Zwar wird dadurch das Unternehmen anpassungsfähiger in seiner IT. Aber meist ist der Fokus weder bei den Unternehmen noch bei ihren externen Dienstleistern auf IT-Sicherheit ausgerichtet, was zur Folge hat, dass potentielle Angriffswege entstehen, die ein großer Anbieter möglicherweise geschlossen hätte.

Große Unternehmen brauchen ein hohes Maß an Flexibilität und haben in der Regel auch eine entsprechende IT-Abteilung. Sie sind sich der Tragweite einer gut ausgeprägten IT-Sicherheit eher bewusst und besitzen im Zweifel die notwendigen Ressourcen, diese einzurichten und zu warten. Und wenn ein externer Dienstleister zu Rate gezogen werden muss, wird dieser meist entsprechende Schwerpunkte auf IT-Sicherheit vorweisen können.

Risiken für KMUs

Damit sind KMU von den drei vorgestellten Unternehmensgrößen am schwächsten aufgestellt, wenn es um ihre IT-Sicherheit geht, da sie zwar in ihren digitalen Unternehmensprozessen vielseitiger werden müssen, gleichzeitig aber aus unterschiedlichen Gründen selten den notwendigen Schwerpunkt auf IT-Sicherheit legen können.

IT-Sicherheit in Abhängigkeit der Unternehmensgröße [Taege 2020]

Es müssen daher Maßnahmen ergriffen werden, die sowohl von technischen Aspekten einer Offenlegung der Schwachstelle (Disclosure) abhängig sind als auch von der Kommunikation mit möglichen Betroffenen, beispielsweise Kunden. Gleichzeitig muss gegebenenfalls die Öffentlichkeit informiert werden, bzw. die Bekanntmachung der Schwachstelle ist als Teil eines angemessenen Krisenmanagements zu etablieren. Häufig haben KMU keine ausreichende Erfahrung im Bereich der IT-Sicherheit. Dieser Mangel an Erfahrung erschwert den Umgang mit den Prozessen, die kritische Schwachstellen mit sich bringen, da die Unternehmen dadurch schlecht auf Sicherheitsvorfälle vorbereitet sind. 

Formen von Schwachstellen

Im Bereich der Informationstechnik gibt es ein sehr breites Spektrum an möglichen Schwachstellen und Systemen, in denen diese auftauchen können. Vulnerabilities können sowohl in Hard- als auch in Software vorhanden sein – und sie können die unterschiedlichsten Ursachen haben: Diese erstrecken sich von veralteten Lizenzen oder Systemen über Verschleißerscheinungen eingesetzter Hardware bis hin zu Konfigurationsfehlern bei der Einrichtung oder Wartung. Die Möglichkeiten, einzelne schwerwiegende Schwachstellen in eingesetzten Systemen zu haben – beziehungsweise eine Kombination aus mehreren kleineren Schwachstellen, die zusammen eine kritische ergeben –, sind nahezu unüberschaubar vielfältig. Daher werden diese in der Mehrheit der Fälle, sofern sie keine direkt ersichtlichen gravierenden Auswirkungen haben, nicht als solche entdeckt.

Um eine repräsentative Übersicht der häufigsten Sicherheitsvorfälle in diesem Bereich wiedergeben zu können, wurden Daten der HiSolutions AG ausgewertet. Hierbei wurden die betreuten Sicherheitsvorfälle sowie Penetrationstests der Jahre 2016 bis 2019 nach der Vorgabe der OWASP Top Ten kategorisiert und anschließend jeweils nach Häufigkeit des Aufkommens und Kritikalität der entsprechenden Kategorie bewertet.

So ist beispielsweise die Kategorie „Mangelnde Systempflege“, die sich auf ein unzureichendes Patchmanagement bei Webservern oder die Verwendung trivialer Passwörter bezieht, 2019 in 56,7% aller Fälle bei Kunden der HiSolutions AG nachgewiesen worden. 

Prävalenz der Schwachstellentypen nach Jahren (HiSolutions Schwachstellen-Report 2020)

Es kann beobachtet werden, dass besonders Findings innerhalb der Kategorien der Authentifizierung von Nutzer*innen, der Verwendung veralteter Komponenten, der mangelnden Systempflege sowie einer ungeeigneten Sicherheitsarchitektur (beispielsweise eine unzureichende Konfiguration von Protokollen oder fehlende Konzepte im Netz-Management) kritische Schwachstellen für ein Unternehmen mit sich bringen.

Prävalenz der Schwachstellentypen (HiSolutions Schwachstellen-Report 2020)

Umgang mit Security in KMUs

Die Risiken für KMU, die von Schwachstellen in der IT-Sicherheit ausgehen, sind enorm vielfältig. Sie reichen von geringen Gefährdungen, etwa der Verlangsamung alltäglicher Prozesse und Aufgaben, bis hin zu existenzgefährdenden Krisen. Dabei steigert der Einsatz jedes Systems, welches in der Infrastruktur eingesetzt wird, die potentiellen Möglichkeiten eines Auftretens einzelner Schwachstellen beziehungsweise einer Kette von Schwachstellen exponentiell. Unternehmen betreiben in der Regel deutlich zu wenig Aufwand betreiben, mögliche Schwachstellen frühzeitig zu erkennen oder diese zu eliminieren, wodurch sie im Großteil der Vorfälle nicht ausreichend vorbereitet sind.

Es lässt sich festhalten, dass die Hürden im Umgang mit Vulnerabilities und eventuell daraus resultierender Vorfälle, im Speziellen was die interne und externe Kommunikation angeht, sehr vielfältig sind und ohne externe Hilfe nicht angemessen bewältigt werden können. Unternehmen, beziehungsweise Entscheidungsträger*innen, die mit der Thematik der IT-Sicherheit nicht vertraut sind, treffen häufig Entscheidungen, die mehr schaden als nutzen. Das Sparen von Ressourcen bei der Einrichtung und Wartung der eigenen IT-Infrastrukturen, bei der Auswahl externer Dienstleister oder beim Aufbau einer eigenen IT-Abteilung hat in der Regel negative Folgen für ein Unternehmen, die unter Umständen später nur schwer auszubessern sind.

Eine frühzeitige Auseinandersetzung mit den unternehmenseigenen Prozessen sowie eine zielführende Verteilung von Expertisen und Aufgaben haben einen beträchtlichen Anteil an der Sicherheit eines Unternehmens. Dafür muss speziell die IT-Sicherheit mehr in den Fokus rücken und mit entsprechenden Ressourcen gefördert werden. Hierzu gehören unter anderem die regelmäßige Auseinandersetzung mit möglichen Schwachstellen eingesetzter Systeme, die Schulung sämtlicher Mitarbeitenden sowie die Einführung von Prozessen und Maßnahmen für den Ereignisfall. 

Fazit

Es muss davon ausgegangen werden, dass Software – egal ob eigens entwickelt oder von Drittanbietern – Bugs hat. Und solange Software Fehler beinhaltet, werden diese auch Schwachstellen enthalten. Wenn eine solche Schwachstelle entdeckt wird und ein Unternehmen davon erfährt, sollte die Entdeckung gründlich untersucht werden, auch oder gerade dann, wenn es an einem detaillierten technischen Verständnis der Problematik mangelt. Die Idee, sich gegen den Melder der Schwachstelle zu wehren, indem Strafverfolgungsbehörden oder Anwälte eingeschaltet werden, ist zwar nicht in jedem Fall zwingend falsch (etwas wenn der Verdacht der Erpressung besteht). Es sollte jedoch eine angemessene und ausreichende Kommunikation mit Meldenden stattfinden, die deren Motivationen herausstellt und prüft, ob entsprechende rechtliche Schritte wirklich notwendig sind. Im schlimmsten Fall können verfrühte Schritte dieser Art zu negativer Aufmerksamkeit in der Öffentlichkeit führen, die unter Umständen schädlicher für das Unternehmen sein kann als die initiale Schwachstelle. Oder aber es werden wohlmeinedne Sicherheitsforscher*innen vergrault, die einen Beitrag zur Security der Organisation hätten leisten können und wollen.

Unabhängig von der Motivation von Melder*innen sollte ein Unternehmen bei kritischen Schwachstellen stets die Verantwortung selbst übernehmen. Eine transparente Kommunikation, extern und intern, die die gefundene Schwachstelle annimmt und ein rasches Handeln vermittelt, hilft dabei das Vertrauen bei Kund*innen, Mitarbeitenden oder dritten Interessengruppen zu fördern und beweist Integrität. Außerdem beugt sie eventuellen Annahmen, die Sicherheits-Situation sei kritischer als sie tatsächlich ist, vor. Die richtige Balance zwischen offener Kommunikation und Diskretion ist schwierig, aber essentiell.

Praktische Hinweise finden Sie auch in unserer Checkliste: https://www.hisolutions.com/detail/checkliste-zur-cybersecurity-fuer-kleine-und-mittlere-einrichtungen

Phishing

Phishing per SMS – Smishing-Angriffe häufen sich

Von Thomas Fischer und Jann Klose, HiSolutions AG.

In den letzten Tagen gehen vermehrt verdächtige SMS-Nachrichten bei Mitarbeiterinnen und Mitarbeitern von Unternehmen und Behörden ein, mit Texten wie „Ihr Paket wurde verschickt. Bitte überprüfen und akzeptieren Sie es. [Link]“.

Bei dieser Art von SMS handelt sich um einen Phishingversuch per SMS, auch Smishing genannt. Dies bezeichnet einen Betrugsversuch, bei dem automatisiert oder gezielt SMS mit irreführenden Informationen versandt werden, um die Empfänger zur Herausgabe sensibler Daten zu verleiten.

Wie funktioniert Smishing?

Beim Smishing versenden die Täter SMS im Namen von vertrauenswürdigen Institutionen wie Banken oder Telekommunikationsanbietern mit dem Vorwand eines fingierten Problems. Einige Beispiele sind:

  • Eine Bank meldet merkwürdige Aktivitäten auf dem Konto
  • Ein Dating-Service bestätigt die vermeintliche Eröffnung eines Premiumkontos
  • Der Telefonanbieter erhebt auf einmal Extragebühren für gewisse Leistungen
  • Man erhält eine Rückzahlung aus einem Bonusprogramm
  • Man wird beschuldigt, Zahlungen nicht getätigt zu haben
  • Ein Paket wurde verschickt, und es gibt Probleme mit der Zustellung

Alle SMS sollen dazu verleiten, einen Link anzuklicken und dort dann Daten einzugeben. Entweder wollen die Cyberkriminellen persönliche Daten stehlen, die sie nutzen können, um sich zu bereichern, oder die Nutzerinnen und Nutzer werden verleitet, Malware herunterzuladen, die sich permanent auf dem Smartphone installiert.

Wie kann ich mich gegen Smishing schützen?

Der Schutz gegen Smishing ist ganz einfach: Tatsächlich muss man gar nichts tun, um sicher zu sein. Der Angriff kann nur Schaden anrichten, wenn der Köder geschluckt wird. Wird die SMS einfach löscht, kann nichts weiter passieren.

Woran kann ich Smishing erkennen?

Was ist zu beachten, um solche Angriffe zu bemerken? Einige Faustregeln helfen:

  • Kein Finanzinstitut oder Händler sendet eine Textnachricht, um Kontodaten zu erfragen oder zur Bestätigung der PIN aufzufordern. Wer sicher gehen will, ruft Bank oder Händler direkt an, um nachzufragen.
  • Kein Klicken auf einen Link oder eine Telefonnummer in einer Nachricht, bei der man sich nicht sicher ist.
  • Ausschau halten nach verdächtigen Nummern, die nicht wie typische Telefonnummern anmuten, z. B. „5000“. Diese Nummern verweisen oft auf E-Mail-zu-SMS-Services, die häufig von Betrügern genutzt werden, um die Preisgabe der echten Telefonnummern zu vermeiden.
  • Möglichst keine Speicherung von Kreditkarten- oder Banking-Informationen auf dem Smartphone – oder aber die Verwendung eines sicheren Passwortsafes. Wenn die Informationen gar nicht erst vorhanden sind, können Diebe sie auch nicht stehlen, selbst wenn sie Malware auf dem Handy installieren.

Meldung von Smishing-Angriffen, um auch andere Benutzer zu schützen.

Beim Smishing – genau wie beim Phishing – geht es darum, möglichst viele Nutzerinnen und Nutzer hinters Licht zu führen. Bei dieser Methode verlassen sich Kriminelle darauf, dass ein Teil der Opfer mitspielt und auf einen Link klickt oder Informationen preisgibt. Der einfachste Schutz vor solchen Angriffen ist tatsächlich, ganz einfach nichts zu tun. Diese Awareness muss sich allerdings möglichst weit verbreiten

Bitte warnen Sie andere Nutzer in Ihrer Organisation – zum Beispiel durch eine Meldung an den IT-Sicherheitsbeauftragten (IT-SiBe). Und sollte doch einmal ein Smishing / Phishing gegen Sie geklappt haben, kann die sofortige Meldung des Vorfalls helfen, Schäden von der Organisation abzuwenden.

Schematische Darstellung Decryption Oracle
Kryptographie

Von Decryption und Signing Oracles: Covert-Content-Angriffe auf E-Mail

Dieser Blog-Beitrag ist eine Zusammenfassung der Untersuchungen, welche von der Autorin im Rahmen einer Abschlussarbeit für den Studiengang Informatik/IT-Sicherheit durchgeführt wurden.

Mit der Entwicklung der Netzwerktechnologie ist die E-Mail zu einem unverzichtbaren Mittel für die tägliche Kommunikation geworden. Laut Untersuchungen der Radicati Group nutzten 2019 bereits über die Hälfte der Weltbevölkerung E-Mails. Viele sensible Informationen werden so ausgetauscht. Im geschäftlichen Kontext können das beispielsweise Liefervereinbarungen, Verträge verschiedenster Art oder vertrauliche Korrespondenz mit Kunden oder Geschäftspartnern sein. Im privaten Umfeld sind zum Beispiel personenbezogene Informationen, vertrauliche Korrespondenzen etc. nicht minder interessant für Internetkriminelle.

E-Mail-Sicherheit

E-Mail-Verschlüsselung und digitale E-Mail-Signatur schaffen im Idealfall Sicherheit für die Nutzer. So ist eine digitale E-Mail-Signatur mit einer Unterschrift im realen Leben vergleichbar. Durch das digitale Signieren einer E-Mail kann der Absender eindeutig identifiziert werden. Außerdem kann die Integrität der Nachricht sichergestellt werden. Das bedeutet, dass der Empfänger erkennen kann, ob die E-Mail unterwegs verändert wurde. Das Versenden einer E-Mail ist mit dem Verschicken einer Postkarte in der anlogen Welt vergleichbar. Die Postkarte wird in den Briefkasten geworfen, der Briefträger holt sie dort ab, und über verschiedene Stationen wird sie schließlich dem Empfänger zugestellt. Jeder, der an der Zustellung beteiligt ist, kann die Postkarte lesen. Beim Versand einer E-Mail ist es ähnlich. Standardmäßig werden E-Mails unverschlüsselt übertragen. Bis sie allerdings beim Empfänger zugestellt werden können, passieren sie viele verschiedene Mailserver und andere Netzwerksysteme. Jeder kann die unverschlüsselte E-Mail abfangen, zwischenspeichern oder mitlesen.

What’s up Johnny?

In 2019 stellten Müller et al. [1] in ihrer Veröffentlichung „Re: What’s up Johnny?“ die sogenannten Covert-Content-Angriffe auf E-Mail Verschlüsselungen und E-Mail Signaturen vor. Die Autoren zeigen, dass die Schutzziele Vertraulichkeit, Authentizität und Integrität einer E-Mail bei der Nutzung bestimmter E-Mail-Clients verletzt werden können.

Die Anfälligkeit der E-Mail Kommunikation in Bezug auf die Gewährleistung der Schutzziele wird durch die Angriffe belegt. Es sind verschiedene Angriffszenarien denkbar:

  1. Übertragung falscher Daten
    1. Impersonation
    2. Manipulation von Informationen
    3. Phishing
    4. Social Engineering
  2. Unbefugter Zugriff auf Daten
    1. Wirtschaftsspionage
    2. Verletzung der Privatsphäre

Die Covert-Content-Angriffe nutzen einerseits die Eigenschaften des MIME-Standards und andererseits HTML/CSS, um den Nutzer zu täuschen. Als Backchannel wird die Antwort-Funktion des E-Mail-Clients genutzt.

Es wird dabei zwischen zwei Angriffskategorien unterschieden: Decryption Oracle und Signing Oracle.

Decryption Oracle

Das Ziel des Angriffs im Sinne des Decryption Oracle ist es, den entschlüsselten Klartext über den Backchannel unbemerkt zu extrahieren. Müller et al. beschreiben, wie es einem Angreifer gelingt, (abgefangenen) Ciphertext in einer harmlosen E-Mail an das Opfer zu verstecken. Nutzt das Opfer die Antwort-Funktion des E-Mail-Clients wird es zum „Decryption Oracle“ und sendet unbewusst den versteckten, jedoch nun entschlüsselten Klartext an den Angreifer zurück.

Das Prinzip des Angriffs wird in Abbildung 1 dargestellt. Die Voraussetzung ist, dass der Angreifer Zugang zu der verschlüsselten Kommunikation zweier Parteien. Hierfür gibt es verschiedene Szenarien. Beispielsweise hat der Angreifer aufgrund eines schwachen, leicht zu erratenen Passworts, Zugang zu dem E-Mail-Konto auf dem E-Mail-Server. Eine weitere Möglichkeit ist, dass der Angreifer die verschlüsselte E-Mail mitliest und speichert, wenn der Nutzer diese über eine unverschlüsselte Verbindung vom Mail-Server abruft.

Abbildung 1: Covert-Content-Angriff gegen E-Mail-Verschlüsselung (Decryption Oracle)

Der Angreifer kann die verschlüsselten E-Mails jedoch nicht selbst entschlüsseln, denn er ist nicht im Besitz des privaten Schlüssels. Daher sendet er eine manipulierte E-Mail an einen der beiden Original-Kommunikationspartner. Dabei ist es unerheblich, ob es sich dabei um den ursprünglichen Sender oder Empfänger der E-Mail handelt. Denn die Verschlüsselung der E-Mail erfolgt beim Sender sowohl mit seinem eigenen öffentlichen Schlüssel als auch mit dem öffentlichen Schlüssel des Empfängers. Wie Abbildung 1 zeigt, besteht die manipulierte E-Mail aus zwei Teilen. Der erste Teil ist eine unverfängliche Nachricht, die das das Opfer zu einer direkten Antwort animieren soll. Um den Angriff erfolgreich durchführen zu können, ist der zweite Teil der Nachricht encω(m) für das Opfer unsichtbar. Antwortet das Opfer auf diese manipulierte E-Mail, dann wird der entschlüsselte Klartext m, als unsichtbarer Bestandteil der E-Mail zurück an den Angreifer gesendet.

Signing Oracle

Die zweite Angriffs-Kategorie verfolgt das Ziel, eine gültig signierte E-Mail durch den vom Opfer genutzten E-Mail-Client, welcher als Signing Oracle fungiert, zu erhalten. Abbildung 2 stellt das Prinzip des Covert-Content-Angriffs für das Signing Oracle dar. Die manipulierte E-Mail besteht hierbei wieder aus zwei Textteilen. Der erste, sichtbare und unverfängliche Teil, der zum Antworten animieren soll, und der zweite, versteckte Teil der Nachricht, der für weiterführende Angriffe genutzt werden soll. Im Kontext einer harmlos erscheinenden E-Mail an das Opfer wird dieser zweite Textteil mittels CSS-Conditional-Rules versteckt. So kann der Angreifer beeinflussen, dass die E-Mail je nach E-Mail-Client unterschiedlichen Text anzeigt. Da die digitale Signatur für die vollständige originale E-Mail gültig ist, kann die E-Mail durch den Angreifer für weitere Angriffe missbraucht werden. Beispielsweise kann der Angreifer sich per E-Mail als vertrauenswürdiges Mitglied des Unternehmens ausgeben, um dringende Überweisungen von ahnungslosen Mitarbeitern zu veranlassen.

Abbildung 2: Covert-Content-Angriff gegen E-Mail-Signatur (Signing Oracle)

Re-Evaluation

Seit der Durchführung der Tests sind mittlerweile ca. zwei Jahre vergangen. Daher wurden nun im Rahmen einer Re-Evaluation folgende Fragen beantwortet:

  1. Sind die Covert-Content-Angriffe auf die untersuchten Email-Clients weiterhin möglich?
  2. Falls nein, können die Gegenmaßnahmen durch Erweiterung der Angriffe umgangen werden?

Es wurden 22 E-Mail-Clients in die Untersuchung einbezogen. Davon unterstützen 19 Clients PGP-Verschlüsselung und -Signatur, 19 Clients S/MIME-Signatur und 18 Clients S/MIME-Verschlüsselung. Die Angriffe funktionieren bei vielen der getesteten E-Mail-Clients weiterhin. Die Re-Evaluation für die Signing Oracle-Schwachstelle ergab keine nennenswerte Veränderung im Vergleich zur Evaluation von Müller et al. [1]. Sämtliche Testcases der Evaluation als auch der Re-Evaluation sind auf Github veröffentlicht und können dort heruntergeladen werden [2].

Ergebnisse

Es sind 37% der S/MIME- und 32% der PGP-fähigen E-Mail-Clients als Signing Oracle angreifbar. Bei Müller et al. waren es 41% bzw. 32% der entsprechenden E-Mail-Clients. In Bezug auf die Decryption Oracle-Schwachstelle ist von Herstellerseite am meisten nachgebessert worden. Es existieren zwar nach wie vor E-Mail-Clients, bei denen es möglich ist, Klartext zu extrahieren, wenngleich deren Zahl um die Hälfte zurückgegangen ist. Insbesondere der Angriff für den Testcase 01-reply-mix-css.eml, der zum Ziel hat, den entschlüsselten Klartext vollständig zu verstecken, schlug bei allen E-Mail-Clients fehl. Die Hersteller haben teilweise die von Müller et al. vorgeschlagenen Gegenmaßnahmen gegen die Covert-Content-Angriffe umgesetzt. Die vollständige Ergebnisübersicht ist in der Tabelle 1 dargestellt.

Abschließend wurden verschiedene Modifikationen der Angriffe vorgenommen. War es im Rahmen der Re-Evaluation nicht mehr möglich, den Klartext vollständig zu verstecken, konnte dies durch eine Modifikation des Testcase 01-reply-mix-css.eml wieder realisiert werden. So ist es möglich, bei drei der S/MIME-fähigen und bei einem der PGP-fähigen Clients den entschlüsselten Klartext für den Nutzer unsichtbar zu gestalten. Dafür werden CSS-Regeln verwendet. HTML und CSS unterliegen einer ständigen Weiterentwicklung durch das World Wide Web Consortium (W3C). Es gibt immer noch E-Mail-Clients, die auch in der Antwort-E-Mail HTML/CSS unterstützen. Dies ist auch eine der Eigenschaften, die durch die reevaluierten Angriffe ausgenutzt wird. Daher ist es eine Frage der Zeit, bis neue Modifikationen, Schwachstellen in Bezug auf die Covert-Content-Angriffe aufzeigen.

Der Nutzer hat viele verschiedene Möglichkeiten, den Client nach seinen Wünschen und Bedürfnissen zu konfigurieren. Die E-Mail-Clients wurden in den Standard-Einstellungen getestet, aber die Re-Evaluation hat gezeigt, dass das Prinzip der Covert-Content-Angriffe, die Antwort-Funktion des E-Mail-Clients als Backchannel zu nutzen, nach wie vor funktioniert. Es entsteht der Eindruck, dass die Hersteller die Verantwortung für eine sichere E-Mail-Kommunikation auf den Nutzer abschieben. Und das ist nicht im Sinne der Sicherheit. Cranor und Buchler [3] stellten bereits fest, dass Benutzer nicht gewillt sind, aktiv die Einzelheiten der Sicherheitsmerkmale zu verwalten. Die Systemdesigner sind in der Pflicht, sich im Vorfeld über die Entscheidungsanforderungen Gedanken zu machen, welche an die Benutzer gestellt werden. Fast jeder Dritte der getesteten PGP-fähigen und gut jeder Fünfte der S/MIME-fähigen Clients ist als Decryption Oracle angreifbar. Sicherheit und Benutzerfreundlichkeit werden traditionell als Kompromiss betrachtet. Nach Schneier [4] führt genau dieses „Entweder-Oder“-Denken oft zu Systemen, die weder benutzbar noch sicher sind. Die Betrachtung, ob ein sicherer E-Mail-Client weniger funktional und ein flexibler und leistungsfähiger E-Mail-Client weniger sicher ist, lassen Raum für weitere Forschung.

Tabelle 1: Re-Evaluation Covert-Content-Angriffe

Quellen

[1] Jens Müller, Marcus Brinkmann, Damian Poddebniak, Sebastian Schinzel, und Jörg Schwenk. Re:What’s Up Johnny?: Covert Content Attacks on Email End-to-End Encryption. Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 11464 LNCS:24–42, 2019. ISSN 16113349.

[2] https://github.com/RUB-NDS/Covert-Content-Attacks

[3] Lorrie Faith Cranor und Norbou Buchler. Better Together: Usability and Security Go Hand in Hand. IEEE Security Privacy, 12(6):89–93, nov 2014. ISSN 1558-4046.

[4] Bruce Schneier. Stop Trying to Fix the User. IEEE Security & Privacy, 14(05):96, 2016. ISSN 1558-4046. URL https://doi.org/10.1109/MSP.2016.101.