Y2K36: protocolo de sincronización de tiempo (NTPv3)

El protocolo de sincronización de tiempo (NTP) se utiliza para mantener el reloj de las computadoras en la hora correcta. Muy utilizado en internet y de muy alta precisión. Sin embargo, su versión 3 tiene un límite de precisión de poco más de 136 años.

Utilizando como fecha cero el 1º de Enero de 1900, la marca de 32 bits para los segundos implica que el problema sucedería en el año 2036. Afortunadamente, el protocolo ya previno dicho inconveniente y su última versión NTPv4 ya utiliza 64 bits para dicha representación, suficiente como para mantener las horas sincronizadas hasta el fin del universo.

Sin embargo, numerosos sistemas aún utilizan la versión 3. En particular, Windows XP y Windows Server 2003, sistemas operativos utilizados desde hace 6 ó 7 años. Y, por lo que pude leer, Windows Vista utilizaría la misma aplicación, lo que aumenta las probabilidades de que haya problemas al respecto con estos sistemas operativos.

Y2K38: tiempo Unix

Los sistemas basados en Unix cuentan el tiempo en segundos desde el 1º de Enero de 1970 (llamado Epoch) con 31 bits – 32 en realidad, pero 1 bit es para el signo -. Esto quiere decir que sólo pueden contar hasta 2147483647 (un poco más de 2 mil millones) segundos, equivalente a las 03:14:07 del 19 de Enero de 2038 en UTC. Esto sería la 01:14:07 en Argentina si para aquél entonces todavía cambiamos la hora como hicimos este verano (las 00:14:07 si no).

Eso nos da aproximadamente 30 años, pero hay aplicaciones que trabajan 30 años a futuro. En particular: aquellas que son utilizadas para préstamos hipotecarios o similares. Ésto, sin embargo, podría llevar a errores de cálculo en este momento si dichos programas hacen una simulación de los pagos de dichos préstamos.

El problema no existe en plataformas de 64 bits, cuya adopción debería de ser popular para aquél entonces. Sin embargo, una solución para los dispositivos de 32 bits es necesaria. Y cualquier cambio que se haga será complicado de implementar ya que implicaría romper muchos programas que no están preparados para ello.

Por suerte el futuro queda muy lejos

Sin embargo, dados recientes estudios, el NIST (Instituto Nacional de Estándares y Tecnología – USA) publicó 4 algoritmos para generar números pseudo-aleatorios. Uno de ellos utiliza una gran cantidad de constantes cuya explicación brilla por su ausencia. Como si eso fuese poco, hace unos meses descubrieron que esas constantes tienen relación con otros números que formarían el esqueleto de una llave maestra que permitiría predecir la generación de números. Esto, evidentemente, es un problema de seguridad grande como una casa.

Aquí traduzco el artículo completo escrito por Bruce Schneier (una persona dedicada a la seguridad y la criptografía desde hace décadas) y publicado en Wired el día de hoy.

Notas de Traducción

• Esto es una traducción, el original debe de ser atribuído a Bruce Schneier
• Los links se mantuvieron como en el original, por lo que seguramente conducen a información en inglés
• Los acrónimos utilizados tendrán su correspondiente traducción aunque ésta no se encuentre en el original
• Artículo Original: Did NSA Put a Secret Backdoor in New Encryption Standard?

La Traducción

Los números aleatorios son críticos para la criptografía: claves de encriptación, desafíos aleatorios de autenticación, vectores de inicialización, esquemas de intercambios de clave, generación de números primos y mucho más. Rompamos el generador de números aleatorios y generalmente romperemos también el sistema de seguridad completo. Razón por la que debemos preocuparnos por un nuevo estándar de generadores de números aleatorios que incluye un algoritmo que es lento, mal diseñado y que podría llegar a incluir una puerta trasera para la NSA (Agencia Nacional de Seguridad de USA)

Generar números aleatorios no es sencillo y los investigadores descubrieron muchos problemas y ataques con el pasar de los años. Un paper reciente encontró una falla en el generador de números aleatorios de Windows 2000. Otro encontró fallas en el generador de números aleatorios de Linux. Allá en 1996, una temprana versión de SSL fue quebrada debido a las fallas en su generador de números aleatorios. Con John Kelsey y Niels Ferguson en 1999 diseñamos Yarrow, un generador de números aleatorios basado en nuestro propio trabajo de criptoanálisis. Yo mejoré el diseño cuatro años más tarde – y lo renombré Fortuna – en el libro “Criptografía Práctica” que escribimos con Ferguson.

El gobierno de los Estados Unidos publicó un nuevo estándar oficial para generadores de números aleatorios este año, seguramente a seguir por desarrolladores de software y de hardware en todo el mundo. Llamado NIST Special Publication 800-90 (PDF), el documento de 130 páginas contiene cuatro técnicas aprobadas llamadas DRBGs (Generadores Determinísticos de Bits Aleatorios). Los cuatro basados en primitivas criptográficas pre-existentes. Uno está basado en funciones de hash, otro en HMAC, uno en cipher de bloque y el último en curvas elípticas. Es un diseño criptográfico inteligente el utilizar sólo unas pocas primitivas criptográficas confiables, por lo que construir un generador de números aleatorios de partes existentes es algo bueno.

Pero uno de esos generadores – el basado en curbas elípticas (N. de T.: curvas elípticas es un concepto matemático muy avanzado y muy utilizado en la actualidad en criptografía) – no es como los demás. Llamado Dual_EC_DRBG, no sólo es complicado de pronunciar sino que es tres órdenes de magnitud más lento que sus pares. Es parte del estándar sólo por haber sido premiado por la NSA, quien lo propuso originalmente hace años en un proyecto de estandarización relacionado en el ANSI (Instituto Nacional Americano de Estándares).

La NSA siempre estuvo íntimamente involucrada en los estándares criptográficos de Estados Unidos – son, después de todo, expertos en hacer y romper códigos secretos. Por lo que la participación de la agencia en el estándar publicaod por el NIST no es siniestro en sí mismo. Sólo cuando se revisa en detalle la contribución de la NSA surgen las dudas.

Los problemas con Dual_EC_DRBG fueron descriptos por primera vez a principios de 2006. La matemática es complicada pero la idea general es que los números aleatorios producidos por el generador tiene un pequeño sesgo. El problema no es suficiente como para hacer inusable al algoritmo – pero es causa de preocupación. Los criptógrafos somos gente conservadora: no nos gusta utilizar algoritmos que tengan el más mínimo esbozo de problema.

Pero hoy hay un hedor aún más grande alrededor de Dual_EC_DRBG. En una presentación informal (PDF) en la conferencia CRYPTO 2007 en Agosto, Dan Shumow y Niels Ferguson mostraron que el algoritmo contiene una debilidad que sólo puede ser descripta como una puerta trasera.

Así funciona: hay un conjunto de constantes – números fijos – en el estándar que se usan para definir la curva elíptica del algoritmo. Éstas constantes están listadas en el Apéndice A de la publicación del NIST, pero en ningún lado se explica de dónde salieron.

Lo que mostraron Shumow y Ferguson es que éstos números tienen una relación con un segundo conjunto de números secretos que pueden hacer las veces de un tipo de esqueleto de clave. Si se conoce los números secretos, se puede predecir la salida del generador de números aleatorios recolectando sólo 32 bytes de su salida. Para ponerlo en términos concretos, sólo necesitamos monitorear una conexión de internet encryptada con TLS para poder romper la seguridad de ese protocolo. Si se conoce los números secretos se puede romper completamente cualquier instancia de Dual_EC_DRBG.

Los investigadores no saben cuáles son dichos números secretos. Pero por la forma en la que funciona el algoritmo, la persona que generó las constantes podría saber; tuvo la oportunidad matemática de generar las constantes y los números secretos en paralelo.

Por supuesto, no tenemos forma de saber si la NSA conoce los números secretos que rompen Dual_EC_DRBG. No tenemos forma de saber si un empleado de la NSA trabajando por su cuenta encontró las constantes – y tiene los números secretos. No sabemos si alguien del NIST o alguien del grupo de trabajo de ANSI las tiene. A lo mejor nadie las posee.

No sabemos de dónde vinieron las constantes para empezar. Sólo sabemos que quien sea que las generó podría tener la clave para esta puerta trasera. Y sabemos que no existe forma que el NIST – o nadie más – demuestre lo contrario.

Esto es algo preocupante.

Aún si nadie conoce los números secretos, el hecho que haya una puerta trasera presente hace a Dual_EC_DRBG muy fráfil. Si alguien resuelve sólo una instancia del problema de curva elíptica del algoritmo, efectivamente tendría las llaves del reino. Podría utilizarlas entonces para cualquier propósito infame que desee. O podría publicar su resultado y dejar toda implementación del generador de números aleatorio completamente insegura.

Es posible implementar Dual_EC_DRBG de forma tal que esté protegido contra esta puerta trasera generando nuevas constantes con algún otro generador de números aleatorios seguro y luego publicando su semilla. Este método inclusive está en el documento del NIST en el apéndice A. Pero el procedimiento es opcional, y adivino que la mayoría de las implementaciones de Dual_EC_DRBG no se molestarán en utilizarlo.

Si esta historia los deja confundidos, bienvenidos al club. No comprendo por qué la NSA fue tan insistente en incluir Dual_EC_DRBG en el estándar. No tiene sentido como puerta trasera: es pública y bastante obvia. No tiene sentido desde una perspectiva ingenieril: es muy lento para que alguien realmente quiera utilizarlo. Y no tiene sentido mirándolo desde el punto de la compatibilidad: cambiar un generador de números aleatorios por otro es sencillo.

Mi recomendación es, si necesitan un generador de números aleatorios, no utilizar Dual_EC_DRBG bajo ninguna circumstancia. Si tienen que utilizar algo del SP 800-90 utilicen CTR_DRBG ó Hash_DRBG.

Mientras tanto, tanto el NIST como la NSA tiene explicaciones que dar.

He aquí una recopilación de lo que pasó (y sigue pasando) con el DRM en este año:

• Enero 3: Ya se pueden leer Blu-Ray y HD-DVD
• Enero 13: Se confirma la ruptura de la encriptación de HD-DVD
• Enero 18: Virgin y Fnac quitan el DRM para aumentar ventas
• Enero 24: el DRM de apple es declarado ilegal en Noruega
• Enero 29: rompieron DRM de Windows Vista
• Febrero 6: Apple quita el DRM de las canciones que vende on-line
• Febrero 10: EMI venderá sus canciones sin DRM
• Febrero 13: encuentran la llave maestra al DRM de HD-DVD y Blu-Ray
• Febrero 15: Un estudio indica que el 62% de los ejecutivos de las disqueras creen que el DRM frena el mercado
• Febrero 22: Puretrack comienza a vender parte de su catálogo sin DRM
• Febrero 24: Eric Flint dice que el DRM no sólo no evita la piratería sino que la causa
• Marzo 01: Tim Berners-Lee dice que el DRM no sirve
• Marzo 06: Un nuevo modelo de negocios con música sin DRM
• Marzo 15: Se publica un estudio sobre el costo real del DRM en la industria de la música
• Marzo 19: MusicLoad quiere vender canciones sin DRM para evitar el 75% de las llamadas a soporte técnico
• Marzo 20: MIT cancela suscripción a una fuente de papers técnicos por el DRM que utilizaba
• Abril 07: Microsoft anuncia que se suma a Apple para dejar el DRM
• Abril 12: AACS roto ahora también en las X-Box
• Abril 17: Sony tiene problemas de su DRM en sus propios reproductores
• Abril 23: Se rumorea que Amazon también venderá canciones sin DRM
• Mayo 16: Amazon confirma que quitará el DRM de su catálogo
• Mayo 17: rompen nueva versión de AACS una semana antes de que salga al mercado
• Junio 09: la BBC hace enojar a sus seguidores con su DRM
• Junio 24: el DRM de Windows Vista podría no funcionar sobre una máquina virtual
• Julio 15: rompieron el DRM de Zune
• Agosto 01: Hackers 5 – DRM 0
• Agosto 09: rompieron DRM de Microsoft sobre streaming de Netflix
• Agosto 10: Universal ofrecería su catálogo sin DRM

Si, definitivamente el DRM no tiene mucho futuro. Esperemos que todas estas ideas que no benefician a nadie tengan igual destino.

1. /etc/password: el archivo donde están los usuarios (las contraseñas se guardan en otro archivo en el 99% de los sistemas)
2. el perfil de Firefox: lee desde las configuraciones del perfil hasta los plugins instalados

Como si fuese poco, hace tiempo ya se comprobó que Skype para Windows lee la BIOS.

Si uno lee un poco hay al menos un par de razones para necesitar leer estos archivos:

• El programa necesita saber dónde está nuestro home
• Quiere convertir un UID a un nombre de usuario o viceversa
• Verifica si tenemos instalado o activado el plugin de Skype para Firefox

Eso sí, ¿por qué no pide permiso para hacer esas cosas? ¿por qué no hay algún tipo de respuesta oficial al respecto? Yo no me preocuparía demasiado; pero he aquí un gran punto a favor del Software Libre y el de Código Abierto. De tener acceso al código podríamos saber exactamente qué es lo que hace con la información que busca y nadie se preocuparía.

Por un lado, vía TechTear Mozilla libera una herramienta para probar software. Básicamente, toma un programa y lo hace trabajar como si alguien lo estuviese usando pero de forma aleatoria. Este tipo de software no es novedad y existe desde hace años (le llaman “Testing Difuso”), pero éste es el primero liberado para ser usado por quien lo desee y con el respaldo de la Fundación Mozilla. Quienes acertadamente dicen que la seguridad de su sistema depende de los usuarios, al liberar esta aplicación sólo les están dando más herramientas.

Sin embargo, Christen Krough, vicepresidente de Opera dice que liberar este tipo de aplicaciones es completamente contraproducente debido a los usos indebidos que se le pueda dar. Mi opinión al respecto es completamente opuesta:

si alguien puede encontrar un agujero de seguridad haciendo uso de las mismas herramientas que podemos tener nosotros nos merecemos que nos hagan lo que fuera que nos quieren hacer

Como si eso fuese poco, via Slashdot me entero que ya existe una forma de obtener acceso a una cuenta con dos clicks. Durante la conferencia de seguridad “Black Hat”, Robert Graham explicó y demostró en vivo cómo podía obtener acceso a una cuenta sin necesidad de saber el nombre de usuario o la password de quien quiera. Lo único que necesitaba hacer es capturar la información que entra y sale de la PC. Cosa que sería muy complicada de no ser por la popularidad de las conexiones WiFi, una puerta abierta para que todos vean lo que hacemos.

Graham desarrolló dos aplicaciones de uso muy específico (que serán liberadas) que permiten obtener acceso a cualquier cuenta que utilice cookies. No importa de qué servicio sea, ni quién la utilice… nisiquiera necesita la contraseña. Sólo obtiene la información de las cookies con un programita, y con otro programita duplica esa información en su propio navegador y voilà, acceso instantáneo. Obviamente, no funciona en conexiones seguras tipo SSL, VPN o sobre SSH.

Nuevamente si no tenemos cuidado sobre cómo accedemos y enviamos nuestra información no podemos pedir que no nos saquen todo.

Salió bien, según uno de los presentes: No lo vendí, fui directo a la información importante y útil. Si bien sé que lo dijo como queriéndome ayudar para la próxima vez (en caso de que la haya) fue justo lo que yo quería lograr. Para explicaciones detalladas y largas hay mucha documentación ya, yo tenía una hora para resumir las 30 páginas que había escrito y pretendía demostrar las capacidades del sistema, no dar un curso detallado sobre cómo usar iptables ó cómo armar un firewall.

Mi visión sobre las herramientas que manejo es demostrar las capacidades del sistema. No sólo porque eso es lo que realmente interesa, sino porque eso es lo que me convence a mí. Obviamente di alternativas a iptables (aunque sobre la hora y bastante apurado), muchas de las que no manejo por lo que no puedo opinar objetivamente; pero eso queda en cada uno. Yo ya mostré qué es lo que se puede hacer con todo esto, cada quien que tome lo que quiera.

Si quieren leer lo que dije pueden bajarlo bien desde la página de GrULiC o bien desde esta misma página. Es un archivo PDF de poco menos de 200K con el informe y, si bien tiene más detalles en algunas cuestiones que en las que no me detuve durante la charla, no contiene exactamente todo lo que se dijo . Se podría trabajar un poco más en el formato; pero no lo voy a hacer por ahora.

Pueden utilizar el documento para lo que gusten. Estaría bueno que me contaran también para ver cuán útil fue (y de paso les puedo dar una mano)

Gracias a GrULiC por la oportunidad y a todos los que fueron.

El año pasado, como parte de la materia Redes y Sistemas Distribuídos, hice un trabajito de investigación al respecto y resultó más interesante de lo que creía. Lo vieron unos amigos y me dijeron que podía hacer una charla al respecto en el marco de las Charlas de GrULic. Por ello, considérense cordialmente invitados:

El próximo Miércoles 15 de Noviembre, a las 21hs., en el aula 34 (subsuelo) de la Facultad de Ciencias Exactas, Físicas y Naturales, sede centro (Vélez Sársfield y Duarte Quirós de la ciudad de Córdoba), Matías Bellone dará una charla titutlada “iptables en español (aka: dejá el paquete sobre la mesa)“. Entrada libre y gratuita.

Resumen de la charla

Desde 1998 un grupo de gente decidió cambiar la historia del manejo de conexiones en Linux. Modificó el kernel, logró que sus cambios se introdujeran al código principal y crearon la herramienta más potente desde la creación de root. Un repaso de su historia, funcionamiento y capacidad en completo español.

Recuerdo que Franco había dicho tener un router FON activo en Córdoba pero no lo encontré. Lo que sí es impersionante la cantidad que hay en Buenos Aires y Capital Federal. Pueden ver dónde están en todo el mundo gracias a los Mapas FON que funcionan sobre Google Maps

En estos días, FON estuvo regalando Foneras en Alemania y Austria bajo la condición que éstos fuesen conectados y utilizados como puntos de acceso FON. He aquí que unos muchachos, estudiantes alemanes, encontraron la forma de entrar al sistema sobre el que trabaja la Fonera y publicaron cómo. Obviamente, la publicación fue en inglés… ahora también en el idioma de cervantes

Las razones

Debido al revuelo causado, los autores han publicado un breve artículo explicando porqué lo hicieron. Dejan muy claro que no pretenden que se usen los routes para otra cosa, boicotear una propuesta como la de FON – que nos beneficia a todos – es simplemente estúpido. Los fundamentos sobre porqué lo hicieron son muy claros; entre ellos:

• Tener control sobre nuestra red: la Fonera procesa y transfiere todos nuestros datos en nuestra red. Un hacker que ingrese a FON podrá meter código arbitrario (como un sniffer) en nuestro router.
• Verificación: FON publicó el código fuente; pero no hay forma de comprobar que dicho código fuente es el que hace funcionar la Fonera (por cuestiones de DRM).
• Seguridad: Todas las Foneras tienen la misma autoridad, con sólo el nombre de usuario y contraseña de la cuenta FON podemos insertar todo lo que queramos dentro de la Fonera de esa persona… inclusive un programa que saque los nombres de usuarios y contraseñas de los usuarios FON que se conecten a nuestro router.
• Inevitabilidad: pretender que la Fonera iba a ser una caja negra permanentemente es una ilusión que nosotros demostramos errada. El que alguien lo hiciera con posibles intenciones maliciosas era una cuestión de tiempo.

Notas de Traducción

• El artículo fue traducido y publicado con permiso por escrito (via un comentario) de uno de sus autores: Stefan Tomanek y Michael Kebe
• Es muy probable que los links conduzcan a sitios en inglés
• Artículo original: Hacking the La Fonera
• Vía Slashdot

La traducción

¿Cómo se configura?

La Fonera es un sistema bloqueado: la configuración normalmente no se hace en el dispositivo sino que éste toma los datos de configuración del servidor FON. Por lo que para configurar los parámetros de red como el ESSID público y prvado y la clave WPA, te logueas en tu cuenta FON y cambias los parámetros desde su sitio web. Durante el proceso de arranque, La Fonera se contacta con el servidor FON y toma su configuración de red. Sin embargo, una interfaz web en el router para configurarlo también existe.

FON también hizo imposible el pisarle el firmware ya que los binarios del mismo están firmados: aquellos archivos del Firmware que no tengan las firas digitales correctas son rechazados por el sistema. Si bien FON publicó el código fuente para el software que corre el router, no son obligados a liberar la clave necesaria para correr el software en su dispositivo. Esto es considerado libre según la GPLv2 pero es uno de los principales aspectos que conciernen a la versión 3 de la licencia GPL.

Por lo tanto, cambiar el firmware no es una opción ya que no hay forma de subir una imagen funcional de firwmware sin poseer la clave criptográfica correcta. Esto es el mismo problema con la grabadora de video digital TiVo.

Mirando el proceso de configuración

Durante su arranque (y en intervalos regulares), La Fonera “llama a casa” para verificar si los datos de configuración fueron modificados. Esto es realizado utilizando una conexión SSH a download.fon.com al puerto 1937. Puedes chequearlo vos mismo:

stefan@nano:~$ telnet download.fon.com 1937
Trying 213.134.45.191...
Connected to download.fon.com.
Escape character is '^]'.
SSH-2.0-OpenSSH_3.8.1p1 Debian-8.sarge.4

El router continúa enviando información para identificarse, incluyendo su dirección MAC y versión de software:

mode='start' wlmac='WIRELESS MAC' mac='LAN MAC' fonrev='4' firmware='0.7.0'
        chillver='1.0' thclver='1.0' device='fonera'

Como respuesta, FON envía instrucciones de consola, incluyendo instrucciones para configurar los dispositivos inalámbricos (ESSIDs y contraseñas WPA).

SSH es una opción elegante desde el punto de vista de FON ya que es relativamente sencillo de instalar en un contexto no interactivo y provee de una forma elegante de evitar suplantación de identidad. Como la clave de acceso a download.fon.com está almacenada en el router, no podemos simplemente decir ser dicho servidor al que se intenta conectar y proveer al nuestro router con nuestros propios instrucciones de consola.

La autenticación se realiza con una clave secreta almacenada en cada router y en el código fuente. Sin embargo, se necesita el cliente Dropbear SSH para utilizarla, OpenSSH pide por una contraseña por razones desconocidas mientras que Dropbear no lo hace. Utilizando dbclient es lo suficientemente sencillo establacer una conexión con el servidor FON y obtener los datos de configuración para nuestra Fonera:

echo "mode='start' wlmac='' mac='' fonrev='4' firmware='0.7.0' chillver='1.0'
 thclver='1.0' device='fonera'" | dbclient -T -i key -p 1937 openwrt@download.fon.com

No hay respuesta alguna ya que dejamos ambas direcciones MAC vacías. De haber utilizado la dirección de una Fonera probablemente hubiésemos recibido:

rm -f /tmp/.thinclient.sh

exit

El archivo /tmp/.thinclient.sh es la ubicación donde se almacena la salida y donde es luego ejecutada por el script de actualización. como FON decidió que no hay nada para hacer, el script se borra a sí mismo y finaliza.

En caso de modificar algunos valores en la interfaz web de tu Fonera antes de recibir los datos, las cosas se verían diferente. Si cambiaste el ESSID, la instrucción para hacerlo son transmitidas al router por un par de instrucciones de consola:

# begin # setssidprivate
awk -v cfgfile="/etc/config/fon" -v "updatestr=private.essid=YOURPRIVATEESSID"
          -f /usr/lib/webif/uci-update.awk -f - > /etc/config/fon.new <<EOF

BEGIN {
    cfg = read_file(cfgfile)
    print update_config(cfg, updatestr)
}
EOF
if [ $? -eq 0 ]; then
    mv /etc/config/fon.new /etc/config/fon
    ifup lan
else
    rm /etc/config/fon.new
fi
# end # set ssid fonera

# begin # set ssid fonera
awk -v cfgfile="/etc/config/fon" -v "updatestr=public.essid=YOURPUBLICESSID"
          -f /usr/lib/webif/uci-update.awk -f - > /etc/config/fon.new <<EOF
BEGIN {
    cfg = read_file(cfgfile)
    print update_config(cfg, updatestr)
}
EOF
if [ $? -eq 0 ]; then
    mv /etc/config/fon.new /etc/config/fon
    iwconfig ath0 essid FON_'YOURPUBLICESSID'
else
    rm /etc/config/fon.new
fi
# end # set ssid fonera
    rm -f /tmp/.thinclient.sh
exit

Código similar es transferido para modificar contraseñas WPA.

¿Cómo inyectamos código?

Como pueden ver, FON tomó ciertas precauciones para evitar que se inyecte código: los parámetros están contenidos en comillas simples para evitar sustituciones de cualquier tipo. El ingreso de caracteres extraños está prohibido por la interfase web y, aún si lograras insertar una comilla simple en tu ESSID, sería “desarmado” al escaparlo con una barra invertida antes de él.

El tipo de ataque de inyección que estamos intentando es muy similar a inyecciones SQL. Nuestro objetivo es poner datos en el sistema que terminen la instrucción en curso (esto es la llamada a iwconfig) y luego comience una nueva instrucción.

iwconfig ath0 essid FON_'YOURPUBLICESSID'

Para poder utilizar esta línea como punto de entrada necesitamos sustituir YOURPUBLICESSID con algo que termine el entorno de parámetro para iwconfig. Para cadenas rodeadas por comillas simples, el único caracter para ello es ‘, sólo una comilla simple que lo cierre. Aún un retorno de línea es incapaz de finalizar la instrucción y será tomada como un parámetro de iwconfig.

Desafortunadamente, FON simplemente reemplaza cualquier ‘ con la cadena \’ para evitar dicho tipo de inyecciones. El agregar una barra invertida a un caracter con un significado especial anula dicho sifnificado; por lo que el peligro de ingreso de intrusos es revertido.

Momento ¿será así? Me sorprendió bastante el consultar la página de manual de bash:

Rodear caracteres con comillas simples preservan el valor literal para cada caracter dentro de las comillas. Una comilla simple no puede ocurrir entre comillas simple, aún cuando sean precedidas por una barra invertida.

Por lo que una comilla simple siempre cierra una cadena rodeada de comillas simples, antecedida por una barra invertida o no. Puedes verificarlo por tí mismo ejecutando esta pequeña instrucción en tu consola:

stefan@nano:~$ echo 'foo\'bar'
>

En lugar de imprimir foo\’bar, bash sigue esperando una cuarta comilla simple ya que la cadena comenzada por la comilla al final de la línea aún no está cerrada.

Realmente logramos inyectar código de esta forma. Todo lo que tienes que hacer es incluir una comilla simple y un retorno de línea en el campo ESSID. Por supuesto, esto no es posible con un navegador, ya que FON intenta proteger su interfaz utilizando Javascript e ingresar un retorno de línea en un campo input puede ser bastante complicado. Existe, sin embargo, un módulo de Perl llamado WWW::Mechanize que le permite a un script comunicarse con un sitio web tal como si fuese un usuario. Utilizando este script, fue finalmente posible ingresar comandos arbitrarios en el script obtenido del servidor FON.

Utilizamos esta ventana abierta para abrir el puerto 22 y activar el servidor SSH Dropbear, lo que nos proveía con acceso total a una consola en el router.

Trepando la ventana y abriendo la puerta principal

El resultado de nuestros experimientos es un script Perl llamado shellfon.pl. Toma como parámetros tu dirección de e-mail y contrasñea FON de la línea de comandos y lee las instrucciones de consola a ser ejecutados en el router de la entrada estándar. Luego se loguea a FON e inserta el ESSID manipulado. Todo lo que debes hacer luego es reiniciar tu Fonera.

Para arrancar y abrir SSH necesitarás la siguiente línea de comandos, que abrirá el firewall en el puerto 22 y lanzará el servidor Dropbear:

echo -e '/usr/sbin/iptables -I INPUT -p tcp --dport 22 -j ACCEPT\\n/etc/init.d/dropbear'
          | perl shellfon.pl email password

Luego de eso, sigue la guía en este sitio para activar permanentemente el acceso de consola. No te olvides de revisar la interfase web nuevamente para configurar tu SSID a algo significativo nuevamente.

Evitando que FON ejecute código en el router

Como ya dijimos, La Fonera recibe instrucciones desde FON desde el enlace SSH. Esto es realizado por el script /bin/thinclient:

[...]
    . /tmp/.thinclient.sh

Si quieres prevenir que La Fonera ejecute el código que recibe, podrías querer cambiar las líneas finales a:

### Don't execute code from FON
# . /tmp/.thinclient.sh

Como puede llegar a haber correcciones de bugs útiles de tiempo en tiempo, podrías tambier copiar o mover los scripts enviados a algún otro lugar para que escrutarlos manualmente luego:

cp /tmp/.thinclient.sh /tmp/thinclient-$(date '+%Y%m%d-%H%M')

De esta forma, puedes revisarlos de tanto en tanto para saber qué es lo que trama FON.

Muchos le echan la culpa a los geeks, otros a los usuarios. Que unos no hacen sistemas confiables, que no toman las precauciones necesarias o que son ellos mismos (los de “su tipo“) los culpables de tanta inseguridad. Los otros dicen que el usuario promedio no sabe qué es lo que hace, que utilizan claves de diccionario o fáciles de adivinar, que hacen click en cualquier lado y revelan información que no deberían. Yo creo que están equivocados… los dos. El problema de la seguridad es de todos.

Tanto de quienes somos responsables de diseñar, construir, implementar y/o mantener sistemas, como aquellos que los utilizan. Pero hay un tercer personaje en esta novela: los medios. Reconozcamos que, por más que nos esforcemos, es complicado hacerle entender al usuario promedio qué es el phishing, cómo decidir qué información revelar o cómo detectar ventanas falsas y sitios peligrosos. En cambio, si lo ven en el diario, el noticiero, o en un blog o sitio de internet que les interese sí prestan atención.

Pero ¿qué pasa cuando esos medios dicen cualquier cosa, o verdades a medias? Es entonces donde se arma el revuelo y todos apuntan dedos. Pero nadie hace nada. Claro ejemplo es un artículo en DiarioTI avisando de un grupo de hackers que publican una vulnerabilidad por día durante Julio. Los errores del artículo son, a mi entender, los siguientes:

• Falta de links: no hay ni un mísero vínculo para poder informarte más al respecto.
• Presunto mal uso de la palabra hackers: el término, si bien está correctamente utilizado, tiene una connotación completamente negativa. El publicar una vulnerabilidad es justamente lo que enaltece el trabajo realizado y los hace hackers y no crackers ya que ésto obliga a los desarrolladores a preparar sus productos contra dicha vulnerabilidad. Caso contrario, cualquiera (y no sólo ellos como sucedería en caso que no la publiquen) podría utilizarla para sus propios objetivos non-sanctos.
• Falta de información: dicen que publicarán vulnerabilidades, no especifican cuáles ni sobre qué navegadores. Estando una semana ya dentro de Julio, significa que se han publicado al menos 7.
• Causar pánico: no dicen cómo protegerse en contra de estas vulnerabilidades. Ni siquiera proveen de recursos para informarse más al respecto.

En caso de haber contenido toda esa información, el artículo sería útil tanto al usuario como a los encargados de sistemas. Además, la publicación gana prestigio y/o audiencia. Todos ganan. Pero no es negocio la seguridad si no se hace escándalo. Otro ejemplo: todos anuncian que Micro$oft dejará de dar soporte a Windows 98/98SE/ME/XP SP1. Esto implica falta de actualizaciones de seguridad y otras tantas cosas; pero nadie dice qué hacer si no se tienen opciones de actualizar (por cuestiones económicas o de hardware). Mi primera respuesta sería, obviamente, Linux; pero hay otras opciones, como extender ciertas medidas de seguridad y minimizar daños. Eso es cuestión de cada uno, pero nadie lo dice… todos se quedan en el escándalo.

Para no quejarme de lleno y hacer de esto una crítica constructiva, he aquí el servicio que yo utilizo para alertas de seguridad. Hay muchos dando vueltas, pero Alerta Antivirus es el que uso yo. Con opción de recibir un e-mail por día con las últimas novedades en materia de Virus clasificados según cuán amenazantes son. También proveen de e-mails especiales en casos extremos (virus de rápida propagación) e información en general sobre el mundo de la seguridad.

Sabiendo o no qué significan todas las cosas que nos pueden pasar. Entendamos o no qué es el phishing, scamming, los troyanos, backdoors, exploits y mil otras palabras estar informados es ir un paso más adelante ¿no?