Cómo dumpear las claves SSH desde el firmware de un router

Algunos me preguntan como sacar las claves ssh de los routers. los veo venir... pero bueno, veremos rápidamente como hacerlo extrayendo la imagen del firmware de un router ;)

En esta ocasión sin embargo vamos a dejar al *pobre* Comtrend VG-8050 y vamos a ir a por el D-Link Dsl-2750u (la belleza de la derecha). En concreto vamos a echar un vistazo a una de las versiones de firmware que también viene con un demonio Dropbear 0.46 con "premio": la ME_1.11 de octubre de 2013:

http://www.dlinkmea.com/partner/media/product_item_downloadables/1351-DSL2750U-U1_FW1.11.rar

Después de descargar los menos de 7mb que ocupa el rar, lo descomprimimos y analizamos la imagen con Binwalk, el estándar de facto para el análisis de firmwares:

root@kali:~/firmwares# file GAN9.9T113A-B-DL-DSL2750U-R5B0024-Dubai.EN_2T2R_text_for_lan_update.img 
GAN9.9T113A-B-DL-DSL2750U-R5B0024-Dubai.EN_2T2R_text_for_lan_update.img: data

root@kali:~/firmwares# binwalk GAN9.9T113A-B-DL-DSL2750U-R5B0024-Dubai.EN_2T2R_text_for_lan_update.img 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 5402908 bytes
1722624       0x1A4900        Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 5080877 bytes,  1142 inodes, blocksize: 262144 bytes, created: Thu Oct 24 07:46:30 2013

Como veis el filesystem es SquashFS, uno de los más ampliamente utilizados en sistemas con Linux embebido, y está comprimido con LZMA en lugar del estandar zlib (algo que también suelen hacer):

root@kali:~# binwalk --dd='squashfs:squashfs' GAN9.9T113A-B-DL-DSL2750U-R5B0024-Dubai.EN_2T2R_text_for_lan_update.img

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 5402908 bytes
1722624       0x1A4900        Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 5080877 bytes,  1142 inodes, blocksize: 262144 bytes, created: Thu Oct 24 07:46:30 2013

root@kali:~/_GAN9.9T113A-B-DL-DSL2750U-R5B0024-Dubai.EN_2T2R_text_for_lan_update.img.extracted# file 1A4900.squashfs 
1A4900.squashfs: Squashfs filesystem, little endian, version 4.0, 5080877 bytes, 1142 inodes, blocksize: 262144 bytes, created: Thu Oct 24 07:46:30 2013

El siguiente paso es extraer la imagen y, para ello, vamos a instalar y utilizar la utilidad unsquashfs-2.1 de Jeremy Collake:

apt-get install liblzo2-dev 
git clone https://github.com/devttyS0/sasquatch
make

root@kali:~/_GAN9.9T113A-B-DL-DSL2750U-R5B0024-Dubai.EN_2T2R_text_for_lan_update.img.extracted# ./sasquatch/sasquatch 1A4900.squashfs 
SquashFS version [4.0] / inode count [1142] suggests a SquashFS image of the same endianess
Parallel unsquashfs: Using 1 processor
Trying to decompress using default lzma decompressor...
Successfully decompressed with default lzma decompressor
1083 inodes (1113 blocks) to write

[=============================================================\] 1113/1113 100%

created 679 files
created 59 directories
created 123 symlinks
created 281 devices
created 0 fifos

Ahora veremos el filesystem colgando del directorio squashfs-root, por lo que sólo tenemos que ir a pescar nuestras claves...

root@kali:~/firmwares/_GAN9.9T113A-B-DL-DSL2750U-R5B0024-Dubai.EN_2T2R_text_for_lan_update.img.extracted# cd squashfs-root/etc/dropbear/
root@kali:~/firmwares/_GAN9.9T113A-B-DL-DSL2750U-R5B0024-Dubai.EN_2T2R_text_for_lan_update.img.extracted/squashfs-root/etc/dropbear# ls -las
total 16
4 drwxr-xr-x  2 594 594 4096 Oct 24  2013 .
4 drwxr-xr-x 10 594 594 4096 Oct 24  2013 ..
4 -rwxr-xr-x  1 594 594  459 Oct 24  2013 dropbear_dss_host_key
4 -rwxr-xr-x  1 594 594  427 Oct 24  2013 dropbear_rsa_host_key

... y con la herramienta dropbearkey mostrar la clave pública:

root@kali:~/firmwares/_GAN9.9T113A-B-DL-DSL2750U-R5B0024-Dubai.EN_2T2R_text_for_lan_update.img.extracted/squashfs-root/etc/dropbear# dropbearkey -y -f dropbear_rsa_host_key
Public key portion is:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgwCAmPVBs6DX2/2G6NcLwFI6jP055kbQzxGNNaYngPhR3TT9MMiGnR2waCQYrZq0n7D+RKu9tEiYU05tPiaMqm5z4qHq2OePKIL4jFhcTJk8p0yz1IpPp9FJjvZ6Daw4Mvr+r+RNNnSTn7Iq7bIxWyNgXnQc7Lx7IPmm8JDqskFEtOC7 root@kali
Fingerprint: md5 63:05:01:4f:cd:09:6d:ad:ed:95:ae:89:19:2c:b8:bc

Finalmente sólo nos queda buscar el fingerprint correspondiente:

Link shodan

 
y tenemos otros 40.000 equipos cuyas comunicaciones podremos descifrar :)


Fuente

JASBUG! es el momento de actualizar todos los equipos de una red con Directorio Activo

En el pasado, la seguridad de la red se diseñó en torno a "mantener el interior seguro desde el exterior", en lugar de la idea más general "proteger cada computadora de todos los demás". En estos días la defensa de la red como un perímetro definido rígidamente no es lo suficientemente buena, ya que muchos atacantes vienen de dentro. JASBUG, bautizado así porque fue descubierto (y reportado hace meses) por la firma de seguridad JAS Global Advisors, es más que un bug un fallo de diseño remanente desde desde Windows Server 2003 que puede permitir la ejecución remota de código (RCE) suplantando los archivos que el servidor envía a un cliente: software de confianza por malware.  

Este martes Microsoft ha publicado correcciones del core de su sistema para solventar estas vulnerabilidades críticas (CVE-2015-0008), concretamente dos que implican directivas de grupo y objetos de directiva de grupo (GPO):

MS15-014 - Una vulnerabilidad en SMB
  
Al iniciar sesión en una red con Directorio Activo, el servidor le enviará las actualizaciones según su directiva de grupo, por lo que el administrador de sistemas tiene la oportunidad de establecer una configuración estandarizada y segura en cada PC de su red. Sin embargo cuando la actualización falla, existe un fallo en SMB mediante el cual es posible desactivar los requisitos de firmado SMB, por lo que el cliente no comprobará que ya no está recibiendo los ficheros del servidor y un atacante podrá modificar la tabla ARP del switch para que acceda a su equipo y obtenga un fichero malicioso, todo esto sin que la víctima se percate.

La corrección es sencilla, cuando falle la actualización de directiva se cerrará la misma sin dejártela abierta sin firmado SMB.

MS15-011 - Una vulnerabilidad en la directiva de grupo

MS15-011 es similar, pero mucho más difícil de arreglar. Un atacante podría también hacer la misma suplantación pero mediante una especie de Catch-22: para averiguar si la firma SMB está activada, un cliente tiene que revisar una directiva de grupo del servidor de Active Directory y, mientras lo comprueba, el firmado SMB es irrelevante. El servidor valida el cliente a través del proceso de inicio de sesión, pero el cliente no valida el servidor (esto, en pocas palabras, es el fallo de diseño).

Para corregirlo Microsoft ha tenido que 1/ añadir una función para implementar el firmando SMB durante el proceso de directiva de grupo, para que su cliente pueda validar el servidor antes de confiar en sus datos de directiva de grupo y 2/ habilitar esta nueva característica en cada cliente.

Aunque ambas vulnerabilidades podrían explotarse a través de Internet, su escenario típico es mediante un ataque MITM en una red interna (LAN) con un Directorio Activo corporativo, por lo que los administradores de Microsoft deberían darse prisa en aplicar los parches publicados por Microsoft ayer...

pd. y no sólo los administradores... los usuarios domésticos también deben aplicar las actualizaciones ya que en este boletín de febrero se solventan otras vulnerabilidades a tener en cuenta: Internet Explorer, Windows Driver, Ms Office...

Fuentes:
- JASBUG Fact Sheet
- MS15-011 & MS15-014: Hardening Group Policy
- The "JASBUG" Windows vulnerability - beyond the hype, what you need to know
- 15-Year-Old JasBug Vulnerability Affects All Versions of Microsoft Windows

Simular un falso ataque de LFI para que “salte” el WAF

Antes de realizar un ataque a una servidor, conviene tener información sobre qué medidas de seguridad tiene. Saber si el sistema tiene algún firewall delante protegiendo con redes el tráfico entrante, un reverse proxy para ocultar la ubicación real o una solución antimalware concreta que esté vigilando los ficheros que se suben, puede venir bien antes de preparar una intrusión. En el mundo del pentesting de aplicaciones web, cuando se realiza un escaneo, conviene saber si delante de la web hay algún WAF (Web Application Firewall) que pueda bloquear los intentos de explotación de vulnerabilidades. Localizar si existe, y cuál es, algún WAF es una buena idea, además de que puede ayudar a generar mucha más información del escenario completo con el que te encuentras.

Figura 1: Simular un ataque LFI para que "cante" el WAF

Existen muchas formas de saber si hay un WAF en un sitio web, pero hay una que es bastante sencilla y que funciona relativamente bien. Normalmente, cuando un WAF bloquea una petición, éste genera un menaje de respuesta HTTP 403 Forbidden, con una página de respuesta por  defecto que debería ser configurada para dar poca información a un posible atacante. Con el objeto de conseguir forzar ese error HTTP 403 del WAF, lo suyo es simular un ataque, y una forma muy sencilla de hacerlo es conseguir que el WAF crea que se está produciendo un ataque de LFI (Local File Inclusión) para acceder a ficheros sensibles.

Figura 2: Mensaje de error del WAF de un blog tecnológico

Estas técnicas se utilizan mucho en auditorías de seguridad e intrusiones de atacantes, y suelen tener la característica de querer escalar en el árbol de directorios del servidor web con la cadena ../../, algo que las reglas por defecto de la mayoría de los WAF - incluyendo el popular mod_security que se utiliza parafortificar servidores web GNU/Linux -, detectan por defecto y bloquean. Basta con añadir a una URL algo como ?file=../../ para hacer creer al WAF que se está produciendo el ataque, y ver qué mensaje obtenemos.

Figura 3: Mensaje 403 de un dominio de Apple.com

Como en los muchos casos vistos con los mensajes de error de los servidores web, estos mensajes pueden ser igual de útiles, no solo para saber que hay un WAF, sino para conocer exactamente el tipo de WAF y hacerse una idea del tipo de posibilidades que ofrece.

Figura 4: Mensaje de Error 403 de una empresa que indica la detección del LFI

Además, si la página ha sido personalizada, tal vez se pueda acceder a alguna información útil que haya podido quedarse allí por una mala configuración.

Figura 5: Mensaje de Error 403 en la web de DefCon generado por McAfee Global Threat Intelligence

Si tienes un WAF, comprueba los mensajes de bloqueo que estás mostrando en losHTTP 403. Si puedes evita dar demasiada información a los atacantes. Puedes configurar el WAF para devolver un HTTP 200 genérico con un bonito mensaje de error, y habrá mucha menos información que un atacante pueda llevarse a la boca.

Fuente

GHOST (CVE-2015-0235), el fantasma que se cierne sobre Linux

Qualys ha publicado una vulnerabilidad grave de desbordamiento de buffer en la función__nss_hostname_digits_dots()usada por otras funciones tan comunes como gethostbyname() y gethostbyname2() de glibc, que un atacante podría provocar al intentar resolver un nombre de host inválido (/etc/hosts o DNS). 

Concretamente la función __nss_hostname_digits_dots() no calcula correctamente el tamaño del buffer que tiene que reservar y, bajo ciertas circunstancias, se pueden sobrescribir datos arbitrariamente mediante este desbordamiento. Aunque en principio sólo se pueden sobrescribir 4 bytes de memoria, se ha demostrado que son suficientes para evadir mitigaciones como ASLR y PIE y conseguir la ejecución remota de código.
En la práctica, esto se podría explotar solicitando resolver un nombre de host lo suficientemente largo (al menos 1KB) que cumpla los requisitos normales de nomenclatura (a.b.c.d).
  
Esta vulnerabilidad bautizada como GHOST (por su paralelismo con el nombre de la función afectada) y con código CVE-2015-0235, puede hacer que el atacante tome el control de un servidor Linux con el usuario de la aplicación que está ejecutando la resolución de nombre: Apache, Exim, Sendmail, Nginx, MySQL, TAZAS, Samba, ... ¡la lista es enorme!

Las versiones afectadas son:

- glibc 2.2 a 2.17 (incluidas) son vulnerables
- glibc 2.18 a 2.20 (incluidas) NO son vulnerables
- las versiones anteriores de glibc (<= 2.1.3) NO son vulnerables

Mediante el siguiente script en C hecho por la Universidad de Chicago podemos comprobar si somos vulnerables:

GHOSTTEMP=$(mktemp /tmp/ghost.XXXXXXXXXXXXXX)
GHOSTEXEC=$(mktemp /tmp/ghost.XXXXXXXXXXXXXX)
cat <<"EOF" > $GHOSTTEMP
#include <netdb.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

#define CANARY "in_the_coal_mine"

struct {
  char buffer[1024];
  char canary[sizeof(CANARY)];
} temp = { "buffer", CANARY };

int main(void) {
  struct hostent resbuf;
  struct hostent *result;
  int herrno;
  int retval;

  /*** strlen (name) = size_needed - sizeof (*host_addr) - sizeof (*h_addr_ptrs) - 1; ***/
  size_t len = sizeof(temp.buffer) - 16*sizeof(unsigned char) - 2*sizeof(char *) - 1;
  char name[sizeof(temp.buffer)];
  memset(name, '0', len);
  name[len] = '\0';

  retval = gethostbyname_r(name, &resbuf, temp.buffer, sizeof(temp.buffer), &result, &herrno);

  if (strcmp(temp.canary, CANARY) != 0) {
    puts("vulnerable");
    exit(EXIT_SUCCESS);
  }
  if (retval == ERANGE) {
    puts("not vulnerable");
    exit(EXIT_SUCCESS);
  }
  puts("should not happen");
  exit(EXIT_FAILURE);
}
EOF
gcc -x c $GHOSTTEMP -o $GHOSTEXEC
$GHOSTEXEC
rm -f $GHOSTTEMP $GHOSTEXECPaste your text here.

En caso que seamos vulnerables tendremos:

(...)
# gcc -x c $GHOSTTEMP -o $GHOSTEXEC
# $GHOSTEXEC
vulnerable
# rm -f $GHOSTTEMP $GHOSTEXEC 

Las siguientes distribuciones de Linux tiene versiones vulnerables de glibc:

Ubuntu
10.04 LTS     fix available     fixed in libc6 2.11.1-0ubuntu7.20
12.04 LTS     fix available     fixed in libc6 2.15-0ubuntu10.10
14 and newer     not vulnerable

Debian
6.x - squeeze     vulnerable
6.x - squeeze (LTS)     vulnerable
7.x - wheezy     vulnerable
7.x - wheezy (security)     fix available     fixed in glib 2.13-38+deb7u7
8.0 - jesse     not vulnerable
dev - sid     not vulnerable

Red Hat Enterprise
fix information
Desktop (v. 6)     fix available     fixed in glibc-2.12-1.149.el6_6.5
Desktop (v. 7)     fix available     fixed in glibc-2.17-55.el7_0.5
HPC Node (v. 6)     fix available     fixed in glibc-2.12-1.149.el6_6.5
HPC Node (v. 7)     fix available     fixed in glibc-2.17-55.el7_0.5
Server (v. 6)     fix available     fixed in glibc-2.12-1.149.el6_6.5
Server (v. 7)     fix available     fixed in glibc-2.17-55.el7_0.5
Server EUS (v. 6.6.z)     fix available     fixed in glibc-2.12-1.149.el6_6.5
Workstation (v. 6)     fix available     fixed in glibc-2.12-1.149.el6_6.5
Workstation (v. 7)     fix available     fixed in glibc-2.17-55.el7_0.5

Mint
13 “Maya”     fix available     Tracks Ubuntu 12.04, should get update from Ubuntu servers
17 “Qiana”     not vulnerable
17.1 “Rebecca”     not vulnerable

Gentoo
libc information
stable     not vulnerable      uses glibc 2.19-r1

Arch
fixed in all releases since August 2013, discussion here and package info here
anything recent     not vulnerable

Fedora
discussion
19 and earlier     vulnerable     uses glibc 2.17 and earlier
20     not vulnerable     uses glibc 2.18
21     not vulnerable     uses glibc 2.20

Mandriva Linux
all     vulnerable     appears to use glibc 2.16

openSUSE
vulnerability information
Enterprise 11 & older     vulnerable
Enterprise 12     not vulnerable
openSUSE 13.1 & newer      not vulnerable

Slackware
current     not vulnerable     uses glibc 2.20
14.1 and earlier     vulnerable     uses glibc 2.17 and earlier

Knoppix
information about glibc versions
7.2 and earlier     vulnerable     uses glibc 2.17 and earlier
7.4 and later     not vulnerable     uses glibc 2.19 and later

Slax
all     vulnerable     appears to use glibc 2.15

Lo llamativo de esta vulnerabilidad, sobre la que se informó públicamente ayer, es que estaba en glibc desde el año 2000 y no fue resuelta hasta 2013; sin embargo, la corrección no se marcó como de seguridad, por lo que distribuciones de largo recorrido como las LTS de Ubuntu, Debian o RHEL, no aplicaron el parche.

Sea como fuere, si tu distribución tiene ya parches disponibles aplicalos cuanto antes:

- Actualiza a glibc 2.18 o más reciente
- Reinicia todos los procesos que cargan la biblioteca glibc
- Corrige los nuevos binarios de software que estén enlazados estáticamente contra versiones vulnerables de la biblioteca glibc. 

Fuentes: 
- The GHOST Vulnerability
- Critical “GHOST” Vulnerability Released
- GHOST, el fantasma que acechaba en glibc
- Comprobar si somos vulnerables a Ghost CVE-2015-0235 
- Ghost, un agujero de seguridad en Linux más peligroso para Internet que Heartbleed 
- Vulnerability Overview: Ghost (CVE-2015-0235)
- Severe “Ghost” flaw leaves Linux systems vulnerable to takeover 
- Scary 'Ghost' vulnerability leaves Linux systems vulnerable to possession
- GHOST: glibc: buffer overflow en gethostbyname CVE-2015-0235