Neuer lokaler Angriffsvektor erweitert die Angriffsfläche der Log4j-Sicherheitslücke

Neuer lokaler Angriffsvektor erweitert die Angriffsfläche der Log4j-Sicherheitslücke

Neuer lokaler Angriffsvektor erweitert die Angriffsfläche der Log4j-Sicherheitslücke

Cybersicherheitsforscher haben einen völlig neuen Angriffsvektor entdeckt, der es Angreifern ermöglicht, die Log4Shell-Sicherheitslücke auf Servern lokal über eine JavaScript-WebSocket-Verbindung auszunutzen.

Mit diesem Angriffsvektor ist jeder mit einer anfälligen Log4j-Version in der Lage, auf seinem Computer oder lokalen privaten Netzwerk eine Website zu durchsuchen und möglicherweise die Schwachstelle auszulösen. Dieser Vektor erweitert die Angriffsfläche erheblich und kann sogar Dienste beeinträchtigen, die als localhost ausgeführt werden und keinem Netzwerk ausgesetzt waren.

WebSockets ermöglichen im Gegensatz zu HTTP, bei dem der Client die Anforderung und der Server die Antwort sendet, eine bidirektionale Kommunikation zwischen einem Webbrowser (oder einer anderen Clientanwendung) und einem Server.

Das Problem kann zwar behoben werden, indem alle lokalen Entwicklungs- und Internetumgebungen auf Log4j 2.16.0 aktualisiert werden, Apache hat jedoch am Freitag die Version 2.17.0 veröffentlicht, die eine Denial-of-Service (DoS) -Schwachstelle behebt, die als CVE-2021- verfolgt wird. 45105 (CVSS-Score: 7,5) ist damit der dritte Log 4j2-Fehler, der nach CVE-2021-45046 und CVE-2021-44228 bekannt wird .

Hier finden Sie eine vollständige Liste der Fehler, die bisher im Logging-Framework entdeckt wurden, nachdem der ursprüngliche Log4Shell- Fehler bei der Remote-Codeausführung bekannt wurde:

  • CVE-2021-44228(CVSS-Score: 10.0) – Eine Sicherheitsanfälligkeit bezüglich Remotecodeausführung, die Log4j-Versionen von 2.0-beta9 bis 2.14.1 betrifft (in Version 2.15.0 behoben).
  • CVE-2021-45046(CVSS-Score: 9.0) – Eine Sicherheitslücke bezüglich Informationslecks und Remotecodeausführung, die Log4j-Versionen von 2.0-beta9 bis 2.15.0 betrifft, außer 2.12.2 (in Version 2.16.0 behoben).
  • CVE-2021-45105(CVSS-Score: 7,5) – Eine Denial-of-Service-Schwachstelle, die Log4j-Versionen von 2.0-beta9 bis 2.16.0 betrifft (in Version 2.17.0 behoben).
  • CVE-2021-4104(CVSS-Score: 8,1) – Ein nicht vertrauenswürdiger Deserialisierungsfehler, der die Log4j Version 1.2 betrifft (Kein Fix verfügbar; Upgrade auf Version 2.17.0).

Die neueste Entwicklung ist darauf zurückzuführen, dass eine Reihe von Bedrohungsakteuren die Log4j-Fehler aufgehäuft haben, um eine Vielzahl von Angriffen durchzuführen, darunter Ransomware-Infektionen, die die in Russland ansässige Conti-Gruppe und einen neuen Ransomware-Stamm namens Khonsari betreffen. Darüber hinaus hat der Log4j-Fehler bei der Remote-Codeausführung auch die Tür zu einer dritten Ransomware-Familie namens TellYouThePass geöffnet, die laut Forschern von Sangfor und Curated Intel bei Angriffen auf Windows- und Linux-Geräte eingesetzt wird.

Es wird dringend empfohlen, schnell zu handeln. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat kurzfristige Schutzmaßnahmen veröffentlicht, die die Schwachstelle zwar nicht schließen, ihre Ausnutzung aber verhindern oder erschweren können. Darüber hinaus sollten die Detektions- und Reaktionsmaßnahmen gestärkt werden. Mehr Informationen finden Sie auf der Website des BSI: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Cyber-Sicherheit/Vorfaelle/log4j-Schwachstelle-2021/log4j_Schwachstelle_Detektion_Reaktion.html?nn=520690.

Log4Shell Zero-Day-Schwachstelle in der Java Bibliothek entdeckt

Log4Shell Zero-Day-Schwachstelle in der Java Bibliothek entdeckt

Log4Shell Zero-Day-Schwachstelle in der Java Bibliothek entdeckt

Am 10.12.2021 wurde bekannt, dass in der Java Bibliothek Log4j eine Zero-Day-Schwachstelle mit dem Namen Log4Shell existiert (CVE-2021-44228). Diese Schwachstelle wurde von BSI als höchst kritisch eingestuft. Log4j ist eine beliebte Protokollierungsbibliothek für Java-Anwendungen. Öffentlich zugänglichen Quellen zufolge meldete Chen Zhaojun von Alibaba am 24. November 2021 offiziell eine Log4j-Schwachstelle für Remotecodeausführung (RCE) bei Apache. Diese kritische Sicherheitslücke, die anschließend als CVE-2021-44228 (auch bekannt als "Log4Shell") verfolgt wurde, betrifft alle Versionen von Log4j von 2.0-beta9 bis 2.14.1. Diese Schwachstelle ermöglicht es Angreifern auf dem Zielsystem eigenen Programmcode auszuführen und damit den Server zu kompromittieren. Dieses Risiko besteht dann, wenn log4j verwendet wird, um eine vom Angreifer kontrollierte Zeichenkette wie beispielsweise den HTTP User Agent zu protokollieren.

Besonders hinterhältig: Angreifer könnten mithilfe der Lücke unauffällige Backdoors für sich im Netzwerk einbauen, sodass der eigentliche Angriff erst Wochen oder mehrere Monate später stattfinden könnte.

Unser BlackTeam hat unverzüglich entsprechende Regeln auf unsere Kunden-Sensoren ausgerollt und für die Schwachstelle typische Strings in mehreren Verbindungen zu einigen Webservern erkannt. Daraufhin wurden unsere Kunden auf die Schwachstelle aufmerksam gemacht und entsprechende Handlungsempfehlungen ausgesprochen.

Unsere Handlungsempfehlungen:

- Prüfen Sie, ob auf Ihren Systemen eine der betroffenen Versionen von Log4j (2.0-beta9 bis 2.14.1) verwendet wird.

- Es sollte entsprechend dem Grundschutzbaustein [BSI2021a] ein Update auf die aktuelle Version 2.15.0 [APA2021] (gittag: 2.15.0-rc2 [GIT2021c]) von log4j in allen Anwendungen sichergestellt werden.

- Da Updates von Abhängigkeiten in Java-Anwendungen häufig nicht zeitnah erfolgen können, sollte bis dahin die folgende Mitigationsmaßnahme ergriffen werden: Die Option "log4j2.formatMsgNoLookups" sollte auf "true" gesetzt werden, indem die Java Virtual Machine mit dem Argument "–Dlog4j2.formatMsgNoLookups=True” gestartet wird.

- Alternativ kann auch die Umgebungsvariable LOG4J_FORMAT_MSG_NO_LOOKUPS auf true gesetzt werden. Diese beiden Mitigationsmaßnahmen funktionieren erst ab Log4J Version 2.10. Achtung: Diese Maßnahme kann die Funktionsweise der Applikation beeinträchtigen, wenn die Lookup-Funktion tatsächlich verwendet wird.

-Weitere Maßnahmen zur Vorbeugung sind in folgendem Dokument des BSI beschrieben: https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-549032-10F2.pdf

Neue Bundesregierung setzt auf Open Source Konzept

Neue Bundesregierung setzt auf Open Source Konzept

Neue Bundesregierung setzt auf Open Source Konzept

Ein Kommentar von Joerg Lammerich

 

Die neue Bundesregierung bekennt sich im aktuellen Koalitionsvertrag zu einem revolutionären Vorgehen im Bereich des Digitalisierungskonzeptes. Durch Bundesmittel entwickelte Lösungen sollten als Open Source Projekte realisiert werden.
Das Vorhaben verfolgt die Idee: Public Money - Public Code

Durch öffentliche Mittel entwickelte Software soll demnach allen Bürgern zur Verfügung stehen. Ein weiterer wichtiger Punkt in diesem Zusammenhang ist die durch Open Source entstehende Transparenz des Programmcodes. Jeder hat somit die Möglichkeit, den Programmcode einzusehen, was eine maßgebliche Erhöhung der Sicherheit von Softwareprodukten zur Folge hat. Hierzu gibt es vielfältige Beispiele aus der Vergangenheit, wie z.B. die Entdeckung von Sicherheitslücken in Verschlüsselungsalgorithmen.

Zu beobachten bleibt natürlich, ob die Ankündigungen im Koalitionsvertrag auch in absehbarer Zeit zur Anwendung kommen. Aus IT-Security-Sicht wäre es besonders wünschenswert, wenn sich Deutschland und die EU zukünftig mehr in Richtung Open Source bewegen würden.

Aus Sicht der Certified Security Operations Center GmbH ist das Vorhaben ambitioniert. Wenn wir jedoch nicht heute mit dieser Entwicklung beginnen,  wird sich auch in Zukunft nichts ändern. Die Certified Security Operations Center GmbH verfolgt und lebt schon seit Jahren den Open Source Ansatz. Wir sind der festen Überzeugung, dass genau das der richtige Weg für sichere Softwarelösungen ist.

 

Domain-Spoofing entwickelt sich zur Last für Unternehmen

Domain-Spoofing entwickelt sich zur Last für Unternehmen

Domain-Spoofing entwickelt sich zur Last für Unternehmen

Unsere Leitstelle verfügt über ein Domain Monitor Detection System und alamiert uns, wenn Domains registriert werden, die sich der Domains unserer Kunden stark ähneln (sog. Lookalike-Domains). Diese Art von Events werden in letzter Zeit im Blue-Team häufiger beobachtet. Die Zahl der detektierten Lookalike-Domains hat sich bei uns im Vergleich zum Vorjahr sogar beinahe verdoppelt.

Unternehmen, die Domain-Spoofing zum Opfer fallen, haben im Anschluss häufig mit dem Rückgang der Markensicherheit und des Vertrauens der Kunden zu kämpfen. Auch Umsatzeinbußen können die Folge sein. Das Problem dabei: Domain-Spoofing ist zwar schwer zu identifizieren, wenn Sie jedoch die Anzeichen und Risiken kennen, können Sie Ihre Marke proaktiv gegen Betrüger schützen. Gerne möchten wir Ihnen im folgenden Beitrag eine kleine Hilfestellung geben, wie Sie Fake-Domains erkennen und bekämpfen können.

Was verbirgt sich hinter Domain-Spoofing?

Domain-Spoofing bezeichnet die Imitation des Namens einer Website oder einer E-Mail-Domain durch Cyberkriminelle. Es wird häufig dazu verwendet, um flächendeckende Angriffskampagnen durchzuführen. Dabei ist es stets das Ziel, das Vertrauen von Opfern zur Ausführung von schädlichen Aktivitäten zu missbrauchen. Dabei kommt die Social Engineering Methode Phishing zum Einsatz. Mithilfe von Phishing-Mails werden personenbezogene Daten, Passwörter und andere sensible Informationen ausgespäht. Auch die Implementierung von Schadsoftware wie z. B. Malware oder Krypto-Mining können ein Ziel sein.

Wie erkenne ich Domain-Spoofing?

Die meisten Fake-Domains besitzen einen DNS-Eintrag, was sie legitim wirken lässt und MX-Einträge, die Angreifer zum Senden und Empfangen von Phishing-E-Mails befähigen. Fake-Webseiten hosten zudem Inhalte, wie Corporate Identity Farben, Logos und Bilder, die bekannte Marken imitieren. Meistens jedoch schleichen sich bei Cyberkriminellen Flüchtigkeitsfehler ein, über die man den Betrug aufdecken kann. Deshalb sollte man beim Empfang einer Mail ganz genau hinschauen. Security Awareness Kampagnen für Mitarbeiter sind in diesem Kontext besonders wichtig, um sie im Umgang mit z.B. Phishing-Mails zu sensibilisieren.

Unsere Tipps und Handlungsempfehlungen:

Maßnahmen bei Fake-Domains:

- Wird ein Verstoß gegen die Markenschutzrechte festgestellt, kann ein Takedown-Verfahren beim Hosting-Anbieter eingeleitet werden, um die Fake-Domain vom Netz nehmen zu lassen. Die zuständigen Behörden des jeweiligen Landes z. B. EUROPOL können auch eingeschaltet werden.

- Mithilfe von Domain Monitoring Lösungen können neu registrierte Lookalike-Domains kontinuierlich reportet werden.

- Es können Cyber-Thread-Intelligence Frameworks wie z. B. MITRE ATT&CK genutzt werden, um einen schnellen und transparenten Austausch zwischen Unternehmen und Sicherheitsteams zu ermöglichen.

Maßnahmen bei gefälschten E-Mails:

- Mit dem neuen Standard namens DMARC können Inhaber von Domains, ihre Domains vor Fälschungen schützen. Mit den gesetzten DMARC-Einstellungen, werden alle eingehenden E-Mails blockiert oder als SPAM deklariert, die nicht von den Domainbesitzern authentifiziert wurden.

-Mitarbeitern sollten Awareness-Schulungen angeboten werden, die gezielt auf Domain-Spoofing eingehen, um sie für dieses Thema zu sensibilisieren, damit sie stärker auf Details wie defekte bzw. unseriöse Links, falsch positionierte Logos, Rechtschreib- und Grammatikfehler oder sogar falsche Corporate Identity beim Aufruf von externen Quellen achten. Zudem sollte der Prozess des Reportings in Ihrem Unternehmen optimiert bzw. vereinfacht werden, damit im Ernstfall möglichst schnell reagiert werden kann.