BungeeCord e Minecraft: problemas de segurança e perigos

Bungee em breve

O BungeeCord é um servidor proxy que permite aos projetos de jogos combinar vários servidores do Minecraft com a capacidade de alternar rapidamente os jogadores entre eles.



Neste artigo, compartilharei minha experiência com o kernel, falarei sobre problemas de segurança em servidores que o utilizam e também darei algumas dicas simples que podem ajudar a prevenir a invasão de tal servidor.



Resumidamente, onde o BungeeCord é mais comumente usado:

• Servidores com vários modos de jogo (incluindo servidores com minijogos)
• Servidores com alta carga e necessidade de distribuição online
• Servidores que usam proteção baseada em BotFilter contra ataques de bot (uma característica desse servidor é "drop check" ou captcha no login)

As vulnerabilidades mais comuns de tais servidores:

• Acesso não controlado a comandos do servidor proxy
• Bypass do servidor de autorização
• Dados de jogador falsificados
• Vulnerabilidades em módulos de servidor de teste

Como funciona

A maioria dos projetos executados pela BungeeCord representam a seguinte cadeia de servidores (que podem estar localizados em pelo menos um IP com portas diferentes, mesmo em máquinas em diferentes partes do mundo).

Proxy

A primeira etapa - na verdade, este é o próprio servidor, ao qual os jogadores estão conectados. Ele não tem um ponto de spawn ou mundos de jogo - sua tarefa é redirecionar o conectado para o próximo estágio.



Parece que tudo é simples aqui - mas não.



O principal charme, e ao mesmo tempo o problema nesta fase, é o próprio redirecionamento - o servidor não apenas redireciona o jogador para outro IP, mas desempenha o papel de um servidor intermediário.

Simplificando, todos os comandos que o jogador envia, todos os pacotes de sincronização, cada mensagem no chat são processados ​​aqui primeiro.

Como isso nos ameaça?

Deixe-me explicar com um exemplo hipotético: nosso desenvolvedor Drygok, valentemente fazendo seu trabalho, tem direitos sobre os servidores próximos ao máximo. Ele protegeu perfeitamente sua conta com seu próprio sistema de autorização - uma senha complexa, autenticação de dois fatores e até mesmo vinculação a uma faixa específica de endereços IP de seu provedor, após o que ele sai do servidor em paz de espírito, mas após 10 minutos todos os jogadores “voam” e os servidores param porque alguém executou o comando / end em seu nome.



O que aconteceu? É simples: uma pessoa desconhecida entrou no jogo com o apelido do nosso desenvolvedor e, ignorando a solicitação do servidor para fazer o login, digitou um comando que é processado pelo próprio servidor Proxy, o que significa que não pode ser evitado nem mesmo por usuários não autorizados.

Como prevenir?

A maneira mais fácil de evitar tais situações é desabilitar todos os comandos internos do kernel e redefinir todos os direitos neste estágio. Mesmo para um desenvolvedor. Especialmente para um desenvolvedor.

Servidor de autorização

O segundo estágio da cadeia é o servidor onde o jogador se registra e faz login.



É aqui que nosso usuário sentirá pela primeira vez o cubo sólido aterrado sob seus pés geométricos.



Na maioria das vezes, os servidores deste estágio se parecem com isto:

• Um pequeno pedaço de terra no espaço infinito de um mundo vazio, onde o jogador fica diante de uma autorização bem-sucedida (ou não)
• Plugins básicos:
  
  SkinsRestorer - , , -

( , )

, ( )

, ( AI , , .)

,

AutoSaveWorld
  
  
• Falta de qualquer controle de direitos
• Ausência de qualquer sistema de proteção contra vulnerabilidades do kernel ou do próprio jogo

O principal problema nesta fase são os direitos de emergência para os jogadores. Raramente alguém os configura, pois apenas um jogador autorizado pode usá-los, e quando o jogador é autorizado, eles redirecionam imediatamente para a próxima fase.

Como isso nos ameaça?

Em alguns casos, o jogador pode impedir o redirecionamento para outro servidor após a autorização: Freqüentemente, reconexões rápidas com o servidor do jogo são impedidas pelo kernel ou plug-ins desse servidor. Portanto, se o jogador se reconectar imediatamente após a autorização bem-sucedida, o servidor no próximo estágio pode rejeitar a conexão e o jogador autorizado permanecerá no servidor de autorização.



Além disso, o jogador que possui direitos elevados aprende silenciosamente a lista de plug-ins instalados em nosso país (/ plug-ins), e então, aprendendo suas capacidades com os direitos que possui, começa seu dark business.



Darei dois exemplos que conheci pessoalmente mais de uma vez.



Primeiro exemplo. Acesso ao ASW.



AutoSaveWorldÉ um plugin extremamente útil e ao mesmo tempo perigoso para qualquer servidor. Suas capacidades em minha recontagem, resumidamente:

• Salve o mundo automaticamente
• Backup mundial automático
• Limpando o mundo de acordo com as configurações especificadas
• Conectando, reiniciando e desconectando plug-ins sem reiniciar o servidor do jogo (/ asw pmanager)
• Iniciar, parar e controlar processos gerados (processo / asw)

Estamos interessados ​​no último item desta lista.



Não, isso não é um erro. Em um grande número de servidores, existe realmente um plugin que permite iniciar qualquer processo com o acesso adequado, que alguns servidores fornecem a todos os jogadores nesta fase.



Nesse caso, alguns /asw process start QQHABR rm -rf / (NÃO EXECUTE ESTE COMANDO!) Serão o menor dos problemas. Acho que não vale a pena dizer o que um "cracker" pode fazer com acesso ao terminal.



Exemplo dois. Um SkinsRestorer inofensivo.



SkinsRestorerÉ um plugin extremamente popular usado em um grande número de servidores. É usado principalmente para recuperar skins perdidos devido ao uso de skins proxy, mas também tem a capacidade de instalar as suas próprias. Essa mesma oportunidade é uma vulnerabilidade potencial.



Usando o comando / skin, você pode não apenas carregar o skin de outro jogador com seu apelido, mas também definir o seu próprio, especificando o endereço da imagem (/ skin URL). O perigo desta equipa reside no facto de inicialmente o acesso a ela ser suposto pelos jogadores (e não apenas se os direitos estiverem configurados incorretamente, como no caso do ASW).



Como isso pode ser usado? O upload de uma imagem para o endereço especificado é uma solicitação GET normal. Uma solicitação feita do próprio servidor.



Existem muitas opções para uso posterior - começando com uma chamada para uma API fechada (por exemplo, emitindo uma doação), o acesso ao qual é fornecido para determinados endereços IP e terminando com uma inundação regular.

Como prevenir?

Você pode evitar isso restringindo os direitos dos jogadores (o que é recomendado para fazer em qualquer servidor), bloquear todos os comandos possíveis, exceto para os comandos de autorização e registro, e também proibir a instalação de sua própria skin por URL (eu recomendo fazer isso em todos os servidores)

Cubo

Hub - um espaço comum onde os jogadores vão para selecionar um servidor e modo de jogo







Na maioria das vezes, os Hubs, como os servidores principais do jogo, são exclusivos para cada servidor, mas alguns problemas de segurança são os mesmos para eles.

Conexão direta

Ao se conectar a este servidor diretamente (ao seu IP), o jogador pode contornar as etapas anteriores, incluindo a autorização

Como isso nos ameaça?

Tendo pulado a fase de autorização, o jogador pode usar todos os direitos do usuário cujo apelido foi usado para conectar

Como prevenir?

A maioria dos núcleos de servidor tem uma configuração integrada para bloquear conexões sem usar o BungeeCord. Por exemplo, Spigot em spigot.yml:

settings:
bungeecord: true

Se você usar esta configuração, certifique-se de ler o próximo parágrafo!

Dados de jogador falsificados

Quase todos os núcleos de servidor que bloqueiam a conexão direta ao servidor (incluindo o Spigot) têm uma vulnerabilidade ativa relacionada à substituição de dados do jogador por meio de seu próprio servidor BungeeCord: O jogador coloca seu servidor proxy com conexões de redirecionamento para nosso servidor de jogo principal, portanto, o núcleo o servidor do jogo determina que o BungeeCord é usado para conectar e confia em todos os dados transmitidos a partir dele (o IP do proxy não é verificado para uma correspondência com o IP do servidor neste caso)

Como isso nos ameaça?

Na maioria das vezes, os seguintes são substituídos desta forma: o IP do jogador (ignorando sessões e obtendo acesso à conta de outra pessoa) e UUID (usado por alguns plug-ins e o próprio servidor para identificar o jogador, ignorar o controle de direitos e acessar os direitos de outros jogadores).



Ao usar o BungeeCord, você precisa consertá-lo sozinho, caso contrário, ele pode permitir que um invasor obtenha acesso não apenas às contas dos jogadores, mas também aos recursos dos administradores!

Como prevenir?

A maneira mais fácil de evitar isso é fechando portas desnecessárias para conexões de terceiros e => qualquer possibilidade de conexão ao servidor ignorando o servidor proxy.



Recomenda-se fechar para conexão externa todas as portas de todos os servidores, exceto o servidor principal BungeeCord!

Servidores de jogo

Servidores de jogos com seus próprios modos. Todos os itens acima são relevantes.