Como os agentes de ameaças descobrem e exploram vulnerabilidades na natureza?

 

No passado recente, várias vulnerabilidades de segurança foram descobertas em produtos de software amplamente usados. Como esses produtos são instalados em um número significativo de dispositivos conectados à Internet, eles estimulam os agentes de ameaças a se desenvolverem botnets, roube dados confidenciais e muito mais.

Neste artigo, exploramos:

• Vulnerabilidades detectadas em alguns produtos populares.
• Técnicas de identificação e exploração de alvos empregadas por agentes de ameaças intrusivos.
• Curso de ação dos agentes de ameaças no caso de identificação de uma falha em produtos/tecnologias da Internet amplamente usados.

 

Vulnerabilidades populares do Target e sua exploração

 Ghostcat: Vulnerabilidade do Apache Tomcat

Todas as versões do Apache Tomcat Server são vulneráveis à inclusão de arquivos locais e ao potencial RCE. O problema está no protocolo AJP, que é uma versão otimizada do protocolo HTTP. A vulnerabilidade antiga é vulnerável devido ao componente que manipulou um atributo de solicitação de forma inadequada. O protocolo AJP, ativado por padrão, escuta na porta TCP 8009. Vários scanners, scripts de exploração e honeypots surgiram em questão de dias após o divulgação original da Apache.

Estatísticas publicadas por pesquisadores indicam um grande número de sistemas afetados, sendo os números muito maiores do que o previsto originalmente.

Citrix ADC, Citrix Gateway RCE, passagem de diretório

Recentemente, as vulnerabilidades Directory Traversal e RCE, nos produtos Citrix ADC e Gateway, afetaram pelo menos 80.000 sistemas. Logo após a divulgação, várias entidades (Projeto Zero India, Confiável na Sec) lançou publicamente roteiros de PoC que geraram uma série de tentativas de exploração, de vários atores na selva.

Exposição de dados confidenciais do Jira

 Há alguns meses, pesquisadores descobriram que o Jira Instances vazava informações confidenciais, como nomes, funções, IDs de e-mail dos funcionários. Além disso, detalhes internos do projeto, como marcos, projetos atuais, detalhes do proprietário e do assinante, etc., também estavam acessíveis a qualquer pessoa que fizesse uma solicitação aos seguintes endpoints do JIRA não autenticados:

 

https://jirahost/secure/popups/UserPickerBrowser.jspa

https://jirahost/secure/ManageFilters.jspa?filterView=popular

https://jirahost/secure/ConfigurePortalPages! default.jspa? visualização = popular

Avinash Jain, da Grofers, testou a vulnerabilidade em vários alvos e descobriu um grande número de instâncias vulneráveis do Jira, revelando dados confidenciais pertencentes a várias empresas, como NASA, Google e Yahoo, e seus funcionários.

 Vazamento de dados do Spring Boot por meio de atuadores

O Spring Boot é uma estrutura MVC de código aberto baseada em Java. Ele permite que os desenvolvedores configurem rapidamente rotas para fornecer dados por HTTP. A maioria dos aplicativos que usam a estrutura Spring MVC agora também usa o utilitário Boot. A inicialização ajuda os desenvolvedores a configurar quais componentes adicionar e também a configurar o Framework mais rapidamente.

Um recurso adicional da ferramenta chamado Actuator permite que os desenvolvedores monitorem e gerenciem seus aplicativos/API REST, armazenando e fornecendo despejos de solicitações, métricas, detalhes de auditoria e configurações do ambiente.

No caso de uma configuração incorreta, esses atuadores podem ser uma porta traseira para os servidores, tornando os aplicativos expostos suscetíveis a violações. A configuração incorreta nas versões 1 a 1.4 do Spring Boot concedeu acesso aos endpoints do Actuator sem autenticação. Embora as versões posteriores protejam esses endpoints por padrão e permitam acesso somente após a autenticação, os desenvolvedores ainda tendem a ignorar a configuração incorreta antes de implantar o aplicativo.

Os seguintes terminais do atuador vazam dados confidenciais:

/despejarexecuta um despejo de linha e retorna o despejo/traçarretorna o despejo das solicitações HTTP recebidas pelo aplicativo/arquivo de logretorna o conteúdo registrado pelo aplicativo/desligarordena que o aplicativo seja desligado normalmente/mapeamentosretorna uma lista de todos os caminhos @RequestMapping/envexpõe todos os valores do ConfigurableEnvironment do Spring/saúderetorna as informações de saúde do aplicativo

 

Existem outros terminais defeituosos do Actuator, que fornecem informações confidenciais para:

• Obtenha informações do sistema
• Envie solicitações como usuários autenticados (aproveitando os valores da sessão obtidos dos despejos de solicitações)
• Execute comandos críticos, etc.

Webmin RCE via funcionalidade de backdoor

O Webmin é uma ferramenta popular de configuração de sistema baseada na web. Uma vulnerabilidade RCE de pré-autenticação de dia zero afeta algumas de suas versões, entre 1.882 e 1.921. Essa vulnerabilidade ativa a funcionalidade de alteração remota de senha. O repositório de código Webmin no SourceForge estava coberto de códigos maliciosos que permitiam a capacidade de execução remota de comandos (RCE) em um endpoint afetado.

O atacante envia seus comandos com parâmetros de alteração de senha por meio de `password_change.cgi` no host vulnerável que está executando o Webmin. E se o aplicativo Webmin estiver hospedado com privilégios de root, o adversário poderá executar comandos maliciosos como administrador.

Por que os agentes de ameaças exploram vulnerabilidades?

1. Violar dados do usuário/empresa: Exfiltração de dados confidenciais/PII
2. Poder de computação: Infectando sistemas para minerar criptomoedas e veicular arquivos maliciosos
3. Botnets, servindo arquivos maliciosos: Explorações destinadas a adicionar mais bots a uma botnet maior
4. Interrupção do serviço e, eventualmente, resgate: Bloqueando usuários dos dispositivos
5. Razões políticas, guerra cibernética, usuário irritado, etc.

 

Como os adversários exploram as vulnerabilidades?

Ao revelar tais vulnerabilidades, os adversários investigam a Internet em busca de detalhes técnicos e códigos de exploração para lançar ataques. Pesquisa da Rand Corporation e a análise de vulnerabilidades de dia zero afirma que, após a divulgação de uma vulnerabilidade, é necessário 6 a 37 dias e um mediana de 22 dias para desenvolver uma exploração totalmente funcional. Mas quando a divulgação de um exploit vem com um patch, desenvolvedores e administradores corrigem imediatamente o software vulnerável. A atualização automática, as atualizações regulares de segurança e a cobertura em grande escala dessas divulgações ajudam a conter os ataques. No entanto, vários sistemas executam as versões não corrigidas de um software ou aplicativo e se tornam alvos fáceis para esses ataques.

Etapas envolvidas na exploração da vulnerabilidade

Quando um malfeitor decide explorar uma vulnerabilidade, ele precisa:

• Obtenha uma exploração funcional ou desenvolva uma exploração (no caso de uma vulnerabilidade de dia zero)
• Utilize a Prova de Conceito (PoC) anexada a um relatório de bug (no caso de divulgação de um bug)
• Identifique o maior número possível de hosts vulneráveis à exploração
• Maximize o número de alvos para maximizar os lucros.

Caça ao alvo

Embora os respectivos fornecedores corrijam as vulnerabilidades relatadas, ao pesquisar no GitHub ou em CVEs específicos no ExploitDB, podemos encontrar scripts de PoC para os problemas. Normalmente, os scripts PoC requerem um host/URL como entrada e medem o sucesso da exploração/exame.

Os adversários identificam um hospedeiro vulnerável por meio de suas assinaturas/comportamento, para gerar uma lista de hospedeiros exploráveis. Os componentes a seguir possuem assinaturas que determinam se um host está vulnerável ou não:

• Porto
• Caminho
• Subdomínio
• Conteúdo/URL indexados

Porto

Muitos softwares comumente usados têm uma (s) porta (s) de instalação padrão específica. Se uma porta não estiver configurada, o software será instalado em uma porta predefinida. E, na maioria dos casos, um software é instalado na porta padrão. Por exemplo, a maioria dos sistemas usa a porta padrão 3306 para instalar o MySQL e portar 9200 para Elasticsearch. Portanto, ao selecionar uma lista de todos os servidores com uma porta 9200 aberta, um agente de ameaças pode determinar os sistemas que executam o Elasticsearch. No entanto, a porta 9200 também pode ser usada para instalar outros serviços/software.

Usando varreduras de portas para descobrir alvos e explorar as vulnerabilidades do Webmin RCE

• Determinar se a porta padrão em que o Webmin escuta após a instalação é a porta 10000.
• Obtenha um PoC funcional para o exploit do Webmin.
• Execute uma varredura de portas em todos os hosts conectados à Internet para a porta 10000.
• Isso levará à descoberta de todas as instalações possíveis do Webmin que podem estar vulneráveis à exploração.

Além disso, ferramentas como Shodan facilite a descoberta de alvos baseada em portas. Ao mesmo tempo, se o Shodan não indexar a porta de destino, os atacantes utilizam ferramentas como MassScan, Zenmap e execute um em toda a Internet escanear. A última abordagem dificilmente leva um dia se o atacante tiver recursos suficientes.

Da mesma forma, um invasor em busca de uma maneira fácil de encontrar uma lista de sistemas afetados pelo Ghostcat escaneará todos os IPs de destino e reduzirá as máquinas com porta 8009 abrir.

Caminho

Os softwares/serviços geralmente são instalados em um caminho padrão distinto. Assim, o software pode receber impressões digitais observando o caminho da assinatura. Por exemplo, as instalações do WordPress podem ser identificadas se o caminho 'wp-login.php'é detectado no servidor. Isso facilita a localização do serviço quando ele acessa um navegador da web.

Por exemplo, quando o utilitário phpmyadmin é instalado, por padrão, ele é instalado no caminho '/phpmyadmin'. Um usuário pode acessar o utilitário por esse caminho. Nesse caso, uma verificação de portas não ajudará, pois esse utilitário não é instalado em uma porta específica.

Usando caminhos distintos para descobrir alvos para explorar o vazamento de dados do Spring Boot

• Reúna uma lista de hosts que executam o Spring Boot. Como os aplicativos padrão do Spring Boot iniciam na porta 8080, ajudaria ter uma lista de hosts que têm essa porta aberta. Isso permite que os agentes de ameaças vejam um padrão.
• Bata endpoints específicos, como '/trace', '/env' nos hosts e verifique a resposta quanto a conteúdo confidencial.

Scanners de caminhos da Web e ferramentas de fuzzer da Web, como Pesquisa de pesquisa ou Fruf facilitar esse processo.

Embora as respostas possam incluir falsos positivos, os atores podem usar técnicas, como correspondência de assinaturas ou verificação estática de regras, para restringir a lista de hospedeiros vulneráveis. Como esse método opera com solicitações e respostas HTTP, o processo pode ser muito mais lento do que as varreduras de portas em grande escala. Shodan também pode buscar hosts com base em respostas http, a partir de seu índice.

Subdomínio

O software geralmente é instalado em um subdomínio específico, pois é uma maneira mais fácil, padrão e conveniente de operar o software.

Por exemplo, o Jira é comumente encontrado em um subdomínio, como em 'jira.domain.com' ou 'bug-jira.domain.com'. Embora não haja regras quando se trata de subdomínios, os adversários podem identificar certos padrões. Serviços similares, geralmente instalados em um subdomínio, são Gitlab, Ftp, Webmail, Redmine, Jenkins, etc.

Security Trails, Circl.lu, Rapid7 Open Data mantenha registros DNS passivos. Outros scanners que mantêm esses registros seriam sites como Crt.sh e Censys. Eles coletam registros de certificados SSL regularmente e têm um recurso adicional que suporta consultas.

Conteúdo/URL indexado

O conteúdo publicado pelos serviços geralmente é exclusivo. Se empregarmos mecanismos de pesquisa, como o Google, para encontrar páginas com base em assinaturas específicas, veiculando conteúdo específico, os resultados terão uma lista de URLs executando um serviço específico. Essa é uma das técnicas mais comuns para caçar alvos com facilidade.
É comumente conhecido como 'Google Dorking'. Por exemplo, os adversários podem selecionar rapidamente uma pequena lista de todas as páginas de login do cPanel. Para isso, eles poderiam usar o seguinte Dork na Pesquisa do Google: “site: cpanel.*.* no título:” login” -site: forums.cpanel.net”. O Banco de dados de hackers do Google contém vários desses Dorks e, depois de entender o mecanismo de pesquisa, é fácil escrever essas consultas de pesquisa.

Observações

Houve vários experimentos com potes de mel para estudar a exploração e exploração em grande escala na natureza. Configurar potes de mel não é apenas uma boa maneira de entender os padrões de ataque, mas também serve para identificar agentes maliciosos que estão tentando explorar sistemas na natureza. Esses IPs/redes identificados que tentam enumerar alvos ou explorar sistemas vulneráveis acabam em várias listas negras públicas. Várias tentativas de pesquisa criaram diversos honeypots e estudaram as técnicas usadas para obter acesso. A maioria das tentativas é obter acesso por meio de credenciais padrão e se originou principalmente de endereços IP na lista negra.

Outra observação interessante é que, a maior parte do tráfego detectado pelo honeypot, parece ter origem na China. Também é muito comum ver honeypots específicos para uma superfície de dia zero no Github logo após o lançamento de um exploit. A vulnerabilidade do Citrix ADC (CVE-2019-19781) também vi alguns honeypots sendo publicado no Github pouco tempo após o lançamento do primeiro PoC de exploração.

Pesquisa realizado pela Sophos destaca a alta taxa de atividade em alvos expostos usando honeypots. Conforme relatado no artigo de pesquisa, foi retirado de menos de um minuto para 2 horas para o primeiro ataque ao alvo exposto. Portanto, se uma configuração incorreta acidental deixar um sistema exposto à Internet, mesmo que por um curto período de tempo, não se deve presumir que o sistema não foi explorado.