Material de la REcon 2016

REcon es una conferencia de seguridad que tiene lugar anualmente en Montreal y que está enfocada a la ingeniería inversa y a las técnicas de explotación avanzadas. Hace unos días vi que publicaron prácticamente todo el material, incluido los vídeos de todas las charlas... así que para quien quiera aprovechar el fin de semana, ahí se lo dejo... ;)

Presentaciones:
Videos:
Web: https://recon.cx/

Envío seguro de contraseñas... ¡a través del cuerpo humano!

El envío de una contraseña o código secreto a través de ondas de radio como WiFi o Bluetooth significa que cualquiera podría "escuchar" a escondidas, por lo que esas transmisiones pueden ser vulnerables a hackers que intenten romper el código cifrado.

Ahora, los científicos informáticos e ingenieros eléctricos de la Universidad de Washington han ideado una manera de enviar contraseñas seguras a través del cuerpo humano, usando transmisiones benignas de baja frecuencia (por debajo de 30 mhz) generadas por los sensores de huellas digitales y pantallas táctiles de los dispositivos de consumo.

"Los sensores de huellas dactilares hasta el momento se han utilizado como un dispositivo de entrada. Lo que es interesante es que hemos demostrado por primera vez que los sensores de huellas digitales pueden ser re-utilizados para enviar información hacia al cuerpo", dijo el autor principal Shyam Gollakota, profesor asistente de la Universidad de Washington de informática e ingeniería.

Estas transmisiones "sobre el cuerpo" ofrecen una forma más segura para transmitir la información de autenticación entre dispositivos que tocan partes del cuerpo (como una cerradura inteligente o un wearable médico) y un teléfono o dispositivo que confirma la identidad pidiendo la contraseña.

Esta nueva técnica aprovecha las señales ya generadas por los sensores de huellas digitales de los smartphones y los touchpads de los ordenadores portátiles para transmitir los datos de nuevas maneras, tal y como se describe en el paper presentado en septiembre en el 2016 en la UbiComp de Alemania.

"Digamos que quiero abrir una puerta con una cerradura electrónica inteligente", comenta Merhdad Hessar, otro de los autores. "Puedo tocar el pomo de la puerta y tocar el sensor de huellas dactilares en mi teléfono y transmitir mis credenciales secretas a través de mi cuerpo para abrir la puerta, sin fugas de información personal a través del aire."

El equipo de investigación probó la técnica en el iPhone y otros sensores de huellas dactilares, así como con los touchpads de portátiles Lenovo y pantallas táctiles capacitivas Adafruit. Probando con 10 sujetos diferentes, de diferentes alturas, pesos y tipos de cuerpo, fueron capaces de generar transmisiones utilizables. El sistema también trabajó cuando los sujetos estaban en movimiento, incluyendo mientras caminaban y movían sus brazos.

"Hemos demostrado que funciona en diferentes posiciones al pararse, sentarse y dormir" dijo el investigador Vikram Iyer. "También podemos generar una señal fuerte a lo largo del cuerpo. Los receptores pueden estar en cualquier lugar -en la pierna, pecho, manos- y sigue funcionando".

Los investigadores alcanzaron velocidades de 50 bits por segundo en paneles táctiles portátiles y 25 bits por segundo con sensores de huellas digitales, los suficientemente rápido para enviar una contraseña simple o un código numérico a través del cuerpo y hacia un receptor en cuestión de segundos.

Esto representa sólo un primer paso, dicen los investigadores. Los datos pueden ser transmitidos a través del cuerpo aún más rápido si los fabricantes de sensores de huellas digitales proporcionan más acceso a su software.

Fuente: https://techxplore.com/news/2016-09-passwords-body-air.html

WSSAT, un escáner de seguridad de web services

El turco Yalçın Yolalan ha desarrollado como proyecto del máster de administración de software de la Middle East Technical University (METU) una herramienta para testear la seguridad de web services. Se trata de WSSAT - Web Service Security Assessment Tool, un escáner de seguridad de web services que acepta un WSDL como entrada para cada servicio y realiza una serie de pruebas tanto estáticas como dinámicas en busca de vulnerabilidades. De esta manera las organizaciones podrán realizar un análisis de la seguridad de todos sus servicios web a la vez, fortificarlos y tener informes valiosos para obtener una valoración global de la seguridad.


Características:

- Soporta autenticación básica
- Comprueba la autenticación de cada método del web service incluso si el usuario y contraseña es suministrado en el WSDL
- Permite enviar múltiples payloads
- Examina el código de estado, la cabecera y el body HTTP del objeto de respuesta
- Soporta múltiples búsquedas en el texto de respuesta
- Realiza inyecciones SQL en bases de datos Oracle, MSSQL, MySQL y SQLite
- Comprueba el valor o la existencia de un nodo/atributo XML en el análisis stático
- Soporta la comprobación de múltiples nodos XML
- Los informes contienen 3 gráficos para visualizar el nombre, tipo y severidad de las vulnerabilidades encontradas
- Incluye modo de depuración y logs detallados


Pruebas dinámicas:

- Comunicación insegura - No se utiliza SSL
- Método de servicio no autenticado
- Inyección SQL basada en error
- Cross Site Scripting
- Bomba XML
- Ataque de entidad externa - XXE
- Inyección XPath
- Mensajes detallado de errores SOAP

Análisis estático:

- Esquema XML débil: Ocurrencias no acotadas
- Esquema XML débil: Namespace indefinido
- WS-SecurityPolicy débil: Transporte inseguro
- WS-SecurityPolicy débil: Soporte insuficiente de protección de tokens
- WS-SecurityPolicy débil: Tokens no protegidos

Fuga de información:

- Descubrimiento de información del servidor o tecnología

Los principales módulos de WSSAT son:

- Parser
- Cargador de vulnerabilidades
- Analizador/Attacker
- Logger
- Generador de informes

Proyecto: https://github.com/YalcinYolalan/WSSAT

Las 10 contraseñas por defecto más usadas por el malware del IoT

El malware especializado en atacar dispositivos de la Internet de las Cosas (IoT) a menudo basa sus ataques en intentar acceder en primera instancia con las credenciales por defecto del firmware instalado, aprovechando que normalmente un usuario doméstico conecta el dispositivo y no se preocupa en cambiar la contraseña ni, en general, realizar ningún cambio para mejorar la seguridad del dispositivo "inteligente" de turno.

Un interesante informe de Symantec (que os recomiendo leer aquí) revela la lista de las contraseñas por defecto que distintos tipos de malware para IoT han intentado utilizar contra sus honeypots. A destacar 'ubnt' por los gusanos que intentan explotar la vieja vulnerabilidad de los routers Ubiquiti y 'pi' por la creciente tendencia del uso de Raspberry:

UsernamesPasswords
root admin
admin root
DUP root 123456
ubnt 12345
access ubnt
DUP admin password
test 1234
oracle test
postgres qwerty
pi raspberry

Obtención de passwords de Outlook analizando el dump del proceso

Últimamente he andado mirando temas de volcado de procesos para posteriormente analizarlos, o bien con herramientas dedicadas para cada proceso o sencillamente interactuando con el comando string y un poco de grep.

Lo último que probé fue volcar el proceso outlook.exe (versión 2003):
 

procdump -ma outlook.exe outlook.dmp

ProcDump v7.1 - Writes process dump files
Copyright (C) 2009-2014 Mark Russinovich
Sysinternals - www.sysinternals.com
With contributions from Andrew Richards

[17:18:34] Dump 1 initiated: D:\Pruebas\Microsoft\technet\Sysinternals\Procesos y subprocesos\outlook.dmp
[17:19:40] Dump 1 complete: 528 MB written in 66.3 seconds
[17:19:41] Waiting for dump to complete...
[17:19:41] Dump count reached.

Una vez volcado el proceso outlook.exe, dije "pues ahora a jugar un poco con strings"...

Antes de nada, como el protocolo utilizado para el correo en este caso es IMAP, quise informarme un poco de comandos del mismo a través de la RFC.

https://tools.ietf.org/html/rfc3501#page-25

Y me resultó curioso el comando NOOP:

6.1.    Client Commands - Any State

   The following commands are valid in any state: CAPABILITY, NOOP, and LOGOUT.
6.1.2.  NOOP Command

   Arguments:  none
   Responses:  no specific responses for this command (but see below)
   Result:     OK - noop completed
               BAD - command unknown or arguments invalid

      The NOOP command always succeeds.  It does nothing.

      Since any command can return a status update as untagged data, the
      NOOP command can be used as a periodic poll for new messages or
      message status updates during a period of inactivity (this is the
      preferred method to do this).  The NOOP command can also be used
      to reset any inactivity autologout timer on the server.

   Example:    C: a002 NOOP
               S: a002 OK NOOP completed
                  . . .
               C: a047 NOOP
               S: * 22 EXPUNGE
               S: * 23 EXISTS
               S: * 3 RECENT
               S: * 14 FETCH (FLAGS (\Seen \Deleted))
               S: a047 OK NOOP completed

Embeber backdoors en APKs al vuelo con Spade

Spade es un pequeño pero útil script que permite infectar fácilmente APKs con payloads de Android de Metasploit.


Veréis que sólo con unas pocas líneas de Python y Metasploit es posible hacerlo rápidamente:

git clone https://github.com/suraj-root/spade.git
cd spade/
./spade.py


Demo vídeo:
Github: https://github.com/suraj-root/spade

Conexión inversa usando como vector NetHunter o Rubber Ducky (HID attack)

Kali NetHunter (kali.org/kali-linux-nethunter), la plataforma Android de pentesting para dispositivos Nexus, tiene muchas opciones interesantes, entre ellas el "DuckHunter HID" que puede convertir rápida y fácilmente los scripts del USB Rubber Ducky para realizar ataques de tipo HID keyboard, ya sabéis, ataques que convierten el smartphone y su cable OTG USB en un teclado preprogramado, capaz de escribir cualquier comando dado...

Lo que vamos a hacer a continuación es algo muy simple, pero puede ser peligroso cuando se implementa.

Preparando el backdoor en Metasploit

Vamos a utilizar el módulo “script web delivery” (rapid7.com/db/modules/exploit/multi/script/web_delivery), que tiene la ventaja de no tener que crear un archivo ejecutable, y muchas probabilidades de transmitir el malware sin que el AV lo detecte.
 

Para nuestra prueba, elegimos el objetivo 2, que va a generar una secuencia de comandos que se utilizará en PowerShell

Configuración del payload
Payload: payload windows/meterpreter/reverse_tcp
LHOST: IP local, que recibirá la conexión
URIPATH: se puede poner simplemente una “/”
LPORT: puerto local, por defecto el 4444
Script: exploit -j

Demuestran que era posible hackear remotamente un coche Tesla Model S, tanto estacionado... como en movimiento

Los chinos de Keen Lab han descubierto una serie de vulnerabilidades que pueden ser explotadas por un atacante para hackear remotamente un Tesla Model S de fábrica, las reportaron bajo el programa de recompensas de Bugcrowd y de paso se embolsaron la nada despreciable cifra de 10.000$.

Aunque de momento no han publicado los detalles técnicos, para demostrar las vulnerabilidades publicaron un impresionante vídeo con la PoC del hack que muestra cómo fueron capaces de tomar el control del techo solar, de la posición de los asientos, de las señales de giro y del sistema de cierre de puertas. La parte más impactante fue cuando el coche estaba en movimiento, momento en que fueron capaces de activar los frenos y los limpiaparabrisas, plegar los espejos laterales y abrir el maletero.


Keen Lab explicaba en su blog: "Con varios meses de investigación en profundidad sobre los coches Tesla, hemos descubierto múltiples vulnerabilidades de seguridad y aplicado con éxito remotamente, sin contacto físico ninguno, el control sobre el Tesla Model S, tanto en modo de conducción como de estacionamiento. Vale la pena señalar que se utilizó un coche sin modificar con el último firmware para demostrar el ataque".

Los investigadores son el primer equipo de hackers capaz de poner en peligro el Bus CAN de control remoto de los coches de Tesla mediante la explotación de una serie de defectos.

"Por lo que sabemos, este es el primer caso de ataque a distancia que compromete el bus CAN para lograr control remoto de los coches de Tesla. Hemos verificado el vector de ataque en múltiples variedades de Tesla Model S. Es razonable suponer que otros modelos de Tesla se ven afectados. A Keen Lab le gustaría enviar este recordatorio a todos los propietarios de automóviles Tesla".

Actualización: Tesla ha comprobado la existencia de las vulnerabilidades y ya las ha parcheado, lo bueno es que la empresa no llevará a taller ningún Tesla Model S porque es capaz de aplicar las actualizaciones de firmware "on-air". Este es su comunicado oficial:

"Tan sólo 10 días después de recibir este informe, Tesla ya ha desplegado una actualización de software over-the-air (v7.1, 2.36.31) que soluciona los problemas de seguridad potenciales. La vulnerabilidad sólo aplica cuando se utiliza el navegador web y también requiere que el coche esté físicamente cerca y conectado a un punto de acceso wifi malicioso. Nuestra estimación realista es que el riesgo para nuestros clientes fue muy bajo, pero esto no nos impidió responder con rapidez".

Fuentes:
- Car Hacking Research: Remote Attack Tesla Motors 
- A group of security researchers from the Chinese firm Tencent have found a series of flaws that can be exploited to remotely hack a Tesla Model S.
- First Tesla Model S remotely controlled by hackers, Tesla already pushed a fix

WinPayloads - generación de payloads indetectables para Windows

WinPayloads de NCCGroup es una herramienta de generación de payloads escrita en Python 2.7 que utiliza el shellcode de meterpreter, inyecta la IP y el puerto del usuario en el shellcode y escribe un archivo de Python que ejecuta dicho shellcode usando ctypes. Posteriormente es cifrado con AES y compilado a un ejecutable de Windows usando PyInstaller.


Características:

- Generación de payloads de Windows indetectables
- GUI fácil de utilizar
- Subida del payload a un WebServer local
- Psexec del payload al equipo destino
- Automáticamente ejecuta el listener de Metasploit con la configuración correcta después de que se haya generado el payload

WinPayloads viene también con algunas características como el bypass UAC y la persistencia de payloads. Estos son archivos de PowerShell que se ejecutan en el sistema cuando el meterpreter consigue una shell inversa. El bypass UAC viene con PowerShellEmpire y utiliza el exploit para evadir UAC con las cuentas de administrador local y crea un shell de meterpreter inverso contra la máquina del atacante como administrador local.

WinPayloads puede también instalar un SimpleHTTPServer para poner el payload en red y permitir descargarlo en el equipo de destino. Además mediante psexec (psexec.py) puede ejecutar directamente en el equipo objetivo si se suministra con nombres de usuario, contraseñas de dominio, o hashes.

Instalación y uso

git clone https://github.com/nccgroup/winpayloads.git
cd winpayloads
sudo ./setup.sh
./Winpayloads.py
Escribe 'help' o '?' para ayuda
setup.sh -r (reinstalar)

Demo:

Proyecto: https://github.com/nccgroup/Winpayloads

CryptoTrooper: el primer ransomware 'white-box' con propósitos educativos para Linux

CryptoTrooper, de Maksym Zaitsev alias cryptolok, es el primer ransomware de tipo white-box o caja blanca para Linux del mundo, con propósitos educativos.

Requiere :

- Un SO de 32/64 bits basado en Debian con privilegios de root
- Apache/Nginx - para el cifrado de servicios web y para cambiar la página principal
- MySQL/PostgreSQL - para el cifrado de base de datos
- / y /home - para el cifrado de los datos personales, excepto el directorio .ssh

Cómo funciona :

- Infección - el servidor de la víctima es comprometido e infectado de alguna manera, obteniendo privilegios de root
- Cifrado - el ransomware genera una clave única de cifrado simétrico y cifra los datos
- White-box - la criptografía de caja blanca intenta proteger la clave secreta del cifrado en un entorno en que adversario tiene acceso completo a la implementación y al entorno de ejecución. El sistema de cifrado utiliza la clave de una sola dirección y cifra la clave utilizada para el cifrado de datos
- Descifrado - la víctima envía al atacante la clave de cifrado de caja blanca y su vector de inicialización (IV), esta clave se descifra por el atacante con su IV y la clave maestra que se utiliza para generar la clave white-box, la verdadera clave se envía a la víctima.

Pros:

- No se requiere conexión a Internet después de la infección (ya que no se utiliza el cifrado de clave pública en ningún C&C)
- Protección contra la extracción de clave
- Sólo AES
- Anti-forense
- Generación aleatoria de claves
- Random IV

Inyección de shellcodes en ejecutables con Shellter VI

Los ejecutables creados con Metasploit u otros frameworks de pentesting conocidos son detectados por la mayoría de los AV. Una de las herramientas que podemos usar para evadirlos es Shellter, con la que dispondremos de una "plantilla" polimórfica que se puede utilizar para insertar nuestros shellcodes en cualquier ejecutable *standalone nativo de Windows en 32 bits.

* por "standalone" entendemos un ejecutable que no está estáticamente vinculado a cualquier DLL propietaria, además de las incluidas por defecto en Windows. Se podría incluir librerías junto un ejecutable siempre que no sean necesarias para crear inicialmente el proceso, pero ya sabéis que no es recomendable.

Podemos decir que Shellter es una herramienta de inyección dinámica de shellcodes o PE infector. Por lo tanto puede usarse para inyectar shellcodes, tanto propios como los generados con Metasploit, en las aplicaciones nativas de Windows (repetimos: de momento sólo aplicaciones de 32 bits).

Shellter aprovecha la estructura original del archivo PE y no aplica modificaciones fácilmente detectables por los AV, tales como cambiar el permiso de acceso a la memoria en las secciones (a menos que el usuario lo especifique) o la adición de una sección con acceso de RWE. Tampoco es el típico infector que trata de encontrar un lugar para insertar instrucciones para redirigir la ejecución del payload. A diferencia de muchos, el motor de infección avanzado de Shellter nunca transfiere el flujo de ejecución a un code cave o añade una sección en el archivo PE infectado. Entonces, ¿cuál es la magia de Shellter?

Shellter utiliza un enfoque dinámico único que se basa en el flujo de ejecución de la aplicación objetivo. Esto significa que no se utilizan ubicaciones predefinidas o estáticas para la inyección de código shell. Shellter ejecutará y trazará el objetivo, mientras que al mismo tiempo registrará el flujo de ejecución de la aplicación en espacio de usuario. Esto incluye el código dentro de la aplicación en sí misma (imagen PE), y el código fuera de ella que podría ser en un archivo DLL del sistema o sobre un heap, etc ... Esto se hace para asegurar que las funciones realmente pertenecen al ejecutable, pero se usan solamente como funciones de callback para que el API de Windows no las pierda.

Durante el trace, Shellter no registrará o tendrá en cuenta cualquier instrucción que no esté en el rango de memoria de la imagen PE de la aplicación de destino, ya que estos no pueden ser utilizado como una referencia para inyectar de forma permanente el shellcode.

0-day en MySQL permite ejecución remota de comandos (CVE-2016-6662): con un usuario con privilegios mínimos y "jugando" con el logging

El pasado 29 de agosto el investigador Dawid Golunski informó de varios problemas graves en MySQL, entre ellos una vulnerabilidad que puede ser explotada por atacantes remotos para inyectar configuraciones maliciosas en ficheros my.cnf y derivar en la ejecución de código arbitrario con privilegios de root o, lo que es lo mismo, comprometer completamente al servidor que ejecuta MySQL.

El caso es que los desarrolladores de "sus hermanas menores" MariaDB y PerconaDB ya publicaron sendos parches para solucionarlo, algo que Oracle no ha hecho todavía *increiblemente*. El problema es que al estar los parches disponibles en los repositorios públicos de PerconaDB y MariaDB cualquiera puede empezar a explotar la vulnerabilidad por lo que el investigador se ha apresurado a publicarlo junto con las PoC correspondientes.

La vulnerabilidad detallada es la que tiene el id CVE-2016-6662, que puede ser aprovechada por un atacante que pueda autenticarse directamente contra la base de datos MySQL a través de una conexión de red o un interfaz web como phpMyAdmin, o de forma indirecta a través de una inyección SQL.

Pre-carga de librerías como root

El ataque es efectivo contra la configuración por defecto de todas las releases de MySQL, incluyendo 5.5, 5.6 y 5.7. Concretamente porque todas las versiones usan el script mysqld_safe como un wrapper para iniciar el servicio de MySQL que se ejecuta como root:
root     14967  0.0  0.1   4340  1588 ?        S    06:41   0:00 /bin/sh /usr/bin/mysqld_safe

mysql    15314  1.2  4.7 558160 47736 ?        Sl   06:41   0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql --log-error=/var/log/mysql/error.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --port=3306

Y este script tiene la siguiente función que puede utilizarse para precargar una librería compartida antes de iniciar el servidor:
----[ /usr/bin/mysqld_safe ]----

[...]

# set_malloc_lib LIB
# - If LIB is empty, do nothing and return
# - If LIB is 'tcmalloc', look for tcmalloc shared library in /usr/lib
#   then pkglibdir.  tcmalloc is part of the Google perftools project.
# - If LIB is an absolute path, assume it is a malloc shared library
#
# Put LIB in mysqld_ld_preload, which will be added to LD_PRELOAD when
# running mysqld.  See ld.so for details.
set_malloc_lib() {
  malloc_lib="$1"

  if [ "$malloc_lib" = tcmalloc ]; then
    pkglibdir=`get_mysql_config --variable=pkglibdir`
    malloc_lib=
    # This list is kept intentionally simple.  Simply set --malloc-lib
    # to a full path if another location is desired.
    for libdir in /usr/lib "$pkglibdir" "$pkglibdir/mysql"; do
      for flavor in _minimal '' _and_profiler _debug; do
        tmp="$libdir/libtcmalloc$flavor.so"
        #log_notice "DEBUG: Checking for malloc lib '$tmp'"
        [ -r "$tmp" ] || continue
        malloc_lib="$tmp"
        break 2
      done
    done

[...]

Esta librería podría ser especificada con el parámetro --malloc-lib=LIB o... directamente en la sección '[mysqld]' o '[mysqld_safe]' del fichero de configuración my.cnf.

Como veis, si un atacante consigue inyectar una línea en ese fichero de configuración podría ser capaz de cargar una librería maliciosa y ejecutar código como root en el momento en que se reinicie el servicio de MySQL. ¿Pero cómo puede un atacante escribir en los ficheros de configuración de mysql? Veamos...

A Black Path Toward The Sun: herramienta para crear un túnel TCP sobre HTTP/HTTPS

Los servidores de aplicaciones web son uno de los puntos de entrada más visibles de una organización por lo que suelen bastionarse y restringirse su perímetro filtrando los puertos mediante firewalls (permitiendo normalmente sólo HTTP y HTTPS desde Internet) y añadiendo una capa de seguridad extra mediante algún WAF y/o IPS. Sin embargo por su propia idiosincrasia, las 'webapps' y los 'webservices' suelen tener fallos que pueden comprometer el servidor, ya sea por un desarrollo no seguro que permite alguna inyección o upload arbitrario o por algún "despiste" en su administración como el uso de credenciales por defecto o de contraseñas predecibles o débiles.

El resultado muchas veces es la capacidad de ejecución remota de comandos (RCE) en la máquina o incluso la obtención de una webshell, que sin embargo y como comentamos puede verse muy limitada en su uso por la infrastructura de red y seguridad perimetral que protege al servidor de aplicaciones. Por ejemplo, es muy común que no se permita la salida a Internet desde el servidor arruinándonos las conexiones inversas e incluso bloquear ICMP o DNS hacia fuera haciendo lo propio al intentar establecer un túnel por esos protocolos.

La solución pasa por establecer un túnel TCP a través del servidor de aplicaciones web usando su propio interfaz HTTP/HTTPS. Esto permite establecer directamente una sesión RDP, un SSH interactivo, meterpreter, subir/bajar ficheros con mayor facilidad, etc. y por supuesto, pivotar para continuar con el movimiento lateral.

Para esto ya conocíamos reGeorg o node-http-tunnel, pero en el arsenal de la BlackHat de 2016 se presentó otra herramienta que es una maravilla... Se llama 'A Black Path Toward The Sun' o ABPTTS que provee dos componentes principales:

- un cliente en Python que escucha conexiones TCP y se encarga de la traducción entre los datos en crudo (raw) y las peticiones HTTP que son enviadas al componente servidor

- una página o un paquete que se sube al servidor (actualmente disponibles en JSP/WAR y ASP.NET) y que levanta un listener para recibir las peticiones HTTP del cliente y convertirlas en datos raw que son enviados a través de un segundo listener que levanta el servidor de aplicaciones

Como veis su objetivo cliente-servidor es establecer un túnel TCP sobre HTTP/HTTPS. Además este túnel se cifra con AES128 lo que dificulta la detección por firmas por parte de IDS/IPS/WAF y dejando como única alternativa la inspección manual u otras técnicas.

¿Tienes el PC bloqueado? Aún te pueden robar las contraseñas conectando un simple USB

Aunque en ocasiones se nos olvida, normalmente tenemos la sana costumbre de bloquear nuestro ordenador cuando nos ausentamos temporalmente para por ejemplo ir a por un café o a comer. Incluso dejamos el equipo encendido bloqueado cuando terminamos la jornada para que al día siguiente no perdamos tiempo y podamos inmediatamente reanudar la actividad. Si bien esto parece una buena medida de seguridad y nos hace sentir seguros, esta semana Rob Fuller de R5 industries ha demostrado que todo lo que se necesita para robar los hashes de las contraseñas del PC bloqueado es conectar un USB durante unos segundos. El hash más adelante puede ser crackeado o utilizado directamente en algunos ataques a la red.

Para su ataque, Fuller utiliza un pequeño ordenador del tamaño de un dispositivo flash llamado USB Armory que cuesta 100€, aunque el mismo ataque se puede sacar con dispositivos más baratos, como Hak5 LAN Turtle que cuesta $50.

El dispositivo tiene que hacerse pasar por un adaptador LAN ethernet USB de tal manera que se convierte en la interfaz de red principal en el equipo al que se conecta. Esto no debería ser difícil porque: 1) los sistemas operativos inician automáticamente la instalación de los dispositivos USB conectados incluyendo tarjetas de red, incluso cuando están en un estado de bloqueo y 2) configuran automáticamente las tarjetas Ethernet por cable como las puertas de enlace predeterminadas.

Por ejemplo, si un atacante enchufa un adaptador USB-Gigabit Ethernet falso en un portátil con Windows bloqueado que normalmente utiliza una conexión inalámbrica, el adaptador se instalará y se convertirá en la interfaz de red preferida.

Por otra parte, cuando una nueva tarjeta de red se instala, el sistema operativo intenta obtener la configuración automática mediante el protocolo de configuración dinámica de host (DHCP). Esto significa que un atacante puede tener un equipo malicioso en el otro extremo del cable Ethernet que actúa como un servidor DHCP. Como comentamos, USB Armory es un ordenador en un dispositivo que se alimenta a través de USB y puede ejecutar Linux, por lo que no se requiere un equipo diferente.

Una vez que el atacante controla la configuración de red de un equipo a través de DHCP, también controla las respuestas DNS (Domain Name System), y puede configurar un proxy de Internet falso a través del protocolo WPAD (descubrimiento automático de proxy web). Esencialmente ganará una posición privilegiada para un ataque man-in-the-middle que se puede utilizar para interceptar y manipular el tráfico de red del ordenador.

Según Fuller, los equipos bloqueados aún generan tráfico de la red, lo que permite que el nombre de cuenta y la contraseña (hash) puedan ser extraídos. El tiempo necesario para que un dispositivo USB capture las credenciales de un sistema mediante este ataque es de alrededor 13 segundos, dijo.

Probó el ataque con éxito en Windows y OS X. Sin embargo, todavía se está trabajando en confirmar si OS X es vulnerable por defecto o si fue configuración particular de su Mac que era vulnerable.

"En primer lugar, esto es demasiado simple y no debería funcionar, pero lo hace," dijo el investigador en un blog. "Además, no es posible de que yo sea el primero que ha identificado esto, pero ahí está."

Dependiendo de la versión de Windows instalada en el equipo y su configuración, los hashes de las contraseñas estarán en NT LAN Manager (NTLM) versión 2 o formato NTLMv1. Los hashes NTLMv2 son más difíciles de descifrar, pero no es imposible, especialmente si la contraseña no es muy compleja y el atacante tiene acceso a una plataforma potente.

Hay también algunos ataques contra los servicios de red de retransmisión, donde los hashes NTLM se puede utilizar directamente sin necesidad de conocer la contraseña en texto plano del usuario (pass-the-hash).

La lección de todo esto es, como Fuller señaló en Twitter: "No dejes tu PC conectado, especialmente durante la noche, sin vigilancia, aunque bloquees la pantalla".

Fuentes:
- A USB device is all it takes to steal credentials from locked PCs
- Snagging creds from locked machines

Instalando PowerShell en Kali Linux

No hay duda de que Microsoft está replanteando su filosofía. En abril y con la colaboración de Canonical (Ubuntu) nos sorprendió integrando bash en Windows 10 y más recientemente, el 15 de agosto, lo volvió a hacer liberando y publicando el código de PowerShell en GitHub. El resultado es que ahora podemos instalar PowerShell también en Linux y Mac OS. Incluso la versión DSC añade diez recursos "built-in" para las operaciones de configuración de Linux más comunes...

Evidentemente parece que la estrategia de Microsoft es extenderse por sistemas heterogéneos para posicionar y universalizar servidores Windows (o en general su tecnología) y probablemente sea así pero, sea como fuere, tener un CLI de PowerShell directamente en nuestro shell es una auténtica delicia para los pentesters que ahora podemos administrar (o explotar) remotamente servidores Windows sin necesidad de levantar una máquina virtual Windows. Así que...¿por qué no? Instalarlo en Kali Linux (rolling 2016) sólo son unos sencillos pasos:
 
1.- Dependencias: sudo apt-get install libunwind8 libicu55
2.- Descarga: wget https://github.com/PowerShell/PowerShell/releases/download/v6.0.0-alpha.9/powershell_6.0.0-alpha.9-1ubuntu1.16.04.1_amd64.deb
3.- Instalación: sudo dpkg -i powershell_6.0.0-alpha.9-1ubuntu1.16.04.1_amd64.deb
4.- Ejecución: powershell

Y ya está, si veis los comandos disponibles comprobaréis que a priori es casi idéntica a una instalación estándar.  

Get-Module -ListAvailable | % {(Get-Module $_.name).ExportedCmdlets | FT -Autosize}


GitHub: https://github.com/PowerShell/PowerShell

Cheatsheet Linux systemd vs sysVinit

Yo no sé vosotros, pero seguro que no soy el único al que la imparable incursión de systemd le resulta un poco irritante. ¿Por qué? Pues porque observamos acontecidos como distro tras distro se va implementando en las actualizaciones y sin embargo no termina de convencernos.

Quizás alguno piense que después de tantos años a algunos nos cuesta desprendernos del clásico SystemV y sus scripts de inicio en /etc/rc.d/init.d/, demonios y procesos en segundo plano. Pero no es sólo eso; son muchas las voces que denuncian que, aunque el gestor de inicio de la todopoderosa Red Hat tiene algunas ventajas (paralelización, cgroups, units), podría haberse hecho mejor y que, aún así, se sigue introduciendo inexorablemente y podría llegar a ser un componente insustituible en todo sistema Linux.

Por ejemplo en OpenSuse, CentOS y por supuesto Fedora/RHEL no pueden usar otro init.
Además udev, el gestor de dispositivos de Linux ha pasado a integrarse en systemd por lo que cualquier programa que necesite udev ahora también necesitará systemd. Y esto es sólo una muestra, a la vez que se va anexando más funciones y subcomponentes se va haciendo también más complejo y difícil de manejar (recordar que systemd es el proceso padre o PID1 y si cae lo hace también el sistema).

Os recomiendo que leáis la entrada de Linuxito en la que veréis diversas razones por las que SystemD "es una mierda", o eso opina y con muchos argumentos por cierto.

Sea como fuere, conviene dominar systemd lo antes posible (antes de que nos domine a nosotros xD), así que hoy os traemos un pequeño cheatsheet de linoxide, casi a modo de infografía, donde podréis comparar los runlevels y comandos entre ambos sistemas de inicio del kernel.

Podéis verlo en la imagen del post de la derecha o descargarlo directamente:

Versión PDF of the systemd vs sysvinit cheatsheet.
Tamaño A4: versión JPG o versión PDF.

pd. ¿Y tú? ¿Estas a favor o en contra de systemd?

IronSFTP: transfiere por SSH y además deja los ficheros cifrados en ambos extremos

Casi todos los servidores actuales tienen SSH con el subsistema SFTP para permitir la transferencia segura (cifrada) de archivos entre dos máquinas. Pero hablamos de asegurar sólo la "transferencia" porque, cuando esta se realiza, los archivos enviados normalmente permanecen en cada uno de los extremos sin cifrar. Esto comunmente es un gran error porque, aunque evitamos que los datos sean capturados mediante un ataque MiTM, un hacker malicioso habría podido comprometer antes uno de los servidores y sólo tendría que esperar tranquilamente a que los datos sensibles se "depositaran" en el directorio correspondiente.

IronSFTP es una alternativa casi idéntica al SFTP desde la línea de comandos con la salvedad de que soluciona el problema que comentamos, es decir, los archivos permanecen cifrados después de ser transferidos. Y lo hace de forma fácil y transparente para los usuarios, gestiona las claves de forma automática y cifra/descifra los archivos residentes en los servidores.
 
SFTP vs IronSFTP
Los archivos cifrados y las claves generadas son compatibles con GPG 2.1.7+, por lo que pueden ser descifrados sin el IronCore. Además, IronSFTP es un fork de OpenSSH y su código está disponible en GitHub bajo licencia BSD.

IronSSH usa libsodium y Curve25519 para el cifrado de la clave pública de la clave simétrica de los archivos y AES256-CFB para los contenidos.  La clave de cifrado local se asegura mediante la clave SSH RSA del usuario. Cuando un usuario abre la clave RSA local esta se usa para desbloquear (o para proteger a crear inicialmente) sus claves de cifrado compatibles con GPG. Esto significa que después de desbloquear una de las claves, las funciones de cifrado y descifrado también están desbloqueadas.

IronSSH requiere OpenSSL 1.0.2+ y los sistemas operativos compatibles son:

- CentOS 7
- Red Hat Enterprise 7
- Fedora 23, 24
- Debian Stretch
- Ubuntu Wily, Xenial, yakkety
- MacOS estará disponible a través de homebrew en breve
- Otros sistemas operativos soportados a través de la compilación del código fuente

Puedes encontrar los detalles de instalación en su página web.

Fuentes:

usbdeath: script antiforense para USBs mediante reglas udev

El año pasado os hablábamos muy brevemente de usbkill, un pequeño script en Python que apaga el PC en cuanto detecta cambios en cualquier puerto USB, muy útil para joder impedir el trabajo del forense de turno que conecta un disco para extraer un volcado de memoria.
Hoy os traemos usbdeath otra herramienta inspirada en usbkill pero con algunas diferencias:

- está escrita en bash
- no es un daemon en sí mismo si no que usa la monitorización y manipula las reglas de udev, ya sabéis, el gestor de dispositivos que usa el kernel Linux desde la versión 2.6. Crea reglas udev para los dispositivos USB conocidos y permite acciones en caso de cambios con los mismos o con dispositivos desconocidos.
- utiliza más valores de identificar dispositivos USB (nombres y números de serie)

Para empezar a usarlo simplemente elimina o comenta la línea del script demo='yes' y edita los triggers (por defecto sync y poweroff).
Luego es recomendable ponerlo en el PATH y no moverlo después de activarlo, ya que el archivo de reglas /etc/udev/rules.d/00-usbdeath.rules se basa en la ruta de acceso absoluta.
No obstante se puede cambiar en la sección de configuración "avanzada".

Uso: usbdeath acción

Las acciones disponibles son:
o, on - activar usbdeath
x, off - desactivar temporalmente usbdeath
j, eject - añadir una entrada en un evento eject
g, gen - generar o refrescar el fichero whitelist de udev
d, del - borrar el fichero de reglas de udev
t, trigger - disparar un evento al insertar o quitar el dispositivo
e, edit - editar el fichero de reglas udev manualmente
s, show - mostrar los dispositivos usb conectados

Github: https://github.com/trpt/usbdeath