Ransomware: Exploração Bluekeep



Foi confirmado nesta segunda-feira (04/11/19) um ataque em massa a níveis globais de um ransomware que se aproveita da falha bluekeep para invasão de sistemas Microsoft Windows e posteriormente realiza a criptografia total dos dados pedindo um resgate para decodificação dos arquivos. A situação é semelhante ao ocorrido em maio de 2017 quando o Ransomware Wannacry causou danos a diversas empresas ao redor do mundo, este artigo explica o ataque http://labs.siteblindado.com/2017/05/explicando-o-ransomware-wannacrywcry.html.

Bluekeep
A vulnerabilidade Bluekeep que possui patch lançado pela Microsoft no último mês de Maio, tem por finalidade explorar solicitações específicas ao serviço de RDP (Remote Desktop Protocol) culminando em uma RCE (Remote Code Execution) quando o atacante ganha acesso à linha de comando da máquina alvo.

A CVE-2019-0708 (https://www.cvedetails.com/cve/CVE-2019-0708/) classifica a vulnerabilidade como gravíssima e de alta probabilidade de exploração.

“O BlueKeep é considerado uma ameaça tão séria que, desde sua descoberta, a Microsoft e até as agências governamentais [NSA e GCHQ] incentivam continuamente os usuários e administradores do Windows a aplicar patches de segurança antes que os hackers se apoderem de seus sistemas. Algumas empresas e pesquisadores individuais de segurança cibernética que desenvolveram com sucesso uma exploração totalmente funcional da vulnerabilidade BlueKeep se comprometeram a não divulgá-la para um bem maior - especialmente porque quase 1 milhão de sistemas foram considerados vulneráveis mesmo um mês após o lançamento dos patches.” (Fonte: https://thehackernews.com/2019/11/bluekeep-rdp-vulnerability.html)
  
 
Na imagem, um resgate é solicitado em criptomoedas cujo número não é especificado (exigindo contato por e-mail para conhecê-lo) e também alerta que ainda não existe uma ferramenta capaz de decifrar o conteúdo criptografado pelo ransomware. (Fonte: https://www.adslzone.net/2019/11/04/bluekeep-ransomware-cadena-ser/)


Alguns dos IPs e hashes referentes ao ataque são listados abaixo. É interessante para as equipes de infraestrutura das empresas cadastrarem este tipo de informação em seus antivírus e firewalls para que eles sejam capazes de detectar estas assinaturas em caso de infecção:

Hashes-256

aaba14efe6e0d19473b3ead438b8946bb38be4095ae8cbfa30b043abdd805248
38243164cfd58c2a1b218e3fbec82a26edcfdf9cecd1d5f78e93f5d1568b8d81
e5af2dc235654574bf807324028429c5580d96d5363c4bbbcfa722c79c385d3d
3ff988e7f53e591feb3d79e9dcf78fcb793f52971592032c110889eaa90ba344
59e62ebb996177d9153834062110456a88cb7fd45e2fed701bc08fc1eee668da
57055dfdbba5415069ff78cebdc1956351213251b21222c043cf6ff27d222212
f509b825008375a921f137f3db76acdb1657b4f06c5d194837b9db46ea2293d0
3c47960346daef8e8c15b9e4bb20fa38c963cd1f4771119389efaf70905443ee
19a9b1f4d9571ef677e9ebcf1acf2ba982bbfd50b133cc38d9aad844a4cf7ffe
8faae67e72b94bb3d7167381242cc94fb18710fa3f1bd121b817f2de15ccceac
8a87a1261603af4d976faa57e49ebdd8fd8317e9dd13bd36ff2599d1031f53ce

URLs e IPs identificados

http://109.176.117.11/362611986ed4/page
http://109.176.117.11:8000/
http://109.176.117.11:8080/362611986ed4/page
http://109.176.117.11/
109.176.117.11
http://5.100.251.106:443/64.exe
http://5.100.251.106:52057/
http://5.100.251.106
5.100.251.106
http://5.100.251.106
5.100.251.106
http://5.100.251.106:52057
5.100.251.106
http://5.100.251.106:443/64.exe
5.100.251.106
http://5.100.251.106:443/sync.pif
5.100.251.106
http://5.100.251.106/sync32.pif
5.100.251.106

Mitigação

A priori, recomendações de boas práticas de segurança são: desativar o serviço RDP quando desnecessário e bloquear a porta 3389 por um firewall.

Segundo boletim da Microsoft, a aplicação do KB4500331 (Windows Server 2003+) KB4499180(Windows Vista+) mitiga a vulnerabilidade e já é disponibilizado nos pacotes cumulativos de atualizações.
  
Referências:
https://thehackernews.com/2019/11/bluekeep-rdp-vulnerability.html
https://www.adslzone.net/2019/11/04/bluekeep-ransomware-cadena-ser/
https://www.virustotal.com/gui/file/8a87a1261603af4d976faa57e49ebdd8fd8317e9dd13bd36ff2599d1031f53ce/community



Slow HTTP – Identificação e proteção

O Slow HTTP é um ataque de negação de serviço (DoS) na camada de aplicação, e podem, de forma simples, tirar um servidor que possua recursos limitados do ar. 

Devido ao baixo volume e velocidade lenta das requisições, esse tipo de ataque é difícil de ser identificado e pode causar danos semelhantes à um DDoS com grande volume de tráfego.

Entendendo o ataque

O protocolo HTTP exige que as requisições sejam completamente recebidas pelo servidor antes de serem processadas. Caso uma requisição HTTP não seja concluída ou se a taxa de transferência for muito baixa, o servidor fica aguardando os dados que ficaram faltando. Se o servidor mantiver muitos recursos ocupados, isso ocasionará uma negação de serviço.

Na imagem abaixo vemos um relatório de um ataque “slowhttptest” realizado, onde o domínio fica claramente com o serviço indisponível por instantes (partes do gráfico que não possuem a cor verde).


Identificando o ataque

Se o seu servidor estiver sob ataque, você verá várias conexões na porta 80 do IP de origem. O comando netstat pode mostrar essas informações conforme abaixo:

$ netstat -nalt | grep :80
tcp   0   0    
0.0.0.0:80              0.0.0.0:*                LISTEN
 tcp   0   0  24.34.0.1:4840      22.50.19.04:80      ESTABLISHED
 tcp   0   0  24.34.0.1:4841      22.50.19.04:80      ESTABLISHED
 tcp   0   0  24.34.0.1:4839      22.50.19.04:80      CLOSE_WAIT
 tcp   0   0  24.34.0.1:4838      22.50.19.04:80      CLOSE_WAIT
 tcp   0   0  24.34.0.1:4808      22.50.19.04:80      ESTABLISHED
 tcp   0   0  24.34.0.1:4898      22.50.19.04:80      CLOSE_WAIT
 tcp   0   0  24.34.0.1:4890      22.50.19.04:80      ESTABLISHED

A informação abaixo mostra, em um servidor Apache, um número muito baixo de consumo de CPU, vários processos do Apache e poucas novas requisições.

$ apachectl status
    CPU Usage: u3.1 s.2 cu0 cs0 - 1.0% CPU load
    .913 requests/sec - 31.1 kB/second - 17.5 kB/request
    611 requests currently being processed, 2 idle workers

O atacante atua fazendo várias requisições até atingir o limite do Apache’s MaxClients. Se olharmos o log, será como o abaixo:

$ cat /var/log/httpd/error.log
  [mpm_prefork:error]  [pid  1842]  AH00161:  server  reached
MaxRequestWorkers  setting,  consider  raising  the
MaxRequestWorkers setting

Depois podemos identificar o endereço IP de origem do atacante usando o netstat e bloqueá-lo.

Ficando menos vulnerável ao Slow HTTP

Para proteger o servidor web contra esse tipo de ataque, é recomendado:

- Descartar conexões com métodos de requisição HTTP não suportados.
- Limitar o cabeçalho e o corpo da mensagem.
- Definir limites mais específicos de URL.
- Definir um tempo limite de conexão, sem deixar que conexões lentas legítimas sejam perdidas.

As alternativas acima são as medidas mais simples e genéricas para minimizar a ameaça.

O ajuste da configuração do servidor da Web é eficaz até certo ponto, embora exista sempre um problema entre limitar ataques HTTP lentos e eliminar solicitações legitimamente lentas. Isso significa que você nunca pode impedir ataques simplesmente usando as técnicas acima.

Além de configurar o servidor da Web, é possível também implementar outras camadas de proteção, como balanceadores de carga de software acionados por eventos, sistemas de detecção / prevenção de intrusão para eliminar conexões com padrões suspeitos, e é claro que contratar um serviço de proteção especializada anti-DDoS irá garantir uma segurança a mais para a sua aplicação.

Referências





Jira vaza informações sobre usuários e projetos



Na última semana, o pesquisador de segurança, Avinash Jain publicou no Medium (blog pessoal), o alerta sobre um erro de configuração na plataforma de produtividade Jira.

Apesar de simples, essa falha permite acesso às informações sensíveis sobre funcionários e projetos de grandes companhias. Estão incluídas organizações como NASA, Google, Yahoo, Zendesk e Lenovo, assim como empreendimentos brasileiros e até mesmo órgãos governamentais.

O Jira é um serviço online desenvolvido pela Atlassian, usado por companhias e organizações globalmente. A ferramenta permite monitorar tarefas e realizar acompanhamento de projetos corporativos.

A seguir, conheça o ponto de falha e as etapas que podem ser realizadas a fim de corrigir a vulnerabilidade e evitar que informações da sua organização sejam vazadas.


Conhecendo a Falha

No Jira, ao criar filtros ou dashboards (painéis) é fornecido algumas opções quanto a visibilidade desses recursos criados. O problema foi devido a permissões incorretas atribuídas a eles.

Quando esses filtros e painéis para os projetos são criados no Jira, as opções de configuração de visibilidade a serem definidas são: "Todos os usuários" ou "Todo mundo"; caso o administrador selecione a segunda opção, interpretando erroneamente que as informações do projeto estarão visíveis para todos da empresa, esses dados estarão expostos publicamente na internet.

Como resultado da configuração incorreta, as informações abaixo podem estar publicamente visíveis:

  1. - Nome de usuário, nome completo e endereço de e-mail de todos funcionários;
  2. - Funções e regras através dos grupos do Jira;
  3. - Projetos secretos, filtros e dashboards do Jira.
Qualquer um com o link acessa os dados confidenciais - incluindo, sem dúvidas, criminosos cibernéticos que podem utilizar essas informações para realizar ataques de phishings, assim como espionagem corporativa. Basta uma query específica no Google (Google Dorks) para obter os resultados com os links de organizações que configuraram incorretamente as permissões de exibição dos recursos da plataforma Jira.

Como solucionar a exposição de dados?

Com o propósito de prevenir a exibição desses dados publicamente na internet, um comunicado de recomendação de usuários no fórum da Hacker News foi publicado com as etapas a serem seguidas para que seja corrigida a configuração de permissão de acesso, "To prevent this issue as a site admin on Jira cloud, go to: Jira Settings -> System -> General Configuration and disable “Allow users to share dashboards and filters with the public.” This doesn’t affect existing filters, which you have to manually fix."

Parafraseando o pesquisador Avinash: "embora seja mais um problema de configuração incorreta, o Atlassian (JIRA) deve cuidar e ser mais explicitamente claro sobre o que significa “Qualquer usuário logado”, seja ele um usuário logado do JIRA ou apenas um usuário logado pertencente a uma conta específica da empresa Jira."

*Vale ressaltar que não publicaremos a query de busca a fim de resguardar a privacidade de todas as companhias vítimas deste erro de configuração. Recomendamos que todos os usuários da plataforma utilizem o processo abaixo e reconfigurem o serviço, garantindo que nenhuma informação sensível esteja exposta.


Referências:

https://medium.com/@logicbomb_1/one-misconfig-jira-to-leak-them-all-including-nasa-and-hundreds-of-fortune-500-companies-a70957ef03c7

https://news.ycombinator.com/item?id=20595658

Entenda melhor o HTTP CORS



O que é CORS ou Cross-Origin-Resource Sharing

Primeiramente, vamos entender o significado de uma origem (origin), que provém do Same Origin Policy.

Dois sites são considerados 'same origin' se eles têm em comum:

- hostname;
- protocolo http, https;
- se trabalham na mesma porta (80, 8080, 7001...).

Por exemplo, 
http://www.siteblindado.com e http://www.siteblindado.com/labs possuem a mesma origem.
Entretanto, http://www.siteblindado.com:7001 e http://www.siteblindado.com:8080 possuem origens distintas.

O Same Origin Policy restringe como um script de uma origem pode interagir com o conteúdo de uma outra origem. É um mecanismo de segurança para que os browsers diminuam as ações de scripts maliciosos. 

Tendo em vista o cenário acima, quando uma aplicação web consegue ler os dados de uma outra aplicação, estamos falando de CORS.
Sendo assim, essa especificação permite uma comunicação cross-domain, através do browser. Essa feature é possível ao adicionar no HTTP Headers as origens que são permitidas para o cross-domain. Ou seja, o CORS serve para flexibilizar o Same Origin Policy.
Ainda, vale ressaltar que CORS é muito utilizado, especialmente em APIs.

Na configuração dos Headers, o Origin fica responsável por validar se a request tem a origem do domínio correto. 

O Access-Control-Allow-Origin fica responsável por validar se o 'response' é permitido ou não. Caso seja ‘setado’ de forma indevida, torna a aplicação vulnerável. 

E o que a torna vulnerável?

Misconfiguration (Top 10 Owasp), a configuração incorreta da feature faz com que a mesma fique vulnerável. O erro mais comum é "setar" os domínios permitidos com um wildcard (*). Exemplo:

GET /api/labs.php
Host: 
www.siteblindado.com
Origin: 
www.siteblindado.com

Quando enviado a request acima, é obtido o response com o header Access-Control-Allow-Origin:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true


Quando o header é mal configurado, como a inserção de um wildcard, permite que qualquer domínio tenha acessos aos dados da aplicação.
A partir do momento que qualquer aplicação pode obter dados da aplicação mal configurada, é possível explorar e obter informações privilegiadas ao enviar o 'response' para uma outra aplicação ou server que o invasor desejar. 

Outra possibilidade de exploração, (caso a aplicação tenha sido configurada com o CORS para aceitar apenas o domínio 
teste.com, quando feito o request pelo atacante) seria da seguinte forma: 

GET /api/labs.php
Host: 
siteblindado.com
Connectrion: Close
Origin: 
atacanteteste.com

O response seria: 

HTTP/ 1.1 200 OK
Access-Control-Allow-Origin: 
atacanteteste.com
Access-Control-Allow-Credentials: True


Este erro ocorre, pois possivelmente o back-end foi mal configurado, aceitando “*
teste.com”, ou seja, toda origem que termina em 'teste.com' será validada e o request será aceito. 

Como evitar? 

O melhor método para diminuir riscos é apostar na configuração correta de acordo com suas aplicações.
Caso a aplicação não seja de acesso para conteúdo público, por exemplo, nunca configure o Access-Control-Allow-Origin com um wildcard (*).

Utilize outros headers para uma melhor política de segurança, como a combinação do Access-Control-Allow-Origin, Access-Control-Allow-Credentials e Access-Control-Allow-Methods, para validar e requerer credencias e métodos (GET, POST, DELETE, PUT) que a aplicação no cross-domain poderá utilizar.

Conclusão

Por mais que seja 'apenas' um header, o CORS pode tornar sua aplicação vulnerável a ataques críticos. A combinação com outros headers mal configurados pode, ainda, permitir exposição de dados da aplicação da API e, inclusive, em um RCE.
Mas a aprofundação destes tópicos a gente deixa para os próximos posts. Neste artigo, fica o alerta para que os desenvolvedores realizem a configuração correta da aplicação como um todo.

Referencias

https://www.pivotpointsecurity.com/blog/cross-origin-resource-sharing-security/

https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007)

https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Controle_Acesso_CORS





Testando WebSocket



Segundo a OWASP, WebSockets HTML5 permite que o cliente/servidor criem canais Full-duplex (bidirecionais), possibilitando uma comunicação assíncrona independente da atualização da página após um handshake inicial HTTP.
Plataformas que precisam de comunicação rápida costumam utilizar este meio para envio e recebimento de requisições específicas.
O protocolo possui algumas características bem conhecidas que podem ser exploradas causando algum tipo de transtorno.
Entre elas, o servidor não valida o cabeçalho da origem das requisições, portanto o servidor aceitará comunicação vinda de qualquer lugar possibilitando um ataque de CSRF, por exemplo.
Quando um canal não seguro é utilizado, um atacante pode interceptar a comunicação em texto claro e realizar as requests de seu próprio computador. É importante reconhecer na primeira etapa do teste se a comunicação está utilizando um canal seguro (wss://).
Uma terceira característica encontrada no protocolo é a possibilidade de abertura de inúmeras conexões viabilizando um ataque de negação de serviço.
Existem programas e extensões de browser conhecidos para captura e leitura dos dados de comunicação que utilizam Web Sockets.
As mitigações de tais características são simples, mas requerem atenção. A validação da origem da requisição, utilizar um canal de seguro de comunicação e limitar uma quantidade de conexões por IP são boas práticas que podem ser implementadas para contornar os problemas apresentados.
Conclusão:
Fique ligado ao executar testes de invasão em sites que utilizam esta tecnologia. Se entre interações com a aplicação não são realizadas requisições HTTP, é possível que esteja utilizando WebSockets para troca de informações. Entender como é feito e se inicia o processo de comunicação é um passo essencial para os testes. A partir daí, basta interceptar as requisições e testá-las de acordo com o escopo de cada chamada. O entendimento do funcionamento deste recurso não é difícil, mas seu uso não costuma ser muito difundido.
Você já usou Websocket em alguma aplicação? Já testou alguma aplicação que utiliza este recurso? Conta pra gente.
Fontes:
https://www.owasp.org/index.php/Testing_WebSockets_(OTG-CLIENT-010)
https://www.blackhillsinfosec.com/how-to-hack-websockets-and-socket-io/
https://www.virtuesecurity.com/pentesting-websockets/
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_client_applications