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.

¿Qué es peor, la ignorancia o la indiferencia? ¿Quién lo sabe? ¿A quién le importa?

La sensación de seguridad es algo psicológico que, en muchos casos, viene erróneamente dada por la ignorancia o la indiferencia hacia este tema.

Para aquellas personas que, además, son responsables de sistemas de información, he hecho un pequeño checklist en el que resumo algunas actividades que considero que son esenciales para no sentirse completamente inseguro.

Por lo tanto, no estas seguro si…

  • Crees que no eres un objetivo para nadie
  • Nunca has sufrido una auditoría
  • Cualquiera puede saber más que tú de tus entornos con un simple nmap
  • Crees que tu [cortafuegos|WAF|IDS/IPS] te va a servir de algo
  • Te fías de tus usuarios, administradores y desarrolladores
  • Ni tú ni nadie mira los logs de tus sistemas y aplicaciones
  • Pones en producción servicios cuya seguridad no ha analizado nadie
  • Crees que el [documento de seguridad|plan de seguridad|plan de adecuación|etc.] desde tu estantería te protege automágicamente
  • Piensas que únicamente el (poco) personal de seguridad es responsable de la seguridad de tu infraestructura
  • Te sientes seguro

Por supuesto esto no es un listado completo, ¿qué más añadirías?

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.

Vamos a ver si animamos un poco esto que está algo decaído. Y nada mejor que un quiosco inseguro, que siempre es muy gracioso.

Desde lo del IKEA le tengo ganas a cualquier quiosco que pillo y siempre intento meterles mano. He pillado alguno más que no puedo contar porque son de clientes (algunos pagados y otros de buen rollo).

En particular, este que os cuento hoy ha sucedido esta mañana en unas oficinas de un organismo nacional del que prefiero mantener el anonimato.

El quiosco en cuestión está en la puerta para expedir los tiques de turno para ser atendido. Nada más verlo te das cuenta de que es un Explorer con una web.

Pues la cosa es que dándole varias veces en la esquina con el dedo así rápido conseguimos sacar el menú de imágenes del Explorer. A partir de ahí, es posible acceder al navegador de ficheros pulsando el último icono (que te lleva a ‘mis imágenes’), que te muestra también la barra de Windows.

Aquí os dejo una foto del hecho. Observad que se trata de Windows XP con servicios Novell y, al menos, tiene instalado el MySQL -Front. Este software es gracioso porque, según su descripción es:

MySQL-Front es una sencilla pero útil aplicación diseñada especialmente para desarrolladores que trabajan con MySQL.

Desde el primer momento en el que empiezas a usar este administrador descubres su facilidad para obtener información sobre las bases de datos, tanto de sus tablas como de su estructura y contenido.

Todo ello desde un interfaz muy intuitivo que recuerda bastante a la estructura del Explorador de Windows.

Con MySQL-Front se pueden realizar acciones básicas como añadir, borrar o modificar tablas, campos, registros, y además:

No parece muy necesario en un quiosco… Lo que me sorprende también es que tiene un software de quiosco… pero vamos, no parece ser muy efectivo contra acceso al sistema operativo.

Por cierto que, os estaréis preguntando… ¿pero tenia conexión a Internet? ¿Se podía acceder a otros equipos del organismo? ¿Qué privilegios tenía vuestro usuario? ¿Era parte del dominio? ¿Presume un pájaro cuando vuela? ¿Ha visto usted algún marciano?

Pues la verdad es que… ni puta idea. Lo primero es que el cacharro no tiene teclado físico. Así que por aquél entonces no sabía como lanzar uno virtual (parece que Windows XP trae un ‘on screen keyboard’ que puede lanzarse mediante el comando OSK).

Y lo segundo es que no paraba de entrar gente a por su turno y así no había manera de probar nada.

Por lo tanto, si vuelvo a ir ya os contaré, siempre y cuando no esté la cosa saturada de peña, que si no…

Para terminar, un poco de moralina. Y es que no se pueden tener quioscos así desprotegidos porque afectan a la seguridad de toda la organización y, en muchos casos, es trivial saltarse la protección del ‘modo quiosco’.

Y en este caso en concreto, ¿de verdad es necesaria una página web y un windows XP para cuatro botones que escupen un turno secuencial?

La mejor escena de Instinto básico para mí siempre fue esa en la que el Douglas sube las escaleras diciendo “porque yo soy…” y la Sharon Stone (sharito para los colegas) le completa la frase diciendo “impredecible”.

Dicho esto, emplear secuencias predecibles en el ámbito tecnológico puede desembocar en problemas que el diseñador no ha previsto.

Veamos algunos ejemplos de la vida real.

El otro día me encontré un servidor de streaming servido desde una aplicación web. Resulta que los enlaces a los contenidos tienen un formato numérico del tipo 0091.flv, 0067.flv, etc. Así que, con un pequeño script es posible hacer un barrido por las 10000 posibilidades, a ver qué encontramos.

Otro día distinto me dieron una cuenta de usuario para hacer unas pruebas y tenía una nomenclartura tal como esta: thx1138. Hmmm. Total que probando, todos los usuarios del sistema eran del tipo thxNNNN. Así que es trivial encontrar nuevos usuarios para otras felonías.

Hay cierta organización que tiene un conjunto de servidores cuyos nombres son del tipo wsNNN. Por lo que, para descubrir servidores sólo hay que iterar entre las 1000 posibilidades.

En otro sitio vi que había una aplicación web que hacía de portal de entrada para otras aplicaciones. Cada usuario veía las aplicaciones que le correspondían en base a su perfil… pero claro, se trataba de un número secuencial, por lo que era fácil descubrir otras aplicaciones a las que, en principio, no tenías acceso.

Uno clásico es el directorio lleno de ficheros generados por una aplicación al que te dan acceso directo. Y resulta que es un tmpNNNNNNNN.pdf o similar. Pues nada, a probar ahí a ver si encontramos otros PDFs.

Otro clásico es la publicación de aplicaciones web de desarrollo o páginas borrador en el entorno de producción, disponibles a quién sepa la URL. Cuando es predecible, siempre aparece al que se le ocurre probar. Por ejemplo, si la aplicación es /aplicacion2011, ¿existira /aplicacion2012? Si la noticia es news20111110… ¿existirá news20111111?

El mayor de los peligros de este tipo de pensamiento (aparte de la enumeración) es que, a veces, hay recursos que el diseñador piensa que están protegidos porque no son ‘enlazados’ desde ningún sitio. Pero claro, si simplemente iterando eres capaz de encontrarlos…

Para los que no la conozcáis una herramienta muy útil para estos casos es seq. Por ejemplo, si queremos generar una secuencia del 1 al 10:

$ seq 1 10
1
2
3
4
5
6
7
8
9
10

O si queréis algo más elaborado: por ejemplo, empezar en 0000 hasta 1138 de dos en dos, añadiendo el thx y con cuatro digitos rellenando con ceros si hace falta.

$ seq -f 'thx%04g' 0000 2 1138
thx0000
thx0002
thx0004
thx0006
thx0008
thx0010
thx0012
thx0014
thx0016
thx0018
...

Para usar esto, por ejemplo, en una secuencia de comandos, podemos hacer lo siguiente:

$ for i in `seq -f 'thx%04g' 0000 2 1138`
> do
> curl -siLk https://lucas.film/user=$i
> done

¿Qué hacemos para no ser predecibles? Pues pensar un poco cada vez que vayamos a nombrar muchos elementos. En ciertos casos es imposible o inconveniente, pero en otros… es fácil.

En el caso del streaming o de las aplicaciones, o nombres de ficheros en general, es posible emplear identificadores universalmente únicos (UUID) que son difíciles de predecir, adivinar o probar por fuerza bruta.

Todos los lenguajes disponen de librerías UUID para generar vuestros nombres aleatorios irrepetibles. De hecho, existe un comando uuid que podéis instalar en vuestra distro favorita o descargar de OSSP.

Los problemas de secuencias predecibles han causado muchísimos problemas en redes. Tanto es así que en OpenBSD fueron los primeros en generar números aleatorios para todo, desde PIDs a números de secuencia TCP. Eso les ha salvado de algunos problemas que han tenido otros sistemas operativos.

Recordad diseñar siempre cualquier tipo de conjunto de elementos nominales para evitar secuencias evidentes que nos hagan tan predecibles como Michael Douglas en Instinto básico.

Coincidiendo con las noticias del World IPv6 Day (el próximo 8 de junio, reservad vuestras agendas) el otro día me decidí a desempolvar mis limitados conocimientos en el nuevo protocolo que sustentará la Internet del futuro.

Un momento… ¿del futuro?

Si consideramos el uso de IPv6 a escala global pues sí, aún no está (aunque sigue avanzando poco a poco). Pero si consideramos el soporte de sistemas operativos, ya todos lo traen… activado por defecto.

Disponer de funcionalidad que realmente no usas tiene siempre implicaciones de seguridad, claro.

Haced un ip a o un ifconfig y buscad inet6. Lo más seguro es que tengáis ya asignada una dirección IPv6.

No voy a entrar a comentar nada sobre los cambios que supone el IPv6 sobre la versión 4 ni nada que ya bastante podéis encontrar por ahí. Sí quiero incidir en los siguientes puntos interesantes que he podido extraer del vídeo que os empotro al final de este post.

  • Las medidas de filtrado o limitaciones que hayáis puesto para servicios sobre IPv4 no van a ser efectivas en IPv6, lo que significa que es posible que sea posible acceder a servicios limitados a determinados rangos de direcciones IP.
  • Es posible que no encuentres los mismos servicios corriendo en uno y otro protocolo, por lo que la exposición de dichos servicios será diferente.
  • Es bastante probable que tu monitor de red y/o IDS no registre tráfico IPv6, por lo que un intento de explotación usando este protocolo puede pasar más desapercibido.
  • Las herramientas de seguridad suelen tener limitaciones cuando se utiliza IPv6.
  • Normalmente no vas a ser capaz de salir de tu red interna por IPv6 (ya que, a diferencia de equipos y servidores, necesitarías un esfuerzo para conseguirlo. Tendría que estar soportado por tu ISP o emplear algunos de los servicios de túneles disponibles gratuitamente por ahí.

Si tenéis activado IPv6 en algún equipo sobre el que tengáis acceso podéis probar a ejecutar los siguientes comandos:

  • ping6 ff02::1%eth0 para identificar otros equipos con IPv6 activado (y que respondan a ping)
  • ping6 ff02::2%eth0 para identificar equipos con funciones de rutado sobre IPv6 en vuestra red

Sustituid eth0 por la interfaz que queráis usar. Para profesionalizar un poco más el asunto, podéis hacer lo siguiente:

ping6 -c 5 ff02::1%eth0 | cut -d' ' -f4 | grep ^fe80 | sort | uniq | sed -e 's/:$//' > ipv6_addr
nmap -6 -sT -iL ipv6_addr

nmap es una de esas herramientas con limitaciones en el uso de funcionalidad sobre IPv6.

Debido a que la dirección IPv6 autoconfigurada se compone de elementos de la MAC de la interfaz, es posible, mediante un <code>arp -a</code> identificar visualmente a qué equipos (identificados por su dirección IPv4) corresponden las direcciones IPv6 que has encontrado.

Algo así hace automáticamente metasploit con el plugin auxiliary/scanner/discovery/ipv6_neighbor.

Por favor, ved el vídeo porque tiene muchas ideas interesantes desde el punto de vista de seguridad sobre IPv6:

  • Frameworks específicos para análisis y explotación de redes IPv6
  • Uso de socat para pasar de IPv4 a IPv6 y poder ejecutar herramientas que no tienen soporte nativo
  • Servidores de túneles para conectarse a la red mundial de IPv6 y poder participar del World IPv6 Day.
  • etc.

¿Has probado cuántos equipos tienen direcciones IPv6? ¿Has visto si difieren los servicios que ofrecen? Si lo haces no olvides comentarnos tus hallazgos aquí o en el próximo Sec&Beer.

Ah, y si consigues conectarte a Internet con IPv6 no olvides ir a ver a la tortuga bailando.

Por último, el vídeo prometido.

Rick Hayes – Assessing and Pen-Testing IPv6 Networks from Adrian Crenshaw on Vimeo.

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.

 

No hace mucho que me encontré con un colega en el Corte Inglés. Mientras jugábamos con unos iPads de muestra, apareció un conocido suyo que, entre otras cosas, le contó que últimamente se dedica a ser ‘hacker a domicilio‘ en el barrio.

La siguiente imagen muestra su ‘tarjeta de visita‘.

Tarjeta de hacker a domicilio

Tarjeta de hacker a domicilio

El principal reclamo de esta tarjeta es proporcionar acceso a Internet Wi-Fi gratis a través del uso de la conexión de algún vecino (al que no le sale gratis, claro). Aunque nos contó que los ‘clientes’ le piden otro tipo de servicios ‘más complejos’, tales como:

  • Esnifar el messenger de otros
  • Descrubrir la contraseña de correo de la novia

En definitiva, que aunque el chaval en cuestión no parecía ser otra cosa que un ‘script kiddie‘ esta es una amenaza más a considerar en el entorno doméstico. Ahora cualquiera, supongo que por poco dinero, puede intentar acceder a tu conexión Wi-Fi y, si lo consigue, ya de paso, enterarse de lo que estás haciendo en la red. Y además alguien que vive cerca de ti.

Para echarse unas risas yo recomiendo, al que pueda, implantar la ‘Internet vuelta del revés‘. A ver si un día de estos flasheo mi router Wi-Fi con alguna distro de Linux.

Por otro lado, esto también es una oportunidad de negocio en el caso de que algún día nos cansemos o se cansen de nuestro trabajo actual. No muy honorable pero… ¿qué trabajo lo es?

Genial este poster de la KiwiCon III.

Hackers don't give a shit
Lamentablemente no se ven todos los puntos. Voy a intentar traducir los que pueden leerse.

A los hackers les importa un carajo:

  • que sea un sistema heredado
  • que sea demasiado crítico para actualizarlo
  • tus ventanas de parada de servicio
  • tu presupuesto
  • que lo hayas hecho siempre así
  • tu fecha de puesta en producción
  • que sea sólo un piloto/prueba de concepto
  • tus acuerdos de no divulgación
  • que no fuese un requisito del contrato
  • que sea un sistema interno
  • que sea muy difícil de cambiar
  • que esté pendiente de ser re-emplazado
  • que no estés seguro de cómo arreglarlo
  • que esté gestionado en la nube
  • tu entrada en el registro de riesgos
  • que tu proveedor no mantenga esa configuración
  • que sea una solución para salir del paso
  • que cumpla el [insertar aquí un estándar]
  • que esté cifrado en el disco
  • que el beneficio no supere el coste
  • que “nadie podría haberse imaginado eso”
  • que no puedas explicar el riesgo al ‘negocio’
  • que tengas otras prioridades
  • tu fé en la competencia de tus usuarios internos
  • que no tengas una justificación de negocio
  • que no puedas demostrar que haya retorno de la inversión
  • que hayas externalizado ese riesgo
Si alguna vez has puesto o te han puesto alguna de estas escusas y te has sentido reconfortado… piénsalo de nuevo.