Microsoft Azure-Schwachstelle OMIGOD in Linux VMs
Falls jemand Linux VMs unter Microsoft Azure nutzt: Dort werden stillschweigend OMI-Agenten installiert. Diese haben aber in der ungepatchten Version vier schwere Sicherheitslücken, die Angreifern die Remote Code-Ausführung mit root-Rechten ermöglichen. Da es keine Update-Mechanismen über Azure gibt, müssen Administratoren selbst prüfen, ob die OMI-Agenten aktuell sind. #Sicherheit #OMIGOD
Microsoft Azure-Schwachstelle OMIGOD in Linux VMs patchen
Microsoft Azure-Schwachstelle OMIGOD in Linux VMs patchen
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1263307472
Url: https://administrator.de/knowledge/microsoft-azure-schwachstelle-omigod-in-linux-vms-1263307472.html
Ausgedruckt am: 22.12.2024 um 01:12 Uhr
6 Kommentare
Neuester Kommentar
Moin,
wollte es vorhin auch schon reinschreiben.
Hübsche KOmmentare gibt es auch von Fefe dazu:
Wenn man beim Azure--Agenten Username und Paßwort wegläßt, ist man root.
Und Sadya Nadella liefert dazu:
The future of security is passwordless
Da haben die Entwickler das wohl etwas zu wörtlich genommen.
lks
PS: Wenn das seit Juni offen rumsteht und die Kunden das erst jetzt gesagt bekommen, weiß man was man von solchen Cloud-Serverices wie Azure zu halten hat.
wollte es vorhin auch schon reinschreiben.
Hübsche KOmmentare gibt es auch von Fefe dazu:
Wenn man beim Azure--Agenten Username und Paßwort wegläßt, ist man root.
Und Sadya Nadella liefert dazu:
The future of security is passwordless
Da haben die Entwickler das wohl etwas zu wörtlich genommen.
lks
PS: Wenn das seit Juni offen rumsteht und die Kunden das erst jetzt gesagt bekommen, weiß man was man von solchen Cloud-Serverices wie Azure zu halten hat.
Zitat von @Lochkartenstanzer:
PS: Wenn das seit Juni offen rumsteht und die Kunden das erst jetzt gesagt bekommen, weiß man was man von solchen Cloud-Serverices wie Azure zu halten hat.
PS: Wenn das seit Juni offen rumsteht und die Kunden das erst jetzt gesagt bekommen, weiß man was man von solchen Cloud-Serverices wie Azure zu halten hat.
Sie verteilen immer noch die verwundbare Version. Mehr als peinlich.
Zitat von @c.r.s.:
Sie verteilen immer noch die verwundbare Version. Mehr als peinlich.
Sicher , hast du mal eine neue Linux VM deployed ? MS Patch die VM‘s ja automatisch ..
Ich verstehe auch immer nicht , warum Azure Kunden alle ihre Ressourcen in das Internet stellen und alle Ports öffnen, mit onPremise Infrastruktur macht man das auch nicht , wieviele Sicherheitslücken gibt es in onPremise Systemen ..,
Mit freundlichen Grüßen
Zitat von @7Gizmo7:
Sicher , hast du mal eine neue Linux VM deployed ? MS Patch die VM‘s ja automatisch ..
Zitat von @c.r.s.:
Sie verteilen immer noch die verwundbare Version. Mehr als peinlich.
Sicher , hast du mal eine neue Linux VM deployed ? MS Patch die VM‘s ja automatisch ..
Natürlich, heute Vormittag in North Europe, Ubuntu 18.04 LTS und Azure Automation.
Ich verstehe auch immer nicht , warum Azure Kunden alle ihre Ressourcen in das Internet stellen und alle Ports öffnen, mit onPremise Infrastruktur macht man das auch nicht , wieviele Sicherheitslücken gibt es in onPremise Systemen ..,
Das machen sicher die wenigsten relevaten Azure-Kunden. Die Schwachstelle ist in einem privaten Netz schlimm genug.
Es gibt ein schon ein spezifisches Risiko von Fehlkonfigurationen bei Cloud-Deployments das letztlich auf die Motivation zurückzuführen ist, aus der Cloud-Services überhaupt eingesetzt werden: Reduktion der eigenen operativen Tätigkeit auf ein Kerngebiet und Konzentration dessen, was nach dieser Philosophie "übersteht", in Ansätzen wie "DevOps" oder "DevSecOps". Wenn dadurch ein Bottleneck ins Unternehmen eingebracht wird, und die Gefahr ist groß, wird der Schritt selten als Fehloptimierung erkannt und eher werden durch weitere Fehloptimierung Sicherheitsbarrieren (z.B. Funktiontrennung) eingerissen. Die Mehrschichtigkeit der Sicherheitsarchitektur bleibt auf der Strecke.
Zitat von @kgborn:
Aber das Fazit ist ein anderes: Als Admin in diesem Bereich musst Du eigentlich bei jedem Deployment prüfen, ob die gepatchten OMI-Agenten vorhanden sind.
Aber das Fazit ist ein anderes: Als Admin in diesem Bereich musst Du eigentlich bei jedem Deployment prüfen, ob die gepatchten OMI-Agenten vorhanden sind.
Und sie dann komplett rauswerfen
lks