Kategorie: Themen

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:

Ransomware

Ryuk-Zuck, Conti-nentaldrift: Die Wandlung der Ransomware

Kurzzeitig hatten Beobachtende und (potenziell) Betroffene zuletzt aufatmen können: Ransomware-Gangs wie die berüchtigte REvil-Gruppe waren durch konzertierte Aktionen von Strafverfolgungsbehörden unter Druck geraten. In der Folge hatten die Cyberkriminellen bestimmte Aktivitäten eingestellt; die sogenannte „victim shaming“-Site von REvil, auf der die gehackten Organisationen samt einem Teil ihrer gestohlenen Daten präsentiert wurden, um den Druck zur Zahlung des Lösegelds zu erhöhen, ging offline.

Nun scheint in den letzten Wochen eine Verlagerung der Aktivitäten und Anpassung der „Geschäftsmodelle“ stattgefunden zu haben. Die Kampagne „Conti“ etwa ist laut Informationen auf ihrer eigenen Website dazu übergegangen, neben den bisherigen Standbeinen „Lösegeld für Entschlüsselung“ und „Lösegeld oder wir leaken die Daten“, zusätzlich Zugriff in die Netze der gehackten Organisationen zum Kauf anzubieten.

Noch wird spekuliert, was der wirkliche Grund für diesen „Pivot“ ist. Einerseits würde dieser Schritt FIN12 – der Gruppe hinter Conti und Ryuk – eine zusätzliche Einnahmequelle ermöglichen. Zum anderen scheint das verlässliche und systematische Leaken von Daten, ohne das die Erpressung nicht wirken kann, die Gruppen vor erhebliche Herausforderungen zu stellen – technisch sowie hinsichtlich der Strafverfolgung. Denn Tor-/Onion-Sites im „Darknet“ haben eine geringe Bandbreite, während öffentliche Downloadseiten im Internet schneller gesperrt werden können. Es bleibt also zu beobachten, in welche Richtung sich die Marktbereinigung und Reorganisation weiterentwickelt und ob die Schläge von FBI und Co. am Ende eine positive Auswirkung hatten.

https://krebsonsecurity.com/2021/10/conti-ransom-gang-starts-selling-access-to-victims/

Ransomware

Gemein(de)heit: Kommunen im Visier

Banken, Versicherungen und ähnliche im Wesentlichen bitschubsende Branchen sind Bedrohungen aus der Cyber-Ecke schon länger gewohnt und haben daher ihre Abwehr bereits seit den 90er-Jahren schrittweise hochgefahren, bisweilen auch zusätzlich motiviert durch gewisse regulatorische Schachzüge. Die cyberphysischen Sektoren wie Energie, Produktion und Wasser sind irgendwann in der Folge von Stuxnet Ende der 2010er-Jahre nach und nach erweckt worden. Und Krankenhäuser etwa hat es nach 2015 zunehmend erwischt, sodass auch sie aufrüsten mussten und weiterhin müssen.

Kommunen wurden auch bisher schon vereinzelt Opfer organisierter Cyberkriminalität. Ebenso gab es den einen oder anderen spektakulären Fall, wie den des Admins, der bis ins Gefängnis hinein das Generalpasswort als Geisel hielt. Die Mehrheit der Fälle waren jedoch Zufallstreffer: Kollateralschäden der Angry-Bear-Strategie der Ransomware-Gangs. Wütende Bären, die es gezielt auf Gemeinden abgesehen hatten, anstatt hungrig wahllos auf Beutezug zu gehen, waren bisher anderen Zielen zugetan.

Nun scheint es einen Dammbruch zu geben: Kommunen werden aktuell am laufenden Band digital „aufgemacht“ und ausgenommen.

Das hat zumindest zwei Gründe: Erstens sind die Taschen der öffentlichen Hand bekanntlich tief. Zwar sind die Kommunen selbst meist klamm, aber wirklich Pleite gehen lassen wie bei einer in den Sand gesetzten Wirtschaftsunternehmung werden wir sie im föderalen System letztlich ja doch nicht. Und Verschuldung geht am Ende im Notfall doch immer unbegrenzt, wenn der Schuldner Staat heißt.

Zum anderen – auch das hat (auch) mit der begrenzten finanziellen Ausstattung zu tun – sind die Kommunen IT-mäßig noch einmal deutlich schlechter aufgestellt als Verwaltungen auf Landes- oder gar Bundesebene. Solange es hier angeblich auch weniger zu holen gab, konnte man das vielleicht sogar als angemessen – Fachleute sagen lieber „risikoorientiert abgewägt“ – durchgehen lassen. Seit die Gangs jedoch verstanden haben, dass hier lohnenswerte UND leichte Ziele zu Hunderten auf die Ernte warten, hat die Hölle angefangen loszubrechen.

Was wir aktuell sehen, dürfte nur der Anfang eines mehrjährigen Prozesses sein, aus dem die kommunale Verwaltung mit vielen Schrammen, aber am weit entfernten „Ende“ nur gestärkt hervorgehen kann. Alles andere können wir uns gar nicht leisten.

Es wird in der nächsten Zeit darauf ankommen, wie lang und schmerzhaft zu werden wir dem Prozess erlauben.

https://www.waz.de/region/rhein-und-ruhr/nach-witten-it-experten-erwarten-weitere-hacker-attacken-id233620623.html