Antes de nada mira los comentarios, el shadow no se usa para autentificarse asi que por ese vector parece que no hay más que rascar

Hola anonymous y anonymaus,

En la época estival 48bits retorna.

[Música épica] Cuando nadie lo esperaba, cuando todos nos daban por muertos, detenidos o ambas cosas. En esos momentos, vamos y publicamos.

Vamos a ver cómo buscar vulnerabilidades en embebidos, sin necesidad de disponer del dispositivo. En este caso vamos a dar un poco de caña al sistema out-of-band management de DELL. Al lío..

A la hora de enfrentarse a un software/hardware, lo primero de todo es buscar toda la documentación posible sobre el sistema. A partir de la wikipedia podemos acceder a las más importantes, sencillas búsquedas por google arrojan un monton de resultados adicionales:

http://www.dell.com/content/topics/global.aspx/power/en/ps2q02_bell?c=us&l=en
http://en.wikipedia.org/wiki/Dell_DRAC

Hay que tener en cuenta la siguiente cuestión, si bien el código fuente de ciertos componentes del firmware de DELL DRAC están disponibles, DELL admite que no provee ni el entorno para crear un firmware funcional, ni el código de la versión final. Por lo tanto no tenemos acceso al código fuente de las partes más interesantes.

Llegado este punto es indispensable pasar a analizar el firmware y ver hasta donde podemos llegar. Podemos descargar la última versión desde la página de soporte de Dell
http://support.us.dell.com/support/downloads/format.aspx?releaseid=R299265&c=us&l=en&cs=&s=gen

Un zip autoejecutable que nos descomprime dos ficheros, uno de ellos es el firmware «firmimg.d6«, que ocupa 54 megas.

Lo común es utilizar binwalk para ver que contiene. No podemos confiar ciegamente en este programa, basado en firmas, porque en ocasiones da falsos positivos y/o resultados con poco sentido. En cualquier caso es un buen punto de partida.

DECIMAL   |	HEX     |  	DESCRIPTION
--------------------------------------------------------------

512       	0x200     	uImage header, created: Sat Mar 12 21:17:47 2011, image size: 4479904 bytes, Data Address: 0x8000, Entry Point: 0x8000, CRC: 0x1BB8BE08, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: none, image name: arm-linux
12424     	0x3088    	romfs filesystem, version 1 1892957376 bytes, named \240\324<\300hsqs\324\324<\300\177\023.
12436     	0x3094    	Linux Compressed ROM filesystem data, little endian size 3225212064 CRC 0xc03cd538, edition 3225212264, 3225738208 blocks,            3225738220 files
12444     	0x309C    	Squashfs filesystem, little endian, version 54632.49212, 4991 bytes, -1069755180 inodes, blocksize: 56288 bytes, created: Fri Aug 11 04:51:44 2006
103296    	0x19380   	gzip compressed data, from Unix, last modified: Sat Mar 12 21:10:25 2011, max compression

Esto es algunos de los resultados que muestra, de los cuales el único válido es el primero, en el offset 0x200. Primero nos encontramos con una cabecera propia del firmware. Es bastante común encontrarse con una imagen del bootloaderu-Boot (tanto en standalone como imagen de kernel, sobre todo esta última). No nos interesa especialmente en este caso, aunque podríamos debuggearlo a través de qemu-arm-system compilado con soporte para gdb. También podríamos seguir paso a paso la ejecución desde IDA que soporta este modo de debugging.

Con una fichero de firmware de 54 Megas, además de un kernel debemos tener mucha más chicha asi que vamos a buscarlo. Un análisis de entropía del fichero, por ejemplo usando uno de los últimos commits de radare (thx pancake!) «rahash2 -b 512 -a entropy firmimg.d6» o de forma visual veremos como en torno al offset 0x45b000 empezamos a observar zonas de muy alta entropía lo que suele significar datos comprimidos o cifrados..Buscando en la zona anterior nos encontramos con

Si os fijais podemos identificar el magic de un CramFS «45 3D CD 28» seguido por «Compressed ROMFS» y nombres relativos a directorios,ficheros… por lo tanto blanco y en botella: previo a la zona de alta entropia tenemos un cabecera de un CramFS legítimo. Por lo tanto, lo que tenemos que hacer es dumpear desde el magic hasta el final y montarlo.

dd if=firmimg.d6 bs=1 skip=4480512 of=tirori.fs
mount -o loop -t cramfs tirori.fs /mnt/drac

Y listo, de esta manera tenemos montado el sistema de ficheros que usa el dispositivo, por lo tanto tenemos acceso a todos los ficheros de configuración, certificados, shadow, demonios… aquí podéis ver el listado http://pastebin.com/Wn10iFf3

Pero podemos ir más allá y emular los ejecutables para poder así buscar vulnerabilidades en los servicios. QEMU soporta dos modos, emulación completa o sólo de user-mode. En este caso lo que nos interesa es emular en la capa de usuario por lo que seguiremos los siguientes pasos.

1. Instalarnos una suite de cross-compiling/debugging ARM como por ejemplo (http://www.codesourcery.com/sgpp/lite/arm/portal/subscription?@template=lite)
2. Cross-Compile QEMU user-mode en éstatico con el target arm
$ ./configure –enable-user –static –target-list=arm-linux-user –enable-debug
3. Activar el soporte en el kernel para otros formatos ejecutables
$ apt-get install binfmt-support
Descargar y ejecutar http://compbio.cs.toronto.edu/repos/snowflock/xen-3.0.3/tools/ioemu/qemu-binfmt-conf.sh
4. Crear /usr/gnemul/qemu-arm y copiar las librerias de /mnt/drac/lib a este directorio.
5. Copiar el qemu-arm estático a /mnt/drac/usr/local/bin
6. Chrootear en /mnt/drac y listo
7. Mapear /proc y /dev en el chroot para poder usar comandos como «ps» y sobre todo permitir a los binarios arm usar /dev/(u)random en el entorno chrooted.
mount -bind /dev /mnt/drac/dev
mount -t proc proc /mnt/drac/proc

De esta manera estamos podemos ejecutar, mediante la emulación que QEMU hace de la capa de usuario, los ficheros del firmware. Esto supone también la posibilidad de debuggearlos mediante gdb en remoto, ya que ptrace no está implementado en la capa de emulación.

(Entorno Chrooted)$ qemu-arm -g 1337 binario
Desde el entorno no chrooted usamos el cross-compiled gdb para arm de la siguiente manera
(gdb) target remote localhost:1337

Por ejemplo, vamos a depurar el servidor web que usan (appweb)

(chrooted) # qemu-arm -g 1337 /usr/local/bin/appweb -r /usr/local/lib/appweb -d /usr/local/www -a 0.0.0.0:8150

(fuera) $ arm-none-eabi-gdb
(gdb) target remote localhost:1337

Tras algo de «stress» los SIGSEGV comienza a aparecer…

Por último, vamos a hacer de esto algo participativo. DRAC permite una serie de métodos de acceso, por ejemplo ssh. Atendiendo a la configuración de PAM
/etc/pam.d
diags
kvm
login other
racadm
sol

sshd
#%PAM-1.0
auth sufficient pam_ldap_manager.so
auth sufficient pam_local_manager.so use_first_pass
auth required pam_auth_status.so
account sufficient pam_ldap_manager.so privilege=0x01
account sufficient pam_local_manager.so privilege=0x01
account required pam_auth_status.so
session required pam_auth_status.so
session required pam_session_manager.so sessiontype=SSH maxsessions=2

telnetd
vm
vmcli
webgui
wsman

Tenemos el /etc/shadow mapeao a memoria flash, pero el shadow por defecto, y que es copiado a la flash por un script en al inicio, está en /etc/default/shadow

root:$1$fY6DG6Hu$OpwCBE01ILIS1H/Lxq/7d0:13502:0:99999:7:::
user1:$1$nVOr80rB$HDAd6FRlG24k/WN4ZuYPC0:0:0:99999:7:::
racuser:!:0:0:99999:7:::
sshd:*:11880:0:99999:7:-1:-1:0

Aunque la documentación avisa que se debe cambiar el password de root, en ningún sitio se menciona el usuario «user1». Por lo tanto estaríamos ante un usuario backdoor o una cuenta de testing de los developers, el problema es que es altamente improbable que ningún administrador haya cambiado el password o deshabilitado el usuario ya que no pueden tener conocimiento de ella.

A parte de otras vulnerabilidades que podamos encontrar vamos a hacer de esto algo participativo.

Para los ninjas del cracking de passwords (@aramosf puta dale cera) vamos a ver si entre todos petamos los passwords. El premio es acceso al sistema 🙂 (no hombre, que es ilegal), ¿cómo encontrarlos? Bueno, hay miles en Shodan http://www.shodanhq.com/?q=appweb

Si los sacais, avisad! Hasta la próxima!