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.

jueves, 6 de octubre de 2011

Ponente en SOURCE Conferences Barcelona 2011

Los próximos 16 y 17 de Noviembre estaré en las SOURCE Conferences Barcelona 2011, participando como ponente en el track en español.


La charla se titula "Canales Cubiertos en Redes Sociales", y básicamente tratará el tema de los canales cubiertos que se han empleado toda la vida a través de las cabeceras IP, TCP o en determinados campos de otros protocolos, pero dándole una vuelta más, y yéndonos a la capa de aplicación y más allá, hasta las aplicaciones web como son las redes sociales.

Como prueba de concepto, se ha desarrollado una herramienta llamada FaceCat (FaceBook NetCat), que realiza más o menos la misma funcionalidad que NetCat en cuanto a relay de puertos, pero empleando la red social FaceBook como pasarela por la cual la información será transmitida.

Este tipo de canales cubiertos van a poner cada vez más difícil a los administradores de red la protección perimetral de una compañía, ya que a nivel de red pueden llegar a resultar indistinguibles de tráfico normal de la aplicación, y dado que opera por encima de la capa de aplicación, va a atravesar sin problemas todo tipo de filtrado de puertos o proxies.

Podeis ver el resto de las charlas AQUÍ.
Me hubiera gustado romper el hielo de las charlas en inglés en estas conferencias, pero al final estoy en el track en español, a no ser que alguien se ponga enfermo, en cuyo caso me presentaré voluntario para cubrirle, por supuesto xD

Espero veros por Barcelona, el 16 de Noviembre, a eso de las 12:00.
FaceBook, no me leais, que no quiero que me fastidiéis la demo ;P

martes, 4 de octubre de 2011

Securizando Android para un uso corporativo (parte 3)

Contribución de Angel Alonso-Párrizas que continúa el post anterior.

Continuando con el post anterior en el que explicamos como deshabilitar la instalación de software, es necesario deshabilitar el software preinstalado para Android así como los ejecutables del sistema operativo que son innecesarios. 

Para deshabilitar los binarios es tan sencillo como borrarlos o bien revocar los permisos.  Esto ser hará con un script de manera automática que pondremos mas abajo.
Este mismo proceso se seguirá de manera análoga para deshabilitar el software preinstalado que no necesitamos.

Controles adiciones de seguridad

Para implementar una política de contraseñas seguras de manera centralizada, Google ha desarrollado una herramienta disponibles para empresas accesible desde el Google Apps. La herramienta va vinculada a una cuenta de Google Business que cuestan 40$ anuales.
Con esta herramienta se puede definir:
  • Forzar a usar contraseñas para acceder al dispositivo
  • Forzar a crear una contraseña segura
  • Forzar a cambiar la contraseña
  • Forzar a no rehusar las N contraseñas últimas
  • Bloquear el dispositivo después de N minutos
  • Umbral en el número de contraseñas erróneas hasta que el dispositivo se borra
  • Permitir el uso de cámara o no

Además de la política de contraseñas es posible también:
  • Localizar el dispositivo por GPS con Google Maps
  • Borrar el dispositivo remotamente
  • Bloquear el dispositivo remotamente

Otra herramienta útil para añadir seguridad al dispositivo es Autowipe. Las funcionalidades que usamos en este proyecto, que no son las únicas de ésta aplicación,  son:
  • Borrado del dispositivo mediante SMS con una contraseña
  • Borrado del dispositivo si la SIM es cambiada


La última herramienta que usamos es el conocido antivirus de AVG. Este antivirus tiene varias funcionalidades, pero las que no son de utilidad son:
  • Escaneo de aplicaciones en busca de malware
  • Navegación segura



Securizando el dispositivo 

El proceso de boot de Android es similar al de linux. Existen una serie de scripts de inicio que se ejecutan cuando el sistema se inicia. Sin embargo, el principal script de arranque init.rc  se encuentra en la ramdisk por lo que para modificarlo habría que modificar la imagen de arranque. Para evitar esto, la versión de la ROM, hace una llamada a un script llamado userinit.sh almacenado en /data/local. Así, tan solo necesitamos crear nuestro propio script, subirlo a ese directorio del Android y darle permisos de ejecución.

#!/system/bin/sh
# Customize some parameters and lockout the SO

mount -o rw,remount /system
# run dropbear / SSH
/system/xbin/dropbear -g -s
# Disable Bluetooth
chmod 000 /dev/ttyMSM0
chmod 000 /dev/ttyHS0
# stop market if running
killall com.android.vending
# hardening TCP/IP stack for IPV4
sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1 #ICMP broadcast
sysctl -w net.ipv4.conf.all.accept_redirects=0 # ICMP redirects ipv4
sysctl -w net.ipv6.conf.all.accept_redirects=0 #ICMP redirects ipv6
sysctl -w net.ipv4.conf.all.send_redirects=0 # ICMP redirects
sysctl -w net.ipv4.conf.all.accept_source_route=0 #source routing disable
sysctl -w net.ipv4.conf.all.forwarding=0 #Forwarding traffic
sysctl -w net.ipv4.conf.all.rp_filter=1
sysctl -w net.ipv4.conf.all.log_martians=1 #filter martians
sysctl -w net.ipv4.tcp_max_syn_backlog=1280 # TCP syn half-opened
sysctl -w net.ipv4.ip_forward=0
# Removing/ disabling unnecessary binaries. Some of them have access to Internet
rm -f /system/xbin/irsii
rm -f /system/xbin/nano
rm -f /system/xbin/nc
rm -f /system/xbin/netserver
rm -f /system/xbin/netperf
rm -f /system/xbin/opcontrol
chmod 740 /system/xbin/scp
chmod 740 /system/xbin/rsync
chmod 740 /system/xbin/sdptest
chmod 740 /system/xbin/ssh
chmod 740 /system/xbin/strace
chmod 000 /system/xbin/tcpdump
chmod 740 /system/xbin/vim
chmod 000 /system/bin/bluetoothd
chmod 750 /system/bin/iptables
chmod 750 /system/bin/ping
chmod -s /system/bin/ping
# Run Iptables
/data/local/iptables.sh
## This is the last step of the hardening
## This will be uncommented only when the system is configured
## This will lockout the system and will only give access through SSH
# Removing unnecessary software
# This must be uncomment at last step
# do a backup before
/data/local/removesoftware.sh
# disable the Packet Management binary
chmod -x /system/bin/pm
# Disable the adbd daemon
mount -o rw,remount -t rootfs rootfs /
chmod -x /sbin/adbd
mount -o ro,remount -t rootfs rootfs /
# disable the SD card
umount /mnt/sdcard/.android_secure
umount -l /mnt/sdcard
mount -o ro,remount /system

Este script llama a dos scritpts: iptables.sh y removesoftware.sh. (iptables.sh ya se comentó en el primer post)

#!/system/bin/sh
# Remove and disable unnecessary software
cd /system/app/
rm /system/app/AndroidTerm.apk
rm /system/app/Bluetooth.apk
rm /system/app/Development.apk
rm /system/app/FM.apk
rm /system/app/CarHomeGoogle.apk
rm /system/app/GoogleFeedback.apk
rm /system/app/GoogleQuickSearchBox.apk
rm /system/app/FileManager.apk
rm /system/app/HTMLViewer.apk
rm /system/app/MarketUpdater.apk
rm /system/app/Music.apk
rm /system/app/RomManager.apk
rm /system/app/SoundRecorder.apk
rm /system/app/Talk.apk
rm /system/app/Torch.apk
rm /system/app/Vending.apk
chmod 000 /data/data/com.android.bluetooth
chmod 000 /data/data/jackpal.androidterm2
chmod 000  /data/data/com.android.development
chmod 000 /data/data/com.android.fm
chmod 000 /data/data/com.android.htmlviewer
chmod 000  /data/data/com.android.music
chmod 000 /data/data/com.android.musicvis
chmod 000  /data/data/org.openintents.cmfilemanager
chmod 000 /data/data/com.android.soundrecorder
chmod 000 /data/data/com.google.android.carhome
chmod 000  /data/data/com.google.android.apps.books
chmod 000 /data/data/com.google.android.googlequicksearchbox
chmod 000 /data/data/com.android.vending
chmod 000 /data/data/com.android.vending.updater
chmod 000  /data/data/com.koushikdutta.rommanager

Una vez se ejecuten estos scripts el sistema esta securizado y solo sera accesible por SSH a través del túnel.
Lo que hay que hacer para configurar el dispositivo desde el principio es lo siguiente:

1.     Instalar Cyanogenmod
2.     Instalar Google Apps
3.     Instalar la aplicación Google App Device Policy
4.     Instalar el Antivirus
5.     Instalar Autowipe
6.      Configurar la cuenta de Google enterprise. Se introduce una contraseña segura en el dispositivo.
7.      Configurar el antivirus: frecuencia de autoscan, de actualización y  la navegación segura. 
9.     Configurar el  VPN: importar el certificado y configurar los parámetros del VPN
10.  Configurar SSH
11.  Copiar iptables.sh, removesoftware.sh y userinit.sh script a /data/local. Cambiar los permisos de estos ficheros a 700.
12.  Reiniciar el sistema.

Con esto finalizamos esta serie de artículos sobre la securización de android para entornos corporativos. No dudéis en dejar comentarios sobre cualquier duda que pueda haberos surgido.