Interfaz wireless desactivada al utilizar power injector en APs Cisco

Cuando se utiliza el AP con power injector instalado, puede suceder que la interfaz wireless se encuentre deshabilitada. Esto se puede observar en los logs del dispositivo ejecutando el comando:
#show logging
El error que se encontrará será similar al siguiente:

*Feb 28 21:00:10.622 GMT-3: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to down
*Feb 28 21:01:09.497 GMT-3: %CDP_PD-2-POWER_LOW: All radios disabled - LOW_POWER_CLASSIC_NO_INJECTOR_CONFIGURED WS-C2924-XL (00d0.bbd6.1b4e)
*Feb 28 21:01:09.497 GMT-3: -Verify the required power-injector is installed on this port: WS-C2924-XL(Fas 0/13).
*Feb 28 21:01:09.497 GMT-3: -If a power-injector is installed, issue the command:"power inline negotiation injector installed"

En este caso, el AP indica que no cuenta con la energía necesaria y por eso deshabilita la interfaz wireless. El problema es que no detecta que se encuentra energizado mediante power injector.

Para solucionar el problema, el AP necesita que se explicite la MAC address del port del switch en el que se encuentra conectado el power injector. Dicha MAC se puede observar en el log anterior, en la línea:

%CDP_PD-2-POWER_LOW: All radios disabled - LOW_POWER_CLASSIC_NO_INJECTOR_CONFIGURED WS-C2924-XL (00d0.bbd6.1b4e)

La dirección en que el injector se encuentra conectado se debe ingresar a través de la configuración del switch, ejecutando el siguiente comando:

(config)#power inline negotiation injector 00d0.bbd6.1b4e

Luego de esperar un minuto o dos, la interfaz de radio debería encontrarse habilitada nuevamente. Para checkearlo se puede ejecutar el comando:

#show interfaces dot11Radio 0

y la respuesta debe ser:

Dot11Radio0 is up, line protocol is up

Nueva extensión para Firefox: Firesheep

La llegada de Firesheep (una extensión de Firefox que automatiza algo que se podía hacer manualmente utilizando Wireshark desde hace años) revolucionó el mundo. Firesheep permite capturar cookies de otras personas esnifeando redes inseguras para luego loguearse en sus cuentas Web. Por ejemplo, me conecto a una red insegura (como una red inalámbrica abierta), luego "pepito" (que se encuentra conectado a la misma red) se loguea en facebook, utilizando Firesheep obtengo la cookie de "pepito" en facebook y a continuación entro a la cuenta de "pepito" en facebook. Así de simple.

El éxito de esta herramienta radica en que basta hacer un par de clics para robar una cuenta Web, algo al alcance de cualquiera, a diferencia de: abrir Wireshark; capturar tráfico de la red insegura; filtrar la captura; copiar el contenido de una cookie; insertar la cookie en el navegador; y finalmente ingresar al sitio.

Debido a esto, creo, va a provocar un caos en las redes inalámbricas abiertas ya que ahora cualquier afiliado al PAMI te hace un session hijacking con 2 clics, que bien :). Aunque por el momento sólo está disponible para Windows y Mac OS, que mal :(

Cabe destacar que esto no es sólo una vulnerabilidad de las redes inalámbricas abiertas, sino que aplica también para las redes cableadas no switcheadas (y switcheadas también, haciendo un previo ataque ARP poisoning).

Pueden ver un video sobre esta herramienta en acción aquí.

Lo más interesante de esta clase de vulnerabilidad es que pone en tela de juicio la seguridad de la llamada """Web 2.0""" y el nivel de adopción de SSL. Un estudio realizado por Digital Society clasificó el nivel de seguridad de los sitios más importantes como Facebook, Google, Twitter, Hotmail, etc. Les recomiendo leer este excelente artículo: Online services security report card. Como siempre, Google a la vanguardia:



Espero que sirva para concientizar, y la próxima vez que se conecten a una red inalámbrica abierta no envíen credenciales sin utilizar HTTPS!

Saludos!

Configurando una red inalámbrica hogareña

Luego de un período con grandes cambios a nivel personal, vuelvo a tener tiempo (y ganas) de escribir un artículo. En este caso para contar mis experiencias configurando mi red inalámbrica hogareña.

Para comenzar el desarrollo de la red hace falta conseguir lo más importante, que es el router inalámbrico. La marca/modelo a comprar depende del área a cubrir y el dinero que dispongamos. En mi caso opté por un router TP-LINK TL-WR340G ya que sólo me interesa cubrir mi departamento y es una opción super económica.

La configuración de este router es extremadamente sencilla: conectamos el cable de red de nuestro ISP al router; conectamos nuestra PC/Notebook (utilizando una IP fija 192.168.0.0/24) a una boca ethernet del router; y finalmente ingresamos por Web al router ingresando 192.168.1.1 en nuestro navegador.

La interfaz Web es muy intuitiva y haciendo unos pocos clics ya tenemos la red inalámbrica funcionando con DHCP. Lo más importante son dos cuestiones. La primera: dependiendo del servicio de Internet contratado, será necesario configurar PPPoE (Point-to-Point Protocol over Ethernet) para conectarse al ISP (con un nombre de usuario y contraseña otorgados por el proveedor). La segunda: habilitar la seguridad Wireless en el router (autenticación y encripción). A pesar de que WEP es mejor que nada, es un protocolo que posee varias debilidades, por lo tanto es altamente recomendable utilizar WPA/WPA2. Basta con seleccionar WPA-PSK (PSK: Pre-Shard Key, autenticación mediante clave compartida) en el router y utilizar una clave fuerte (formada por letras mayúsculas, minúsculas, números, símbolos y lo suficientemente larga).

Luego de configurar el router (la parte sencilla) la tarea de configurar los clientes no fue tan trivial.

El primer cliente fue una Notebook con Windows XP instalado de base con su placa de red inalámbrica funcionando correctamente. Para conectarlo a nuestra red simplemente hacemos clic derecho sobre el ícono del adaptador de red inalámbrico en la barra de tareas, luego clic en "Ver redes inalámbricas disponibles", luego seleccionamos nuestra red, clic en "Conectar" e introducimos la contraseña dos veces. Hasta acá muy fácil y bonito.

El siguiente cliente fue una Notebook con Ubuntu 9.04. Esta versión de Ubuntu ya incorpora los drivers para la placa de red Realtek RTL8187B y funciona correctamente. Pero los problemas comenzaron al tratar de conectarse a una red protegida con WPA. Ya sea utilizando el administrador de redes "network-manager" o "Wicd", la conexión se pierde luego de un corto lapso de tiempo. El error se repite una y otra vez. Luego de investigar un tiempo en Internet supe que se trata de un problema de autenticación (bastante común entre los usuarios de esta distro) entre gnome-keyring/Dbus/Network Manager. Para solucionarlo le otorgué permisos para utilizar adaptadores inalámbricos al usuario en cuestión desde el menú "System > Administration > Users and Groups". Luego de esto, utilizando Wicd, la red comenzó a funcionar "más o menos bien" aunque tarda mucho tiempo en detectar y conectarse a la red y sufre alguna desconexión esporádica.
La solución a implementar para que la red funcione perfectamente en este sistema operativo es la misma que describo más adelante para Slackware.

El próximo cliente fue una PC con Windows XP. Como no tenía un adaptador de red inalámbrico decidí comprar uno USB (la solución más económica y práctica para mis necesidades). Luego de conectar el dispositivo cometí el error de instalar los controladores directamente desde el disco compacto que incluía en la caja. Este instalador agregó un horrible manejador de redes inalámbricas en la barra de tareas que reemplazó al manejador de redes inalámbricas de Windows. Luego de la clásica reiniciada, el manejador no detectó ninguna red y no me permitió utilizar el de Windows. Por lo tanto tuve que desinstalar los controladores, reiniciar y comenzar de nuevo, esta vez utilizando el "Asistente para agregar hardware" en lugar del instalador del CD. Cuando se abre el asistente insertamos el CD y presionamos en "Siguiente". Luego de que Windows detecta los drivers que se encuentran en el CD, seleccionamos el driver de acuerdo a nuestra versión de Windows y continuamos con la instalación.
Una vez instalado el hardware utilizamos (previa reiniciada) el manejador de redes inalámbricas de Windows que se encuentra en la barra de tareas y nos conectamos perfectamente a nuestra red (esta vez sin utilizar el horrible manejador de redes incorporado en el CD del fabricante) como para el caso del primer cliente.

Luego de renegar con Windows y Ubuntu me puse el overol para aprender cómo funcionan las cosas de la mano de Slackware. La versión 13.1 instalada en la PC incorpora los drivers para el adaptador USB (utiliza el mismo chip Realtek RTL8187B de la notebook) por lo tanto la red inalámbrica funciona perfectamente.
Ya que vamos a conectarnos a una red inalámbrica con seguridad WPA, no basta con utilizar iwconfig para configurar el adaptador, es necesario utilizar wpa_supplicant. WPA Supplicant es el componente del protocolo IEEE 802.1X/WPA utilizado en las estaciones cliente. Implementa la negociación de claves con un autenticador WPA (en este caso nuestro router). Funciona como un demonio que se ejecuta en background y actúa como un componente back-end que controla la conexión wireless. En Slackware 13.1 viene incluido en la instalación base y en las distribuciones basadas en Debian lo provee el paquete wpasupplicant.
wpa_supplicant toma la configuración de las redes inalámbricas con seguridad WPA desde el archivo /etc/wpa_supplicant.conf. Para agregar una red en este archivo se utiliza el comando wpa_passphrase con el SSID de la red como parámetro:

$ wpa_passphrase myssid

Este comando lee la clave compartida de la red WPA (la misma que ingresamos en el router) por la entrada estándar y genera la clave encriptada para almacenar en el archivo /etc/wpa_supplicant.conf (para no tener que escribir la contraseña cada vez que nos conectamos a la red). Copiamos la salida de wpa_passphrase y la pegamos al final del archivo /etc/wpa_supplicant.conf.
Luego de estos pasos podemos conectarnos a la red inalámbrica:

# iwconfig wlan0 essid "myssid"
# ifup wlan0
# wpa_supplicant -iwlan0 -c/etc/wpa_supplicant.conf
# dhcpcd wlan0

El cliente WPA Supplicant es bastante vervoso e imprime por salida estándar todos los pasos durante la autenticación con el AP. Luego podemos verificar que la red haya tomado una dirección IP desde el AP utilizando el comando ifconfig.

Parece una tarea tediosa, pero el aprendizaje es invaluable y la red funciona excelentemente.

Aunque si no desean escribir estos 4 comandos cada vez que se conecten a la red, en Slackware pueden agregar un script en /etc/rc.d que lo haga automáticamente o en las distribuciones basadas en Debian pueden editar el archivo /etc/network/interfaces:

auto wlan0
iface wlan0 inet dhcp
up wpa_supplicant -iwlan0 -c/etc/wpa_supplicant.conf -Bw
down killall wpa_supplicant

La opción -B pone el demonio wpa_upplicant en background y la opción -w le indica que no haga anda hasta que la interfase esté levantada.

Luego de esta tarea tengo mi red inalámbrica funcionando en perfectas condiciones. A aquellos usuarios de Linux espero que les sirva la info y a los de Windows, bueno... nadie es ferpecto.

Saludos!


P.S.: Perdón por las screenshots!


Referencias:

• http://hostap.epitest.fi/wpa_supplicant/
• http://www.enterprisenetworkingplanet.com/netsecur/article.php/3594946/Linux-on-Your-WLAN-Configure-WPA.htm

Configurar APs Wireless Cisco

Después de una intensa lucha con el AP Wireless Cisco (ver el artículo anterior), logré configurarlo de forma satisfactoria, y como de costumbre, comparto la experiencia en el blog por si alguien más debe enfrentar este reto =)

En los siguientes pasos mostraré cómo configurar un Access Point Cisco Aironet de la serie 1240 (probablemente funcione en otros), para que utilice autenticación Radius, manejo de claves WPA y encripción AES (es decir, utilizar el estándar WPA2). Son el resultado de horas de lectura de artículos y manuales, así que espero que les sirva =)

Lo primero que haremos es revisar que el AP tenga instalado un IOS que funcione como autónomo:

ap # show version

Si el IOS es uno Lightweight, conseguir un IOS que funcione en modo autónomo y realizar los pasos explicados en Revertir Lightweight (LWAPP) Mode a Autonomous Mode para configurar APs Cisco.

Utilizando el IOS en modo autónomo, realizar los siguientes pasos. Tener en cuenta el prompt para saber donde estamos parados. Por ejemplo ap(config) indica que estamos en la configuración global, ap(config-if) es la configuración de interfaz, ap(config-ssid) es la configuración del SSID, etc.

1) Configurar la autenticación con el servidor radius (en el ejemplo 192.168.1.111):

ap(config) # radius-server host 192.168.1.111 auth-port 1645 acct-port 1646 key 7 password-con-radius

deberán colocar el password que utilizan en el servidor Radius para autenticar dispositivos.

2) Habilitar el nuevo modelo de autenticación, autorización y contabilización:

ap(config) # aaa new-model

3) Definir un grupo de servidores Radius:

ap(config) # aaa group server radius mis-radius

utilizaremos este grupo para configurar la autenticación.

3.1) Agregar el/los servidor/es que realizará/n la autenticación (paso 1) al grupo recién creado:

ap(config-sg-radius) # server 192.168.1.111 auth-port 1645 acct-port 1646

4) Crear el método de autenticación eap_auth y agregar el grupo de servidores Radius:

ap(config)# aaa authentication login eap_auth group mis-radius

con esto ya tenemos configurado un método de autenticación que luego asignaremos al SSID.

5) Configurar un SSID para el AP (es posible tener múltiples SSID). En el ejemplo lo llamaremos AP_Wireless (si, muy original...):

ap(config)# dot11 ssid AP_Wireless

5.1) Utilizar autenticación open eap (Extensible Authentication Protocol) con el servidor Radius del grupo de servidores mis-radius (ver pasos 1 - 3):

ap(config-ssid)# authentication open eap eap_auth

Existen varios tipos de autenticación y Cisco permite una buena variedad. EAP nos permite que la autenticación la realice un servidor externo, y no el mismo AP.
Que la autenticación sea open no quiere decir que los datos viajen planos, sino que esta es la forma en que Cisco define el tipo de autenticación que no utilizan protocolos Cisco (LEAP).

5.2) Realizar la administración de claves con WPA:

ap(config-ssid)# authentication key-management wpa

5.3) Utilizar el modo guest para que la antena haga broadcast del SSID. Si no desean divulgar el SSID, saltear este paso:

ap(config-ssid)# guest-mode

5.4) Setear el intervalo entre beacons DTIM. Estos beacons se envían a los clientes para que despierten y checkeen si tienen paquetes pendientes. Intervalos DTIM largos permiten preservar energía.

ap(config-ssid)# mbssid guest-mode dtim-period 75

6) Configurar la interfaz wireless para que autentique clientes utilizando Radius y WPA:

ap(config)# interface Dot11Radio0

6.1) Definir el algoritmo de encripción (AES):

ap(config-if)# encryption mode ciphers aes-ccm

6.2) Asociar el SSID a la intefaz:

ap(config-if) # ssid AP_Wireless

Con los pasos anteriores el AP ya está configurado y listo. Si no poseen un servidor DHCP en la red, o bien si quieren fijar una dirección IP al AP, pueden hacerlo de la siguiente forma:
1) Acceder a la interfaz virtual BVI 1 (Bridge-Group Virtual Interface):

ap(config)# interface BVI 1

esta interfaz virtual agrupa todas las interfaces que estén en el grupo bridge 1.

2) Configurar la dirección IP y la máscara:

ap(config-if)# ip address 192.168.1.80 255.255.255.0

3) Definir el gateway:

ap(config)# ip default-gateway 192.168.1.1

Algo a tener en cuenta es que por defecto tanto la interfaz wireless como la fast ethernet están en el grupo bridge 1, pero si no lo están, pueden configurarlo de la siguiente forma:

ap(config)# interface FastEthernet 0
ap(config-if)# bridge-group 1
ap(config-if)# exit
ap(config)# interface Dot11Radio0
ap(config-if)# bridge-group 1

Referencias

- Cisco IOS Software Configuration Guide for Cisco Aironet Access Points
- EAP Authentication with RADIUS Server
- Autonomous APs: Network EAP vs. Open with EAP, the right combination
- Cisco 802.11 Wireless Networking: Installing and Configuring Access Points
- Configuring Cisco Aironet in Home Lab - Part 2
- Configuring WPA and WPA2 on Cisco Aironet

Revertir Lightweight (LWAPP) Mode a Autonomous Mode para configurar APs Cisco

Una vez más me toca enfrentar un reto Cisco, en esta ocasión con los access point (AP) Wireless de la serie 1240. Cuál es el reto? hacerlos funcionar!!!
Si, hacer funcionar uno de estos dispositivos no resultó ser tan simple como "leer el manual -> enchufarlo -> configurarlo", nono, porque el manual no explica un pequeño detalle extremadamente importante: los dispositivos traen un IOS pensado para recibir la configuración a través de Wireless LAN Controllers (otros dispositivos Cisco $$$, pensados para controlar centralizadamente todos los APs de la red).
Qué quiere decir esto? que no podemos configurar los condenados APs si no contamos con un Wireless LAN Controller (WLC)!!! Es una pena que los manuales de estos bichos no expliquen ésto y te hagan perder tiempo haciendo pruebas inútiles. Todos dicen lo mismo y no te aclaran que el f*cking aparato puede estar en modo Lightweight. El resultado es que como no tenemos un WLC y el AP está en modo Lightweight, no tenemos configuración Web, es más, ni siquiera contamos con el modo de configuración desde consola! Nunca imaginé encontrar un "command not found" al ejecutar "configure terminal" en un IOS...

En fin, después de perder un día leyendo información, encontré el problema que les comento. Ahora, cómo volvemos al modo autónomo para que podamos configurarlo sin tener un WLC? Creo que la respuesta salta a la vista: instalar otro IOS. Pero cómo instalamos otro IOS si el IOS actual ni siquiera posee comandos básicos como copy? Booteando una imagen por TFTP.

Los siguientes pasos están basados en los que encontré en la sección Reverting from LWAPP Mode to Autonomous Mode y permiten instalar una nueva imagen (que posea modo autónomo) en un AP Cisco:

1- Montar un servidor TFTP en la máquina que utilizaremos para configurar el AP. Pueden encontrar los pasos de cómo hacer esto en el artículo Server TFTP + Actualización IOS.
2- Dar al servidor TFTP una IP del rango 10.0.0.2 a 10.0.0.30. El AP se autoconfigura con la IP 10.0.0.1.
3- Copiar la nueva imagen del IOS a la carpeta del servidor TFPT y renombrar dicha imagen a c1200-k9w7-tar.default para APs de la serie 1200, c1240-k9w7-tar.default para la serie 1240, etc.
4- Enchufar un cable UTP desde el AP a la placa de red de la máquina con el servidor TFTP.
5- Apretar y mantener apretado el botón MODE mientras se enchufa el AP.
6- Mantener apretado el botón MODE hasta que la LED de estado se pone en rojo (o lila en los 1240; esto sucede luego de 20 o 30 segundos). En la consola aparecerá el cartel "button is pressed, wait for button to be released...".
7- Esperar hasta que se termine de copiar la nueva imagen en la flash del AP.
8- Reiniciar y ejecutar "show version" para comprobar que la imagen es la correcta.

Como se darán cuenta, una vez que booteamos desde la imagen por TFTP, esta imagen se copia en la flash y reemplaza la que tenia antes.

Una vez que contamos con la imagen en modo autónomo, podemos configurar el AP de la siguiente forma:
- Enchufar el AP a una red que cuente con DHCP para que el dispositivo tome IP.
- Elegir alguna de las siguientes opciones de configuración:

Opción 1 (Web):

- Acceder a la interfaz Web de configuración del dispositivo y loguearse con las credenciales Cisco/Cisco. La dirección de la interfaz web será la que les entregó el DHCP.

Opción 2 (consola):

- Configurar el dispositivo conectándose a la consola a través de un cable serie, utilizando una terminal virtual con la configuración "8 bits, paridad none, 1 bit de parada, y sin control de flujo" (pueden utilizar minicom, como explico en este otro artículo - http://itfreekzone.blogspot.com/2010/09/acceder-dispositivos-cisco-desde.html), y ejecutar:

ap> enable # el password es Cisco
ap # configure terminal

NOTA: si no poseen servidor DHCP en la red, pueden clavarle una IP al AP a través de la consola. Para ello, conectense utilizando la configuración que expliqué en el punto anterior y ejecutar:

ap> enable # el password es Cisco
ap # configure terminal
ap(config) # interface FastEthernet 0
ap(config-if) # ip address <ip> <mascara>

Una vez que el dispositivo cuenta con IP, pueden acceder a la interfaz web.

Como siempre, espero que este artículo les ayude a ahorrar tiempo y entender rápidamente cómo configurar esta clase de dispositivos!

news: cracking paquetes invisibles

El mismo día leo dos interesantes noticias sobre cracking de algoritmos utilizados para la transmisión wireless, ambos con implicaciones muy graves.

Por un lado me encuentro con que científicos japoneses dicen haber desarrollado una forma de romper WPA en 60 segundos! Para el que no lo sepa WPA (Wi-Fi Protected Access) es un protocolo para la transmisión segura de datos a través de una red wireless creado para suplir el fiasco de su predecesor, don me rompo todo WEP (Wired Equivalent Privacy). Si bien ya se habían evidenciado problemas con WPA en noviembre del año pasado, los muchachos japoneses se encargaron de llegar más allá y romper todo... unos maestros.
Actualmente, el protocolo más seguro es WPA2, que un algoritmo basado en AES, el cual es considerado completamente seguro (por ahora...).
Así que están avisados, si van a comprar un Access Point o algún otro hard wireless, asegúrense que soporte WPA2 y no la porquería WEP o el próximamente desechable WPA.


Por otro lado, me encuentro con algo aún más interesante. En la reciente conferencia Hacking at Random (HAR), un hacker detalló sus planes para crackear el estándar de encripción para celulares utilizado en GSM, conocido como A5/1!... qué quiere decir ésto? bueno, que alguien con el equipamiento adecuado (no demasiado caro) podrá escuchar llamadas GSM... osea, nuestras conversaciones por celular! yeah muchachos, ya nada será privado y nos podrán espiar hasta cuando hablemos a escondidas... a aquellos que anden de trampa con algún amante, les sugiero dejar de usar el cel =P
Si bien ya existían varios hacks teóricos al protocolo, este sería el primero en volverse realidad y en menos de 6 meses podríamos tener gente robando números de tarjeta, información de empresas, o cualquier cosa que hablemos/mensajiemos por celular.

Hacking Bluetooth: ni tan fácil, ni tan imposible

Después de varios años me modernicé y por fin tengo un celular que soporta la ultra conocida y usada tecnología bluetooth. Luego de jugar un rato con las opciones, la paranoia empezó a surgir y por supuesto, no pude dejar de pensar en "qué tan seguro es ésto?" (y si, siendo admin de seguridad uno se pone más y más paranoico). Así que hoy con un poco de tiempo libre, me puse a investigar el tema y encontré lo que sospechaba... hackear usando bluetooth no es extremadamente sencillo, pero no es imposible.
Lo que más me gusta de la idea es que hoy en día, prácticamente todo celular medianamente interesante, trae bluetooth incorporado, y celulares hay a montones, así que es fácil experimentar y descubrir cosas.


Definiciones

Hay varias definiciones "estándar" dando vueltas por la red sobre los distintos tipos de hacking:

bluejacking: el menos dañino de todos, yo lo consideraría algo así como un sistema para divertirnos un rato, aunque por supuesto, puede tener una funcionalidad que apeste a SPAM. Bluejacking trata sobre crear un contacto de teléfono o una tarjeta de trabajo y enviarlo a un celular a través de bluetooth. El contacto puede llamarse algo así como "te bluejackiaron" y el que lo reciba no va a entender nada. El dark side de esto, como bien dije, es el SPAM. Uno puede enviar contactos cuyo nombre sea una propaganda de algo, a todo el que pase cerca de un emisor bluetooth. Dado que se envía masivamente y nosotros no solicitamos el mensaje, es un clásico caso de SPAM.

bluesnarfing: en este caso nos encontramos con algo más peligroso. Bluesnarfing es el acto de acceder o robar información almacenada en el celular, como ser libreta de direcciones, calendarios, mensajes, imágenes, videos, lo que se imaginen. Por supuesto que nadie quiere que se metan con nuestra información >=(

bluebagging: simplemente, mi favorito. Bluebugging trata sobre controlar el dispositivo de la víctima remotamente, sin su autorización o conocimiento. De esta forma, un atacante puede potencialmente llamar al otro extremo del mundo, enviar mensajes, usar el celular como conexión "gratis" a internet, escuchar conversaciones... nuevamente, lo que se imaginen.

Algunas definiciones que no son tan comúnmente encontradas en la red, pero que son igualmente interesantes (con nombres inventados por su servidor) son:

blueDoS: ataque del tipo Dennial of Service, donde la interfaz bluetooth se torna inusable y nos gastan la batería. El ataque igualmente no es tan significativo porque se necesita estar cerca del dispositivo continuamente.

bluesniffing: utilizar un dispositivo para sniffear conexiones entre otros dispositivos. Hasta hace un tiempo esto se consideraba extremadamente complejo y que requería de hardware muy caro, pero ahora es posible.


No es tan fácil

Ahora, al leer el punto anterior, muchos se habrán asustado tanto como para no salir de sus casas llevando el celular (bueno, es entretenido pensar que se les ocurriría algo tan descabellado =D), así que para que no se vuelvan locos de paranoia (como sucede al hablar de virus), les dejo algunos datos interesantes de por qué no es tan fácil hackear dispositivos bluetooth.
Es importante destacar que las especificaciones Bluetooth son desarrolladas y licenciadas por el Bluetooth Special Interest Group (SIG), el cual se encarga de velar por la seguridad de la tecnología. Algunos de los miembros más activos en el SIG son Ericsson, Lenovo, Intel, Microsoft, Motorola, Nokia y Toshiba. Ericsson, Lenovo (antes como IBM) e Intel fueron los fundadores del SIG.

En primer lugar tenemos las limitaciones físicas:

- La limitación más importante es el corto alcance. Los dispositivos pequeños (como los celulares) tienen un alcance cercano a 10mts, y otros más grandes como las notebooks pueden llegar hasta 100mts. Como se imaginarán, 10mts es muy corta distancia, y el atacante deberá estar muy cerca de sus víctimas. Igualmente en lugares donde concurre mucha gente, como los shoppings, cafés, etc, sería relativamente fácil encontrar víctimas.

- El ancho de banda. Bluetooth cuenta con un ancho de banda de entre 723.2 Kbps y 2.1Mbps. Si bien éste ancho de banda alcanza para transmitir archivos pequeños, tardaría siglos en transmitir archivos grandes o muchos archivos. Además el ancho de banda limita el hacking por fuerza bruta.

- El usuario puede activar y desactivar la funcionalidad bluetooth. Claramente un usuario que no tiene bluetooth habilitado, no puede ser hackeado. Aunque por supuesto, muchas veces (me ha pasado), activamos la funcionalidad bluetooth para transferir hacia/desde otro dispositivo y luego olvidamos desactivarla.

Por otra parte tenemos la seguridad impuesta en los protocolos bluetooth:

- Bluetooth cuenta con cuatro modos de funcionalidad:
# Mode 1: non-secure. No se aplica ninguna medida de seguridad, los dispositivos no emplean ningún mecanismo para prevenir que otros establezcan conexiones.
# Mode 2: seguridad forzada a nivel de servicio. Se inician procedimientos de seguridad después de establecer el link LMP pero antes de que se establezca el canal L2CAP (L2CAP sería como el TCP y UDP de bluetooth).
# Mode 3: seguridad forzada a nivel de enlace. El dispositivo bluetooth debe iniciar procedimientos de seguridad antes de que se establezca el link físico.
# Modo 4: seguridad forzada a nivel de servicio, similar al modo 2, en el cual los procedimientos de seguridad se inician luego de establecer el linkeo. En este caso se utiliza Secure Simple Pairing (SSP) que simplifica el proceso de pareo y mejora la seguridad.

Son las compañías que desarrollan el dispositivo las encargadas de utilizar un modo u otro. Por supuesto, menos seguridad suele asegurar mayor facilidad de uso (un clásico). Por esto es recomendable no dejar de lado la seguridad e imponer aunque sea el modo 2 para que no nos rompan todo sin que nos enteremos.

- El usuario puede setear su dispositivo como oculto. Que un dispositivo esté oculto significa que no anda gritando contínuamente diciendo "aquí estoy! - soy BT Cell", algo que sí hace en modo visible. El modo visible facilita que otros dispositivos encuentren fácilmente al nuestro, dado que de otra forma deberían conocer la MAC con anterioridad.
Igualmente oculto no significa invisible, como acabo de decir, si alguien conoce la MAC, puede intentar acceder al dispositivo. La MAC es un identificador de 48bits de los cuales los 3 primeros bytes identifican al fabricante del dispositivo. Esto nos deja un total de 16.277.216 direcciones posibles para una marca dada. Son muchas direcciones para escanear, así que encontrar la dirección del dispositivo (debido a limitaciones de ancho de banda) podría llevar años. Si bien, algunos fabricantes suelen asignar las direcciones siguiendo alguna secuencia predecible, con lo cual se reduce el rango a escanear, siguen siendo muchas direcciones.

- Durante la comunicación entre dos dispositivos se utiliza una frecuencia de saltos de 1600 saltos/segundo, lo que permite de alguna forma evitar que un sniffer pesque una dirección MAC (las cuales, por cierto, no viajan encriptadas) y pueda seguir una conexión ajena. Cabe aclarar que los saltos son pseudo-random, así que no es imposible adivinar la secuencia.

- Si bien la comunicación entre dos dispositivos no suele contener autenticación, si hay autenticación cuando se intenta acceder a algún servicio o recurso. En algunos dispositivos suele utilizarse un PIN (passkeys) que acuerdan poner los usuarios involucrados en la comunicación. En otros casos, simplemente se le solicita al usuario autorizar la transacción.


No es imposible

Como fuí destacando en cada uno de los puntos citados en la sección anterior, todos tienen alguna falencia. Y como todo en el mundo informático, una cosa es la teoría y otra la implementación. Los fabricantes suelen cometer errores en las implementaciones dejando problemas explotables por atacantes.
Un caso interesante de falencias del fabricante es la vulnerabilidad encontrada en los modelos Nokia 6310, 6310i, 8910, 8910i, y Sony Ericsson T68, T68i, R520m, T610, Z600 (y posiblemente otros), donde robarse la libreta de direcciones es sólo cuestión de utilizar el comando obexftp, el cual es parte del estándar de bluetooth.

Por supuesto influye el factor "mi dispositivo es más fácil de usar que el tuyo", lo cual siempre acarrea que se omita algún control o se otorguen demasiadas facilidades que son aprovechables por los atacantes.
El problema más grave es que la mayoría de los celulares (hablando de celulares, NO smartphones) no traen facilidades para actualizar el firmware, por lo que una vulnerabilidad de fábrica queda impresa de por vida en miles de dispositivos.
Por otra parte, es un defecto interesante que el identificador de un dispositivo sea un nombre tipo string (cambiable fácilmente por el usuario), con lo cual un atacante que conozca el nombre de un Access Point, puede sustituirlo y engañar a quienes intenten conectarse pensando que se conectan al access point.

La mayoría de los hacks encontrados en internet requieren de ingeniería social. Es así como para lograr un bluebugging necesitaremos que el usuario acepte la recepción de un archivo. Aunque el tiempo ha dejado en claro que la gente es extremadamente susceptible a este tipo de ataques. Como lo demuestra Marek Bialoglowy en su genial artículo Bluetooth Security Review, 1 de cada 10 intentos de conexión a desconocidos fueron aceptadas! ¬ ¬

Entre las herramientas más conocidas para realizar ataques, se encuentra Super Bluetooth Hack (también conocida como BT Info) escrito en J2ME, del cual no pude encontrar mucha información sobre cómo funciona, pero algo es seguro, de hacking tiene poco dado que solo puede aprovechar vulnerabilidades en celulares viejos, y para el resto, necesita que el otro dispositivo establezca una conexión con el nuestro antes de poder hacer algo. Como cité en el párrafo anterior, la ingeniería social debe formar gran parte del ataque. En youtube pueden ver un video que muestra cómo funciona este programa.

Una herramienta más moderna es BTCrack, el cual nos permite crackear PINs y LINK-KEYs utilizando datos sniffeados en el aparejado de dos dispositivos. El PIN nos puede servir para autenticarnos ante un dispositivo que utilice un PIN hardcoded (osea, en el firmware). Por otra parte el Linkey es más útil, dado a que puede ser usado para acceder al dispositivo sin ninguna interacción del usuario. Además el Linkey nos permitirá desencriptar las tramas de datos enviadas entre los dispositivos.

Si bien, como comentaba al principio, hasta hace un tiempo sniffear una conexión bluetooth se consideraba complejo y requería hardware costoso gracias a la cantidad de saltos por segundo (1600/seg) pseudo-random entre distintas frecuencias, además de utilizar un PIN de seguridad, hace algunos meses se demostró lo contrario. Pueden leer algunos ejemplos en Construyendo tu propio sniffer bluetooth y en Sniffeando el emparejamiento bluetooth. Igualmente según comentarios que he leído, el proceso es todavía algo engorroso.

A pesar de que en la net se citan otras herramientas de hacking, la realidad es que la mayoría utilizan los protocolos estándar de bluetooth y no hacen realmente un hacking, sino que requieren nuevamente de ingeniería social para que el usuario acepte conexiones.


Acciones defensivas

Como menciona el artículo Symantec Warns Users Over Bluetooth Security, hay ciertas medidas que debemos aplicar para mantenernos relativamente seguros al utilizar esta tecnología. Las recomendaciones básicas son:

- Permanecer offline: si no estás usando bluetooth, desactivalo! Tener activada la conectividad bluetooth sin necesidad solamente implica correr riesgos innecesarios.

- Permanecer oculto: si estás usando bluetooth pero no necesitas enviar tu identificador para ser visible por otros, asegurate de que la visibilidad de tu dispositivo esté seteada a "oculto".

- Verificar transferencias entrantes: no aceptes o ejecutes archivos enviados por fuentes desconocidas a menos de que los estés esperando (como sucede con los adjuntos de los e-mails).

- Usar passwords: idealmente, utilizá un password de varios dígitos. Un PIN de 4 dígitos puede ser roto en menos de un segundo, uno de 6 llevaría cerca de 10 segundos, mientras que uno de 10 llevaría semanas.


Conclusiones

Como cualquier otra tecnología, Bluetooth tiene falencias que pueden llevar a que un atacante con experiencia y la motivación suficiente obtenga lo que desea, desde utilizar el celular de una persona para realizar llamadas de cualquier tipo, hasta robar información de contactos o mensajes de texto, lo cual puede significar un daño importante para el perjudicado. Pero como bien destaco, éste debe ser un hacker con conocimientos. La información que pude encontrar (o más bien la que NO pude encontrar) indica que más allá de herramientas simples como Super Bluetooth Hack que tiene varias limitaciones, no cualquier script kiddie puede hackear un teléfono moderno a través de bluetooth. Por supuesto que ésto no significa que debamos confiar ciegamente, dado que las falencias existen.

El ataque más factible por lejos es el bluejacking, dado que es fácilmente realizable por cualquier persona y no sería raro que en el futuro algunas empresas lo adopten como forma de SPAM.

Cabe destacar que la complejidad del protocolo (solo mirar el diagrama de capas de bluetooth hace que uno quiera pegarse un tiro) y las fallas en las implementaciones de cada fabricante son señales suficientes para pensar que todavía hay mucho por descubrir, que van a aparecer más vulnerabilidades y que los hackers estarán presentes para explotarlas. Tal es el caso de la citada herramienta BTCrack lanzada hace unos meses y que abre varias puertas, sobre todo para el sniffing.

El tiempo dirá que sucede, tal vez dentro de un tiempo salga una tecnología superior a bluetooth, todos los equipos comiencen a utilizarla y este post sirva menos que papel higiénico usado.


Algunas referencias

Guide to Bluetooth Security - Recommendations of the National Institute of Standards and Technology (Karen Scarfone, John Padgette).
Bluetooth Security Review
Type of Bluetooth Hacks and its Security Issues
Bluejacking Bluesnarfing Bluebugging Bluetoothing
Bluetomorrow - Bluetooth Security