Share on Google+Share on FacebookTweet about this on Twitter

Nota: Todo fue realizado con el consentimiento expreso del dueño. Al principio fue una cuestión de investigación, los cambios no obstante solo fueron aplicados con el conocimiento del dueño.

 

Cansado de la vida en la ciudad que mejor forma que descansar debajo del sol y escuchar las olas del mar.

Honestamente, no es que no pueda vivir sin la tecnología, pero sí me divierto mucho con ella… y también aprendo. Así que entre el bañador, la toalla y protector solar he tenido que dejar espacio para el equipo informático. Una de las primeras cosas que aprendí fue a no dar nada por supuesto, así que ¿por qué no voy a pensar que algún vecino bueno y amigable iba a olvidarse a proteger a conciencia su conexión WIFI? Así que para no tener que cargar con más equipo del necesario simplemente tomé mi viejo router Linlsys wrt54GL (resucitado recientemente), el cual tuve la precaución de dejarlo preparado para destripar cualquier red WIFI que se pusiese a su alcance.

Dicho y hecho, después de dar un paseo agradable por la orilla y desempacar a montar mi pequeño puesto de trabajo fuera del ruido y el estrés de la ciudad. ¿Y cual es mi sorpresa? Un vecino amigable tiene su red WIFI expuesta (llamemos a su router/modem a partir de ahora “Destiny”). Bueno… robar está mal, así que después de comprobar la seguridad de esta no estaría de más contactar con el usuario y charlar animadamente con él. Pero lo primero es lo primero, tan solo tengo que conectarlo todo, configurar mi viejo router (llamado a partir de ahora como “Chaos”) y romper la pobre seguridad de Destiny, una clave WEP de 64bits. Una vez realizado esto (cosa fácil), tan solo es cuestión de configurar el router como cliente WIFI. Podría configurarlo como repetidor para aumentar la cobertura también de la red, pero siempre que no me es completamente necesario evito el uso de WIFI, así que opté mejor por el modo Cliente. En este modo Chaos actúa como si fuese un cliente más conectado a Destiny, a la par que actúa como router para mi propia red local. Es decir, la IP externa de Chaos será una IP asignada por defecto por el servidor DHCP de Destiny, mientras que la IP de mi red será aquella que yo desee dentro de mi propia red, y de tal modo que cualquier equipo conectado a mi red es completamente invisible de cara a Destiny, y la existencia de Chaos tan solo podría ser detectada accediendo a Destiny y comprobando los clientes conectados.

Una vez que todo se ha completado y la red comienza a funcionar el segundo paso es apuntalarlo todo. Esto implica primero a intentar configurar Destiny para mejorar en lo posible la cobertura WIFI (dado que esta será la que marque el rendimiento global de toda mi conexión a Internet y su estabilidad), mejorar la seguridad y de paso impedir que el vecino se arrepienta de permitirme el acceso a su red… al menos antes de que pueda pedirle permiso formalmente. Su red permite perfectamente pasar mis peticiones desde mi red local 192.168.3.0 a su red local 192.168.1.x lo que quiere decir que en teoría podría alcanzar desde mi equipo la configuración de Destiny, comenzando por la interfaz web y su puerta de enlace. ¿Cual es su puerta de enlace? Tan solo tengo que verlo en Chaos, o en el peor de os casos realizar un escaner de Pings y ver los hosts despiertos en la red:

C:\Users\Theliel>nmap -sn 192.168.1.0/24

Starting Nmap 5.30BETA1 ( http://nmap.org ) at 2010-06-12 18:03 Hora de verano romance
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
Nmap scan report for 192.168.1.64
Host is up (0.011s latency).
Nmap scan report for 192.168.1.65
Host is up (0.58s latency).
Nmap scan report for 192.168.1.254
Host is up (0.0043s latency).
Nmap done: 256 IP addresses (3 hosts up) scanned in 31.80 seconds

C:\Users\Theliel>

Vaya, no soy el único que está conectado, si mi cliente es el .64, el .65 debe de ser algún inquilino y Destiny debe de ser .254. Bueno, veamos que podemos obtener de Destiny sin intentar siquiera acudir al sentido común, así que vamos a ver si podemos ver sus puertos abiertos:

Nmap scan report for 192.168.1.254
Host is up (0.016s latency).
Not shown: 995 filtered ports
PORT     STATE  SERVICE
21/tcp   open   ftp
23/tcp   open   telnet
80/tcp   open   http
443/tcp  open   https
8080/tcp closed http-proxy

Vaya!! Destiny brilla por su escasa o nula seguridad, puertos http, telnet y ftp abiertos. ¿Y si solicito información sobre la versión de sus servicios y el OS de este?:

Starting Nmap 5.30BETA1 ( http://nmap.org ) at 2010-06-12 18:17 Hora de verano romance
Nmap scan report for 192.168.1.254
Host is up (0.013s latency).
Not shown: 996 filtered ports
PORT    STATE SERVICE  VERSION
21/tcp  open  ftp      Alcatel Speedtouch aDSL router ftpd
23/tcp  open  telnet   Alcatel/Thomson SpeedTouch DSL router admin interface
80/tcp  open  http     Alcatel/Thomson SpeedTouch aDSL http config 1.0
|_html-title: HTTP/1.0 401 Authorization Required
|_http-favicon: Thomson/Speedtouch Device
443/tcp open  ssl/http Alcatel/Thomson SpeedTouch aDSL http config 1.0
|_html-title: HTTP/1.0 401 Authorization Required
|_http-methods: No Allow or Public header in OPTIONS response (status code 400)
|_http-favicon: Thomson/Speedtouch Device
| http-auth: HTTP Service requires authentication
|   Auth type: Digest, realm = Thomson Gateway
|_  Auth type: Basic, realm = Thomson Gateway
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port

Esto continua dando sus frutos, ahora puedo afirmar casi con toda seguridad sin siquiera ponerle los dedos encima aun, que Destiny es un router/modem thomson SpeedTouch, lo que me dice que el vecino amigo posee una linea ADSL y que el usuario por defecto de este router será “Administrator” y la contraseña “admin”, y si el usuario no modificó siquiera la seguridad WIFI, no hay nada que me diga que cambiaron su configuración de fábrica. Y efectivamente, si intento alcanzar la interfaz web por medio de su puerta de enlace y con las credenciales por defectos, tengo acceso con nivel “administrador” a su router/modem para configurarlo a mi gusto.

A este punto, lo primero será crear un nuevo usuario en Destiny como administrador (es el mayor permiso que me permite especificar… por ahora) y poner una contraseña. También puedo eliminar la cuenta por defecto “Administrator”. Una vez que el acceso a Destiny está más o menos terminado (por ahora) hay que ver que seguridad tiene y sobre todo la configuración WIFI. No hay que estropear nada a sus dueños, tan solo podré modificar aquello que crea que no afectará a nadie. Curiosamente Destiny tiene un Firewall relativamente decente (deshabilitado por defecto o a conciencia, y yo no fui) y un sistema de detección de intrusos para filtrar escaners y otras técnicas, que está habilitado por defecto. Lo gracioso del tema es que registró mi escaner de puertos, pero no me impidió realizarlo, luego de nuevo podemos suspenderle en cuanto a seguridad se refiere. Por seguridad lo mejor es habilitar el Firewall a su nivel estandar (bloque de todas las conexiones entrantes), el IDS no podemos modificar su estado (por ahora).

Una vez realiza todo esto me tomo con una sección de gestión remota para un supuesto usuario denominado “tech”, aunque en los usuarios listados en el administrador de usuarios no aparece… interesante. Lo apunto por si las moscas. Los ajustes WIFI no permiten gran cosa, deshabilito los modos 802.11b, fuerzo el canal a 1 y eso es todo lo que me permite la interfaz web.

Visto lo visto, lo mejor será realizar un acceso por telnet y ver si puedo tener un control algo más extendido de Destiny, ya sé que tiene el puerto abierto, y si nada ha cambiado no tendría que ser complicado. Al menos ya he logrado obtener una calidad de señal de un 20% (nada despreciable, teniendo en cuenta que Destiny debe de estar en un bloque de pisos enfrente del mío a unos 30 metros terraza con terraza). El acceso por telnet es igualmente sencillo en este router, mis credenciales nuevas tienen completa validez y en principio tengo acceso completo al sistema. Lo primero que haré será realizar un volcado completo de toda la configuración de este, así podré hacerme una idea de las posibilidades que tengo. Por suerte este router nos deja jugar bastante con él:

 

Username : Theliel
Password :
————————————————————————

Thomson XXXXX
Copyright (c) 1999-2007, THOMSON
————————————————————————
{Theliel}=>config dump
[ sntpc.ini ]
config poll=60 pollpresync=5
config state=disabled

[ xdsl.ini ]
debug traceconfig level=0
config adslmultimode=adsl2plus detect-lop=enabled syslog=disabled
debug multimode config=default

…… -> Unas cienos de lineas más

Lo mejor de todo es que gracias a este volcado puedo analizar de forma simple todo lo que desee. Veamos que tenemos sobre WIFI:

[ wireless.ini ]
ifconfig interop=802.11g locale=Europe
ifconfig channel=1 ssid=xxxxxx any=enabled rts=2347 protection=never protmode=rtscts prottrigger=local&overlap shortslot=always frameburst=disabled dtim=3
macacl config control=unlock
secmode wep encryptionkey=XXXXXXXX
secmode wpa-psk presharedkey=XXXXXXX rekeysec=0 version=WPA
secmode config mode=WPA-PSK
wds config state=enabled

Lo interesante es lo que está en negrita, evidentemente. Parece ser que al forzar a usar tan solo el estandar 802.11g, protection se pone a never, con lo que ello explica a que no pueda setear el parámetro protmode a off. Dicho de forma simple, la protección CTS RTS/CTS es un sistema para que las redes B y G puedan coexistir juntas. En realidad CTS y RTS no son más que señales necesarias para el sistema CSMA/CA. Cuando todos los dispositivos funcionan en el mismo modo no hay problema dado que todos ellos están sincronizados (por así decirlo). En cambio si no lo están se produce lo que se llama estaciones ocultas. Es decir, pensar en dos clientes y un AP. Los dos clientes están dentro de la cobertura del AP, pero no entre ellos. Al no estar sincronizados ninguno sabe de la existencia del otro y podrían enviar de forma simultanea información al AP. Y esto es lo que evita la protección CTS y CTS/RTS.

shortslot es una mejora de rendimiento y está activada, pero por lo que se puede contemplar no sucede lo mismo con frameburst. Frameburst es una tecnología que permite ENVIAR (no recibir) datos en el tiempo de espera entre cada frame, es decir… a fin de cuenta enviar más datos en menos tiempo. Si una red G tiene una salida máxima de unso 3,1 MB más o menos, gracias a frame burst puede tener una salida máxima de a lo mejor 4-5MB, un buen incremento sin duda alguna. Pero esto solo ayuda en la subida, si queremos que se vea en la recepción de datos entre dos clientes WIFI, los dos deben de soportar dicha tecnologías, a sí uno puede enviar datos a esa velocidad y el otro contestarle con la misma tecnología. El lado negativo es que Frameburt tiene un impacto negativo cuando en la red existen clientes que no soportan dicha función, aunque a día de hoy casi todos los adaptadores G la soportan. Muchos routers y adaptadores permiten establecer esto en sus interfaces web o en las opciones del controlador. En mi caso es tan simple como:

{Theliel}=>wireless ifconfig config frameburst=true

Una vez que creo que todo está en orden queda tan solo saber que pasa con ese usuario tech, quiero asegurarme de que “Theliel” es el único usuario con acceso a Destiny. Bueno, a ver que encontramos en el volcado de la configuración:

[ mlpuser.ini ]
add name=tech password=_CYP_XXXXXXXXXXaa9a0f9d4dad275559194f role=TechnicalSupport hash2=XXXXXXXXXX7cd799135924d299fcc55d defremadmin=enabled
add name=Theliel password=_CYP_
AE2B1FCA515949E5D54FB22B8ED95575 role=Administrator hash2=XXXXXXXXXX… defuser=enabled

Con un poco de imaginación puedo suponer que la contraseña está en algún tipo de Hash para protegerla, dado que son 32 caracteres numéricos y alfabéticos, lo más normal es que sea un Hash MD5, y por su formato no parece que tenga ninguna Salt. Pero es fácil saberlo, mi contraseña la conozco “testing”, tan solo tengo que calcular algunos hash para ella y ver si alguno coincide, y efectivamente coincide. El hash MD5 de “testing” es AE2B1FCA515949E5D54FB22B8ED95575. El hash 2 debe de ser posiblemente un hash de protección, pero no es importante. el Hash de la cuenta tech lo tengo (lo he protegido por XXX por razones de seguridad). Si pudiese romper el hash y obtener la contraseña por él, tendré la contraseña del usuario tech. Esto es útil? Bueno… aun no lo sé, pero toda información siempre es buena. Así que me puse manos a la obra.

Como romper un Hash MD5? esto lo publiqué en uno de los artículos de seguridad. Pero lo mejor es siempre que sea posible pensarlo. Esta contraseña la pondrá el ISP, luego es posible que pueda encajar con algún diccionario. Primer intento? Un ataque por diccionario. He de decir que esto no me dio ningún exito. Bueno la segunda opción es por medio de tablas rainbow, es el método más efectivo, además sé perfectamente que no es un hash con salt. ¿Problema? Estoy en la playa, no tengo aquí los GBs y GBs de las tablas rainbow, ergo esto lo tenemos que descartar también. Tan solo queda un ataque de fuerza bruta. Cuando se realiza un ataque de fuerza bruta hay que ser realista, de nada sirve lanzar un ataque que puede durar años y años. Si puedo tener éxito me vale si es para dentro de como mucho una hora, más tiempo no voy a entretenerme con ello. Por ello lo máximo que me voy a permitir es un juego de caracteres de:

1-8 caracteres en minúsulas -> Sin éxito, hash no encontrado
1-14 carácteres solo numéricos -> Éxito!!

C:\Users\Theliel\>MDCrack-sse.exe –charset=%N xxxxxxxxxxaa9a0f9d4dad275559194f

System / Starting MDCrack v1.8(3)
System / Running as MDCrack-sse.exe –charset=%N xxxxxxxxxxaa9a0f9d4dad275559194f s
System / Filtering custom charset… done
System / Charset is: 0123456789
System / Detected processor(s): 8 x INTEL Itanium | MMX | SSE | SSE2 | SSE3
System / Detected hash format: MD5
Info   / Other possible matche(s): MD2, MD4, PHP, MD4MD4, MD5MD5
System / Target hash: xxxxxxxxxxaa9a0f9d4dad275559194f
System / >> Using MD5 cores: maximal candidate/user salt size: 16/54 bytes
Info   / Press ESC for available runtime shortcuts (Ctrl-c to quit)
Warning/ Thread number has been reduced in order to match charset size
Info   / Thread #0: >> Using Core 1
Info   / Thread #1: >> Using Core 1

……..
Info   / Thread #4: Candidate size: 10 ( + user salt: 0 )
Info   / Thread #2: Candidate size: 10 ( + user salt: 0 )
———————————————————-/ Thread #3 (Success) \—-
System / Thread #3: Collision found: 1122334455
Info   / Thread #3: Candidate/Hash pairs tested: 463 062 646 ( 4.63e+008 ) in 59s 131ms
Info   / Thread #3: Allocated key space: 2.22e+015 candidates, 0.00% done
Info   / Thread #3: Average speed: ~ 7 831 081 ( 7.83e+006 ) h/s

Bueno, he tenido suerte, era una contraseña numérica de 10 dígitos: 1122334455 (No era esa, pero por razones de seguridad será esa la que usemos). Solo tengo que intentar un acceso por telnet y ver si es la contraseña realmente. Bueno, telnet me responde con un error, pero no me dice que la contraseña sea errónea, sino que dicho usuario tan solo tiene acceso remoto, no local. Si pruebo con otra contraseña me responde directamente contraseña/usuario incorrecto, ergo ya tengo la contraseña del usuario tech.

Indagando un poco en Destiny pude comprender que este router tiene una serie de jerarquía de niveles de acceso bastante seria. Por ejemplo existe siempre un usuario por omisión root con acceso completo. Mi usuario Theliel con permisos administradores posee permisos para modificación de todos los servicios, pero no tiene acceso desde remoto. El usuario tech le pasa lo contrario, tiene permisos casi totales pero no de forma local. Puedo modificar los permisos de Theliel como desee, pero no puedo realizar ninguna tarea sobre tech, labor que tan solo puede el usuario por omisión root:

{Theliel}=>mlp config addpriv name Administrator anyaccess anyservice

Con eso Theliel obtendrá permisos de acceso remoto, y tech no es en principio un problema, dado que Destiny no permite por defecto ningún tipo de acceso externo, tan solo cuando premeditadamente se permite dicho acceso. No obstante, ya que poseo la contraseña de acceso del usuario tech sería buena idea intentar el acceso como root con dicha contraseña. Y de nuevo éxito!! Y con acceso de root ahora sí puedo eliminar si así lo deseo el usuario tech de forma permanente:

{root}=>mlpuser config delete name tech

Con esto podría dar por concluido la diversión. Esto es algo que no se debería de hacer nunca, dado que podríamos producir un bloque completo del dispositivo y hacerlo irrecuperable por parte incluso de su dueño o el ISP. Primero cambiando la contraseña de root garantizaríamos que nadie pudiese acceder al router. Pero queda otra cuestión. El dueño de Destiny ante cualquier tipo de sospecha o incluso vita de un técnico o recomendación de un amigo o… le bastaría con pulsar el botón de reset en la parte de atrás del router para que todos los ajustes volviesen. ¿Que se puede hacer ante esta situación? Anular el reset. NOTA!! Anular el reset de un router (no todos se pueden) es una práctica poco aconsejable, y tan solo se debería de hacer en circunstancias muy concretas. En este caso sí es posible deshabilitar el reset:

{root}=>system config resetbutton=false
{root}=>saveall
{root}=>system reboot

Terminamos guardando todos los cambios y reiniciando Destiny, una vez reiniciado completamente bajo mi control. Si algo fallase al tener el botón de reset deshabilitado y sin ningún otro usuario autorizado para acceder, el router se quedaría completamente inservible, recuperable tan solo a través de un cable de consola o un JTAG para poder eliminar la nvram.

¿Que se gana? Bueno, esto es solo un resumen. Una vez concluí todo, incluyendo una instrucción para aumentar la potencia del adaptador WIFI, pasé de tener un 19% de señal a un 29%, haciendo posible disfrutar de una navegación completamente fluida y sin ningún tipo de corte, sin necesidad de tener e Chaos orientado a ninguna parte.  Por otro lado, podía estar seguro ya no solo del firewall de mi propio router, sino tb del de Destiny.

 

¿Moraleja?

Las personas siguen sin darse cuenta del peligro que entraña la seguridad y la privacidad. Ambas deben de ser un deber para cualquier usuario. Quien no pueda porque no lo sepa, existen profesionales para auditar la seguridad de una empresa o incluso de un usuario!! el peligro no es algo tan banal como robar un poco de conexión por dios, eso es lo de menos. El peligro es el acceso a toda la red del usuario, el poder usar técnicas de sniffing (me queda poco para terminar el siguiente artículo) o simplemente el molestar por molestar al que se tiene al lado. No implica que todos sepan o que cualquier persona puede jugar con tus infraestructuras, pero tampoco puedes dar por echo de que tu sistema es realmente seguro. Que hubiese pasado si en vez de la casa de un vecino es el negocio de una empresa? Que sucede si soy un cabrón y no solo no hablo con el dueño sino que uso su red de forma indiscriminada e incluso ilegal!! por ejemplo descargando pornografía infantil o cualquier otra historia. Una vez más… ¿soy un paranoico o tengo algo de razón en ello?

Un saludo.

 

PD: La crónica de la playa segunda parte no creo que sea escrita. Posiblemente conecte el modem 3G directamente a mi router ASUS-NT16 o realice un puente de red en el PC para enviar la conexión al viejo WRT54GL y usar este para WIFI u otros equipos. Aunque nunca se sabe… en cualquier momento tengo acceso a otra red y repetimos esta misma crónica pero con otro modem/router diferente.