Redes Sociales

viernes, 12 de junio de 2015

Miles de servidores web en dominios .es desactualizados

Hoy me han publicado en Security Art Work una entrada que había preparado para este blog. Publico la versión original, que es casi la misma que se publica en SAW. Los valores pueden ser diferentes debido a que para SAW refiné las busquedas mucho más para no pillarme los dedos.


Siguiendo con la serie de entradas (esta, esta o esta) sobre los dominios ".es", el siguiente paso consistió en obtener toda la información posible de:

  • Servidores Web
  • CMS instalados
  • Tecnologia subyacente (ASP.NET, PHP, etc)

Para ello me propuse lanzar el script whatweb contra todos los dominios ".es" de manera que se almacenara en una base de datos MySQL los resultados. El proceso tardó casi 3 semanas en realizarse (estamos hablando de 1.7 millones de dominios .es) y la verdad es que los resultados fueron impresionantes.

Whatweb dispone de una opción que permite introducir los datos directamente en una base de datos MySQL, pero la estructura de la base de datos que crea no es especialmente util. Por ejemplo, si un dominio .es redirige hacia otro, los datos los obtiene del segundo y en ningun momento almacena el dominio .es original. Los dominios a los que redirige, whatweb los llamaba "targets". Hubo que realizar una serie de procesos para asociar los "targets" a su dominio correspondiente.

Como decía, se escanearon 1.7 millones de dominios ".es", pero solo se consiguió obtener información de 1.291.713 "targets". El resto o bien no respondieron a las peticiones o bien, dieron un timeout o bien no respondieron lo que se esperaba. Y solo 914.903 de esos targets se pudieron asociar a un dominio ".es", el resto hasta 1.291.713 son casos en que varios dominio ".es" redirige a un mismo "target" o donde las URLs no son facilmente asociables a dominios ".es" (distintos nombres de dominio). Usaremos como base los 1.291.713 "targets" para medir la información obtenida.

HTTP Servers

Los datos obtenidos por tanto se basaran en estos 914.903 dominios ".es" de los que tengo datos verificables. En cuanto a los servidores web, se encontraron (sobre 1.414.996):

  • 1.017.744 servidores Apache
  • 155.080 servidores IIS
  • 132.881 servidores NGINX
  • Big IP : 7785 servidores
  • LiteSpeed: 6381 servidores
  • OpenGSE (De Google): 6327
  • Tomahawk: 6181
  • Zeus Web Server: 5013
  • GHS (De Google Hosting Services): 3489
  • LightHttpd: 3402

Distribución de servidores HTTP detectados

Si contamos el millon de servidores apache que respondieron, la gran mayoria no ofrecieron informacion sobre su versión. 796962 unicamente contestaron "Apache", pero 221000 nos dieron algun tipo de información:

  • 174817 de la rama Apache 2.2
  • 14358 de la rama Apache 2.4
  • 6789 de la rama Apache 2.1
  • 2757 de la rama Apache 1.3
  • 7097 dan otra informacion

Apache

Por versiones y sistemas operativos las más instaladas son:

  • 27875 Apache 2.2.14 sobre Ubuntu
  • 22277 Apache 2.2.29 sobre UNIX
  • 14806 Apache 2.2.3 sobre CentOS
  • 11515 Apache 2.2.22 sobre Debian
  • 11267 Apache 2.2.16 sobre Debian

Y si ordenamos unicamente por las versiones de Apache (Entre paréntesis la fecha de lanzamiento):

  • Apache 2.2.29 (03/09/2014): 38567
  • Apache 2.2.14 (05/10/2009): 28597
  • Apache 2.2.22 (31/01/2012): 28052
  • Apache 2.2.3 (): 18052
  • Apache 2.2.16 (): 13905
  • Apache 2.2.15 (): 12056

Si calculamos aquellas versiones que tienen más de 1 año de antiguedad (desde el momento de obtencion de los datos en Abril de 2015), que son las versiones anteriores a la 2.2.27 (18/03/2014) y a la 2.4.9 (17/03/2014):

  • Apaches con mas de un año de antigüedad: 167988
  • Apaches con menos de un año de antigüedad: 52462

IIS

Si nos fijamos en las versiones de IIS:

  • IIS/6.0 : 77678
  • IIS/7.5 : 48666
  • IIS/7.0: 11561
  • IIS/8.0 (2012): 10263
  • IIS/8.5 (2013): 5830
  • IIS/4.0: 257
  • IIS/5.0: 714
  • IIS/5.1: 22
  • Otros: 137

Las versiones anteriores a IIS/7.5 se pueden considerar inseguras, por lo que tendriamos 64759 IIS seguros y 90210 IIS inseguros.

Los servidores nginx no aportan informacion referente a sus versiones por lo que no podemos decir nada sobre su antiguedad.



viernes, 22 de mayo de 2015

Unos 100.000 dominios .es permiten la transferencia de zonas

Hoy me publicaron en Security Art Work un articulo que les habia preparado hace ya unos cuantos dias sobre AXFR. Lo hay tenido que recortar porque por una parte era muy largo y por otra mencionaba algunas empresas de Hosting que no estaban haciendo bien su trabajo.

A continuación dejo publicada la versión original del post, sin censuras.


El pasado 13 de Abril el US-CERT publicaba una alerta informando que "Las peticiones AXFR podrían filtrar información referente a los servidores de dominio". La comunidad cuando menos se rasco la cabeza pensando en qué estaba pensando el US-CERT. De hecho, este comportamiento fue reportado ya en 1997 por el NIST.

Las peticiones AXFR a servidores de nombres permiten replicar bases de datos DNS entre distintos servidores DNS. Las entidades por lo general tienen al menos dos servidores DNS (un primario y un secundario) que les permiten seguir disponiendo de servicio de nombres en caso de que el primario caiga. Por esta razón es importante que todos los servidores de nombres de una organización esten sincronizados. Esta sincronización se consigue mediante las peticiones XFR. Existen dos tipos de peticiones XFR, la incremental (IXFR) y la completa (AXFR), que envía al secundario toda la información de DNS local (lo que se conoce como la zona) que tiene el servidor primario. A este proceso se le conoce como "Transferencia de Zona".

Recordemos un poco todo el proceso. Una transferencia de zona se inicia cuando:

  • El servidor primario detecta que se actualizado su información y envía un paquete NOTIFY al servidor secundario.
  • Ha transcurrido el tiempo marcado como tiempo de actualización (que permite a ambos servidores estar sincronizados). Este tiempo esta especificado en el campo RDATA del registro SOA de la zona.

En ambos casos el servidor secundario le envía una petición AXFR al servidor primario. El problema es que esta petición no es autenticada por lo que cualquiera iniciar el proceso de transferencia de zona.

Un ejemplo

Se pueden realizar peticiones AXFR únicamente usando el comando dig de linux, primero consultando cual es el servidor de nombres (NS) del dominio:

root@kali:~/# dig ns XXXXX-valencia.es

...lo que nos interesa son los registros NS devueltos en la seccion Answer.

El siguiente paso consiste en solicitar la transferencia de zona (AXFR) al servidor de nombres que nos ha devuelto la consulta:

root@kali:~/# dig @ns2.XXXXXquer.net. XXXXX-valencia.es AXFR

Como vemos, gracias a este procedimiento nos enteramos que este dominio tiene un servidor FTP, un servidor de correo entrante (POP) y saliente (SMTP), un servidor de correo Web, y que protege sus correos con un registro SPF, todo ello en la misma máquina, con IP terminada en 209.50.

La transferencia de zona es una técnica muy usada en procedimientos de pentesting en la fase de reconocimiento y adquisición de información de la empresa atacada. Como vemos, no ha sido necesario ningún tipo de autenticación para obtener esta información.

Por supuesto el administrador del servidor de nombres primario puede evitar que cualquiera pueda consultar su registro añadiendo una simple linea en el fichero de configuración del servidor DNS en el que le indique cual es la IP del servidor secundario, quienes serán los unicos que puedan realizar peticiones AXFR:

Zone “XXXXX-valencia.es” {
         type master;
         file “/etc/bind/db.XXXXX-valencia.es”;
         allow-transfer { IP_SERVIDOR_SECUNDARIO; };
};

Realmente no se trata de una vulnerabilidad del servidor de nombres, sino de un fallo de configuración por parte de los administradores del dominio. De hecho no es que el servidor de nombres en sí esté mal configurado, si no que la configuracion para una zona (un dominio) en concreto es incorrecta.

Aunque se supone que la configuración debería ser igual (correcta o incorrecta) para todos los dominios al que da servicio un mismo servidor de nombres, lo cierto es que en nuestro experimento hemos encontrado casos en que no es asi y cada dominio estaría configurado de una forma.

Casi un 7% de los dominios .es afectados

El pasado 29 de Marzo publicaban en el blog de internetwache.org un estudio sobre el millón de dominios más visitados según Alexa que indicaba que el 7,24% de esos dominios usaban servidores de nombres mal configurados.

Se nos ocurrió hacer el mismo experimento pero sobre los 1.7 millones de dominios ".es" que Red.es tiene registrados. Para ello usmos el mismo script python que se utilizaban en su experimento ligeramente modificado para poder introducir los datos devueltos en una base de datos MySQL.

Es necesario indicar algunas cosas para que se entiendan los resultados obtenidos:

  1. Se ha tomado como base todos los dominios REGISTRADOS en Red.es y que se pueden obtener haciendo una petición a Red.es (En el momento en que hicimos la solicitud eran 1.762.459 dominios). Sin embargo no todos estos dominios están activos. Aproximadamente 1 de cada 12 dominios registrados no están activos o devuelven algún error (por ejemplo NXDOMAIN – Non existent domain) al consultar información sobre ellos. Esto hace que debamos eliminar un total de 147.063 dominios consultados, que lógicamente no van a permitir transferencia de zonas ya que ni siquiera responden.
  2. Otros 168.905 dominios devuelven un timeout a la hora de solicitar el servidor de nombres (Se ha establecido un timeout de 10 segundos). En estos casos puede ocurrir que sean dominios inactivos o que su conectividad sea mala o estén temporalmente desconectados. Probamos a aumentar el tiempo de timeout y algunos de estos 168.000 dominios sí que respondía, pero calculamos que revisar estos 168.000 dominios nos llevaría más de un año de trabajo por lo que les hemos considerado como inactivos a todos los efectos.

Descontando los anteriores de los 1.762.459 dominios .es registrados, obtenemos 1.446.491 dominios que realmente han respondido a las consultas AXFR y que será el número de dominios que tomaremos como base, tal y como se ve en la siguiente tarta:

Sobre esos 1.44 millones de dominios los resultados han sido:

  • 109886 dominios (un 7.5% de los dominios) tienen sus servidores de nombres mal configurados. Como vemos el porcentaje es muy similar al del Alexa Top 1 Million
  • Estos 1.44 millones de dominios .es utilizan hasta 211286 servidores de nombres diferentes, de los cuales 9347 (un 4.4%) están mal configurados y dan servicio a esos 109886 dominios.
  • El dominio español tiene registrados de media 2.53 servidores de nombres y un servidor de nombres da servicio, de media, 6.84 dominios .es (y a mucho otros, seguro, que no sean ".es").
  • Sin embargo estos 7.880 servidores de nombres dan servicio a un total de 98.456 dominios (un 6.8% del total) cuya información puede ser obtenida (y utilizada) sin ningún problema. Como vemos el porcentaje es muy similar al del Alexa Top 1 Million (Un 7.2% en su caso).
  • Estos 7.880 servidores “mal configurados” dan servicio a otros 9.400 dominios (hasta 109.866) que han rechazado nuestras consultas AXFR. La explicación más plausible es que la zona de estos dominios está bien configurada aunque algunas zonas “hermanas” dentro del mismo servidor de nombres estén mal. Esta configuración heterogénea parece extraña pero no le encontramos otra explicación.
  • También nos encontramos casos en que los servidores de nombres primario y secundario están configurados de forma diferente. Por ejemplo casos en que el primario permite transferencia de zonas mientras que el secundario no, o viceversa. Como vemos en el siguiente ejemplo, en un mismo servidor de nombres, tenemos una zona mal configurada y que devuelve información de todos sus registros DNS y otra, abajo del todo, bien configurada.
  • Un dominio “.es” utiliza, de media, 2.53 servidores de nombres mientras que un servidor de nombres da servicio, de media, a 6.84 dominios .es (y probablemente a muchos otros que no sean ".es").
  • Un total de 30.088 dominios tienen servidores de nombres propios (con un nombre perteneciente a su mismo dominio). Esto significa un 2% del total de dominios y representan a empresas que tienen infraestructura propia no utilizando una empresa de hosting para el alojamiento.
  • España es un país de PYMEs las cuales lógicamente no tienen la capacidad de tener un equipo de informáticos que les administren sus servidores y que por tanto contratan a empresas de hosting el mantenimiento de su páginas y sus servidores. En este sentido, y a partir de los resultados de este estudio se puede concluir que más del 95% de los dominios ".es" están alojados en empresas de hosting de mayor o menor tamaño.

  • De los 98456 dominios afectados, se han extraído un total de 1.994.350 registros (a una media de 20 registros por dominio). Cabe mencionar que se extrajeron unos 190.000 registros MX (primarios o secundarios), pero que solo 108.000 de ellos disponían de registro SPF para evitar el spoofing de correo electrónico y sólo 21281 tenían registro DKIM para la firma digital.
  • Se encontraron asimismo 3915 servidores FTP diferentes, 3383 servidor SMTP, 2453 servidores webmail, 133 impresoras laser y hasta 2 equipos con Kali anunciados entre los registros DNS (Asombroso lo que se puede encontrar en ellos). También es verdad que lo que se anuncia en los registros DNS muchas veces no tiene nada que ver con lo que luego resulta ser.

En resumen, entre los registros DNS de un dominio te puedes encontrar cualquier cosa.


Empresas de hosting. Un servicio mejorable.

Este estudio tambien ha sido muy util para saber que empresas de hosting estan utilizando los dominios .es. Por lo general las empresas de hosting utilizan sus propios servidores de nombres y haciendo una simple búsqueda encontramos por ejemplo que 1and1 esta dando servicio a 335.280 dominios .es, Arsys (a través del dominio servidoresdns.net y de piensasolutions.com) sería la segunda empresa de hosting que da servicio de nombres a mas dominios con 155.528 y Dinahosting (a través de sus dominios gestiondecuenta.com y dinahosting.com) sería la tercera, con servicio a 57.879 dominios ".es".

1and1  - 335280
servidoresdns.net  - 109302
domaincontrol  - 47226
piensasolutions  - 46226
ovh.net  - 43715
rzone.de  - 39909
sedoparking  - 37869
dondominio  - 35814
dinahosting  - 32792
gestiondecuenta  - 25087
cdmon  - 29875
nominalia  - 21718
redcoruna  - 16247
canaldominios  - 11856
ono.com  - 6431

¿Y entre los que estan afectados?. De los 98456 dominios mal configurados, solo 1977 usan servidores de nombres propios. Esto quiere decir que la gran mayoría de dominios que permiten transferencia de zona, han pagado un hosting que no les está dando un buen servicio. Algunas de estas empresas de hosting son bien conocidas y en su mayoría son empresas de hosting españolas. Este es el listado de servidores de nombres más afectados:

dns-servicios  - 11077
cyberneticos.com  - 4663
redunda.com  - 4021
servicios-fusion.es  - 3282
zonadns.com  - 2933
123hjemmeside.com  - 1890
srv-hostalia.com  - 2508
hospedajeydominios.com  - 2472
virtualns.net  - 2330
dnssecundario.com  - 2721
srv-acens.com - 744

Llama la atencion que sea la empresa Acens, mediante sus dominios "dns-servicios.es", "dns-servicios.com" y "srv-acens.com" la que esté dejando más dominios .es afectados (Un total de 11821 dominios).

La segunda es cyberneticos.com, empresa gaditana de hosting que parece que tampoco esta haciendo bien los deberes.

La tercera es Redunda.com, pertenece a enom.com, que es la segunda empresa registradora de dominios a nivel mundial. Probablemente se traten de dominios de empresas extranjeras (americanas) afincadas en españa.

Y la cuarta son dominios que utilizan servidores de nombres de servicios-fusion.es, por lo que vemos es son dominios que van vinculados con un producto llamado MOVISTAR-TU WEB de Telefonica.


Resumen

Resumiremos todo lo anterior en tres píldoras muy concretas:

  • Se puede obtener información de los servicios ofrecidos por hasta el 6.8% de los dominios .es (unos 98400).
  • Muchos de estos dominios .es pertenece a PYMEs que contratan sus dominios con pequeñas empresas de informática que no les dan un servicio del todo seguro.
  • La gran mayoría de las empresas de hosting grandes dan un servicio correcto.Existen sin embargo unas 5-6 empresas españolas que dan soporte a miles de dominios .es manteniéndolos mal configurados.

martes, 31 de marzo de 2015

Unos 6600 dominios ".es" aún son vulnerables a heartbleed

Una vez creado el repositorio, poco a poco hay que ir añadiéndole información. Tengo en mente añadirle información de whois, aunque haya que hacerlo a través de la herramienta Java que ofrece Red.es y que sólo permite 10 consultas por minuto.

Pero antes quiero recabar información de los dominios .es que son vulnerables (Los dominios no, claro, los servidores que hay detrás). El primer paso ha sido recabar información de qué dominios (bueno, sus servidores) eran vulnerables a Freak, así como otra información interesante. Hoy mostraré los que son aún vulnerables a heartbleed.

Como recordaremos (aquí, aquí y aquí), heartbleed es una vulnerabilidad de la versión 1.0.1f de openssl, que se descubrió en Marzo de 2014 (hace justo un año, ahora) y cuya resolución consiste en simplemente actualizar la versión de openssl instalada en los servidores.

La vulnerabilidad es un desbordamiento de buffer en memoria de openssl y el atacante podría obtener información aleatoria almacenada en el mismo bloque de memoria donde se encuentra la vulnerabilidad. Además, cada vez que se lanza el ataque, el servidor devolverá información diferente, permitiendo a los atacantes, con el tiempo recabar información de todo tipo, desde contraseñas en claro, rutas del servidor o versiones de software instaladas.

Para añadir información sobre si los dominios .es (los servidores que hay detrás) estan afectados por heartbleed, he utilizado la herramienta sslscan, que ofrece información de todo tipo sobre la implementacion de openssl instalada en los servidores HTTPS (en el puerto 443 sólo, no he buscado en puertos 443 alternativos como el 444 o el 8443).

Lo que muestra normalmente sslscan, por ejemplo contra google.es es los siguiente:

Como se puede ver nos indica si la compresión y la renegociación estan habilitadas, si las versiones 1.0, 1.1 y 1.2 de TLS son vulnerables y los cifrados permitidos por el servidor. A mi en este caso solo me interesaba la parte de la vulnerabilidad de heartbleed.

El script utilizado ha sido el siguiente:

for i in `cat Full_ES_Domains_List.csv | cut -d'|' -f1 | sed 's/"//g'`
do 
      ./inserta_heartbleed.sh $i >> heartbleed & 
      if [ `ps -ef | grep sslscan | wc -l` -gt 100 ]
      then 
          sleep 10
      fi
done

Como vemos, tira del script inserta_heartbleed.sh que es el siguiente:

#!/bin/bash

VALOR=`/usr/bin/sslscan --no-ciphersuites --no-renegotiation --no-compression --no-preferred 
--no-check-certificate $1 2>/dev/null| /bin/grep heartbleed | /usr/bin/awk '{ if ($3 ~ "not") 
{ printf "%s", "0"} else { printf "%s", "1"} }'`

echo $1 ":" $VALOR

Vamos, script muy sencillitos que permiten lanzar hasta 100 sslscan simultáneos y que me permitirán recorrer los 1.7 millones de dominios .es en apenas 4 o 5 días.

El listado devuelto por estos scripts es el siguiente:

Como se puede ver, para cada dominio se muestran tres numeros, que corresponden a las versiones 1.0, 1.1 y 1.2 de TLS tal y como nos saca sslscan.



Resultados


En estos momentos, se han escaneado 1762459 dominios, es decir el total de los dominios .es. El script detectó "unicamente" 8228 dominios (servidores) vulnerables a heartbleed, lo que significa que un año después de su descubrimiento sólo el 0,46% de los dominios estarían en peligro de robo de información. La verdad es que es un muy buen resultado, máxime porque unos 1500 de estos 8228 dominios son dominios del estilo zxs.es, zxq.es, creados únicamente con objeto de de vender el propio dominio. Aún así unos 6650 dominios .es (los servidores que dan servicio) aún son vulneraables.

Como vengo repitiendo desde el principio del articulo, el problema no es de los dominios, sino de los servidores que hay detrás y en el tejido empresarial español, en el que más del 90% son PYMEs que no tienen un área IT, el alojamiento web se contrata a empresas especializadas. El siguiente psaso pues, fue descubrir qué empresas de alojamiento web (muchas de ellas extranjeras) no estan cumpliendo sus obligaciones y mantienen todavía los sitios web de sus clientes vulnerables a heartbleed. La búsqueda fue muy simple:

for i in `grep 111 heartbleed | cut -d':' -f1`; do echo -n $i": " ;echo -n `ping -c 1 -W 5 $i  
| grep from`; echo; done | cut -d':' -f 2 | cut -d' ' -f5 | sort 

Sólo se me ocurrio hacerlo usando ping, seguro que hay soluciones mejores. En apenas 5 minutos el resultado nos demostró que algunas empresas de hosting no estan haciendo bien su trabajo. Estas son las 10 más afectadas con dominios. Recordemos que los valores totales son 6650. Si por ejemplo onlinehome-server.info tiene 214 dominios afectados, ella sola un 11% del total de dominios afectados en España. Entre las 10 de la gráfica de abajo suman el 36% de los dominios .es. Vamos, que yo si tuviera que escoger un hosting no me tiraría por ninguna de estas.

Pero por supuesto, hay muchas otras empresas que ofrecen hosting con dominios afectados. En total podemos estar hablando de cerca de 70 empresas de hosting que en mayor o menor medida no estan haciendo correctamente su trabajo... Muchas, demasiadas.

miércoles, 25 de marzo de 2015

Primeros resultados del repositorio de información de dominios .es

A partir del simple repositorio de información de dominios .es que explique en mi anterior entrada, en apenas 4 días de tenerlo en funcionamiento ya podemos sacar las primeras conclusiones.

Como resumen, en apenas 4 días se obtuvo información de:

  • nmaps de 4930 dominios .es
  • 114369 puertos
  • resultados de whatweb de 139857 dominios .es
  • 1441056 datos diferentes de esos 139857 dominios


Algunos datos interesantes obtenidos


Puertos abiertos más comunes

Como era de esperar, los puertos 80,443, 25 y 21 son los puertos más comúnmente abiertos, pero curiosamente no por este orden:

Si no contamos el total de estos 10 puertos, en las casi 5000 máquinas escaneadas nos quedan 77439 puertos de todo tipo en estado "open". Y seguramente muchos de ellos con aplicaciones vulnerables detrás y abiertos a internet:



Que tecnología hay detrás?

Si nos centramos en la información proporcionada por whatweb sacamos cosas aún mas interesantes. Para empezar si miramos los servidores web más comunes aparecen sobre todo Apache y nginx, pero llama la atención la cantidad de IIS/6.0 aun en funcionamiento. ¿Estaran parcheados?:



Pero es que si tiramos un poco hacia arriba nos encontramos con un buen numero de Apaches 2.0.52 y 2.0.54, IIS/5.0 y Nginx 1.0:



A ver que vulnerabilidades podemos encontrar en un Apache 2.0.52... pues salen un total de 36 que tengan su propio CVE:



En cuanto a la tecnología subyacente, vemos que ASP es la primera, se entiende que en los servidores IIS:



Llama la atención los 3617 servidores (un 2,58% del total) que aun tienen la version 5.2.17 de PHP y que como podemos ver atesoran cada uno de ellos un total de 38 vulnerabilidades, algunas de ellas con su correspondiente exploit:



Hay mucha mas información. Estas son las cabeceras especiales que devuelve una peticion HTTP. Como vemos, muchos sitios tienen la cabecera x-frame-options para evitar episodios de click-fraud.

Pero llama la atencion la cantidad de webs que envían la cabecera HTTP x-adblock-key. ¿Y esto que es?. Es una cabecera que le dice a AdBlock Plus que los anuncios de su web son legítimos y los muestre. Y es que Adblock no deja de ser un negocio y aunque filtra muchos anuncios, si la web paga, sus anuncios se mostraran todos.



En fin, se puede sacar información de todo tipo, por ejemplo ésta es la versión de wordpress utilizada, vemos aún alguna versión 2.9 y 3.0 en uso:



Por supuesto, de cada uno de estas tecnologías vulnerables que encontramos podemos sacar su IP y probar un ataque. Si esto es lo que he encontrado yo con apenas 4 días de busqueda, ¿que es lo que tendran las organizaciones que se pasan todo el día rastreando internet?.

Otro día seguiré sacando estadisticas curiosas.

martes, 24 de marzo de 2015

Preparando un repositorio de información sobre dominios ".es"

Disponiendo como tengo estos dias de dos recursos importantes como son el tiempo y un listado completo de dominios .es y dado que no existe un repositorio whois mantenido por nic.es o red.es, decidí ponerme a recabar y almacenar información sobre los servicios y servidores de los dominios .es.

Mi idea inicial fue almacenar los puertos abiertos en cada dominio, pero rápidamente se me ocurrió ampliar esta información con toda la que nos ofrece el comando "whatweb", el cual además ofrece una opción por la cual la información la escribe en formato de sentencias SQL. Perfecto para un gran repositorio de información como el que me planteo crear.

El primer paso fue crear la base de datos. Inicialmente instalé y preparé una base de datos SQLite, hasta que me di cuenta que, al no permitir concurrencia de sentencias SQL, esta BD me penalizaba mucho mas que ayudarme. Por esta razón decidi migrar lo poco que había obtenido (hasta el momento solo los nombres de los 1.7 Millones de dominios .es) a MySQL.

A día de hoy (su segundo dia), la base de datos tiene 5 tablas:

  • Domains
  • Ports
  • plugins
  • scans
  • targets

Las dos primeras tablas fueron creadas por mi para almacenar los dominios .es y sus puertos (tanto abiertos, como filtrados, como cerrados). Las tres ultimas pertenecen a la salida que genera el script whatweb.

La table Domains. Su objetivo es almacenar los dominios .es, en ella se almacena un id, el nombre de dominio, la IP, si es vulnerable a FREAK y el CIF del dominio.

+---------+---------+------+-----+---------+-------+
| Field   | Type    | Null | Key | Default | Extra |
+---------+---------+------+-----+---------+-------+
| Id      | int(11) | YES  |     | NULL    |       |
| Name    | text    | YES  |     | NULL    |       |
| IP      | text    | YES  |     | NULL    |       |
| Company | text    | YES  |     | NULL    |       |
| FREAK   | text    | YES  |     | NULL    |       |
| CIF     | text    | YES  |     | NULL    |       |
+---------+---------+------+-----+---------+-----

La tabla Ports. Rellenada a partir de la información obtenida via nmap, se incluye un id del dominio (que se casa con la tabla Domains), el numero del puerto y si es tcp o udp (con el formato "465/tcp"), el estado (Open, Close, Filtered, etc) y el servicio que hay detrás. En estos momentos tiene 59000 Puertos documentados pertenecientes a 3015 dominios. Esta es la tabla que más lentamente se rellena y tengo que echarle una pensada.

+---------+---------+------+-----+---------+-------+
| Field   | Type    | Null | Key | Default | Extra |
+---------+---------+------+-----+---------+-------+
| Id      | int(11) | YES  |     | NULL    |       |
| Port    | text    | YES  |     | NULL    |       |
| Status  | text    | YES  |     | NULL    |       |
| Service | text    | YES  |     | NULL    |       |
+---------+---------+------+-----+---------+-----

La tabla plugins es una tabla estática que almacena un id y el nombre de un plugin. ¿Y que es un plugin?. Pues es un tipo de datos que devuelve whatweb, desde un servidor web hasta una IP.

La tabla scans es la que almacena el grueso de la información devuelta por whatweb, en concreto se almacena en el campo string, por lo que el resto de campos son bastante innecesarios.

+-----------+--------------+------+-----+---------+----------------+
| Field     | Type         | Null | Key | Default | Extra          |
+-----------+--------------+------+-----+---------+----------------+
| scan_id   | int(11)      | NO   | PRI | NULL    | auto_increment |
| plugin_id | int(11)      | NO   |     | NULL    |                |
| target_id | int(11)      | NO   |     | NULL    |                |
| version   | varchar(255) | YES  |     | NULL    |                |
| os        | varchar(255) | YES  |     | NULL    |                |
| string    | varchar(767) | YES  |     | NULL    |                |
| account   | varchar(767) | YES  |     | NULL    |                |
| model     | varchar(767) | YES  |     | NULL    |                |
| firmware  | varchar(767) | YES  |     | NULL    |                |
| module    | varchar(767) | YES  |     | NULL    |                |
| filepath  | varchar(767) | YES  |     | NULL    |                |
| certainty | varchar(10)  | YES  |     | NULL    |                |
+-----------+--------------+------+-----+---------+----------------+

La tabla targets almacena los nombres de dominios, un id y el codigo devuelto al conectarse via web (un 200, un 404, un 301...). La información almacenada aqui es bastante redundante ya que también la tengo en la tabla Domains, pero dado que es la que proporciona whatweb por defecto, la dejaré así y ya veré como solucionar el problema de la duplicidad.

Una vez creadas las tablas, hay que crear los scripts que recaban la información. Un poco de shell magic y...

for i in `cat datos_originales/Full_data | cut -d'|' -f1 | sed 's/"//g'`
do 
         nmap -T4 --host-timeout 660 $i 2>/dev/null | egrep "tcp|udp" |while read line; do 
                        PORT=`echo $line | awk '{ print $1 }'`
                        STATUS=`echo $line | awk '{ print $2 }'`
                        SERVICE=`echo $line | awk '{ print $3 }'`
                        python inserta-mysql.py $i $PORT $STATUS $SERVICE
         done &  
         if [ `ps -ef | grep nmap | wc -l` -gt 90 ]
         then 
              sleep 30
         fi
done &

Este script lanza hasta 90 nmaps simultaneamente y espera 11 minutos (660 segundos) a que acaben. Despues de varias pruebas consideré que era la mejor combinación. Si todo va bien un nmap deberia tardar unos 60 sg, pero con tantos lanzandose a la vez es normal que tarden mas bien entre los 7 y los 8 minutos.

Como vemos el script tira de inserta-mysql.py, programita en python que inserta los datos en la BD MySQL y que tiene este aspecto:

import csv
import sys
import MySQLdb

DB_HOST='localhost'
DB_USER=''
DB_PASS=''
DB_NAME='whois'

datos = [DB_HOST, DB_USER, DB_PASS, DB_NAME]
con = MySQLdb.connect(*datos)
cur = con.cursor()   
i=0

domain=sys.argv[1]
port=sys.argv[2]
status=sys.argv[3]
service=sys.argv[4]

cur.execute("select id from Domains where Name='"+domain+"'")
records = [int(record[0]) for record in cur.fetchall()]
id=records[0]

query="INSERT INTO Ports VALUES('"+str(id)+"','"+port+"','"+status+"','"+service+"')" 
cur.execute(query)

con.commit()

if con:
 cur.close()
        con.close()

Ahora ya solo queda lanzar los comandos y esperar:

root@kali:~/Downloads# ./inserta.sh

Por otra parte, no me quería centrar sólo en los puertos abiertos, quería obtener más información de los dominios españoles. Whatweb es un programita escrito en Ruby que obtiene información muy variada sobre un dominio. Por ejemplo:

  • La IP
  • El código de acceso (200, 301, 404, etc)
  • El servidor web instalado y su versión (Apache, IIS 7.5,...)
  • El CMS que tienen instalado (Drupal, Joomla!, etc)
  • Las librerias Javascript, PHP instaladas, etc.

Además tiene una opción estupenda que escribe en formato SQL la salida de la herramienta. Perfecto para pasásela a continuación a MySQL. Así que con la siguiente linea de comando:

for i in `cat datos_originales/Full_data | cut -d'|' -f1 | sed 's/"//g'` 
do 
    whatweb $i --log-sql=inserta.sql & 
    if [`ps -ef | grep whatweb | wc -l` -gt 50 ]; then sleep 20; fi
done

...lanzo hasta 50 whatweb simultáneos. Whatweb no consume tanto ancho de banda como nmap por lo que podía haber aumentado el numero de whatweb simultaneos, pero con los nmap funcionando a la vez ya era demasiado para mi pobre instalación casera...

El anterior script genera un fichero SQL que lógicamente hay que meter en MySQL. El comando es muy simple:

mysql -f whois < inserta.sql

Me hubiera gustado poder recopilar información de whois de los dominios españoles, pero por desgracia España todavía no tiene un servidor de Whois público, y el servicio de whois que ofrece Red.es se basa en Java y solo permite 10 consultas por minuto.

En la próxima entrada mostraré los resultados obtenidos en apenas 4 días lanzando estos scripts.

miércoles, 18 de marzo de 2015

Haciendo funcionar Tortazo en una Kali de 32 bits

Tortazo es un proyecto muy interesante de la gente de TheHackerWay para auditar los nodos de la red Tor.

Se puede descargar de https://github.com/Adastra-thw/Tortazo.

Su funcionamiento esta bien explicado en su manual, pero la parte de instalación se queda un poco coja.

En esta entrada voy a explicar los problemas que me encontré para hacerlo funcionar en mi sistema Linux.

Después de descargarlo desde github y leerme la documentación, indica que podemos tirar del ejecutable que se encuentra en Tortazo-master/bin, pero resulta que el ejecutable de linux solo es para arquitecturas de 64 bits:

root@kali:~/Tortazo-master/bin# ls
Tortazo11-linx86_64  Tortazo11-win32.exe

root@kali:~/Tortazo-master/bin# file *
Tortazo11-linx86_64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses
shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0xad2a63133513bdc57e327dc38fd08e78bc27c9b0, not 
stripped

root@kali:~/Tortazo-master/bin# ./Tortazo11-linx86_64 
bash: ./Tortazo11-linx86_64: no se puede ejecutar el fichero binario

Así pues toca tirar del código. Aparente con ejecutar "python Tortazo.py" debería funcionar, pero en la documentación dicen claramente que hay que instalar una serie de dependencias. Pero no indica exactamente los comandos. Para que no os peleeis con ellos como yo, son estos:

pip install stem
apt-get install python-nmap python-shodan
pip install fabric
pip install pysmb
pip install plumbum
pip install pyfiglet
pip install pygeoip
pip install Ipython
pip install scrapy

El tema de los 64 bits es un problema porque hay alguna funcionalidad que falla por esta razón. Por ejemplo el plugin de Crawler tira de una version de socat hardcodeada de 64 bits. La única forma de hacer funcionar el plugin Crawler en un sistema de 32 bits consiste o bien en modificar el código python o bien en machacar el binario socat de tortazo por el que viene en tu sistema:

cp /usr/bin/socat /plugins/utils/socat

martes, 17 de marzo de 2015

Unos 95000 dominios .es aún son vulnerables a FREAK

FREAK es una vulnerabilidad en la gestión del nivel del cifrado de conexion SSL/TLS que podría permitir a atacantes maliciosos la negociación de un cifrado débil en la comunicación de manera éste pudiera descifrar el tráfico y obtener las claves de cifrado de una forma relativamente simple, permitiendo a usuarios no autorizados acceder a la información que envíen y reciban estos servidores, llegando incluso a poder suplantarlos.

FREAK ya ha sido encontrada siendo utilizada desde el primer dia de su descubrimiento, tanto en servidores Linux, Windows como Mac.

Aunque todos los fabricantes ya se han puesto manos a la obra para ofrecer actualizaciones que solucionen esta vulnerabilidad, a día de hoy, casi 100000 dominios .es aún son vulnerables.

Se puede consultar si un servidor es vulnerable de diferentes formas, accediendo a páginas creadas especificamente para tal fin, como http://www.nagios.com/freak-vulnerability-tester o https://tools.keycdn.com/freak, o directamente desde nuestro Linux con el comando:

openssl s_client -cipher EXPORT -connect [DOMINIO]:443 < /dev/null 2>/dev/null | grep SSL-Session -c

Si este comando devuelve "1" es que el sistema podria ser vulnerable, a través de su puerto 443 (https).

Existen un total de 1763357 dominios .es registrados y activos (a fecha del pasado jueves 12 de Marzo), y este listado completo se puede solicitar a Red.es.

A lo largo de los ultimos días, he estado lanzando el anterior comando contra los puertos 443 de los 1763357 dominios .es registrados hasta la fecha. Los resultados han sido que aproximadamente el 5.4% de estos dominios aun son vulnerables.

Aunque la cifra puede parecer pequeña, esto significa que aproximadamente 95000 dominios son vulnerables (a través de las conexiones a su puerto 443, no se ha probado conectando a otros puertos típicos como el 8443 o similares).

Para realizar este estudio se utilizaron los siguientes tres shell scripts:

root@kali:~/tmp# cat full_check.sh 
#!/bin/bash

FILE=/tmp/Full_listing_es_domains

TOT=`wc -l $FILE | awk '{ print $1 }'`

k=0
j=0

while [ $k -lt $TOT ]
do 
    next=`echo "100000 * $j" | bc`
    filename="list_$k_$next"
    head -$next $FILE | tail -100000 > $filename; 
    k=`echo "$k + 100000" | bc`
    j=`echo "$j + 1" | bc`

    /tmp/check_100000.sh  $filename &
done

Este era el script principal, que divide fichero inicial en 18 partes de 100000 (o menos) dominios y lanza 18 procesos que procesarán cada uno 100000 dominios.

Este segundo script recorre los 100000 dominios que le tocan y lanza un openssl para cada dominio. No deja haya más de 500 openssl lanzado simultáneamente en memoria:

root@kali:~/tmp# cat check_100000.sh 
#/bin/bash

    for i in `cat $1 | cut -d'|' -f 1 | sed 's/"//g'`
    do 
         /tmp/check_server.sh $i $1_output.txt & 
         if [ `ps -ef | grep openssl | wc -l` -gt 500 ]
         then 
             sleep 10
         fi
    done 

El tercer script es el que lanza el openssl y solo comprueba la vulnerabilidad contra un dominio en concreto:

root@kali:~/tmp# cat check_server.sh 
#!/bin/bash

NOMBRE=`echo -n $1  ":"`
VALOR=`openssl s_client -cipher EXPORT -connect $1:443 < /dev/null 2>/dev/null | grep SSL-Session -c`

echo $1 ":" $VALOR >> $2

Por supuesto esto es infinitamente mejorable. En python por ejemplo podría hacerse mejor. Sin embargo, asi me ha funcionado y asi lo dejo por si alguien quiere repetir el proceso.



Resultados

Aunque el proceso aún no ha terminado, se han procesado hasta el momento 1.300.280 dominios '.es'. De los cuales se han detectado un total de 70026 vulnerables. Esto significa que en estos momentos son un 5.4% del total, lo que, extrapolando al numero total de 1.7 millones de dominios '.es' son mas de 95000 los que a día de hoy serían vulnerables.

Algunos de los dominios que actualmente son vulnerables:

Por desgracia España aun no dispone de un servidor whois público por lo que resulta difícil poder comunicar este problema a los encargados de cada dominio. Red.es proporciona un servicio whois utilizando un cliente Java (!!!) con un máximo de 10 solicitudes por minuto.

L atarea de comunicar a las distintas empresas la vulnerabilidad en sus servidores Web deberá ser realizada por un organismo púbico como INCIBE.


PS: El listado final se redujo hasta los 92862 dominios vulnerables. Lo que significa un 5,26% de todos los dominios. Como este estudio se produjo a los largo de varios dias, he vuelto a lanzar los scripts unicamente sobre los 92862 positivos para conocer la evolución en los últimos 3 días y 1164 dominios han resuelto el problema en sus servidores. Esta vez el script tardo apenas unas horas porque solo ha comprobado esos 92000 dominios. Sin embargo aún quedan al menos 91698 servidores vulnerables. Iré actualizando esta entrada para ver cómo evoluciona el parcheado ante esta vulnerabilidad.