Cuando leáis esto probablemente estaré ya en Hamburgo para asistir a la 33ª edición del Chaos Computer Congress, conocido como #33c3 y organizado por el Chaos Computer Club (CCC), la asociación de hackers (más bien es un conjunto de hackerspaces y asociaciones de hacking) más grande de Europa, y que lleva más de 30 años investigando y promoviendo la concienciación en temas relacionados con la tecnología y el hacking, incluyendo temas controvertidos como privacidad, vigilancia y seguridad de la información entre otros.

Este año, y gracias a la insistencia de algunos amigos, me he hecho un autorregalo de navidad y asistiré a este congreso que, al igual que todos los eventos organizados por el CCC, son únicos en el mundo, y no solo por la calidad o variedad de los temas tratados en las ponencias oficiales, sino por todo lo que se mueve a su alrededor. Voy a explicar por qué creo que esto es así.

Para empezar, se pone a disposición de los asistentes y de aquellos que no han podido asistir al evento varias redes de comunicación. En concreto, una red GSM (aunque este año no se pueden comprar tarjetas SIM nuevas) y una red DECT (muchos de los teléfonos inalámbricos que tenemos en casa son compatibles) desplegadas por todo el centro de convenciones donde tiene lugar el evento gracias a Eventphone, así como extensiones SIP tanto dentro del evento como fuera, para poder comunicarte con amigos o familiares que no hayan podido asistir al evento (esta última red externa se conoce como EPVPN). Además hay todo un directorio de servicios a los que puedes acceder a través de extensiones en esta red.
[Read more…]

Tras los post de mis compañeros Javier García y Alberto Sáez sobre la 6ª edición de Navaja Negra, me toca a mí terminar la crónica del evento.

A pesar de que parte de la organización ha cambiado respecto a años anteriores, la nueva organización ha seguido manteniendo el mismo espíritu que sus predecesores y ha apostado por rodear el congreso de muchos elementos que lo hacen hoy por hoy uno de los más completos que existen en España.

Además de tener almuerzo, comida y merienda incluidas en el precio de la entrada (incluyendo miguelitos!), este año el “ecosistema” Navaja Negra se ha nutrido de diferentes talleres, un Super CTF, y un espacio nocturno de colaboración y networking.
[Read more…]

Hoy os vamos a hablar de una charla que José González (@bitsniper) y yo (@jovimon) dimos en el FAQin Congress de Madrid celebrado los pasados días 5 y 6 de marzo.

En la charla hablamos de Telegram, la gran alternativa a Whatsapp como herramienta de mensajería, y que cada día que pasa se va haciendo un hueco más importante, ya que sus creadores van añadiendo más y más funcionalidades que la distinguen de la propia Whatsapp y del resto de aplicaciones del sector.

[Read more…]

Hoy vamos a continuar con la presentación de Suricata, aplicación de detección de intrusos de la que ya hemos contado entre otros sus características principales y las mejoras en detección y recolección de registros que proporciona respecto a Snort.

En el anterior artículo de la serie hablamos de la utilización de dichos registros para generar paneles de visualización personalizados, y hoy vamos a cerrarla viendo una forma de integrar todos los componentes de los que hemos hablado y facilitar todavía más la puesta en marcha de sondas IDS en cualquier lugar.

Esta integración nos la proporciona Stamus Networks, que ha creado una distribución de Linux llamada SELKS que integra tanto Suricata como la pila ELK, por lo que puesta en marcha de todo el sistema se reduce a instalar el sistema operativo, que ya viene preconfigurado para empezar a capturar tráfico en modo promiscuo en la interfaz de red de la máquina.

[Read more…]

Retomamos la serie sobre Suricata que iniciamos hace unos meses con dos entradas la presentación de sus principales características y la exposición de algunas de sus funcionalidades de detección de protocolos y extracción de registros adicionales.

En el final de la entrada anterior nos quedamos con un IDS que además de detectar nos ofrecía multitud de registros adicionales de muchos tipos diferentes.

Tanta cantidad de información puede desbordar a cualquier equipo de trabajo que intente procesarla, pero por suerte Suricata también proporciona una forma de unificar toda la información que puede generar para que nos sea más fácil de digerir. Esta forma unificada se llama Extensible Event Format (EVE) y utiliza el formato JSON para presentarnos toda la información disponible.

[Read more…]

Estaba hace unos días cambiando las contraseñas de acceso a varias aplicaciones y servicios que utilizo diariamente, cuando al introducir la clave en una de ellas me encuentro con el temido error: “Contraseña incorrecta”.

“Seguro que me ha bailado un dedo al escribir la contraseña” fue el primer pensamiento. Vuelvo a intentarlo. “Contraseña incorrecta” de nuevo. Me empieza a entrar el pánico. “¿Habrá dado error al cambiarla y no me he dado cuenta?” “¿Habré puesto la de otro servicio?”. Estas y otras preguntas me venían a la cabeza, pero todos los intentos manuales que hacía tenían el mismo resultado: “Contraseña incorrecta”.

[Read more…]

En esta segunda parte de la serie sobre Suricata (ver primera parte) vamos a continuar repasando las ventajas de Suricata, pero esta vez centrados en la información que podemos obtener de la aplicación.

Con Snort teníamos únicamente alertas, que podían provenir o bien de preprocesadores o bien de firmas que se cargaban a la aplicación. Suricata, si bien mantiene estas ideas, y ofrece total compatibilidad con las reglas existentes para Snort, ofrece muchísimo más.

Por una parte se ha mejorado el proceso de detección de protocolos, de forma que, para algunos de ellos (actualmente http, ssl, tls, smb, smb2, dcerpc, smtp, ftp, ssh y dns), ya no es necesario especificar los puertos en los que queremos buscarlos, sino que con añadir el protocolo correspondiente al principio de la firma se va a identificar el protocolo y procesar la regla, sea cual fuere el puerto en el que se ha detectado el tráfico.

[Read more…]

A finales de 2010 nuestro compañero Nelo hablaba, en tres magníficos artículos, acerca de cómo configurar nuestro IDS Snort para que fuera capaz de procesar gran cantidad de tráfico (partes 1, 2 y 3). En aquel momento Nelo utilizó cuatro instancias, a las que enviaba únicamente una parte del tráfico mediante filtros BPF.

En todo este tiempo los despliegues han ido actualizándose, y mejorando y aumentando sus funcionalidades. Esto se debe por una parte a que Snort ha incluido nuevas mejoras, como por ejemplo la posibilidad de extraer información adicional de los preprocesadores SMTP y HTTP (partes 1 y 2).

Por otra parte, también se han mostrado útiles nuevos drivers para tarjetas de red, como PF_RING, una herramienta excepcional que permite aumentar el número de “cerditos” en esta particular granja de forma fácil ya que, además de acelerar el acceso a la propia tarjeta de red para evitar pérdidas de datos, se encarga automáticamente de dividir el tráfico entre todas las instancias de Snort que se conectan a él evitando el uso de los incómodos filtros BPF que usamos inicialmente (en la documentación de Snort se puede encontrar un completo manual de instalación de Snort con PF_RING). Incluso es posible conectar Snort con nuevas herramientas de Big Data como la suite ELK (parte 1 y 2) para hacer algunos de esos cuadros de mando visuales que tan populares son actualmente.

Pero, como dice el dicho, no sólo de pan vive el hombre, o en nuestro caso no sólo de Snort vive el mundo de los IDS/IPS de código abierto. En estos últimos cuatro años hemos vivido la consolidación y expansión de Suricata, que ya por aquel entonces se postulaba como un duro competidor para Snort. Tal ha sido su expansión que a principios de marzo de este año la empresa matriz que está al cargo de su desarrollo (Emerging Threats) ha sido adquirida por Proofpoint Inc, una importante empresa americana dedicada a ofrecer servicios de seguridad.

En los últimos meses hemos estado probando Suricata, y precisamente de él, y de las mejoras que ofrece respecto a la rama actual (2.9.x) de Snort, quiero hablaros en esta serie de entradas.

A pesar de que el pasado mes de diciembre se anunció la existencia de la rama 3.0 de Snort, que supone una reescritura de gran parte del código de la aplicación y la introducción de bastantes mejoras sobre la rama actual, algunas de ellas presentes en Suricata y otras no, hemos decidido realizar la comparativa con la rama actual de Snort ya que la nueva rama 3.0 aún se encuentra en fase alfa y por tanto, al no ser un producto terminado, puede acarrear problemas y no se recomienda su uso en entornos en producción. Si de todas formas alguien se anima a empezar a probarlo, puede descargar el código fuente de su proyecto de GitHub.

El cambio más significativo en lo que a arquitectura se refiere, y uno de los principales a nivel global es el hecho de que, a diferencia de Snort, Suricata es multihilo. Esto quiere decir que una única instancia de Suricata va automáticamente a balancear la carga de trabajo entre todos los cores disponibles, mejorando el rendimiento de la aplicación y permitiendo alcanzar tasas de procesamiento de 10Gbit/s en servidores normales, sin necesidad de obtener hardware especial (un ejemplo aquí). Además, hay un control completo sobre qué hilos y de qué tipo (hay un tipo de hilo para cada una de las fases por las que pasa un paquete dentro de Suricata) se ejecutan sobre qué cores de nuestro equipo. También se permite elegir entre diferentes modos de ejecución, llamados runmodes en Suricata, y que permiten modificar a nivel global el comportamiento de los hilos y el flujo de paquetes a través de los mismos.

Otro punto importante es la integración con diferentes métodos y dispositivos de captura de tráfico. En Snort era necesario una extensión que había que compilar y enlazar por separado para hacer uso por ejemplo de PF_RING, pero Suricata trae por defecto soporte para este método de captura. En el ámbito de la integración, también cabe destacar la integración con CUDA, que permite descargar de trabajo a las CPU y llevar dicha carga a las potentes tarjetas gráficas existentes actualmente. Toda esta integración mejora también la instalación al reducir en gran medida el número de dependencias.

En siguientes entradas de esta serie nos centraremos en la información de toda clase que podemos obtener de Suricata, y cómo poder representar esta información de forma fácil.

Hace unas semanas se publicó un ‘leak’, otro más, con multitud de contraseñas aparentemente asociadas a un servicio web conocido. Ya nos estamos acostumbrando a este tipo de noticias, y esta vez se ha apuntado con el dedo a la todopoderosa Google como fuente de esta publicación, con nada menos que alrededor de 5 millones de usuarios comprometidos.

Desde Google indican que no se trata de un ataque dirigido ni un compromiso de ninguno de los servidores de la empresa, sino que apuntan a que se puede tratar de una recopilación elaborada con mucha paciencia, y que menos de un 2% de las combinaciones de usuario y contraseña podrían haber funcionado. A pesar de ello nunca está de más echar un pequeño vistazo a las credenciales publicadas y, además de comprobar si nosotros o amigos y familiares están comprometidos, poder realizar un pequeño análisis y comprobar el estado de la concienciación en materia de seguridad de las contraseñas.

Para la primera tarea nos ponemos a buscar por el documento de texto y nos quedamos tranquilos tras comprobar que ni nosotros ni ningún conocido aparecen en esta publicación. Si no has podido obtener este ‘leak’ puedes acceder al proyecto Have I been pwned? del investigador de seguridad Troy Hunt, que recopila cuentas de correo comprometidas en este y otros ‘leaks’ importantes, y comprobar tus cuentas de correo.

Para la segunda tarea, vamos a emplear una utilidad que realiza el análisis de forma automática. La utilidad se llama Pipal y ha sido creada por Robin Wood (@digininja) precisamente para esta tarea: analizar los listados de contraseñas obtenidos, en su caso tras realizar las auditorías de seguridad que Robin lleva a cabo durante su trabajo habitual. Como el propio Robin indica “Antes de continuar debo resaltar que lo único que hace esta aplicación es proporcionar las estadísticas e información necesaria para ayudarte a analizar las contraseñas. El verdadero trabajo lo debes realizar tú interpretando los resultados. Yo te doy los números, tú cuentas la historia”.

Veamos como funciona la aplicación y los resultados que nos puede mostrar. Pipal se puede descargar desde github, y es una aplicación en Ruby autocontenida que podemos ejecutar en cualquier instalación estándar de Ruby, sin ningún otro requisito adicional.

$ ./pipal/pipal.rb -?
pipal 3.1 Robin Wood (robin@digi.ninja) (http://digi.ninja)

Usage: pipal [OPTION] ... FILENAME
     --help, -h, -?: show help
     --top, -t X: show the top X results (default 10)
     --output, -o : output to file
     --gkey : to allow zip code lookups (optional)
     --list-checkers: Show the available checkers and which are enabled
     --verbose, -v: Verbose

     FILENAME: The file to count

El listado contiene direcciones de correo electrónico. Necesitamos convertir el fichero a UTF8 para que pueda ser procesado correctamente, así que ejecutamos las siguientes órdenes para dejarlo preparado:

cat google_5000000_passwords.txt | awk -F":" '{print $2}' > pass.txt

iconv -f 437 -t utf8 pass.txt > pass-utf8.txt

Tras esto, pasamos ya a ejecutar la aplicación con el fichero de contraseñas obtenido:

./pipal/pipal.rb pass-utf8.txt -o salida.txt -v

Empezamos a ver en la consola como la aplicación se pone a realizar su trabajo. Tras unos minutos (u horas, según el equipo utilizado), obtenemos los resultados, que pasamos a analizar.

En primer lugar obtenemos los resultados generales, donde podemos ver las contraseñas más utilizadas, y aquellas “base words” (palabras que forman parte de la contraseña) que aparecen con mayor frecuencia:

Basic Results

Total entries = 4926343
Total unique entries = 3120179

Top 10 passwords
123456 = 48003 (0.97%)
password = 11593 (0.24%)
123456789 = 11162 (0.23%)
12345 = 8119 (0.16%)
qwerty = 5925 (0.12%)
12345678 = 5253 (0.11%)
111111 = 3524 (0.07%)
abc123 = 3016 (0.06%)
123123 = 2990 (0.06%)
1234567 = 2915 (0.06%)

Top 10 base words
password = 17596 (0.36%)
qwerty = 11061 (0.22%)
love = 3424 (0.07%)
monkey = 3213 (0.07%)
dragon = 3043 (0.06%)
hello = 2804 (0.06%)
iloveyou = 2778 (0.06%)
abcd = 2264 (0.05%)
welcome = 2241 (0.05%)
july = 2225 (0.05%)

Aquí podemos ver cómo, a pesar de los múltiples esfuerzos de la comunidad en este aspecto, las contraseñas más utilizadas siguen siendo o siguen teniendo palabras o secuencias de caracteres que consideramos inseguras.

Los conjuntos de dígitos o las sucesiones de caracteres tal y como se encuentran en el teclado, así como palabras comunes, entre las que destaca la propia palabra “password” (contraseña en inglés) copan los primeros lugares.

A continuación aparecen dos listas donde se muestra la longitud de las contraseñas, ordenadas por número de caracteres y por frecuencia de aparición, respectivamente, junto con un pequeño gráfico en ASCII que muestra la distribución de las mismas:

Password length			Password length
(length ordered)		(count ordered)
1 = 853 (0.02%)			8 = 1424125 (28.91%)
2 = 1565 (0.03%)		6 = 926282 (18.8%)
3 = 12721 (0.26%)		10 = 682219 (13.85%)
4 = 45572 (0.93%)		9 = 681330 (13.83%)
5 = 143317 (2.91%)		7 = 663424 (13.47%)
6 = 926282 (18.8%)		11 = 151685 (3.08%)
7 = 663424 (13.47%)		5 = 143317 (2.91%)
8 = 1424125 (28.91%)	        12 = 93010 (1.89%)
9 = 681330 (13.83%)		4 = 45572 (0.93%)
10 = 682219 (13.85%)	        13 = 42293 (0.86%)
11 = 151685 (3.08%)		14 = 24787 (0.5%)
12 = 93010 (1.89%)		15 = 14812 (0.3%)
13 = 42293 (0.86%)		3 = 12721 (0.26%)
14 = 24787 (0.5%)		16 = 7277 (0.15%)
15 = 14812 (0.3%)		17 = 2548 (0.05%)
16 = 7277 (0.15%)		32 = 2512 (0.05%)
17 = 2548 (0.05%)		18 = 1780 (0.04%)
18 = 1780 (0.04%)		2 = 1565 (0.03%)
19 = 1079 (0.02%)		20 = 1169 (0.02%)
20 = 1169 (0.02%)		19 = 1079 (0.02%)
21 = 451 (0.01%)		1 = 853 (0.02%)
22 = 387 (0.01%)		21 = 451 (0.01%)
23 = 288 (0.01%)		22 = 387 (0.01%)
24 = 257 (0.01%)		23 = 288 (0.01%)
25 = 172 (0.0%)			24 = 257 (0.01%)
26 = 118 (0.0%)			25 = 172 (0.0%)
27 = 71 (0.0%)			26 = 118 (0.0%)
28 = 51 (0.0%)			27 = 71 (0.0%)
29 = 31 (0.0%)			28 = 51 (0.0%)
30 = 41 (0.0%)			30 = 41 (0.0%)
31 = 12 (0.0%)			40 = 33 (0.0%)
32 = 2512 (0.05%)		29 = 31 (0.0%)
33 = 6 (0.0%)			31 = 12 (0.0%)
34 = 7 (0.0%)			35 = 11 (0.0%)
35 = 11 (0.0%)			34 = 7 (0.0%)
36 = 4 (0.0%)			33 = 6 (0.0%)
37 = 6 (0.0%)			37 = 6 (0.0%)
38 = 3 (0.0%)			50 = 5 (0.0%)
39 = 1 (0.0%)			36 = 4 (0.0%)
40 = 33 (0.0%)			53 = 4 (0.0%)
41 = 3 (0.0%)			122 = 3 (0.0%)
42 = 2 (0.0%)			41 = 3 (0.0%)
44 = 2 (0.0%)			45 = 3 (0.0%)
45 = 3 (0.0%)			38 = 3 (0.0%)
50 = 5 (0.0%)			44 = 2 (0.0%)
53 = 4 (0.0%)			42 = 2 (0.0%)
54 = 2 (0.0%)			56 = 2 (0.0%)
56 = 2 (0.0%)			64 = 2 (0.0%)
64 = 2 (0.0%)			54 = 2 (0.0%)
65 = 1 (0.0%)			65 = 1 (0.0%)
67 = 1 (0.0%)			67 = 1 (0.0%)
85 = 1 (0.0%)			85 = 1 (0.0%)
91 = 1 (0.0%)			91 = 1 (0.0%)
122 = 3 (0.0%)			39 = 1 (0.0%)
136 = 1 (0.0%)			136 = 1 (0.0%)

    ||                                                                  
    ||                                                                  
    ||                                                                  
    ||                                                                  
    ||                                                                  
    ||                                                                  
    ||                                                                  
    ||                                                                  
    ||                                                                  
    ||                                                                  
    ||                                                                  
    ||                                                                  
   ||||                                                                 
   ||||                                                                 
   ||||                                                                 
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
000000000011111111112222222222333333333344444444445555555555666666666677
012345678901234567890123456789012345678901234567890123456789012345678901

Podemos ver como las contraseñas de 8 caracteres son las que más aparecen, y el rango entre 6 y 10 caracteres es en el que se encuentran la mayoría de las contraseñas.

Teniendo en cuenta un equipo potente que utilice la herramienta oclhashcat (del que ya hemos hablado anteriormente en este blog), que las contraseñas únicamente contienen minúsculas y caracteres alfanuméricos, y suponiendo que se obtienen las contraseñas en MD5 (lo que es bastante común), se podría recorrer todo el espacio de contraseñas de 10 caracteres en algo menos de un día, así que, aunque a priori 10 caracteres pueda parecer muy seguro, vemos que no es así.

También cabe destacar la aparición de más de 2500 contraseñas de longitud 32, cuando únicamente aparecen pocas decenas de casos de contraseñas con longitudes vecinas. Revisando las contraseñas vemos que parecen ser hashes MD5, lo que puede significar 2 cosas: o bien no han sido descifradas o bien alguien ha introducido la suma MD5 de algún fichero como contraseña (veo que no soy el único que lo ha hecho alguna vez).

A continuación, aparecen varias estadísticas interesantes relacionadas con la longitud de la contraseña y el conjunto de caracteres utilizado:

One to six characters = 1130310 (22.94%)
One to eight characters = 3217859 (65.32'%)
More than eight characters = 1708484 (34.68%)

Only lowercase alpha = 1972788 (40.05%)
Only uppercase alpha = 0 (0.0%)
Only alpha = 1972788 (40.05%)
Only numeric = 775445 (15.74%)

First capital last symbol = 0 (0.0%)
First capital last number = 0 (0.0%)

Vemos que más del 65% de las contraseñas son de 8 o menos caracteres, alrededor del 40% están formadas únicamente por letras en minúscula, y más de un 15% sólo contienen dígitos. Todas estas prácticas rebajan la seguridad de las contraseñas y deberíamos tratar de evitarlas.

También vemos que no aparecen contraseñas que contengan únicamente mayúsculas o que empiecen con mayúsculas, lo que nos puede hacer sospechar de que realmente no existe ninguna contraseña que utilice mayúsculas, como veremos más adelante.

Acto seguido se muestran estadísticas de las contraseñas con números en su parte final.

Single digit on the end = 396589 (8.05%)
Two digits on the end = 561345 (11.39%)
Three digits on the end = 307392 (6.24%)

Last number
0 = 225978 (4.59%)
1 = 446157 (9.06%)
2 = 249229 (5.06%)
3 = 322395 (6.54%)
4 = 199645 (4.05%)
5 = 198905 (4.04%)
6 = 236076 (4.79%)
7 = 204986 (4.16%)
8 = 190806 (3.87%)
9 = 215301 (4.37%)

 |                                                                      
 |                                                                      
 |                                                                      
 |                                                                      
 | |                                                                    
 | |                                                                    
 | |                                                                    
||||  |                                                                 
|||||||| |                                                              
||||||||||                                                              
||||||||||                                                              
||||||||||                                                              
||||||||||                                                              
||||||||||                                                              
||||||||||                                                              
||||||||||                                                              
0123456789

Last digit
1 = 446157 (9.06%)
3 = 322395 (6.54%)
2 = 249229 (5.06%)
6 = 236076 (4.79%)
0 = 225978 (4.59%)
9 = 215301 (4.37%)
7 = 204986 (4.16%)
4 = 199645 (4.05%)
5 = 198905 (4.04%)
8 = 190806 (3.87%)

Last 2 digits (Top 10)
23 = 139781 (2.84%)
56 = 71742 (1.46%)
12 = 61841 (1.26%)
11 = 59786 (1.21%)
00 = 50068 (1.02%)
01 = 49657 (1.01%)
10 = 41260 (0.84%)
21 = 40985 (0.83%)
34 = 37776 (0.77%)
89 = 37686 (0.76%)

Last 3 digits (Top 10)
123 = 113837 (2.31%)
456 = 60162 (1.22%)
234 = 27651 (0.56%)
345 = 18836 (0.38%)
789 = 16930 (0.34%)
000 = 16916 (0.34%)
007 = 14584 (0.3%)
321 = 13666 (0.28%)
111 = 13478 (0.27%)
010 = 11371 (0.23%)

Last 4 digits (Top 10)
3456 = 55734 (1.13%)
1234 = 25782 (0.52%)
2345 = 17379 (0.35%)
6789 = 13343 (0.27%)
2010 = 8404 (0.17%)
1111 = 7681 (0.16%)
2009 = 7672 (0.16%)
2008 = 6442 (0.13%)
5678 = 6438 (0.13%)
1987 = 6207 (0.13%)

Last 5 digits (Top 10)
23456 = 55364 (1.12%)
12345 = 17006 (0.35%)
56789 = 12977 (0.26%)
45678 = 6056 (0.12%)
11111 = 5821 (0.12%)
54321 = 4407 (0.09%)
34567 = 4166 (0.08%)
23123 = 4064 (0.08%)
00000 = 3499 (0.07%)
67890 = 3089 (0.06%)

Muchos usuarios simplemente añaden algunos dígitos a “su contraseña” si se les obliga a utilizar números. Aquí vemos como muchos usuarios añaden un sólo dígito (siendo el más común el 1), o 2 o más dígitos, ya sea repetidos o formando series. Mención especial al apartado de 4 dígitos, donde podemos ver como aparecen varios números que podríamos identificar con años (2010, 2009, 2008, 1987).

Finalmente, aparecen estadísticas sobre el conjunto de caracteres utilizado y cómo se ordenan los caracteres dentro de la contraseña:

Character sets
loweralphanum: 2096099 (42.55%)
loweralpha: 1972788 (40.05%)
numeric: 775444 (15.74%)
loweralphaspecialnum: 39336 (0.8%)
loweralphaspecial: 25376 (0.52%)
specialnum: 4200 (0.09%)
special: 582 (0.01%)

Character set ordering
allstring: 1972788 (40.05%)
stringdigit: 1544506 (31.35%)
alldigit: 775444 (15.74%)
othermask: 233532 (4.74%)
stringdigitstring: 174893 (3.55%)
digitstring: 144649 (2.94%)
digitstringdigit: 42337 (0.86%)
stringspecialdigit: 15959 (0.32%)
stringspecialstring: 13657 (0.28%)
stringspecial: 4875 (0.1%)
specialstring: 2083 (0.04%)
specialstringspecial: 873 (0.02%)
allspecial: 582 (0.01%)

La tabla de conjuntos de caracteres nos muestra que no hay ninguna letra mayúscula en ninguna de las contraseñas que hemos obtenido, algo que ya habíamos intuido anteriormente. La tabla de ordenación, por su parte, nos muestra que más del 70% de las contraseñas están formadas únicamente por una cadena de texto o una cadena con un número detrás. Si añadimos a esto las contraseñas formadas únicamente por números, estamos hablando de alrededor del 87% de las contraseñas encontradas.

Por si este análisis no os parece suficiente, Pipal tiene dos funcionalidades de análisis más: los Splitters y los Checkers. Ambos son pequeños módulos que otorgan más funcionalidad a la aplicación.

En el caso de los Splitters, éstos dividen cada una de las líneas del fichero de entrada en campos, de forma que si tenemos por ejemplo nombre de usuario y contraseña, podemos indicarlo a la aplicación y puede ser de utilidad en fases posteriores de análisis.

Los Checkers en cambio realizan comprobaciones adicionales sobre el conjunto de contraseñas sirviendo, por ejemplo, para identificar campos de fecha (días, meses, años), como los grupos de 4 dígitos que forman años que hemos visto anteriormente. También hay otros para comprobar colores, estaciones del año, codigos postales, nombres de usuario, etcétera.

Se pueden listar los checkers disponibles con el modificador --list-checkers, y se habilitan al estilo módulos de apache2, creando un enlace simbólico desde la carpeta checkers-available a la carpeta checkers-enabled.

El único problema de los checkers es que la distribución oficial no tiene ninguno localizado en español. Para solucionar este problema David Lladró (@davidlladro), amigo y antiguo compañero, ha creado una versión de Pipal en la que sí aparecen varios checkers localizados en español.

Con esto concluye el análisis de esta herramienta y el último “leak” de contraseñas publicado. Espero que os haya gustado y vuestros comentarios sobre esta estupenda herramienta.