Este artigo faz parte da série Fileless Malware. Todas as outras partes da série:
- As aventuras do malware indescritível, parte IV: campos DDE e documentos do Word (estamos aqui)
Neste artigo, eu iria mergulhar em um cenário de ataque sem arquivo em vários estágios ainda mais complexo com fixação no sistema. Mas então me deparei com um ataque incrivelmente simples e sem código – sem necessidade de macros do Word ou Excel! E isto prova de forma muito mais eficaz a minha hipótese original subjacente a esta série de artigos: romper o perímetro exterior de qualquer organização não é uma tarefa nada difícil.
O primeiro ataque que descreverei explora uma vulnerabilidade do Microsoft Word baseada em desatualizado (DDE). Ela já estava . O segundo explora uma vulnerabilidade mais geral no Microsoft COM e nos recursos de transferência de objetos.
De volta ao futuro com DDE
Alguém mais se lembra do DDE? Provavelmente não muitos. Foi um dos primeiros protocolos de comunicação entre processos que permitiam que aplicativos e dispositivos transferissem dados.
Eu mesmo estou um pouco familiarizado com isso porque costumava verificar e testar equipamentos de telecomunicações. Naquela época, o DDE permitia, por exemplo, que operadores de call center transferissem o identificador de chamadas para um aplicativo de CRM, que acabava abrindo um cartão de cliente. Para fazer isso, você teve que conectar um cabo RS-232 entre o telefone e o computador. Aqueles eram os dias!
Acontece que o Microsoft Word ainda está DDE.
O que torna esse ataque eficaz sem código é que você pode acessar o protocolo DDE diretamente de campos automáticos em um documento do Word (tiramos o chapéu para o SensePost por sobre isso).
Códigos de campo é outro recurso antigo do MS Word que permite adicionar texto dinâmico e um pouco de programação ao seu documento. O exemplo mais óbvio é o campo de número de página, que pode ser inserido no rodapé usando o valor {PAGE *MERGEFORMAT}. Isso permite que os números das páginas sejam gerados automaticamente.
Dica: Você pode encontrar o item de menu Campo em Inserir.
Lembro que quando descobri esse recurso no Word, fiquei surpreso. E até o patch desativá-lo, o Word ainda suportava a opção de campos DDE. A ideia era que o DDE permitisse que o Word se comunicasse diretamente com a aplicação, para que pudesse então passar a saída do programa para um documento. Era uma tecnologia muito jovem na época - suporte para troca de dados com aplicações externas. Posteriormente, foi desenvolvido na tecnologia COM, que também veremos a seguir.
Eventualmente, os hackers perceberam que esse aplicativo DDE poderia ser um shell de comando, que obviamente iniciava o PowerShell, e a partir daí os hackers poderiam fazer o que quisessem.
A captura de tela abaixo mostra como usei essa técnica furtiva: um pequeno script do PowerShell (doravante denominado PS) do campo DDE carrega outro script PS, que inicia a segunda fase do ataque.
Obrigado ao Windows pelo aviso pop-up de que o campo DDEAUTO integrado está tentando secretamente iniciar o shell
O método preferido para explorar a vulnerabilidade é usar uma variante com o campo DDEAUTO, que executa automaticamente o script ao abrir Documento do Word.
Vamos pensar no que podemos fazer sobre isso.
Como um hacker novato, você pode, por exemplo, enviar um e-mail de phishing, fingindo ser da Receita Federal, e incorporar o campo DDEAUTO com o script PS para o primeiro estágio (um conta-gotas, essencialmente). E você nem precisa fazer nenhuma codificação real de macros, etc., como fiz em
A vítima abre seu documento, o script incorporado é ativado e o hacker acaba dentro do computador. No meu caso, o script PS remoto apenas imprime uma mensagem, mas poderia facilmente iniciar o cliente PS Empire, que fornecerá acesso remoto ao shell.
E antes que a vítima tenha tempo de dizer qualquer coisa, os hackers acabarão por ser os adolescentes mais ricos da aldeia.
O shell foi lançado sem a menor codificação. Até uma criança pode fazer isso!
DDE e campos
Posteriormente, a Microsoft desativou o DDE no Word, mas não antes de a empresa declarar que o recurso foi simplesmente mal utilizado. A sua relutância em mudar alguma coisa é compreensível. Na minha experiência, eu mesmo vi um exemplo em que a atualização de campos ao abrir um documento estava habilitada, mas as macros do Word foram desabilitadas pela TI (mas mostrando uma notificação). A propósito, você pode encontrar as configurações correspondentes na seção de configurações do Word.
Porém, mesmo que a atualização de campos esteja habilitada, o Microsoft Word notifica adicionalmente o usuário quando um campo solicita acesso aos dados excluídos, como é o caso do DDE acima. A Microsoft está realmente avisando você.
Mas muito provavelmente, os usuários ainda irão ignorar este aviso e ativar a atualização dos campos no Word. Esta é uma das raras oportunidades de agradecer à Microsoft por desabilitar o perigoso recurso DDE.
Quão difícil é encontrar um sistema Windows sem patch hoje?
Para este teste, usei AWS Workspaces para acessar um desktop virtual. Dessa forma, obtive uma máquina virtual do MS Office sem patch que me permitiu inserir o campo DDEAUTO. Não tenho dúvidas que de forma semelhante você poderá encontrar outras empresas que ainda não instalaram os patches de segurança necessários.
Mistério dos objetos
Mesmo que você tenha instalado esse patch, existem outras falhas de segurança no MS Office que permitem que os hackers façam algo muito semelhante ao que fizemos com o Word. No próximo cenário aprenderemos use o Excel como isca para um ataque de phishing sem escrever nenhum código.
Para entender esse cenário, vamos lembrar do Modelo de Objeto Componente da Microsoft, ou abreviadamente COM (Modelo de Objeto Componente).
COM existe desde a década de 1990 e é definido como um "modelo de componente orientado a objetos e neutro em linguagem" baseado em chamadas de procedimento remoto RPC. Para uma compreensão geral da terminologia COM, leia no StackOverflow.
Basicamente, você pode pensar em um aplicativo COM como um executável do Excel ou Word, ou algum outro arquivo binário em execução.
Acontece que um aplicativo COM também pode ser executado cenário — JavaScript ou VBScript. Tecnicamente é chamado scriptlet. Você pode ter visto a extensão .sct para arquivos no Windows - esta é a extensão oficial para scriptlets. Essencialmente, eles são códigos de script agrupados em um wrapper XML:
<?XML version="1.0"?>
<scriptlet>
<registration
description="test"
progid="test"
version="1.00"
classid="{BBBB4444-0000-0000-0000-0000FAADACDC}"
remotable="true">
</registration>
<script language="JScript">
<![CDATA[
var r = new ActiveXObject("WScript.Shell").Run("cmd /k powershell -c Write-Host You have been scripted!");
]]>
</script>
</scriptlet>
Hackers e pentesters descobriram que existem utilitários e aplicativos separados no Windows que aceitam objetos COM e, consequentemente, scriptlets também.
Posso passar um scriptlet para um utilitário do Windows escrito em VBS conhecido como pubprn. Ele está localizado nas profundezas de C:Windowssystem32Printing_Admin_Scripts. A propósito, existem outros utilitários do Windows que aceitam objetos como parâmetros. Vejamos este exemplo primeiro.
É bastante natural que o shell possa ser iniciado até mesmo a partir de um script de impressão. Vá Microsoft!
Como teste, criei um scriptlet remoto simples que inicia um shell e imprime uma mensagem engraçada: “Você acabou de receber um script!” Essencialmente, pubprn instancia um objeto scriptlet, permitindo que o código VBScript execute um wrapper. Este método oferece uma clara vantagem para hackers que desejam entrar e se esconder em seu sistema.
No próximo post, explicarei como scriptlets COM podem ser explorados por hackers usando planilhas do Excel.
Para sua lição de casa, dê uma olhada do Derbycon 2016, que explica exatamente como os hackers usaram scriptlets. E também leia sobre scriptlets e algum tipo de apelido.
Fonte: habr.com