zypherion-technologies/vulnariumEin Sicherheitsforschungsarchiv, das Schwachstellen, technische Analysen und PoC-Demonstrationen dokumentiert.
Zwei unabhängige LPEs; MSI ist eher ein UAC-Bypass über TOCTOU und NL sind LPE-Schwachstellen, die bei der Sicherheitsforschung gefunden wurden. Jede hat einen funktionierenden Proof of Concept.
Rechteausweitung über die MSI-Center-Dienstbrücke und den Terminalserver.
MSI Center führt einen SYSTEM-Dienst (MSI_Center_Service) aus, der eine lokale TCP-Brücke auf Port 32683 bereitstellt. Jeder Prozess auf der Maschine kann sich damit verbinden. Daher akzeptiert die Brücke einen Steuercode, der einen zweiten Listener, den Terminalserver, auf Port 26822 startet. Dieser Terminalserver akzeptiert JSON-Befehle, von denen einer RunSetupModule ist. Der Befehl nimmt einen Komponentennamen, eine Parameterzeichenfolge und eine Liste abhängiger Dateien entgegen. Der Dienst löst die abhängigen Dateien in C:\MSI\MSI Center\Setup auf und führt die Komponente dann mit hoher Integrität aus.
Der PoC sendet eine RunSetupModule-Anfrage, die auf eine abhängige Datei namens elevcmd.exe verweist. Während der Dienst das Verzeichnis einrichtet, legt der PoC eine Kopie von cmd.exe unter diesem Namen im Setup-Pfad ab. Der Dienst nimmt sie auf und führt sie mit erhöhten Rechten aus. Der erzeugte Prozess erbt die hohe Integritätsstufe des Dienstes, sodass ein Standardbenutzer eine Eingabeaufforderung mit erhöhten Rechten erhält, ohne jemals einen UAC-Dialog zu sehen.
MSI-Elev.go
Beliebiges Schreiben von Dateien in das NetLimiter-Installationsverzeichnis über CNLService.InstallIp2LocDB. Der Dienst entpackt ein ZIP-Archiv in einen Pfad unter ProgramData, ohne das Ziel zu bereinigen. Eine Verzeichnisverknüpfung (Directory Junction) leitet die Extraktion in Program Files um und platziert eine bösartige NLog-Ziel-DLL, die der SYSTEM-Dienst beim nächsten Log-Ereignis lädt.
2 Dinge kannst du tun: entweder neu starten, um das Ergebnis sofort zu sehen (den Dienst mit Admin), oder du kannst einfach neu booten, und da es beim Systemstart läuft, wird es automatisch ausgelöst.
Gemeldet: 17. Juli 2026
Die MSI-Center-Schwachstelle wurde MSI PSIRT vertraulich gemeldet, zusammen mit einem detaillierten technischen Bericht, einer Reproduktionsmethodik, einer Auswirkungsanalyse und einem Proof of Concept.
MSI bestätigte den Eingang des Berichts und erklärte, dass er zur weiteren Prüfung an das zuständige Team weitergeleitet worden sei. Danach erhielt der Forscher keine substanzielle Rückmeldung bezüglich Validierung, Annahme, Ablehnung, Behebung oder Schwachstellenverfolgung.
Das zugehörige Support-Ticket wurde später ohne substanzielle Entscheidung über die Schwachstelle geschlossen.
Der von MSI veröffentlichte PSIRT-Prozess besagt, dass das Unternehmen bestrebt ist, Meldungen innerhalb von drei Werktagen zu bestätigen und sich im Rahmen des Zumutbaren zu bemühen, innerhalb von dreißig Tagen nach der ersten Bestätigung mitzuteilen, ob eine Schwachstelle bestätigt, akzeptiert oder abgelehnt wird.
Gemeldet: 20. Juli 2026
Die NetLimiter-Schwachstelle wurde Locktime Software vertraulich gemeldet, zusammen mit einer detaillierten technischen Beschreibung, Reproduktionsinformationen, einer Auswirkungsanalyse und einem funktionsfähigen Proof of Concept.
Die Schwachstelle wurde zum Zeitpunkt der Erstmeldung nicht öffentlich bekannt gegeben. Der Forscher erklärte ausdrücklich, dass die technischen Details vertraulich bleiben würden, während der Hersteller das Problem untersuchte und behob.
Zum Zeitpunkt der Veröffentlichung hatte der Forscher weder eine öffentliche Behebung noch einen Sicherheitshinweis erhalten.
Beide Schwachstellen wurden vor jeder öffentlichen Offenlegung privat und in gutem Glauben gemeldet. Keiner der Hersteller lieferte eine substanzielle Antwort. MSI schloss das Ticket, ohne die Schwachstelle zu behandeln. Locktime Software antwortete überhaupt nicht.
Dieses Repository veröffentlicht die Forschung zu Bildungs-, Verteidigungs- und Schwachstellenanalysezwecken, nachdem den Herstellern die Gelegenheit gegeben wurde, die Probleme zu untersuchen und zu beheben.
Das Proof-of-Concept-Material ist nicht dazu gedacht, unbefugte Angriffe auf Systeme Dritter zu erleichtern. Die Nutzer sind dafür verantwortlich, vor der Nachstellung der Forschung eine entsprechende Genehmigung einzuholen.
Die Veröffentlichung von Sicherheitsforschung und Proof-of-Concept-Quellcode ist durch mehrere rechtliche Rahmenwerke geschützt.
Code als geschützte Meinungsäußerung. Die Bundesgerichte der USA haben Quellcode als Ausdrucksform anerkannt, die durch den Ersten Verfassungszusatz geschützt ist. Bernstein v. U.S. Department of Justice, 176 F.3d 1132 (9th Cir. 1999), entschied, dass Quellcode für den Schutz durch den Ersten Verfassungszusatz in Frage kommt. Junger v. Daley, 209 F.3d 481 (6th Cir. 2000), übernahm unabhängig dieselbe Begründung.
CFAA und gutgläubige Sicherheitsforschung. Im Mai 2022 überarbeitete das US-Justizministerium seine Anklagepolitik für den Computer Fraud and Abuse Act und wies die Staatsanwälte an, von der Strafverfolgung gutgläubiger Sicherheitsforschung abzusehen. Die Politik definiert gutgläubige Forschung als den Zugriff auf einen Computer ausschließlich zum Zweck der Prüfung, Untersuchung oder Behebung eines Sicherheitsfehlers, durchgeführt in einer Weise, die darauf ausgelegt ist, Schäden für Einzelpersonen oder die Öffentlichkeit zu vermeiden.
DMCA-Ausnahme für Sicherheitstests. 17 U.S.C. Section 1201(j) sieht eine ausdrückliche Ausnahme für Umgehungshandlungen vor, die zum Zweck von Sicherheitstests durchgeführt werden. Die Library of Congress hat diese Schutzmaßnahmen in aufeinanderfolgenden Regelungszyklen erneuert und erweitert.
Koordinierte Offenlegung von Schwachstellen in der EU. Die NIS2-Richtlinie (2022), Artikel 12, legt Anforderungen an die koordinierte Offenlegung von Schwachstellen fest und beauftragt CSIRTs mit nationalen CVD-Prozessen. Der Cyber Resilience Act (2024) verlangt darüber hinaus, dass Hersteller offengelegte Schwachstellen über definierte Verfahren behandeln.
GitHubs Richtlinie zu Dual-Use-Sicherheitsinhalten. GitHub erlaubt ausdrücklich Proof-of-Concept- und Sicherheitsforschungs-Repositories. Die Richtlinie besagt, dass GitHub „Dual-Use-Inhalte zulässt und das Posten von Inhalten unterstützt, die für die Forschung zu Schwachstellen, Malware oder Exploits verwendet werden, da die Veröffentlichung und Verbreitung solcher Inhalte einen pädagogischen Wert hat und der Sicherheitsgemeinschaft einen Nettonutzen bringt.“ Die Entfernung erfolgt nur, wenn ein Repository aktiv als Infrastruktur für laufende Angriffe genutzt wird.
Beide Schwachstellen in diesem Repository wurden den jeweiligen Herstellern gemeldet, bevor eine öffentliche Offenlegung stattfand. Keiner der Hersteller lieferte eine substanzielle Antwort. Die Forschung wurde in gutem Glauben mit dem Ziel durchgeführt, die Sicherheit der betroffenen Produkte zu verbessern.
Dieser Abschnitt dient nur zu Informationszwecken und stellt keine Rechtsberatung dar.
Copyright (c) 2026 Zypherion Technologies. Alle Rechte vorbehalten.
Es wird die Erlaubnis erteilt, die Inhalte dieses Repositorys für defensive Sicherheitsforschung, Sicherheitsschulung, Schwachstellenanalyse und autorisierte Penetrationstests zu verwenden, zu vervielfältigen und zu verbreiten, sofern alle folgenden Bedingungen erfüllt sind:
Alle weiteren Rechte bleiben vorbehalten. Für kommerzielle Lizenzen oder eine anderweitige Nutzung, die nicht oben abgedeckt ist, kontaktieren Sie [email protected].
