Bungee en bref
BungeeCord est un serveur proxy qui permet aux projets de jeu de combiner plusieurs serveurs Minecraft avec la possibilité de basculer rapidement entre les joueurs.
Dans cet article, je vais partager mon expérience avec le noyau, parler des problèmes de sécurité sur les serveurs qui l'utilisent et également donner quelques conseils simples qui peuvent aider à empêcher le piratage d'un tel serveur.
En bref, où BungeeCord est le plus souvent utilisé:
- Serveurs avec plusieurs modes de jeu (y compris les serveurs avec mini-jeux)
- Serveurs à forte charge et nécessitant une distribution en ligne
- Serveurs qui utilisent une protection basée sur BotFilter contre les attaques de bots (une caractéristique d'un tel serveur est un "drop check" ou captcha lors de la connexion)
Les vulnérabilités les plus courantes de ces serveurs:
- Accès incontrôlé aux commandes du serveur proxy
- Contournement du serveur d'autorisation
- Usurpation des données du joueur
- Vulnérabilités dans les modules de serveur de transfert
Comment ça fonctionne
La plupart des projets gérés par BungeeCord sont la chaîne de serveurs suivante (qui peut être située sur au moins une IP avec différents ports, même sur des machines dans différentes parties du monde).
Procuration
La première étape - en fait, c'est le serveur lui-même, auquel les joueurs sont connectés. Il n'a pas de point d'apparition ni de mondes de jeu - sa tâche est de rediriger les connectés vers l'étape suivante.
Il semblerait que tout soit simple ici - mais non.
Le charme principal, et en même temps le problème à ce stade, est la redirection elle-même - le serveur ne redirige pas seulement le joueur vers une autre IP, mais joue le rôle d'un serveur intermédiaire.
En termes simples, toutes les commandes que le joueur envoie, tous les paquets de synchronisation, chaque message du chat sont traités ici en premier.
Comment cela nous menace-t-il?
Laissez-moi vous expliquer avec un exemple hypothétique: notre développeur Drygok, faisant vaillamment son travail, a les droits sur les serveurs proches du maximum. Il a parfaitement protégé son compte avec son propre système d'autorisation - un mot de passe complexe, une authentification à deux facteurs et même une liaison à une plage spécifique d'adresses IP de son fournisseur, après quoi il quitte le serveur l'esprit tranquille, mais après 10 minutes tous les joueurs «s'envolent» et les serveurs s'arrêtent parce que quelqu'un a exécuté la commande / end en son nom.
Qu'est-il arrivé? C'est simple: une personne inconnue est entrée dans le jeu sous le surnom de notre développeur et, ignorant la demande de connexion du serveur, a entré une commande qui est traitée par le serveur proxy lui-même, ce qui signifie qu'elle ne peut pas être empêchée même pour les utilisateurs non autorisés.
Comment empêcher?
Le moyen le plus simple d'éviter de telles situations est de désactiver toutes les commandes internes du noyau et de réinitialiser les droits à ce stade. Même pour un développeur. Surtout pour un développeur.
Serveur d'autorisation
La deuxième étape de la chaîne est le serveur sur lequel le joueur s'enregistre et se connecte.
C'est ici que notre utilisateur ressentira d'abord le sol cubique solide sous ses pieds géométriques.
Le plus souvent, les serveurs de cette étape ressemblent à ceci:
- Un petit lopin de terre dans l'espace infini d'un monde vide, où le joueur se tient devant une autorisation réussie (ou pas)
- Plugins de base:
SkinsRestorer - , , -
( , )
, ( )
, ( AI , , .)
,
AutoSaveWorld
- Absence de contrôle des droits
- Absence de système de protection contre les vulnérabilités du noyau ou le jeu lui-même
Le principal problème à ce stade concerne les droits d'urgence pour les joueurs. Rarement quelqu'un les configure, car seul un joueur autorisé peut les utiliser, et lorsque le joueur est autorisé, ils redirigent immédiatement vers l'étape suivante.
Comment cela nous menace-t-il?
Dans certains cas, le joueur peut empêcher la redirection vers un autre serveur après autorisation: Souvent, les reconnexions rapides au serveur de jeu sont empêchées par le noyau ou les plugins de ce serveur. Ainsi, lorsque le joueur se reconnecte immédiatement après une autorisation réussie, le serveur à l'étape suivante peut rejeter la connexion et le joueur autorisé restera sur le serveur d'autorisation.
De plus, le joueur qui a des droits élevés apprend tranquillement la liste des plugins installés dans notre pays (/ plugins), puis, apprenant leurs capacités avec les droits dont il dispose, commence sa sombre entreprise.
Je vais donner deux exemples que j'ai personnellement rencontrés plus d'une fois.
Premier exemple. Accès à ASW.
AutoSaveWorldEst un plugin extrêmement utile et en même temps dangereux pour n'importe quel serveur. Ses capacités dans mon récit, brièvement:
- Sauver automatiquement le monde
- Sauvegarde mondiale automatique
- Nettoyer le monde selon les paramètres spécifiés
- Connexion, redémarrage et déconnexion des plugins sans redémarrer le serveur de jeu (/ asw pmanager)
- Démarrer, arrêter et contrôler les processus générés (processus / asw)
Nous sommes intéressés par le dernier élément de cette liste.
Non, ce n'est pas une erreur. Sur un grand nombre de serveurs, il existe vraiment un plugin qui vous permet de démarrer n'importe quel processus avec l'accès approprié, que certains serveurs fournissent à tous les joueurs à ce stade.
Dans ce cas, certains
/asw process start QQHABR rm -rf / (N'EXÉCUTEZ PAS CETTE COMMANDE!) Seront le moindre des problèmes. Je ne pense pas que cela vaille la peine de dire ce qu'un "cracker" peut faire avec l'accès au terminal.
Exemple deux. Un SkinsRestorer inoffensif.
SkinsRestorerEst un plugin extrêmement populaire utilisé sur un grand nombre de serveurs. Il est principalement utilisé pour récupérer les skins manquants en raison de l'utilisation de skins proxy, mais il a également la possibilité d'installer les vôtres. Cette opportunité même est une vulnérabilité potentielle.
En utilisant la commande / skin, vous pouvez non seulement charger le skin d'un autre joueur avec son pseudo, mais également définir le vôtre en spécifiant l'adresse de l'image (/ URL du skin). Le danger de cette équipe réside dans le fait que l'accès à celle-ci est initialement supposé pour les joueurs (et pas seulement si les droits sont mal configurés, comme dans le cas d'ASW).
Comment cela peut-il être utilisé? Le téléchargement d'une image à l'adresse spécifiée est une demande GET standard. Une requête exécutée à partir du serveur lui-même.
Il existe de nombreuses options pour une utilisation ultérieure - à commencer par un appel à une API fermée (par exemple, émettre un don), dont l'accès est fourni pour certaines adresses IP et se terminer par une inondation régulière.
Comment empêcher?
Vous pouvez empêcher cela en restreignant les droits des joueurs (ce qu'il est recommandé de faire sur n'importe quel serveur), bloquer toutes les commandes possibles à l'exception des commandes d'autorisation et d'enregistrement, et également interdire l'installation de votre propre skin par URL (je recommande de le faire sur tous les serveurs)
Centre
Hub - un espace commun où les joueurs vont sélectionner un serveur et un mode de jeu. Le
plus souvent, les hubs, comme les serveurs de jeu principaux, sont uniques pour chaque serveur, mais certains problèmes de sécurité sont les mêmes pour eux.
Connexion directe
En se connectant directement à ce serveur (à son IP), le joueur peut contourner les étapes précédentes, notamment l'autorisation
Comment cela nous menace-t-il?
Après avoir sauté l'étape d'autorisation, le joueur peut utiliser tous les droits de l'utilisateur dont le pseudo a été utilisé pour se connecter
Comment empêcher?
La plupart des cœurs de serveur ont un paramètre intégré pour bloquer les connexions sans utiliser BungeeCord. Par exemple Spigot dans spigot.yml:
settings:
bungeecord: trueSi vous utilisez ce paramètre, assurez-vous de lire le paragraphe suivant!
Usurpation des données du joueur
Presque tous les cœurs de serveur qui bloquent la connexion directe au serveur (y compris Spigot) ont une vulnérabilité active liée à la substitution des données du joueur via leur propre serveur BungeeCord: le joueur met son serveur proxy avec des connexions de redirection vers notre serveur de jeu principal, donc le noyau le serveur de jeu détermine que BungeeCord est utilisé pour se connecter et fait confiance à toutes les données transmises par lui (l'IP proxy n'est pas vérifiée pour une correspondance avec l'IP du serveur dans ce cas)
Comment cela nous menace-t-il?
Le plus souvent, les éléments suivants sont remplacés de cette manière: l'adresse IP du joueur (contournement des sessions et accès au compte de quelqu'un d'autre) et l'UUID (utilisé par certains plugins et le serveur lui-même pour identifier le joueur, contourner le contrôle des droits et accéder aux droits des autres joueurs).
Lorsque vous utilisez BungeeCord, vous devez le réparer vous-même, sinon cela pourrait permettre à un attaquant d'accéder non seulement aux comptes des joueurs, mais aussi aux capacités des administrateurs!
Comment empêcher?
Le moyen le plus simple d'éviter cela est de fermer les ports inutiles pour les connexions tierces, et => toute possibilité de se connecter au serveur en contournant le serveur proxy.
Il est recommandé de fermer pour une connexion externe tous les ports de tous les serveurs à l'exception du serveur BungeeCord principal!
Serveurs de jeu
Serveurs de jeu avec leurs propres modes. Tout ce qui précède est pertinent.