Kritische SicherheitslŸcke

Log4Shell Software-Fehler macht viele Server und Apps angreifbar

https://www.deutschlandfunk.de/kritische-sicherheitsluecke-100.html (im Cache)

https://ondemand-mp3.dradio.de/file/dradio/2021/12/13/flaechenbrand_im_internet_sicherheitsluecke_in_der_java_dlf_20211213_1645_c77eac72.mp3 (im Cache)

von

Peter Welchering, Deutschlandfunk

13.12.2021


Zusammenfassung

Es passiert nicht oft, dass das Bundesamt fŸr Sicherheit in der Informationstechnik (BSI) eine Schwachstelle mit ihrer hšchsten Warnstufe Rot versieht. So eine SicherheitslŸcke - Log4Shell - hat sich gerade aufgetan. Sie šffnet Hackern TŸr und Tor fŸr Angriffe auf zahlreiche Server, Firmennetzwerke und Apps.


Die SicherheitslŸcke Log4Shell erlaubt es Angreifern, verwundbare Server mithilfe manipulierter Anfragen zu kapern.


Was macht diese SicherheitslŸcke so gefŠhrlich?

Bei der SicherheitslŸcke Log4Shell geht es um fehlerhaften Code aus einer Java-Bibliothek namens Log4j. Viele kommerzielle Softwarepakete nutzen diese Bibliothek, um zu protokollieren, wer mit dieser Software arbeitet und wer auf welche Server zugreift. Brisant ist das aus vier GrŸnden:


Wo wird Log4j Ÿberall eingesetzt?

Weltweit. Das besondere Anwaltspostfach an deutschen Gerichten, musste beispielsweise au§er Betrieb genommen werden, jetzt wird dort wieder gefaxt. Bei allen grš§eren IT-Firmen wird die Bibliothek gern verwendet, also zum Beispiel bei


Die fehlerhafte Bibliothek ist also wirklich extrem weit verbreitet:



Gab es denn schon erfolgreiche Angriffe?

Ja. Verschiedene Computer-Notfallteams haben erfolgreiche Angriffe gemeldet, das BSI hat auch einige bestŠtigt. Allerdings dŸrften die meisten dieser Zugriffe Ÿber diese SicherheitslŸcke aktuell von Sicherheitsexperten stammen, die genau nachschauen wollen, wo das Problem liegt.


IT-Fachleute gehen davon aus, dass demnŠchst einige Computernetze Ÿber einen Ransomwareangriff lahmgelegt werden, wobei die Ransomware Ÿber diese SicherheitslŸcke eingeschleust wird. Es gibt Hinweise, dass diese LŸcke bereits seit dem 1. Dezember 2021 ausgebnutzt wird. Mittelfristig dŸrfte deshalb mit einer grš§eren Welle von SystemausfŠllen zu rechnen sein.


Wie lassen sich solche Angriffe abwehren?

Die SicherheitslŸcke muss zunŠchst schnell geschlossen werden. Die Hersteller von Softwareprodukten, die die Bibliothek Log4j verwenden, mŸssen dann Sicherheitsupdates ihrer Software herausgeben. In einigen FŠllen ist das am Wochenende bereits passiert, andernorts arbeiten die Hersteller gerade fieberhaft an solchen Updates. Und eine gewisse Anzahl von Herstellern prŸft derzeit noch, ob in ihren Produkten eventuell auch Teile aus der Log4j-Bibliothek verwendet wurden. Es wird also noch etwas dauern, bis man Genaueres wei§.


Wie sollten Verbraucher auf die SicherheitslŸcke reagieren?

Otto-Normalanwender kšnnen zunŠchst wenig tun. Gefordert sind jetzt die Softwarehersteller und IT-Sicherheitsdienstleister. Als Erste-Hilfe-Ma§nahmeÊ haben einige Sicherheitsfirmen Filter fŸr Befehlsfolgen gebaut, mit denen die SicherheitslŸcke ausgenutzt werde kann. Grš§ere Unternehmen haben bereits am Wochenende die Ÿblichen Notfallma§nahmen eingeleitet: ZugangsbeschrŠnkungen. Netzwerke aufteilen und segmentieren, so dass nicht sofort das gesamte Unternehmensnetz betroffen ist, wenn solch ein Angriff gelingt, Zugriffsrechte einschrŠnken, ebenso wie hereinkommende Verbindungen und ausfŸhrbare Befehle und Programme. Allerdings schrŠnken all diese Ma§nahmen natŸrlich auch die Nutzung der Systeme ein und sind bei den Anwendern wenig beliebt.


Log4J ist Open-Source-Software. Ist die doch nicht so sicher wie gedacht?

Open Source steht dafŸr, dass jeder draufschauen und Fehler finden kann. Deshalb werden mehr Fehler schneller gefunden. Das hei§t aber nicht, dass Open-Source-Software ohne SicherheitslŸcken ist. Log4J ist eine quelloffene Software der Apache Software Foundation. Zwei Betreuer werden Ÿber Sponsorships in Teilzeit darŸber finanziert. Wer also eine solche Bibliothek in Softwareprodukten fŸr kritische Einsatzbereiche verwendet, muss unbedingt genau prŸfen, wie sich die Bibliothek in seinem Produkt verhŠlt und nachgeordnete Sicherheitsroutinen einbauen. Doch da wird aus KostengrŸnden leider gern geschludert. Das ist fahrlŠssig.


Kritische Schwachstelle in Log4j

CVE-2021-44228, CVE-2021-45046, CVE-2021-45105

Arbeitspapier "Detektion und Reaktion, Version 1.4

vom Bundesamt fŸr Sicherheit in der Informationstechnik, Stand 20.12.2021

im Cache

Auszug


Die besondere KritikalitŠt des Themenkomplexes ergibt sich aus der generellen Ausnutzbarkeit, die auch fŸr FolgeaktivitŠten wie das Ausrollen von Ransomware oder die Kompromittierung von nachgelagerten Systemen und Produkten genutzt werden kann.


Das ganze Ausma§ der Bedrohungslage ist nach EinschŠtzung des BSI aktuell nicht abschlie§end feststellbar. Zwar gibt es fŸr die betroffene Java-Bibliothek Log4j ein Sicherheits-Update, allerdings mŸssen alle Produkte, die Log4j verwenden, ebenfalls angepasst werden.

Eine Java-Bibliothek ist ein Software-Modul, das zur Umsetzung einer bestimmten FunktionalitŠt in weiteren Produkten verwendet wird. Es ist daher oftmals tief in der Architektur von Software-Produkten verankert. Welche Produkte verwundbar sind und fŸr welche es bereits Updates gibt, ist derzeit nicht vollstŠndig Ÿberschaubar und daher im Einzelfall zu prŸfen. Es ist zu erwarten, dass in den nŠchsten Tagen weitere Produkte als verwundbar erkannt werden.

Beschreibung der Schwachstelle

Log4j ist eine beliebte Protokollierungsbibliothek fŸr Java -Anwendungen. Sie dient der performanten  Aggregation von Protokolldaten einer Anwendung. Die Bibliothek ist in vielen Softwareprodukten  enthalten. Java-Software verwendet Ÿblicherweise nicht die vom Betriebssystem bereitgestellten Systembibliotheken, sondern liefert die notwendigen Bibliotheken selbst  mit, sodass verwundbare Versionen der Bibliothek auch auf dem System vorhanden sein kšnnen, ohne dass Log4j durch die Administrierenden selbst explizit installiert wurde.


2.2 Betroffene Produkte

Durch die Vielzahl der Produkte, die  Log4j  einbinden  und deren Konfigurationsoptionen ist eine vollstŠndige Liste der verwundbaren Produkte nicht erstellbar.  Eine Liste von potenziell  gefŠhrdeten Produkten  [5]  wird gepflegt, erhebt aber keinen Anspruch auf VollstŠndigkeit. Die hohe Verbreitung von  Java zum Beispiel auch im Privatanwender -, Netzwerkinfrastruktur- und Smartphonebereich legt nahe,  dass  neben Servern potenziell sehr viele  weitere Systeme betroffen sein kšnnen, insbesondere auch wenn es sich um selbst entwickelte Anwendungen von Unternehmen handelt. Dies zeigt auch eine weitere  Sammlung betroffener Produkte [6] .


Aufgrund der derzeit nicht Ÿberschaubaren Vielfalt der verwundbaren Anwendungen kann diese  Schwa chstelle sowohl z.  B. Webseiten und  automatisierte Schnittstellen als auch Client-Anwendungen  betreffen. DarŸber hinaus kšnnen auch Anwendungen betroffen sein, die in eingebetteten Systemen und  Komponenten zur industriellen Steuerung (z.B. Siemens [7], Schneider Electric [8] ) eingesetzt werden.


2.3 Gefahren

2.3.1 Exponierte IT-Systeme ins Internet

Die folgenden Gefahren bestehen, wenn Log4j verwendet wird, um eine vom Angreifern kontrollierte Zeichenkette wie beispielsweise Ð im Falle einer Webanwendung Ð   den HTTP User Agent zu protokollieren. Sollten die verwundbaren IT-Systeme Verbindungen ins Internet aufbauen und nicht nur entgegennehmen kšnnen, kann Ÿber die Schwachstelle schŠdlicher Programmcode nachgeladen werden. DafŸr kšnnen auch Protokolle verwendet werden, die Ÿblicherweise nur innerhalb von IT-Netzwerken zum Einsatz kommen, wie beispielsweise LDAP. UnabhŠngig von der Mšglichkeit Schadcode nachzuladen, kšnnen durch DNS-Anfragen trotzdem Informationen wie beispielsweise Umgebungsvariablen zum Angreifern gelangen. In diesen Umgebungsvariablen werden je nach Anwendungsfall auch Benutzerkennungen und Authentifikationsmerkmale gespeichert, sodass ein Abfluss der Daten mit der Kompromittierung dieser Informationen gleichzusetzen ist. Auch kšnnten Angreifer gegebenenfalls sensible Informationen in die Protokolldaten ausleiten. Bisher konnte nicht gesichert nachgewiesen werden, dass eine AusfŸhrung von Schadcode auch mit untersagten Kommunikationsbeziehungen mšglich ist, allerdings war dies bei Šhnlich gelagerten Schwachstellen in der Vergangenheit unter bestimmten UmstŠnden der Fall.


Durch den im Internet frei verfŸgbaren Quelltext einer beispielhaften Ausnutzung der Schwachstelle (ãProof of ConceptÒ) [9], kšnnen Angreifer mit sehr geringem Aufwand verwundbare Systeme auffinden und die Schwachstelle anschlie§end ausnutzen. Solche automatisierten Ausnutzungen konnten bereits durch das BSI beobachtet werden. Ebenfalls wurden bereits erfolgreiche Kompromittierungen mit z. B. Kryptominern und Ransomware [10] bestŠtigt; eine Rekrutierung in Botnetze scheint ebenfalls wahrscheinlich. Neben diesen Infektionen wurde auch schon Ÿber den Einsatz von so genannten Post-Exploitation-Frameworks wie Cobalt Strike berichtet. Solche Anwendungen werden von Angreifern genutzt, um weitere Aktionen auf dem angegriffenen System auszufŸhren. Dies kann zum Beispiel das Verschleiern des Angriffs, das Nachladen eines Root-Kits oder von Ransomware beinhalten. Es kšnnen auch Systeme verwundbar sein, die nicht explizit aus dem Internet erreichbar sind, aber z. B. Daten von im Internet exponierten Diensten verarbeiten. Gibt beispielsweise eine Internetseite Suchanfragen an einen Java-basierten internen Suchindexdienst weiter, dann ist dieser ebenfalls gefŠhrdet.


Eine Šhnliche Problematik kšnnten Spamfilter oder Virenscanner, die Java-basiert sind, aufzeigen. Das sind lediglich zwei von zahlreichen mšglichen Konstellationen.


2.3.2 Ausbreitung im internen Netzwerk

Sowohl nach au§en (ins Internet) exponierte IT-Systeme als auch interne Systeme, welche keine Verbindungen ins Internet aufweisen, kšnnen durch die veršffentlichten Schwachstellen angegriffen werden. Eine Mšglichkeit zur Infektion von nicht aus dem Internet erreichbaren Systemen bietet die grundsŠtzliche WurmfŠhigkeit der Schwachstelle.


Angreifer mit Zugriffen auf interne Systeme kšnnen die Schwachstellen bspw. fŸr die Bewegung im internen Netzwerk nutzen (eng. ãLateral MovementÒ). DarŸber hinaus kšnnen Angreifer die Schwachstellen fŸr Angriffe auf ESXi Server verwenden (Hypervisor Jackpotting [2]) und somit SchŠden in Unternehmen anrichten.


Deutschlandfunk-Audio-BeitrŠge


Version: 8.1.2023

Adresse dieser Seite: http://acamedia.info/politics/hacks/Log4J/index.html

Home: http://acamedia.info

Joachim Gruber: http://acamedia.info/sciences/J_G/