Archivo de la categoría ‘Sistemas Operativos’

¿Un fallo de seguridad en High Sierra (MacOS) permite acceso Root a cualquiera? Sí, y más simple imposible

Share on Google+Share on FacebookTweet about this on Twitter

Generalmente no suelo hacer eco de estas noticias a menos que el fallo de seguridad (o el exploit) tenga una relevancia/peligrosidad tan elevada. Y es que creo que a estas alturas el que más o el que menos (y si tiene High Sierra espero que seguro) que esté en el “mundillo” habrá escuchado las noticias por todos lados. Sinceramente, creo que nos tenemos que remontar a la famosa “Cadena de la Muerte“, en 2013, para encontrar algo tan flagrante, y en esta ocasión Apple se ha superado, lo ha logrado, nadie lo sabe bien pero lo ha conseguido, basta invocar la cuenta Root en el sistema para que este la cree en ese momento y le asigne una contraseña en blanco. Dicho de otro modo, si cualquiera se pone delante del sistema tenga la cuenta que tenga e intenta entrar/usar el usuario “root”, sin especificar ninguna contraseña, al segundo intento generalmente entra (El primero la crea, el segundo accede).

Bien, no hace falta decir que el usuario root es por lo general la cuenta/usuario maestro en casi todos los sistemas UNIX/Linux, el super administrador. Es decir, que como tal usuario tendremos acceso total al sistema. La cosa es aun peor, porque si el equipo tiene habilitados servicios de acceso remoto, la gracia se puede mascar en el aire.

No es un exploit remoto que permita ejecución arbitraria de código, es un bug en principio con alcance local, y como tal requiere acceso físico al equipo. No obstante a nadie se le escapa la gravedad del asunto. Para usuarios particulares que usen el equipo en entornos digamos de confianza o familiares o… generalmente no va a suponer un gran problema si los que nos rodean tenían acceso igualmente al equipo de forma indiscriminada, pero en entornos más empresariales, equipos portátiles que en cualquier momento puede ser “dejado” en cualquier lugar, el problema no tiene parangón.

La cosa es aun peor, y es posiblemente una de esas políticas que tanto tiempo llevo recriminando a Apple con más intensidad. La falta de actuación y transparencia. Este fallo no ha sido descubierto hoy, Apple lleva tiempo con conocimiento de ello. Es más, hace más de dos semanas se comentaba abiertamente en los foros de soporte, e incluso por lo que dicen, se daba como solución a usuarios que necesitaban acceder a sus propios equipos como Root. En cambio, como siempre, silencio. Hoy, por el motivo que sea a saltado a la prensa, y nos hemos enterado la mayoría (personalmente no tenía constancia de ello), y como Apple hace siempre, es cuando lanza un comunicado diciendo que tendrán la actualización lista para solucionarlo “pronto”. No dudo en absoluto que lo solucionen pronto, eso no me preocupa, ni siquiera en realidad este bug por grave que sea, lo que me preocupa es la falta de inacción por parte de Apple, y que sólo se pone las pilas cuando el problema se escala a los medios de comunicación. La “cadena de la muerte” estuvo funcionando durante semanas sin que se solucionase incluso siendo ya un “vox populi”. Dicho de otro modo… si algo tan sencillo y tan absurdo como este bug (y tan grave) lleva semanas rondando por los foros oficiales de Apple y no han hecho nada, ¿qué exploits/bugs habrá en la trastienda (con conocimientos o sin ellos por parte de Apple) que no conocemos?

Siempre he dicho y “defendido” el error humano. Nadie es perfecto y todas las empresas cometen errores, y de todos los tamaños por cierto. A veces esos errores son tan tontos como es este caso y otras veces la gran genialidad de expertos de seguridad logran meterse en los resquicios más insospechados para hacer saltar un sistema. Esto sucede constantemente y no pasa nada, lo asumimos y lo aceptamos porque en cierto modo nos fiamos de los desarrolladores que, en función de la gravedad y la importancia, tal como los problemas vayan apareciendo, se irán solucionando de igual modo. Puedo perdonar a Apple de que alguno de sus programadores haya metido la pata hasta donde la ha metido, lo que no puedo perdonar es que la vulnerabilidad lleve circulando semanas por su propio foro, y no haya dicho ni hecho absolutamente nada. Eso sí, hoy que salta la noticia a la prensa es cuando se mojan. Deleznable.

Router Mitrastar HGW-2501GN-R2: Shell e Ingeniería inversa (para crear firmwares modificadas, por ejemplo) (Actualizado)

Share on Google+Share on FacebookTweet about this on Twitter

mitrastar
Introducción

La historia es sencilla. Aunque en la medida de lo posible siempre uso mis propios dispositivos, me gusta igualmente exprimir cualquier otro chisme que tenga por casa. Unos fuman… yo cacharreo.

En este caso, este fue el router que me entregó el ISP para mi conexión de Fibra, Mitrastar HGW-2501GN-R2. Duró conectado a la línea el tiempo de irse el instalador, pero lo saqué recientemente del “trastero” al ver por los foros de soporte oficiales (y no oficiales) que estaba dando un sin fin de problemas a los usuarios. Como siempre he dicho, opinar podemos hacerlo todos, pero si queremos dar soluciones que sean lo más acertadas posibles, es mejor comprobar las cosas por uno mismo y poder estudiarlas como dios manda. Así que le saqué el polvo y me puse a desentrañar sus más y sus menos.

Un dispositivo es bueno o malo sencillamente a razón de dos cuestiones sencillas, y es lo bueno o malo que sea su hardware y su software. Si el hardware es “malo” las ataduras de manos siempre son mucho peores, porque salvo modificaciones directamente en el hardware poco podemos hacer. Un hardware bueno tampoco hace del dispositivo algo bueno, es fundamental el Software, y sobre el software podemos decir lo mismo.

En el caso del Mitrastar, tenemos un poco de todo. Respecto al hardware no es ni mucho menos de lo peor que podemos encontrarnos en un router como muchos puedan pensar, pero eso no quiere decir que no se hubiese podido mejorar sustancial, sobre todo lo referente a su interfaz wifi. Eso no podemos cambiarlo, tenemos que aguantarnos con lo que hay. No he conectado aun el router por puerto de serie ni lo he sacado de su carcasa, así que los siguientes datos pueden no ser exactos del todo. Por lo que podemos saber el hardware se compone de una arquitectura MIPS:

CPU1: Ralink RT63368F (En Placa)/RT63365 (En Software)
Switch: Realtek RTL8368MB
Wl0: Ralink RT5392
RAM: 128MB
Flash: 64MB

El Switch debe de contar con unos 7 puertos diferentes, apoyado principalmente por el SOC RT63365. El adaptador inalámbrico dista mucho de ser una maravilla, nos encontramos ante un disposotivo 802.11n de dos streams unibanda. Por otro lado contamos con una cantidad más que suficiente de RAM y Flash para todo, lo cual siempre se agradece el no ir siempre bajo mínimos.

El principal problema que se ha tenido es que el software del router (la firmware) ha estado lejos de ser aceptable, salvaguardando por supuesto las propias limitaciones del hardware. Entre las quejas más frecuentes han sido los enormes problemas de batería causados por el router a dispositivos portátiles, la interfaz web de configuración con constantes problemas… En un mundo ideal, como se trata de Software, en el peor de los casos podríamos decir: “Pues si no quieren hacer ellos su trabajo, al menos voy a ver si puedo yo mejorar o corregir alguno de esos problemas de software”. Pero nunca suele ser tan sencillo, las firmwares y los sistemas se protegen precisamente para impedir cualquier tipo de modificaciones al software, siguen sin entender que cuanto más abierto sea un software más probabilidad hay que funcione mejor y con menos fallos/problemas.

 

Acceso Básico

Manos a la obra, partamos desde cero. Instalamos el router, lo tenemos todo funcionando… ¿ahora que?. Aquí entra en juego el primer escollo, y la culpa de esto la tiene principalmente los ISP, nada que ver con los fabricantes del hardware o el software que se instala (por lo general). Los dispositivos que nos entregan actualmente (No solo Movistar) vienen precargados con una configuración básica por defecto con los ajustes básicos de la compaña, como puedan ser los SSID, ajustes de WAN… ahora debido a los servicios avanzados como VoIP o IPTV suele ser necesario además de todo esto ajustes adicionales específicos para cada cliente, así que el router está preparado para conectar a los servidores de ellos después de un reset o cada X tiempo para reconfigurarse con los datos de la línea del cliente. Esto es perfecto porque evita configuraciones manuales uno a uno.

Lo primero que quiero o puede querer cualquiera es realizar pequeños ajustes a nuestro router, ya sea abrir un puerto, configurar una IP diferente… eso lo hacemos como toda la vida de dios, lo más básico y sencillo: La interfaz web del Router. El problema aparece porque la mayoría de los ISP se preocupan y hacen TODO LO POSIBLE para que el usuario, el cliente, tenga acceso a cuantas menos funciones posible del router mejor. Esto se hace por lo general con la creación de usuarios con permisos mucho más restrictivos a los usuarios tipo admin/root con acceso completo. Estos usuarios que crean tienen al final acceso para modificar 3 parámetros y medio y no poder consultar muchas otras configuraciones que pueden ser de interés, con lo que nos limita enormemente, incluso a usuarios con un perfil básico. Esto es algo que la mayoría no toma en cuenta cuando contrata un ISP u otro, pero para mí es esencial y marca mucho el tipo de compañía que tienes delante. Muchos de los amigos que me leen saben mi opinión sobre Apple, y se resumen sencillamente en que no permito que una compañía me diga que puedo hacer o no hacer con mi hardware.

Dependiendo del dispositivo que tengamos instalado y dependiendo del ISP, podremos acceder de mejor modo o no la configuración de nuestro router. En el caso concreto del Mitrastar, tengo que decir sinceramente que chapó por Movistar, ha hecho lo que tenía que haber echo hace tiempo y hacer TODOS. El Mitrastar, como viene siendo ya costumbre desde hace tiempo en los dispositivos de Movistar tiene dos interfaces web, una sencilla para usuarios nóveles que quieren cambiar 3 cosas (llamada Movistar Home Station, aka mhs, y una avanzada. El Mitrastar posee 3 usuarios (en realidad son 4, pero el usuario samba lo obviamos), cada uno con permisos diferentes enfocados a necesidades diferentes:

-“admin”: La contraseña de este usuario podemos encontrarla debajo del router en una pegatina. Este usuario y contraseña nos da acceso a las dos interfaces del router. Es el acceso normal a la interfaz mhs, y si accedemos a la avanzada a través de mhs (o a través de la dirección http://IP/cgi-bin/main.html) nos encontraremos con limitaciones en cuanto que podemos modificar. Esta cuenta por otro lado carece de acceso por terminal (SSH/Telnet…)

-“1234”: La contraseña coincide con la contraseña anterior, y en este caso sería lo más similar a un usuario root. Tiene acceso completo a las opciones de configuración de la interfaz, y es la cuenta que usa el portal Alejandra igualmente para configurar de forma remota nuestros dispositivos (si los tenemos asociados al portal).

-“supervisor”: La contraseña en este caso es siempre la misma, zyad1234, y posee permisos similares al usuario 1234, con el añadido de que con este usuario se tiene acceso por la interfaz web a poder modificar los permisos de los otros usuarios y de sus contraseñas igualmente.

mhs
web

Ahora entenderéis porqué digo que en este caso chapó por Movistar. Cualquiera puede tener acceso completo (al menos por web) al Mitrastar, sin hacer cosas extrañas, sin tener que pelearse, sin acudir a… dicho de otro modo, los técnicos de Movistar no tienen un mejor acceso que nosotros. Gracias a estos usuarios podremos no sólo consultar la mayoría de todas las configuraciones del router, sino que también ajustarlas a nuestro antojo.

Por otro lado, lo primero que se le ocurre a cualquiera es ver como son los archivos de configuración (backup) del router, así que como primer paso para entender un poco todo lo que cualquiera haría sería descargar dicho archivo desde mantenimiento, quizás sea legible o haya algo o algún ajuste que pueda ser de interés. El archivo de configuración del Mitrastar, por suerte, no está cifrado y parece ser un xml totalmente legible, pero que algunas opciones curiosamente las enmascara, todas aquellas donde hay contraseñas. Por qué es esto interesante?? Bueno, yo he dicho que la contraseña de admin y 1234 es la misma, pero a veces no es tan sencillo como prueba/error, o mejor dicho… a veces es más sencillo no tener que estar probando… pero como vemos el archivo de configuración no permite ver estos datos. En cualquier caso, vemos que estos campos llamados “encrypted” comienzan todos por: “41455300”, casualidad que 41 45 53 = AES, lo cual nos daría a pensar que el resto es posible que sea el texto codificado en AES.

 

Acceso Limitado por Terminal

El 99% de las veces nos sobra la interfaz web, pero que pasa cuando nos gustaría poder modifica o consultar cualquier cosilla que no esté presente o tengamos acceso por la interfaz web?? A fin de cuenta presuponemos que nuestro router estará corriendo algún tipo de Linux debajo de él. Para eso es indispensable acceso mediante SSH o Telnet. El problema es que como aplican la mayoría de fabricantes, para negarnos la posibilidad de toquetear las tripas, lo que nos dan es acceso es a una shell limitada… muy limitada. Así, en el caso del Mitrastar si intentamos acceder mediante supervisor o 1234, nos encontramos ante un panorama… “triste”:

ssh

Así pues podemos acceder con las credenciales por defecto, pero los únicos comandos que nos muestra la interfaz como válidos son: ?, exit, save, sys, restoredefault, lan, igmp, wlan, nat. La mayoría de todos ellos tienen subcategorías. No hay nada interesante a priori que podamos hacer desde la shell que no podamos hacer desde la interfaz web. Dos comandos “al azar” muestran dos resultados interesante: mtd y sh, ninguno de los dos listados en los comandos disponibles. El primero nos devuelve que el comando está prohibido, el segundo directamente que introduzcamos una contraseña… ¿quizás existe una contraseña para poder acceder a la shell que hay debajo? Por descontado ninguna de las contraseñas que disponemos es aceptada como válida.

Algo relativamente común a las shell limitadas es que permiten realizar copias de la configuración. A priori podríamos pensar que esos “dump” son iguales que los que podemos obtener desde la interfaz web, pero… que pasa si introducimos por shell limitada “sys dumpcfg”?? Sí, nos devuelve en la consola exactamente el archivo de configuración que pudimos descargar con anterioridad… pero con una salvedad, en esta ocasión los campos de contraseña están en texto plano. Bingo!!

username=”supervisor” web_passwd=”zyad1234″ console_passwd=”zyad1234″

La contraseña es la misma, pero en cambio en el archivo de configuración cifrado vemos que el “resultado” es diferente. Asumimos que además de poder estar cifrado con AES usa algún tipo de SALT, y no sólo una key cualquiera. Aun así esto tampoco nos abre la puerta a mucho más, esta contraseña es de hace mucho conocida y compartida en muchos productos.

 

Acceso a la Shell que hay debajo

Lo que nos interesa es acceder detrás de la shell limitada a la que tenemos acceso. Parece que para esto existe directamente un medio para hacerlo, a través del comando “sh” desde la shell limitada, pero esto nos solicita una contraseña que es totalmente desconocida para nosotros. Aquí empieza realmente el trabajo duro, ingeniárselas de algún modo para poder acceder debajo, aunque sólo sea una vez, y poder echar un vistazo desde una shell completa. No voy a detallar, por cuestiones de seguridad, como logré ese primer acceso, pero sí de que se trata.

Presuponemos que tenemos Linux debajo, con lo que realmente lo primero que desearíamos sería echarle un ojo al archivo /etc/passwd y/o /etc/shadow. Estos dos archivos, en linux, son los que contienen las credenciales de los usuarios y sus contraseñas (cifradas claro está). Pero además contienen la shell que será ejecutada a cada usuario. Es posible que el router posea otro usuario/contraseña que desconocemos o a saber…

Pongamos que gracias a la interfaz web logramos ejecutar de algún modo algún comando dentro de la shell y sacar los datos por el navegador. “cat /etc/shadow” cat /etc/passwd” sería sin duda alguna las primeras pruebas, y pongamos que en un momento dado la interfaz web nos devuelve lo deseado, nada para shadow, y para passwd:

1234:$1$$xxxxxxxxxxxxxxxxxxxx:0:0:root:/:/bin/cmdsh
admin:$1$$xxxxxxxxxxxxxxxxxxxx:0:0:root:/:/bin/sh
supervisor:$1$$xxxxxxxxxxxxxxxxxxxx:0:0:root:/:/bin/cmdsh
samba:$1$$xxxxxxxxxxxxxxxxxxxx:500:500:Linux User,,,:/home/samba:/bin/sh

Bingo!! (de nuevo). Parece ser que además de existir un cuarto usuario, samba, el usuario 1234 y el usuario supervisor (que son los dos únicos que tienen acceso por shell) ejecutan una shell extraña llamada “cmdsh”. Sea como sea, si logramos ejecutar con suerte cat, podríamos igualmente intentar sobrescribir el contenido del archivo, igual no existe una protección contra escritura… como dicen, probar no cuesta nada… usando incluso de nuevo cat, se puede enviar el mismo archivo pero modificando la shell a ejecutar, en vez de /bin/cmdsh, /bin/sh. Lanzamos la petición, volvemos a lanzar otra para ver el contenido y… se ha modificado!!. Ejecutemos de nuevo una sesión Telnet/SSH, usuario 1234 (es al usuario que le cambie la Shell), su contraseña… y efectivamente no más shell limitada:

login as: 1234
1234@192.168.1.1’s password:
# ls
bin      boaroot  dev      etc      lib      linuxrc  proc     sbin     sys      tmp      userfs   usr      var
# uname -a
Linux MitraStar 2.6.36 #1 SMP Thu Aug 13 14:04:19 CST 2015 mips unknown
#

 Llegados a este punto ya lo tendríamos todo?? Sí y no. Esto habría que repetirlo siempre, porque si reiniciásemos el router veríamos que el cambio que habíamos realizado al archivo passwd se perdería, teniendo que repetir todo el proceso constantemente. Aun así al menos ya habríamos logrado acceder a la Shell de debajo con plenos permisos administrativos. ¿Podemos mejorar esto? Por supuesto.

Lo primero que viene a la cabeza es: Bien, puedo acceder gracias un exploit, pero parece ser que la shell cmdsh tenía un comando “sh” que solicitaba una contraseña para acceder, y no hay que ser muy listo que lo que permite es acceder precisamente a una shell completa. ¿Donde puede estar esta contraseña? Personalmente el primer lugar donde miraría, teniendo en cuenta que no parece existir otros usuarios en el archivo /etc/passwd, es en el binario de la propia shell, o sino este sabrá de donde obtenerla, dado que es esta shell la que lo solicita. Ya sabemos donde está, así que sólo tenemos que extraerlo. Esto puede hacerse de mil y una forma, dependiendo de las herramientas que tengamos disponibles claro está en la firmware del router:

-ssh/sftp/ftp/scp
-curl/wget
-netcat/nc
-base64
-usb
-…

Cualquier sistema nos vale para enviar donde queramos el archivo en cuestión y poder manipularlo en condiciones, la elección de un sistema u otro dependerá de las utilidades que tenga la firmware y de lo sencillo o no que nos resulte a nosotros mover los archivos. Una vez tengamos el archivo, tan solo tendríamos que decompilarlo y echar un vistazo rápido. Vamos a lo sencillo, si cuando introducimos a través de sh una contraseña cualquiera recibimos: “Password incorrect !” Podemos empezar buscando por ahí, o mirar directamente las posibles funciones… eso nos lleva al siguiente trozo de código:

diss

Curiosamente, justo unas líneas de ahí encontramos una extraña cadena alfanumérica. Bueno, además de que el código en ensamblador es bastante legible, lo que está claro es que compara un string (lo que introducimos por teclado) con el string “c93vu02jp4z04“. Si la comparación es incorrecta, vemos que salta a la posición 0x00402408 (=contraseña incorrecta), mientras que salta a otra posición en caso de que la comparación sea acertada. Dicho y hecho, tan solo tenemos que verificar que ese string es realmente la contraseña para acceder a la shell completa desde la shell limitada. Y no hace falta decir que efectivamente esa es la contraseña de acceso a la Shell.

Llegados a este punto lo tenemos todo, hemos podido acceder gracias a un exploit, hemos podido extraer la contraseña que nos da acceso a la shell completa, con lo que podemos ya hacer con nuestro router lo que deseemos… ¡No tan rápido! ¿Seguro que ya tenemos total libertad?.

 

Acceso (y modificación) a la “nvram” – Autentificarse

Como vimos en la parte del exploit, y si empezamos a jugar con la shell interna, antes o después nos topamos con un problema bastante importante. Sí, podemos usar todas las utilidades de nuestro router, podemos añadir reglas a iptables, ver el estado de todo, controlarlo todo!! ¿Pero como podemos hacer para que los cambios que hagamos sean persistentes?

Vimos que si intentábamos modificar el archivo passwd este volvía de nuevo a su “ser” al reiniciar. Esto nos dice que al menos la raiz de la firmware está protegida contra escritura de algún modo, y de echo no hay que ser demasiado imaginativo para ir entendiendo que el sistema de archivo del router usa SquashFS, un sistema de archivos de sólo lectura que se monta en cada inicio. Ademeás, si miramos realmente la ubicación de la carpeta /etc tenemos esto:

# ls -la /etc
lrwxrwxrwx    1 1234     root            8 Aug 13  2015 etc -> /tmp/etc

La carpeta /etc desde la cual accedemos a /etc/passwd ni siquiera se encuentra en el sistema de archivos SquashFS, sino que el bootloader/kernel genera el archivo de algún modo en cada inicio, por eso pudimos modificarlo con el exploit entre otras cosas, está fuera de la “prisión” de SquashFS. Se genera en cada inicio, con lo que nuestros cambios se pierden. Pero sabemos que todo no es tan negro, porque en realidad debe de existir una zona o partición donde se puedan inscribir datos y estos sean persistente, o algún sistema para poder hacerlo, ya que a fin de cuenta podemos configurar el router a través de la interfaz web, y los datos son persistentes a cada reinicio. Si cambiamos por ejemplo la contraseña del usuario 1234 dicho archivo al iniciar será diferente al original y reflejará el cambio que hicimos por la interfaz Web. Quizás no podamos modificar el sistema de archivo raiz (lo haremos, pero más adelante), pero cuanto menos en teoría deberíamos de ser capaces de realizar cualquier cambio persistente que permita la interfaz web, y eso como mínimo, porque es de suponer que esté donde esté ese “espacio” contendrá quizás otros datos de interés.

Así es realmente como funcionan la mayoría de dispositivos. Los routers suelen tener una zona llamada nvram (RAM no volatil), que contiene parámetros que pueden ser leídos y almacenados con independencia del sistema de archivos. Esto es necesario para poder realizar configuraciones de cualquier tipo, pero incluso el propio router necesita este “espacio” para poder funcionar y configurarse a sí mismo. En muchos dispositivos es bien conocida la herramienta “nvram”, pero si lo intentamos veremos que aquí al menos no disponemos de una herramienta similar. Así que queda hacer un poco de detective y ver si disponemos de alguna utilidad que nos brinde algo similar.

Como podemos acceder a la shell podemos recorrer rápidamente los directorios donde sabemos que es más que posible que se encuentren: /bin, /sbin, /usr/bin… la mayoría de todas las utilidades podemos conocerlas los amantes de linux y muchas otras deducirlas. Otras en cambio podemos ir directamente probando a ver que pasa. Si no damos con la “tecla”, tenemos otro sistema sencillo para hacernos una idea… si la interfaz web cambia los ajustes, la interfaz web debe de saber o tener idea de como realizar esto. Antes o después llegaremos a la conclusión de que hay ciertos binarios que parecen ser los encargados de manejar todo esto, aquellos que empiezan por “tc” que es el acrónimo de TrendChip. Si nos movemos por las carpetas de la interfaz web (/boaroot) veríamos también rápidamente las referencias constantes a tcwebapi, y mira tu por donde tenemos un binario llamado: “tcapi”. Si lo invocamos:

# tcapi
set unset get show commit save read readAll staticGet

 Parece ser que hemos dado con la interfaz que interactúa con la nvram. Con un poco de paciencia y de estudio aprendemos a usar esta interfaz. tcapi funciona de un modo similar a nvram, con show podemos mostrar lo que deseemos (no existe un show all), pero tenemos que especificar que nodo queremos visualizar. Los nodos son precisamente las etiquetas xml que están dentro de nuestros archivos de configuración. Si miramos nuestro archivo de configuración veremos por ejemplo uno de los primeros nodos, “Wan”, así que “tcapi show Wan” nos devuelve efectivamente todo lo almacenado en ese nodo. Podemos pensar que esto no tiene demasiada utilidad ya que a fin de cuenta tenemos el archivo de configuración, pero no hay que ser muy listo para presuponer que el archivo de configuración es sólo una parte de todo. De echo podemos almacenar los valores que queramos en la nvram existan o no existan en el arcivo de configuración, o modificar cualquier otro.

Si alguien ha usado anteriormente nvram (la utilidad) sabrá que para que los cambios se apliquen hace falta realizar un “commit” y seguido de un “save” si se quiere que los cambios se guarden (aplicar no significa guardar, y viceversa). Aquí tenemos lo mismo. “tcapi save” guarda todos los cambios realizados en la nvram, mientras que “tcapi commig nodo” aplica los cambios efectuados al nodo citado. Cuidado!! Estamos modificando la nvram, si guardamos los cambios y estos han sido incorrectos podemos encontrarnos en que sea necesario resetear el router para que vuelva a sus ajustes por defecto.

Quien llegue a este punto se habrá dado cuenta que, de echo, aunque puede usar show, no puede realizar un save y peor aun, un set, devolverá lo mismo que sucedía cuando intentábamos teclear mtd. El acceso por alguna razón a ciertos comandos, incluso teniendo permisos administrativos y a la shell completos, siguen estando restringidos, hace falta algo más para desbloquear esto. Aquí tendríamos de nuevo que empezar a investigar donde buscar y encontrar esto. Podríamos empezar por cmdsh y encontraríamos referencias a un supuesto archivo llamado “/tmp/Authentication”. Antes o después (grep es un gran amigo), daríamos con el binario /usr/bin/syscmd. Si decompilamos y echamos un ojo llegaríamos pronto a una sección bastante interesante:

auth

Vemos demasiada información, pero todo de gran utilidad. Por un lado vemos que aparece de nuevo el archivo nombrado, pero esta vez precedido de un comando completo, y además curiosamente justo encima vemos un “Correct Key imput. Auth…”. Eso ya nos está diciendo que el sistema parece importarle más que el usuario esté “autentificado” ante ciertos comandos que cualquier otra cosa, y que parece que lo verifica seteando el archivo /tmp/Authentification con authenticated. Podríamos hacer la prueba: “echo authenticated > /tmp/Authentication” y veríamos que funcionan mágicamente a partir de este momento tcapi set/save y otros

Antes de irnos a otro lado, podemos ver igualmente en el trozo desensamblado de nuevo la contraseña de acceso a la Shell, y un “EncryptKey” y un “Account_Common”. Quien haya estado ya jugando con la nvram sabrá que en esta se separan los nodos de otros subnodos con guiones, así que por curiosidad si miramos la información del nodo “Account_Common” con tcapi:

# /userfs/bin/tcapi show Account_Common
EncryptKey=MSTC

El resultado es un string: MSTC, que según aparece en la nvram es un “EncryptKey”. Demasiado cerca del código que hace estar autentificado para no tener nada que ver. Si vemos desde la shell que podemos hacer con syscmd, vemos que existe curiosamente un comando que es authKey, y que efectivamente:

# syscmd authKey
Error!
# syscmd authKey MSTC
Correct key input. Authentication done.

Así que en realidad el proceso “real” implicaría autentificarse a través de syscmd con la EncryptKey almacenada en la nvram, MSTC, y eso a su vez produce que el sistema setee el archivo anteriormentes citado. Así que en realidad podríamos realizar la autentificación de cualquiera de las dos maneras: por lo “legal” y a lo “bruto”. Ahora sí, después de esto, podríamos usar algunos de los comandos más particulares (y también peligrosos), como puedan ser: sys memwl, sys memww, sys erase, sys romd, tcapi set, tcapi save…

La nvram permite acceder a todos los parámetros almacenados en nuestra configuración, y además acceder a otros parámetros que podrían ser interesantes, pero eso para otro día. Veamos mejor que más podemos hacer… podemos modificar la nvram, podemos ejecutar cualquier herramienta que tengamos dentro del router, ahora iremos un pasito más, esta vez como poder “modificar” lo que nos queda, el sistema de archivos, e incluso poder instalar/actualizar componentes en ella.

 

Ejecución de comandos desde el archivo de configuración (Nuevo)

Por azares de la vida, me topé días después con que resultaba relativamente sencillo realizar ejecución de código directamente desde el archivo de configuración del router, que no deja de ser gran parte de la nvram. El secreto reside en el nodo “Autoexec”, que si miramos en nuestro archivo tan sólo existe como cierre.

El cfg_manager, por suerte para nosotros, parsea el cfg en cada inicio para cargarlo a la nvram. Al llegar a dicho nodo, si no está vacío, pasa TODO lo que hay en él (sin el nombre de la entrada, sólo los valores de estas) a un archivo llamado autoexec.sh en /etc/, le da permisos de ejecución y acto seguido lo ejecuta. Dicho de otro modo, podemos añadir todo el código que queramos ahí, que será ejecutado al inicio en el Router. Evidentemente de saber esto anteriormente, el proceso de acceso inicial al router hubiese sido mucho más sencillo.

El potencial de esto ya no está realmente en los expertos que sepan modificar la firmware o entrar y salir del Router de forma sencilla, sino que el usuario novel puede de forma sencilla gracias a esto solucionar problemas que pueda tener en el router, o aplica ajustes concretos especiales.

El formato que siguen estas instrucciones es similar al de otros nodos:

<Autoexec>     <Entry
arp_fix=”sysctl -w net.ipv4.neigh.br0.mcast_solicit=0″
dhcp_fix=”echo ‘* * * * * ebtables -D FORWARD -p ipv4 –ip-proto 17 –ip-source-port 67:68 -j DROP’ &gt; /etc/admin; crond -c /etc/” />
</Autoexec>

Ese por ejemplo sería el bloque modificado para realizar dos fixs a la firmware B21, uno el problema de la batería y otro el problema que posee el router que bloquea todo el tráfico DHCP que no sea el suyo propio. Es sólo un ejemplo sencillo, en realidad podríamos realizar casi cualquier cosa. Como vemos la entrada en sí no importa su nombre, es su contenido el que será pasado al archivo autoexec.sh. Tan sólo hay que añadir el bloque que queramos, guardar, cargar la configuración y solucionado.

 

 

Modificando el sistema de archivos raíz

El router usa como hemos dicho SquashFS para montar su raíz. El problema que esto nos origina es que no podemos realizar cambios en él directamente. Para poder hacer esto, en principio, lo que se necesita es modificar directamente la imagen SquashFS con los cambios que deseemos y volver a cargarla. En un sistema más potente o con otras herramientas podríamos incluso pensar hacer el proceso directamente bajo la misma shell, pero aquí estamos limitado tanto en espacio, herramientas y memoria del router, con lo que esta opción no es muy viable. La opción que nos queda es realizar la modificación fuera del router, y volver a escribir el sistema de archivos de vuelta al router.La teoría en realidad es sencilla, la práctica es algo más complicada porque hay que ver como podemos hacer esto.

A priori se me ocurren dos formas. Una, extrayendo en la partición que se encuentre (en caso de ser así) el sistema de archivos, modificarlo, copiarlo de nuevo dentro y volver a copiarlo a su partición con dd/mtd (lo cual puede resultar bastante peligroso si hacemos algo mal y tampoco tengo claro que pueda realizarse sin hacerlo desde el bootloader), o aprovecharnos del propio sistema de actualización de firmware del router, es mucho más seguro pero implica conocer bastante bien como es la imagen de actualización, para poder no solo modificarla, sino también hacer que el router la acepte. Yo he tomado la segunda opción, no quiero tener que llamar a Movistar para decirles que misteriosamente el Mitrastar ha muerto.

Dicho esto, se abren por desgracia una serie de puntos que pueden ser “largos”, pero necesarios. Si queremos modificar la firmware, lo primero que necesitamos es precisamente al firmware, el binario de actualización, y dado que las actualizaciones se realizan por telecarga puede no ser tan sencillo tener una copia de ella, a menos que conozcamos a algún amigo de un amigo que buenamente nos la suministre. Por suerte… hoy tenemos respuestas y medios para todos.

 

Estructura interna de las particiones de memoria

Antes que nada hay que “estudiar” como está organizada la memoria flash del router, hay que ver realmente que particiones hay:

# mount
/dev/mtdblock3 on / type squashfs (ro,relatime)
proc on /proc type proc (rw,relatime)
ramfs on /tmp type ramfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
usbfs on /proc/bus/usb type usbfs (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
# cat /proc/mtd
dev: size erasesize name
mtd0: 00020000 00020000 “bootloader”
mtd1: 00020000 00020000 “romfile”
mtd2: 0014e7e3 00020000 “Kernel_main”
mtd3: 01090000 00020000 “Rootfs_main”
mtd4: 00006292 00020000 “Defcfg_main”
mtd5: 01d40000 00020000 “Tclinux_main”
mtd6: 0014e7e3 00020000 “kernel”
mtd7: 010b0000 00020000 “rootfs”
mtd8: 00006292 00020000 “defcfg”
mtd9: 01d40000 00020000 “tclinux”
mtd10: 00020000 00020000 “romd”
mtd11: 00020000 00020000 “second_romfile”

Con eso tenemos una visión más que completa del mapa del router, de como se compone internamente.Efectivamente comprobamos que la partición raiz es SquashFS, las particiones /sys, /proc son las habituales. A parte de ello se monta una partición como “ramfs” que como vimos contenía el archivo /etc/passwd, y por otro lado uan con el extraño nombre “usbfs”… es posible que el router tenga internamente puertos USB después de todo, y de echo la interfaz tiene configuraciones para SAMBA.

Lo que se refiere al particionado de la Flash, vemos hasta 12 particiones, y por suerte para nosotros los nombres son relativamente descriptivos. Vemos además que las particiones mtd2-5 estan duplicadas, o al menos eso parece, lo que nos hace pensar en un sistema de doble imagen, muy usado en los sistemas para evitar una mala actualización. Bootloader, kernel, rootfs y rom/cfg parecen evidentes su contenido, mientras que tenemos otra partición algo más extraña con el nombre de tclinux. El tamaño de las diferentes particiones también nos dan otra idea, siendo tclinux la partición más grande con diferencia, más que la suma de las demás, lo que posiblemente nos indique que tclinux es de algún modo “todo”, y de echo, lo es.

Pero pongamos por caso que tenemos la imagen de actualización, nos será más sencillo para explicar su estructura, y más adelante veremos como poder extraerla si queremos desde el router, que es secundario.

 

Estructura de la imagen de la firmware

Actualmente tan sólo existe una firmware completamente oficial, la B14, aunque la B21 se ha distribuido a muchos usuarios debido a los problemas ocasionados por la B14:

Mitrastar b14 113WJI0b14.bin b79d53bb663cbae480532942cc0e961a
Mitrastar b21 113WJI0b21.bin 770a5a52069066dc87978dba949cb1fd

Tomemos la segunda por caso. En lo personal, me gusta siempre antes de cualquier otra cosa, echarle un vistazo a través de un editor hexadecimal a ver que veo. Haciendo un barrido sin demasiada observación, vemos en primer lugar lo que parece claramente una cabecera al comiendo de la imagen, y curiosamente al final de todo el archivo nos encontramos también que termina con “</ROMFILE>” que es precisamente como termina también nuestro archivo de configuración. Si hacemos una pequeña búsqueda con esto, podemos localizar también el inicio de esta parte, que parece que tiene una pequeña cabecera que lo precede especificando que está comprimido y el tamaño que posee, eso lo vemos en el offset 0x011d27d6.

firmware

Como sabemos también que se supone es una imagen SquashFS, podemos buscar su cabecera y ver si se encuentra alguna correspondencia, buscando por los valores “68737173”, y sí… encontramos también una correspondencia de este en el offset ox0014e7e3, que termina de echo justo cuando comienza el archivo de configuración antes citado. Con esto tenemos prácticamente, y sin necesidad de usar ninguna utilidad, el contenido completo de la firmware (aunque queda ver y analizar aun unas cuantas cosas). Lo único que nos queda es una parte, que se encuentra después de la cabecera y antes de la imagen squashfs. Teniendo en cuenta que tenemos la información anterior de las particiones mtd, la respuesta es evidente: Es el kernel. Recordemos que en las particiones teníamos 3 en concreto que estaban duplicadas con el mismo nombre, con la única diferencia a priori de que las particiones más bajas tenían la coletilla main. Bien, por pura lógica asociamos defcfg al archivo de configuración que hemos encontrado, roofs a la imagen squashfs y el otro pedazo que nos queda es el Kernel. Además, como tenemos el tamaño de las particiones vemos también que efectivamente, si dividimos cada parte independientemente, corresponden sus tamaños a los tamaños de las particiones (ojo que dado que el tamaño de erasesize es de 0x00020000, el espacio de las particiones es múltiplo siempre de este valor, con lo que el tamaño excedente se rellena). Con este pequeño análisis, podríamos ya extraer la imagen squashfs a nuestro equipo, y a priori modificarla como nos diese en gana, volver a crear la imagen squashfs y ver como poder volver a montar la imagen de actualización con todo sin romper nada.

 A partir de aquí, tendríamos el trabajo farragoso. Es necesario comprender las cabeceras, el contenido tan sólo es lo sencillo. Diseccionar las cabeceras es un trabajo más meticuloso y estar haciendo comprobaciones, sumas, cuentas, mirar binarios del router en busca de más información… es tedioso. En mi caso empiezo siempre desde el comienzo, identifico lo que parecen ser los “Magic Number”, cadenas de texto descriptivas que pueden indicar versiones, conjuntos de bytes que indiquen tamaños y desplazamientos, checksums… en definitiva, lo que se puede esperar de cualquier cabecera. Diseccionar totalmente la cabecera (las dos que hay) fue lo que más tiempo me llevó. Os desgloso lo que sería la estructura integral de la firmware, incluyendo por supuesto la estructura de su cabecera. Digamos que la imagen de actualización se compone de tres “partes”. La cabecera, la firmware en sí (compuesta de kernel+rootfs/sistema_archivos) y el archivo de configuración:

0x00000000 Header
    0x0000 Cabecera “Magic Number” 04 D0 FC 9C
    0x0004 chipID = “36 33 33 36 38 00 00 00” = 63368 (8Bytes)
    0x000C Padding (16 Bytes)
    0x001C ModelID = 5A596004 (4Bytes)
    0x0020 Tamaño total archivo .bin, incluído cabeceras (4Bytes)
    0x0024 Offset en Memoria rootfs (0x40000 + offset bin) | 0x40000 = Bootloader 0x20000 + romfile 0x20000
    0x0028 Tamaño Rootfs (4Bytes)
    0x00CC Offset en Memoria Kernel
    0x0030 Tamaño Kernel (4Bytes)
    0x0034 Offset en Memoria cfgfile
    0x0038 Tamaño cfgfile (4Bytes)
    0x003C ¿Magic Number?? 01 00
    0x003E Tipo de imagen | main (0x0003),  esclava (0x0002), bin de actualización (0x0001)
    0x0040 Versión Firmware (32Bytes)
    0x0060 Descripción Firmware (32Bytes)
    0x0080 Checksum Rootfs (4Bytes)
    0x0084 Checksum Kernel (4Bytes)
    0x0088 Checksum cfgfile (4Bytes)
    0x008C Padding

0x00000100 Firmware
    0x00000000 Header
        0x000 Cabecera “Magic Number” 32 52 44 48 (4Bytes)
        0x004 Tamaño de cabecera (4 Bytes)
        0x008 Tamaño de la “Firmware” incluyendo su cabecera
        0x00C checksum SquashFS, las particiones _main no llevan CRC, la firm no lo computa en cualquier caso.
        0x010 versión de 2rdh?? Termina con salto de linea (32Bytes)
        0x030 “Salto de linea”/padding (32Bytes)
        0x050 Offset squashfs/tamaño kernel (4Bytes)
        0x053 Tamaño squashfs (4Bytes)
        0x058 Padding
        
    0x00000100 Kernel, lzma
    0x0014e6e3 rootfs Squashfs 4.0 lzma | Sistema de archivos

0x011d27d6 Configuración romfile
    0x0000 Header
    0x0028 romfile comprimido.  ¿Algoritmo fastlz?

 

 Modificación/Creación de una firmware nueva

Bien, teniendo toda la estructura de la imagen de actualización, debería de ser trivial realizar cualquier cambio (añadir, eliminar, modificar) dentro de la firmware. Con linux tan sólo necesitaremos tener las herramientas para crear y extraer squashfs, teniendo en cuenta que la imagen original fue creada en SquashFS 4.0+, usando la compresión LZMA. Esto significa que si no usaron un SquasFS modificado tuvieron que usar SquasFS 4.1, 4.2 o 4.3, ya que hasta la versión 4.1 no se dio soporte oficial a LZMA. Yo lo he realizado todo con SquasFS 4.3, usando como compresor LMZA el SDK de 7zip. Es necesario eso sí, modificar el makefile para habilitar lzma.

Extraída la imagen en nuestro equipo y modificada a voluntad (o añadido los archivos/paquetes que deseemos…) volvemos a empaquetar nuestra imagen squashFS. De nuevo, recordemos que debemos de usar LZMA y realizar la creación sin el padding a 4K. Llegados a este punto, como tenemos toda la estructura de como tiene que la estructura de la imagen de actualización, tan sólo tenemos que realizar el proceso inverso y corregir todas las cabeceras que sean necesarias. Sería muy sencillo crear una pequeña utilidad que pasándole la imagen modificada, el kernel y el archivo de configuración nos crease el archivo final de actualización con todas las cabeceras corregidas. Pero ni he tenido tiempo ni tengo ganas de hacerlo. Así que sigamos.

Con la imagen SquashFS ya modificada, podemos empezar a empaquetar nuestra nueva imagen de actualización. Por suerte para nosotros, la cabecera de la sección perteneciente al kernel+rootfs no se verifica en ningún momento, y aunque podemos por supuesto calcularla, no es necesario ser muy rigurosos. La parte más tediosa es el cálculo del checksum, así que podemos establecerlo tan ricamente como “00 00 00 00” y no pasa nada.

Añadimos al final de la imagen squashfs el archivo de configuración previamente extraído de la imagen inicial. Añadimos encima de este el kernel, y encima del kernel la cabecera secundaria. No es necesario, pero por tener un mínimo de decencia corregimos en esta el tamaño de la “firmware” (que es el tamaño de la cabecera secundaria+kernel+squashFS), el checksum no nos complicamos y lo dejamos en 00 00 00 00, el offset de squashfs no ha cambiado con lo que lo dejamos igual y modificamos el nuevo tamaño que tiene nuesetra imagen squashfs (ahora sí, tan sólo el tamaño de nuestro squashfs modificado)

Por último queda realmente lo que es más delicado, que es reconstruir realmente la cabecera que va a judgar si nuestra firmware es válida, por no decir que si metemos la pata siempre podemos bloquear e inutilizar el router, así que cuidado aquí. Los valores a modificar en realidad son pocos, si tan sólo hemos tocado el sistema de archivos:

    0x0020 Tamaño total archivo .bin -> Es necesario modificarlo porque el tamaño de nuestro squashFS será diferente
    0x0028 Tamaño Rootfs -> El valor es el mismo que se puso en la cabecera secundaria, y hay que modificarlo por lo mismo que el anterior
    0x0034 Offset en Memoria cfgfile -> Al cambiar el tamaño del rootfs, el offset del archivo de configuración cambia. Recordemos que hay que sumar siempre 0x40000
    0x0080 Checksum Rootfs (4Bytes) -> Que checksum??

Bien, tenemos todo menos el checksum de rootfs, el resto son los mismos porque no hemos realizado ninguna modificación. La pregunta del millón es como diablos calcula Mitrastar este valor, puesto que ha podido usar cualquier técnica conocida o desconocida. La mala noticia es que usa un algoritmo propio para calcularlo, la buena noticia es que ya lo tengo recreado, y la mejor noticia es que incluso nos podemos ahorrar su cálculo si sabemos donde mirar (una pena que descubriese esto último más tarde, pero al menos tengo igualmente el algoritmo.

El checksum usado por Mitrastar es una modificación al conocido CRC32, usando una lockup table para agilizar los cálculos, y podemos encontrarlo en el binario cfg_manager. Se puede buscar la función y decompilarla. Es necesario este valor porque el bootloader y el propio cfg_manager comprobarán dicho valor, y si no corresponde al que ellos calculan, el router rechazará dicha imagen. No sólo se usa este checksumo para verificar la firmware, igualmente se verifican tamaños y otros, pero ya hemos dado por supuesto que la cabecera la hemos calculado bien.

Bien, he dicho que aunque tengo creado el algoritmo para calcular el crc32 modificado no es necesario. Esto es porque por suerte para nosotros ya lo calcula el cfg_manager por nosotros. Cuando actualizamos el router (o lo intentamos), justo antes de que este se reinicie (sea la firmware válida o no) escupe en la consola de registro los cálculos pertinentes, sacando por pantalla los checksum calculados y los que tenemos en nuestra firmware. Dicho de otro modo… si actualizamos aun con la cabecera con los checksum incorrectos, y mientras esta el proceso miramos el registro con dmesg, obtendremos algo como esto:

***** MitraStar Confidential Firmware *****
compressedLen = 25194
pTag->kernelChksum = 11b8cc8b
pTag->rootfsChksum = da3878fa
pTag->defcfgChksum = 35842e0b
cal kernelChksum = 11b8cc8b
cal rootfsChksum = da3878fa
cal defcfgChksum = 35842e0b

pTag->modelId = 5a596004
pTag->chipId = 63368
len = 011d8a68
mrd->modelId = 5a596004
mrd->chipId = 63368

Update slave image version

Ready to flash image…

Si los checksum calculados no se corresponden a los nuestros, el proceso fallará, pero podremos anotar el crc calculado, modificar los nuestros para que correspondan y volver a actualizar. Eso le quita a cualquiera tener que decompilar el código en cfg_manager, extraer el algoritmo de verificación y recrearlo en C o en el lenguaje que le guste. Por supuesto el echo de que se calcule el CRC no hay que verlo sólo como para impedir que se realicen modificaciones, sino para garantizar la integridad de estas y evitar una mala actualización.

Si todo ha ido bien, el cfg_manager copiará la imagen de actualización a 4 particiones esclavas, mtd6-9, cada una con su contenido. Al reiniciar el router, el bootloader realizará comprobaciones similares a las realizadas por cfg_manager, y si todo es correcto procederá a copiar las particiones esclavas mtd6-9 a las principales mtd2-5. Si el router se reiniciase (funcionando) sin aparentemente ningún cambio efectuado, posiblemente el bootloader encontró algún problema en la firmware modificada y anuló la copia a las particiones principales, con lo que habría que ver el problema, solucionarlo y volver a cargarla.

Si todo ha sido correcto, llegados a este punto, tendríamos nuestra propia firmware modificada con lo que necesitásemos, ya fuesen arreglos de los problemas que tiene la firmware oficial o nuestros propios añadidos.

Recordemos que dije que no es necesario tener una imagen de actualización. Podemos extraerla a partir de las particiones mtd5 o mtd9, tan sólo con una apreciación: Las particiones mtd5 y 9 estarán posiblemente padeadas para rellenar el resto del erasesize, con lo que hay que eliminar dicho bloque. Por otro lado hay que modificar un byte en la cabecera que especifica el “tipo de partición”. El archivo de actualización tiene que estar en 01, no en 02 o 03. Quitando estos dos cambios, el resultado será una copia 1:1 (exacta) del archivo de actualización original. No es mal truco después de todo.

 

¿Instalación/Actualización de componentes y otros paquetes?

Ahora mismo no he añadido ningún componente extra, pero es más que factible. Hay que tener en cuenta que el router usa una arquitectura MIPS, y que tendríamos que recompilar cualquier paquete o binario para esta arquitectura. Aquí la idea he de decir que no fue mía y me llegó leyendo a un blogero en algún lado, y es que el router usa uClibc como motor, y el proyecto uClibc posee por suerte para nosotros imágenes listas para iniciar desde linux en las que podremos tener las herramientas necesarias para compilar el códígo y paquetes que deseemos, y una vez realizado sacarlo de ahí y meterlo en nuestra firmware modificada:

http://www.uclibc.org/downloads/binaries/0.9.30/


 

Conclusión

Bien, creo que eso ha sido todo. Sin duda alguna un buen entretenimiento del que siempre se aprende, y yo el primero. Quizás lo más útil en este caso no es instalar paquetes o actualizar otros (al menos en principio), pero puede que sí lo sea el poder realizar pequeños cambios aquí y allá, instalar algunos binarios extras como tcpdump, aplicar configuraciones específicas, filtros… tenemos espacio en memoria de sobra a fin de cuenta, y posiblemente tardemos nosotros mismos menos tiempo en corregir algunos de los problemas de la firmware, que esperar que Mitrastar los arregle por nosotros y que Movistar la distribuya.

Por ejemplo, para corregir el problema de la batería de los ARP en la B21, bastaría en principio con hacer el siguiente cambio permanente:

echo 0 > /proc/sys/net/ipv4/neigh/br0/mcast_solicit

Aunque como digo, tan solo es un ejemplo más…

La cadena de texto “de la muerte” de iOS y OSX: سمَـَّوُوُحخ ̷̴̐خ ̷̴̐خ ̷̴̐خ امارتيخ ̷̴̐خ

Share on Google+Share on FacebookTweet about this on Twitter

Por desgracia no he tenido tiempo antes para hablar sobre la ya famosa “cadena de la muerte” que afecta a los productos de Apple, así que aprovecho para dedicarle unas cuantas letras a ello, puesto creo sin duda alguna que merece la pena por lo absurdo del caso. Pero antes que nada hagamos un poco de recapitulación para aquellos que no saben nada de ello.

¿Algún usuario de iPhone ha observado últimamente que sus aplicaciones se cierran sin mucho sentido?

Hace ya más de 6 meses, expertos de seguridad reportaron a Apple un fallo crítico en sus sistemas operativos, tanto iOS como OSX, afectando en ambos casos incluso sus versiones más actuales. El fallo provoca un ataque de denegación de servicio (DoS) producido por el motor de renderizado de texto del sistema operativo ante una cadena unicode concreta: “سمَـَّوُوُحخ ̷̴̐خ ̷̴̐خ ̷̴̐خ امارتيخ ̷̴̐خ”. En términos profanos, cada vez que cualquier dispositivos de Apple (iPhone, iPod Touch, OSX…) tiene que renderizar (dibujar/interpretar) en pantalla dicha cadena de texto (pues usa el motor de texto del OS), la aplicación que esté en primer plano que esté accediendo a dicho texto se cerrará. Si mandamos un WhatsApp con dicha cadena, el usuario de iOS no podrá abrir WhatsApp (por poner un ejemplo sencillo)

En primer lugar, encontrar un fallo en cualquier aplicación que pueda producir un DoS en ella, no es algo demasiado extraño. Encontrar un fallo en un OS que pueda producir un DoS en él es algo que suele ser mas extraño pero todos los años solemos tener unos cuantos. Lo que realmente hace peculiar este fallo (y de ahí su gran importancia) es el método para “dispararlo”, puesto que tan solo es necesario una sencilla cadena de texto unicode que cualquiera puede enviar, copiar/pegar… o hacer el uso que sea de ella. No es necesario dispararlo por medio de un exploit complejo, no es necesario un conocimiento avanzado informático, no es necesario ser un experto… cualquier persona puede producirlo en un dispositivo objetivo, sencillamente haciendo llegar al objetivo dicha cadena de texto. Tan simple como eso.

En segundo lugar, otra cosa que hace de este fallo crítico en los productos de Apple algo tan severo, es la inacción por parte de Apple (como de costumbre) ante un fallo de seguridad o de cualquier otra índole en su software y sistema operativo. El error fue reportado hace más de 6 meses, 6 meses en los que cualquiera ha podido estar explotando dicha vulnerabilidad a su antojo. Pero aun peor que todo ello, es que después de que hace una semana saltara en todos los medios de noticias, Apple sigue sin hacer absolutamente nada, siendo afectados todas las versiones de iOS (exceptuando la beta de iOS 7) y prácticamente todas las versiones de OSX.

Para cualquier usuario de iOS (y mayoría de OSX) no pueden hacer sencillamente nada. Si el texto es puesto en cualquier sitio y sus dispositivos lo reciben, la aplicación que lo muestre en pantalla se cerrará sin remedio alguno. Esto es un problema, porque incluso el simple echo de escribir un artículo con ello, provocará que a los usuarios de iOS/OSX se les cierre el navegador web si abren mi blog. Para tener constancia de la gravedad de ello, voy a exponer unos sencillos ejemplos y el efecto que tendría en los dispositivos de Apple. Otro gran problema de todos los ejemplos que veamos, es que el usuario de Apple ni siquiera será consciente de que ha pasado o porqué sus aplicaciones no funcionan correctamente.

-En una página web

El navegador del dispositivo se cerrará cada vez que se intente acceder a dicha web, puesto que la cadena de texto hará por mostrarse en él. La única solución pasa por no acceder a dichas webs, lo cual es complicado, cualquier webmaster podría poner la cadena de texto en cualquier parte de su web/blog/foro… En este caso el ataque sería indiscriminado, no iría dirigido concretamente a nadie.

-En un correo electrónico

En el caso sencillo, bastaría incluir la cadena de texto en el cuerpo de cualquier correo electrónico dirigido a cualquier usuario de Apple. Este al abrir dicho corro provocará que el gestor de correo electrónico o el navegador web (en caso de acceso por web) se cierre.

Un caso más maligno de este sería usar dicha cadena de texto como asunto y no como cuerpo de mensaje. En este caso, dado que los gestores de correo y los webMail tienen a mostrar directamente el asunto del mensaje SIN NECESIDAD de abrir el correo, sería suficiente de nuevo para provocar el cierre del navegador web o del gestor de correo.

Usado de forma “maligna”, cualquier usuario de forma muy muy sencilla podría dejar inutilizable de un modo efectivo el gestor de correo de los usuarios de iOS o de OSX (puesto que por lo general el asunto se muestra directamente lo cual provocaría el cierre de la aplicación), y de forma menos agresiva también el navegador cuando se acceda por webMail

En este caso, tan solo sería necesario conocer el correo electrónico del usuario al que dirigirse.

-Facebook, Twitter, Google+…

Independientemente de si se accede a estas aplicaciones desde una aplicación móvil o desde el navegador, parece evidente pensar que pasaría si se publicase en las redes sociales dicha cadena de texto, y el efecto que tendría a todos los usuarios de Apple. Este pensamiento no son pocos los que lo han tenido… y muchos los que lo han hecho. Así pues, son muchos los que han twitteado el mensaje, haciendo que a los usuarios de Apple les fallase tanto la aplicación como e navegador web al intentar visualizar dichos Twitts.

En caso de Facebook, estos bloquearon prudentemente la posibilidad de poder escribir dicha cadena de texto de forma directa, pero existen multitud de formas de evadir este sistema, como por ejemplo estableciendo manualmente como ubicación de la publicación la cadena de texto, pero las opciones son múltiples. La cuestión siempre es la misma, cuanto más ingenioso se sea a la hora de exponer la cadena de texto…

En este caso, se podría usar las redes sociales sin tener un objetivo concreto, o por supuesto bastaría con poder enviar un mensaje o publicar lo que fuese en el perfil del usuario.

-HangOut, SMS, WhatsApps…

A nadie se le escaparía tener en cuenta la mensajería instantánea y los SMS. En estos casos posiblemente el vector de ataque sería mucho peor.

En el caso de los SMS el daño a provocar es evidente, tan solo basta con mandar un SMS a cualquier iPhone para bloquear de forma sencilla la aplicación iMessage del dispositivo. Si la aplicación realiza un pequeño preview del texto maligno, será suficiente para provocar el cierre de la aplicación, y de volver a intentarlo el resultado sería el mismo. En este caso tan solo sería necesario tener el número de teléfono de la persona a afectar.

En el caso de WhatsApp las opciones son múltiples. En primer lugar sería suficiente con mandar un WhatsApp a cualquier dispositivo. Esto provocaría que al abrirse (o incluso en la previsualización) fuese suficiente para provocar la inutilización de WhatsApps. El usuario se vería forzado a tener que reinstalar WhatsApps en algunos casos. Otra opción de WhatsApps sería establecer el texto como mensaje de estado, un sistema pasivo que provocaría que cualquier usuario que nos tuviese en su lista de contactos (usuario de iPhone) no pudiese acceder a su lista de contactos, puesto que cargaría nuestro estado y de este modo WhatsApp se cerraría. Como tercera opción en WhatsApp, y la más efectiva, pasaría por crear un grupo de WhatsApp y establecer en su nombre el texto dañino. Dado que los grupos se regrean aun cuando WhatsApp se reinstala, a cualquier atacante le bastaría el número de telefono de cualquier usuario con iPhone para crear un grupo de WhatsApp, establecer el nombre a la cadena de texto dañina y añadir a dicho miembro al grupo. Dado que el nombre del grupo es visible en la lista misma de WhatsApp, el usuario de iPhone no podría abrir WhatsApp, y aun cuando reinstalase los grupos se recrearían igualmente, haciendo muy complicado evitarlo. De este modo se quedaría totalmente inutilizada la aplicación, se cerraría nada más abrirla constantemente.

En realidad, cualquier sistema de mensajería instantanea los efectos serían similares. La diferencia quizás radica en quien puede o no mandarnos mensajes. En el caso de los SMS por ejemplo, cualquiera con nuestro teléfono puede mandarnos uno. En caso de WHatsApp cualquiera con nuestro número puede hacerlo… esto hace de este fallo de Apple un problema en mayúsculas sin duda alguna.

 

Podríamos expandir la lista todo lo que quisiésemos. Desde establecer el SSID de nuestra red WIFI al texto en cuestión y ver que le ocurre a los iPhone cercanos, códigos QR, firmas… en realidad cualquier sitio donde podamos escribir un texto en unicode y que vaya a ser leído por el usuario en sus pantallas.

Lo peor de todo ello como ya he dicho, es que al contrario de otros fallos de seguridad, en este caso puede dispararse el error sencillamente con una cadena de texto, lo cual no solo hace que el vector de ataque sea increiblemente grande, sino que cualquiera puede explotar esta vulnerabilidad. Si a eso le sumamos que Apple continúa sin solucionar este problema que se conoce desde hace más de 6 meses…

Cada cual que haga sus propias conclusiones… o pruenas

Un saludo amigos, y ser buenos… no seamos demasiado… “traviesos” con los fanboys 🙂

Evento de Google del 24 Julio: Nuevo Nexus 7, Android 4.3 y Nuevo dispositivo ChromeCast

Share on Google+Share on FacebookTweet about this on Twitter

El Google IO 2013 dejó claro que iba a ser orientado casi en su totalidad para los desarrolladores, y quitando Play Services no se anunció ningún producto ni actualización de los ya existentes. Quizás el motivo fuese que este año el Google IO se celebró casi un par de meses antes que el año pasado. Dicho así, era lógico pensar como dijimos muchos que Google lanzaría novedades en Julio, y así han sido. Fundamentalmente han sido 3 novedades en las que se ha centrado toda la conferencia: El nuevo Nexus 7, Android 4.3 y como sorpresa ha sido un dispositivo que han bautizado como “ChromeCast”.

Por supuesto, Google a aprovechado para recordar que las ventas de este último año de Android son superiores al doble del año pasado, que el dinero que se ha pagado a los programadores de aplicaciones estos últimos meses es de 2.5 veces superior al año pasado. Realmente no son números para obviar.

 

Nexus 7

Hace un año Google presentó el que sería el primer Tablet con su sello, el N7. A día de hoy ha resultado ser un éxito indiscutible, un hardware más que capaz a un precio que la competencia podía siquiera acercarse. Un año más tarde, era evidente que Google tenía que mejorarlo… y así ha sido.

-Mismo tamaño, 7,02 Pulgadas, pero no obstante se pone a dieta, ahora es ligeramente más estrecho (conservando el mismo tamaño de pantalla), un pelín mas alto, pero sobre todo más delgado y pesando menos.

-Pantalla FullHD! Si el N7 original ya tenía una gran pantalla HD Ready de 1280×800 con 216ppp, han dado un salto significativo al emplear una pantalla FullHD de 1920×1200, con 323 ppp. Es interesante anotar que Apple llamó originalmente “Pantallas Retinas” a cualquier pantalla con una densidad superior de 300 ppp porque según ellos el ojo humano no era capaz de percibir algo mejor. El iPad 4 actual, llamado retina, posee una densidad de 264 ppp (lo que estrictamente según la definición que Apple daba a sus pantallas Retina, no es Retina). Bien, pues como digo el nuevo N7 tendría una densidad de 323 ppp (El N10 actual posee 300 ppp).

-Incorporación de cámara trasera de 5MP: Muchos se quejaron inicialmente por no poseer una cámara trasera (yo personalmente es algo de lo que podría prescindir, quiero una cámara frontal para videoconferencia, pero no voy a ir haciendo fotos con un tablet). Aun así han implementado una cámara de 5MP traseras para completar aun más el dispositivo.

-CPU/GPU: También se ha modificado el Procesador, y se ha implementado el mismo que usa actualmente el Nexus 4, un SnapDragon Pro 8086 de 4 núcleos a 1.5 GHz, frontera con los Cortex-A15. Según afirma Google, el procesador sería aproximadamente un 50% superior a su predecesor, y hasta un 150% superior que su predecesor gráficamente, en conjunción de Adreno 320. Es decir, que no solo de pantalla vive el hombre. Esto es totalmente lógico. Muchas veces se olvida que el poseer una pantalla con mayor resolución implica tener que trabajar el procesador y la GPU mucho más. No es el caso, pero muchas veces incluso aun aumentando el procesador y la GPU un producto nuevo puede ser más lento que su antecesor por tener una pantalla superior.

-Batería: No tengo los datos de capacidad de la batería actualmente, creo qeu es la misma que su antecesor, pero han mejorado el consumo. Según claman, es capaz de estar reproduciendo sin parar durante 9 horas seguidas contenido en HD.

 -Por último, posee conector HDMI para su conexión a la televisión.

Si lo comparásemos actualmente con el iPad Mini, esto es lo que tendríamos:

Nexus7

El Nexus 7 anterior, que salio a la venta 6 meses antes que el actual iPad Mini, ya era superior al iPad Mini, con lo que es evidente decir que el actual Nexus 7 es muy superior al iPad Mini actual, y posiblemente lo sea al iPad Mini nuevo que saque Apple este año (si lo saca). Lo Cuadriplica en RAM, lo duplica (que se dice pronto) en densidad de píxeles!! Si pusiésemos una foto de calidad en ambos dispositivos, la calidad de la imagen en el iPad mini sería de chiste en comparación. Repito, es evidente que el iPad Mini actual tiene ya algo más de 6 meses y habrá que esperar al nuevo para realizar otra comparación más, aunque en ese caso será el iPad mini el que lleve una ventaja de 6 meses.

 

Android 4.3

Google está tardando en lanzar su Android 5.0 (Lime Pie), es posible que para que la gran mayoría de dispositivos Android estén usando JellyBean, y lo cierto es que a día de hoy ya se ha confirmado que JellyBean posee una penetración superior a GingerBread, que ostentaba el mayor uso. Eso no quiere decir que Google esté parado, y estoy seguro que Android 5.0 está más que avanzada y casi preparada, y todo el tiempo de más que se le de será para mejorarla aun más. Mientras tanto, mientras que eso ocurre (supongo que se lanzará en Noviembre), Google ha añadido algunas mejoras en Android 4.3, sin realizar cambios demasiado dramáticos. De echo para el usuario final, no notará prácticamente nada nuevo, que no quiere decir que no las use sin saberlo o que no se beneficie de las mejoras.

Google Play Game App: En realidad no forma parte de Android 4.3, pero si de android, y está disponible para todos. Es la aplicación de Google que hará de hub par alos juegos, para centralizar de este modo los progresos de ellos, tablones de puntos, logros… cualquiera puede descargarla si lo desea desde ya.

– Control de permisos para Tablets con múltiples usuarios: Recordemos que Android en las tablets posee (tiene la opción) de tener diferentes perfiles de usuarios desde hace tiempo. Así por ejemplo dos personas podrían tener sus configuraciones totalmente diferentes. Bien, la gran novedad es que podrá existir lo que llamaríamos un “Administrador” que podrá definir el control de acceso y permisos que tendrá otro usuario. Así por ejemplo, no solo podrá definir a que aplicaciones tendrá acceso o no el otro usuario, sino que incluso podrá definir algunos permisos por aplicación incluso. Esto evidentemente está enfocado para tablets como el N7 orientadas a un público más juvenil. Básicamente, estoy viendo al Padre impidiendo que el hijo acceda a juegos que el si puede, películas que el padre no quiere que vea… o simplemente facilitarle el uso al pequeño quitandole todo aquello que él no entendería.

-Soporte para Bluetooth 4.0 Smart, un tipo de dispositivos Bluetooth de muy bajo consumo, generalmente dispositivos biométricos que envían constantemente datos a nuestro dispositivo Android. Básicamente aquellos dispositivos que sean compatibles con BT Smart tendrán un consumo energético mínimo.

-Perfil de Bluetooth AVRCP en su stack de BlueTooth, lo cual permite el control remoto de video y audio por Bluetooth en dispositivos compatibles.

-Soporte para OpenGL ES 3.0: Es otra de esas grandes novedades que solo los programadores apreciarán, y es una sorpresa. OpenGL es junto DirectX las API gráficas más comunes que existen en el mundo. DirectX solo es para Windows por supuesto, mientras que OpenGL posee un soporte completo tanto en Windows,  móviles, Linux, OSX, iOS… OpenGL ES epor otro lado es por así decirlo la adaptación de la API OpenGL en dispositivos portátiles, es un subconjunto de OpenGL.  OpenGL ES 3.0 es la versión más actual, y no hace falta siquiera decir que ni iOS ni Windows Phone son compatibles, incluso el nuevo iOS 7 que aun no ha salido, tan solo es compatible con OpenGL ES 2.0, que es lo que usan el 99% de todos sus juegos. ¿Esto que implica? Implica mejores efectos y realismo en juegos, más facilidad a la hora de programar y mayor rendimiento en cualquier aplicación que haga uso de OpenGL.

-APIs para DRM: En realidad Google lo ha tenido bien organizado todo, y con el lanzamiento del nuevo Nexus 7 con pantalla 1080p y el nuevo dispositivo que hablaremos más adelante, se ve que implementar medidas DRM para películas sobre todo era casi una obligación, que por cierto seguro les ha hecho poner proveedores de películas como Netflix.
 
-Mejoras en la introducción de teclado, posiblemente alguna versión nueva de su teclado para Android, me pregunto si habrán dado ya acceso al selector de temas del teclado que sabemos ya incorpora desde hace tiempo.
-Mayor rapidez en el cambio rápido de usuario (para tablets multiusuarios)
 
-Autocompletado al marcar un número. La mayoría de todos los dialers que traen por defecto los dispositivos Android de los fabricantes poseen este tipo de dialers, en los que puedes llamar escribiendo el nombre o empezando a poner el teléfono. Por fin Google lo implementa, espero que permita también la búsqueda por nombre.
 
-Mejora de la localización WIFI en segundo plano… lo cierto es que no sé exactamente que se han referido con esto, habrá que diseccionar el código fuente y ver los cambios reales al respecto.
 
-Incorporación del hebreo y el árabe (idiomas de escritira inversa) y otros idiomas.
 
En realidad no son cambios de calado, pero si desde luego Google quiere cubrir algunos puntos más deficitarios en su Nexus 7, e incorporar mejoras significativas a los programadores. El precio en cambio es ligeramente superior. En realidad era algo que se veía venir, Google lo iba a tener realmente complicado mejorar los 200€ que costaba el Nexus 7 anterior. Aun así se ha acercado bastante, teniendo en cuenta que en cuanto a hardware hay un gran cambio significativo, posiblemente solo la pantalla ya fuese suficiente para entender ese precio adicional.
 
La OTA para Nexus 4, Nexus 7, Nexus 10 y Galaxy Nexus está ya circulando, así como las imágenes completas de todos ellos en el centro de siempre
De igual modo, los repositorios oficiales AOSP de Google están también terminando de ser rebasados con Android 4.3, lo que significa que cualquier ROM personalizada basada en AOSP será actualizada en los próximos dias (seguramente claro, y siempre que así lo deseen)
 
 

ChromeCast

El invitado especial en esta ocasión ha sido ChromeCast. El año pasado vimos en el lanzamiento del Nexus 7 el novedoso e ingenioso Nexus Q, un dispositivo ciertamente interesante, pero lo cierto es que era extremadamente caro para lo que ofrecía, y aunque su potencial era realmente importante, fue un, podemos llamarlo así y sin paños menores, fracaso. Tampoco hay que olvidar que el Nexus Q ni siquiera llego a estar a la venta masiva, y fue presentado más que nada como un experimento.

12 meses después, Nexus Q es historia. No obstante Google entendió lo bueno que podía resultar Nexus Q en muchas ocasiones, así que tomó lo bueno de Nexus Q, añadió algunas ideas más y busco la forma en la que poder poner todo ello en un dispositivo que merezca la pena comprar (caro o no). Y es evidente que así es como ha nacido ChromeCast.

Técnicamente hablando, ¿que es ChromeCast?

chromecast

Eso es ChromeCast. ES un dispositivo de 5 centímetros similar a un simple PenDrive, con una salvedad que lo hace diferente:

-Funciones de Adaptador WIFI
-Salida HDMI
-Versión de Chrome OS en su interior minimalista y personalizada
-Cuesta 35$

Que tenemos si juntamos todo ello? Es sencillo, un dispositivo que puede conectarse virtualmente a cualquier televisor por HDMI y a la par a nuestra conexión WIFI. ¿Y que hace? Básicamente permite “enviar” contenido de CUALQUIER DISPOSITIVO con independencia de la plataforma usada a la tele. Es decir, es compatible tanto con Android como con iOS como con equipos de sobremesa con Chrome.

De este modo, los usuarios pueden por ejemplo entrar en YouTube en su tablet/movil/PC y simplemente dándole a un botón en su aplicación de YouTube y el contenido empezará a reproducirse en HD en la televisión. Algo tan sencillo en concepto pero que sin duda alguna muchos hemos querido hacer mas de una y mas de dos veces. Todo ello sin configuración alguna de nada, simplemente tener conectado el dispositivo a la tele y conectado a nuestra red. Google ha anunciado que actualmente, ChromeCast permite la “recepción” de contenido desde YouTube, Google Movies, Google Music (música también), Google+ Photos, Chrome, Pandora, Netflix… y por supuesto Google asegura que muchos mas están en camino.

Al anunciar conjuntamente el SDK para ChromeCast, nos permite pensar que en realidad cualquier aplicación actual como reproductores de audio o vídeo e incluso juegos, podrían usar esta tecnología en un momento dado. Habrá que ver las limitaciones del servicio.

ChromeCast además funciona usando los servicios en nube de Google. De echo si mandas un vídeo a la tele desde el tablet, y añadir a la cola de reproducción 10 videos más, puedes irte de casa si lo deseas que la tele no tendrá problema en su reproducción. Es más, si cualquier usuario llega a casa podrá controlar inmediatamente la reproducción actual. Esto es aplicable a películas o a cualquier otra cosa, evidentemente no hay que ser muy listo para pensar que el contenido no se envía realmente de un dispositivo a otro en estos casos, sino que es la tele quien por la conexión WIFI De ChromeCast accede a dicho contenido y lo reproduce. Si puede realmente también recibir datos directamente desde otros dispositivos, esto podría hacer de ChromeCast algo muy muy jugoso.

Lo más importante quizás, y lo que realmente ha sorprendido a muchos y ha hecho que ahora mismo ChromeCast esté totalmente agotado, es el precio. Nexus Q era bonito, genial en esencia e idas pero extremadamente costoso para lo que ofrecía. En este caso, ChromeCast cuesta 35 dólares. aun cuando hiciésemos un cambio de 1:1, 35€ es algo que realmente cualquiera en un momento dado puede permitirse, teniendo en cuenta sobre todo cuando les cuesta su pantalla de televisión. Y por 35€ lo que te llevas es algo totalmente portable, útil, ingenioso… Personalmente es evidente que aunque por ahora tan solo se ha lanzado en EEUU, ya me las ingeniaré para tener el mío. Creo sinceramente que en este caso merece la pena.

Vulnerabilidades en 2012: Windows 7/8, OSX, SmartPhones y Navegadores

Share on Google+Share on FacebookTweet about this on Twitter

Este año las felicitaciones navideñas y el próspero año nuevo se quedaron en aguas de borrajas, aunque no por eso quiera decir ni mucho menos que los días de escribir algunas cosillas en el blog terminaron. Así que antes de comenzar, aunque vaya un mes tarde, espero que todos pasásemos unas felices navidades, y que este año sea próspero para todos.

Dicho esto, ya el año pasado hice exactamente lo mismo para con los datos de 2011. Así que este año había que hacer lo mismo para el año 2012 que ya hemos dejado atrás. Los datos de nuevo están extraídos desde Secunia y el NIST

Muchos pueden creer que no es importante estos datos, pero sinceramente al menos para mí, no como aficionado a la materia sino como usuario diario de estos software es de suma importancia, lo suficiente muchas veces como para ver si uso el software correcto, o a la hora de aconsejar a otros sobre que productos decantarse. Es algo que siempre me ha sorprendido enormemente, cualquier persona se escandaliza si ve una pantalla de publicidad con un mensaje extraño, pero nadie se escandaliza cuando le dicen que su dispositivo o su equipo se encuentra en serias deficiencia en cuanto a seguridad, y que cualquier Hacker inteligente podría tomar el control de su dispositivo. Cuando intentas contarle esto a las personas te miran raro, o te dicen eso de: “Total para lo que tengo…”. En cambio, es cuando a esa persona le sucede algo por culpa de ello, es ya siempre tarde, y no son uno ni dos ni tres los casos al año, raro es el mes que no leo en mi correo o por cualquier otro medio alguien que tiene un problema, y no precisamente por que el navegador no deja de reenviarle a webs pornográficas.

Es por todo ello, que el principal problema de seguridad que existe a día de hoy es la ignorancia, el creer que nadie puede estar interesado en nuestros datos (cuando son oro puro para muchos), el creer por pura fe lo que le dicen otros, que posiblemente tienen aun más problemas que él, aunque no lo sepa. La mejor forma de enseñar, no es con miedo, no es con críticas baratas, es simplemente mostrando datos, enseñando que hay, que no hay, y que cada cual sea por tanto quien saque sus propias conclusiones.

 

Bien, el objetivo de este post como el del año pasado, es ver el número de fallos de seguridad (vulnerabilidades) acumulado durante este año pasado 2012 en sistemas operativos de escritorio, de dispositivos portátiles y de navegadores web. Eso no quiere decir que no existan otros problemas de seguridad ni mucho menos, los datos que puedo mostrar son datos PÚBLICOS que cualquiera puede tener acceso, en concreto mis datos recogidos son simplemente los CVE registrados. CVE son los reportes (un identificador) que asigna un organismo internacional a vulnerabilidades/fallos de seguridad. Hay que tener en cuenta ciertas cosas a la hora de interpretar los datos

Primero, un CVE NO IMPLICA de modo alguno que un hacker podría hacerse con el control total de tu dispositivo a través de él, un CVE es un problema potencial de seguridad que puede ser explotado con fines malignos o no, y que por supuesto su peligrosidad varía enormemente en relación con el tipo de fallo descubierto. De este modo, tenemos problemas de seguridad menos peligrosos como los que “simplemente” exponen datos de nuestro sistema o datos sensibles al exterior sin nuestro consentimiento, pasando por fallos de seguridad que permiten el Spoofing, el Cracking, escaladas de privilegios, ataques de denegación de servicio… y por supuesto hasta llegar al peor de los males, como es el acceso al sistema, que son vulnerabilidades que se pueden aprovechar para la ejecución de código remoto (digamos, el santo grial siempre del Hacker)

Segundo, hacer una tabla con el número de fallos de seguridad sin tener en cuenta otros datos sería totalmente demagogo, hay que entender muchas veces como se recogen dichos datos, si puede existir una explicación “decente” a dichos números… de lo contrario entraríamos de nuevo en escribir artículos partidistas en los que el redactor siempre haría que ganasen unos y otros en función de sus intereses. Aquí no se trata de ganar o perder, se trata de exponer datos y explicar lo que puede explicarse con las razones que puedan darse. A partir de ahí, cada cual tendrá que pensar un poco por si mismo y sacar sus conclusiones, no creerse los datos expuestos y fijarse simplemente en una tabla de datos.

Por el segundo punto, voy por ello a recalcar con mucho énfasis la gran importancia de esos “atenuantes” o “detonantes” de este número de vulnerabilidades. De echo en mi humilde opinión, que un producto haya obtenido el mayor número de vulnerabilidades a lo largo del año no implica que sea un producto inseguro per sé, eso hace solo un 50%, el otro 50% reside (de nuevo en mi opinión) en las políticas de actualizaciones/distribuciones de los desarrolladores, y del índice de penetración del mercado que posee cada producto. Las políticas de actualizaciones/distribución es esencial para tener nuestros sistemas dispositivos siempre al día, y la penetración del mercado es esencial para entender que plataformas están mucho más expuestas a todo tipo de ataques, a fin de cuenta nadie quiere encontrar un fallo de seguridad que afecte a un 1% de la población, lo intentan buscar en productos que afecte a un 50%, aunque sea 100 veces más complicado el hacerlo.

Las versiones usadas en cada caso, correspondería con las versiones que dicho producto ha tenido durante estos pasados 365 días. Por ejemplo en el caso de Windows, se han sumado los fallos de seguridad de Windows 7 de TODO el año conjuntamente con los de Windows 8 de TODO el año (desde que se terminó la versión de oro en Agosto. Lo mismo para cada producto. El índice de penetración de mercado se calcula simplemente tomando el porcentaje global de cada producto, y este a su vez se divide en función del índice de penetración que posee dicha versión dentro de dicho producto, si posee más de una versión ese producto en el período a tratar (2012), se suma dicho porcentaje. Es  decir, que si Windows posee por ejemplo un 90% de cuota de mercado y fuésemos a tratar SOLO windows XP, y que este fuese un 50% de todos los Windows instalados, el porcentaje real de Windows XP sería por tanto de un 45%, el 50% de ese 90%. Es simple.

 

Sistemas Operativos: Windows 7/8 VS OSX Lion/Montain Lion

Escritorio

 

Los datos son escalofriantes un año más, tanto en fallos de seguridad como en cuota de mercado.

  • Windows 7 en conjunto con Windows 8 poseen una cuota de mercado aproximado de un 50%, y terminaron el año con solo 50 fallos de seguridad
  • OS X Lion en conjunto con OS X Montain Lion posee una cuota de mercado conjunta aproximado del 5%, y terminaron el año con la friolera de 164

Los datos que tendríamos que obtener serían totalmente inversos, dado que Windows 7/8 posee una cuota de mercado 10 veces superior, el número de fallos de seguridad quizás no tendría que ser proporcionalmente también diez veces superior, pero evidentemente superior. En cambio el panorama no es así. A pesar de que Windows 7/8 están asentados en el 50% de los PCs de escritorio (un 92% aproximadamente todas las versiones de Windows en su conjunto), y a pesar de que OS X tan solo posee una cuota de mercado (sumando todas sus versiones) de un 6-7%, OS X posee una tasa de problemas de seguridad muy superior a Windows, la triplica!! Con el índice tan bajo de cuota de mercado y dicha tasa de problemas, teniendo en cuenta que OS X es igualmente software de código cerrado, deja claro sin lugar a dudas que es un sistema muy vulnerable.

Como ya dije anteriormente, hay que ver también la política de empresa de cada desarrollador de cara a las actualizaciones o el despliegue de su software. Una tasa alta de fallos de seguridad es mala, pero dentro de lo malo puede ser menos malo si se implementan políticas de actualizaciones rápidas, de respuesta inmediata ante cualquier tipo de vulnerabilidad que se descubra. Estos datos son igualmente públicos y se conoce la política de estas dos grandes empresas ante los fallos de seguridad:

  • Microsoft: Publicación estándar mensual de todos los boletines de seguridad, así como actualización de las definiciones de malware y otras actualizaciones (no de seguridad). Dicha publicación se realiza el segundo martes de cada mes. Al margen de este ciclo estándar, a veces también se han lanzado actualizaciones esporádicas en cualquier momento del año cuando se había detectado un problema de seguridad muy grave o para solucionar un fallo existente que ya se estaba usando para causar estragos. Eso quiere decir que en el año 2012 Microsoft lanzó sus actualizaciones en al menos 12 entregas.
  • Apple: No posee un calendario fijo de actualizaciones, suele lanzar sus actualizaciones en forma de macropaquetes, distribuidos a lo largo de todo el año. El problema es que a lo mejor en todo el año tan solo lanza 3-4 de estos. Eso quiere decir que aun cuando aparece un fallo de seguridad grave, el usuario puede necesitar de al menos unos meses para que Apple haga caso. A lo largo de 2012 Apple lanzó 5-6 paquetes de este tipo, y solo intervino en una actualización espontánea no ante la gravedad del fallo de seguridad que les afectaba, sino porque dicho fallo saltó a los medio de prensa. Es una pena, pero Apple tan solo lanza actualizaciones de forma rápida cuando el problema se ha hecho eco en los medio.

De nuevo, otro fracaso por parte de Apple y su OS X, fracasa en fallos de seguridad al año, fracasa en número de fallos de seguridad si tenemos en cuenta la tasa de mercado estrepitosamente, y lo que es peor, la política de actualización de Apple es pésima, lo que hace que los usuarios sean propensos de sufrir problemas de seguridad por exploits y otros medios que llevan circulando por la red a lo mejor durante meses, sin que Apple haga nada.

 

SmartPhones: Android VS iOS VS Windows Phone

 smarphones

 

En este caso no tenemos dos competidores, tenemos 3, y si bien es cierto que Windows Phone aun no tiene una cuota de mercado importante, es previsible que vaya subiendo poco a poco. Pero discutamos estos resultados teniendo en cuenta la penetración en el mercado que tiene cada OS:

  • Windows Phone posee tan solo un 3% aproximadamente de cuota de mercado dentro de los Smartphones, y tan solo se ha conocido un boletín CVE en todo 2012. Este resultado por tanto es totalmente consistente, es decir, con una tasa de mercado que ronda el 3%. al margen de lo seguro o lo inseguro que sea el sistema, es comprensible que el número de fallos sacados a la luz en este año sea mínimo. De nuevo esto no quiere decir que el sistema sea más o menos seguro que el resto, pero al menos sus datos son repito consistentes.
  • Android posee un índice de mercado entorno al 75%, eso quiere decir que más o menos 3 de cada 4 dispositivos Smartphones que se venden es Android. A pesar de ello terminó el año con 8 CVE, un dato bastante bueno para tener un 75% de cuota de mercado, ya que implica que Android es a día de hoy la plataforma más… “jugosa” de cara a los Hackers
  • iOS posee una cuita de mercado entorno al 15%, que no es poco ni mucho menos, pero en su caso terminó el año con la friolera de 94 fallos de seguridad. Que sea mucho o poco no podemos juzgarlo de forma sencilla, pero si simplemente lo comparamos con Android que posee una penetración de mercado 5 veces superior y menos de la décima parte de fallos de seguridad…

Estos datos son aun más inexplicables si tenemos en cuenta otro factor que aun no se ha comentado, que es que software que vamos a ver aquí, es de código libre. Cuando un software es de código libre cabe esperar que en igualdad de condiciones registre siempre un mayor de fallos de seguridad publicados. Esto es muy sencillo de entender, si es de código abierto CUALQUIERA puede acceder al código fuente y buscar y encontrar vulnerabilidades de forma mucho mucho mucho más sencilla. Esto lo veremos con claridad un pelín más adelante con los navegadores Web.

Bien, Android es de código abierto, y además posee una cuota de mercado de un 75%, esto significa que los resultados habrían sido consistentes y relativamente lógicos si fuese Android y no iOS quien tuviese esos 94 fallos de seguridad. Es más, si así hubiese sido, durante un mes estaríamos escuchando en todos los medios lo vulnerable que es Android. Lejos de eso, es iOS con tan solo un 15% (mucho si tenemos en cuenta el total, poco si lo comparamos con Android), a pesar de código totalmente cerrado, alcanza la friolera de 96.

En cuanto a políticas de actualizaciones y distribuciones:

  • Microsoft al igual que hace con su OS de escritorio, suele ser relativamente rápido a la hora de tapar cualquier problema de seguridad. No podemos saber no obstante su política exacta ante Windows Phone, puesto como ya se ha dicho con tan solo un fallo de seguridad en 2012 no se puede cuantificar demasiado bien su tiempo de respuesta.
  • Google por su parte es conocido en todos los ámbitos por dar siempre una respuesta casi inmediata ante cualquier fallo de seguridad, este es inmediatamente corregido en los repositorios AOSP para que cualquiera pueda aplicar el fix que sea necesario. Aquí hay que indicar que existe un retraso significativo no a la hora de actuar contra el problema, sino en que los fabricantes lo adepten. No es un fallo de Google de echo, es de las políticas de cada uno de los fabricantes. Lo general es que ante un fallo de seguridad grave, los fabricantes puedan tardar en lanzar actualizaciones a sus dispositivos hasta dos y tres meses.
  • Apple aplica la misma filosofía que con OSX, hasta que el fallo no trasciende a los medios de comunicación le da igual la gravedad del problema, y por desgracias tenemos muchos ejemplos de ello. De echo, precisamente aparece en los medios, porque es algo fragante que está totalmente extendido. Así aun recordamos todos el fallo de seguridad que permitía tomar el control de cualquier iPhone simplemente a través de unos SMS que se enviaban, o al menos 4-5 fallos de seguridad críticos que permitían igualmente apoderarse del control total del dispositivo simplemente haciendo que el usuario accediese a una web concreta. Fueron necesario meses y meses antes de siquiera lanzar una actualización para ello, a lo que a partir de aquí hay que sumar el tiempo que tardaría cada cual en aplicar dicha actualización.

 

Navegadores WEB: Opera 11/12, Internet Explorer 9/10, Firefox 10..17, Safari 5/6. Chrome 17..23

 navegadores

 Veamos en esta ocasión la consistencia de los fallos de seguridad de cada navegador atendiendo a su cuota de mercado, aunque en el caso de los navegadores hay que añadir un factor adicional que posee tanto Firefox como Chrome y que se debe de tener muy en cuenta:

  • Opera registra el menor número de fallos de seguridad, con tan solo 34 boletines CVE si sumamos los fallos de seguridad de todo 2012 a las versiones que estuvieron en funcionamiento en él, pero hay que tener en cuenta que posee una tasa de mercado muy pequeña, entorno al 3%. Es necesario por tanto ver el resto de navegadores para ver si sus datos son consistentes, y lo cierto es que más o menos si lo son. No es una tasa demasiado elevada, era de esperar que al tener tan poca tasa de mercado sería el que menor número de boletines acapararía. Aun así, desde mi punto de vista, para tener tan solo 3% de cuota me parece un valor alto
  • Internet Explorer 9 y 10 suman un total de 39 problemas de seguridad, algo más que Opera, pero con una gran diferencia, y es que IE tiene una penetración que ronda el 39%, eso multiplica por 10 la expansión de IE frente a Opera, y aun así tan solo llega a 39. Este dato es muy sorprendente.
  • Firefox si lo comparamos con los datos del año pasado a sufrido un incremento exponencial (que ya veremos debido a que), terminado 2012 con 216, muy superior a los 39 de IE sin duda alguna, y posee un share entorno al 25%, nada despreciable tampoco.
  • Safari alcanza los 274, pero en este caso el share de este es igualmente mínimo, rondaría el 6%.
  • Chrome por su parte comparte todos los pros y contra de Firefox, solo que en este caso llega a los 277 boletines, con un mercado que ronda el 36%, eso significa la segunda posición en cuanto a su uso.

Antes de analizar esto, hay que tener en cuenta que tanto Chrome como Firefox son de código abierto, y que ambos ademeás poseen ciclos de productos muy cortos, solo hay que ver que en todo 2012 el resto de los navegadores difícilmente cambiaron en uno la versión de sus productos, mientras que Firefox vivió 2012 con 8 versiones diferentes, y Chrome lo hizo con 7. Esto es a tomar muy en cuenta, ciclos cortos permiten un progreso más rápido de los navegadores, pero también implica que aparecerán más problemas de seguridad, aunque (y esto es importante) solo afecten a versiones concretas de ellos. Es decir, Chrome y Firefox poseen una tasa mucho más alta fundamentalmente a que participan con muchas más versiones, pero no quiere decir que todos esos fallos de seguridad afectasen a todas las versiones, de echo si dividimos el número CVE entre el número de versiones lanzadas, vemos que el resultado es mucho más cercano al que logra obtener IE.

Dicho esto, de todos modos el ganador indiscutible es Internet Explorer, aunque es cierto que es de código cerrado, con una tasa tan grande de mercado y con tan solo 39 fallos de seguridad en todo 2012, nadie puede acercarse. Impresionante trabajo por marte de Microsoft. El segundo lugar sería más complicado, Opera tiene un resultado muy bueno, pero un 3% es muy poco significativo, por tanto el segundo lugar sería quizás para Firefox, sí, son 216 CVE, pero si tenemos en cuenta que posee un 25% de mercado, ciclos cortos y de código libre, hay que entender el gran trabajo que hay de fondo. Del mismo modo y rozando los talones estaría Chrome con algunas más, aunque también con un porcentaje de mercado algo superior. Después si situaría a Opera, y por último tendríamos Safari, que aun cuando tendría que partir de una postura ventajosa como Internet Explorer, fracasa estrepitosamente en todo. Con tan solo un 6% de mercado, aun asiendo de código cerrado y con ciclos largos, obtiene el el segundo peor número, muy cercano al de Chrome, con 274. A diferencia de Chrome, Safari no tiene excusa alguna de tal número de fallos de seguridad, y tampoco puede culparse a las diferentes plataformas ya que desde Safari 6, este tan solo se usa en OS X.

Las políticas de actualizaciones y distribución en algunos casos son las mismas ya comentadas:

  • Opera actúa ciertamente con bastante rapidez ante cualquier problema de seguridad, no tiene una actuación inmediata, pero se puede tener la cierta seguridad de estar protegido por fallos de seguridad que salen día a día. Si es un fallo crítico, posiblemente tendrían una actualización lista en dos o tres días.
  • Microsoft aplica a Internet Explorer su misma política que a Windows, usa los boletines de seguridad mensuales de Windows para actualizar Internet Explorer, y solo cuando un problema grave de seguridad es detectado se plantea el lanzamiento de una actualización fuera de su ciclo normal. Eso nos dice que con seguridad Internet Explorer suele estar actualizado y protegido con un intervalo de un mes, y si es urgente de nuevo casi de forma inmediata, unos días como mucho
  • Mozilla y Google al usar un navegador de código abierto y ciclos cortos, la actuación ante problemas de seguridad es prácticamente inmediata, en cuanto es conocida o comunicada, sin importar demasiado el grado de importancia que tenga problema encontrado es corregido con la mayor presteza en los repositorios oficiales, y en cuanto son probados se lazan actualizaciones inmediatas al propio navegador, que se actualiza el sólo sin intervención siquiera muchas veces del propio usuario. Sin duda alguna son las dos compañías que reaccionan más rápido ante cualquier amenaza. Bravo por ambos.
  • Apple por su parte usa también la misma filosofía que en OS X o en iOS, actualizaciones esporádicas en las que aprovechan para parchear todo lo que tengan pendiente, no importa si el fallo de seguridad lleva circulando dos días o un mes, si no ha trascendido a la prensa no cambian su calendario. Eso hace evidentemente que el navegador del usuario se encuentre constantemente en peligro, y más si vemos el gran numero de fallos que acumula, con 274 fallos de seguridad tenemos una media de 0.7 fallos diarios, lo que quiere decir que el usuario de Safari está sencillamente “jodido”, usar Safari implica estar expuesto a cualquier Hacker básicamente.

Pronto será el Pwn2Own como todos los años, en el que los navegadores se expondrán en un concurso de Hackers a ser destrozados. Aquí es donde vemos realmente no lo bueno o malo que sea el navegador en aguantar (que también), sino las políticas de empresa de cada cual. Cuando veos que dos o tres días antes del Pwn2Own Apple lanza apresuradamente un macro paquete de actualizaciones, algo te dice que es mejor huir de dicho navegador. Google hace lo mismo no nos engañemos, aprovechará días antes para parchear al máximo Chrome e intentar pasar indemne la prueba del Pwn2Own, pero en su defensa tenemos que decir que es un patrocinador oficial del Pwn2Own y que hace precisamente estos días una competición similar, dicho de otro modo y pese a intentar aprovecharse el día antes para actualizar su navegador, posiblemente es la empresa que se toma más en serio la seguridad de los 5, o al menos lo demuestra. Microsoft el año pasado ya optó por jugar limpio y no lanzar ninguna actualización a destiempo, es decir, fue el único que jugó limpio…. veremos este año que sucede.

Es por eso que aunque Firefox o Chrome posean las tasas mas altas de problemas de seguridad (quitando Safari), es casi imposible que ninguno de esos fallos de seguridad pueda afectar al navegador, a menos que alguno de ellos sea lo que se conoce como un Zero Day Exploit, es decir, un exploit que se aproveche de un fallo de seguridad que aun no ha sido comunicado o hecho público. Es la única forma, puesto de lo contrario si el usuario mantiene su navegador actualizado (que generalmente se automantienen ellos), estará siempre protegido. Internet Explorer es igualmente complicado atacarle con un CVE ya publicado, aunque es posible, si un exploit aparece para aprovechar un CVE, con suerte es posible usarse durante unos días. Ese es el problema de Sarafi, que es posible usar contra él exploits que afectan a CVE publicados incluso meses antes, sin que el usuario pueda hacer nada al respecto porque no hay ninguna actualización que le protega ante ellos, y hablamos de exploits y fallos de seguridad, aquí no sirven de nada los corta fuegos o cualquier otro tipo de medidas.

 

Tener un número alto de fallos de seguridad es malo, este número es alto o bajo solo si lo comparamos con productos similares y vemos que número podría ser más o menos aceptable o lógico, es cuando vemos la capacidad realmente de los programadores y lo serio que pueden tomarse la seguridad. Pero eso no hace ni mucho menos que nuestros dispositivos sean más o menos seguros, es importante, pero no es algo que lo decida por completo, como hemos dicho con Google o Mozilla, es incluso más importante el tener una actuación inmediata ante cualquier problema, es la única forma de tener la certeza, o al menos la garantía más alta, de que estamos seguros. Vale, no hay nada seguro, y un exploit Zero Day hará trizas cualquier sistema por protegido que esté, pero hay que poder encontrarlo y usarlo. Y sí, los hay, siempre los habrá.

Un saludo.

Volver a arriba

Sobre Mí

Cambiar a la versión para móviles

Creative Commons License
Alma Oscura por Theliel is licensed under a Creative Commons Reconocimiento-No comercial-Sin obras derivadas 3.0 Unported License.
Basado en el trabajo de blog.theliel.es.
Para otros permisos que puedan exceder el ámbito de esta licencia, contactar en blog.theliel.es/about/contactar.