Kategorie: Themen

Kryptographie

Abfragwürdig: Queryable Encryption wird praktikabel

Die meisten Evolutionsschritte in der Kryptographie haben nicht sofort nennenswerte Auswirkungen auf die Praxis. Schlimmstenfalls wird ein Verfahren oder ein Algorithmus durch einen neuen kryptoanalytischen Angriff unbrauchbar gemacht oder geschwächt. Aber dass neue Anwendungsfelder entstehen, geschieht nur etwa einmal im Jahrzehnt (z. B. in den 70er Jahren mit Public-Key-Kryptographie, in den 2000ern mit Blockchain oder in den 2010ern mit bestimmten quantensicheren Verfahren).

Jetzt könnte ein solcher Punkt wieder einmal erreicht sein: Mathematisch ist Queryable Encryption kein Hexenwerk. Verglichen mit ihrer großen Schwester könnte sie gar als geradezu trivial bezeichnet werden: Während homomorphe Verschlüsselung das Durchführen beliebiger Rechenoperationen auf verschlüsselten Daten ermöglicht, verspricht Queryable Encryption nur die Möglichkeit, bestimmte Operationen auszuführen, ohne die Daten zu entschlüsseln – im Wesentlichen eine (semantisch möglichst reichhaltige) Suche.

Das allein ermöglicht schon magisch klingende Anwendungsfälle: Der Cloud-Provider muss nicht mehr in unsere Daten hineinschauen. Das polizeiliche Informationssystem kann gewisse Recherchen durchführen, ohne den Inhalt der Datensätze kennenzulernen. Bestimmte bioinformatische Forschung kann auf verschlüsselten Genomen erfolgen. Die Kunst besteht jedoch darin, ein solches Kryptosystem zur Einsatzreife zu bringen.

Den Macherinnen und Machern der beliebten NoSQL-Datenbank MongoDB scheint es nun gelungen zu sein, Queryable Encryption in ihr Flaggschiff-Datenbank-Produkt Atlas einzubauen. Im aktuellen Preview ist zunächst nur die exakte Suche enthalten – das aber immerhin schon auf komplett randomisiert verschlüsselten Daten, krankte doch herkömmliche Client-Side-Verschlüsselung immer daran, dass nur deterministisch (immer gleich) verschlüsselt werden konnte, um die Daten wiederfinden zu können. Die Möglichkeit zur Suche nach Intervallen (Range) und Substrings soll in späteren Releases folgen.

Ob sich die Implementierung in MongoDB in der Praxis bewährt, wird sich erst noch zeigen. Als großer Schritt für die angewandte Kryptographie insgesamt darf das Feature aber durchaus schon gefeiert werden.

https://www.mongodb.com/blog/post/mongodb-releases-queryable-encryption-preview

Cyberwar

Der wahre Hackback – Ukrainische IT-Armee meldet Erfolge

Traditionell halten sich staatliche Stellen, die in Sachen Cyber offensiv unterwegs sind, mit Verlautbarungen über Erfolge und Misserfolge zurück. Die Öffentlichkeit erfährt im Allgemeinen eher zufällig oder über Umwege Details über Ziele, Angriffskampagnen und mögliche oder tatsächliche Impacts – wenn überhaupt.

Anders in der Ukraine, wo wieder einmal die durch den Krieg ausgelöste Zeitenwende deutlich wird. Nicht nur, dass der ukrainische Vizepremier und Minister für digitale Transformation, Mychajlo Fedorow, zwei Tage nach dem Überfall auf sein Land auf Twitter zur Bildung einer Cyber-Armee aufgerufen hat. Nun meldet der Pressedienst seines Ministeriums gar die aktuellen Zahlen zur Angriffskampagne, diesmal auf dem eigenen Telegram-Kanal.

So sollen im Laufe der letzten Woche mehr als 400 russische Online-Ressourcen angegriffen worden sein. Betroffen waren laut ukrainischen Angaben viele regionale Medienseiten, aber auch das neu geschaffene russische Pendant zu Apples App Store und Google Play, NashStore. Insgesamt sollen seit Beginn der Invasion bzw. seit Gründung der IT-Armee aus ukrainischen und internationalen Spezialistinnen und Spezialisten rund 2.000 russische Assets attackiert worden sein, zum Teil mehrfach. Die ukrainische Seite nennt dies „Präventivschläge gegen Cyber-Positionen.“

Damit könnte ein neues Kapitel eingeleitet worden sein im Bereich Cyberwar, wenn sich verstetigt, dass Cyberoperationen nicht nur klandestin, sondern auch öffentlichkeitswirksam in der Medienschlacht vor- und zum Einsatz kommen.

https://www.unian.ua/techno/communications/ukrajinska-it-armiya-za-tizhden-atakuvala-ponad-400-rosiyskih-onlayn-resursiv-11838027.html

Cloud

Jirassic Park: Das zwischenzeitliche Aussterben der Confluencer

Atlassian ist seit Jahren als eines der Unternehmen bekannt, die ihre Kunden mit besonders viel Enthusiasmus in die Cloud locken – manche würden vielleicht sogar scheuchen sagen. Immerhin verspricht man sich dort (zu Recht) mehr Agilität und damit auch mehr Nutzen für die Kunden.

Nun hat das Umarmen der Wolke einige, die sich darauf voll eingelassen haben, böse gebissen. Ein Wartungsskript, das eigentlich nur Legacy-Daten löschen sollte, entfernte darüber hinaus die produktiven Daten von 400 Kunden samt Informationen zu gebuchten Produkten, Nutzern und Drittanbieteranwendungen. Zwar waren umfangreiche Wiederherstellungssysteme vorhanden, trotzdem sollte der Wiederaufbau für einen Großteil der Betroffenen bis zu zwei Wochen dauern.

Nun gibt es zwei Sichten auf die Misere. Die eine: Das passiert On-Prem auch, nur dann steht es (meist) nicht in der Zeitung. Das ist auch richtig. Und allein die Cloud zu verdammen ist in diesem Fall sicherlich nicht hilfreich. Andererseits zieht das andere Extrem, den Cloud-Betrieb von der Verantwortung völlig freizusprechen, auch nicht komplett. Immerhin bauen wir uns mit IaaS, PaaS und SaaS erhöhte Komplexität und damit auch mehr „Single“ Points of Failure, mindestens aber Klumpenrisiken auf.

Die Verantwortung, für die geschäftskritischen Daten einer Vielzahl von Organisationen verantwortlich zu sein, muss daher mit einem umso größeren Maß an Professionalität und Due Diligence einhergehen. Die – zumal nicht-amerikanischen – Cloud-Anbieter (Atlassian sitzt in Sydney) werden sich daran messen lassen müssen, ob sie schneller besser werden, als wir ihnen unser Geld und unsere Verantwortung hinterherwerfen.

https://www.heise.de/news/Atlassian-Ausfall-der-Cloud-Dienste-Jira-Confluence-dauert-noch-zwei-Wochen-6669601.html

Malware

Après-Kasper-Ski? Warnungen vor russischer Software

Die IT-Supply-Chain ist in den letzten Jahren nicht zuletzt dank internationaler Vorfälle wie Solarwinds oder Kaseya stark in den Fokus gerückt. Dabei geben wird schon seit Jahrzehnten gewissen Softwaretypen („Hilfs- oder Dienstprogramme“) tiefsten Einblick und Zugriff in bzw. auf unsere IT-Systeme.

Dass insbesondere Antiviren-Software aufgrund ihrer umfassenden Systemrechte besonders kritische Gäste in der eigenen Infrastruktur sind, die zudem funktionsbedingt einen Kanal zum Nach-Hause-Telefonieren benötigen, wurde ebenfalls immer wieder diskutiert. Und doch kommen nur ganz wenige Organisationen von ihnen los. Zu groß scheint der Nutzen in Bezug auf übliche Malware, zu groß das Compliance- und Haftungsrisiko, wenn man Antiviren-Software nicht nutzt.

Nun hat mit dem russischen Einmarsch in die Ukraine die Diskussion neuen Anschub erhalten: Der im Enterprise-Bereich beliebte Hersteller Kaspersky gilt potenziell als durch Moskau steuerbar. So blieb es diesmal nicht bei den üblichen abstrakten Aufrufen, Risikomanagement für die eigene Supply Chain zu betreiben. Das BSI nutzte vielmehr den bisher nur dreimal gezogenen § 7 BSI-Gesetz, um konkret vor dem Einsatz von Kaspersky-Produkten zu warnen.

Obwohl dies nicht mit einem Verbot gleichzusetzen ist, kommen deutsche Unternehmen und Behörden nun in Bedrängnis. Schließlich ist die Migration auf ein neues Antivirus-Produkt nicht mal nebenbei gemacht und außerdem mit erheblichen Kosten verbunden, von der Frage öffentlicher Mittel im Fall von Behörden ganz zu schweigen.

Wie ist das ganze also einzuordnen? Zunächst hat das BSI völlig recht: Der Einsatz russischer Produkte in deutschen kritischen Infrastrukturen war vor dem 24. Februar ein Risiko – und ist es jetzt umso mehr. Niemand kann sicher vorhersagen, inwieweit und wann sich der Krieg doch noch stärker in den bisher erstaunlich ruhigen Cyberraum bewegen wird.

Auf der anderen Seite ist Ruhe bewahren das Gebot der Stunde. Natürlich versuchen Geheimdienste und andere „state-sponsored“ Akteure seit Jahren, in Infrastrukturen hierzulande einzudringen. Und es ist zwar nicht auszuschließen, dass ihnen dafür bestimmte Software helfen kann, die schon einen Fuß in der Tür hat. Auf der anderen Seite haben bisherige Angriffskampagnen ganz andere Vektoren zu nutzen gewusst, von Phishing über RDP bis Teamviewer. Es gibt also viel mehr – und übrigens auch viel dringendere – Hausaufgaben zu tun, als sofort Kaspersky den Stecker zu ziehen. Und kritischen Playern wie der Rüstungsindustrie wäre mit solch einer Warnung des BSI eh nicht mehr zu helfen, wenn sie bisher auf derartige Produkte gesetzt hätten.

Allerdings ist es nützlich, den aktuellen Anlass zu einer ehrlichen Bestandsaufnahme zu nutzen, wie abhängig die eigene Infrastruktur von bestimmten Staaten ist. Und im Fall von Russland hat sich die Einschätzung, was Vertrauen und Sicherheit betrifft, eben noch einmal eingedunkelt.

Am Ende könnte die Abkehr von Kaspersky zwar nicht mit dem Paukenschlag der BSI-Warnung, sondern mit den Füßen erfolgen: Wenn bei den nächsten Lizenzverlängerungen die Geopolitik als ein weiteres, wichtiges Argument mit auf den Tisch kommt. Oder wenn aktuell die eine oder andere Cyberversicherung schreibt, dass ein Umstieg weg von Kaspersky zwar keine Voraussetzung für die Weiterführung der Police sei, im Schadensfall aber ggf. keine Deckung erfolge, falls das der Angriffsvektor wäre. Es ist also in der neuen Weltordnung ein Stück riskanter geworden, Kaspersky langfristig die Treue zu halten.

Fazit: Mit einer angemessenen Risikoanalyse und einem Lagebild der eigenen Situation im Zusammenspiel mit den konkreten Gefährdungen (Ransomware lässt grüßen) fährt man derzeit besser, als mit hektischer Deinstallation von Schutzsoftware.

https://www.dw.com/de/warnstufe-orange-deutsche-unternehmen-im-visier-russischer-hacker/a-61232466

BSI-Warnung: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Warnungen-nach-P7_BSIG/Archiv/2022/BSI_W-004-220315.html

Cyberwar

Hybrider Cyberkrieg: Angriffe auf die Ukraine – und Westeuropa?

Seit Jahren gibt es immer wieder Cyberangriffe auf Systeme und kritische Infrastrukturen in der Ukraine, etwa auf die Energieversorgung 2015 und 2016. Einige davon konnten mit ausreichender Sicherheit russischen Akteuren zugeordnet werden, bei anderen wird dies nur vermutet.

Nun, mit dem Einmarsch russischer Truppen in die Ostukraine, wird die Sorge um eine Eskalation auch im Cyberraum immer größer. Eine neue Angriffswelle auf ukrainische Organisationen hat in den letzten Tagen bereits stattgefunden. Diesmal waren das Verteidigungsministerium und zwei Banken die Ziele von DDoS-Angriffen; Russland wird auch hier hinter den Angriffen vermutet.

Weiterhin gibt es Berichte, dass russische Hackergruppen aktiv Ziele in Amerika auskundschaften, um auf mögliche Sanktionen gegen Russland reagieren zu können. Und auch deutsche Sicherheits- und Zivilschutzbehörden sind alarmiert, inwieweit hiesige und sonstige europäische Infrastrukturen ins Visier geraten werden.

Die nächsten Wochen könnten also zeigen, ob unsere Vorbereitungen der letzten Jahre für derartige Szenarien ausreichend waren oder nicht.

https://www.tagesspiegel.de/politik/haben-alarmstufe-rot-sicherheitsbehoerden-fuerchten-massive-attacken-russischer-hacker/28091330.html

OSINT

Die Macht der OSINT: Geheimdienste enttarnen leichtgemacht

Man kann politisch unterschiedlich dazu stehen, aber eines ist nicht zu bestreiten: Die Forschungsarbeit der Security-Researcherin Lilith Wittmann, in der mit einfachen Mitteln mutmaßlich zwei Außenstellen des Bundesamts für Verfassungsschutz enttarnt wurden, zeigt eindrücklich, wie mächtig „OSINT“ geworden ist.

Open Source Intelligence – die geschickte Nutzung und Verknüpfung öffentlich verfügbarer Informationen – war seit jeher ein Mittel der Geheimdienste. Durch die immer weiter voranschreitende Digitalisierung stehen jedoch auch Einzelpersonen mit etwas Geschick, Neugier und einem Internetzugang schier endlose Recherchemöglichkeiten zur Verfügung. Gepaart mit etwas Durchhaltevermögen und einer kleiner Prise Frechheit – wer hätte damit gerechnet, dass jemand einfach mal zu Fuß vorbeischauen und Klingelschilder vergleichen könnte? – ist schnell ein Niveau erreicht, das die Tarnfähigkeiten vieler Behörden übersteigt. Einfach weil es bisher ausreichte, ein paar Decknamen, Postfächer und tote Mailboxen vorzuhalten.

In der neuen Welt, in der Google-Fu, Suche in IP-Datenbanken und Crowd-Sourcing von Recherchen langsam zu Allgemeinbildung werden, müssen sich die Dienste zukünftig deutlich mehr einfallen lassen, um Deckmäntel aufrechtzuerhalten. Oder umdenken. Auch in der Security wurde mit Kerckhoffs‘ Prinzip Ende des 19. Jahrhunderts die Security through obscurity aufgegeben.

Ungelöst ist insbesondere die Herausforderung der physischen Verfolgung durch funkende Mini-Devices (Tags): Die Apple AirTags, mit denen Wittmann eine Postsendung bis ins Bundesamt für Verfassungsschutz verfolgen konnte, stellen auch an anderen Stellen eine Gefahr für Privatsphäre und Safety dar, lassen sie doch Menschen, Waren und Fahrzeuge für kleinstes Geld unbemerkt tracken. Und nicht alle haben die Mittel – wie theoretisch ein Geheimdienst –, um Scanner zu betreiben, die diese detektieren können.

https://lilithwittmann.medium.com/bundesservice-telekommunikation-enttarnt-dieser-geheimdienst-steckt-dahinter-cd2e2753d7ca

Advisories, Log4Shell

Log4Shell-Schwachstelle in Log4j: Überblick

Hilfe zur Selbsthilfe

Unsere aktuelle HiSolutions „Hilfe zur Selbsthilfe Log4Shell“ (v1.11 vom 05.01.2022 07:00) gibt es hier zum Download:

(Danke an das Team für die schnelle Arbeit – Inés Atug, Markus Drenger, Enno Ewers, Daniel Jedecke, Lisa Lobmeyer, Lena Morgenroth, Folker Schmidt, Volker Tanger, Manuel Atug.)

HiSolutions-Selbsthilfe-log4j_version-1.11Herunterladen

Go to English version

Changelog 

V1.11 (05.01.2022 07:00): CVE-2021-44832 (Arbitrary Code Execution) und Updatehinweis auf Version 2.17.1 ergänzt. Hinweis auf Ausnutzung ohne Nachladen von Schadcode entfernt. Scantools von AV-, Endpoint-Protection-, IDS- und Schwachstellenscanner-Herstellern ergänzt. Bekannte Angriffe ergänzt.

V1.10 (22.12.2021 09:00): Abgleich mit dem erweiterten BSI-Dokument (Stand 20.12.2021). Ergänzen der Gefährdungslage. Überarbeitung der Dokumentenstruktur. Löschung von Dopplungen. Ergänzen von Maßnahmenempfehlungen. Ergänzen bisher bekannter Angriffe (zum Ableiten möglicher IOCs).

V1.9 (20.12.2021 21:00): Expliziter Hinweis, dass generell alle Versionen vor 2.17.0 anfällig sind. Hinweis auf neue Schwachstelle in Version 2.16.0. Hinweis auf Prüfung in ICS-Umgebungen. Einbeziehung von Produkt-Herstellern und Dienstleistern konkretisiert.

V1.8 (15.12.2021 20:00): Verbesserung und Hinweise zu Überprüfung von Linux-Systemen per Kommandozeile.

V1.7 (15.12.2021 18:00): Verweis auf Angriffe mittels Ransomware hinzugefügt. Klarstellung zur Zielgruppe des Dokumentes eingefügt. Sprachliche Verbesserungen. Hinweis auf besseres Logging eingebaut. Hinweis auf CI/CD und Wiederherstellung von Backups eingefügt.

V1.6 (15.12.2021 12:00): CISA-Liste betroffener Produkte hinzugefügt. Hervorhebung der neuen Log4j 2.15.0 CVE-2021-45046 und des Defizits im ersten Patch. Prüfung via Konsole auf Linux-Systemen. Strukturiertes Vorgehen, um zu erkennen, ob Angreifer sich eingenistet und im Anschluss selber das System gepatcht haben. Verifikation der Behebung der Verwundbarkeit nach Patch. Datenschutzrelevantes Dokument vom BayLDA aufgenommen. BSI-Dokumente referenziert. Hinweis auf Feedbackmöglichkeit.

V1.5 (14.12.2021 15:00): Priorisierung und Liste aller Produkte. Wir haben eine Empfehlung zur Priorisierung hinzugeführt sowie eine Vorgehensweise der strukturierten Erfassung aller Produkte, die betroffen sind, und wie diese abgearbeitet werden kann.

V1.4 (14.12.2021 13:00): log4j v1.x mit CVE-2021-4104 adressiert. Ausnutzung der Schwachstellen seit 1.12.2021. Cloud Dienste hinzugefügt. Potentiell betroffene Systeme mit drei Merkmalen beschrieben. Intranet erläutert. Egress-Filter (ausgehender Datenverkehr) hinzugefügt. Hinweis auf Logfile-Sicherungen aufgrund der Angriffe seit 1.12.2021. Hinweis auf Aussage Hessischer Beauftragter für Datenschutz und Informationsfreiheit (HBDI), dass wegen Art. 33 DSGVO auf erfolgreiche Angriffe zu prüfen ist. 

V1.3 (13.12.2021 17:00): Erste veröffentlichte Version 

Beiträge zu Log4Shell/Log4j

  • Log4Shell: HiSolutions Self-Help Guide Log4j
    The following self-help guide contains HiSolutions‘ expert assessment, recommendations, IT procedures, and measures to cope with the ongoing Log4Shell cybersecurity incident and attack wave caused by a critical vulnerability in the Apache Log4j logging library. Special thanks to Lisa Lobmeyer for the English version.
  • Log4Shell-Schwachstelle in Log4j: Überblick
    Hilfe zur Selbsthilfe Unsere aktuelle HiSolutions „Hilfe zur Selbsthilfe Log4Shell“ (v1.11 vom 05.01.2022 07:00) gibt es hier zum Download: (Danke an das Team für die schnelle Arbeit – Inés Atug, Markus Drenger, Enno Ewers, Daniel Jedecke, Lisa Lobmeyer, Lena Morgenroth, Folker Schmidt, Volker Tanger, Manuel Atug.) Go to English version Changelog  V1.11 (05.01.2022 07:00): CVE-2021-44832 (Arbitrary Code Execution) und Updatehinweis auf Version 2.17.1 ergänzt. Hinweis auf Ausnutzung ohne Nachladen von Schadcode entfernt. Scantools von AV-, Endpoint-Protection-, IDS- und Schwachstellenscanner-Herstellern ergänzt. […]
  • Log4Shell: Massive Bedrohung durch Schwachstelle in Bibliothek Log4j
    Aktuell besteht eine IT-Sicherheitsbedrohung der höchsten Warnstufe: Durch eine Schwachstelle in der weitverbreiteten Java-Protokollierungsbibliothek Log4 sind sehr viele Systeme, Anwendungen und Applikationen (unvollständige, ständig wachsende Liste hier) anfällig für einen sehr einfach durchzuführende Remote Code Execution Angriff (RCE). Ein Vielzahl von Akteuren scannt bereits das Internet nach vulnerablen Instanzen, und erste Angreifer haben bereits begonnen, Backdoors auf Systemen zu installieren. Diese könnten später etwa für Ransomware-Angriffe missbraucht werden. Die Bibliothek ist dringend zu patchen – eine Herausforderung durch die vielen […]
Log4Shell

Log4Shell: Massive Bedrohung durch Schwachstelle in Bibliothek Log4j

Aktuell besteht eine IT-Sicherheitsbedrohung der höchsten Warnstufe: Durch eine Schwachstelle in der weitverbreiteten Java-Protokollierungsbibliothek Log4 sind sehr viele Systeme, Anwendungen und Applikationen (unvollständige, ständig wachsende Liste hier) anfällig für einen sehr einfach durchzuführende Remote Code Execution Angriff (RCE).

Ein Vielzahl von Akteuren scannt bereits das Internet nach vulnerablen Instanzen, und erste Angreifer haben bereits begonnen, Backdoors auf Systemen zu installieren. Diese könnten später etwa für Ransomware-Angriffe missbraucht werden.

Die Bibliothek ist dringend zu patchen – eine Herausforderung durch die vielen Stellen, an denen Log4j zum Einsatz kommt. Häufig sind Anwender auch auf die Zuarbeit der Hersteller angewiesen. Dabei sind beileibe nicht nur direkt aus dem Internet erreichbare Systeme betroffen.

Der IT-Sicherheitsforscher Kevin Beaumont (@gossithedog) pflegt einen Twitter-Thread mit den neusten Entwicklungen und Tipps: