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