Warnung vor Mods/Addons von BlitzNxah

(Kategorie "Scamming" mangels passender Option, es geht hier um ein Sicherheitsrisiko, nicht um einen nachgewiesenen Scam.)

Hallo meine lieben Mitspieler,
leider muss ich hier eine Warnung aussprechen, vor einer Mod von BlitzNxah.
Ich hab einen genaueren Blick in eine seiner Mods geworfen und hab da einige Red-Flags gesehen.

Die Mod lädt ihren Code bei jedem Start nach (Remote Code Loading)
Die Mod lädt bei jedem Start von Minecraft, unbekannten verschlüsselten Code herunter und führt ihn aus.

Das heißt nicht, dass BlitzNxah böse Absichten hat oder dass die Mod zurzeit Schadsoftware runterlädt.
Aber, der Code der da heruntergeladen wird kann JEDERZEIT geändert werden und wird dann auf allen Geräten ausgeführt, die die Mod installiert haben.

So eine Mod öffnet einige Sicherheitsrisiken. Sowas geht in IT-Sicherheit in Richtung CWE-829 (Code aus einer Quelle, die man selbst nicht kontrollieren kann).

Welche Risiken sind das?

• Keine Kontrolle über den Code:
  Der Code kann jederzeit geändert werden, ohne Update und ohne dass ihr was davon mitbekommt. Was heute harmlos ist, kann morgen was ganz anderes machen.
• Gestohlener Schlüssel:
  Der Code ist zwar signiert, also ein Hack vom Server allein reicht nicht um eigenen Code einzuschleusen. Wenn aber jemand an BlitzNxahs Schlüssel oder seinen PC kommt, kann der über die Mod Code an jeden schicken der sie installiert hat. Bei Fractureiser 2023 wurde auch erst ein kleiner Loader in Mods eingeschleust, der dann den eigentlichen Schadcode von einem Server nachgeladen hat.
• Gezielte Angriffe:
  Der Server weiß genau welcher Account sich gerade anmeldet. Wer den Schlüssel hat (also BlitzNxah selbst, oder wer ihn klaut), müsste also nicht alle infizieren, sondern könnte gezielt einer Person eine andere Version schicken, z.B. einem Teamler oder Streamer. Alle anderen bekommen ganz normal die harmlose Version und keinem fällt was auf.
• Zugriff auf euren PC:
  Minecraft Mods laufen sowieso mit euren vollen Benutzerrechten, auch der nachgeladene Code. Der hätte also theoretisch Zugriff auf eure Dateien, gespeicherte Browser Passwörter, Discord usw.
  Der nachgeladene Code kann außerdem noch eine DLL runterladen und starten (die Funktion dafür ist in der Mod schon drin), die ist um einiges schwerer zu analysieren als Java Code und kann Sachen machen, die mit Java allein nicht so einfach gehen.
  In der Mod selbst hab ich aber nichts gefunden was sowas macht, und euer Minecraft Token geht dort nur an Mojang. Was der nachgeladene Code damit macht, kann man halt nicht sagen.
• Kaum nachprüfbar:
  Die Mod ist stark verschleiert und blockiert Debugger. Wenn also mal was passieren würde, kann man das im Nachhinein kaum nachweisen.

An BlitzNxah:
Falls du das liest, das ist kein Angriff gegen dich. Ich versteh schon, dass du deine Mod vor Cracks schützen willst. Aber so wie das gerade gelöst ist, ist das ein echtes Risiko für deine Nutzer.
Ein paar Vorschläge wie man das besser machen könnte:

• Den Code direkt in die Mod packen, statt ihn bei jedem Start runterzuladen. Eine Lizenzprüfung kann trotzdem online laufen, sie muss halt nur keinen Code nachladen.
• Updates ganz normal veröffentlichen, damit jede Version öffentlich und für alle gleich ist.
• Auf die DLL verzichten, oder sie wenigstens fest in die Mod packen, damit jeder nachschauen kann was sie macht.
• Ein bisschen mehr Transparenz, damit man nachvollziehen kann, was die Mod eigentlich macht.

Bleibt sicher!

Zitat von BlitzNxah

nur mal so wenn ne runtime geupdatet wurde wird sie eh nicht vom client geladen der er vorher den hash überprüft wenn ich nur die runtime ändern würde würde der core nichts laden. Ich kann nicht einfach code aufm server ändern und dann hat die mod nen update wenn es nen update gibt gibt es eh ne neue core da sie sonst nichts einfach so lädt

Hey, danke für die schnelle Antwort.

Dass die Mod noch nicht public ist und du die DLLs in den Core packen willst, find ich gut, das ist genau einer der Punkte.

Das mit dem Hash stimmt aber so nicht ganz. Ich hab mir das nochmal angeschaut. Der Core prüft den Hash vom Core selbst, und bei der Runtime nur ob sie mit deinem Zertifikat signiert ist. Der Hash von der Runtime selbst ist nirgends im Core fest drin. Heißt, eine neue Runtime die du signierst würde auch ohne neuen Core geladen werden.

Wenn du den Hash von der Runtime fest in den Core packst, dann stimmt genau das was du sagst. Dann braucht jede Änderung einen neuen Core, und jeder sieht wenn sich was ändert. Damit wäre der größte Punkt aus meinem Post eigentlich erledigt.

Zitat von BlitzNxah

Kurz zur Erklärung, was die DLL/Dylib macht:

Die Native lädt die Java-Klassen, die vom Server kommen und die eigentliche Mod-Logik enthalten, und definiert sie dann zur Laufzeit in Java. Warum ist der ClassLoader nicht einfach in Java geschrieben? Mein Gedanke war, dass man die Klassen so nicht so einfach aus der JAR extrahieren und auf der Festplatte speichern kann. Deshalb die DLL bzw. Dylib.

Außerdem kommt die Runtime-JAR vom Server AES-verschlüsselt an. Die Native enthält den AES-Schlüssel und entschlüsselt die Runtime zur Laufzeit. Im Java code würde man den Key easy finden deswegen dazu die Native.

Zusätzlich überwacht sie die Core-JAR und prüft regelmäßig deren Hash. Wenn sich die Datei verändert hat, versucht die Native, die Core-JAR zu löschen und beendet das Spiel. Diese Funktion wird von der Runtime über JNI aufgerufen.

Aktenkoffer

Alles anzeigen

Danke für die Erklärung, aber das geht ein bisschen an meinem Punkt vorbei.

Mir geht es nicht darum wie der Code geschützt ist, sondern dass er überhaupt bei jedem Start vom Server geholt und ausgeführt wird. Egal wie gut das verschlüsselt ist, am Ende läuft auf unseren PCs Code den keiner kennt und der jederzeit ein anderer sein kann.