Archivo de la categoría ‘Proyectos’

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…

Para hacer en casa: Como agotar en minutos, de forma remota, los datos móviles de cualquier usuario de iOS (iPhone o iPad)

Share on Google+Share on FacebookTweet about this on Twitter

Animado por la cantidad de datos manipulados y/o tergiversados que Apple está enseñando estos días en su WWDC (gráficas “falseadas” constantemente) e impresionado una vez más por los 20€ que quiere cobrar a sus usuarios por una actualización de su sistema operativo (recordar que no es un OS nuevo sino actualizaciones, parches), escrito estas palabras a día de hoy, para mostrar una vez más al lector con mucha o poca idea de tecnología, lo bonito y bello que es el mundo fuera de esa secta.

Material necesario:

-Un PC con conexión a Internet
-Seleccionar de forma inteligente el tipo de paquetes a usar (desde un simple Ping a un paquete Sync TCP…)
-Unos minutos/horas (dependiendo diversos factores)
-Un objetivo con el que “experimentar”
-Tener ganas de gastar una graciosa broma “pesada”

Nota: En las pruebas realizadas, se logró un agotamiento de datos aproximados de unos 10MB/minuto sin mucha complicación

 

La idea surgió mientras me daba un relajante baño, y lo cierto es que brilla por su sencillez, no comprendo como a estas alturas no sea algo que haya visto en ningún sitio, y es cuanto menos gracioso. Antes de empezar, y prometo no extenderme “demasiado”, voy a explicar un poco más el título de este pequeño artículo, y es que hoy vamos a prender como cualquier persona detrás de un PC, una línea a Internet y poco más puede agotar en cuestión de minutos u horas (dependiendo de su conexión y del plan de datos del usuario de iPhone/iPad) los datos que tenga contratado dicho usuario. En realidad no puede aplicarse absolutamente a todos, pero sí me arriesgaría a decir que sí es posible a la inmensa mayoría de ellos.

Veamos, la inmensa mayoría de todos los usuarios que tenemos Smartphones tenemos contratado con nuestro operador una tarifa de datos, hasta aquí todo perfecto. Por otro lado, al menos aquí en España, nuestros operadores como sabéis nos asignan un límite mensual en el volumen de datos transferidos, definido por el tipo de tarifa que tengamos con ellos. Cumplido dicho límite pueden suceder dos cosas: Algunos operadores te bajan la velocidad de la transmisión de datos a niveles irrisorios (que valen para leer un correo y poco más) y otros pasado dicho umbral tarifan los MegaBytes transferidos hasta finalizar el mes.

¿Qué consecuencias podría acarrear el agotamiento de estos datos en un usuario que tenga un iPhone o un iPad? Es simple:

-En caso de que su operador le reduzca la velocidad, agotarle sus (por ejemplo) 500MB mensuales, obligándole a trabajar a velocidades bajísimas, haciendo prácticamente inservible dicho dispositivo para cualquier tarea que requiera datos. Llegado a este umbral si se continuase con este método a ahogar al dispositivo, no repercutiría en la tarifa de dicho usuario, pero sí bloquearía totalmente el tráfico de datos del usuario, hasta que el (llamémosle atacante) atacante detuviese el asalto.

-En caso de que su operador le facture el tráfico de más, a dicho usuario le podría llegar una cuantiosa factura al finalizar el mes, el límite tan solo estaría en lo bueno o malo que sea el gracioso que le quiera jugar una mala broma. A efectos prácticos dicho usuario afectado no podría rendir culpa al operador ya que como veremos no ha existido trampa por ningún lado, simplemente alguien se aprovechó del sistema, y el usuario de su dispositivo iOS tendría que pasar por caja.

-De estar el dispositivo en baterías (sin estar cargando), le estaríamos reduciendo su batería de forma drástica!! no puedo conocer de cuando estaríamos hablando, pero posiblemente en unas horas podríamos agotar por completo la carga de un iPhone con la batería al máximo, y eso solo contando el consumo de batería repercutido por el propio bombardeo.

-A corto plazo el propio dispositivo del usuario afectado funcionaría en correcto estado (salvo por el consumo masivo de datos que empezaría a acusar), pero a medio largo plazo podría ver como su dispositivo se bloquearía o comenzase a actuar de forma errática por culpa del efecto de un DoS (Ataque de Denegación de Servicio)

-Si quien realiza el asalto es ingenioso, podría bloquear la capacidad de sincronización del dispositivo de la víctima (el usuario de iPhone/iPad)  de forma simple, impidiendo que este pueda usar servicios como sincronización, iCloud… e incluso Whatapps y otros.

 

Todos sabemos de lo que estoy hablando cuando nombramos el consumo de datos, cualquiera que tenga un Smarphone lo sabe, así como su límite mensual. Lo que no sabe la gran mayoría sin embargo porque quizás nunca se ha hecho dicha pregunta, es como se contabiliza esta transferencia. En la práctica, cualquier dato que sale o llega al dispositivo cuenta, da igual que este tráfico lo haya generado el propio usuario directamente o indirectamente. Es evidente que el usuario siempre puede controlar (los usuarios de iOS no tienen prácticamente control de nada) el tráfico generado por ellos mismos, ¿pero que pasa con el tráfico generado por el exterior?

Muchos pueden pensar que el exterior no genera ningún tipo de tráfico a sus dispositivos cuando estos no lo solicitan, pero esto es totalmente falso. Es cierto que si abrimos un navegador Web estamos iniciando nosotros una comunicación de forma directa y que desde ese momento se abre un canal de comunicación el cual consumirá datos (los enviados por el dispositivo al exterior y los recibidos por parte del servidor), pero ¿qué pasaría si de forma externa intentamos conectar/contactar con otro dispositivo sin que este solicite dicha conexión? A fin de cuentas cualquier dispositivo conectado a Internet es accesible desde otro dispositivo por medio de su dirección IP como muchos saben, y aunque no sea el dispositivo quien inicie la comunicación, sería absurdo pensar que desde fuera esto no puede hacerse.

Bueno pues en esta ocasión la teoría es casi tan simple como la práctica. ¿Qué sucede si bombardeásemos cualquier dispositivo conectado directamente a Internet con paquetes de datos arbitrarios (o no tan arbitrarios)? Dado que el operador de dicho usuario contabiliza los datos que llegan al terminal (con total indiferencia de si son datos útiles o no), por cada Kb que le enviásemos le estaríamos comiendo otro Kb de datos que tiene. El concepto no es nada nuevo, y los que viven en estos lares desde hace años, quizás les suene los viejos Flood de texto del IRC, o incluso los Sync Flood. El concepto es el mismo, bombardear un dispositivo con paquetes de datos.

Esto por supuesto es algo que puede hacerse con absolutamente cualquier dispositivo conectado directamente a Internet, ¿pero que hace de este sistema realmente interesante aquí? Son dos las peculiaridades que hacen que este sistema de extenuación de datos obtenga un éxito abrumador: Tarifas de datos limitadas y la facilidad de detección de un dispositivo con iOS (ya sea iPhone o iPad). Estas dos peculiaridades hace que resulte realmente sencillo acabar en un rato con todo el consumo mensual de cualquier usuario estos dispositivos. Gracioso cuanto menos, ¿verdad?

 

Manos a la obra. Al comenzar expuse el material necesario, y lo cierto es que prácticamente cualquier usuario puede probarlo. Ni que decir tiene que no comparto la idea de fastidiar por el mero echo de fastidiar, yo expongo simplemente echos y vulnerabilidades que creo que son de gran interés, sobre todo a los propios usuarios expuestos. Tan solo hay dos puntos en todo el proceso que merece la pena deteneros, que sería el tipo de datos a enviar (y como hacerlo) y el objetivo.

 

Paquetes a usar

Podríamos enviar de forma arbitraria cualquier dato a un dispositivo por medio de multitud de herramientas existentes, pero lo cierto es que pensando un poco podemos idear/fabricar paquetes que sean más efectivos que otros.

Bien, la idea es agotar en el menor tiempo posible la mayor cantidad posible de Bytes. Si lográsemos un agotamiento de 1Byte por segundo tardaríamos más de 12 días en consumirle a ese usuario 1MB… lo cual no es viable desde luego. Y si enviamos cada segundo paquetes de 1KB? y si son de 16KB? A un consumo de 16KB por segundo, consumiríamos 1MB en tan solo 64 segundos, 10MB en 10 minutos aproximadamente… en 9 horas se abrían consumido de ese usuario 500MB.

Cual es el mejor sistema? Aquí cada cual puede optar por el sistema que crea mejor, pero si tenemos en cuenta que nuestros operadores cuentan como datos cualquier dato tanto recibido como ENVIADO, en mi cabeza solo suena una palabra: Ping. Una de las herramientas más viejas que existen y una de los más famosos. No voy a extenderme minutos u horas explicando las bondades de nuestro amigo el Ping, pero lo mínimo para entender la gran utilidad de este amigo. El Ping no es más que una herramienta que permite enviar un tipo especial de paquetes de datos ICMP llamado “Echo Request”, un tipo de paquete usado en el protocolo IP que no usa los protocolos de transportes TCP o UDP. Al igual que todos de los paquetes ICMP, se creó con el propósito de garantizar el buen funcionamiento de la red por medio de dos tipo de paquetes concretos, el Echo Request y el Echo Reply (pregunta y respuesta). La idea era simple, cuando a cualquier dispositivo de internet le llagase un Echo request, este respondería con un Echo Reply. Esto tenía dos funciones fundamentales: Saber el estado de un dispositivo de red (si está en línea o no) y conocer incluso la calidad de la red midiendo el tiempo transcurrido desde que se realiza el request hasta que se recibe el reply, puesto que cuanto menor sea el tiempo es de suponer que la red es más rápida o está menos congestionada o sufre de menor retraso.

A día de hoy, excluyendo algunos Routers o puertas de enlace residenciales, cualquier dispositivo está configurado por defecto para contestar los ICMP Echo Request, lo cual es lógico puesto que como digo estos paquetes juegan una importante labor en el mantenimiento y correcto funcionamiento de Internet. Pues bien, dicho todo esto tendríamos en nuestras manos una herramienta que no solo nos permite enviar datos a un determinado objetivo (consumiéndole la cantidad de datos que sea) por medio de un paquete Echo Request, sino que además dicho objetivo nos responderá con otro paquete Echo Reply!! eso quiere decir que sus datos se verán consumido tanto por nuestro paquete de datos enviado como por el paquete de contestación que se ha visto forzado a enviarnos de vuelta sin que él lo sepa.

Pero es que además, prácticamente todas las herramientas de Ping para generar este tipo de paquetes nos permiten especificar el payload (datos) a enviar dentro del propio Echo Request!! sin contar que el Echo Reply de vuelta contendrá también exactamente los mismos datos. Dicho de otro modo, si hacemos Ping a un iPhone especificando usar un payload de 16KB y este paquete llega a su destino, el destino nos responderá con un paquete de respuesta a nuestro Ping con el mismo Payload enviado por nosotros, co lo que en total estaríamos consumiendo al usuario 16*2=32KB simplemente enviando un Ping de 16KB. Un dos por uno, no está nada mal. Recordar que el tamaño máximo del Payload son los 64KB. Lanzar este tipo de ping es trivial en cualquier plataforma, voy a poner dos ejemplos, uno en Windows usando Ping y otro en Debian usando nPing. La única desventaja que posee Ping en Windows es que este no envía otro Ping hasta que no ha recibido el Eco de respuesta, y esto hace que se ralentice mucho el ataque. Podríamos usar nPing en Windows, pero no permite por desgracia la fragmentación de paquetes y tendríamos que usar un payload máximo que rondaría los 1500KB. De cualquier manera, ya sea usando Ping o nPing el resultado es impresionante. Por supuesto esto no es más que un pequeño ejemplo:

Debian:

nping -c 0 –icmp –icmp-type 8 –data-length 4096 –mtu 1448 –delay 50ms IP_Destino

Se estaría enviando un paquete de 4KB de datos fragmentados (dado que el MTU de las líneas DSL/cable no es más de 1500 máximo y es necesario fragmentar) cada 50 milisegundos al destino especificado, y continuaría así hasta que el usuario cancelase el asalto.

Windows:

ping -t -l 4096 IP_Destino

En este caso se enviaría un paquete de 4KB fragmentado, pero no se puede controlar con que velocidad, el sistema enviará un nuevo paquete en cuanto reciba la respuesta por parte del destino.

 

Por descontado que la primera opción es mucho más eficaz. Con la primera opción, se lograrían estar generando 20 paquetes por segundo de más de 4KB, que así mismo en teoría generarían otros tantos paquetes por parte del cliente, duplicando la tasa de datos consumida. Es decir, en este caso concreto serían 20 paquetes enviados en un segundo a 4KB = 80KB/seg, y se generarían otros tantos el otro extremo, lo que resultaría de un total de 160KB/s, 1MB cada 6 segundos y medio, 100MB cada 10 minutos aproximadamente. Esto quiere decir que en menos de una hora habríamos consumido (posiblemente mucho antes) todos los datos del mes del usuario!

En las pruebas que he realizado, en el caso de iPhone/iPad el tamaño más adecuado para el ping sería de 4KB, es capaz de devolver prácticamente todos los Echo Request a una buena velocidad. Por supuesto dependerá de la buena o mala cobertura que el dispositivo tenga. Por supuesto el tiempo que tardará el sistema en consumir al totalidad de los datos del usuario dependerá también del plan contratado, si el usuario tan solo dispone de 100MB le podríamos consumir el primer día del mes todos los datos en tan solo 10 minutos.

 

 

Que objetivo especificar

Hasta aquí ha sido todo fácil, pero prácticamente el sistema explicado anteriormente puede usarse no solo en iPhone, sino en cualquier dispositivo conectado por datos a Internet. ¿Porque hace este sistema un arma terrible contra los dispositivos de Apple? Porque como vimos en otros artículos publicados como por ejemplo el de búsqueda y captura de iPhone, Apple nos deja la puerta abierta de poder localizar de forma simple y trivial cualquier iPhone o iPad que deseemos. Por supuesto que podemos utilizar lo anteriormente dicho de forma indiscriminada, pero sería un gasto de tiempo no asumible sin conocer de antemano que dispositivo se encuentra detrás de ese objetivo. Es decir, incluso con fines experimentales podríamos estar atacando un dispositivo que es un PC, o un dispositivo Android cofigurado para no contestar paquetes Ping (con lo que se ahorraría la mitad del tráfico), o simplemente un router. En cambio, sí podemos saber con total antelación si ese dispositivo es o no es un iPhone sin posibilidad de error. El truco ya lo he explicado otras veces en el Blog, y parece que Apple no se ha enterado aun del peligro de dejar un puerto abierto a sus dispositivos, en concreto el puerto TCP 62078. Ese puerto se encuentra abierto en absolutamente TODOS los dispositivos con iOS, tanto iPhone como iPad!! Es decir, que si nos encontramos dicho puerto abierto, podemos afirmar que al otro lado tenemos un pobre usuario que no sabe la que le espera.

Aquí se abren dos posibilidades:

-Buscar indiscriminadamente iPhone e iPad escaneando Internet gracias al puerto 62078 como vimso en el artículo de búsqueda y captura
-Conocer la IP del dispositivo de nuestra víctima, y de antemanos saber si es un iPhone/iPad o verificarlo mediante el puerto abierto

 

La primera opción sería muy sencillo, para encontrar cualquier infeliz de forma rápida e indiscriminada tan solo nos bastaría comenzando a escanear el segmento de subred /24 de nuestra propio operador. Casi con toda seguridad en dicho segmento (que sería un total de 256 host) habrá al menos algún iPhone/iPad conectado a la red. Ejemplo:

A) Supongamos que la IP de nuestro teléfono es 32.104.119.125
B) Realizamos un escaneo del puerto 62078 en el segmento /24: 32.104.119.0 – 32.104.119.255

C:\Users\Theliel>nmap -Pn -p62078 -vvv 32.104.119.0-255

Starting Nmap 6.00 ( http://nmap.org ) at 2012-06-12 03:45 Hora de verano romance
Initiating Parallel DNS resolution of 256 hosts. at 03:45
Completed Parallel DNS resolution of 256 hosts. at 03:45, 4.36s elapsed
DNS resolution of 256 IPs took 4.38s. Mode: Async [#: 2, OK: 0, NX: 256, DR: 0, SF: 0, TR: 321, CN: 0]
Initiating SYN Stealth Scan at 03:45
Scanning 256 hosts [1 port/host]
Discovered open port 62078/tcp on 77.208.119.7
Discovered open port 62078/tcp on 77.208.119.25
Discovered open port 62078/tcp on 77.208.119.42
Discovered open port 62078/tcp on 77.208.119.41

C) Como es de esperar casi de inmediato tenemos a nuestras víctimas, ya solo queda comenzar el bombardeo que estimemos oportuno

 

Aunque el primer método es gracioso y podemos ir aniquilando usuario a usuario (sería igualmente simple crear un script en Linux para automatizar todo el proceso, en una noche habríamos dejado sin datos a unos cuantos usuarios de iPhone/iPad), no sería un ataque dirigido. ¿Sería posible posible realizar este bombardeo o Flood contra un objetivo específico? Bueno, aquí el problema estaría en conocer la IP de dicho usuario, si disponemos de ella sí, de lo contrario no. ¿Y es posible conocer la IP de un usuario de iPhone sin que evidentemente nos la de? Aquí ya entra el ingenio de cada uno, y como se dice cada maestrillo tiene su librillo. Si se sabe buscar sí es posible, amen de poder usar diferentes técnicas y/o engaños para obtenerla.

Dejo simplemente algunas ideas al aire que usar sin especificar demasiado, a fin de no darle al posible “Lamer” que lea esto lo necesario para apretar un botón y listo, al menos que pierda el tiempo en buscarse las habichuelas:

-Engaños de cualquier tipo, desde un: “Tio dame el número que sale en la web www.cualesmiip.com”, pasando por entra en esta web (que es mía y registra laIP) y terminando por quiero enseñarte algo dame este dato. Os sorprendería lo incautos que son algunos, sobretodos los usuarios de Apple que precisamente por creerse eso de que sus dispositivos son segurosson los que comenten más irresponsabilidades.
-La mensajería instantánea y programas de videollamadas como Whatapps, Gtalk, Skype, Windows Live Messenger, iMeenseger/FaceTime, Viber… no es complicado gracias a estas herramientas conocer la IP del incauto usuario de iPhone, sin que este jamás sepa por supuesto que fuimos nosotros.
-Cualquier comunicación que se nos ocurra que pueda ser directa entre dispositivo-dispositivo
-En los correos electrónicos siempre hay más información de la que aparentemente hay
-…

Como siempre en la imaginación está el límite.

 

 

Como evitar en lo posible  este tipo de Floods

En primer lugar hay que tener en cuenta que no existe una solución totalmente eficaz con este problema, el propio diseño de Internet hace posible esta técnica. No quiere decir que no podamos hacer cosas para evitarlo en lo posible, pero además de no existir algo eficaz hay que sumarle que cualquier cosa que hagamos nos repercutirá casi siempre en una u otra cosa.

En primer lugar tenemos el dispositivo en sí. La mejor defensa es sin duda alguna tener un buen sistema que pueda protegernos. En este sentido vuelvo a recalcar la cutrería e inexplicable seguridad de los dispositivos de Apple dejando ya no solo el puerto anteriormente nombrado, sino otros!! A los ingenieros de Apple alguien tendría que explicarle el peligro que concierne el tener un puerto abierto al exterior. Esto muchos pueden leerlo y decir: Buaj, que más da… y a esas personas yo les diría. ¿Tu dejas la puerta de tu casa abierta? Pues esto es lo mismo. No quiere decir que un puerto abierto equivale a una muerte anunciada, pero un puerto abierto que de antemano sabemos que existe, para que se usa, expuesto al exterior y que además tan solo usa Apple para sus dispositivos portátiles, es como poner una etiqueta a sus dispositivos que ponga: “Por favor, atáquemen/Piratéemen por aquí”. Eso sin contar que Apple en cualquier momento puede conectarse a dicho puerto para lo que ellos estimen, ya que aunque sabemos que ese puerto se usa para sincronizaciones, quien nos dice que no se usa para algo más. En la práctica, Apple podría estar usándolo para lo que quisiese , y al estar abierto al exterior tendría acceso remoto siempre. En comparación, Android por defecto no posee absolutamente ningún puerto ni TCP ni UDP expuesto, del mismo modo que ningún router lo posee, ni Windows, ni Linux…

En segundo lugar, la mejor forma de acotar el problema sería que nuestro operador de datos nos proporcionase acceso a la red por medio de su red interna, es decir por medio de una IP privada. Este servicio lo usan por ejemplo a día de hoy en España Yoigo o Pepephone (este último ofrece las dos posibilidades). Si nuestro operador nos asigna una IP privada cuando estamos conectados a su red, quiere decir que TODO el tráfico que enviamos y que podría llegarnos pasa antes por sus dispositivos NAT/Firewall. Es decir, sería imposible alcanzar a los dispositivos que se encuentren dentro de esa red privada desde fuera, tan solo obtendríamos en el mejor de los casos la IP pública, y esta nos dejaría a la puerta del Firewall de la compaññía, nuestros intentos serían totalmente ineficaces. No obstante, aun cuando el usuario se encontrase en este escenario no sería invulnerable, ya que podría ser atacado desde dentro de la propia red. Cualquier usuario de su mismo proveedor podría alcanzarlo. Es decir, un usuario iPhone de Yoigo protegido por una IP Privada podría ser totalmente atacado y asaltado por otro usuario de Yoigo, pueseto que estaría conectado a la misma red privada que él, aunque en este caso el asalto tendría que realizarlo desde el propio dispositivo, y por consiguiente tb repercutiría en su propio consumo de datos. Pero el principal problema del segundo método y por el cual tan solo lo usan Yoigo y Pepehone, es que cualquier usuario dentro dentro de una red privada para su acceso a internet tendrá sus servicios muy limitados, sin contar que estarán totalmente controlados por parte de su operador. El usuario detrás de esta red no podrá usar/utilizar una gran cantidad de servicios, comenzando por cualquiera que requiera ejercer de servidor: servidores web/ftp/ssh/samba… también se saben de problemas los usuarios de iPhone detrás de estas redes en sincronizaciones con iCloud, problemas, cortes y retrasos a la hora de usar programaspor VoIP como Skype, Viber… retrasos en programas de mensajería instantánea tipo Whatapp… este es el motivo principal por el cual tan solo Yoigo y Pepephone (que yo sepa ahora mismo) proveen el acceso a Internet por medio de su red privada. El caso de Pepephone no obstante es de señalar y sinceramente de alabar, puesto que permite a sus usuarios por medio de dos APN diferentes el acceso a Internet tanto por IP ública como IP privada, es decir que es el usuario quien puede optar en cualquier momento por cualquiera de estos dos sistemas, estando la elección en manos del usuario a golpe de golpe en la pantalla para cambiar de APN. Bien por el tío Pepe!!

En tercer lugar, aquellos usuarios que disponemos de dispositivos Android podríamos sin mucha dificultad configurar el sistema para evitar al menos conexiones salientes que no deseemos, es decir en el caso de los paquetes Echo Reply, denegar su uso, impedir responder a las peticiones Ping. No se evitaría el problema, pero reduciríamos a la mitad el gasto de datos.

 

 

Proyecto: Búsqueda y Captura de iPhones/iPad. Lo simple que es “Hackear” unos millares de ellos

Share on Google+Share on FacebookTweet about this on Twitter

“¿Tienes un iPhone o un iPad? Quizás no lo sepas, pero es posible que en este mismo momento te haya robado, sin que tu lo sepas jamás, toda la información personal que tenías en él, desde la agenda, fotos, música… o puede simplemente que me haya entretenido en realizar llamadas o enviar SMS desde tu iPhone para beneficio propio.”

Este, señores, podría ser perfectamente el mensaje que podríamos hacer que les apareciese en la pantalla a muchos usuarios de iPhone/iPad, que confiadamente creen que su teléfono o su teléfono gigante (iPad) es un producto seguro. En otras ocasiones muchos me habéis escuchado decir que si iPhone es una porquería, que si iPhone es inseguro, que si Apple hace las cosas mal… el problema es que el lector que no comparte dicha opinión (ya sea porque tiene un iPhone, tiene otros conocimientos o simplemente otro punto de vista) cree que son exageraciones, o simplemente que este humilde “redactor” es un poco engreído o tiene una cruzada contra Apple.

Así pues, he comenzado a jugar a un juego que le he llamado: “Búsqueda y Captura de iOS”. Pero tranquilidad, en realidad he sido benevolente (sin contar que es lo que la legalidad me deja), y este juego al final no tendrá consecuencia alguna para nadie (excluyendo quizás la imagen de Apple). Y digo esto y quiero dejarlo muy claro, que del mismo modo que estoy jugando a “Búsqueda y Captura” podría haber comenzado a jugar un poco más fuerte, y nombre del juego sería “Búsqueda, Captura y Secuestro”. El juego tendrá dos partes, como su propio nombre indica: Búsqueda de iPhones/iPad y su “captura”. En realidad el término “Captura” sería más bien como “blanco fijado y preparado para disparar”.

Primero, aprovechando parte del trabajo que realicé en el artículo anterior sobre la seguridad de las redes españolas voy a realizar una búsqueda (no demasiado exhaustiva) de los iPhone e iPad que se encuentran conectados a redes de datos 3G/3G+. Evidentemente esto deja a no pocos iPhone/iPad fuera de esta búsqueda, pero aun así los datos recogidos pueden ser relativamente interesantes… serán quizás cientos? serán miles? decenas de miles? Cuantos iPhone/iPad hay actualmente en España? Por “suerte” la gran mayoría de usuarios de iPhone e iPad tienen contratos leoninos con los operadores, los cuales les obligan a tener conexiones 3G. Pues bien, digamos que prácticamente cualquier iPhone o iPad conectado a 3G será registrado, esto excluye por definición a los iPhone 2G o cualquier iPhone conectado a WIFI o sin plan de datos. Que porcentaje de iPhones/iPad quedará cubierto entonces? No creo que sea posible saberlo, pero en realidad tampoco es importante desde el objetivo de este juego, dado que cuando pasemos a la segunda parte, si podremos comparar entre porcentajes de ambas partes. El objetivo por tanto de esta primera parte es claro y evidente: Localizar la mayor cantidad de iPhone e iPad que se encuentran en España. Gracias Apple por hacerme el trabajo tan fácil.

Segundo, dado que es relativamente sencillo realizar dicha búsqueda, que menos que aprovecharla no solo para decir: En España he logrado encontrar X iPhone y Z iPads. Ya que puedo localizar unos miles, decenas de miles o cientos de miles de iPhones e iPads, puedo de paso digamos “llamar a la puerta” de cada uno de ellos y comprobar si la puerta está abierta o si me quieren abrir. Hasta este punto todo entraría dentro de la legalidad. Ahora bien, la diferencia radica en que si veo que la puerta está abierta y simplemente anoto su dirección y referencia (y me doy la vuelta), es legal. Si en cambio cruzo la puerta ya no es legal. Es decir, voy a llamar gentilmente a la puerta de unos cuantos de miles o cientos de miles de iPhone e iPad en España, voy a cargar la pistola y al final tan solo dispararé un poco de fogueo. Vale, para quien no le guste las metáforas, más simple: En esta segunda parte voy a ver simplemente con cuantos de esos iPhone e iPad (localizados en la primera parte) puedo/podría lograr un control total, sobre dichos dispositivos claro está.

Encendemos las noticias o leemos el periódico, escuchamos/leemos que nuestros datos pueden estar expuestos, que pueden robarnos información… pero lo gracioso de todo es que rara vez el usuario hace algo. Lejos de hacer algo o de preocuparse de si su dispositivo es seguro, prefiere ir a la tienda y comprarse lo primero que le aconsejan o le gusta. A fin de cuenta, lo que dicen los medios, los periódicos o los blog de algún loco (como un servidor) sobre la importancia de la seguridad, parece que es algo que jamás les afectará a ellos, a fin de cuenta cuantos hackers hay en el mundo? Y por descontado que los que haya están entretenidos en acceder a datos de personas más importantes. ¿Seguro señores? Hay una diferencia muy grande entre lo que se puede hacer, se hace y de que es de lo que realmente se entera uno. Cualquier dispositivo con iOS de los que he citado que se encontrase a merced, se le podría hacer lo que uno quisiese, desde realizar llamadas al extranjero, enviar SMS, copiar de ellos la información que deseásemos… o simplemente eliminarle de sus terminales todo aquello que nos apeteciese en ese momento. Por supuesto la imaginación es el límite, podríamos usar el GPS para conocer la ubicación exacta de dicha persona, robar datos de sus cuentas de correo… en fin, creo que nos hacemos más o menos una idea.

Muchos pueden creer que este tipo de cosas son ciencia ficción, que simplemente nadie se molesta en ello o que como digo hay que ser un gran Hacker para llevar a cabo una hazaña así. Pues señores, no es así. Personalmente no me considero un Hacker, y sin embargo me resultaría tremendamente sencillo bloquear o robar la información que desease de unos cuantos de miles de iPhone de toda España. Claro aquí es donde entran los porcentajes y la importancia real de la seguridad. Todo es cuestión de números. Si logramos encontrar un fallo de seguridad, aunque tan solo afecte a por ejemplo un 1% de la población mundial, estaría afectando a más de 60 millones de personas. Pensar por un momento lo que sería tener la agenda o el control de aunque fuese tan solo 1.000 iPhones, 1000 vidas que hay detrás de ellos con sus secretos, su intimidad, sus trabajos o estudios, sus… Aunque solo fuesen 1.000 afectados o 100!! El daño que se puede producir es descomunal. Es por eso y no por otra cosa por la que la seguridad debe de ser un pilar tan importante… y más aun la educación de las personas en dichas lides.

Volviendo al tema que nos atañe, puedo decir que el juego ya ha empezado ;), en este caso por Orange, aunque el plato fuerte sin duda alguna será Movistar. ¿Ahora mismo? Pues digamos que apenas he comenzado por Orange, y ahora mismo ya se deben de contar por centenas. ¿Cuando termine el juego? Bueno, al igual que en el artículo anterior daré los datos obtenidos en forma de números y porcentajes, no en forma de IPs. Es cuestión de ser prudente, cualquier lector comprenderá que si saco un listado de los iPhone de España en los que en ese momento son completamente vulnerables y como tener control total sobre ellos, más de uno le va a faltar el tiempo para hacer cosas que no debería de hacer, y quien piense que no es así es que no conoce como funciona esa… ideosincrasia tan especial que muchos tienen en este país. De todos modos dar la información no es ningún delito, así que cuando llegue el momento estudiaré que publico o que no publico. A fin de cuenta también puede ser divertido…

Continuará…

Proyecto: Escaner completo a las redes de los ISP Españoles (Finalizado)

Share on Google+Share on FacebookTweet about this on Twitter

Para más información ver aquí

Ono

Pool IP: 2.785.536 direcciones IP
Estado: 100% Analizado -> 2.416.896 IPs/1.857.024 Host activos aproximadamente

Hosts “expuestos”: 142.922 -> 7.7% (Sobre el total de host activos analizados)
Hosts Vulnerables: 110.372 -> 5.94% (Sobre el total de host activos analizados)

*Entendiendo como Host cualquier dispositivo de red, sea un PC, un router…
*El dato “Hosts Activos” no es del todo preciso. Los porcentajes se basan sobre estos


TELEFÓNICA

Pool IP: 9.928.636 direcciones IP
Estado: 100% Analizado -> 9.928.636 IPs/6.619.091 Host activos aproximadamente

Hosts “expuestos”: 1.270.407 -> 19.19% (Sobre el total de host activos analizados)
Hosts Vulnerables: 1.090.850-> 9.22% (Sobre el total de host activos analizados)

*Entendiendo como Host cualquier dispositivo de red, sea un PC, un router…
*El dato “Hosts Activos” no es del todo preciso. Los porcentajes se basan sobre estos

 

ORANGE (France Telecom)

Pool IP: 2.351.616 direcciones IP
Estado: 100% Analizado -> 2.185.952 IPs/1.567.744 Host activos aproximadamente

Hosts “expuestos”: 9.657 -> 0.62% (Sobre el total de host activos analizados)
Hosts Vulnerables: 3.372 -> 0.21% (Sobre el total de host activos analizados)

*Entendiendo como Host cualquier dispositivo de red, sea un PC, un router…
*El dato “Hosts Activos” no es del todo preciso. Los porcentajes se basan sobre estos

 

JAZZTEL

Pool IP: 1.463.318 direcciones IP
Estado: 100% Analizado -> 1.463.318 IPs/975.545 Host activos aproximadamente

Hosts “expuestos”: 471.520 -> 48% (Sobre el total de host activos analizados)
Hosts Vulnerables: 465.456 -> 47.7% (Sobre el total de host activos analizados)

*Entendiendo como Host cualquier dispositivo de red, sea un PC, un router…
*El dato “Hosts Activos” no es del todo preciso. Los porcentajes se basan sobre estos

 

VODAFONE

Pool IP: 2.043.273 direcciones IP
Estado: 100% Analizado -> 2.043.273 IPs/1.362.182 Host activos aproximadamente

Hosts “expuestos”: 654.795 ->48% (Sobre el total de host activos analizados)
Hosts Vulnerables: 599.941 -> 44% (Sobre el total de host activos analizados)

*Entendiendo como Host cualquier dispositivo de red, sea un PC, un router…
*El dato “Hosts Activos” no es del todo preciso. Los porcentajes se basan sobre estos

Proyecto: Escaner completo de las redes de los principales ISP Españoles

Share on Google+Share on FacebookTweet about this on Twitter

Esto era algo en lo que quería embarcarme hacía ya un tiempo. Todo este tiempo he hablado entre otras cosas de lo importante que es la seguridad y bla bla bla, pero nunca he tenido realmente datos tangibles que demuestren realmente cuan seguras son las redes de los millones de hogares (incluyendo a empresas y PYMES) españoles. Evidentemente, hacer un examen a fondo de ello es completamente imposible, hablamos de millones y millones de conexiones!! y tanto el tiempo como mis recursos son finitos. No obstante, espero poder llevar a buen puerto un examen cuanto menos superficial de los principales ISP españoles, y aunque no pueda profundizar demasiado en cada equipo/sistema, si intentar abarcar la gran mayoría de todo el territorio español, y así poder tener una visión mucho más amplia de todo

Por otro lado, sería imprudente y poco “ortodoxo” por mi parte realizar un examen con mayor profundidad, o incluso realizar prácticas más “intrusivas” que pudiesen molestar a más de uno, por no decir que con mucha probabilidad no sean legales. Como siempre, mi intención no es molestar a nadie ni causar dolores de cabeza. Lo cierto no obstante (y sin querer parecer pedante), es que con los primeros resultados que estoy obteniendo me resultaría tremendamente sencillo hacer que la palabra “Theliel” apareciese dentro de unos días en más de un medio.

Quiero dejar claro que hasta donde voy a llegar es completamente legal, que los datos obtenidos tan solo van a ser publicados en forma de números/estadísticas (y no precisamente de IPs), pero espero poder publicar información suficiente para poner al menos los pelos de punta a más de uno. Cuando a lo mejor hablas de que un 1% de los equipos son vulnerables (y con vulnerables me refiero por ejemplo a “controlar” todo lo que hacen), parece un porcentaje muy pequeño, a fin de cuenta de cada cien solo hay uno. En cambio, cuando hablamos de un millón de objetivos, si hablamos de un 1% son 10.000 equipos que pueden ser fácilmente controlables. 10.000!! es una cifra verdaderamente alta si tenemos en cuenta lo sencillo que puede resultar llevar a cabo algunos ataques informáticos. De todos modos como he dicho el objetivo es simplemente tener una perspectiva general.

Los pasos serán los siguientes:

  1. Obtener el Pool de direcciones IP de los ISP
  2. Escaneado completo del Pool de cada ISP
  3. Filtrado de los datos
  4. Algunas pruebas aleatorias sobre los resultados obtenidos
  5. Finalizar


He comenzado con ONO, y estoy en su fase 2. Solo puedo decir por ahora que el pool de direcciones de este es de cerca de dos millones y medios, espero poder tener listo mañana el pool de telefónica, aunque presumiblemente no termine con ONO hasta dentro de 2 o 3 días.


Sinceramente, tengo una curiosidad malsana de ver los resultados finales

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.