Comparativa de herramientas de enumeración de subdominios

Hoy os traemos una interesante comparativa del italiano Ricardo Iramar con diversas herramientas de enumeración de subdominios:
La máquina usada para las pruebas fue una VM en VirtualBox con la instalación mínima de Ubuntu 18.04 LTS (64 bits). Todas las herramientas se instalaron siguiendo el procedimiento estándar proporcionado por la documentación oficial correspondiente y se ejecutaron con las opciones predeterminadas para realizar una comparación lo más justa posible. El dominio para las pruebas fue spotify.com y después de la ejecución de cada herramienta los subdominios encontrados se filtraron con:

while read i; do digout=$(dig +short ${i//[$'\t\r\n ']}); if [[ ! -z $digout ]]; then echo ${i//[$'\t\r\n ']}; fi; done < spotify.com.txt > spotify.com_valid.txt

Y estos fueron los resultados:


Amass pudo encontrar 489 subdominios válidos, casi el doble que la del segundo lugar Sublist3r (280 subdominios válidos). Pero, por otro lado, Amass fue la herramienta más lenta ya que tardó alrededor de 20 minutos en terminar (0.4 subdominios por segundo).

La herramienta más rápida fue Findomain que pudo encontrar 270 subdominios y tardó solo 6 segundos (casi 46 subdominios por segundo).

Como veis la herramienta Sudomy no funcionó correctamente a Ricardo, no se exactamente por qué razón. Nosotros la hemos ejecutado sin problemas y los resultados fueron 727 subdominios, de los cuales 210 fueron válidos, todo ello en 2 minutos y 38 segundos.

Finalmente en el enlace https://drive.google.com/open?id=1vc-5INapxD909GGUROcb86I_vdufS1Ha se puede encontrar una hoja de cálculo con los resultados completos y el resultado de cada herramienta utilizada durante la evaluación.

FuenteSubdomain Enumeration Tools Evaluation

Xencrypt: un crypter en PowerShell

Xencrypt de Xentropy (@SamuelAnttila) y SecForce (@SECFORCE_LTD) es un crypter en PowerShell que utiliza cifrado AES y compresión Gzip/DEFLATE para generar con cada ejecución una cantidad casi infinita de variantes para bypassear antivirus. Lo hace comprimiendo y cifrando el script de entrada y almacenando los datos como un payload en un nuevo script que descifrará y descomprimirá antes de ejecutarlo. En esencia, es para PowerShell lo que es un crypter PE.
 

Características

- Evade AMSI y todos los AV modernos de VirusTotal (en el momento de escribir este post)
- Comprime y cifra los scripts de PowerShell
- Tiene un overhead mínimo y a menudo incluso negativo (gracias a la compresión)
- Aleatoriza nombres de variables para ofuscar aún más el código auxiliar de descifrado
- Aleatoriza el cifrado, la compresión e incluso el orden en que aparecen las declaraciones en el código para obtener la máxima entropía
- Súper fácil de modificar para crear una variante propia de cifrado
- Admite capas recursivas (crypter que cifra la salida cifrada...), probado hasta 500 capas.
- Admite Import-Module así como la ejecución normal siempre que el script de entrada también lo admita

Uso

Import-Module ./xencrypt.ps1
Invoke-Xencrypt -InFile invoke-mimikatz.ps1 -OutFile xenmimi.ps1


Ahora tendremos un archivo cifrado xenmimi.ps1 en el directorio de trabajo actual y podremos usarlo de la misma manera que lo haríamos con el script original, por lo que en este caso:

Import-Module ./xenmimi.ps1
Invoke-Mimikatz


También admite capas recursivas a través del parámetro -Iterations.

Invoke-Xencrypt -InFile invoke-mimikatz.ps1 -OutFile xenmimi.ps1 -Iterations 100
 
Esto lo comprimirá y cifrará 100 veces y es útil para bypassear AV dinámicos porque tienen un tiempo de espera para analizar el código. Ahí no hace falta usar sleeps que algunos escaneos dinámicos puede omitir para llegar al final: tienen que atravesar toda la cadena para llegar al payload malicioso, lo que generalmente nunca ocurre, ya que normalmente caducan después de un segundo o dos o escaneo.

Sin embargo, los archivos pueden crecer en tamaño y generar el archivo de salida puede llevar mucho tiempo dependiendo de los scripts y el número de iteraciones solicitadas.

Proyecto: https://github.com/the-xentropy/xencrypt

#hc0n2020 : Crónica de la tercera conferencia de @Hackplayers

Logo h-c0n 2020
La tercera edición de nuestra conferencia h-c0n tuvo lugar los pasados 31 de enero y 1 de febrero y, como en las veces anteriores, voy a dar un repaso bastante informal y prácticamente gráfico a mis reflexiones ahora que todavía lo tengo reciente (y aún mantengo las agujetas cab**nes).

Ya sabéis que el escenario este año fue la Nave Madrid, una antigua fábrica de ascensores reconvertida a un sitio chulo y muy JRANDEEE para eventos. Nos acordaremos eso sí de su equipo gestor que nos mantuvo en vilo con algunas "cosillas" y sobretodo con la reserva de las aulas hasta el último momento, resarcidos sin embargo finalmente por dejarnos llevar grifos de cerveza a la cafetería :P

A izda. miembro de staff al borde de un ataque por la incertidumbre. A dcha. cervecería cafetería.

En cuanto a contenidos ya sabéis que nos venimos arriba y tuvimos cuatro tracks simultáneos (dos de charlas y dos de talleres), un ctf presencial, expositores, arsenal y una zona para otras comunidades y congresos. Os puedo asegurar que organizarnos en el staff para cubrir todo eso fue un auténtico desafío.

Write-up CTF NFC h-c0n 2020

Para resolver este reto hará falta hardware especial capaz de leer la tecnología NFC de las tarjetas que llevan las acreditaciones de acceso al evento de la h-c0n 2020 de Hackplayers. Es posible utilizar diferentes tipos de hardware tales como un dispositivo usb ya sea con chipset ACR122U o como en este write-up que se ha utilizado un dispositivo Proxmark3.

1. Identificando el tipo de tarjeta NFC

Lo primero es identificar el tipo de tarjeta. Lanzando comandos como “lf search” o “hf search” enseguida vemos que se trata de una tarjeta de alta frecuencia (hf – high frequency) de tipo Mifare Classic 1k.


Vemos que tiene el UID AB 1D A2 24. Aunque para la resolución del reto no es relevante. Todas las acreditaciones tienen los mismos datos y el mismo UID.

2. Lectura por defecto de los sectores

Ahora lanzaremos un comando para ver si podemos leer todos los sectores. “hf mf chk *1 ?”


Como podemos observar en la columna res, todo lo que está con el valor “1” es que se ha podido leer porque tenía una clave muy estándar como es el caso de la key ffffffffffff o aabbccddeeff y lo que está con “0” no se ha podido leer porque tiene una clave que no es estándar. Por lo que hemos podido leer todo a excepción de los sectores 002, 012 y 013 de la sección A de la tarjeta.

Métodos para ocultar el historial de bash

Bash mantiene el listado de comandos que se están ejecutando en memoria y que se escriben en $HISTFILE (~/.bash_history) cuando un usuario cierra la sesión.
$ echo $HISTFILE
/home/usuario/.bash_history
Hoy recopilamos un cheatsheet de secbytes en el que recogen un buen número de métodos que un atacante puede utilizar para que sus comandos no queden almacenados, tanto en memoria como en disco.

Poniendo un espacio antes de cada comando

Es posible que no esté habilitado de forma predeterminada en algunas distribuciones pero, en la mayoría, si ponemos antes de cada comando un espacio el mismo no se almacenará en el historial:
$ echo "hello"
hello
$  echo "ritsec"
ritsec
$ history 
    1  ls
    2  echo "hello"
    3  history 

Observad que el comando $echo "hola" se guardó el historial a diferencia del $echo "ritsec". Eso es posible debido a la variable de entorno HISTCONTROL:
$ head -2 /etc/os-release
 NAME="Ubuntu" 
 VERSION="18.04.3 LTS (Bionic Beaver)" 
$ echo $HISTCONTROL
 ignoredups:ignorespace

[HTB-writeup] Player


Comencemos con un poco de escaneo:
nmap 10.10.10.145 -sC -sV -n -Pn -p- -oA nmap.tcp
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 6.6.1p1 Ubuntu 2ubuntu2.11 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   1024 d7:30:db:b9:a0:4c:79:94:78:38:b3:43:a2:50:55:81 (DSA)
|   2048 37:2b:e4:31:ee:a6:49:0d:9f:e7:e6:01:e6:3e:0a:66 (RSA)
|   256 0c:6c:05:ed:ad:f1:75:e8:02:e4:d2:27:3e:3a:19:8f (ECDSA)
|_  256 11:b8:db:f3:cc:29:08:4a:49:ce:bf:91:73:40:a2:80 (ED25519)
80/tcp   open  http    Apache httpd 2.4.7
|_http-server-header: Apache/2.4.7 (Ubuntu)
|_http-title: 403 Forbidden
6686/tcp open  ssh     OpenSSH 7.2 (protocol 2.0)
Service Info: Host: player.htb; OS: Linux; CPE: cpe:/o:linux:linux_kernel

(Se ha omitido UDP por no haber devuelto resultados interesantes).

Antes de continuar, añadiremos player.htb a /etc/hosts para facilitar la enumeración.

Tras un vistazo rápido al puerto 80:

Por lo que vamos a intentar encontrar hosts virtuales:
wfuzz -c -w /usr/share/wordlists/SecLists/Discovery/DNS/subdomains-top1million-20000.txt --hc 400,404,403 -H "Host: FUZZ.player.htb" -u http://player.htb -t 100
********************************************************
* Wfuzz 2.4 - The Web Fuzzer                           *
********************************************************

Target: http://player.htb/
Total requests: 19983

===================================================================
ID           Response   Lines    Word     Chars       Payload                                                                                                                                           
===================================================================

000000019:   200        86 L     229 W    5243 Ch     "dev"                                                                                                                                             
000000067:   200        63 L     180 W    1470 Ch     "staging"                                                                                                                                         
000000070:   200        259 L    714 W    9513 Ch     "chat" 

Tras añadir los resultados a /etc/hosts podemos hacer un poco de fuzzing en la URL principal y en los vhost dev, staging y chat:
gobuster dir -r -x php -t 100 -u http://player.htb -w /usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-medium.txt
gobuster dir -r -x php -t 100 -u http://dev.player.htb -w /usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-medium.txt
gobuster dir -r -x php -t 100 -u http://staging.player.htb -w /usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-medium.txt
gobuster dir -r -x php -t 100 -u http://chat.player.htb -w /usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-medium.txt

Como ya sabemos, la enumeración es importantísima para una futura explotación, por lo que vamos a ir anotando todo lo que nos vaya llamando la atención.

RCE no autenticado en Citrix Netscaler y Gateway (CVE-2019-19781)

El 17 de Diciembre de 2019, Citrix anunció que NetScaler ADC (Application Delivery Controller) y Citrix Gateway tenían una vulnerabilidad que puede permitir a un atacante no autenticado ejecutar código en gateways vulnerables.

Esto condujo a una ola de titulares alarmantes sobre "80.000 empresas" expuestas debido a esta fallo. Lo más interesante es que Citrix no publicó un parche sino un workaround que, básicamente, añade una política para denegar estas peticiones:
enable ns feature responder
add responder action respondwith403 respondwith "\"HTTP/1.1 403 Forbidden\r\n\r\n\""
add responder policy ctx267027 "HTTP.REQ.URL.DECODE_USING_TEXT_MODE.CONTAINS(\"/vpns/\") && (!CLIENT.SSLVPN.IS_SSLVPN || HTTP.REQ.URL.DECODE_USING_TEXT_MODE.CONTAINS(\"/../\"))" respondwith403
bind responder global ctx267027 1 END -type REQ_OVERRIDE
save config

Como podéis comprobar, una regla para bloquear intentos de explotar path traversal... ¿Y cómo se consigue ejecución remota de código a través de este path traversal?

El 10 de enero, Rio Sherri, consultor de seguridad de MDSec, publicó un post destacando el código en la función 'csd' del módulo perl UserPrefs que "construye una ruta desde el encabezado HTTP NSC_USER sin ningún tipo de sanitización" y se activará con cualquier script que llame a la función:
sub csd {
        my $self = shift;
        my $skip_read = shift || "";
  # Santity Check
    my $cgi = new CGI;
print "Content-type: text/html\n\n";

// Username variable initialized by the NSC_USER HTTP Header
    my $username = Encode::decode('utf8', $ENV{'HTTP_NSC_USER'}) || errorpage("Missing NSC_USER header.”); <- br="" mark="" this="">
    $self->{username} = $username;
...
    $self->{session} = %session;

// Constructing the path from the username.
        $self->{filename} = NetScaler::Portal::Config::c->{bookmark_dir} . Encode::encode('utf8', $username) . '.xml’;
        if($skip_read eq 1) {
                return;
        }

BusKill: un cable USB contra los "tirones" de portátil

Imagina que estás en una cafetería con tu portátil, en la página de tu banco o en otro servicio importante, y de repente alguien coge tu portátil y sale corriendo... ¿qué pasaría si ese alguien se aprovechara de que estabas autenticado para realizar cualquier acción rápidamente?

Quizás no te diera tiempo a llamar al banco para que congelaran tus cuentas, o avisar a tu empresa para forzar un logout, etc.

Pues leyendo encontré una solución bastante original para bloquear, apagar o "autodestruir" el ordenador cuando está físicamente separado de uno mismo: BusKill.

Se trata de un cable USB conectado al equipo y alguna parte del cuerpo (la muñeca por ejemplo, que os veo venir) y que al tirar y desconectarse realice esa acción inmediata que nos salve el culo. Esto se puede mejorar aún más utilizando un conector magnético. Por ejemplo, los siguientes elementos son suficientes para construir este cable USB de "interrupción":

Lo más visto del 2019 en Hackplayers

En esta época de arraigada tradición no quería dejar escapar las últimas horas de este año 2019 sin publicar el top 50 de entradas más vistas en el blog, excusa como siempre para hacer un brevísimo balance y desearos a todos un feliz y próspero 2020.

Creo que este año ha sido un buen año para la Comunidad, empezando por el reconocimiento en MundoHacker como impulsores de talento, el vuestro, el de todos los que estáis leyendo y que de alguna manera habéis participado contribuyendo y debatiendo todo lo relacionado con la temática que nos apasiona: el hacking y la in-seguridad informática. A todos vosotros un guiño de complicidad y muchas gracias por estar siempre ahí.

Pero no puedo despedirme de este año sin hacer también mención especial como siempre a la familia (a mis niñas) y a los que habéis estado más cerca, a los compis del curro con los que he trabajado codo con codo y viajado a otras conferencias y jugado en algún CTF que otro. También a los de los grupos de Telegram, sobretodo a los de mi equipo de gigantes de L1k0rd3b3ll0t4 y a los organizadores y resto de staff de h-c0n que en esta nueva edición la estamos preparando buena... Así que a los que estéis el 31 de enero y 1 de febrero en Madrid espero veros allí y, a los que no podáis, pues seguir escribiéndonos y viéndonos virtual o físicamente, compartiendo experiencias, anécdotas y más de una cerveza, que es de lo que se trata... ;)

¡Gracias y a por el 2020!

1 El abc para desproteger un Excel con contraseña
2 Listado de códigos secretos de Android
3 Grupos de Telegram sobre hacking y seguridad informática en español
4 8 servicios proxy gratuitos para evitar restricciones y mantener el anonimato y la privacidad : hackplayers
5 Ya llega BlueKeep... aka ejecución remota de código en RDP
6 Taller para escalar privilegios en Windows/Linux
7 hackplayers: Blogroll en español
8 iDict, una herramienta de fuerza bruta para obtener contraseñas de usuarios de iCloud
9 100 grupos de hackers famosos
10 Cómo clonar la tarjeta SD de la Raspberry Pi

Aprovechando el Directorio Activo como C2 (Command & Control)

En un directorio activo, por defecto, todos los usuarios autenticados tienen acceso de escritura a algunos de sus propios atributos y acceso de lectura a los atributos de otros usuarios. Por increíble que parezca, se puede abusar de los atributos de usuario con acceso de lectura/escritura para almacenar payloads y convertir así al directorio activo en un auténtico C2.

La idea no es nueva, de hecho ya la expuso harmj0y en su blog en 2016, que además creó un script en powershell para usar la propiedad 'msmqsigncertificates' para escribir el payload en el atributo del usuario. La ventaja de usar 'msmqsigncertificates' es que tiene un tamaño máximo de 1 MB y también tiene el PAS (Partial Attribute Set), es decir, los payloads almacenados en 'msmqsigncertificates' se propagarán a todas las copias del catálogo global en el bosque.

Entonces básicamente el procedimiento será el siguiente: un usuario cambia su propiedad mientras que otro usuario consulta continuamente la información que se puede leer por todos y luego informa los resultados a sus propios "certificados de msmqsignce". Es decir, tenemos un canal de datos bidireccional de 1 MB.


En el escenario propuesto por akijos, Aki (el atacante) creará un payload utilizando el cmdlet 'New-ADPayload'. El payload se comprimirá utilizando la compresión .NET [IO.Compression.DeflateStream] y luego los datos en Base64 se almacenarán en el atributo 'msmqsigncertificates'. Esto también creará como resultado un script en Powershell que debe ejecutarse en la máquina Victim (Tom Hanks).