| Reversing DELL's DRAC firmware |
|
|
| Written by Rubén | |
| Monday, 15 August 2011 | |
|
Update #1 http://twitter.com/#!/reversemode/status/103372506869661696 Update #2 http://twitter.com/#!/reversemode/status/103386457707782144 pam_local_manager.so != pam_unix.so so /etc/shadow is not being used to authenticate users :( Hi, Firmware reversing is really interesting, better said not only interesting but mandatory when you are researching into SCADA devices. However, this time I'm going to explain how to discover vulnerabilities on embedded systems, without needing the device at all. In this case, our target is the latest version of DELL's out-of-band management system: iDRAC 6. When facing a new software / hardware, first of all is to find as much documentation as possible about the system. By reading Wikipedia's entry about DRAC we come across the most important references, moreover simple google searches show a lot of interesting results. Although the source code of certain components of DELL DRAC firmware are available, Dell does not provide neither the environment to create a functional firmware nor the code of a fully functional final version. Therefore, we do not have access to the more interesting part, reverse engineering comes into play. Let's see how far we can go. You can download the latest version from Dell's support page http://support.us.dell.com/support/downloads/format.aspx?releaseid=R299265&c=us&l=en&cs=&s=gen It's a self-extracting zip that unpacks two files, one of them is the firmware "firmimg.d6" (54mb). Now, we can start by using binwalk to see how many info it can extract. We can not blindly trust this program, based on signatures, since sometimes it returns false positives and/or results that make nonsense. Anyway, it's a good starting point. DECIMAL | HEX | DESCRIPTION -------------------------------------------------- ------------ 0x200 512 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 1,892,957,376 bytes, named \ 240 \ 324 <\ 300hsqs \ 324 \ 324 <\ 300 \ 177 \ 023. 12436 0x3094 ROM filesystem Linux Compressed data, little endian size 0xc03cd538 3225212064 CRC, edition 3225212264, 3225738208 blocks, files 3225738220 0x309C 12444 Squashfs filesystem, little endian, version 54632.49212, 4991 bytes, -1069755180 inodes, blocksize: 56288 bytes, created: Fri Aug 11 4:51:44 2006 103296 gzip compressed data 0x19380, from Unix, last modified: Sat Mar 12 21:10:25 2011, max compression These are some results, mostly false postivies. The only valid result is located at 0×200. It is quite common to find an image of the bootloader u-Boot (both standalone and kernel image). We are not particularly interested in this image, although we could debug through qemu-system-arm compiled with gdb debugging stubs and gdb/IDA. Taking into account the firmware file is about 54mb, it should contain much more than a kernel. Analyzing the file's entropy , for example by using one of the latest commits of radare2 (thx @trufae!) "rahash2 -b 512 -a entropy firmimg.d6" or just by taking a look at the file we'll see how at offset 0x45b0000 a big area of high entropy, which usually means compressed or encrypted data, can be observed Above that area we find  If you look carefully, the magic of a CramFS "45 3D CD 28" emerges, it is followed by "Compressed ROMFS" and names of directories, files ... so it's pretty clear. Summing up, before entering the zone of high entropy we have a header of a CramFS which seems legit. Therefore, all we have to do is dumping the file contents from that magic until the EOF. dd if=firmimg.d6 bs=1 skip=4480512 of=tirori.fs mount -o loop -t cramfs tirori.fs /mnt/drac Ready, by mounting the filesystem we should have access to all configuration files, certificates, shadow, binaries ... full list is available at http://pastebin.com/Wn10iFf3 We can go further and emulate the binaries contained in the firmware in order to discover vulnerabilities. How? QEMU supports two modes, full system emulation and user-mode only. In this case what we want to emulate is the user layer, so we have to perform the following steps 1. Set up a cross-compiling/debugging environment for ARM, such as (http://www.codesourcery.com/sgpp/lite/arm/portal/subscription?@Template=lite) 2. Cross-Compile QEMU user-mode + static + target arm $./configure-enable-user -static -target-list=arm-linux-user -enable-debug 3. Turn on kernel support for other executable formats $ apt-get install binfmt-support Download and run http://compbio.cs.toronto.edu/repos/snowflock/xen-3.0.3/tools/ioemu/qemu-binfmt-conf.sh 4. Create /usr/gnemul/qemu-arm and copy libraries from /mnt/drac/lib to this directory. 5. Copy qemu-arm to /mnt/drac/usr/local/bin 6. Chroot /mnt/drac 7. Map /proc and /dev into the chroot environment in order to be able to use commands like "ps" and especially to let arm binaries use /dev/(u)random within the chrooted environment. mount-bind /dev /mnt/drac/dev mount -t proc proc /mnt/drac/proc Following these steps we can run, through the QEMU user-mode emulation, any suitable binary. We need to debug the binaries as well. Taking into account that qemu user-mode does not emulate ptrace, we'll take advantage of gdb remote debugging capabilities + "qemu-arm -g" (Chrooted) $ qemu-arm -g 1337 binary Outside chrooted environment, use the cross-compiled gdb for arm as follows (Gdb) target remote localhost: 1337 i.e: In order to debug the web server they're using ( appweb ) (Chroot) # qemu-arm -g 1337 /usr/local/bin/appweb -r /usr/local/lib/appweb -d /usr/local/www -a 0.0.0.0:8150 (Outside) $ arm-none-eabi-gdb (Gdb) target remote localhost:1337After some "stress" SIGSEGV signals appear... Finally, let's make people get involved. DRAC allows several remote access methods, such as ssh. According to the PAM configuration /etc/pam.d diags kvm loginother racadm sun 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 Sufficient privilege account pam_ldap_manager.so = 0 × 01 Sufficient privilege account pam_local_manager.so = 0 × 01 pam_auth_status.so account required session required pam_auth_status.so session required maxsessions pam_session_manager.so sessiontype = SSH = 2telnetd vm vmcli webgui wsman We have the /etc/shadow mapped into flash memory, but the default shadow, which is copied to the flash mem by a script at startup, is /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 See updates above Beyond other vulnerabilities and curious data we can find on this firmware, let's see whether the community can crack these passwords. Thousands of exposed systems are out there waiting for your inputs ( no! ) http://www.shodanhq.com/?q=appweb If you manage to crack it, please let me know: @reversemode |
|
| Last Updated ( Monday, 12 December 2011 ) |
| < Prev | Next > |
|---|
