Explicando o Ransomware WannaCry/Wcry


O que é Ransomware WannaCry/Wcry?


No último dia 12 de maio de 2017, um ransomware, chamado Wannacry/Wcry ou, como a Microsoft nomeou, Win32/WannaCrypt, se espalhou e infectou máquinas de grandes empresas privadas e instituições públicas em mais de 70 países.


Esse ransomware - que suporta 28 idiomas e criptografa 179 tipos diferentes de arquivos - obtém as informações das vítimas, as criptografa e exige o pagamento de um resgate para que as pessoas possam recuperá-lo. O valor deve ser pago na “criptomoeda” bitcoin (saiba o que é aqui)  e gira em torno de US$ 300,00a US$ 600,00. Apenas mediante o pagamento é que, em teoria, as vítimas poderão descriptografar o conteúdo de suas máquinas.


Quando surgiu o Ramsomware WannaCry?


Em agosto de 2016, um grupo hacker realizou o vazamento de arquivos contendo ferramentas ofensivas pertencentes à NSA (National Security Agency). Dentre estes arquivos e ferramentas vazadas, estava um exploit remoto que explorava uma falha do SMB (Server Message Block) no Windows, chamada de EternalBlue.


Esse princípio foi o que deu origem ao ransomware Wannacry. Ele utiliza especificamente a vulnerabilidade presente no SMBv1 do sistema operacional Windows.


A vulnerabilidade chegou a receber um patch de correção fornecido pela própria Microsoft (MS17-010) em março de 2017.


Como o WannaCry se espalha?


Após infectar a vítima, o ransomware procura por outras máquinas em uma rede local ou na Internet, e usa o protocolo SMB para infectá-las.  


Para continuar propagando seus códigos maliciosos, ele usa um gerador de números aleatórios para criar endereços IP’s randômicos, testá-los e infectá-los.


O Wannacry/Wcry se espalhou rapidamente pelo mundo, pois o mesmo comporta-se como um “worm”, infectando novas vítimas automaticamente, sem a necessidade de interação de um usuário final. Após a infecção, procura computadores vulneráveis na rede e utiliza um exploit para infectar sua nova vítima.


Abaixo é possível verificar o modus operandi e fluxo de execução do WannaCry:



O ransomware afeta os seguintes sistemas operacionais Windows:
  • Microsoft Windows Vista SP2
  • Windows Server 2008 SP2 e R2 SP1
  • Windows 7
  • Windows 8.1
  • Windows RT 8.1
  • Windows Server 2012 e R2
  • Windows 10
  • Windows Server 2016
O Wcry criptografa os seguintes arquivos na máquina infectada:
.jpeg , .rb , .602 , .jpg , .rtf , .doc , .js , .sch , .3dm , .jsp , .sh , .3ds , .key , .sldm , .3g2 , .lay , .sldm , .3gp , .lay6 , .sldx , .7z , .ldf , .slk , .accdb , .m3u , .sln , .aes , .m4u , .snt , .ai , .max , .sql , .ARC , .mdb , .sqlite3 , .asc , .mdf , .sqlitedb , .asf , .mid , .stc , .asm , .mkv , .std , .asp , .mml , .sti , .avi , .mov , .stw , .backup , .mp3 , .suo , .bak , .mp4 , .svg , .bat , .mpeg , .swf , .bmp , .mpg , .sxc , .brd , .msg , .sxd , .bz2 , .myd , .sxi , .c , .myi , .sxm , .cgm , .nef , .sxw , .class , .odb , .tar , .cmd , .odg , .tbk , .cpp , .odp , .tgz , .crt , .ods , .tif , .cs , .odt , .tiff , .csr , .onetoc2 , .txt , .csv , .ost , .uop , .db , .otg , .uot , .dbf , .otp , .vb , .dch , .ots , .vbs , .der” , .ott , .vcd , .dif , .p12 , .vdi , .dip , .PAQ , .vmdk , .djvu , .pas , .vmx , .docb , .pdf , .vob , .docm , .pem , .vsd , .docx , .pfx , .vsdx , .dot , .php , .wav , .dotm , .pl , .wb2 , .dotx , .png , .wk1 , .dwg , .pot , .wks , .edb , .potm , .wma , .eml , .potx , .wmv , .fla , .ppam , .xlc , .flv , .pps , .xlm , .frm , .ppsm , .xls , .gif , .ppsx , .xlsb , .gpg , .ppt , .xlsm , .gz , .pptm , .xlsx , .h , .pptx , .xlt , .hwp , .ps1 , .xltm , .ibd , .psd , .xltx , .iso , .pst , .xlw , .jar , .rar , .zip , .java , .raw


Recomendações:


É importantíssimo que todos os usuários que possuam plataformas baseadas em Windows atualizem seus ambientes (especialmente aplicando a correção MS17-010).


O antivírus deverá estar atualizado e não permitir a criação das seguintes extensões:
00000000.eky,00000000.pky, 00000000.res, @Please_Read_Me@.txt, @WanaDecryptor@.exe, b.wnry, c.wnry, f.wnry, r.wnry, s.wnry, t.wnry, u.wnry.
Por existirem outros vetores de infecção para que ransomwares possam atuar, aconselhamos que não sejam abertos e-mails e anexos que pareçam suspeitos.

A disseminação desmedida do Wcry nos lembra a importância de manter os sistemas sempre atualizados, aplicando patches de segurança e realizando verificações constantes nas infraestruturas internas. Além disso, ressalta a necessidade, cada vez maior, de se investir em segurança da informação.
[Atualização 19/05/2017]

Foi desenvolvida uma ferramenta chamada "WanaKiwi", que simplifica todo o processo de decodificação de arquivos infectados com WannaCry.

Embora a ferramenta não funcione para todos os usuários devido a suas dependências, pelo menos ele dá alguma esperança para as vítimas de WannaCry de obter seus arquivos criptografados de volta gratuitamente, mesmo do Windows XP. O WanaKiwi também funciona nos sistemas Windows 7, Windows Vista, Windows Server 2003 e 2008

Todas as pessoas infectadas têm que fazer o download da ferramenta WanaKiwi do Github e executá-lo em seu computador Windows afetado pelo WannaCry usando a linha de comando (cmd).

WanaKiwi tool
https://github.com/gentilkiwi/wanakiwi/releases

Referências: 

https://nakedsecurity.sophos.com/2017/05/15/wannacry-heres-what-we-know-now-about-the-outbreak/

https://blog.comae.io/wannacry-the-largest-ransom-ware-infection-in-history-f37da8e30a58

https://latesthackingnews.com/2017/05/13/protect-your-self-against-wannacry-ransomware/

http://thehackernews.com/2017/05/how-to-wannacry-ransomware.html


http://thehackernews.com/2017/05/wannacry-ransomware-unlock.html


http://anchisesbr.blogspot.com.br/2017/05/seguranca-perguntas-e-respostas-faq.html


https://blog.comae.io/wannacry-decrypting-files-with-wanakiwi-demo-86bafb81112d

Novo Header de Segurança : Expect - CT


Certificate Transparency


Abril de 2018 é o deadline para que seu certificado esteja devidamente instalado e configurado na aplicação, de acordo com as recomendações da Google. As aplicações que não estiverem em conformidade, irão apresentar mensagens de falta se segurança e não terão as páginas com um bom índice de SEO, ou seja, o site não irá funcionar corretamente no Chrome, não serão tratados como certificados confiáveis pelo browser.  Estas recomendações surgiram de um projeto que a Google iniciou em 2012, chamado de Certificate Transparency, que visa obter a maior transparência possível nas emissões de certificados feitas pelas CA, possível obter mais informações aqui.  
Para ajudar neste processo de adequação as solicitações da Google, a empresa criou um header de segurança, chamado Expect-CT, que permite analisar se a sua aplicação está pronta para as mudanças que serão aplicadas a partir de Abril de 2018.

Signed Certificate Timestamp

Os certificados deverão ser enviados ao servidor do Certificate Transparency (CT) pela CA que os emitiu, entretanto, é possível que o mantenedor do site faça isso. Signed Certificate Timestamp (SCT) é o response de um log de um certificado, ele que deve ser entregue aos clientes quando é feita estabelecida uma conexão TLS, e isso pode ser feito de três maneiras:

x.509v3 Extension

Uma extensão que já vem com o certificado, ou seja, quando sua CA emite o certificado, ela entrega esta extensão que já faz a entrega SCT, sem necessitar de uma ação por parte do dono do site que não seja a instalação típica.

TLS Extension

Via extensão TLS, onde é necessária uma ação por parte do dono do site, aplicando a extensão chamada de signed_certificate_timestamp

OCSP Stapling

OCSP Stapling é normalmente usado para obter informações sobre a revogação dos certificados em um servidor, mas também serve para entrega do SCT.  

Clicando aqui, é possível ver como funciona um log, ele busca todos os certificados que foram instalados no seu domínio.


Header Expect-CT


Para implementar o header, não requer muita configuração. As suas diretivas disponíveis são:

Enforce – A diretiva enforce é opcional, ela controla se o browser deve aplicar uma política ou trata-la como report-only.
Max-age – A diretiva max-age especifica o número de segundos que o browser deve fazer cache e aplica a política para enforced ou report-only
Report-uri – A diretiva report-uri especifica onde o browser deve enviar relatórios, caso não esteja recebendo informações validas do CT.


Aplicando o Header

Para aplicar o header, é importante que esteja no modo report-only para testar e certificar que não irá causar alguma falha. Isso significa que deve omitir a diretiva enforce e aplicar max-age para 0. Exemplo:

Expect-CT: max-age=0; report-uri="https://meusite.report-uri.io/r/default/ct/reportOnly"
Essa política é implementada no modo report-only e se o browser não receber as informações CT de acordo, será referenciado como não qualificado e ao invés de terminar a conexão, será enviado um relatório para o valor report-uri especificado. Quando as configurações estiverem corretas e as entregas de SCTs estejam de acordo, aplique a politica Expect-CT. Inicie o processo com um “max-age” baixo.

Expect-CT: enforce; max-age=30; report-uri=https://meusite.report-uri.io/r/default/ct/enforce
Agora o browser irá fazer o cache e aplicar esta política em todas as conexões do site por 30 segundos.

As especificações do header podem ser encontradas aqui.
Essa opção ajuda para que a sua aplicação esteja de acordo com os requerimentos que a Google pede. Mesmo que sua CA forneça o certificado com o SCT, considero ser importante a aplicação do header, pois um dia você poderá trocar de CA.

Referencias:

Vulnerabilidade SSRF – Explicando o ataque e como se prevenir


Server Side Request Forgery em uma tradução literal seria uma “Falsificação de solicitação via o lado do servidor”. O SSRF é uma vulnerabilidade na qual um atacante força um servidor a executar solicitações em seu nome. Aplicativos Web podem acionar solicitações entre servidores, que normalmente são usadas para buscar recursos remotos como, atualizações de software, importar dados de uma URL, etc. Embora essas solicitações entre servidores normalmente sejam seguras, elas podem tornar o servidor vulnerável à falsificação de solicitações do lado do servidor caso sejam implementadas incorretamente.

Uma vulnerabilidade SSRF permite que um invasor altere parâmetros usados em um aplicativo da Web para criar ou controlar solicitações de um servidor vulnerável. Quando as informações de um aplicativo da Web precisam ser recuperadas de um recurso externo, as solicitações do lado do servidor são usadas para buscar o recurso e incluí-lo na aplicação. Por exemplo, um desenvolvedor pode usar uma URL como https://exemplozero.com.br/feed.php?url=siteexterno.com/feed/ para recuperar um feed remoto.

Se o atacante é capaz de alterar o parâmetro url para localhost, então ele é capaz de visualizar os recursos locais hospedados no servidor, tornando-o vulnerável a um ataque Server Side Request Forgery.

Caso um atacante seja capaz de controlar o destino de solicitações do lado do servidor, eles podem executar as seguintes ações:
  • Realizar o by-pass de whitelists de IP.
  • Ignorar serviços de autenticação baseados no host.
  • Ler os recursos que não estão acessíveis ao público, como trace.axd em ASP.NET ou APIs de metadados em um ambiente AWS.
  • Realizar a digitalização da rede interna à qual o servidor está conectado.
  • Ler arquivos do servidor web.
  • Visualizar páginas de status e interagir com APIs como servidor da Web.
  • Recuperar informações confidenciais, como endereços IP de um servidor da Web atrás de um proxy reverso.



Como funciona uma exploração básica de uma vulnerabilidade Server Side Request Forgery:



Uma vez que o invasor não pode enviar solicitações diretas ao servidor da vítima, porque elas são bloqueadas por um firewall, para verificar uma rede interna o atacante precisa:
  1. Envia uma solicitação ao servidor web vulnerável que se utiliza da vulnerabilidade SSRF.
  2. O servidor web faz uma solicitação para o “servidor vítima” que fica atrás do firewall.
  3. O “servidor vítima” responde com os dados.
  4. Se a vulnerabilidade específica do SSRF permitir, os dados são enviados de volta ao atacante.

O ataque de SSRF pode gerar vários impactos para a vítima, porém, o resultado mais comum é a divulgação de informações, como:
  • Digitalizar portas e endereços IP.
  • Interagir com alguns protocolos como o Gopher, que permitem que o atacante faça descobertas adicionais sobre a rede interna da vítima.
  • Descobrir os endereços IP dos servidores em execução atrás de um proxy reverso.
  • Execução remota de código dentro do servidor utilizando shellcode.

Além dos exemplos acima, há várias outras coisas que os invasores podem fazer quando exploram uma vulnerabilidade SSRF, algumas das quais podem ter consequências mais graves, mas depende principalmente de como a aplicação web usa as respostas do recurso remoto.

Para evitar vulnerabilidades do SSRF em suas aplicações Web, é altamente recomendável usar uma lista de permissões de domínios e protocolos de onde o servidor da Web pode buscar recursos remotos.

Além disso, como regra geral, você deve evitar usar a entrada do usuário diretamente em funções que podem fazer solicitações em nome do servidor. Você também deve desinfetar e filtrar a entrada do usuário, mas normalmente é muito difícil de configurar, principalmente porque é praticamente impossível cobrir todos os cenários diferentes.

Referências:


4 tipos de ataques comuns no XML


Para quem não conhece, a sigla XML é o acrônimo de EXtensible Markup Language, um termo que foi originalmente criado para suprir os desafios das publicações em larga escala. Hoje, o XML é muito utilizado em serviços web como SOAP, REST, WSDL, RSS feed, Atom e também arquivos de configurações de aplicações mobile e desktop.
Os ataques a esse formato de arquivo normalmente acontecem na inserção de dados no XML ou na entrada que é usada para criá-lo - muitos desses ataques utilizam funcionalidades específicas do XML para a ação.
Confira abaixo alguns ataques que podem acontecer no XML:
XML External Entities (XXE)
O ataque XXE é um dos mais conhecidos no XML e o que tem sido explorado ultimamente em aplicações de grandes empresas, incluindo as que participam de programas de bug bounty, onde são oferecidas recompensas para pesquisadores que encontram vulnerabilidades no sistema.
O XML possui uma característica que permite que o desenvolvedor aponte para um endereço onde o dado está armazenado, local ou remotamente.
Com isso, um atacante pode alterar essa informação e solicitar dados locais ou remotos como no exemplo abaixo:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [  
 <!ELEMENT foo ANY >
 <!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foo>&xxe;</foo>


XML Injection
Os ataques de injeção de dados no XML funcionam de forma parecida com o de scripts, para quem está familiarizado. Podemos subdividir este ataque em três: XML Data Injection, Extensible Stylesheet Language Transformations (XSLT) Injection e XPath/XQuery Injection.


  • XML Data Injection: neste tipo de ataque é realizada a inserção de dados no arquivo XML. Normalmente esses dados não são controlados pelo atacante, mas são interpretados pela aplicação para determinar uma ação, por exemplo:
<?xml version="1.0" encoding="UTF-8"?>
<USER role="user">Atacante</USER>
Caso a aplicação leia estas informações acima para determinar uma ação, o atacante poderá inserir alguns dados com outras permissões para tentar fazer um bypass no controle de acesso de usuários, da seguinte forma:
<?xml version="1.0" encoding="UTF-8"?>
<USER role="user">Usuario1</USER>
<USER role="admin">Atacante</USER>


  • Extensible Stylesheet Language Transformations (XSLT) Injection: neste tipo de ataque, em vez de injetar dados no arquivo XML, o objetivo é inserir códigos que sejam executados no documento. O XSL consiste em XSL Transforms (XSLT), expressões XML Path Language (XPath), XSL Formatting Objects (XSL-FO) e uma folha de estilo (tipo um CSS) que pode ser aplicado em um arquivo XML. Esta folha de estilos pode transformar os dados do arquivo XML em novos dados XML aplicando esta formação. Com isso, um atacante pode injetar códigos capazes de resultar na execução do script no navegador.


  • XPath/XQuery Injection: o XPath e XQuery são linguagens que permitem consultar um documento XML de forma muito semelhante ao SQL, aliás muitos bancos de dados permitem consultar o banco de dados usando XPath ou XQuery. Neste caso um atacante pode criar uma instrução XPath ou XQuery e injetar consultas para obter dados que não seriam possíveis através pelo método convencional. Confira abaixo o exemplo retirado da apresentação do Daniel Tomescu para o OWASP.
Arquivo: employees.xml
<?xml version="1.0" encoding="utf-8"?>
<Employees>
<Employee ID="1">
<Name>Mike</Name>
<UserName>Mike07</UserName>
<Password>TopSecret</Password>
<Type>Admin</Type>
</Employee>
</Employees>
Código C#
String FindUserXPath;
FindUserXPath =
    "//Employee[UserName/text()='"
    + Request("Username")
    + "' And Password/text()='"
    + Request("Password") + "']";


Payload
Username: Mike07
Password: oops' or 'a'='a
Resultado da injeção: FindUserXPath
//Employee[UserName/text()='Mike07' And Password/text()='oops' or 'a'='a']


Infinite Entity Loops
É possível criar um loop infinito dos entities quando criamos duas entradas e uma chama a outra, veja o exemplo abaixo:
<!ENTITY % aa '&#x25;bb;'>
<!ENTITY % bb '&#x25;aa;'>
%aa;
Se você observar o código acima, verá que o entity aa chama o entity bb, que por fim chama o entity aa e com isso entra em um loop infinito gerando um ataque de DoS.
XML Bombing
O ataque de XML Bombing é muito parecido com o loop infinito e tem como objetivo causar um ataque DoS. Confira abaixo um exemplo retirado do artigo do Rami Jaamour:
<?xml version="1.0" ?>
<!DOCTYPE foobar [
<!ENTITY x0 "Bang!">
<!ENTITY x1 "&x0;&x0;">
<!ENTITY x2 "&x1;&x1;">
...
<!ENTITY x99 "&x98;&x98;">
<!ENTITY x100 "&x99;&x99;">
]>
Quando as entities são chamadas recursivamente, ele irá chamar uma quantidade enorme de elementos que irão aumentar o uso de recursos e causar o DoS.


Conclusão
Mesmo no XML os cuidados de segurança devem aplicados de forma rígida, seja na configuração, na validação de dados ou na criação do arquivo XML, além disso, a aplicação do XML Encryption e o XML Signature são obrigatórias quando houver a manipulação de dados sensíveis.
Caso você tenha interesse em testar esses ataques de uma maneira mais prática, eu recomendo olhar o framework chamado Magical Code Injection Rainbow (MCIR) criado pelo Daniel Crowley e disponível no endereço https://github.com/SpiderLabs/MCIR.


Fontes:

GALLAGHER Tom; JEFFRIES Bryan; LANDAUER Bryan. Hunting Security Bugs (Developer Reference) Microsoft Press; 1 edition (June 9, 2006)