Austausch unter IT-Professionals - Erfahrungen, Tipps, Fachsimpelei

Zur Abwechslung gibt's zwei 0-Days für Windows:
Chaotic Eclipse zwei 0-Day-Windows Schwachstellen (YellowKey, GreenPlasma), eine in MS Teams

Wobei ich YellowKey besonders elegant finde. Im Gegensatz zu den Bitpixie-Schwachstellen benötigt man hier kein Bootloader-Downgrade (mit Ablaufdatum Oktober 2026), sondern nur einen USB-Stick mit ein paar präparierten Dateien um BitLocker zu umgehen. Zudem schreibt der Autor, dass TPM+PIN hier keine Abhilfe schafft:
Second thing is, No, TPM+PIN does not help, the issue is still exploitable regardless, I asked myself this question, can it still work in a TPM+PIN environment ? Yes it does, I'm just not publishing the PoC, I think what's out there is already bad enough.
Ergänzung: Das benötigt dann wohl aber einen anderen Exploit. Wie der funktionieren soll? Keine Ahnung.

Der Artikel erklärt die Exploits besser:
Windows BitLocker zero-day gives access to protected drives, PoC released
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: konkretor
Fliegt wer von euch zur Dell Technologies World?
evtl. sieht man sich da?
 
Warum sollte man auf so ne Herstellerveranstaltung? Wenn würde ich in Deutschland auf Cloud Festival oder die ISC.
 
  • Gefällt mir
Reaktionen: holdes und konkretor
https://www.phoronix.com/news/Linux-ssh-keysign-pwn

Den Exploit gibts gleich mal wieder mit. Es gibt zwar einen Patch im Vanilla Kernel aber bis der wieder in den Distris landet dauert es halt wieder.

Ich bin mir da aktuell unsicher wie man mit der aktuellen Lage umgehen soll. Sobald ein fix im Kernel öffentlich sichtbar ist, kann mit einem LLM noch schneller ein Exploit gebaut werden. Früher brauchte es noch einige Tage, heute ist es in Stunden / Minuten fertig gebaut.
 
Ich selber habe wenig bis garnix mit Linux Servern zu tun.
Aber ich habe eine ganze Flotte an verschiedenen Hersteller Appliances in meiner Verantwortung, die alle auf irgendeinem Linux OS laufen.
Die sind gekapselt, an eine Linux CLI kommt man in der Regel nicht, nur ueber den Herstellersupport.

Welche von diesen Luecken fuer solche Appliances relevant ist, ist ja leider vollkommen undurchsichtig. Herstellerupdates kommen zwar, aber eher unregelmaessig, und es ist oft ein groesserer Aufwand die einzuspielen.

Ich bin gespannt wie es damit weitergeht...
 
Das seh ich hier ebenfalls, sowohl Hardware Appliance, als auch vom Hersteller bereitgestelltes VM-Image auf dessen Linux wir keinen direkten Zugriff haben. Aber noch hat auch niemand nachgefragt, so wie der Support vom dem Hersteller aber grade allgemein läuft....wird spaßig.
 
@konkretor ich wollte es gerade auch schreiben. Nen exploit Code gibt es wohl direkt seit Tag 0 aber er ließ sich nicht direkt per Google finden. Das war wohl erst gestern so. Immerhin. Trotzdem richtig Kacke. Was ich dazu genau denke verkneif ich mir mal. Wenn es interessiert kann ja ins Aquarium schauen...

Was Herstellerfixes anbelangt wird es spannend.

Ich denke aber so lange man nicht direkt auf ein System kommt wird es jetzt nicht sooo ein riesiges Problem sein. Es sei denn man kann beliebigen Code im User Kontext ausführen. Dann hast du vermutlich verloren.

Das bittere ist halt das aktuell immer gleich ein POC mitgeliefert wird. Das macht es halt Skriptkiddies extrem einfach und erhöht den sofortigen Handlungsdruck.

Wenn ich dran denke, dass das alles "nur" 7.8er Scores sind aber binnen Stunden gefixed werden sollen, dann ist das sicherlich darauf zurückzuführen. 8er hatten normal mehr Zeit gehabt...

Wenn du wie ich mit Systemen arbeitest die du ohne Schaden nicht einfach rebooten kannst, dann ist das halt echt bitter....

Zum Glück waren die mitigations bei uns ohne reboot einspielbar. Aber verursacht dennoch ziemlich Arbeit die niemand einplant.

Solche Fälle sind ja auch die absolute Ausnahme und kommen nur alle paar Jahre vor. Oh wait das waren ja jetzt 3 Fälle in 2 Wochen wenn ich das richtig sehe....

Und die Erwartungshaltung ist das da erstmal noch viel mehr kommt...
 
  • Gefällt mir
Reaktionen: konkretor
Bin ganz bei dir die Zeit um Lücken zu fixen wird immer kleiner. Die Angriffsfläche immer größer , die Schere wird immer größer . Bei den Verantwortlichen ist noch nicht angekommen das du mittlerweile ein erheblicher Anteil der Arbeitszeit in patchen investiert. Neulich mit meinem Chef Chef diskutiert. War mühselig zumindest ist angekommen.

Ich patche Lücken mittlerweile ganz pragmatisch.

https://www.first.org/epss/

Ich nutze mittlerweile den EPSS Score um hier für mich Prioritäten zu setzen. Der Score zeigt an wie hoch die Wahrscheinlichkeit ist das der Exploit ausgenutzt wird. Desto höher desto schneller patche ich. Alles andere muss warten. Firmen die keinen Automatismus haben um so etwas flächendeckend zu Regeln. Da wird's lustig.
Im SAP wo ich aktuell neuerdings unterwegs bin werden Monate keine Patches installiert. Ich habe noch nicht raus gefunden wieso und weshalb. Da geben sich die SAP Basis Leute etwas zugeknöpft. Ich werde es noch raus finden.
 
  • Gefällt mir
Reaktionen: Skysnake
Ja so mache ich das auch. Wenn es über Netz geht ist richtig schlimm wenn man schon Nutzer sein muss nicht ganz so sehr, da ich zwar prinzipiell von Innentätern ausgehen, aber nicht unter den Nutzern selbst die legitim auf die Systeme dürfen
 
Und die nächste Runde mitigations ausrollen...
https://almalinux.org/blog/2026-05-15-ssh-keysign-pwn-cve-2026-46333/

Nur damit ihr nicht lange suchen müsst. Exploit ist natürlich gleich mit dabei. Sogar in doppelter Ausfertigung:
https://github.com/0xdeadbeefnetwork/ssh-keysign-pwn

Mitigation scheint aber wieder ohne reboot zu gehen laut Almalinux. Ich würde jetzt auch mal erwarten das es nicht viel Software mit berwchtigtwm Interesse die damit ein Problem hat. Wobei debugging Tools und vielleicht irgendwelche Security Sachen dann halt vermutlich nicht mehr gehen.. Aber als Notmaßnahme muss man halt eventuell damit klar kommen.

Code:
sudo sysctl -w kernel.yama.ptrace_scope=[COLOR=rgb(208, 191, 105)]3[/COLOR]
[COLOR=rgb(208, 168, 255)]echo[/COLOR] [COLOR=rgb(252, 106, 93)]'kernel.yama.ptrace_scope = 3'[/COLOR] | sudo tee /etc/sysctl.d/99-ssh-keysign-pwn.conf
Ergänzung ()

Hab ich schon erwähnt das ich es absolut geil finde wie aktuell das responsible disclosure gelebt wird?

🤮
 
  • Gefällt mir
Reaktionen: konkretor
https://www.openwall.com/lists/oss-security/2026/04/28/15
https://www.openwall.com/lists/oss-security/2026/05/14/2

Ich hab die Links von einem Kumpel bekommen. Er arbeitet in der Security Branche seit Jahrzehnten. Ich diskutiere mit ihm auch gerade das Thema "responsible disclosure".
Das trifft gerade alle OOS Projekte da hier der Code öffentlich ist und die Firmen Produkte dadurch verkaufen wollen. Zeigen her unser KI Gedoehns irgendwas Agent hat kann folgendes finden. Das müsst ihr kaufen um "sicher" zu sein. Durch die ganzen LLM sinkt aktuell die Zeit um anhand eines Patches einen Exploit zu erstellen von Tagen auf Stunden / Minuten. Ich gehe davon aus die Distris müssen sich bewegen in Richtung Vanilla Kernel. Ein RHEL / SUSE / Ubuntu Kernel so unterschiedlich sind, das hier immer Zeit gebraucht wird um Patches einzubauen im aktuellen Stand. Wie lange hat RHEL gebraucht um CopyFail einzubauen. RHEL ist dafür bekannt Dinge aus dem aktuellen Kernel back zu porten. Das braucht Zeit um alles mögliche zu beachten.

Schaut euch den Patch für den aktuellen Kernel an

https://git.kernel.org/pub/scm/linu.../?id=31e62c2ebbfdc3fe3dbdf5e02c92a9dc67087a3a

2026-05-14 08:32:11 -0700

Die Patches für die LTS Kernel kamen ein Tag später

Fri, 15 May 2026 15:05:38 +0200

In der Zeit hast du schon einen Exploit mit einem LLM bauen lassen. Der Code muss ja nicht fancy StyleGuide geschrieben sein. Er muss funktionieren so etwas bekommst mit einem LLM locker hin.
Auch beim Kernel werden wir wohl in den nächsten Monaten Änderungen sehen müssen. Nur den Patch für den aktuellen Kernel und die LTS Kernel was die meisten Distris nutzen erst einen Tag später zu patchen, gibt den Distris noch weniger Zeit.

Beispiel QEMU keine 14 Stunden alt.
https://github.com/v12-security/pocs/tree/main/qemu

Wurde auch durch einen Agenten gefunden, nicht so dramatisch da in QEMU CXL noch nicht weit verbreitet ist. Exploit wird gleich mit geliefert. Die Firma will Zeigen wie toll sie ist und scheißt auf den responsible disclosure.

Rocky hat angefangen ein Repo raus zu geben um schneller patches zu verteilen.

https://www.phoronix.com/news/Rocky-Linux-Security-Repo

Das hier geht in eine ähnliche Richtung
https://borncity.com/blog/2026/05/1...ruenden-wohl-alle-oeffentlichen-repositories/

Wir müssen uns dieser Realität nun annehmen. Das trifft ja OSS und Closed Source ebenso.
Wir sehen hier gerade die Umwälzungen was es bedeuetet KI/LLM im Alltag zu erleben.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: nutrix und Skysnake
Das "geile" ist halt wenn du jetzt an Enterprise Software denkst. Die ist doch so veraltet und unbeweglich usw das du überhaupt keine Chance hast da irgendwas zu machen...

Die sind doch bereits mit dem Umstieg von Redhat7 auf 8 überfordert gewesen. Ich sags mal so erst mit 8.10 hat es dann so langsam angefangen wieder rund zu laufen.

Von RedHat 9 reden wir mal lieber erst gar nicht. Da gibt es Unmengen an Enterprise Software die das noch nicht supported weil "zu neu"....

Ich bin echt am überlegen was wir da machen sollen. Im Prinzip muss man vermutlich hingehen und wirklich jedweden einzelnen User als eigenen Tenant betrachten und volle multi Tenant Fähigkeit durchprügeln.

Wobei auch dann ist er root. Also muss man ihn vermutlich in nen rootleas Container innerhalb ner memory encrypted VM packen.

Wobei ob das wirklich hilft???

An sich musst du trotzdem schnell patchen. Hilft irgendwie alles nicht so wirklich.

Ich sollte aber definitiv mehr Gels verlangen für die Scheiße der Großteil der Kollegen ist meiner Einschätzung nach damit überfordert. Vor allem mit der nötigen Geschwindigkeit und das man an sich selbst harte Entscheidungen treffen muss die im Zweifel auch zu weiteren Üroblemen führen...

An sich müssten wir mindestens zweischichtbetrieb fahren mit echter Doppelspitze. Den.zweiten 100% Chef könnte ich ja übernehmen 😉

Aber der Knaller ist das bei uns ein Security Audit ansteht. Perfektes Timing..
 
konkretor schrieb:
Ich hab die Links von einem Kumpel bekommen. Er arbeitet in der Security Branche seit Jahrzehnten. Ich diskutiere mit ihm auch gerade das Thema "responsible disclosure".
Das trifft gerade alle OOS Projekte da hier der Code öffentlich ist und die Firmen Produkte dadurch verkaufen wollen. Zeigen her unser KI Gedoehns irgendwas Agent hat kann folgendes finden. Das müsst ihr kaufen um "sicher" zu sein. Durch die ganzen LLM sinkt aktuell die Zeit um anhand eines Patches einen Exploit zu erstellen von Tagen auf Stunden / Minuten.
Hatte ich hier auch schon erwähnt
https://www.computerbase.de/forum/threads/rollback-bei-virusbefall.2257016/page-2#post-31058136
https://www.computerbase.de/forum/t...-immer-vornehmen.2259986/page-2#post-31135761
Diverser Hackergruppen sind heute auch hochspezialisiert und nutzen professionell auch Automation und entsprechende Infrastruktur incl. KI.

Momentan bekommen wir dauernd Sicherheitswarnungen für diverse NPM-Packete und VS Code Erweiterungen, welche die Entwickler so nutzen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: konkretor
Mordi schrieb:
Also die enterprise software von meinem AG unterstützt auch schon EL 10 und Ubuntu 26 :P
Das ist toll, aber nicht der Standard.

Schau dir mal allein irgendwelche CAD/CAE Software an. Das ist der absolute Graus.

Und so geht es halt grad weiter. Enterprise heißt für mich überwiegend: wir sind zu langsam und träge um unsere Software auf neuen Systemen zu supporten, da wir nen riesigen Karren an technischen Schulden mit uns herumschleppen...
 
  • Gefällt mir
Reaktionen: holdes und konkretor
Das ist generell eine unfassbar nervige Sache. Selbst unter Windows Server wenn man auf MSSQL gebunden ist dauert es ewig bis irgendwas freigegeben wird unabhängig davon ob SQL selbst 100% kompatibel ist, muss ja nichtmal das komplette OS selbst betreffen.
 
Zurück
Oben