Este artigo forma parte da serie Fileless Malware. Todas as demais partes da serie:
- The Adventures of the Elusive Malware, Part IV: DDE and Word Document Fields (estamos aquí)
Neste artigo, ía mergullarme nun escenario de ataque sen ficheiros en varias etapas aínda máis complexo con fixar o sistema. Pero entón atopeime cun ataque sen código incriblemente sinxelo, sen necesidade de macros de Word ou Excel. E isto demostra moito máis eficazmente a miña hipótese orixinal que subxace a esta serie de artigos: romper o perímetro exterior de calquera organización non é unha tarefa difícil en absoluto.
O primeiro ataque que describirei explota unha vulnerabilidade de Microsoft Word na que se basea desactualizado (DDE). Ela xa estaba . O segundo aproveita unha vulnerabilidade máis xeral en Microsoft COM e as capacidades de transferencia de obxectos.
Volta ao futuro con DDE
Alguén se lembra de DDE? Probablemente non moitos. Foi un dos primeiros protocolos de comunicación entre procesos que permitían a aplicacións e dispositivos transferir datos.
Eu estou un pouco familiarizado con el porque adoitaba comprobar e probar equipos de telecomunicacións. Nese momento, DDE permitía, por exemplo, aos operadores de centros de chamadas transferir o identificador de chamadas a unha aplicación CRM, que finalmente abría unha tarxeta de cliente. Para iso, tivo que conectar un cable RS-232 entre o seu teléfono e o seu ordenador. Eran os días!
Como se ve, Microsoft Word aínda está DDE.
O que fai que este ataque sexa efectivo sen código é que podes acceder ao protocolo DDE directamente desde campos automáticos nun documento de Word (sombreiro para SensePost para ao respecto).
Códigos de campo é outra característica antiga de MS Word que che permite engadir texto dinámico e un pouco de programación ao teu documento. O exemplo máis obvio é o campo do número de páxina, que se pode inserir no pé de páxina usando o valor {PAGE *MERGEFORMAT}. Isto permite que os números de páxina se xeren automaticamente.
Consello: podes atopar o elemento do menú Campo en Inserir.
Lembro que cando descubrín esta función por primeira vez en Word, quedei abraiado. E ata que o parche o desactivou, Word aínda admitía a opción de campos DDE. A idea era que DDE permitise a Word comunicarse directamente coa aplicación, para que despois puidese pasar a saída do programa a un documento. Era unha tecnoloxía moi nova daquela: soporte para o intercambio de datos con aplicacións externas. Máis tarde desenvolveuse en tecnoloxía COM, que tamén veremos a continuación.
Finalmente, os hackers decatáronse de que esta aplicación DDE podía ser un shell de comandos, que por suposto lanzou PowerShell, e a partir de aí os hackers podían facer o que quixesen.
A captura de pantalla que aparece a continuación mostra como usei esta técnica furtiva: un pequeno script de PowerShell (en adiante denominado PS) do campo DDE carga outro script PS, que inicia a segunda fase do ataque.
Grazas a Windows polo aviso emerxente de que o campo DDEAUTO integrado está tentando en segredo iniciar o shell
O método preferido para explotar a vulnerabilidade é utilizar unha variante co campo DDEAUTO, que executa automaticamente o script na apertura documento de word.
Pensemos no que podemos facer con isto.
Como hacker novato, pode, por exemplo, enviar un correo electrónico de phishing, finxindo que é do Servizo Federal de Impostos, e incorporar o campo DDEAUTO co script PS para a primeira etapa (un contagotas, esencialmente). E nin sequera necesitas facer ningunha codificación real de macros, etc., como fixen eu
A vítima abre o teu documento, actívase o script incrustado e o hacker acaba dentro do ordenador. No meu caso, o script remoto de PS só imprime unha mensaxe, pero podería lanzar facilmente o cliente PS Empire, que proporcionará acceso remoto ao shell.
E antes de que a vítima teña tempo para dicir nada, os hackers resultarán ser os adolescentes máis ricos da vila.
O shell lanzouse sen o máis mínimo de codificación. Incluso un neno pode facelo!
DDE e campos
Microsoft posteriormente desactivou DDE en Word, pero non antes de que a compañía declarase que a función simplemente se utilizou incorrectamente. A súa reticencia a cambiar nada é comprensible. Na miña experiencia, eu mesmo vin un exemplo onde se activaba a actualización de campos ao abrir un documento, pero as macros de Word foron desactivadas pola TI (pero mostrando unha notificación). Por certo, podes atopar a configuración correspondente na sección Configuración de Word.
Non obstante, aínda que a actualización de campos estea activada, Microsoft Word tamén notifica ao usuario cando un campo solicita acceso a datos eliminados, como é o caso de DDE anterior. Microsoft realmente está advirte.
Pero o máis probable é que os usuarios aínda ignoren esta advertencia e activen a actualización de campos en Word. Esta é unha das raras oportunidades para agradecer a Microsoft por desactivar a perigosa función DDE.
Que difícil é atopar hoxe un sistema Windows sen parches?
Para esta proba, usei AWS Workspaces para acceder a un escritorio virtual. Entón acabei cunha máquina virtual de MS Office sen parches que me permitiu inserir o campo DDEAUTO. Non teño dúbida de que dun xeito semellante podes atopar outras empresas que aínda non teñan instalados os parches de seguridade necesarios.
Misterio dos obxectos
Aínda que instalou este parche, hai outros buracos de seguridade en MS Office que permiten aos hackers facer algo moi semellante ao que fixemos con Word. No seguinte escenario aprenderemos use Excel como cebo para un ataque de phishing sen escribir ningún código.
Para comprender este escenario, lembremos o modelo de obxectos de compoñentes de Microsoft, ou para abreviar COM (Modelo de obxectos de compoñentes).
COM existe desde a década de 1990 e defínese como un "modelo de compoñentes orientado a obxectos, neutral na linguaxe" baseado nas chamadas de procedementos remotos RPC. Para unha comprensión xeral da terminoloxía COM, le en StackOverflow.
Basicamente, podes pensar nunha aplicación COM como un executable de Excel ou Word, ou algún outro ficheiro binario que se executa.
Resulta que unha aplicación COM tamén se pode executar escenario - JavaScript ou VBScript. Tecnicamente chámase guión. Quizais teña visto a extensión .sct para ficheiros en Windows - esta é a extensión oficial para scriptlets. Esencialmente, son código de script envolto nun envoltorio 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>
Os piratas informáticos e os pentesters descubriron que hai utilidades e aplicacións separadas en Windows que aceptan obxectos COM e, en consecuencia, tamén scriptlets.
Podo pasar un scriptlet a unha utilidade de Windows escrita en VBS coñecida como pubprn. Está situado nas profundidades de C:Windowssystem32Printing_Admin_Scripts. Por certo, hai outras utilidades de Windows que aceptan obxectos como parámetros. Vexamos primeiro este exemplo.
É bastante natural que o shell se poida lanzar mesmo desde un script impreso. Vaia Microsoft!
Como proba, creei un simple scriptlet remoto que inicia un shell e imprime unha mensaxe divertida: "Acabas de ser escrito!" Esencialmente, pubprn crea unha instancia dun obxecto de scriptlet, permitindo que o código VBScript execute un envoltorio. Este método ofrece unha clara vantaxe para os piratas informáticos que queren colarse e ocultarse no seu sistema.
Na seguinte publicación, explicarei como os piratas informáticos poden explotar os scriptlets COM mediante follas de cálculo de Excel.
Para os deberes, bótalle un ollo de Derbycon 2016, que explica exactamente como usaron os scriptlets os hackers. E tamén ler sobre scriptlets e algún tipo de apelido.
Fonte: www.habr.com