Prosiguiendo con la secuela del equipo de S2 Grupo en la 6ª edición de la Navaja Negra, os seguimos detallando las charlas que más nos llamaron la atención:

BadUSB, Vectores de ataque y Contramedidas – Ernesto Sánchez

Repaso de los vectores de ataque por medio de USB, así como las contramedidas disponibles para cada uno de ellos. Ernesto Sánchez nos da a conocer Phoenix Ovipositor, un USB con características similares a las ofrecidas por Tensy o Rubber Ducky, destacando que se trata de un producto Español. Este USB consta de un microprocesador Atmega 32U4 con tarjeta Zócalo MicroSD, un controlador USB Host MAX3421E, además permite la conexión de conectores serie y USB A, como pueden ser módulos Xbee y compatibles (Zigbee, Bluetooth, Wifi…) y GMS/GPRS
[Read more…]

¿Qué os parecería si pudierais controlar un equipo a través de Gmail? Este es el tema del que vamos a hablar hoy. Descubrimos tras una pequeña búsqueda un script en Python desarrollado por @byt3bl33d3r que emplea los servidores de Gmail como un servidor de “Command and Control” (C&C).

¿Y qué es un servidor de Command and Control?
Un servidor de C&C o botmaster es el encargado de gestionar una red de equipos infectados conocidos como “bots”. Estos pueden ser manipulados a través de diversos canales, como por ejemplo IRC, con el objetivo de mandarles órdenes tales como el envío masivo de spam, ataques remotos, esnifar el tráfico de la red (traffic sniffers) o Denegación Distribuida de Servicio (DDoS – Distributed Denial of Service), etc.

¿Cómo funciona este script denominado “Pyexfil”?
Este script tiene la finalidad de controlar un equipo infectado o víctima a través del envío y recepción de correos electrónicos a una cuenta de gmail especificada por el atacante, empleando el protocolo SMTP sobre SSL/TLS que utiliza el puerto 587.

[Read more…]

Se han identificado recientemente multitud de aplicaciones Android vulnerables a ataques del tipo Man-In-The-Middle (MITM) bajo SSL, permitiendo a un atacante obtener la información transmitida entre el dispositivo móvil y el servidor.

En Fireeye han analizado 1.000 aplicaciones disponibles en Google Play y de ellas el 68% fueron identificadas como vulnerables. En el análisis se detectaron las siguientes tres casuísticas, que provocan un error en el manejo de las sesiones SSL/TLS conllevando a que un atacante puede realizar un ataque MITM.

• El gestor de confianza no verifica la cadena de certificados del servidor remoto, al no comprobarse si los certificados se encuentran firmados por una Autoridad de Certificación (CA).
• Se permite reemplazar el servidor remoto, dado que no se verifica el nombre del servidor, verificándose únicamente si el servidor dispone de un certificado, independientemenete de si es autofirmado o generado por una CA.
• Se ignoran errores en la negociación de las sesiones SSL al emplear Webkit.

Al revisar las estadísticas de Fireeye podemos observar:

• El 73% de las 664 aplicaciones no revisan los certificados de los servidores.
• El 8% de las 50 aplicaciones no verifica el nombre de los servidores.
• Y un 77% de aplicaciones de las 285 analizadas ignora los errores SSL generados al emplear Webkit.

Ahora bien, ¿qué impacto o consecuencias pueden suponer estas vulnerabilidades en nuestro dispositivo móvil?

Tras los análisis llevados a cabo, dependiendo de la aplicación que tengamos instalada podemos sufrir las siguientes consecuencias:

• Extracción de fotos almacenadas.
• Extracción de las credenciales de acceso de la aplicación.
• Extracción de credenciales de acceso de redes sociales (Facebook, Twitter…)
• Asimismo, hay aplicaciones que pueden llegar a permitir a un ataque inyectar imágenes o aplicaciones maliciosas, así como Denegación de Servicio (DoS).

Pero no únicamente se han detectado aplicaciones vulnerables a MITM, también existen librerías que permitirían obtener información sensible, como puede ser la ubicación o el código IMEI.

Estas detecciones nos hacen plantearnos las siguientes preguntas, ¿cuál es nuestro nivel de seguridad hoy en día en nuestros dispositivos móviles? ¿Podemos confiar ciegamente en las aplicaciones de Google Play?

Este descubrimiento pone en peligro la seguridad de nuestros dispositivos móviles, en especial los dispositivos de Android, y por consiguiente la confidencialidad de la información que manejamos en ellos (correo electrónico personal y/o profesional, credenciales a redes sociales, datos bancarios etc.).

Los desarrolladores ya están informados de las vulnerabilidades y esperamos que se apliquen las medidas correctivas cuanto antes. Aún así, como usuarios, nosotros también debemos aplicar medidas preventivas, especialmente en las redes wifi, dado que es en ellas donde podríamos sufrir este tipo de incidentes de seguridad. Hay que recordar que nunca sabemos quién puede estar detrás analizando el tráfico que enviamos en este tipo de redes.

Por otro lado, estas detecciones recientes ponen en entredicho la seguridad de las aplicaciones de Google Play, y por consiguiente el sistema Android. Este tipo de incidentes puede incluso llegar a hacer que nos decantemos por uno u otro dispositivo. Esto está siendo aprovechado hoy por hoy por Apple en su sistemas iOS, queriendo dar la sensación de mayor seguridad, al ser aplicaciones que han pasado un control más exhaustivo por miembros de Apple.

En el siguiente post vamos hacer un breve repaso a la escala de privilegios mediante el uso de “Incognito”. Después de las fiestas navideñas, y una vez comenzado este nuevo año, vamos a comenzar a repasar trucos y comandos publicados allá por el 2010, para así poder refrescar conocimientos y seguir investigando en la materia.

Según establece Offensive Security “La aplicación Incognito, se encuentra integrado en Mestasploit y en su instancia Meterpreter. Se puede encontrar más información acerca en el documento “Security Implications of Windows Access Tokens – A Penetration Tester’s Guide”. Incognito realiza el escalado de privilegios mediante la reproducción de la clave temporal cacheada en el sistema que es empleada cuando le solicita autenticación, permitiendo acceso al sistema.”

Con esto imaginemos ahora que nos encontramos realizando una auditoría lógica a la entidad ACME, y hemos obtenido acceso a un servidor Windows (a lo largo del post lo denominaremos “Gospi” para darle más realismo a nuestro entorno), disponiendo de una sesión abierta en dicha máquina mediante meterpreter.

Por tanto, una vez obtenida la máxima información posible ubicada en Gospi, ejecutamos Incognito mediante los comandos habituales de meterpreter “use incognito” (podemos ver los comandos permitidos mediante el comando “help”).

meterpreter > use incognito
Loading extension incognito...success.

Y procedemos a ver los tokens de los usuarios cacheados en Gospi mediante el comando “list_tokens –u”, obteniendo los usuarios.

Delegation Tokens Available
========================================
ACME\ Administrador
NT AUTHORITY\LOCAL SERVICE
NT AUTHORITY\NETWORK SERVICE
NT AUTHORITY\SYSTEM

Como podemos observar disponemos de los usuarios locales, así como también, por suerte, cacheado el acceso del Administrador del dominio ACME en el sistema. Y por tanto, aprovecharemos dicho usuario para escalar privilegios, ejecutando el comando “impersonate_token ACME\\Administrador”.

meterpreter > impersonate_token ACME\\Administrador
[+] Delegation token available
[+] Successfully impersonated user ACME\Administrador

Una vez especificado el token que deseamos suplantar, podemos verificar que disponemos de acceso al sistema con la cuenta de Administrador del dominio ACME, ejecutando el comando “getuid”.

meterpreter > getuid
Server username: ACME\ Administrador

Dado que disponemos de acceso al dominio de la entidad, vamos a proceder a crear un usuario en dicho dominio con permisos de administrador. Por tanto, abriremos una terminal mediante el comando “Shell”, y ahora haremos uso de comandos habituales de Windows.

Para dar de alta un usuario en el dominio ejecutaremos el siguiente comando “net user <usuario> <contraseña> /add /domain”. Y por último, lo añadiremos al grupo de Administrador del dominio “net group “Domain Admins” <usuario> /add /domain”.

Con esto, disponemos de un usuario con permisos de administrador en el dominio de la entidad ACME, y podemos disponer de acceso a diversos sistemas que sean controlados por el dominio de la entidad, así como acceder a la información confidencial almacenada.

Es muy común en la mayoría de las organizaciones disponer de servidores antiguos o sin los parches pertinentes, al ser servidores “offline”. Esto puede suponer un riesgo en la organización, no por la información que pueda contener (obsoleta o no confidencial), si no porque permita realizar un escalado de privilegios, y un atacante pueda acceder al dominio de la entidad como ha ocurrido en este caso en ACME. Obteniendo información confidencial, así como pudiendo pivotar a cualquier equipo de la red.

Aquello que consideramos menos crítico, suele ser la mayor fuente de ingresos de incidentes de seguridad.

Fuente:
http://www.offensive-security.com/metasploit-unleashed/Fun_With_Incognito

Prosiguiendo con el post anterior sobre GPS Spoofing, vamos a detallar el proceso que se realiza en GPS Spoofing.

Un ataque de GPS Spoofing se basa en suplantar la señal original del satélite GPS “engañando” al receptor GPS. Esto se logra mediante la construcción de una señal fraudulenta a partir de las señales transmitidas por los satélites GPS realizando conversiones de digital a analógico. Creada la señal “fraudulenta/suplantada” se va aumentando lentamente la potencia de la señal suplantada, hasta llegar a solapar la señal real (emitida por los satélites GPS) y a partir de ese instante el atacante pasa a controlar el sistema GPS receptor. En la siguiente ilustración se puede observar el proceso de suplantación:

La Universidad de Texas, bajo la dirección del Profesor Todd Humphreys, demostró que no únicamente se puede controlar un Drone. Para ello realizó un experimento por el que llegó a controlar un barco de 80 millones de dólares de uno 65 metros de eslora en la costa Italiana. El experimento se basó en ubicarse en la proa del barco con el sistema diseñado por propios estudiantes de la universidad, provocando las señales fraudulentas, y modificar así la trayectoria del barco en 3 grados. Los resultados dejan claro cómo afecta esta técnica al sistema GPS y como puede impactar en la actualidad.

Asimismo, cabe señalar que existe una técnica denominada Jamming GPS. En este caso, se trata de interrumpir/bloquear las señales GPS. La combinación de ambas técnicas (GPS Spoofing y Jamming GPS), se puede llegar a controlar un Drone militar tal y como realizó el gobierno iraní. En la siguiente ilustración, se puede observar el ataque llevado a cabo por el gobierno iraní a un Drone de los Estados Unidos.

Hasta ahora hemos estado comentado como son de vulnerables los sistemas GPS. Sin embargo, ¿como podemos defendenos frente a este tipo de ataques? ¿Es posible aplicar medidas palitivas que nos informen de si estamos siendo manipulados por un tercero?

A la hora de securizar las señales GPS civiles se podría optar por emplear señales cifradas, tal y como se hace en la señales GPS militares. Sin embargo, de hacerlo así el GPS civil dejaría de ser una herramienta tal y como la conocemos ahora (económica y viable) y probablemente dejaría de utilizarse.

En este sentido los investigadores de la Universidad de Oklahoma encontraron en el 2011 dos soluciones posibles. Una de ellas es aumentar la intensidad de la señal de los GPS civiles, lo que haría más difícil para un GPS spoofer engañar al sistema de navegación. Sin embargo, su implementación presenta dificultades importantes. La otra opción, más práctica en su opinión, es aplicar “algoritmos de anti-spoofing triviales en los receptores de GPS”, que se encargarían de alertan al sistema receptor de la falsificación de la señal GPS mediante la comparación de la intensidad y la potencia de la señales GPS recibidas, de los intervalos de tiempo y los identificadores de los satélites GPS.

Los gobiernos también han comenzado a preocuparse por proteger sus señales GPS. Este es el caso de Corea del Sur que anunció que planea lanzar una red de torres eLORAN (mejorada navegación de largo alcance), debido a las interrupciones producidas desde Corea del Norte. Este sistema de navegación (eLORAN) emite señales de posicionamiento desde estaciones base, emitiendo señales más fuertes, evitando bloqueadores o interrupciones de señales GPS. El Reino Unido también tiene planes para construir un sistema de este tipo.

Referencias:

• http://theaviationist.com/2012/12/10/sentindel-decoded/#.Unitz5zuIa
• http://www.webmar.com/archives/6841
• http://www.digitaltrends.com/mobile/gps-spoofing/

Recientemente han aparecido algunos estudios en los que se plantea la posibilidad de realizar GPS Spoofing en vehículos civiles no tripulados o “drones”. En éstos se ha conseguido controlar o alterar la secuencia de posicionamiento de un drone y como veremos, incluso la trayectoria de un barco. Sin embargo, antes de entrar en materia, explicaremos primero cómo funciona el sistema GPS.

Cada satélite GPS transmite dos señales, una señal militar y una señal civil. Sólo las señales de GPS código civil puede ser utilizadas por la gran mayoría de los usuarios de GPS (incluyendo los Departamentos de Defensa). El código civil se compone de dos componentes principales, la señal y la onda portadora, tal y como se puede observar en la Figura 1.

Los datos de NAV/System proporcionan al receptor GPS la información sobre la posición de los satélites, así como los datos de tiempo suministrados por los relojes atómicos que se encuentran a bordo de los satélites.

[Read more…]