Satellite: sirviendo payloads "like a sir"

Satellite es un servidor que aloja payloads y que filtra las peticiones para garantizar que cada objetivo obtenga el más adecuado. Se trata de una alternativa a Apache y Nginx para alojar payloads, así como una alternativa a Caddy para la redirección de tráfico C2.

Está escrito en Go e implementa un proxy HTTP y un servidor JA3 basado en CapacitorSet, es capaz de filtrar el tráfico en función de la cantidad de veces que se ha servido un payload, tiene en cuenta los agentes de usuario, las firmas JA3, paths de prerequisitos y más.

Características destacadas

- Entrega de payloads basada en firmas JA3
- Tiempo de vida de payloads configurable
- Redirección de tráfico C2 (proxy)
- Posibilidad de "scriptear" las peticiones
- Facilidad en la captura de credenciales
- Filtrado global de peticiones

Instalación

Para probarlo en mi caso lo instalaré en Ubuntu aunque podeis encontrar instrucciones de instalación para otras plataformas en la Wiki del proyecto.  https://github.com/t94j0/satellite/wiki/Installation

Simplemente descargamos el paquete correspondiente y lo instalamos:

$ wget https://github.com/t94j0/satellite/releases/download/v0.0.1/satellite_0.0.1_linux_amd64.deb
$ sudo dpkg -i satellite_0.0.1_linux_amd64.deb

Configuración del servidor

Las rutas que Satellite buscará para cargar la configuración son las siguientes:

    $HOME/.config/satellite/config.yml
    $HOME/.satellite/config.yml
    /etc/satellite/config.yml

El "brazalete del silencio" contra Siri, Alexa y demás micrófonos "inteligentes"

Por diseño, los teléfonos y altavoces inteligentes tienen micrófonos que siempre están encendidos y escuchan las llamadas palabras de activación como "Alexa", "Hey, Siri" u "OK, Google". Solo después de escuchar esa señal se supone que deben comenzar a grabar. Pero sólo "se supone"... y no nos referimos sólo a que se pueda espiar de forma intencionada: varios estudios ya han demostrado que los dispositivos se activan docenas de veces diariamente y comienzan a grabar después de escuchar frases similares a sus palabras de activación, sobretodo a través de la TV, la radio u otras conversaciones.

Heather Zheng y Ben Zhao, profesores de informática en la Universidad de Chicago, junto con el profesor asistente Pedro Lopes han diseñado un "brazalete de silencio" o jammer que bloquea Amazon Echo o cualquier otro micrófono cercano que pueda escuchar las conversaciones del usuario.

El brazalete tiene 24 altavoces que emiten señales ultrasónicas cuando el usuario lo enciende. El sonido es imperceptible para la mayoría de los oídos, con la posible excepción de los más jóvenes y los perros, pero los micrófonos cercanos detectarán el sonido de alta frecuencia en lugar de otros ruidos.

"Es muy fácil grabar en estos días", dijo Lopes. “Esta es una defensa útil. Cuando tenga algo privado que decir, puede activarlo en tiempo real. Cuando reproduzcan la grabación, el sonido desaparecerá".

Durante la PoC, podemos observar como al encender el brazalete se genera un ruido blanco estático que enmascara las conversaciones:

Url del video: https://youtu.be/-43-4LfqiTA

Por el momento, el brazalete es solo un prototipo. Los investigadores dicen que podrían fabricarlo por tan solo $20 y un puñado de inversores ya han preguntado sobre su comercialización.

Habrá que estar pendientes.. ;)

Fuente: https://www.nytimes.com/2020/02/14/technology/alexa-jamming-bracelet-privacy-armor.html

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:

•     Amass (https://github.com/OWASP/Amass)
•     DNSRecon (https://github.com/darkoperator/dnsrecon)
•     dnssearch (https://github.com/evilsocket/dnssearch)
•     Findomain (https://github.com/Edu4rdSHL/findomain)
•     Knock (https://github.com/guelfoweb/knock)
•     SubBrute (https://github.com/TheRook/subbrute)
•     Subfinder (https://github.com/projectdiscovery/subfinder)
•     Sublist3r (https://github.com/aboul3la/Sublist3r)
•     Sudomy (https://github.com/Screetsec/Sudomy)

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.

Fuente:  Subdomain 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":

• Una pendrive USB barato de $4 con un agujero para llavero
• Un llavero de mosquetón pequeño y fuerte para conectar la unidad anterior a la presilla del cinturón (el de este link de $6 es pequeño, está bien hecho y tiene un mecanismo de bloqueo inteligente)
• Un adaptador de ruptura magnética USB de $7 para conectar al puerto USB-A de la computadora
• Y finalmente, un cable de extensión USB de 1 metro de $3 para conectarlos