[English]Im Februar 2024 hat Microsoft die Schwachstelle CVE-2024-21338 im Kernel von Windows 10/11 und diversen Windows Server-Versionen geschlossen. Super! Der Fehler an der Geschichte: Die Schwachstelle wurde von AVAST im August 2023 gemeldet, und die Schwachstelle wurde zu dieser Zeit als 0-day ausgenutzt.
Anzeige
Februar 2024-Update schließt CVE-2024-21338
Kleine Geschichte, wie besorgt und professionell Microsoft mit der Sicherheit seiner Windows-Nutzer umgeht. Bei der Schwachstelle CVE-2024-21338 handelt es sich um eine Windows Kernel Elevation of Privilege-Schwachstelle, CVEv3 Score 7.8. Ein Angreifer könnte diese Schwachstellen im Rahmen von Aktivitäten nach der Kompromittierung ausnutzen, um die Berechtigungen auf SYSTEM zu erhöhen.
Um diese Sicherheitslücke auszunutzen, müsste sich ein Angreifer zunächst beim System anmelden. Ein Angreifer könnte dann eine speziell gestaltete Anwendung ausführen, die die Sicherheitslücke ausnutzt und die Kontrolle über ein betroffenes System übernimmt, heißt es bei Microsoft. Ich hatte im Blog-Beitrag Microsoft Security Update Summary (13. Februar 2024) darüber berichtet und die betreffenden Februar 2024-Updates in den am Beitragsende verlinkten Artikeln aufgeführt.
Am 28. Februar 2024 hat Microsoft dann den Beitrag zur Schwachstelle CVE-2024-21338 erneut aktualisiert und gibt an, dass die Schwachstelle ausgenutzt wurde. Soweit so normal – die Brisanz kommt ins Spiel, wenn man die Geschichte zur Meldung kennt.
Avast hat es im August 2023 gemeldet
Sicherheitsforscher von AVAST sind bei Analysen darauf gestoßen, dass die Lazarus-Hackergruppe aus Nordkorea die Schwachstelle CVE-2024-21338 ausgenutzt hat, wie aus nachfolgendem Tweet hervorgeht.
Anzeige
Im Beitrag Lazarus and the FudModule Rootkit: Beyond BYOVD with an Admin-to-Kernel Zero-Day vom 28. Februar 2024 legen die Sicherheitsforscher von AVAST die Details offen. Avast ist auf einen in freier Wildbahn ausgenutzten Admin-to-Kernel-Exploit für eine damals unbekannte Zero-Day-Schwachstelle im appid.sys AppLocker-Treiber gestoßen.
Die Schwachstelle wurde von der Lazarus-Gruppe ausgenutzt, um ein Lese-/Schreib-Primitiv für den Windows-Kernel einzurichten. Diese Primitive ermöglichte Lazarus die direkte Manipulation von Kernel-Objekten in einer aktualisierten Version des Rootkits FudModul.
AVAST dokumentiert im oben verlinkten Beitrag die vielen Details der Schwachstelle und deren Ausnutzung durch Lazarus. Die Sicherheitslücke besteht seit Windows 10 1703 (RS2/15063), als der 0x22A018 IOCTL-Handler erstmals implementiert wurde. Ältere Builds sind nicht betroffen, da ihnen die Unterstützung für die verwundbare IOCTL fehlt.
Interessanterweise wird der Lazarus-Exploit die Schwachstelle nicht aktiviert, wenn er auf eine Build älter als Windows 10 1809 (RS5/17763) stößt, und ignoriert dabei drei vollkommen anfällige Windows-Versionen. Was die späteren Versionen betrifft, so erstreckte sich die Sicherheitslücke bis zu den neuesten Builds, einschließlich Windows 11 23H2.
Brisanz bekommt das Ganze mit der Information, dass AVAST einen benutzerdefinierten PoC (Proof of Concept)-Exploit entwickelt und ihn im August 2023 als Teil eines Schwachstellenberichts an Microsoft übermittelt hat. Für die Schwachstelle wurde CVE-2024-21338 vergeben, aber Microsoft hat das Ganze erst am 13. Februar 2024 gepatcht. Die haben also sechs Monate zum Schließen einer bereits ausgenutzten 0-Day-Schwachstelle gebraucht. (via)
Ähnliche Artikel:
Microsoft Security Update Summary (13. Februar 2024)
Patchday: Windows 10-Updates (13. Februar 2024)
Patchday: Windows 11/Server 2022-Updates (13. Februar 2024)
Anzeige
Vielleicht wurde die "Schwachstelle" ja auch von "guten" Zeitgenossen ausgenutzt? Dann will/darf/soll man die nicht so schnell schliessen ohne adäquaten Ersatz?
Das ist Blödsinn! Denn die "guten" Zeitgenossen wären davon ja auch betroffen!
Denn die Schwachstelle war ja allgemein bekannt!
Da wohl nochmal drüber nachdenken… die Backdoor Welt ist komplexer als Du annimmst.
Komplexität hin oder her, wenn die NSA weiß, dass z.B. die Russen, die Chinesen oder die Nordkoreaner um die "Lücke" wissen und diese auch aktiv ausnutzen, kann ich mir beim besten Willen nicht vorstellen, dass die dann MS verbieten diese Lücken zu stopfen. Nationale Sicherheit und so!
Der Schaden durch die Wirtschaftsspionage, durch Sabotage usw. wäre um ein Vielfaches höher, als selbst diese "Schwachstelle" offenzulassen um sie nutzen zu können.
Es könnte auch schlicht sein, das es ziemlich kompliziert war, diese Lücke zu schließen und die Programmierer deswegen eine so lange Zeit brauchten.
Nicht jede Lücke kann sofort geschlossen werden!
Man muß auch z.B. Abhängigkeiten prüfen und evtl. auch da etwas umprogammieren, damit es nicht zu Programmfehlern kommt.
Du magst recht haben, aber ich erwarte dann von MS, dass ALLE Programmierer ihre arbeiten an den
Spielereien der UI liegen lassen und sich um die Sicherheit des BS kümmern und nicht wie irgendein Bedienelement auszusehen hat.
Ich hoffe, Du erkennst meine bewusste Zuspitzung!
Nicht jeder GUI-Designer ist auch ein guter Kernel-Entwickler.
Außerdem, oben steht "Ein Angreifer könnte dann eine speziell gestaltete Anwendung ausführen, die die Sicherheitslücke ausnutzt".
Wer in seinem Unternehmen keinen Applocker oder eine andere Application-Control-Policy z.B. vom Antivirus einsetzt, hat es nicht besser verdient. Oder bei dem ist es nicht so schlimm, wenn alles platt ist.
Der Witz ist, dass der Applocker -Treiber für die Sicherheitslücke genutzt wurde.
Die Frage ist doch wieviel Opfer gab es bisher? Denn entweder hatte MS recht das nicht als hochbrisant anzusehen oder sie haben sich da doch geirrt.
Hab das jetzt nich im Detail verfolgt, aber so wie ich das versatnden habe muss der Angreifer bereits Zugang haben um die Lücke auszunutzen und seine Privilegien zu erhöhen.
Also nicht wirklich der Knackpunkt, wenn der Anfgreifer bereits da ist!
Komm ich über diese Lücke überhaupt erst ins System sieht das gleich anders aus.
Ne Lücke wo der Angreifer bereits im System ist, ist nicht so brisant.
So ist es.
Steht auch so im Beitrag:
***
Um diese Sicherheitslücke auszunutzen, müsste sich ein Angreifer zunächst beim System anmelden.
***
D.H., der Angreifer ist schon im System drin, erst dann kann er die Lücke ausnutzen.
Und wenn ein Angreifer ins System kommt, dann hat man noch ein weit schwereres Problem als diese Lücke.
Und interessant ist, das Windows 10 vor 1703 und auch Windows 8.1/8/7/Vista/XP und auch die Server 2016/2012R2 und älter etc. nicht betroffen sind, weils da die Funktionalität schlicht noch nicht gab.
Es macht aber schon einen gewissen Unterschied, ob der Angreifer nur eingeschränkte Rechte besitzt oder ob er Systemrechte erlangen kann.
Denn ansonsten würde das ganze Rechtemanagement überhaupt keinen Sinn ergeben! Und die ganzen Anstrengungen seitens MS Nutzer in Benutzerkonten zu zwängen und selbst Adminrechte zu beschneiden erst recht nicht.
Wenn er im System bereits drinn ist kann er auch anderweitig seine Systemrechte erweitern ganz ohne Lücken! Klar so ne Lücker erleichtert es einem , aber sie ist nicht wirklich notwendig geht auch ohne.
Sicher geht das auch ohne, aber fliegt halt schneller auf, wenn der/die Admin/s nicht schlafen.
Und nachvollziehbarer ist es auch noch.
Funktioniert so nicht, denn es gibts Programmiererteams.
1 Team macht nur Kernelfunktionen
1 Team macht nur Sicherheitsfeatures wie AppLocker, Defender etc.
1 Team macht nur die mitgelieferten Apps
etc. etc.
Und wie heißt es doch:
Viele Köche verderben den Brei.
Ergo ist es sinnvoll und auch Praxis, das sich nur 1 Team um Sicherheitslücken (und zwar nur in dem Bereich, für den sie zuständig sind) kümmert.
Ich schrieb doch, dass ich es überspitzt habe!
Wenn Team 1 "nur" aus wenigen Mann besteht und die zum Teil auch noch mit anderen Problemen beschäftigt sind, muss man die Manpower für begrenzte Zeit aufstocken! Stell Dir das doch mal bei einem Hochhausbrand vor.
Die Bereitschaft rückt aus, es sind zu wenig Mann. Tut mir leid, die einen haben gerade Freischicht und die anderen putzen gerade den Einsatzwagen, die haben keine Zeit, und überhaupt, "zu viele Köche verderben den Brei". ;-)
Nee, ganz einfach schlechtes Management der Verantwortlichen!
naja, nur das ein GUI Entwickler nun mal keine Ahnung von Security hat und nimmst du den da zum "Brandlöschen" mit dazu, hast du nachher noch mehr Lücken!
Die Feuerwehr hollt dann auch Feuerwehren aus Nachbarstädten und drückt nicht Passanten den Schlauch in die Hand, weil der grad aussieht als hätte er schonmal nen Schlauch in der Hand gehabt. ;-P
oder anderes Beispiel nen Elektroniker und nen Elektriker haben auch eine teilgemeinsame Ausbildung, trotzdem läßt du nen Elektroniker keine 10kV Anlage schalten!
Weil trotz ähnlicher und teilweise gleicher Ausbildung eben das Fachwissen fehlt.
Ok, dann haben die bei MS wohl fast nur noch Passanten da am Werkeln, so mein Eindruck.
Sonst würden sie ja nicht so beim Updaten patzen.
Und mal ganz ehrlich, das Design von Windows ist so tief in Systemdateien eingebunden, dass ich mir auch da recht sicher bin, dass da auch ein paar Programmierer dabei sind, die in der Lage wären, einen bekannten Fehler im System patchen zu können.
Das Problem wird sein, dass der Code für Windows, mit all dem "Schrott", der eigentlich nichts in einem BS zu suchen hat, einfach nicht mehr überschaubar ist. Sie patchen einen Fehler und produzieren damit an anderer Stelle einen Anderen. Nicht immer führt das zu gravierenden Fehlfunktionen, aber hier und da dann aber eben doch, oder eben zu Sicherheitslücken im System. Und da wäre ich wieder bei meinem Wunsch, das BS doch bitte modular zu machen.
Da stimm ich dir mal zu ;-P
Passiert halt wenn man nen OS zur eierlegenden Wollmilchsau aufbläht und QS für unwichtig hält.
"…ich erwarte dann von MS…"
der war gut…rofl