BungeeCord und Minecraft: Sicherheitsprobleme und Gefahren

Bungee in Kürze

BungeeCord ist ein Proxyserver, mit dem Spielprojekte mehrere Minecraft-Server kombinieren und schnell zwischen ihnen wechseln können.



In diesem Artikel werde ich meine Erfahrungen mit dem Kernel teilen, über Sicherheitsprobleme auf Servern sprechen, die ihn verwenden, und einige einfache Tipps geben, die helfen können, das Hacken eines solchen Servers zu verhindern.



Kurz gesagt, wo BungeeCord am häufigsten verwendet wird:

• Server mit verschiedenen Spielmodi (einschließlich Server mit Minispielen)
• Server mit hoher Auslastung und der Notwendigkeit einer Online-Verteilung
• Server, die einen BotFilter-basierten Schutz gegen Bot-Angriffe verwenden (ein charakteristisches Merkmal eines solchen Servers ist eine "Drop-Check" oder ein Captcha beim Anmelden)

Die häufigsten Sicherheitslücken solcher Server:

• Unkontrollierter Zugriff auf Proxy-Server-Befehle
• Umgehung des Autorisierungsservers
• Spielerdaten fälschen
• Sicherheitslücken in Staging-Servermodulen

Wie es funktioniert

Die meisten von BungeeCord ausgeführten Projekte stellen die folgende Serverkette dar (die sich auf mindestens einer IP mit unterschiedlichen Ports befinden kann, selbst auf Computern in verschiedenen Teilen der Welt).

Proxy

Die erste Stufe - in der Tat ist dies der Server selbst, mit dem die Spieler verbunden sind. Er hat keinen Spawnpunkt oder keine Spielwelten - seine Aufgabe ist es, die Verbundenen auf die nächste Stufe umzuleiten.



Hier scheint alles einfach zu sein - aber nein.



Der Hauptcharme und gleichzeitig das Problem in dieser Phase ist die Umleitung selbst - der Server leitet den Player nicht nur auf eine andere IP um, sondern spielt die Rolle eines Zwischenservers.

Einfach ausgedrückt, alle Befehle, die der Player sendet, alle Synchronisierungspakete und jede Nachricht im Chat werden hier zuerst verarbeitet.

Wie bedroht uns das?

Lassen Sie mich anhand eines hypothetischen Beispiels erklären: Unser Entwickler Drygok, der tapfer seine Arbeit erledigt, hat die Rechte auf den Servern nahezu maximal. Er hat sein Konto perfekt mit seinem eigenen Autorisierungssystem geschützt - einem komplexen Passwort, einer Zwei-Faktor-Authentifizierung und sogar der Bindung an einen bestimmten Bereich von IP-Adressen seines Anbieters. Danach verlässt er den Server beruhigt, aber nach 10 Minuten „fliegen“ alle Spieler aus und die Server stoppen weil jemand den Befehl / end in seinem Namen ausgeführt hat.



Was ist passiert? Es ist ganz einfach: Eine unbekannte Person hat das Spiel unter dem Spitznamen unseres Entwicklers betreten und, ohne die Anmeldeanforderungen des Servers zu beachten, einen Befehl eingegeben, der vom Proxyserver selbst verarbeitet wird. Dies bedeutet, dass er selbst für nicht autorisierte Benutzer nicht verhindert werden kann.

Wie man etwas vorbeugt?

Der einfachste Weg, solche Situationen zu verhindern, besteht darin, alle internen Kernelbefehle zu deaktivieren und alle Rechte in dieser Phase zurückzusetzen. Auch für einen Entwickler. Besonders für einen Entwickler.

Autorisierungsserver

Die zweite Stufe in der Kette ist der Server, auf dem sich der Spieler registriert und anmeldet.



Hier spürt unser Benutzer zuerst den festen Würfelboden unter seinen geometrischen Füßen.



Meistens sehen die Server dieser Phase ungefähr so ​​aus:

• Ein kleines Stück Land im endlosen Raum einer leeren Welt, in dem der Spieler vor einer erfolgreichen (oder nicht erfolgreichen) Autorisierung steht
• Grundlegende Plugins:
  
  SkinsRestorer - , , -

( , )

, ( )

, ( AI , , .)

,

AutoSaveWorld
  
  
• Keine Kontrolle der Rechte
• Fehlende Schutzsysteme gegen Kernel-Schwachstellen oder das Spiel selbst

Das Hauptproblem in dieser Phase sind die Notfallrechte für die Spieler. Selten konfiguriert jemand sie, da sie nur von einem autorisierten Spieler verwendet werden können. Wenn der Spieler autorisiert ist, wird er sofort zur nächsten Stufe weitergeleitet.

Wie bedroht uns das?

In einigen Fällen kann der Spieler die Umleitung auf einen anderen Server nach der Autorisierung verhindern: Oft werden schnelle Wiederverbindungen zum Spielserver durch den Kernel oder die Plugins dieses Servers verhindert. Wenn der Player die Verbindung sofort nach erfolgreicher Autorisierung wieder herstellt, kann der Server in der nächsten Phase die Verbindung ablehnen und der autorisierte Player bleibt auf dem Autorisierungsserver.



Außerdem lernt der Spieler, der über erhöhte Rechte verfügt, leise die Liste der in unserem Land installierten Plugins (/ Plugins) und beginnt dann sein dunkles Geschäft, indem er ihre Fähigkeiten mit den Rechten lernt, die er besitzt.



Ich werde zwei Beispiele nennen, die ich mehr als einmal persönlich getroffen habe.



Erstes Beispiel. Zugang zu ASW.



AutoSaveWorldIst ein äußerst nützliches und gleichzeitig gefährliches Plugin für jeden Server. Seine Fähigkeiten in meiner Nacherzählung, kurz:

• Rette automatisch die Welt
• Automatische Weltsicherung
• Reinigen Sie die Welt gemäß den angegebenen Einstellungen
• Plugins verbinden, neu starten und trennen, ohne den Spieleserver neu zu starten (/ asw pmanager)
• Starten, Stoppen und Steuern von gespawnten Prozessen (/ asw process)

Wir interessieren uns für den letzten Artikel aus dieser Liste.



Nein, das ist kein Fehler. Auf einer großen Anzahl von Servern gibt es wirklich ein Plugin, mit dem Sie jeden Prozess mit dem entsprechenden Zugriff starten können, den einige Server derzeit allen Spielern zur Verfügung stellen.



In diesem Fall sind einige /asw process start QQHABR rm -rf / (DIESEN BEFEHL NICHT DURCHFÜHREN!) Das geringste Problem. Ich denke, es lohnt sich nicht zu sagen, was ein "Cracker" mit dem Zugang zum Terminal anfangen kann.



Beispiel zwei. Ein harmloser SkinsRestorer.



SkinsRestorerIst ein äußerst beliebtes Plugin, das auf einer Vielzahl von Servern verwendet wird. Es wird hauptsächlich zum Wiederherstellen von Skins verwendet, die aufgrund der Verwendung von Proxy-Skins verloren gegangen sind. Es kann jedoch auch eigene Skins installieren. Diese Gelegenheit ist eine potenzielle Sicherheitslücke.



Mit dem Befehl / skin können Sie nicht nur den Skin eines anderen Spielers mit seinem Spitznamen laden, sondern auch Ihren eigenen festlegen, indem Sie die Bildadresse (/ skin URL) angeben. Die Gefahr dieses Teams liegt in der Tatsache, dass der anfängliche Zugriff für die Spieler vorgesehen ist (und nicht nur, wenn die Rechte falsch konfiguriert sind, wie im Fall von ASW).



Wie kann das genutzt werden? Das Hochladen eines Bildes an die angegebene Adresse ist eine reguläre GET-Anforderung. Eine Anfrage vom Server selbst.



Es gibt viele Optionen für die weitere Verwendung - beginnend mit einem Aufruf einer geschlossenen API (z. B. Ausgabe einer Spende), auf die für bestimmte IP-Adressen zugegriffen wird, und endend mit einer regelmäßigen Flut.

Wie man etwas vorbeugt?

Sie können dies verhindern, indem Sie die Rechte der Spieler einschränken (was auf jedem Server empfohlen wird), alle möglichen Befehle außer den Autorisierungs- und Registrierungsbefehlen blockieren und auch die Installation Ihres eigenen Skins per URL verbieten (ich empfehle dies auf allen Servern).

Nabe

Hub - ein gemeinsamer Bereich, in dem Spieler einen Spieleserver und







-modus auswählen. Meistens sind Hubs wie die Hauptspielserver für jeden Server eindeutig, einige Sicherheitsprobleme sind jedoch für sie gleich.

Direkte Verbindung

Durch die direkte Verbindung mit diesem Server (mit seiner IP) kann der Player die vorherigen Phasen einschließlich der Autorisierung umgehen

Wie bedroht uns das?

Nachdem die Autorisierungsphase übersprungen wurde, kann der Player alle Rechte des Benutzers verwenden, dessen Spitzname für die Verbindung verwendet wurde

Wie man etwas vorbeugt?

Die meisten Serverkerne verfügen über eine integrierte Einstellung zum Blockieren von Verbindungen ohne Verwendung von BungeeCord. Zum Beispiel Spigot in spigot.yml:

settings:
bungeecord: true

Wenn Sie diese Einstellung verwenden, lesen Sie unbedingt den nächsten Absatz!

Spielerdaten fälschen

Fast alle Serverkerne, die die direkte Verbindung zum Server blockieren (einschließlich Spigot), weisen eine aktive Sicherheitsanfälligkeit im Zusammenhang mit der Ersetzung von Spielerdaten durch ihren eigenen BungeeCord-Server auf: Der Spieler stellt seinen Proxyserver so um, dass Verbindungen zu unserem Hauptspielserver umgeleitet werden, also zum Kern Der Spieleserver stellt fest, dass BungeeCord zum Verbinden verwendet wird, und vertraut allen von ihm übertragenen Daten (die Proxy-IP wird in diesem Fall nicht auf Übereinstimmung mit der Server-IP überprüft).

Wie bedroht uns das?

In den meisten Fällen werden die folgenden Elemente auf diese Weise ersetzt: IP des Spielers (Umgehen von Sitzungen und Zugriff auf das Konto eines anderen Benutzers) und UUID (von einigen Plugins und dem Server selbst verwendet, um den Spieler zu identifizieren, die Rechtekontrolle zu umgehen und auf die Rechte anderer Spieler zuzugreifen).



Wenn Sie BungeeCord verwenden, müssen Sie das Problem selbst beheben. Andernfalls kann ein Angreifer nicht nur auf Spielerkonten, sondern auch auf die Funktionen von Administratoren zugreifen!

Wie man etwas vorbeugt?

Der einfachste Weg, dies zu verhindern, besteht darin, unnötige Ports für Verbindungen von Drittanbietern zu schließen und => jede Möglichkeit, über den Proxyserver eine Verbindung zum Server herzustellen.



Es wird empfohlen, für eine externe Verbindung alle Ports aller Server außer dem Haupt-BungeeCord-Server zu schließen!

Spieleserver

Spieleserver mit eigenen Modi. All dies ist relevant.