Un vistazo profundo a bluetooth y su seguridad

Como ya he dicho en anteriores entradas, la seguridad es una ciencia a la merced de las modas, a diferencia de lo que cree mucha gente, no existe nadie que se asegure de que todo sea seguro, no existen mil ojos mirando cada código de software libre, ni existen mil ojos mirando cada nuevo protocolo, no es así.

En realidad, hay poca gente que audite código, hay poca gente que se baje el código de openssl, y le busque problemas de seguridad, y la poca gente que hay: se mueve por modas. (o intereses comerciales)

Si digo todo esto, es por que mientras que a bluetooth no se le han encontrado prácticamente problemas de seguridad reales, a las redes wireless (802.11) se le han encontrado una gran cantidad de ellos.

Esto podría llevarnos a pensar que bluetooth es mas seguro que 802.11, pero en realidad no es así, en realidad es que bluetooth no lo ha examinado casi nadie a fondo, y 802.11 tiene mil ojos encima.

Y sobre eso va a tratar este artículo, sobre como funciona bluetooth y que posibles problemas de seguridad tiene.

Bluetooth es un protocolo de comunicación inalámbrica de corto alcance, es decir, un protocolo que permite comunicar sin cables, distintos dispositivos que estén cerca el uno del otro, diseñado y mantenido por el “SIG” (Bluetooth Special Interest Group) el cual es una asociación de empresas las cuales tienen un interés en esta tecnología.

Dicho de otra manera mucho mas coloquial: bluetooth es como una pequeña red wireless de corto alcance.

En nuestra vida real, estamos rodeados de bluetooth por todas partes, se suele utilizar en dispositivos de manos libre, auriculares, teclados…y sobretodo, con mucha diferencia, en móviles.

En los móviles es donde mas éxito ha tenido bluetooth, ya que permite que dos móviles intercambien datos (fotos, música, contactos…) de forma fácil y rápida, además permite que puedas acceder a los archivos de tu móvil desde tu ordenador.

Bluetooth en realidad, es una pila de protocolos, siendo el protocolo de mas abajo el que se encarga de los temas de ondas de radio etc y los protocolos de mas arriba los que se encargan de direccionamiento, datos, etc.

Empezando por abajo en la pila, tenemos el protocolo “Bluetooth Radio”, el cual define como funciona la parte de radio de bluetooth, entre otras cosas define que bluetooth funciona a 2.4GHz, la misma frecuencia que utiliza 802.11.

Una vez dos dispositivos se entienden, por que utilizan la misma frecuencia y reglas definidas por “Bluetooth Radio”, existen dos protocolos en bluetooth que ya pueden funcionar cuando se cumple ese protocolo: LMP y L2CAP.

LMP es el protocolo que se encarga de la conectividad entre dos dispositivos bluetooth, temas de calidad del servicio, etc.

Una característica importante de LMP, es que bluetooth se mueven entre 79 frecuencias diferentes, separadas cada una por 1mhz, cuando dos dispositivos bluetooth quieren hablarse por radio, primero hablan mediante una frecuencia predefinida, conocida como “control channel” (canal de control) y usando ese canal, acuerdan en que orden van a utilizar las 79 frecuencias disponibles, esto significa, que se ponen de acuerdo, por ejemplo, en decir: te enviaré el primer paquete por la 39, el segundo por la 45, el tercero por la 78…y así hasta utilizar los 79 canales y volver a empezar la secuencia.

La secuencia utilizado, se genera de forma aleatoria y se ponen de acuerdo en cual usar, mediante el canal de control, esta técnica se conoce como FHSS.

Bluetooth utiliza este mecanismo de ir saltando entre frecuencias, para complicar (como veremos mas adelante) el tema de que alguien se ponga a sniffear la conversación entre dos dispositivos.

Una vez LMP ha establecido el enlace radio, entre dos dispositivos, entra en juego el siguiente protocolo, L2CAP.

L2CAP es un protocolo que define una serie de puertos que se pueden utilizar para mandar y recibir datos mediante las capas de abajo, es decir, define una forma en la que varias aplicaciones pueden enviar datos y recibir datos utilizando las ondas de radio de bluetooth, sin confundir de quien es que, de la misma forma que tcp/ip permite que una misma ip, pueda enviar y recibir datos por el mismo cable, para distintas aplicaciones a la vez, haciendo uso de los “puertos”, por ejemplo, servidores web utilizan el puerto 80, y así, el tráfico de la web, se puede distinguir del tráfico ftp, que va por el puerto 21, aunque en realidad, todo son pulsos eléctricos por el mismo cable.

L2CAP dispone de 32767 puertos, disponibles para que las aplicaciones los utilicen, al comunicarse mediante bluetooth.

Y ya por encima de L2CAP trabaja RFCOMM un protocolo que emula las conexiones por puerto serie, dispone de 30 puertos (1 al 30) y solo puede gestionar 6 conexiones como máximo a la vez.

Supongo que después de toda al explicación, uno anda un poco perdido, pero para simplificarlo, voy a hacer una equivalencia entre las redes cableadas normales, y bluetooth, para que se vea claramente donde encaja y que hace cada protocolo:

  • “Blueooth Radio” sería el cable en si mismo
  • L2CAP sería ethernet
  • RFCOMM sería TCP/IP

Por lo cual, a las aplicaciones que se comunican usando bluetooth, les suele preocupar únicamente RFCOMM, igual que a tu navegador, le preocupa tcp/ip, y no si por debajo hay bluetooth, ethernet, o una red wireless 802.11.

Hay un concepto que nos hemos dejado en el aire, y que aparece en el gráfico: Host Controller Interface (HCI).

El HCI es la forma en la que el ordenador (o el móvil) se comunica con el dispositivo bluetooth, es decir, los dispositivos bluetooth, por ejemplo esos pequeños dispositivos usb que conectas a tu ordenador para disponer de bluetooth, tienen dentro un microprocesador, una memoria, registros, y areas de memoria donde se almacena un pequeño programa, llamado firmware, que se ejecuta dentro del procesador que tiene dentro el bluetooth, y que se encarga del tema del LMP, los saltos entre frecuencia, la conectividad por radio, etc, todos los temas de radiofrecuencia a bajo nivel.

Mientras que el L2CAP se ejecuta en el ordenador, no en el dispositivo usb, por lo cual debe existir una forma de comunicar el ordenador y con el dispositivo usb, que es quien gestiona los temas de radio.

Ese protocolo se llama HCI, para verlo mas claro:

Como se puede observar, podríamos resumir una conexión bluetooth como:

  1. Un programa en el ordenador, pide conectarse a un dispositivo bluetooth, en el puerto X
  2. La librería bluetooth del sistema, habla con el driver bluetooth
  3. El driver bluetooth, mediante HCI, habla con el dispositivo bluetooth conectado al USB
  4. El dispositivo bluetooth, inicia una comunicación por radio con el dispositivo al que queremos conectar.
  5. Mediante el canal de control, acuerdan el orden en el que van a utilizar las 79 frecuencias de radio que tienen disponibles.
  6. Ya tienen conectividad, por lo que la aplicación puede enviar datos mediante bluetooth, los cuales los recibirá el driver bluetooth, e irán a parar mediante el HCI (el enlace entre el dispositivo y el ordenador) al dispositivo bluetooth, que los convertirá en ondas de radio, y llegarán al otro dispositivo, donde sucederá todo el camino, a la inversa, hasta llegar a la aplicación que está escuchando en el otro lado.

Despues de haber visto como funciona bluetooth, sabemos que es algo muy similar a ethernet+tcp/ip, aunque con ciertas particularidades.

En primer lugar, bluetooth nos permite escanear los dispositivos que hay alrededor nuestro con bluetooth habilitado, para poder comunicarnos con ellos, sin embargo bluetooth no existen direcciones IP, se usan las direcciones MAC de los dispositivos directamente, el problema es que los seres humanos tienen problemas para memorizar direcciones IP, en el caso de TCP/IP y direcciones MAC, en el caso de bluetooth, por lo que si escaneamos en busca de dispositivos cercanos, para transferir una foto al móvil de un amigo, y nos aparecen direcciones MAC, no sabremos de todos los que aparezcan, cual es el móvil de nuestro amigo.

Por ello, bluetooth dispone de un concepto llamado “Nombre de dispositivo”, cuando un dispositivo bluetooth escanea en busca de dispositivos bluetooth cercanos, los dispositivos cercanos que contestan al escaneo, le indican cual es su nombre de dispositivo, y ese será el que aparezca en la lista, una vez finalizado el escaneo.

El nombre de dispositivo, es algo que puede configurar el usuario, en telefonía móvil, por defecto, el nombre de dispositivo es el modelo del teléfono, por ejemplo: Nokia N70.

Una vez el dispositivo tiene una lista de los dispositivos cercanos, puede consultar que “servicios” provee un determinado dispositivo, es decir, de la misma forma que un ordenador puede tener un servidor web instalado, un dispositivo bluetooth puede tener servicios que se pueden utilizar a través de el, o dicho de otra forma: existe un ftp a través de bluetooth, y se llama OBEX.

Obex es un pequeño protocolo que especifica como intercambiar archivos entre dos dispositivos bluetooth, todos los móviles modernos llevan instalado un servidor obex en algún puerto RFCOMM.

Sin embargo, como solo existen 30 puertos RFCOMM (el equivalente a tcp/ip en bluetooth), a diferencia de ftp, que se utiliza normalmente el puerto 21, no existe ningún puerto por defecto para Obex FTP, ya que hay muchos mas protocolos (no solo existe obex) que funcionan sobre bluetooth, que puertos disponibles tienen rfcomm (30), así que lo que se hace, es que existe un servicio llamado SDP que está instalado en todos los dispositivos bluetooth, y que cualquier otro dispositivo bluetooth, se puede conectar a el, y consultar que servicios tiene un dispositivo, y en que puertos rfcomm están.

Para salir un poco de tanta teoría, usando un dispositivo bluetooth usb, voy a conectarme al servicio SDP de mi móvil (un LG KU380) para consultar que servidores accesibles desde bluetooth tiene instalados, y en que puertos están.

Para ello, lo primero que voy a hacer es escanear en busca de dispositivos bluetooth cercanos:

jcarlosn@localhost:~$ hcitool scan
Scanning …
00:1F:6B:E2:24:96    Rooibo
jcarlosn@localhost:~$

Me aparece mi móvil, que tiene de nombre de dispositivo: Rooibo, y su dirección MAC: 00:1F:6B:E2:24:96, ahora, sabiendo su dirección MAC, puedo conectarme a su servidor SDP, y consultar que servicios tiene:

jcarlosn@localhost:~$ sdptool browse 00:1F:6B:E2:24:96
Browsing 00:1F:6B:E2:24:96 …
Service Name: OBEX Object Push
Service RecHandle: 0x10000
Service Class ID List:
“OBEX Object Push” (0x1105)
Protocol Descriptor List:
“L2CAP” (0x0100)
“RFCOMM” (0x0003)
Channel: 6
“OBEX” (0x0008)
Language Base Attr List:
code_ISO639: 0x656e
encoding:    0x6a
base_offset: 0x100
Profile Descriptor List:
“OBEX Object Push” (0x1105)
Version: 0x0100

Service Name: OBEX File Transfer
Service RecHandle: 0x10001
Service Class ID List:
“OBEX File Transfer” (0x1106)
Protocol Descriptor List:
“L2CAP” (0x0100)
RFCOMM” (0x0003)
Channel: 7
“OBEX” (0x0008)
Language Base Attr List:
code_ISO639: 0x656e
encoding:    0x6a
base_offset: 0x100
Profile Descriptor List:
“OBEX File Transfer” (0x1106)
Version: 0x0100

Service Name: LG Sync SPP
Service RecHandle: 0x10002
Service Class ID List:
“Serial Port” (0x1101)
Protocol Descriptor List:
“L2CAP” (0x0100)
“RFCOMM” (0x0003)
Channel: 16
Language Base Attr List:
code_ISO639: 0x656e
encoding:    0x6a
base_offset: 0x100
Profile Descriptor List:
“Serial Port” (0x1101)
Version: 0x0100

Service Name: LG Audio Gateway
Service RecHandle: 0x10003
Service Class ID List:
“Headset Audio Gateway” (0x1112)
“Generic Audio” (0x1203)
Protocol Descriptor List:
“L2CAP” (0x0100)
“RFCOMM” (0x0003)
Channel: 3
Language Base Attr List:
code_ISO639: 0x656e
encoding:    0x6a
base_offset: 0x100
Profile Descriptor List:
“Headset” (0x1108)
Version: 0x0100

Service Name: LG Audio Gateway
Service RecHandle: 0x10004
Service Class ID List:
“Handsfree Audio Gateway” (0x111f)
“Generic Audio” (0x1203)
Protocol Descriptor List:
“L2CAP” (0x0100)
“RFCOMM” (0x0003)
Channel: 4
Language Base Attr List:
code_ISO639: 0x656e
encoding:    0x6a
base_offset: 0x100
Profile Descriptor List:
“Handsfree” (0x111e)
Version: 0x0105

Service Name: LG Dial-up Networking
Service RecHandle: 0x10005
Service Class ID List:
“Dialup Networking” (0x1103)
Protocol Descriptor List:
“L2CAP” (0x0100)
“RFCOMM” (0x0003)
Channel: 8
Language Base Attr List:
code_ISO639: 0x656e
encoding:    0x6a
base_offset: 0x100
Profile Descriptor List:
“Dialup Networking” (0x1103)
Version: 0x0100

jcarlosn@localhost:~$

Son muchos servicios, pero si nos fijamos en lo que he puesto en negrita, podemos ver que hay un servidor OBEX FTP en el puerto 7 rfcomm.

Ademas hay otro servidor OBEX Object Push en el puerto 6, este otro protocolo también de obex, es similar a OBEX FTP (el cual es muy similar a un servidor ftp normal) pero mas simple, no permite listar el contenido de los directorios, y permite simplemente transferir archivos de uno en uno, estilo tftp.

Obex FTP se utiliza, normalmente, para comunicar el ordenador con el móvil, creando un directorio virtual, donde el contenido que vemos, es el del teléfono, mientras que Obex Object Push, se utiliza habitualmente para transferir contactos, imágenes, música, etc… entre dos móviles.

Sin embargo, tener en el móvil algo similar a un servidor ftp, y algo similar a un servidor TFTP, puede parecer peligroso, sin embargo, el móvil no permite que nadie se conecte a su servidor Obex Object Push, si el dueño del teléfono no acepta la conexión (le aparece una pregunta por pantalla, de si quiere aceptar el archivo), y para mas seguridad, para aceptar una conexión al servidor Obex FTP, se ha de introducir un número en el móvil, que hace las veces de contraseña, y luego introducir el mismo número en el dispositivo que intenta conectarse al servidor Obex FTP.

Es decir, que cuando a alguien le aparece en el móvil que existe un dispositivo que intenta conectarse a el (a su servidor Obex FTP) el dueño del móvil debe aceptarlo, y además, deberá pensar algún número aleatorio, e introducirlo en la caja de texto que le aparece, entonces, debe introducirse ese mismo número, en el dispositivo que intenta conectar.

Ese número se utiliza para cifrar los datos de la conexión.

Ahora que ya sabemos como va todo esto, podemos echar un vistazo al pasado…

Seguramente todos habéis oído hablar de vulnerabilidades que permiten robar información de los móviles vía bluetooth, la forma mas famosa es conocida como “bluesnarf“, la cual se basa en que algunos viejos móviles no requerían que el dueño del teléfono aceptase la conexión, para que un tercero, se conectase a su servidor Obex Object Push.

Por lo cual, lo que hacían era conectarse a tu teléfono vía bluetooth, consultar el servicio sdp para saber si hay algún servidor Obex Object Push, y saber en que puerto está, conectarse a el, y pedir los archivos de la libreta de contactos, los sms, etc…así de simple, simplemente se basa en utilizar un servidor instalado en el móvil, en un puerto bluetooth.

Ademas, algunos móviles permiten que se les envíen contactos vía bluetooth sin requerir confirmación, y ahí nació otro conecto: el bluejacking.

El bluejacking, a diferencia del bluesnarfing, no busca robar información de nadie, simplemente se basa en que alguien coge un móvil, va por la calle escaneando en busca de dispositivos bluetooth cercanos, y cuando encuentra alguno, le manda un contacto vía Obex Object Push, y en el nombre del contacto, pone alguna frase. Cuando el otro lo recibe y lo ve, lee la frase que hay en el campo nombre.

A raíz de esto aparecieron pequeñas aplicaciones (midlets) en java para móviles, que permiten definir un mensaje, y escanean sin parar vía bluetooth, envíando ese mensaje en forma de contacto, a todos los móviles con los que te cruzas. Una de ellas es EasyJack, disponible aquí.

Cuando los fabricantes de telefonos móviles reaccionaron, y empezaron a requerir que el usuario acepte la conexiones al servidor Obex Object Push, y que haga falta poner un PIN y todo eso, para conectar al servidor Obex FTP del telefono, el hacking a dispositivos bluetooth pasó a ser historia del pasado.

Sin embargo, se crearon algunas nuevas ideas para atacar móviles con bluetooth, la primera es el DoS, que consiste en buscar formas de clavar o congelar el móvil, a base de mandarle paquetes L2CAP malformados, o cosas similares.

Entorno a esta idéa, salieron varios bugs publicados, como este, que envíando paquetes L2CAP malformados, el móvil se congela hasta que lo reinicies.

Además, apareció una herramienta para GNU/Linux que, llamada bss, que crear paquetes L2CAP malformados sin parar, y los envía a la dirección bluetooth que le indiques, si en algún momento el móvil le deja de contestar los paquetes bluetooth, te dice el paquete que ha provocado que el móvil pete, con esta herramienta sacaron la mayoría de bugs de DoS a móviles.

La otra vertiente por la que se empezó a explorar la seguridad bluetooth, fue la de que ya que bluetooth son ondas de radio, nada nos debería impedir poder sniffear todas las ondas que llegan a nuestro receptor, y de ahí, espiar conversaciones bluetooth, etc.

Sin embargo, para eso existe un problema, el FHSS comentado mas arriba, es decir, el hecho de que bluetooth utiliza 79 frecuencias diferentes, entre las que va saltando de forma aleatoria, y solo el emisor y el receptor que acordaron esos saltos, saben el orden en el que se producen.

Para un dispositivo bluetooth normal, es imposible escuchar en 79 frecuencias distintas a la vez, por las que pueden estar saltando el emisor y el receptor, y a menos que conozca el orden en el que saltan, no conseguirá nada.

Sin embargo, había gente que insinuaba que se podía sniffear usando un dispositivo bluetooth normal, aún y con el problema de las 79 frecuencias, por lo cual, Max Moser, se decidió a escribir un pdf intentando desvelar si eso era posible o no.

En el PDF, utiliza un producto privativo, llamado FTS4BT, de la empresa FrontLine, que consiste en un firmware modificado para los bluetooth con chipset CSR (Cambridge Silicon Radio), un driver .sys para windows, y un programa que interactúa con el driver.

Después de eso, no tardó en aparecer un tutorial paso a paso para linux para modificar tu bluetooth usb con ese firmware.

Al poco tiempo, salió un nuevo paper sobre el tema, bastante mas completo, y muchísimo mas técnico, bastante interesante.

Y hasta aquí ha llegado la ciencia de la seguridad en bluetooth, hace relativamente poco (un año) que el sniffing en bluetooth es algo extendido, por lo cual, habrá que esperar que se consigue con esta nueva posibilidad.

La verdad, es que he intentado hacer este documento lo mas simple posible, pero creo que no lo he conseguido, en el fondo es un tema complejo, aunque espero haber contribuido un poco en un tema tan indocumentado como este.

19 Responses to “Un vistazo profundo a bluetooth y su seguridad”


  1. 1 vierito5 octubre 13, 2008 a las 5:36 pm

    Existen algunos bugs más como el HeloMoto que permitía autoañadirse a la lista de dispositivos pareados. Originalmente descubierto en móviles Motorola, de ahí el nombre. Más información en: http://trifinite.org/trifinite_stuff_helomoto.html
    Luego también podrías desplazar la cadena que se mostraba por pantalla a la hora de hacer una conexión bluetooth y engañar al usuario, de modo que en lugar de mostrar ‘Desea aceptar la conexión?’ podrías hacer que mostrara un ‘Error grave. Pulse aceptar para recuperar’😛

    Respecto a l2cap, con hacer un ping (l2ping) con un tamaño superior a 500 ya era suficiente para provocar reinicios en varios modelos de móviles. Con tener un bucle mandando esos pings provocabas el DoS ya que al usuario ni siquiera le daba tiempo a desactivar bluetooth.

    Muy buen artículo!

  2. 2 jcarlosn octubre 13, 2008 a las 5:46 pm

    Hola vierto5, gracias por tu comentario.

    Es cierto, además hay mas, como el BlueBug, el BlueSmack, entre otros, todos están documentados en trifinite.org, que fueron de los pioneros en este tema, aunque no he querido hacer un el artículo un listado de bugs existentes, pero es cierto que es bueno tenerlos como referencia :p

    Gracias por la nota!

  3. 3 tiolalu octubre 14, 2008 a las 11:03 am

    Muy buen articulo🙂 , me ha gustado leerlo, he recordado muchas cosas y me he enterado de cosas nuevas.

  4. 4 Edu octubre 14, 2008 a las 3:33 pm

    Muchas gracias, buscaba algo de esto.

  5. 5 Jinme octubre 14, 2008 a las 3:43 pm

    Excelente articulo, la verdad no resulta tan complejo como pensaste. Agradecido. ;P

  6. 6 fixxx octubre 14, 2008 a las 4:23 pm

    Hace tiempo que quería leer algo como esto =)).

    Me parecia interesante el hecho de poder ‘interactuar’ con dispositivos móviles a un nivel mas bajo para así poder llegar a sitios restringidos mediante el software.
    Pero como la gran mayoría de ideas siempre se quedan en el stack por falta de tiempo.

    Me ha quedado una dudilla sobre el tema. Dices que es imposible escuchar los 70 canales por los que se comunican los dispositivos, pero no seria mas facil escuchar primero la comunicación que mantienen éstos mientras ‘deciden’ cual va a ser el orden de los canales? Luego ya sabrías donde ir a buscar.

    En fin, muchas gracias por el articulo!

  7. 7 jcarlosn octubre 14, 2008 a las 5:46 pm

    Hola, gracias por vuestros comentarios.

    Exacto fixxx, muy buena idea, lo único negativo es que tienes que llegar a tiempo, y ver la negociación, de lo contrario, tendría que DoSear uno de los teléfonos, para que reinicien la conexión, y pillarlos negociando.

    Gracias!

  8. 8 wirwin octubre 14, 2008 a las 10:04 pm

    Oro has puesto en esas lineas no tiene precio realmente excelente redes y protocolos no es mi area informatica sin embargo has explicado de una forma tan clara y sencilla que no me he perdido en el artículo, Felicidades sigue escribiendo en tu excelente blog

    ——————————
    Ejecución Estratégica
    http://ejecucion.wordpress.com

  9. 9 Nach0 octubre 15, 2008 a las 10:15 am

    articulo de 10😉
    me entere de cosas que no sabia.
    muy interesante

  10. 10 cheer_ octubre 15, 2008 a las 11:26 am

    Muy bueno el articulo!!…

  11. 11 jcarlosn octubre 15, 2008 a las 4:20 pm

    Hola, gracias por los comentarios, me alegra ver que ha quedado bastante entendible, al final no me convencía mucho si había sido lo suficientemente explicativo en algunas partes, pero veo que si.

    Un saludo!

  12. 12 fank octubre 16, 2008 a las 10:10 pm

    muy buen artículo, muy entretenido, enhorabuena

  13. 13 ege octubre 25, 2008 a las 6:39 pm

    Muchas gracias por las líneas, la manera de escribir me parece muy acertada principalmete para aquellos que se inician en conocer el funcionamiento del Bluetooth, como yo.

    Muy bueno!

    Saludos

  14. 14 mary diciembre 15, 2008 a las 10:13 pm

    hola gracias por el articulo la verdad esta interesante pero tengo un duda sobre el fhss porque ahi no lo explicas a fondo . tu crees que bluetooth pueda ser una red lan.?

  15. 15 motorola earpiece mic enero 4, 2013 a las 4:04 am

    I was sent here from the Slashdot website

  16. 16 Johne610 julio 18, 2014 a las 1:16 pm

    Ive learn some excellent stuff here. Certainly worth bookmarking for revisiting. I wonder how a lot attempt you set to create such a fantastic informative web site. gcfceffeckgd


  1. 1 meneame.net Trackback en octubre 13, 2008 a las 5:20 pm
  2. 2 Teknologeek.net » Bluetooth a Fondo y su seguridad Trackback en octubre 17, 2008 a las 9:59 pm
  3. 3 Selección de Noticias y Blogs [18] « Raul Barral Tamayo’s Alpha Blog Trackback en noviembre 2, 2008 a las 10:14 pm

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s





A %d blogueros les gusta esto: