Análisis del CVSS de ShellShock

Una de las vulnerabilidades más importantes del año sin duda ha sido ShellShock. En el artículo de hoy vamos a explicaros cómo funciona el sistema de evaluación de vulnerabilidades más extendido, el CVSS (Common Vulnerability Scoring System), haciendo uso de dicha vulnerabilidad.

Como ya sabéis la vulnerabilidad de ShellShock corresponde a un bug en Bash que afecta a sistemas UNIX, Linux y OS X que incorporan esta herramienta en su sistema. Dentro de la métrica CVSS podemos encontrar este bug dividido en dos ocurrencias: CVE-2014-6271 y CVE-2014-7169.

¿Qué es CVSS?

CVSS es una métrica para evaluar vulnerabilidades que nos reporta un valor, o conjunto de valores, que nos dan una idea del peligro que conlleva una vulnerabilidad.

Si buscamos el CVSS Score de las vulnerabilidades nombradas en la National Vulnerability Database (NVD) veremos que su valor es 10.

¿Cómo se utiliza?

CVSS utiliza tres métricas básicas para medir el alcance que puede tener una vulnerabilidad. Podemos verlas en la siguiente imagen para la CVE-2014-6271

 1. Métrica Base

Dentro de la métrica base tenemos evaluados aquellos parámetros que son constantes en el tiempo y el entorno. Dicha métrica se suele expresar como un vector.

Esto es lo que se conoce con el nombre de vector base y sería el siguiente:

CVSS v2 Vector (AV:N/AC:L/Au:N/C:C/I:C/A:C)

    AV: Vector de Acceso, es decir, la manera a través de la cual podemos acceder a la vulnerabilidad. En nuestro caso para explotar la vulnerabilidad podemos acceder desde cualquier red, no sólo en local (N:Network).
    AC: Complejidad de Acceso, es decir, la complejidad que requiere el atacante una vez ha accedido al sistema, en nuestro caso complejidad baja (L: Low).
    Au: Autenticación, es decir, cuantas veces debe autenticarse el usuario para poder hacer uso de la vulnerabilidad, en nuestro caso ninguna (N:None).
    C: Impacto de Confidencialidad, es decir, como afecta esta vulnerabilidad en cuanto a la confidencialidad. En este caso el impacto es total, porque podemos ejecutar cualquier código en el sistema, lo que conlleva acceso a cualquier archivo, rompiendo de manera completa la confidencialidad del sistema (C: Complete).
    I: Impacto de Integridad, es decir, como afecta esta vulnerabilidad en cuanto a la integridad. Al igual que en el caso anterior, tenemos acceso completo a modificar cualquier archivo de tal forma que se rompe este principio completamente (C: Complete).
    A: Impacto a la Disponibilidad, más de lo mismo, si podemos ejecutar en el sistema cualquier comando podemos echar abajo servicios entre otras cosas. Por tanto afecta a la disponibilidad de manera completa (C: Complete)

Normalmente a la hora de evaluar una vulnerabilidad mediante el CVSS tan sólo se suele valorar la métrica base, ya que las dos siguientes son opcionales y cambiantes en el tiempo. En caso de la vulnerabilidad que tratamos aquí no han sido evaluadas, pero no obstante vamos a explicar cada uno de los campos.

2. Métrica Temporal

Esta métrica varía en el tiempo, en ella podemos evaluar varios parámetros como vemos a continuación:

Explotabilidad: se refiere a si existen exploits y si están disponibles, o sólo existen pruebas de concepto, si los exploit sólo existen en X sistemas o por el contrario existe código multiplataforma.
    Nivel de curación: hace referencia a la existencia o no de soluciones para corregir dicho bug, si estas provienen de fuentes oficiales o anónimas, o incluso si son soluciones temporales.
    Confianza del anuncio: trata de evaluar la veracidad en la existencia de dicha vulnerabilidad, si ha sido confirmada por fuentes oficiales (el responsable del software o sistema) o sólo por grupos independientes de seguridad.

A continuación os muestro la evaluación que podríamos hacer de esta métrica para la CVE-2014-6271.

Explicación: La explotabilidad es alta ya que existen numerosos exploits documentados, en cuanto a la cura también existen parches de fuentes oficiales para todas las plataformas afectadas y en cuanto a su confirmación, está más que confirmada su existencia.

3. Métrica del entorno

Esta métrica también varía en el tiempo, en ella podemos evaluar varios parámetros relacionados al entorno al cual afecta la vulnerabilidad. Los vemos a continuación:

Daño colateral potencial: hace referencia al daño que puede ocasionar a terceros, como a personas, bienes físicos, la productividad o beneficios.
    Distribución de objetivos: aquí medimos la proporción de sistemas vulnerables en el entorno, se suele dar valor numérico entre 0 y 10; y se expresa en intervalos de mínimo y máximo.
    Modificadores de las subpuntaciones de impacto: aquí se trata del grado de afectación dentro de los objetivos de la seguridad como son Confidencialidad, Integridad y Disponibilidad. Es decir, mediante estos valores podemos medir cuan importante es para esta vulnerabilidad cada uno de estos parámetros.

A continuación os muestro la evaluación que podríamos hacer de esta métrica para la CVE-2014-6271.

Explicación: El daño colateral es enorme, ya que si se puede explotar esta vulnerabilidad en un entorno de una empresa, por ejemplo, podríamos hacer lo que quisiéramos. Datos de clientes que provoquen pérdidas económicas, proyectos de investigación en manos inadecuadas que roben ideas, etc.

En cuanto al número de sistemas afectados, estaréis de acuerdo conmigo que entre el 76% y 100% de sistemas han tenido que parchear dicha vulnerabilidad, desde el smartphone Android que llevamos en el bolsillo hasta el servidor linux que se utiliza en el trabajo.

En referencia a los modificadores en cuanto a Confidencialidad, Integridad y Disponibilidad; podemos decir que cualquiera de los tres objetivos de la seguridad son importantes en esta vulnerabilidad, de ahí su valor High.

Conclución

Una vez evaluados todos los parámetros y explicados cada uno de ellos, podemos recalcular el CVSS de la CVE-2014-7169 usando el propio sistema de cálculo que nos facilita NVD (CVSS v2 Calculator), y obtendremos el siguiente resultado:

El vector completo para CVE-2014-7169 quedaría de la siguiente forma:

CVSS v2 Vector (AV:N/AC:L/Au:N/C:C/I:C/A:C/E:H/RL:OF/RC:C/CDP:H/TD:H/CR:H/IR:H/AR:H)

Espero que a partir de ahora entendáis mejor este sistema de evaluación de vulnerabilidades.

Honeypot. Un tarro de miel para los atacantes.

En el artículo de hoy trataremos el tema de los Honeypots. Este tema es bastante desconocido para mucha gente, ya que es un concepto bastante contradictorio.

Honeypot significa en inglés, “tarro de miel”. Es una herramienta que se usa casi exclusivamente en el campo de la seguridad informática. Su función se basa en atraer y analizar ataques realizados por bots o hackers. Y podremos decir: ¿Atraer? ¿Pero el quid de la cuestión no es repeler?. Pues bien, su objetivo es atraer atacantes para ver sus pautas de ataque, generar diccionarios para recopilar que palabras usan en ataques (para no usarlas en tu sistema), conocer al enemigo y su perfil.

Bueno, ¿y cómo es un honeypot?. Un honeypot puede ser tan sumamente sencillo como un equipo informático cualesquiera que analice el tráfico entrante y saliente hacia Internet. Pero es importante “habilitar” o no sanear alguna vulnerabilidad del S.O, en algún protocolo, programa o cualquier otro elemento para así atraer más fácilmente a un atacante o atacantes.

Pero por otra parte, un honeypot puede ser bastante complejo. Puede funcionar como una red de ordenadores, funcionando con diversos sistemas, y con infinidad de servicios. Con esto, cuando uno de los equipos es atacado inmediatamente es informado el administrador de sistemas.

Una de las opciones más utilizadas es usar un honeypot en forma de programa. Hay honeypots que simulan ser una red local de múltiples equipos, ips falsas, directorios inventados, equipos no presentes, etc… para crear gran confusión al atacante y/o para detectar nuevos métodos de ataque y poder aplicar defensas a nuestra red real.

También pueden guardar usuario y contraseña que el atacante introduce, bien manualmente, o por medio de diccionarios para así poder excluir todos esos caracteres alfanuméricos o no de contraseñas en nuestra red real.

A continuación os mostramos un esquema de un honeypot en una red local:

Podemos decir, que un honeypot es un gran aliado para defender tu red, aunque el concepto sea atraer ataques, la mejor táctica para defenderse es saber como actúa el enemigo y que mejor que ponerle un cebo el cual no supondrá un riesgo para nuestra red, y nos ayudará a saber como incide el ataque y de que manera.

Los honeypots más conocidos son: honeyd, kippo(ssh), Valhalla, Specter, honeynet…

Unos son mas fáciles de usar, otros más complejos, pero altamente configurables, aunque la forma más fácil de saber cuál va a cubrir nuestras necesidades será probándolos.

Creando un túnel SSH con Nessus

Muchas veces a la hora de hacer una auditoría externa y tener algún sistema de protección exterior (Firewall, IDS…), se nos habilitan diferentes mecanismos para poder acceder dentro de la red que queremos auditar sin que su seguridad exterior se vea comprometida. Es muy común habilitar un túnel SSH para acceder al interior de la red local.

Hoy vamos a ver cómo aprovechar ese túnel para correr Nessus como si estuviéramos ubicados dentro de la red. Como sabéis, la versión gratuita de Nessus tan sólo nos permite escaneos a direcciones IP locales, sin embargo mediante el túnel vamos a conseguir utilizar esta herramienta frente a una IP pública, como si estuviéramos dentro de la red a auditar aún estando fuera de la misma.

Vamos a utilizar para ello un túnel SSH y la herramienta Proxychains de la cual tenéis un artículo en el blog sobre cómo trabajar con ella y Tor.

En el siguiente diagrama vemos el entorno en el cual vamos a trabajar:

La idea es crear un túnel SSH y haciendo uso de Proxychains reenviaremos todas las peticiones de nuestro PC (Nodo A) a través del túnel, de tal forma que Nessus va a pensar que está corriendo el scanner en la máquina intermedia (Nodo B) que sí está en la misma red del servidor a auditar (Nodo C). Los pasos a seguir son los siguientes:

Creación del túnel SSH con el nodo B.

Para crear el túnel previamente tenemos que tener habilitado en el nodo B el servicio SSH con nuestro usuario correspondiente y una regla en el Firewall que permita las peticiones desde exterior hacia la máquina B (natearemos el puerto 22 mediante Port Fowarding a la máquina B).

Con todo preparado pondremos a la escucha un puerto en la máquina local A, de tal forma que todo lo que se envíe a ese puerto se reenviará a través del túnel que crearemos contra la máquina B. Usaremos el siguiente comando:

sudo ssh –p 22 –N –D 8081 user@direccionIP_B

Tras introducir las credenciales oportunas podemos ver desde otra terminal como ya tenemos el puerto 8081 a la escucha en la máquina local A:

Instalación y configuración de Proxychains.

Para la instalacción de Proxychains simplemente ponemos:

sudo apt-get install proxychains

y nos vamos a editar su fichero de configuración /etc/proxychains.conf. Pondremos que todas las peticiones de los programas/servicios abiertos con Proxychains vayan al puerto 8081 de autobucle (127.0.0.1) donde está el túnel.

Comprobación del funcionamiento del túnel.

Pasamos ahora a comprobar si funciona nuestro túnel, para ello vamos a solicitar desde nuestra máquina local A la IP pública que tenemos. Vemos como aparece nuestra IP 95.x.x.x.

Sin embargo cuando pasamos la petición a través del túnel mediante proxychains vemos que nos da la IP del nodo B, por tanto nuestro túnel funciona correctamente.

,

Iniciando Nessus a través del túnel.

Una vez que tenemos todo funcionando vamos a lanzar Nessus de nuevo pero esta vez a través del túnel. Primero paramos el servicio de Nessus:

/etc/init.d/nessus stop

y lo iniciamos a través de proxychains para que las peticiones vayan a través del túnel.

Una vez que tenemos todo funcionando ya podemos arrancar Nessus y llevar a cabo el escaneo de la máquina C en cuestión, sin necesidad de desplazarnos a la ubicación del nodo

Dejar claro que todas las pruebas se han llevado a cabo sobre dos redes propietarias y que como comentábamos en la nota legal, se hace con fines educativos.

Iniciando Nessus a través del túnel.

Una vez que tenemos todo funcionando vamos a lanzar Nessus de nuevo pero esta vez a través del túnel. Primero paramos el servicio de Nessus:

/etc/init.d/nessus stop

y lo iniciamos a través de proxychains para que las peticiones vayan a través del túnel.

- See more at: http://hacking-etico.com/2015/06/12/creando-un-tunel-ssh-con-nessus/#more-4509

Usando Nmap para detectar Heartbleed

A estas alturas, pocas personas existirán que no hayan escuchado hablar de Heartbleed, considerado uno de los bug más críticos de la historia de internet.

No entraré en más explicaciones de Heartbleed, puesto que existen ya infinidad de sitios hablando de ello, aunque uno que explica todo muy claro lo tenéis en el blog Un Informático en el lado del mal.

En estos pasados días me ha tocado dedicarme exclusivamente a este bug en OpenSSL por lo que he debido informarme bien de en qué consistía exactamente hasta al mismo nivel del código fuente.

Una vez entendido ha tocado escanear una gran cantidad de IPs para comprobar qué hosts eran vulnerables. En esta ocasión me centro en servidores que pueden estar dando servicios que usan OpenSSL vulnerable, aunque no olvidéis que los clientes también pueden serlo.

Dado que la cantidad de IPs a escanear superaba los pocos miles, debía automatizar el scanning de alguna manera. Voy a explicar sin entrar en mucho detalle cómo fue el proceso.

Aclarar que he utilizado BackTrack 5 RC2 y Nmap 6.25.

1ª Situación

Cuando empecé el chequeo no existía exploit, tan sólo la web que todos conocemos para comprobar online si una aplicación bajo un dominio y puerto es vulnerable.

Por lo tanto el proceso sería usar nmap con fingerprinting de los servicios y una vez localizados aquellos servicios que podrían estar usando una versión vulnerable de OpenSSL comprobarlos en la web. Inviable dada la gran cantidad de IPs a comprobar.

2ª Situación

Sale el primer exploit en Python. Por lo tanto la idea cambia. Analizar qué servidores tiene esas servicios abiertos y crear un script para correr el exploit en esos servidores. Tedioso.

3ª Situación

Sale el primer script para nmap para comprobar Heartbleed. Suena perfecto. Tras unos cuantos escaneos me doy cuenta de que nmap me esta dando algunos falsos negativos, es decir, servidores que son de hecho vulneables, nmap los muestra como no vulnerables. Toca analizar a mano algunos de ellos aunque muchos otros ya son marcados correctamente gracias al script.

¿Situación final?

Sale una modificación del script para nmap que hace también Hearbeat request usando TLS 1.0, TLS 1.1 y TLS 1.2. En problema de los falsos negativos en la etapa anterior venía de que el script sólo comprobaba TLS 1.1.

El nuevo script podéis encontrarlo aquí . Se instala igual que cualquier otro script para nmap. En BackTrack (BT BT!!!) bajáis el fichero .nse y lo metéis en directorio usr/local/share/nmap/scripts/

En mi instalación de nmap por defecto el script me daba error ya necesita la librería tls para realizar conexiones “seguras” (si es que las hay hoy en día, un saludo  para la NSA por cierto). Para instalar esta librería debéis descargarla de aquí y alojar el fichero .lua en nselib de vuestro nmap.

Ya tenemos todo listo para escanear. Este es el comando que yo he usado:

 # nmap -iL ip_ranges -sV –top-ports 100 –script ssl-heartbleed -oA nmap_heartbleed_results

Breve explicación del comando:

-iL ip_ranges: ip_ranges es un fichero plano con todas las IPs a escanear. Muy útil cuando la cantidad es grande. Podemos incluir ahí IPs individuales, rangos de Ips, IPs de red con máscara… Se puede poder una en cada línea y mezclando formatos.

 –top-ports 100: Nmap escaneará sólo los 100 puertos más comunes. Esta clasificación está basada en el fichero nmap-services y cogerá aquellos 100 puertos con el ratio más alto. En mi caso era suficiente para cubrir los servicios más importantes que podrían utilizar OpenSSL.

–script ssl-heartbleed: Hacer uso del script para este bug.

-oA nmap_heartbleed_results: Cuando uso nmap, acostumbro a sacar los resultados en todos los formatos posibles, de modo que podremos grepearlos a nuestro antojo, exportar XML a otros formatos, etc.

No dudéis en reducir el scan sólo a los puertos que realmente queráis comprobar, ahorraréis tiempo.

Una vez tengáis los resultados, podréis exportarlos a un bonito HTML con la aplicación xsltproc.

Ahora a reportar y parchear, que la ocasión lo merece.PD: no tengo a mano los resultados por lo que no puedo publicar ninguna captura. Aún así, no os debe resultar difícil encontrar un servidor vulnerable o montar el vuestro propio para las pruebas.

Ataque BadUSB Man-In-The-Middle

Como ya habréis notado gracias a nuestro anterior artículo, en los últimos días en hacking-etico.com hemos estado probado la nueva maravilla que nos trae el equipo de Kali Linux: NetHunter. Aprovechando que yo también dispongo de un terminal Nexus 5 he decidido instalar y probarlo y las sensaciones son muy buenas.

Si aún no sabéis cómo descargarlo e instalarlo, os recomiendo nuevamente que leáis “NetHunter: Kali Linux en tu Android“, un estupendo artículo nos trae nuestro compañero Manuel Camacho en donde nos explica todo lo que necesitáis saber para tenerlo en vuestro dispositivo Nexus.

Uno de los ataques que más fácilmente nos permite hacer NetHunter es un curioso Man-In-The-Middle con el que me llevé una grata sorpresa. Vamos a centrar este artículo en explicar cómo funciona, por qué funciona, cómo explotarlo y cómo defendernos ante ello.

Este año tuve la suerte de asistir a la BackHat en Las Vegas, donde una de las más esperadas charlas era la de BadUSB y que a título personal me dejó maravillado. Ya se empiezan a ver las primeras implementaciones y vectores de ataque: Por parte de los chicos de NetHunter tenemos “BadUSB MITM Attack“. Ya podéis imaginar cual será el vector de ataque… con tan sólo conectar el móvil por USB a un ordenador con Windows conseguiremos redirigir todo el tráfico a nuestro móvil y hacer lo que queramos con él… guardarlo, modificarlo, bloquearlo… ¿interesante verdad? ¡A partir de ahora nos pensaremos dos veces cuando alguien nos pida que le carguemos el móvil en nuestro ordenador! Pero eso no es todo… seguid leyendo porque os cuento más adelante que la cosa es más grave aún.

Vamos al lío. Para ello voy a diferenciar tres secciones:

    Explotando Ataque BadUSB MITM: Mostrando cómo se explota y resultado en un escenario real.
    Entendiendo Ataque BadUSB MITM: Analizaremos en detalle cómo y por qué funciona el ataque.
    Defendiéndonos del Ataque BadUSB MITM: Una vez hemos analizado y entendido cómo funciona, podemos tomar un serie de acciones para evitar que este ataque sea efectivo en nuestras máquinas.


Explotando Ataque BadUSB MITM

Es momento de ver en acción cómo funciona el ataque. He escogido el vídeo oficial que la gente de NetHunter ha publicando donde se puede ver una demostración del ataque de una manera muy sencilla y directa. Si no entedéis bien inglés no os preocupéis puesto que en la siguiente sección lo veremos en detalle

¿Tiene buena pinta? Pues pasemos al a siguiente sección donde vamos a entender un poco mejor cómo funciona.


Entendiendo Ataque BadUSB MITM

A continación explicaré un poco más en profundidad cómo funciona la implementación de este ataque MITM. Para ello he grabado el siguiente vídeo (no olvidéis verlo en HD para ver todos los detalles sin problema) en el que veremos con detalle paso a paso todo lo que va sucediendo desde el principio hasta el final del ataque:

Como prueba de concepto y para comprobar que realmente se está capturando el tráfico, he filtrado tcpdump para capturar sólo el tráfico con destino al puerto 21 y guardarlo en el fichero mitm.pcap

Una vez hecho lo anterior, me conecto desde la máquina víctima a un servidor FTP insertando un usuario y contraseña de prueba sólo para ver si realmente se está capturando el tráfico. Al abrir el fichero pcap con Wireshark vemos que efectivamente el usuario y contraseña han sido capturados

,

 Varios puntos a aclarar:

El dispositivo móvil debe estar conectado a internet para que esté propiamente en el medio de la comunicación.

Aunque no lo he probado, probablemente este ataque no funcione en máquinas UNIX debido a la manera en la que UNIX administra las puertas de enlace por defecto.

El ataque funciona aunque la sesión Windows del usuario esté bloqueada, es decir, nos encontremos ante la pantalla de inicio de sesión donde hay que meter la contraseña del usuario para acceder de nuevo a su sesión. Este escenario es muy común, puesto que en entornos de trabajo cuando el empleado se ausenta, una buena costumbre es bloquear la pantalla con “Windows + L”. Aún así, el ataque funcionará. Por lo tanto… imaginen un entorno donde podamos acceder a un puerto USB de una máquina importante (ufff se me ocurren tanto sítios públicos donde puertos USB son accesibles), es cuestión de enchufar el móvil, guardar el tráfico durante un tiempo y luego analizarlo en casa tranquilamente.
Defendiéndonos del Ataque BadUSB MITM

Como ha quedado demostrado, el principal problema es que Windows asigna a la métrica de la nueva ruta un valor menor al que la ruta por defecto ya tiene. ¿Qué podemos hacer entonces? Bueno se me ocurre algo bien sencillo como solución rápida y temporal: asignar un valor estático y menor a nuestra ruta por defecto y por lo tanto aunque se cree una nueva ruta para el tráfico por defecto, éste tendrá un valor mayor y por lo tanto el tráfico se seguirá enviando por nuestra interfaz de red.

Para ello nos vamos Conexiones de red y entramos en las propiedades de la interfaz de red que conecte con internet (igualmente con otras interfaces importantes, por ejemplo aquellas para tráfico de intranet).

BadUSB MITM

A continuación quitamos la opción de que la métrica de la ruta se calcula automáticamente y le ponemos un valor manual de 1:

Sin título3

De este modo, cuando Windows tenga dos rutas para el tráfico 0.0.0.0 siempre lo enviará por esta interfaz al tener una métrica mejor que la creada por NetHunter.

Es importante no olvidar que esto se debe hacer tanto para IPv4 como IPv6.

Sólo una última nota: Ojo porque el tráfico DNS se seguiría enviando por ambos y si no estoy equivocado, tráfico multicast actuaría del mismo modo. Desde luego este “parche” no soluciona el verdadero problema de raíz.

Varios puntos a aclarar:

El dispositivo móvil debe estar conectado a internet para que esté propiamente en el medio de la comunicación.

Aunque no lo he probado, probablemente este ataque no funcione en máquinas UNIX debido a la manera en la que UNIX administra las puertas de enlace por defecto.

El ataque funciona aunque la sesión Windows del usuario esté bloqueada, es decir, nos encontremos ante la pantalla de inicio de sesión donde hay que meter la contraseña del usuario para acceder de nuevo a su sesión. Este escenario es muy común, puesto que en entornos de trabajo cuando el empleado se ausenta, una buena costumbre es bloquear la pantalla con “Windows + L”. Aún así, el ataque funcionará. Por lo tanto… imaginen un entorno donde podamos acceder a un puerto USB de una máquina importante (ufff se me ocurren tanto sítios públicos donde puertos USB son accesibles), es cuestión de enchufar el móvil, guardar el tráfico durante un tiempo y luego analizarlo en casa tranquilamente.

Defendiéndonos del Ataque BadUSB MITM

Como ha quedado demostrado, el principal problema es que Windows asigna a la métrica de la nueva ruta un valor menor al que la ruta por defecto ya tiene. ¿Qué podemos hacer entonces? Bueno se me ocurre algo bien sencillo como solución rápida y temporal: asignar un valor estático y menor a nuestra ruta por defecto y por lo tanto aunque se cree una nueva ruta para el tráfico por defecto, éste tendrá un valor mayor y por lo tanto el tráfico se seguirá enviando por nuestra interfaz de red.

Para ello nos vamos Conexiones de red y entramos en las propiedades de la interfaz de red que conecte con internet (igualmente con otras interfaces importantes, por ejemplo aquellas para tráfico de intranet).

A continuación quitamos la opción de que la métrica de la ruta se calcula automáticamente y le ponemos un valor manual de 1:

De este modo, cuando Windows tenga dos rutas para el tráfico 0.0.0.0 siempre lo enviará por esta interfaz al tener una métrica mejor que la creada por NetHunter.

Es importante no olvidar que esto se debe hacer tanto para IPv4 como IPv6.

Sólo una última nota: Ojo porque el tráfico DNS se seguiría enviando por ambos y si no estoy equivocado, tráfico multicast actuaría del mismo modo. Desde luego este “parche” no soluciona el verdadero problema de raíz.

- See more at: http://hacking-etico.com/2014/10/08/ataque-badusb-mitm/#more-3730

NetHunter: Kali Linux en tu Android

Vuelvo a publicar en hacking-etico.com tras unos meses un poco “diferentes” y regreso para traeros un artículo que os puede resultar muy interesante.

Todos nuestros visitantes sabéis o habéis oído hablar de Kali Linux, la conocida distribución Linux que incorpora multitud de herramientas para testear todo tipo de sistemas y conexiones. Esta “distro” es la sucesora de la archiconocida Backtrack. Pues bien, ya la tenemos disponible para smartphones.

En mayor o menor medida, en el Play Store habitan una cantidad ingente de aplicaciones para generar claves WiFi de todo tipo de fabricantes y a día de hoy el 99% son aplicaciones extremadamente malas (probad probad xD). Unas generan supuestas claves para redes Jazztel, WLAN, etc… pero en muy pocos casos funciona. A veces porque los usuarios se les ha removido la conciencia “segura” y otras porque simplemente no se corresponden con la red en cuestión. Y otras son aplicaciones fakes en toda regla.

Pocas alternativas hay que no sean generadores de diccionarios sin más. Metes el SSID y la MAC y a marchar con o sin resultados (esto último casi siempre).

Pero si hay una interesante que ya publiqué el año pasado. Dsploit. Esta aplicación es más avanzada y funciona en teléfonos rooteados y a ser posible con cierta potencia. Con ella puedes snifar tráfico de la red WiFi que estés conectado, capturar sesiones, envenenamiento DNS, etc.. Tiene algunos bugs que pueden hacer un reboot indeseado pero es más que apta para por ejemplo, snifar tráfico de tu red Wifi e interpretarla con el Wireshark o el Networkminer.

Pero hasta ahora sólo teníamos esas opciones. Hasta que los chicos de www.offensive-security.com nos han traído un regalito. Kali Linux NetHunter. Y vamos a “fusionarlo” con Android.
Advertir que solo está disponible para dispositivos Nexus 5, Nexus 7 y Nexus 10 (al menos por ahora) y que debes tener rooteado el teléfono y con su recovery. NO es en sí una ROM por tanto si usas MULTIROM (tener varias rom en el mismo teléfono) e instalas como secundaria “cascará” al 100%.

Bien, vayamos con la faena.

Para instalar NetHunter en el Nexus 5 tenemos dos opciones:

A: Instalar sin MULTIROM.

B: Instalar con MULTIROM.

No pretende ser esto un tutorial para androides pero si una pequeña aclaración ya que hay escasa información sobre este tema a día de hoy. Hay que tener una ligera idea sobre ciertos términos y conceptos.

Partiremos de la base de que hay un recovery personalizado instalado. Para los newbies han de mirarse primero conceptos clave para personalizar un smartphone Android.

Fundamental descargar:STOCK ROM 4.4.4 en formato .zip- Descargar (Enlace MEGA)
 SuperSU (Rootear) – Descargar

 Opción A

Antes de nada aclarar que hay otro tipo de instalación que es bajándose un instalador de la página de www.offensive-security.com, instalarlo en Windows e ir haciendo los pasos. Personalmente no lo he probado ya que prefería asegurarme usando el “método tradicional”. Pero esto es a elección del usuario. Nosotros vamos a usar el método más común de instalar una ROM.

Hay que trabajar siempre con STOCK ROM 4.4.4. Supongamos que hemos entrado en el recovery, hemos hecho los WIPES (wipear es opcional pero es altamente recomendable aunque desaparecerán todas las aplicaciones y configuraciones, no así las imágenes a no ser que hayáis personalizado los wipes y elegido el “format storage”)  pertinentes para dejar a CERO nuestro teléfono e instalamos nuestra STOCK ROM 4.4.4. Seguidamente y sobre la misma instalación FLASHEAMOS el ZIP que contiene el SUPERSU el cual ROOTEARÁ el teléfono.

A continuación iniciamos el teléfono, configuramos la cuenta gmail y nos vamos al Play Store previa conexión a nuestra WiFi. Descargamos BUSYBOX (yo lo he tenido que instalar sino no me funcionaba) e instalamos.

Reiniciamos nuestro dispositivo en modo recovery, esto es pulsando tecla Volumen Abajo y Power a la vez.

Ahora toca flashear nuestra herramienta NetHunter encima de nuestra STOCK ROM 4.4.4 ya que complementa nuestro sistema con las herramientas de seguridad. Por ello decimos que no es en sí una ROM 100%.

El proceso es lento. Muy lento, así que si todo va bien veréis una barra de progreso que avanza a pasos de tortuga disecada. (Momento para sacar un “beer” mientras esperamos el “hack” xD)

Una vez finalizado el proceso, reiniciáis y debe funcionar vuestra STOCK ROM 4.4.4 rooteada con el añadido de NetHunter.

Deberíais ver en las aplicaciones algunas que no son habituales nada más instalar el teléfono. Veamos en la imagen.



Opción B

Aquí viene cuando la “matan” verdaderamente.

Para quién no conozca MULTIROM es un “Plus” del recovery para poder instalar diferentes ROMS personalizadas siempre que la capacidad de almacenamiento de nuestro teléfono lo permita. Una especie de MULTIBOOT que en sistemas de ordenadores sería como tener Windows, Linux y Hackintos para elegir en el arranque.

Antes de nada tenemos que tener estas premisas claras:

    Nexus 5 funcionando con STOCK ROM o ROM PERSONALIZADA.
    Teléfono ROOTEADO.
    Más los archivos indicados en negrita anteriormente.

En nuestro Play Store, buscamos la APP de nombre MULTIROM, que instalamos y ejecutamos.

 Pedirá permisos de ROOT que concederemos como generosos usuarios. Marcamos los pasos de la imagen, aunque os saldrá a vosotros en rojo la línea de “Kernel”.

,

 Hacemos los reinicios pertinentes y entramos a recovery. (Volumen Abajo y Power). Hecho esto deberíamos tener instalado ya un recovery con soporte multirom.

Ahora vamos a añadir una ROM a nuestro MULTIARRANQUE.

Entramos en Recovery, con Volumen Abajo y Power. Seguimos estos pasos: ADVANCED/MULTIROM/ADD ROM botón NEXT luego opción ZIP FILE buscamos nuestra STOCK ROM 4.4.4 la seleccionamos y procedemos a instalar. Cuando acabe, volvemos a hacer estos pasos pero eligiendo LIST ROM en vez de ADD ROM y seleccionando SUPERSU para rootear esta ROM secundaria.

Cuando acabe veremos un nuevo menú, el multiarranque (una maravilla) elegimos la segunda opción que será nuestra ROM secundaria donde queremos instalar el NetHunter. Iniciamos, conectamos a Internet, añadimos cuenta gmail, abrimos PLAY STORE buscamos BUSYBOX (repito que me fue necesario) y reiniciamos en modo recovery.

Ahora vamos a instalar NetHunter ENCIMA de nuestra STOCK ROM 4.4.4 SECUNDARIA porque como ya hemos dicho, NetHunter necesita apoyarse en esta versión de Android para funcionar.

Elegimos en el TWRP RECOVERY:

– ADVANCED

– MULTIROM

– LIST ROM

– Seleccionar la que aparece

– Flash ZIP (botón pequeño)

– Buscamos NetHunter e instalamos.

Unas imágenes para que podáis ver mejor lo que aparecerá.

 Tras unos interminables 20 minutos aproximadamente se instalará por completo. No os desesperéis porque tarda. A continuación reiniciais y elegís la ROM secundaria. Aviso que si os despistáis cargará la ROM Primaria que es también STOCK ROM (cuántas veces habré dicho STOCK ROM? xD) pero sin el complemento (de un 1gb nada más y nada menos ) NetHunter.

Elegís la segunda en la lista, y cargará. Ahora en el menú aplicaciones podréis ver algunas APP que no vienen “de fábrica”. Estás APPs son para utilizar Kali Linux NetHunter en tu terminal Nexus.

 Es posible que quizás al iniciar el la ROM con NetHunter y entrar a KaliMenú no encuentre rutas en la consola (terminal). Para ello el proceso a seguir es:

    Iniciar Recovery
    ADVANCED/MULTIROM/LIST ROM Seleccionar la recién instalada STOCK ROM con Nethunter como secundaria.
    Flash ZIP e instalar encima de nuevo STOCK ROM 4.4.4
    Al acabar el proceso, realizar lo mismo que en este primer paso, pero instalar SUPERSU(para ROOTEAR).
    Volver a hacer lo mismo pero seleccionar ahora NetHunter.

Este paso tuve que realizarlo para que me funcionara por completo en la consola del KaliLinux en el teléfono ya que iniciaba pero no existían las rutas de las aplicaciones.

He intentado resumir el proceso y generalizarlo un poco puesto que como ya advertí no es un tutorial en sí y pueden faltar pasos que los he obviado.

Pues esto es todo, cómo utilizar NetHunter para probar nuestros sistemas será en otro capítulo de nuestro blog.

Espero que ante tanto caos os haya servido de referencia y podáis disfrutar de un multiarranque para auditar vuestras redes.

Hacemos los reinicios pertinentes y entramos a recovery. (Volumen Abajo y Power). Hecho esto deberíamos tener instalado ya un recovery con soporte multirom.

Ahora vamos a añadir una ROM a nuestro MULTIARRANQUE.

Entramos en Recovery, con Volumen Abajo y Power. Seguimos estos pasos: ADVANCED/MULTIROM/ADD ROM botón NEXT luego opción ZIP FILE buscamos nuestra STOCK ROM 4.4.4 la seleccionamos y procedemos a instalar. Cuando acabe, volvemos a hacer estos pasos pero eligiendo LIST ROM en vez de ADD ROM y seleccionando SUPERSU para rootear esta ROM secundaria.

Cuando acabe veremos un nuevo menú, el multiarranque (una maravilla) elegimos la segunda opción que será nuestra ROM secundaria donde queremos instalar el NetHunter. Iniciamos, conectamos a Internet, añadimos cuenta gmail, abrimos PLAY STORE buscamos BUSYBOX (repito que me fue necesario) y reiniciamos en modo recovery.

Ahora vamos a instalar NetHunter ENCIMA de nuestra STOCK ROM 4.4.4 SECUNDARIA porque como ya hemos dicho, NetHunter necesita apoyarse en esta versión de Android para funcionar.

Elegimos en el TWRP RECOVERY:

– ADVANCED

– MULTIROM

– LIST ROM

– Seleccionar la que aparece

– Flash ZIP (botón pequeño)

– Buscamos NetHunter e instalamos.

Unas imágenes para que podáis ver mejor lo que aparecerá.

- See more at: http://hacking-etico.com/2014/10/06/nethunter-kali-linux-en-tu-android/#more-3741

SuperSU (Rootear) – Descargar

Port Knocking con PowerShell

Después de varios días investigando con el USB Rubber Ducky para preparar una ponencia en el VI Congreso ACCID, sobre los peligros de los dispositivos USB si no se dispone de un control de éstos,  y como nos gusta tanto compartir con vosotros nuestras experiencias, os dejo este artículo sobre cómo hacer Port-Knocking con PowerShell para, por ejemplo, poder ejecutarlo desde nuestro querido Pato (USB Rubber Ducky).

A estas alturas creo que todos conocéis ya de sobra a nuestro amigo Pato, oficialmente conocido como USB Rubber Ducky y del que nuestro compañero Goldrak ya nos ha hablado. Si aún no habéis leído sus dos primeros artículos de esta serie, os aconsejo que lo hagáis:
A estas alturas creo que todos conocéis ya de sobra a nuestro amigo Pato, oficialmente conocido como USB Rubber Ducky y del que nuestro compañero Goldrak ya nos ha hablado. Si aún no habéis leído sus dos primeros artículos de esta serie, os aconsejo que lo hagáis:
¿Por qué Port Knocking?

La idea original era que el Pato ejecutara una instrucción PowerShell para descargar desde un servidor Web el payload que previamente habríamos preparado con Metasploit, para que la víctima (mejor dicho, nuestro Pato) lo descargara y ejecutara para obtener una sesión Meterpreter.

Así lo hice, monté mi servidor Web con Apache, generé con msfpayload un payload de tipo windows/meterpreter/reverse_tcp con los parámetros correspondientes y subí el fichero al servidor Web, listo para su descarga.

Problema: si dejo el servidor Web funcionando continuamente a la espera de algún ataque con el Pato, corro el riesgo de que el servidor y el recurso sean indexados por buscadores, crawlers y otras arañas. Lo ideal sería que fuera el propio Pato el que levantara el servicio Web, descargara el payload, y bajara el servicio. De esa forma dejar el servidor lo más “invisible” posible.

Se me ocurrió hacerlo con Port-Knocking, así que instalé knockd en mi servidor, donde tengo montado el servidor Web y subido el payload. El siguiente paso era configurar el knockd para que al “tocar” los puertos TCP 7000, 8000 y 9000 en un tiempo máximo de 10 segundos, levante el servicio Web, espere 30 segundos y lo vuelva a bajar. ¿Sencillo verdad?

Este es el archivo de configuración de knock.conf:

    [options]

    logfile = /var/log/knockd.log

    sequence    = 7000,8000,9000

    seq_timeout = 10

    command     = service apache2 start ; sleep 30 ; service apache2 stop

    tcpflags    = syn

En la opción command, escribo los comandos que quiero que se ejecuten en caso de que haya un Port-Knocking correcto: Iniciar Apache, esperar 30 (tiempo para la descarga del payload) y parar Apache.

Seguía teniendo un problema, y es que necesitaba un cliente de Port-Knocking. Hay varios clientes para Windows, pero necesitaría su descarga.  Otra opción sería con telnet o netcat, pero en las últimas versiones de Windows no están instaladas por defecto.

¡Houston! Aquí es donde me acordé de mi amigo Pablo González y de su charla en Qurtuba CON sobre PowerShell. ¿Por qué no intentar hacer Port-Knocking con PowerShell? Así que me puse manos a la obra y a investigar, de paso me vendría bien para adentrarme en este mundo de PowerShell, ya que yo soy más de “pingüinos”.

Pronto me empecé a llevar gratas sorpresas y di con clases y métodos tales como:

    powershell (New-Object System.Net.Sockets.TcpClient).Connect(‘ip-address,’port’)

Que permite establecer como Cliente TCP una conexión al servidor y puerto que indiquemos. Así que probé a realizar la “llamada a puertos” con esta instrucción, repitiendo por cada puerto (7000, 8000, y 9000)

El knockd estaba esperando en un tramo máximo de 10 segundos, knocking a los puertos TCP 7000, 8000 y 9000, pero al ejecutarlos con PowerShell no lograba pasar todos los stages del Port-Knocking. Pensé que podía ser por el tipo de conexión, al no indicar nada, el cliente TCP intentaría llevar a cabo el Three-Way Handshake completo, lo que me podría causar problemas. Lo ideal sería poder indicar tipo de flag en los paquetes que envía el cliente, para que sólo envíe de tipo SYN, pero no encontré la forma.

Sin embargo, sí me encontré con otro método de la clase anterior, llamado BeginConnect que realiza una conexión asíncrona, y que por el tipo de conexión sí que me cuadraba más para poder llevar a cabo el Port-Knocking de forma exitosa.

    powershell (New-Object System.Net.Sockets.TcpClient).BeginConnect(‘ip-address’,’port’,$null,$null)

Con la dirección IP y los puertos correspondientes, ejecutándolos en un tramo máximo de 10 segundos, conseguí el Ábrete Sésamo del knockd. ¡Bingo!

,

Bastaría con cambiar el puerto por 8000 y 9000, siempre y cuando se ejecuten dentro de esos 10 segundos.

    [2015-05-28 08:17] 8x.1x.16x.4x: prueba: Stage 1
    [2015-05-28 08:17] 8x.1x.16x.4x: prueba: Stage 2
    [2015-05-28 08:17] 8x.1x.16x.4x: prueba: Stage 3
    [2015-05-28 08:17] 8x.1x.16x.4x: prueba: OPEN SESAME

Ya tan sólo me quedaría modificar el script del Pato, añadiendo las líneas correspondientes del Port-Knocking con PowerShell. La última línea del script del Pato sería la descarga y ejecución del payload.

Bastaría con cambiar el puerto por 8000 y 9000, siempre y cuando se ejecuten dentro de esos 10 segundos.

[2015-05-28 08:17] 8x.1x.16x.4x: prueba: Stage 1
[2015-05-28 08:17] 8x.1x.16x.4x: prueba: Stage 2
[2015-05-28 08:17] 8x.1x.16x.4x: prueba: Stage 3
[2015-05-28 08:17] 8x.1x.16x.4x: prueba: OPEN SESAME

Ya tan sólo me quedaría modificar el script del Pato, añadiendo las líneas correspondientes del Port-Knocking con PowerShell. La última línea del script del Pato sería la descarga y ejecución del payload.

En próximos artículos veremos cómo llevar a cabo estos pasos.
- See more at: http://hacking-etico.com/2015/05/28/port-knocking-con-powershell/#more-4425