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.