Produtos baseados no mesmo núcleo do ISPsystem ficam expostos quando identificadores de sessão de 6 bytes podem ser previstos a partir do gerador pseudoaleatório usado na autenticação.
| Componente | Núcleo compartilhado dos produtos ISPsystem, incluindo painéis de hospedagem, VPS, servidores dedicados, virtualização e cobrança. |
| Vetor | Previsão de identificadores de sessão de 6 bytes gerados por rotina pseudoaleatória baseada em rand(), acionada durante autenticações no painel web. |
| Impacto | Sequestro de sessão de outro usuário já autenticado, com possibilidade de operar sites, máquinas virtuais e dados de cobrança vinculados à conta capturada. |
| Prioridade | Atualizar instalações com núcleo anterior à versão 5.178.2 e revisar telemetria de autenticação, criação de sessões e uso anômalo de sessões simultâneas. |
| Versões | A correção foi disponibilizada na versão 5.178.2; instalações com núcleo abaixo dessa versão são descritas como afetadas. |
| Artefatos | Serviço web do painel exposto por padrão na porta TCP 1500 e lógica de autenticação executada no contexto do processo ihttpd. |
| Mitigação | Aplicar a atualização, invalidar sessões existentes após a correção e monitorar tentativas repetidas de autenticação usadas para inferir a sequência pseudoaleatória. |
A vulnerabilidade afeta o núcleo comum usado pelos produtos ISPsystem, plataforma empregada para administração de servidores web, servidores dedicados, VPS, virtualização e faturamento em provedores de hospedagem. O problema não está restrito a uma tela específica do painel: a geração de sessão ocorre na lógica central de autenticação e, por isso, produtos que compartilham esse núcleo herdam a mesma exposição. O impacto confirmado é o sequestro de uma sessão válida de outro usuário autenticado, permitindo que o atacante passe a interagir com recursos associados à conta capturada, como sites, máquinas virtuais e informações de cobrança disponíveis no painel.
A causa técnica é a criação de identificadores de sessão com apenas 6 bytes por uma rotina pseudoaleatória previsível. A autenticação cria um objeto de sessão e chama uma rotina interna para gerar o identificador, que por sua vez depende de uma função de geração de bytes aleatórios implementada em biblioteca do próprio produto. Essa função usa rand() repetidamente e reduz cada resultado a 8 bits, formando a cadeia usada como identificador. Embora o espaço bruto de 6 bytes pareça grande para força bruta remota direta, o desenho do gerador reduz a incerteza quando o atacante consegue observar sessões próprias e correlacionar a sequência de valores produzidos pelo processo.
O painel pode ser instalado localmente para administração de VPS e, durante a configuração padrão descrita, prepara um banco de dados MySQL e um servidor HTTP acessível pela porta TCP 1500. A autenticação do usuário é realizada por uma requisição HTTP POST ao painel, após a qual a lógica em C++ executada no contexto do processo ihttpd cria a sessão. A biblioteca libispapi.so participa do fluxo de autenticação, enquanto a geração do identificador passa pela classe isp_api::Session e por uma rotina de geração de ID. O ponto sensível é que o valor gerado para representar a sessão não tem entropia suficiente na prática quando analisado junto ao estado do gerador pseudoaleatório.
A rotina que produz a sequência chama rand() uma vez para cada byte solicitado e armazena o resultado em uma variável de tipo char, descartando tudo exceto os 8 bits inferiores. O estado do gerador é controlado por uma semente de 32 bits, mas ela não é renovada a cada chamada. O contador de reinicialização recebe um valor inicial derivado de rand()%255 + 128, resultando em uma janela entre 128 e 382 bytes antes da troca de semente. A cada chamada da rotina, o tamanho da string gerada é subtraído desse contador. Enquanto a semente permanece a mesma, sessões sucessivas podem aparecer como subsequências dentro de um fluxo pseudoaleatório previsível.
O ataque descrito depende de observar identificadores emitidos para sessões controladas pelo próprio atacante, calcular uma semente compatível com esses valores e estimar os deslocamentos dentro da sequência. Quando outro usuário se autentica durante essa janela, a distância entre identificadores observados muda, revelando atividade adicional no painel. A partir daí, o invasor não precisa testar todo o espaço de 6 bytes: ele testa subsequências candidatas dentro do intervalo previsto entre valores conhecidos. A condição crítica é a presença de uma vítima autenticando ou mantendo sessão válida durante a execução do ataque, combinada com a capacidade do atacante de interagir repetidamente com o painel para gerar amostras próprias.
A superfície afetada envolve instalações de produtos ISPsystem que usam o mesmo núcleo antes da versão 5.178.2. O texto técnico menciona um ecossistema amplo, com milhares de instalações e uso por provedores de hospedagem, o que torna o problema especialmente sensível em ambientes multiusuário. Em um painel desse tipo, uma sessão sequestrada não representa apenas acesso a uma página administrativa: ela pode expor operações de provisionamento, gerenciamento de instâncias, administração de sites e visualização de dados financeiros ou de cobrança conforme os privilégios do usuário capturado.
O risco operacional cresce quando o painel fica acessível pela Internet, quando múltiplos clientes ou operadores usam o mesmo serviço e quando a atualização do núcleo é tratada como manutenção secundária. Como todos os produtos mencionados compartilham a lógica central, a avaliação defensiva deve olhar para o número real de instâncias e não apenas para um produto isolado. Ambientes com ISPmanager, usado para hospedagem web e administração de servidores Linux, e VMmanager, usado para virtualização OpenVZ ou KVM, devem ser tratados como candidatos à exposição se ainda estiverem em versão anterior à correção.
- Instalações do ISPsystem com núcleo anterior à versão 5.178.2.
- Painéis administrativos acessíveis via servidor HTTP, incluindo a configuração padrão na porta TCP 1500.
- Ambientes multiusuário de hospedagem, VPS, servidores dedicados, virtualização e cobrança.
- Sessões de usuários que se autentiquem durante a janela em que o atacante consegue correlacionar valores pseudoaleatórios.
- Produtos como ISPmanager e VMmanager quando baseados no núcleo afetado.
A investigação deve começar por eventos de autenticação e criação de sessão no painel. O comportamento de interesse não é apenas uma tentativa de senha incorreta; a técnica depende de várias autenticações controladas pelo atacante para coletar amostras e inferir a sequência de identificadores. Portanto, registros com padrões de login repetido, criação frequente de sessões em curto intervalo, mudança incomum de sessão entre contas e uso de uma mesma origem para interagir com múltiplos contextos administrativos merecem prioridade. A análise também deve comparar horários de login legítimo de usuários com ações administrativas posteriores que não seguem o perfil normal daquela conta.
Como o efeito final é o sequestro de sessão, a telemetria de aplicação é mais valiosa quando registra associação entre identificador de sessão, usuário autenticado, endereço de origem, agente de usuário e operações executadas. Uma sessão capturada pode aparecer como uma transição repentina de rede, navegador ou padrão de navegação sem novo fluxo de autenticação correspondente. Em provedores de hospedagem, sinais adicionais incluem alterações em sites, recursos de VPS, configurações de virtualização ou dados de cobrança logo após eventos de autenticação de outros usuários. O tráfego para a porta TCP 1500 deve ser correlacionado com logs de painel e não analisado isoladamente.
- Sequência de autenticações bem-sucedidas ou repetidas vindas da mesma origem em intervalos curtos.
- Sessões de um usuário passando a executar ações a partir de endereço IP ou agente de usuário incomum.
- Operações administrativas sem evento de autenticação compatível imediatamente anterior.
- Aumento de criação de sessões no painel próximo ao horário de login de outros usuários.
- Alertas ou assinaturas com referência a
ISPsystem COREmanager Authentication Bypass, quando disponíveis no controle de prevenção.
A ação principal é atualizar o núcleo do ISPsystem para a versão 5.178.2 ou posterior, pois essa é a versão indicada como corrigida. A atualização deve ser acompanhada de invalidação de sessões ativas, especialmente em ambientes compartilhados, para remover identificadores emitidos antes da correção. Depois da aplicação, a equipe deve confirmar a versão do núcleo efetivamente carregada pelos produtos instalados, porque a exposição decorre do componente comum e não apenas do nome comercial do painel usado na operação diária.
A resposta defensiva deve incluir revisão de logs anteriores à atualização, com foco em períodos nos quais usuários realizaram login enquanto havia atividade repetida de autenticação por outra origem. Quando houver indício de sequestro de sessão, a contenção deve tratar a conta afetada como potencialmente operada por terceiro no escopo do painel: revisar alterações em sites, máquinas virtuais, permissões, informações de cobrança e configurações administrativas executadas durante a janela suspeita. Senhas podem ser redefinidas como medida complementar, mas a causa técnica está na geração do identificador de sessão; portanto, a correção do núcleo e a invalidação das sessões são os controles centrais.
A exposição também justifica endurecimento de acesso ao painel. Mesmo após a atualização, restringir a superfície administrativa por rede, aplicar autenticação forte quando suportada, reduzir exposição pública desnecessária da porta de administração e manter registros detalhados de sessão melhora a capacidade de detectar abuso semelhante. Em provedores com múltiplos clientes, a validação deve incluir comunicação interna com equipes de suporte, infraestrutura e faturamento, pois uma sessão capturada pode produzir ações em áreas diferentes do mesmo ambiente administrativo.
- Atualizar todos os produtos ISPsystem afetados para núcleo 5.178.2 ou posterior.
- Invalidar sessões ativas após a atualização e exigir novo login dos usuários.
- Revisar logs de autenticação, criação de sessão e ações administrativas no período anterior à correção.
- Investigar alterações em sites, VMs, virtualização e cobrança feitas por sessões com origem anômala.
- Restringir acesso de rede ao painel administrativo e monitorar tráfego para a porta TCP 1500 quando ela estiver em uso.
- Ativar ou revisar controles de prevenção capazes de detectar a condição identificada como
ISPsystem COREmanager Authentication Bypass.
0 Comentários