Suche
Close this search box.

Schlagwort: Zero-Day

Zero-Day-Lücke in Log4j
Bedrohung

Zero-Day-Lücke in Log4j

Zero-Day-Lücke in Log4j  – Kritische Sicherheitslücke gefährdet zahlreiche Server und Apps. Apple, Twitter, Amazon und tausende andere Dienste sind anfällig. Die ersten Angriffe laufen bereits und wurden dokumentiert. Administratoren müssen sofort handeln. Zero-Day-Lücke in Log4j  Eine Zero-Day-Sicherheitslücke names Log4Shell ermöglicht es Angreifern beliebigen Code auszuführen. Über die weit verbreitete Java-Logging-Bibliothek Log4j können Attacken auf viele Server und Apps durchgeführt werden. Dienste wie Apple, Twitter, Steam und Amazon sind betroffen aber auch viele kleinere Angebote. Es gibt bereits ein Proof-of-Concept Code der das Ausnutzen der Lücke demonstriert. Ein Angreifer kann die Sicherheitslücke ausnutzen, indem er manipulierte Anfragen an einen verwundbaren Server oder eine angreifbare Anwendung schickt. Der Proof-of-Concept-Code (PoC) der Pen-Testing-Gruppe 0x0021h zeigt, dass der Angreifer eine Zeichenkette der Form ${jndi:ldap://127.0.0.1:1389/a} ins Protokoll schreibt. Der Verzeichnisdienst JNDI kontaktiert den genannten LDAP-Server 127.0.0.1:1389 und nimmt schließlich von ihm Daten wie potenziell bösartige Java-Klassen entgegen und führt diese aus. Ein Angreifer müsste demnach einen von ihm kontrollierten Server angeben, um einen Server über das Logging zu kapern (Log4Shell). Verwundbare Projekte Die Lücke hat bereits eine CVE-Nummer erhalten (CVE-2021-44228, Risiko kritisch, CVSSv3 10/10). Auch das BSI warnt vor dieser Lücke und Administratoren sollten dringend handeln. Viele Anwendungen verwenden die Log4j-Bibliothek und all diese sind von der Sicherheitslücke betroffen. Die Pen-Testing-Gruppe 0x0021h schreibt zu ihrem PoC-Exploit, dass er für Apache Struts2, Apache Solr, Apache Druid, Apache Flink und weitere funktioniere. Die Bibliothek Betroffen ist die Log4j Bibliothek von der Version 2.0-beta9 bis 2.14.1. Das Apache-Projekt hat kurzfristig Version 2.15.0 veröffentlicht, die die Lücke schließt. In einer Sicherheitsmeldung listen die Apache-Entwickler zudem Maßnahmen auf, wie man die Server ohne Update vorläufig sichern kann. Bei Log4j ab Version 2.10 helfe das Setzen der Systemeigenschaft „log4j2.formatMsgNoLookups“ auf “true” oder das Entfernen der JndiLookup-Klasse aus dem Klassenpfad (etwa mit dem Befehl zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Weitere Informationen finden Sie auch hier: https://www.heise.de/news/Kritische-Zero-Day-Luecke-in-log4j-gefaehrdet-zahlreiche-Server-und-Apps-6291653.html?wt_mc=rss.red.security.alert-news.atom.beitrag.beitrag https://www.spiegel.de/netzwelt/web/log4-j-schwachstelle-ja-leute-die-scheisse-brennt-lichterloh-a-760bd03d-42d2-409c-a8d2-d5b13a9150fd#ref=rss?sara_ecid=soci_upd_wbMbjhOSvViISjc8RPU89NcCvtlFcJ Haben Sie Fragen? Unsere Techniker stehen Ihnen gerne zur Verfügung. Kontaktieren Sie uns!

Microsoft Exchange Server-Zero-Day-Schwachstellen
Bedrohung

Microsoft Exchange Server-Zero-Day-Schwachstellen

Microsoft Exchange Server-Zero-Day-Schwachstellen – Bereits am 2.März haben Microsoft in ihrem Blog auf neue Microsoft Exchange Server-Zero-Day-Schwachstellen aufmerksam gemacht. Die Schwachstellen bestehen in den lokalen Exchange-Servern 2010, 2013, 2016 und 2019. Exchange Online, also Microsoft 365 ist davon nicht betroffen. Die Akteure nennt Microsoft in ihrem Blog-Beitrag Hafnium. Die Angriffe scheinen gezielt aus China zu stammen und haben evtl. eine nationalstaatliche verbundene Gruppe im Hintergrund. Microsoft Exchange Server-Zero-Day-Schwachstelle Die Angriffe beziehen sich auf die Exchange Server Welt von Microsoft. Hier wird versucht über gestohlene Passwörter oder durch Sicherheitslücken das System übernehmen zu können. Mit Hilfe von Web Shell wird versucht das System zu übernehmen und dann Daten stehlen zu können. Hierbei wird sehr professionell vorgegangen und ein hohes Maß nach so genannten „Skills“ sind erkennbar. Die Akteure sind also keine Amateure die einfach nur ein paar Daten stehlen wollen. Microsoft stellt Patch bereit Um die Auswirkungen dieser Situation zu minimieren bzw. ganz zu vermeiden, empfiehlt Microsoft dringend, sofort Maßnahmen zu ergreifen, um die Patches für alle lokalen Exchange-Deployments anzuwenden. Um diese Schwachstellen zu beheben, sollten Sie zu den neuesten Exchange Cumulative-Updates wechseln und dann die entsprechenden Sicherheitsupdates auf jedem Exchange Server installieren. Oberste Priorität haben Server, auf die über das Internet zugegriffen werden kann (z. B. Server, die Outlook im Web/OWA und ECP veröffentlichen). Sie können das Exchange Server Health Checker-Skript verwenden, das von GitHub heruntergeladen werden kann (verwenden Sie die neueste Version). Wenn Sie dieses Skript ausführen, werden Sie darüber informiert, ob Sie mit Ihren lokalen Exchange Server-Updates in Verzug sind (beachten Sie, dass das Skript Exchange Server 2010 nicht unterstützt). Es wird außerdem empfohlen, dass Ihr Sicherheitsteam anhand der hier geteilten Kompromissindikatoren bewertet, ob die Schwachstellen ausgenutzt wurden. Weitere Informationen zum Thema finden Sie auch im Microsoft Blog. Haben Sie Fragen oder benötigen Sie Unterstützung beim Update für Ihren Exchange Server, können Sie gerne unsere technischen Experten um Rat und Unterstützung anfragen.   

Nach oben scrollen