Seit Freitag ist bekannt, dass es eine massive Sicherheitslücke in der Java-Logging-Bibliothek „Log4j“ gibt. Diese erlaubt es einem Angreifer ohne weitere Authentifizierung Schadcode auf einem betroffenen System auszuführen.
Da es sich bei Log4j um eine weit verbreitete Softwarekomponente handelt, sind von diesem Problem weitreichende Teile der Software-Landschaft betroffen. Dies hat dazu geführt, dass auch das BSI bereits eine kritische Warnung zu dieser Schwachstelle herausgegeben hat.
Nachdem wir uns im ersten Teil der Blogserie das sogenannte Shared Responsibility Model, das Zuständigkeiten innerhalb von AWS regelt, angesehen haben, gehen wir in diesem Artikel einen Schritt weiter und sprechen über die geographischen sowie physikalischen Grundlagen der AWS Datacenter. Auch hier handelt es sich um Grundlagen, die wir für die nächsten, deutlich spezifischeren, Themen benötigen.
Während vor einigen Jahren oftmals noch debattiert wurde, wann und in welcher Form „die Cloud“ auch in Unternehmen ein Thema wird, kann mittlerweile wohl niemand mehr leugnen, dass dieses nebulöse Geschöpf der Technik bereits allgegenwärtig ist. Während Cloud Infrastrukturen in vielen Unternehmen bereits Gang und Gebe sind, legen andere Unternehmen derzeit noch eine gewisse Portion Vorsicht an den Tag. Auch wir werden immer häufiger mit diesen und vielen weiteren exemplarischen Fragen innerhalb unserer Cloud Projekte konfrontiert:
Wir schaffen es derzeit natürlich schon lange nicht mehr jede Vulnerability zu beschreiben, allerdings versuchen wir zumindest von Zeit zu Zeit auf besonders schwerwiegende Schwachstellen hinzuweisen. Weiterlesen
Fileless Malware ist derzeit in aller Munde. Mal wieder eine „neue“ Angriffsform, vor der jeder Hersteller 148 % besser als der andere Hersteller schützt. So konnte ich auf der diesjährigen itsa wieder beobachten, wie sich die IT-Security Branche in Sachen Bullsh**-Bingo wieder einmal selbst übertreffen konnte. Im heutigen Blogpost möchte ich möglichst kurz und bündig auf das Konzept Fileless Malware eingehen, das Risiko beschreiben und erklären, wieso wir auch deswegen vermutlich nicht sterben werden. Weiterlesen
VMware veröffentlichte am 14.08.2018 Updates für vCenter und ESXi Server. Diese Updates sollten näher beleuchtet werden, da sie die Foreshadow-NG Lücke in Intel Prozessoren schließt und gegebenenfalls Performanceprobleme verursachen können. Es handelt sich dabei um einen CPU Bug der Spectre / Meltdown Familie. Genauer eingeordnet ist es eine der 8 Spectre-NG Lücken, über die mein Kollege Martin Steigerwald bereits einen Artikel auf unserem Blog veröffentlicht hat. Eine aktuelle Auflistung der bekannten Bugs findet sich auch in diesem Heise Artikel. Hier erfahren Sie, ob Sie updaten sollten. Weiterlesen
UPDATE 22.5.2018: Die ersten beiden Sicherheitslücken sind nun bekannt. Es gibt auch das erste Hersteller Advisory. Für beide Lücken hat Intel Microcode Updates angekündigt, damit Anwendungen Memory Disambiguation (MD) abschalten können. Nur in diesem Fall greift der durch die Updates bereitgestellte Schutz. Ich habe den Blog-Artikel um CVEs und Hersteller Advisories ergänzt.
UPDATE 9.5.2018: Bis zum 7.5.2018 gaben die Entdecker keine Details zur ersten Spectre NG-Sicherheitslücke bekannt, da Intel offenbar Probleme habe, rechtzeitig Patches bereit zu stellen. Neuer Termin für eine koordinierte Veröffentlichung könnte der 21. Mai sein. Es könnte aber auch noch länger dauern. Für Patches zur kritischsten Sicherheitslücke ist der 14. August im Gespräch – eine ziemlich lange Zeit, um eine Lücke zu schließen, die es sehr einfach mache, Barrieren zwischen virtuellen Maschinen oder virtuellen Maschinen und Hypervisor zu umgehen.
Zwischenzeitlich war es relativ ruhig geworden um Meltdown und Spectre. Für die meisten im Enterprise-Umfeld eingesetzten Systeme gibt es mittlerweile Patches, die oftmals aus einer Mischung von Microcode-Updates (via Betriebssystem und/oder Firmware), Vorkehrungen im jeweiligen Betriebssystem-Kern sowie Anwendungen mit besonders großer Angriffsfläche, wie Webbrowser, bestehen. War es das?
Schon zu Meltdown und Spectre warnten Experten, dass es noch weitere Sicherheitslücken geben könnte. Genau dies hat sich laut einem Artikel im c´t Magazin bewahrheitet. Weiterlesen
Einen Angriff auf die eigene Infrastruktur? Wer macht denn sowas? Na Sie – hoffentlich! Denn nur wer seine eigenen Systeme angreift, der sieht, wozu ein richtiger Angreifer in der Lage ist. Und so ein Angriff muss ja nicht destruktiv sein, es reicht ja schon zu sehen, dass die Hintertür aus morschem Holz besteht. Dagegentreten ist gar nicht notwendig 🙂
Obwohl das neue Jahr nur wenige Tage alt ist, hatte es mit Meltdown und Spectre bereits einiges an sicherheitsrelevanten Bugs im Petto.
Auch in Juniper Produkten wurde jetzt eine schwerwiegende Sicherheitslücke entdeckt.
Immerhin ist der Workarround im Gegensatz zu Meltdown und Spectre einfach: Auf den betroffenen Geräten muss das Web-Management deaktiviert werden.
UPDATE: Nach einem Hinweis von Falco in den Kommentaren zu diesem Artikel muss ich meine Aussage zu den Hypervisorbreakouts revidieren. Nach genauerer Recherche aufgrund des Hinweises im VMware Advisory, muss konstatiert werden, dass es mittels der Variante aus CVE-2017-5715 sehr wohl möglich ist, den Speicher des Hypervisor auszulesen und damit Daten anderer, eigentlich nicht sichtbarer VMs auf dem gleichen System auszulesen!
Seit Ende letzten Jahres sind im Internet diverse Gerüchte über eine massive Sicherheitslücke aufgetaucht, die alle Systeme (Linux, macOS, Windows) und alle Prozessorarchitekturen (x86, x64, ARM, Power, …) betrifft. Seit heute haben wir Gewissheit, dass das nicht nur Gerüchte waren: mit der Veröffentlichung von Meltdown/Spectre haben wir eine der flächendeckendsten Schwachstellen in der IT-Infrastruktur seit langem und es handelt sich nicht um einen Software-Bug, sondern um einen Designfehler in den CPUs selbst. In diesem Artikel werde ich versuchen, den doch sehr komplexen Hintergrund der Angriffe auf einigermaßen verständliche Begriffe herunter zu brechen, damit sich jeder ein Bild von den Auswirkungen und der Gefährdung machen kann. Etwas technisches Interesse und Geduld vorausgesetzt, werde ich hier den Hintergrund (grob) darstellen und erklären, was da eigentlich schiefgeht.
Proact Deutschland GmbH
Südwestpark 43
90449 Nürnberg
Mail: info@proact.de
Tel.: 0911 309990