Bungee en breve
BungeeCord es un servidor proxy que permite que los proyectos de juegos combinen varios servidores de Minecraft con la capacidad de cambiar rápidamente de jugador entre ellos.
En este artículo, compartiré mi experiencia con el kernel, hablaré sobre los problemas de seguridad en los servidores que lo utilizan y también daré algunos consejos simples que pueden ayudar a prevenir la piratería de dicho servidor.
Brevemente dónde se usa BungeeCord con más frecuencia:
- Servidores con varios modos de juego (incluidos servidores con minijuegos)
- Servidores con alta carga y necesidad de distribución online
- Servidores que utilizan protección basada en BotFilter contra ataques de bot (un rasgo característico de dicho servidor es un "drop check" o captcha al iniciar sesión)
Las vulnerabilidades más comunes de dichos servidores:
- Acceso incontrolado a los comandos del servidor proxy
- Omisión del servidor de autorización
- Suplantar los datos del jugador
- Vulnerabilidades en los módulos de servidor provisional
Cómo funciona
La mayoría de los proyectos ejecutados por BungeeCord representan la siguiente cadena de servidores (que se pueden ubicar en al menos una IP con diferentes puertos, incluso en máquinas en diferentes partes del mundo).
Apoderado
La primera etapa: de hecho, este es el servidor en sí, al que están conectados los jugadores. No tiene un punto de generación o mundos de juego; su tarea es redirigir a los conectados a la siguiente etapa.
Parecería que aquí todo es simple, pero no.
El encanto principal, y al mismo tiempo el problema en esta etapa, es la redirección en sí: el servidor no solo redirige al jugador a otra IP, sino que desempeña el papel de servidor intermedio.
En pocas palabras, todos los comandos que envía el jugador, todos los paquetes de sincronización, cada mensaje en el chat se procesan aquí primero.
¿Cómo nos amenaza esto?
Permítanme explicarles con un ejemplo hipotético: nuestro desarrollador Drygok, haciendo valientemente su trabajo, tiene los derechos en los servidores cerca del máximo. Protegió perfectamente su cuenta con su propio sistema de autorización: una contraseña compleja, autenticación de dos factores e incluso vinculación a un rango específico de direcciones IP de su proveedor, después de lo cual abandona el servidor con tranquilidad, pero después de 10 minutos todos los jugadores "salen volando" y los servidores se detienen. porque alguien ejecutó el comando / end en su nombre.
¿Que pasó? Es simple: una persona desconocida ingresó al juego con el apodo de nuestro desarrollador e, ignorando las solicitudes del servidor para iniciar sesión, ingresó un comando que es procesado por el propio servidor Proxy, lo que significa que no se puede evitar ni siquiera para usuarios no autorizados.
¿Como prevenir?
La forma más fácil de prevenir tales situaciones es deshabilitar todos los comandos internos del kernel y restablecer los derechos en esta etapa. Incluso para un desarrollador. Especialmente para un desarrollador.
Servidor de autorización
La segunda etapa de la cadena es el servidor donde el jugador se registra e inicia sesión.
Es aquí donde nuestro usuario sentirá por primera vez el suelo sólido del cubo bajo sus pies geométricos.
La mayoría de las veces, los servidores de esta etapa se ven así:
- Un pequeño pedazo de tierra en el espacio infinito de un mundo vacío, donde el jugador se encuentra ante una autorización exitosa (o no)
- Complementos básicos:
SkinsRestorer - , , -
( , )
, ( )
, ( AI , , .)
,
AutoSaveWorld
- Falta de control de derechos
- Falta de sistemas de protección contra las vulnerabilidades del kernel o el juego en sí
El principal problema en esta etapa son los derechos de emergencia para los jugadores. Rara vez alguien los configura, porque solo un jugador autorizado puede usarlos, y cuando el jugador está autorizado, inmediatamente redirigen a la siguiente etapa.
¿Cómo nos amenaza esto?
En algunos casos, el jugador puede evitar la redirección a otro servidor después de la autorización: A menudo, el kernel o los complementos de ese servidor impiden las reconexiones rápidas al servidor del juego. Por lo tanto, si el jugador se vuelve a conectar inmediatamente después de una autorización exitosa, el servidor de la siguiente etapa puede rechazar la conexión y el jugador autorizado permanecerá en el servidor de autorización.
Además, el jugador que tiene derechos elevados aprende silenciosamente la lista de complementos instalados en nuestro país (/ complementos), y luego, aprendiendo sus capacidades con los derechos que tiene, comienza su oscuro negocio.
Daré dos ejemplos que personalmente he conocido más de una vez.
Primer ejemplo. Acceso a ASW.
AutoSaveWorldEs un complemento extremadamente útil y al mismo tiempo peligroso para cualquier servidor. Sus capacidades en mi recuento, brevemente:
- Salvar el mundo automáticamente
- Copia de seguridad mundial automática
- Limpiar el mundo según la configuración especificada
- Conectar, reiniciar y desconectar complementos sin reiniciar el servidor del juego (/ asw pmanager)
- Iniciar, detener y controlar procesos generados (proceso / asw)
Estamos interesados en el último elemento de esta lista.
No, esto no es un error. En una gran cantidad de servidores, realmente existe un complemento que le permite iniciar cualquier proceso con el acceso adecuado, que algunos servidores brindan a todos los jugadores en esta etapa.
En este caso, algunos
/asw process start QQHABR rm -rf / (¡NO EJECUTE ESTE COMANDO!) Serán el menor de los problemas. No creo que valga la pena decir qué puede hacer un "cracker" con el acceso a la terminal.
Ejemplo dos. Un restaurador de pieles inofensivo.
Restaurador de pielesEs un complemento extremadamente popular que se utiliza en una gran cantidad de servidores. Se utiliza principalmente para recuperar máscaras que se perdieron debido al uso de máscaras de proxy, pero también tiene la capacidad de instalar las suyas propias. Esta misma oportunidad es una vulnerabilidad potencial.
Usando el comando / skin, no solo puedes cargar el skin de otro jugador con su apodo, sino también establecer el tuyo especificando la dirección de la imagen (/ skin URL). El peligro de este equipo radica en que inicialmente se supone el acceso a él para los jugadores (y no solo si los derechos están configurados incorrectamente, como en el caso de ASW).
¿Cómo se puede usar esto? Cargar una imagen en la dirección especificada es una solicitud GET normal. Una solicitud realizada desde el propio servidor.
Hay muchas opciones para un uso posterior, comenzando con una llamada a una API cerrada (por ejemplo, emitiendo una donación), cuyo acceso se proporciona para ciertas direcciones IP, y termina con una inundación regular.
¿Como prevenir?
Puede evitar esto restringiendo los derechos de los jugadores (lo que se recomienda hacer en cualquier servidor), bloquear todos los comandos posibles excepto los comandos de autorización y registro, y también prohibir la instalación de su propia máscara por URL (recomiendo hacer esto en todos los servidores)
Cubo
Hub : un espacio común donde los jugadores seleccionan un servidor y un modo de juego.
La mayoría de las veces, los Hubs, como los servidores de juegos principales, son únicos para cada servidor, pero algunos problemas de seguridad son los mismos para ellos.
Conexión directa
Al conectarse a este servidor directamente (a su IP), el jugador puede omitir las etapas anteriores, incluida la autorización.
¿Cómo nos amenaza esto?
Habiendo omitido la etapa de autorización, el jugador puede usar todos los derechos del usuario cuyo apodo se usó para conectarse
¿Como prevenir?
La mayoría de los núcleos de servidor tienen una configuración incorporada que bloquea las conexiones sin usar BungeeCord. Por ejemplo, Spigot en spigot.yml:
settings:
bungeecord: trueSi utiliza esta configuración, asegúrese de leer el siguiente párrafo.
Suplantar los datos del jugador
Casi todos los núcleos de servidor que bloquean la conexión directa al servidor (incluido Spigot) tienen una vulnerabilidad activa relacionada con la sustitución de los datos del jugador a través de su propio servidor BungeeCord: el jugador coloca su servidor proxy con redirección de conexiones a nuestro servidor principal del juego, por lo tanto, el núcleo el servidor del juego determina que se usa BungeeCord para conectarse y confía en todos los datos transmitidos desde él (la IP del proxy no se verifica para una coincidencia con la IP del servidor en este caso)
¿Cómo nos amenaza esto?
La mayoría de las veces, los siguientes se sustituyen de esta manera: la IP del jugador (omitiendo sesiones y obteniendo acceso a la cuenta de otra persona) y UUID (utilizado por algunos complementos y el servidor mismo para identificar al jugador, omitir el control de derechos y acceder a los derechos de otros jugadores).
Cuando use BungeeCord, debe solucionarlo usted mismo; de lo contrario, puede permitir que un atacante obtenga acceso no solo a las cuentas de los jugadores, sino también a las capacidades de los administradores.
¿Como prevenir?
La forma más fácil de evitar esto es cerrando puertos innecesarios para conexiones de terceros y => cualquier posibilidad de conectarse al servidor sin pasar por el servidor proxy.
¡Se recomienda cerrar para la conexión externa todos los puertos de todos los servidores excepto el servidor principal de BungeeCord!
Servidores de juegos
Servidores de juego con sus propios modos. Todo lo anterior es relevante.