Tag: Vulnerabilides

Alerta de segurança: vulnerabilidade crítica no Nginx UI

Foi divulgada uma vulnerabilidade crítica no Nginx UI, painel web para administração do servidor web Nginx, registrada como CVE-2026-27944 e com pontuação CVSS 9.8 (Critical).

NOTA IMPORTANTE: “Nginx UI” é um projeto open-source complementar e não oficial ao Nginx, hospedado no GitHub em 0xJacky/nginx-ui. Ele é uma interface gráfica para administração do Nginx e possui cerca de 9.6k estrelas de avaliação no GitHub, mas não há dados públicos de adoção em larga escala, contrastando com o market share global do Nginx core que é cerca de 33% dos servidores web existentes na Internet.

Se você não utiliza Nginx UI você pode parar de ler esse alerta nesse pronto. Caso contrário, continue.


A falha do Nginx UI permite que um atacante não autenticado baixe e decripte um full backup do sistema, expondo credenciais, tokens de sessão, chaves privadas SSL/TLS e configurações completas do Nginx e do próprio Nginx UI.

Fontes mencionam explicitamente que pesquisadores já lançaram um script PoC que automatiza o envio do GET para /api/backup, extrai a chave e o IV do cabeçalho X-Backup-Security e faz a decriptação local do backup.

Com isso, a exploração é de baixa complexidade e totalmente automatizável, o que aumenta bastante a urgência de correção

A ação mais imediata, rápida e efetiva é:

Atualizar imediatamente o Nginx UI para a versão 2.3.3 ou superior, que contém o patch oficial da CVE‑2026‑27944 e corrige tanto a falta de autenticação no /api/backup quanto a exposição das chaves de criptografia no cabeçalho X-Backup-Security.

Se a atualização não puder ser aplicada na hora, o mínimo é bloquear o acesso ao /api/backup e à interface do Nginx UI a partir de redes não confiáveis (Internet) via firewall, ACL ou reverse proxy, até concluir o patch.

Caso a solução imediata seja viável, ela resolve o problema. Continue lendo se quiser entender os detalhes.

Resumo técnico da vulnerabilidade

O Nginx UI expõe um endpoint de backup em /api/backup, concebido originalmente para que administradores autenticados baixem backups criptografados do sistema.
Em versões anteriores à 2.3.3, este endpoint pode ser acessado sem qualquer autenticação, caracterizando um caso clássico de Missing Authentication for Critical Function (CWE-306).

Além da ausência de autenticação, o endpoint retorna no cabeçalho HTTP X-Backup-Security as informações necessárias para decriptar o backup (chaves/segredo de criptografia), o que neutraliza totalmente a proteção oferecida pela criptografia aplicada ao arquivo.

Na prática, um atacante precisa apenas enviar uma requisição HTTP para /api/backup, receber o arquivo de backup e ler a chave de descriptografia no cabeçalho da resposta para ter acesso imediato a todos os dados sensíveis contidos ali.

De acordo com os advisories públicos, o backup pode conter:

  • Credenciais de usuários do Nginx UI.
  • Tokens de sessão.
  • Chaves privadas SSL/TLS.
  • Arquivos de configuração do Nginx.
  • Demais segredos e parâmetros sensíveis do ambiente.

Impacto

O impacto é crítico em qualquer cenário em que o Nginx UI esteja acessível a partir de redes não confiáveis (por exemplo, exposto diretamente à Internet).
Um comprometimento via CVE-2026-27944 tende a resultar em comprometimento completo da instância de Nginx UI e potencialmente dos serviços HTTP(s) servidos pelo Nginx, uma vez que chaves privadas e configurações podem ser reutilizadas para ataques de hijack, impersonation e movimento lateral.

Como já existe código de prova de conceito público para exploração, o nível de risco aumenta e a janela entre divulgação e exploração em massa tende a ser curta.

Versões afetadas e correção

  • Produto afetado: Nginx UI (0xJacky/nginx-ui).
  • Versões vulneráveis: todas as versões anteriores à 2.3.3.
  • Versão corrigida: 2.3.3, na qual o endpoint /api/backup passa a exigir autenticação adequada e deixa de expor as chaves de criptografia no cabeçalho de resposta.

Os mantenedores recomendam atualização imediata para a versão 2.3.3; distribuições e fornecedores de appliances podem liberar patches ou backports específicos, portanto também é importante acompanhar os comunicados do seu fornecedor.

Relação com vulnerabilidades anteriores

Esta não é a primeira vez que o Nginx UI é alvo de vulnerabilidades severas: em 2024 foi divulgada a CVE-2024-22198, que permitia execução de comandos arbitrários autenticados ao abusar configurações expostas na página Home > Preference, como o parâmetro Terminal Start Command.

Embora esse bug exigisse autenticação (PR:L), ele mostrava um padrão de exposição de funções sensíveis via API, exploradas através de requisições diretas e não necessariamente pela UI, algo que volta a aparecer na CVE-2026-27944 com impacto ainda maior por ser não autenticada.

Referências:

Vulnerabilidade no Microsoft Exchange Server

INTRODUÇÃO

Estamos cientes de uma vulnerabilidade de alta gravidade, a qual permite que um agente de ameaça cibernética com acesso administrativo a um servidor Microsoft Exchange local aumente privilégios explorando configurações híbridas vulneráveis. Essa vulnerabilidade, se não for corrigida, pode afetar a integridade da identidade do serviço Exchange Online de uma organização. Uma vez explorada, permite que um atacante com acesso administrativo a um servidor MS Exchange local consiga elevar seus privilégios para o ambiente em nuvem (Exchange Online), potencialmente comprometendo todo o domínio.

Ela foi catalogada como a vulnerabilidade CVE-2025-53786 com pontuação CVSS de 8.0 (Alta).

  • Tipo: Escalonamento de privilégios.
  • Gravidade: Alta, com pontuação CVSS de 8.0.
  • Vetor:  CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H
  • CWE-287: CWE-287: Improper Authentication
  • Impacto: Permite que um atacante com acesso administrativo local acesse o ambiente em nuvem sem deixar rastros facilmente detectáveis, explorando a confiança entre o Exchange local e o Exchange Online.
  • Causa principal: O uso de um service principal compartilhado para autenticação entre o servidor local e a nuvem em configurações híbridas, criando uma ligação que pode ser explorada.

OBSERVAÇÃO: Não há evidências de exploração ativa até o momento, 08 de agosto de 2025, mas a Microsoft classifica a vulnerabilidade como “Exploitation More Likely“ (Exploração Razoavelmente Provável) devido à sua gravidade. Independente de não haver relatos da exploração da vulnerabilidade em larga escala, nós recomendamos fortemente a aplicação de mitigação sugerida nesse documento.

A exploração é particularmente perigosa porque pode passar despercebida. O ataque não gera logs ou alertas evidentes, dificultando a detecção, já que usa funções legítimas do sistema.

RESUMO DA VULNERABILIDADE

O atacante já deve ter privilégios administrativos no servidor Exchange local, por exemplo, via uma senha fraca, outra vulnerabilidade, ação de phishing ou credenciais roubadas.

Como ocorre a exploração da vulnerabilidade:

  • O atacante acessa as keyCredentials do service principal, armazenadas na configuração do Exchange ou via PowerShell/Graph API.
  • Com essas chaves, ele gera um token S2S (server-to-server) válido para autenticação na nuvem.
  • Isso permite acesso a recursos como caixas de e-mail no Exchange Online, envio de e-mails em nome de outros usuários, alterações em configurações de segurança ou até pivô para outros serviços, como SharePoint Online.
  • Para entender o que é o service principal e o KeyCredentials e como esses se combinam para o ataque, consulte o apêndice desse alerta.

Quais os riscos associados:

  • Comprometimento de dados sensíveis (e-mails, configurações de segurança).
  • Movimento lateral para outros serviços na nuvem (como SharePoint).
  • Potencial para comprometimento total do domínio em ambientes híbridos.
  • A exploração é particularmente perigosa porque pode passar despercebida, mesmo com ferramentas de monitoramento como Conditional Access ou de autenticação MFA.

MITIGAÇÃO RECOMENDADA

1. Aplicar o hotfix de abril de 2025:

  • Instale a atualização de segurança em todos os servidores Exchange locais (2016, 2019 ou Subscription Edition) em modo híbrido.
  • Verifique se os servidores estão dentro do ciclo de suporte (ex.: Exchange 2019 CU14/CU15, Exchange 2016 CU23).

2. Fazer inventário e verificação:

  • Use o script HealthChecker.ps1 da Microsoft para identificar servidores afetados e gerar relatórios.

3. Migrar para um service principal dedicado:

  • Execute o Hybrid Configuration Wizard (HCW) atualizado para configurar uma nova entidade de serviço dedicada:
.\HybridConfigurationWizard.exe /Upgrade

.\HybridConfigurationWizard.exe /Configure
  • Redefina as keyCredentials do service principal compartilhado:
Connect-MgGraph -Scopes "Application.ReadWrite.All"
$sp = Get-MgServicePrincipal -Filter "displayName eq 'Exchange Hybrid Modern Auth Service Principal'"
Update-MgServicePrincipal -ServicePrincipalId $sp.Id -KeyCredentials @()

4. Adotar boas práticas

  • Minimize permissões administrativas.
  • Habilite e monitore logs detalhados.
  • Desconecte da internet servidores Exchange ou SharePoint em fim de vida (EOL).
  • Considere migrar para protocolos mais seguros, como Graph API, e reduzir o uso de Exchange Web Services (EWS).

INFORMAÇÕES ADICIONAIS

  • Descoberta: A vulnerabilidade foi reportada por Dirk-jan Mollema da Outsider Security e apresentada na conferência Black Hat no último dia 6 de agosto de 2025.
  • Diretiva da CISA: Agências federais dos EUA foram obrigadas a mitigar a falha até 11 de agosto de 2025, mas a recomendação se estende a todas as organizações com ambientes híbridos.
  • Contexto maior: Tal falha reforça a necessidade de revisar configurações legadas em ambientes híbridos e adotar modelos de zero trust para minimizar riscos.

REFERÊNCIAS:

[1] CISA – Emergency Directives ED 25-02: Mitigate Microsoft Exchange Vulnerability – Released: Aug 7, 2025

[2] Microsoft Exchange Server Hybrid Deployment Elevation of Privilege Vulnerability – CVE-2025-53786 Security Vulnerability – Released: Aug 6, 2025

[3] CVE-2025-53786

APÊNDICE

A keyCredentials é como um “chaveiro” criptográfico, que funciona como uma carteira de identidade do service principal híbrido. Ela é usada para autenticar um servidor Exchange local na nuvem. Na vulnerabilidade CVE-2025-53786, um atacante com acesso administrativo local pode roubar esse chaveiro (keyCredentials) e usá-lo para fazer se passar pelo servidor, acessando o Exchange Online sem deixar rastros óbvios.

O que é um Service Principal?

Um service principal é uma identidade não-humana usada em sistemas da Microsoft (como o Azure Active Directory, agora Microsoft Entra ID) para autenticar aplicativos ou serviços, permitindo que eles interajam com outros recursos na nuvem, como o Exchange Online. No caso de ambientes híbridos do Exchange, o service principal é usado para facilitar a comunicação segura entre o Exchange Server local (on-premises) e o Exchange Online (nuvem).

  • Função no ambiente híbrido: O service principal híbrido atua como uma “ponte” de autenticação, permitindo que o servidor local execute ações na nuvem, como sincronizar dados, gerenciar caixas de e-mail ou autenticar usuários. Ele é configurado automaticamente pelo Hybrid Configuration Wizard (HCW) durante a criação do ambiente híbrido.

O que é a keyCredentials?

A keyCredentials é uma propriedade do service principal que armazena as chaves criptográficas (certificados ou chaves assimétricas) usadas para autenticar o service principal no Microsoft Entra ID. Essas chaves são essenciais para o processo de autenticação server-to-server (S2S), permitindo que o servidor local consiga provar sua identidade ao acessar recursos na nuvem.

  • Formato: A keyCredentials contém informações como:
    • Chave pública de um certificado.
    • Identificador da chave (keyId).
    • Tipo de chave (geralmente assimétrica, como RSA).
    • Datas de validade (início e fim).
  • Uso: Quando o servidor Exchange local precisa acessar o Exchange Online, ele usa a chave privada correspondente à keyCredentials para assinar um token de autenticação (JWT). Esse token é validado pela nuvem usando a chave pública armazenada na keyCredentials.

Como o Ransomware se Espalha Dentro da Sua Rede

Ajudando em uma resposta a incidente, recentemente tivemos que lidar com um determinado grupo de ransomware que atrapalhou uma empresa por um período. Com isso decidi detalhar como geralmente um ataque ocorre.

Ponto de partida

Imagine uma manhã comum na sua empresa. Os colaboradores chegam e iniciam suas atividades. Tudo parece normal até que, um e-mail aparentemente inofensivo chega à caixa de entrada de um colaborador do setor financeiro. O assunto é: “Nota Fiscal em Atraso – URGENTE”. Sem nem desconfiar, o funcionário clica no anexo.

O anexo executa um script em PowerShell, que baixa e executa um payload malicioso. Em segundos, o atacante já acesso à rede. Mas o objetivo não é apenas comprometer uma máquina é paralisar a empresa inteira. E para isso, o ransomware precisa se espalhar.

Descoberta do ambiente

Antes de se mover, o atacante precisa entender o ambiente. Ele começa com técnicas de reconhecimento interno. Utiliza comandos para descobrir sistemas remotos, identificar conexões de rede, e localizar compartilhamentos acessíveis.

Com essas informações em mãos, o atacante sabe exatamente onde estão os servidores de arquivos, os controladores de domínio e as estações mais críticas.

Movimentação lateral

Para se mover lateralmente, o atacante precisa de credenciais. Com Mimikatz usa para extrair senhas da memória do processo LSASS. Se tiver sorte, encontra credenciais de administradores de domínio. Caso contrário, ele pode recorrer a ataques de força bruta ou password spray para comprometer outras contas.

Usando ferramentas como PsExec ou WMI, o ransomware começa a se espalhar. Ele cópia seus arquivos para máquinas remotas usando compartilhamentos administrativos e executa o payload silenciosamente.

Se encontrar vulnerabilidades conhecidas, como EternalBlue, ele pode explorá-las diretamente, sem depender de credenciais.

Garantindo a Persistência

Para garantir que o ransomware continue ativo mesmo após reinicializações, o atacante cria tarefas agendadas ou serviços maliciosos.

Processo Final

Quando o atacante sente que já comprometeu o suficiente, ele inicia a fase final: a criptografia. Utilizando algoritmos robustos, o ransomware bloqueia arquivos em servidores, estações de trabalho e até backups conectados.

Em minutos, a empresa inteira está paralisada. Um aviso aparece nas telas: “Seus arquivos foram criptografados. Pague em Bitcoin para recuperá-los.”

Melhorias no ambiente

  • Segmentação de rede: impede que o atacante se mova livremente.
  • Monitoramento de credenciais: detecta uso anômalo de contas.
  • Atualizações regulares: fecham portas exploradas por vulnerabilidades.
  • Treinamento de usuários: reduz o risco de phishing.
  • Soluções de segurança avançadas: como EDRs e SIEMs, ajudam a detectar e responder rapidamente.

Conclusão

O ransomware não é apenas um vírus que aparece do nada. Ele é o resultado de uma cadeia de ações cuidadosamente planejadas.

A pergunta não é se sua empresa será alvo, mas quando. E quando isso acontecer, o quão preparado você estará?

Atenção aos IoTs

Nos últimos dias tenho observado diversos bloqueios pelo IPS (intrusion prevention system) nos logs do firewall. A origem da comunicação apresentava variação, porém o payload era sempre o mesmo /boaform/admin/formLogin?username=adminisp&psd=adminisp.Ao investigar mais a fundo, verifiquei que se trata de um payload utilizado por algumas botnets para realizar ataques em dispositivos ONT.

Um artigo da LevelBlue, de 2021 [1], alerta sobre a botnet BotenaGO que utiliza diversos exploits, incluindo um que explora vulnerabilidades em servidores web Boa, a CVE-2020-8958. Uma rápida consulta ao Shodan mostrou que o IP atacante, sem muita surpresa, utiliza uma versão do webserver explorado pela BotenaGO.

Webserver utilizado pelo IP atacante.

Atualmente, o código do malware, está disponível na internet, podendo conter diversas variantes, uma vez que qualquer desenvolvedor mal intencionado pode ter acesso ao código e realizar alterações – o que pode acarretar em crescimento de novas ameaças a roteadores e dispositivos IoT.

Payloads inicializados no código fonte do malware, evidenciando ataques em IoTs e roteadores.
Fonte: LevelBlue [2]

Na imagem anterior, podemos observar uma função executada para diferentes modems, IoTs e roteadores, onde cada função carrega um exploit diferente. Apesar da botnet BotenaGO ser apenas um kit de exploit, ela pode facilitar o envio de malwares para dispositivos vulneráveis.

Finalizo com a recomendação essencial: seguir processos. Atualizações de segurança, atualizações de firmware e diminuir a exposição de dispositivos IoT na internet, podem diminuir consideravelmente o risco de infecção.

Referências

LevelBlue Labs. LevelBlue, 2021. Disponível em: https://levelblue.com/blogs/labs-research/att-alien-labs-finds-new-golang-malwarebotenago-targeting-millions-of-routers-and-iot-devices-with-more-than-30-exploits. Descrição: LevelBlue Labs finds new Golang malware (BotenaGo) targeting millions of routers and IoT devices with more than 30 exploits. Acesso em: 17, abril e 2025.

LevelBlue Labs. LevelBlue, 2021. Disponível em: https://levelblue.com/blogs/labs-research/botenago-strike-again-malware-source-code-uploaded-to-github. Descrição: BotenaGo strikes again – malware source code uploaded to GitHub. Acesso em: 17, abril e 2025.

Sobre POCs para ataques a dispositivos Fortinet

Estamos cientes de pelo menos um agente de ameaça explorando vulnerabilidades importantes de execução remota de código (RCE) em produtos Fortinet, como FortiOS e FortiGate, que podem ser usadas para criar arquivos maliciosos ou explorar sistemas.

Estamos tratando aqui especificamente das vulnerabilidades catalogadas pela Fortinet como: FG-IR-22-398 (CVE-2022-42475), FG-IR-23-097 (CVE-2023-27997) e FG-IR-24-015 (CVE-2024-21762), todas relacionadas ao SSL VPN em dispositivos Fortinet.

Nesse ponto é importante observar que se o produto Fortinet não tem, e nunca teve, SSL VPN ativado, ele não é afetado por essas vulnerabilidades. Para determinar se um dispositivo Fortinet, como um FortiGate rodando FortiOS, tem ou teve o SSL VPN ativado é necessário fazer verificações na interface gráfica (GUI) ou na linha de comando (CLI) e, se julgar necessário, analisar logs ou configurações históricas.

Vamos analisar se há provas de conceito (PoCs – Proof Of Concept) públicas ou evidências de exploração para essas vulnerabilidades:

  • FG-IR-22-398 / CVE-2022-42475
    CVSS: 9,8 (Critical) – EPSS: 92,9% de chance de ataque (em 14/4/2025)
    Essa é uma vulnerabilidade crítica de estouro de buffer baseado em heap no FortiOS SSL VPN, permitindo execução remota de código (RCE) sem autenticação. A Fortinet confirmou exploração ativa em dezembro de 2022, com indicadores de comprometimento (IoCs) como arquivos maliciosos (ex.: /data/lib/libips.bak) e conexões a IPs suspeitos. Há PoC público disponível para essa vulnerabilidade. A exploração real sugere que atores avançados desenvolveram seus próprios métodos, possivelmente devido à sua complexidade e ao foco em alvos governamentais.

  • FG-IR-23-097 / CVE-2023-27997
    CVSS: 9,8 (Critical) – EPSS: 87,3% de chance de ataque (14/4/2025)
    Outro problema crítico de estouro de buffer no SSL VPN, também permitindo RCE sem autenticação. A Fortinet relatou exploração limitada em junho de 2023 e, presumivelmente, existe de uma PoC funcional, embora não amplamente divulgada. Um repositório no GitHub contém um exemplo de PoC que demonstra a corrupção da memória heap para executar código remoto. Esse PoC é funcional, mas requer adaptações específicas, indicando que atores de ameaça podem estar usando variantes para criar arquivos maliciosos ou backdoors.

  • FG-IR-24-015 / CVE-2024-21762:
    CVSS: 9,8 (Critical) – EPSS: 90,7% de chance de ataque (14/4/2025)
    Essa vulnerabilidade de escrita fora dos limites no FortiOS SSL VPN foi reportada como potencialmente explorada em fevereiro de 2024. A Fortinet alertou para ataques reais, mas não há PoC pública confirmada até agora. A exploração envolve requisições HTTP maliciosas, e a falta de um PoC público pode refletir a recente divulgação ou esforços para limitar a disseminação de exploits. A recomendação da Fortinet de desativar o SSL VPN como mitigação sugere que atores de ameaça podem estar usando essa falha para acesso inicial e implantação de payloads maliciosos.

As três vulnerabilidades são alvos atraentes para atores sofisticados devido à exposição do SSL VPN na internet. A criação de arquivos maliciosos, como backdoors ou implantes, é consistente com o comportamento observado em explorações de RCE, especialmente em FG-IR-22-398, onde malwares personalizados para FortiOS foram detectados. Embora PoCs públicos sejam limitados, a exploração ativa indica que grupos de ameaça possuem exploits funcionais, possivelmente compartilhados em fóruns privados ou desenvolvidos internamente.

RECOMENDAÇÃO:

Há PoCs públicas confirmadas para FG-IR-22-398 (CVE-2022-42475) e FG-IR-23-097 (CVE-2023-27997), mas para FG-IR-24-015, não há PoCs amplamente disponíveis, embora explorações reais tenham sido reportadas. Entretanto, atores específicos podem estar de posse de algum código de ataque, ou códigos de ataque podem se tornar disponíveis em algum momento próximo ou vindouro.

Por esse motivo, nossa recomendação é aplicar os patches mais recentes [1] e, se possível, desativar o SSL VPN (obviamente, caso a VPN não seja utilizada), além de monitorar sistemas por IoCs, como arquivos ou conexões suspeitas.

Para mais informações sobre o tratamento das vulnerabilidades relacionadas com SSL VPN em produtos Fortinet, por favor consulte [1].

Referências:

[1] Carl Windsor – “Analysis of Threat Actor Activity”. Fortinet. 10 de abril de 2025.

https://www.fortinet.com/blog/psirt-blogs/analysis-of-threat-actor-activity