My Experience with Learning binwalk (0day?)

cryptology

#1

How I found a Vulnerability using binwalk (0day included)

While attempting to teach myself how to use binwalk from this tutorial by Praetorian, I ran into a few problems with the firmware. So I decided, “Fuck it! We’ll do it live!”
Since I’ve been working in the Healthcare industry and would be reverse-engineer medical devices for future assignments, I decided to just get started now.

Required Skills

To completely understand the content of this article, the following lists pre-requisite knowledge:

  • General Linux Knowledge

Let’s get Started

I looked for some firmware and came across this article.
Atredis found a few vulnerabilities in two devices, GE Healthcare MAC5500 EEG, and the Silex SDS-500, SD-320AN linux-based WiFi bridges.

They found some OS Injections in the SD-320AN, which I thought was pretty cool. Silex updated their firmware, so these vulnerabilities shouldn’t be present. Atredis also shared a link on the current version of the firmware, so after the patch.
I wanted to know what would happen if I ran binwalk on the updated firmware. (I still didn’t know how binwalk worked).

After running binwalk, I got a layout of a linux filesystem.

From here, I usually just go straight to /etc/passwd

root:x:0:0:root:/tmp:/bin/sh
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:100:sync:/bin:/bin/sync
mail:x:8:8:mail:/var/spool/mail:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
operator:x:37:37:Operator:/var:/bin/sh
haldaemon:x:68:68:hald:/:/bin/sh
dbus:x:81:81:dbus:/var/run/dbus:/bin/sh
ftp:x:83:83:ftp:/home/ftp:/bin/sh
nobody:x:99:99:nobody:/home:/bin/sh
sshd:x:103:99:Operator:/var:/bin/sh
admin:x:1001:1001:Linux User:/tmp/jail/tmp:/usr/bin/console

This wasn’t that much help. So then I looked at /etc/shadow

root::10933:0:99999:7:::
bin::10933:0:99999:7:::
daemon:
:10933:0:99999:7:::
adm::10933:0:99999:7:::
lp:
:10933:0:99999:7:::
sync::10933:0:99999:7:::
shutdown:
:10933:0:99999:7:::
halt::10933:0:99999:7:::
uucp:
:10933:0:99999:7:::
operator::10933:0:99999:7:::
ftp:
:10933:0:99999:7:::
nobody:*:10933:0:99999:7:::
admin:tVMhrdFrEt866:0:0:99999:7:::

You notice the password for admin?
tVMhrdFrEt866

I thought this was a hash so I plugged it into CrackStation. A great website that has a ton of hashes already there.

“Unrecognized hash format.” So…it’s not a hash.
After a few moments, I thought about just throwing it into a base64 decoder.

Base64 decoded tVMhrdFrEt866 as S!k:

Conclusion:

All in all, from grabbing the firmware, to running binwalk (poorly. I’m sure I’m underutilizing it’s potential.), and plugging this encoded string into a hash lookup and decoder, this entire process took me only about 2 hours. I spent more time being afraid of trying things in the wild, than I did actually discovering things. If you ever want to try or get into something, but want to build your skills up first, I suggest, if it’s harmless like this, just do it. You’ll learn. If it has some legal or criminal implications, then maybe you should spend more time in the Information Gathering and Recon phases. But this is harmless. Mostly.


(3,4,5-trimethoxyphenethylamine) #2

Yeah, sadly embedded devices usually have backdoor passwords. They don’t even go to the troubler of making a decent backdoor, they just add a user.


(system) #3

This topic was automatically closed after 30 days. New replies are no longer allowed.