18 agosto 2014

Cuando hace poco más de un mes publiqué el post sobre Detalles que se convierten en un ataque de ingeniería social comenté al final del mismo que el ejemplo que había realizado probablemente no funcionaría debido a que la mayoría de antivirus detectaban los payloads generados por SET. Curiosamente, unos días después me instalé una máquina virtual con Windows 8.1 y descubrí que podía ejecutar ese payload sin que Windows Defender lo bloqueara.

Según Microsoft, Windows Defender dejaba de ser simplemente un antimalware para convertirse en antivirus en Windows 8, dejando así de existir el producto Microsoft Security Essentials para Windows 8. Sin embargo, se ve que no está muy púlido ya que en Windows 7 con Microsoft Security Essentials este problema no ocurre, únicamente en Windows 8.1 (supongo que Windows 8 también) con Windows Defender.

Antes de entrar a detallar el proceso, el escenario era el siguiente:
  • Host OS: Debian Wheezy + backports.
  • Guest OSes: Windows 8.1, Kali.
  • Virtualización: VirtualBox.
  • Malware: Windows Shell Reverse TCP generada con SET.
  • Protección: built-in Windows 8.1 (Windows Defender, firewall, UAC).
  • Lugar vulnerable: carpeta compartida de VirtualBox.
Ahora sí, vamos al lío. Lo primero que hay que hacer es generar el payload utilizando SET, para ello se ejecuta setoolkit en Kali y se eligen las opciones 1 > 4 > 1 > 4, rellenando los datos que se vayan pidiendo como la IP y puerto del listener. Una vez creado el payload.exe, se coloca en la carpeta compartida de VirtualBox, carpeta que deberá estar montada tanto en Kali como en Windows 8.1. Ahora se accede a esta carpeta en la máquina virtual de Windows 8.1, y se observa como el malware sigue ahí. Se ejecuta, y voila! Windows Defender detecta que se ha encontrado malware y lo acaba eliminando, sin embargo, no impide su ejecución, por lo que se obtiene una shell en este equipo. NOTA: el único sitio vulnerable es la carpeta compartida. Si se mueve el ejecutable a cualquier otro sitio, si que es bloqueado correctamente.

A continuación un video PoC (si, ya sé que mi pronunciación es lo peor...):



Como comenté anteriormente, probé lo mismo en una máquina virtual con Windows 7 y MSE, pero aquí si que se bloqueaba la ejecución del malware. También probé a realizar lo mismo cambiando el Host OS por un Windows 8.1, escenario en el que también se bloquea la ejecución (tanto en el host, como en el guest W8.1). Por lo tanto, parece que para aprovecharse de este bug el escenario es muy limitado y posiblemente no exista una aplicación real para dicho fallo.

Desde que detecté el problema me puse en contacto con el Microsoft Security Response Center, explicándoles como reproducir la vulnerabilidad y enseñándoles el video. Tras un mes de investigación, finalmente han determinado que no se trata de una vulnerabilidad de seguridad ya que para su explotación debe existir cierta componente de ingeniería social que engañe al usuario, y eso viola la primera ley inmutable de seguridad. Aún así, el coordinador del caso me informa de que ha pasado el informe al equipo de Windows Defender para que consideren un fix para próximas versiones.

Artículo cortesía de Ayoze Fernández (@SecurityEffect)

6 comments :

britinx dijo...

Si bien la primer ley inmutable de seguridad tiene sentido, (y por eso es importantísimo que un usuario sea responsable con el uso de su pc), si empezamos a utilizarlo como excusa no tendría sentido que existan esas "suites de seguridad" para empezar...

Me explico, una persona normal puede equivocarse y ejecutar algo que no debe por confiado, o incluso entrar a una pagina "malvada" sin saber que esta le puede hacer mal, y *se supone* que la suite debe *intentar* protegerlo (estamos en la realidad, nada es perfecto).

Si mi empleador me pide que ejecute X por la red en mi pc personal por razón laboral Z y su único propósito es enchufarme un bicho? Con esa excusa que te dieron basicamente me cabe por confiado.

Javier Javichu dijo...

Hola felicidaes por el articulo, una preguntita:

cualquier aplicación Android es valida?, e probado co esta apk:
com.cleanmaster.mguard.apk

y obtengo el siguiente error:

=> Time to edit the code in com.cleanmaster.mguard-dir.
==>Press ENTER to continue.

assemble com.cleanmaster.mguard-dir -> com.cleanmaster.mguard-edited.jar
jar2dex com.cleanmaster.mguard-edited.jar -> classes.dex
call com.android.dx.command.Main.main[--dex, --no-strict, --output=C:\apks\apkvi
nos\classes.dex, C:\apks\apkvinos\com.cleanmaster.mguard-edited.jar]
Traceback (most recent call last):
File "modifynew1.py", line 116, in
APKmodify(sys.argv[1][:-4])
File "modifynew1.py", line 46, in APKmodify
zip_out = zipfile.ZipFile(apkFile+'-manifest.apk')
File "C:\Python27\lib\zipfile.py", line 699, in __init__
self.fp = open(file, modeDict[mode])
IOError: [Errno 2] No such file or directory: 'com.cleanmaster.mguard-manifest.a
pk'

Saludos

Miguel Ángel García dijo...

Hola Javier,

Puedes encontrarte con aplicaciones que ofrezcan más resistencia (tal y como los llama el equipo de apktool, los llamados magic apks), que pueden haber sido empaquetados utilizando versiones modificadas de las herramientas o cuyo APK puede haber sido alterado de modo que provoque errores al intentar pasarlo por determinadas funciones de apktool.

En tu caso y después de dedicarle un rato he visto que la salida de error del comando "apktbool b ..." indicaba lo siguiente:

libpng error: Not a PNG file
ERROR: Failure processing PNG image /home/nodoraiz/pruebas/com.cleanmaster.mguard-dir-apktool/res/drawable-hdpi/dimensional_logo.png

Para poder salvar este problema he hecho lo siguiente:
1. Ejecutar el script
2. Darle al enter en la fase de modificación del AndroidManifest.xml
3. Cuando me ha indicado que podía modificar el código, he ido al directorio que he puesto arriba y eliminado ese recurso (si lo intentas abrir verás que está corrupto) y he renombrado un copy-paste de otra imagen que estuviera OK para que exista un "dimensional_logo.png". He dado a ENTER
4. Me ha generado el APK modificado


Estaba un poco escondido el problema, pero al final y al menos en este caso si que se ha podido alterar el código ;) .


Un saludo!

javier González dijo...

Hola, tengo un pequeño problema, es lo siguiente; cuando realizo el paso de jasmin, funciona bien pero cuando voy a ver los paquetes que ha generado, solo me genera (buildingconfig,LoadStage,MainActivity y J) no me muestra ni payload....eso a que se debe..?
SaluDdos....

michael mariscal dijo...

file "modify.py", line 8
tempdir= tempfile.mkdtemp() IdentationError: expected an indented block!! alguien puede orientarme a corregir este error, por favor :)

kevin dijo...

hola me podrian ayudar , me pierdon en el paso de configurar el path para que el script las reconosca ?