SanDisk Wireless Media Drive Root Crack(and other useful info)

[Cleafspear]

Ah the SanDisk media drive. a pocket drive that is a wifi router,media server,and a fairly useful USB device. Sadly, it's also ripe with security issues that the average user may not know about......

So our target today: sandisk media drive 64GB running firmware 3.21(the latest revision as of this writing...)

to begin with,lets go over some already knowns about this device that have been found by the community:

• it has a WIDE OPEN ftp server that can be access by anyone either on the same network as the device or connected via wifi directly to it
• ssh is locked down, but there is a telnet server ready to go for your terminal.
• it runs a linux embedded environment (busybox)
• it has its own web interface for management via web browsers.

now this may not seem like much,but the web portal and the telnet will handle a large amount of what i needed to do in order to break this device open and get Root, along with more useful information to write a custom firmware image for it.

the first attack was to set up the device normally,setting a admin password (or keep it the default: password) using this, we log into the telnet server with user: admin password:admin password from portal

now this will land you in the file system at /var/ftp/storage .you are not chrooted,so you can browse the file system to get a feel of its structure (the important locations are /var/ftp/storage for the local storage and /var/ftp/storage/card for the additional SD card, everything else is partition in the protected sector of the flash storage)

surprisingly you can /cp most files in /var,however the files i was interested in was shadow. its not copy protected form admin, so it went to the local computer for some cracking...

in shadow you will find the following:(password hashes are --- out for what little security the device has...)

[spoiler]

root:---:0:0:99999:7::: bin:*:11851:0:99999:7::: daemon:*:11851:0:99999:7::: adm:*:11851:0:99999:7::: lp:*:11851:0:99999:7::: sync:*:11851:0:99999:7::: shutdown:*:11851:0:99999:7::: halt:*:11851:0:99999:7::: mail:*:11851:0:99999:7::: news:*:11851:0:99999:7::: uucp:*:11851:0:99999:7::: operator:*:11851:0:99999:7::: games:*:11851:0:99999:7::: gopher:*:11851:0:99999:7::: ftp:*:11851:0:99999:7::: nobody:*:11851:0:99999:7::: sshd:!!:11851:0:99999:7::: mailnull:!!:11851:0:99999:7::: xfs:!!:11851:0:99999:7::: ntp:!!:11851:0:99999:7::: rpc:!!:11851:0:99999:7::: gdm:!!:11851:0:99999:7::: rpcuser:!!:11851:0:99999:7::: nfsnobody:!!:11851:0:99999:7::: nscd:!!:11851:0:99999:7::: ident:!!:11851:0:99999:7::: radvd:!!:11851:0:99999:7::: postgres:!!:11851:0:99999:7::: apache:!!:11851:0:99999:7::: squid:!!:11851:0:99999:7::: named:!!:11851:0:99999:7::: pcap:!!:11851:0:99999:7::: amanda:!!:11851:0:99999:7::: junkbust:!!:11851:0:99999:7::: mailman:!!:11851:0:99999:7::: mysql:!!:11851:0:99999:7::: ldap:!!:11851:0:99999:7::: pvm:!!:11851:0:99999:7::: user:---.:11851:0:99999:7::: messagebus:!:15:0:99999:7::: haldaemon:!:15:0:99999:7::: admin:---:0:0:99999:7::: guest:---.:15744:0:99999:7::: 

gave this file to john to crack open, which took 12 min to crack root....

my root password was 7 characters (stranded alphanumeric, nothing special)

a interesting fact: the admin password is truncated to 8 characters. so if you know the first 8, you can log in

now for some juicy info...

• it has a 1 core freescale i.mx502 capable of running at 200MHz
• has LPDDR1 ram totaling 128MB
• uses WG7311-2A wifi chipset
• ftp server: pure-ftpd V1.0.36-20121015
• UPnP: miniupnpd V1.6.20120406
• uses U-Boot V1.2.5 for installing and updating firmware.
• web server is a Nimbus V1.1.8

now for the holes i found:

• ftp is wide open. no password to log in and no SFTP. careful of your files
• in /nimbus, the settings.db is a SQLite database with....password, password hint, and answer in CLEARTEXT
• root is standard 7 charaters long. a bruteforce attack takes a few minutes, but is possible and easy
• they may have went with a universal root password. both drives i have have the SAME root password
• you can reflash the device with alternate firmware from the app by simply placing the update img in the ftp base directory and running the updater from the app ( will natrally remove the set file so a user may not know what has happened)

now for some hackability and modding stats im after:

• it uses u-boot to manage all the updates.
• it has a built in hard set firmware. if a flash fails, it will reset to that image
• webroot is /nimbus
• the base os is busybox modified by sandisk

[cooper]

If I'm not misreading this, admin is simply an alias for root (both produce a user with uid 0, gid 0). So your discovery is that while the owner can (and presumably does) change the password to the 'admin' account, the identical 'root' account password can't be (easily) modified by the user and tends to be the same across similar devices, correct?

In other words, the owner is instructed (via the manual or something I'd presume) to change the admin account password to create a sense of security which is a false sense of security because the root account next to it which provides identical privileges doesn't get changed in this process and has proven itself to be identical across devices.

That's not good...

Questions:

That wide open FTP, does it serve files from / or from a fixed subdir (like Nimbus which restricts itself to /nimbus)?

What can you access once you know the password for nimbus? What can you do that you otherwise couldn't?

Did SanDisk provide sources, as the BusyBox license requires?

[Cleafspear]

Sandisk is currently in violation of of the buesybox os TOS, as they do not provide the sourcecode for the device. ive been escalated to a technical engineer when i opened a ticked about it and currently awaiting a reply on it(hopefully within a few days)i have a feeling they will brush me off with:"the source-code on our device is proprietary and we cannot release the code for the device"

If I'm not misreading this, admin is simply an alias for root (both produce a user with uid 0, gid 0). So your discovery is that while the owner can (and presumably does) change the password to the 'admin' account, the identical 'root' account password can't be (easily) modified by the user and tends to be the same across similar devices, correct?

In other words, the owner is instructed (via the manual or something I'd presume) to change the admin account password to create a sense of security which is a false sense of security because the root account next to it which provides identical privileges doesn't get changed in this process and has proven itself to be identical across devices.

That's not good...

Questions:

That wide open FTP, does it serve files from / or from a fixed subdir (like Nimbus which restricts itself to /nimbus)?

What can you access once you know the password for nimbus? What can you do that you otherwise couldn't?

Did SanDisk provide sources, as the BusyBox license requires?

to answer a few of your questions:

the code is NOT available at this time for the device, se above message.

the ftp server is chrooted at /var/ftp. trying to get it to move into the other directories is not easy and i have not been able to direct it to /var

for the password to nimbus: knowing the inital password:the truincated 8 digit password is not enough to push the device to update the firmware. you need that password from the nimbus server for it to command u-boot to install the firmware upgrades.

[cooper]

What happens when you change the root password and then reflash the firmware? Does the modified root password retain its value or is it changed back? It would significantly reduce the attack surface if you could change it to something more sensible.

When you say ssh is locked down does it mean it's not available by any real means or does it simply provide a proper version of it?

So basically a sensible person who owns this would want to:

- Change the admin as well as the root password - better yet, change the usernames too.

- Disable the telnet server.

- Update the ProFTPd config such that it allows write access but not overwrite or delete to what is effectively a public account. The files themselves are public but the public shouldn't be allowed to mess with the real content.

- Set it up as a WPA AP with a sensible password.

The plain text nimbus password is unfortunate, but once these measures have been taken it would take more than a modest amount of time to access it, and by the time you do access it you've effectively popped it already so it doesn't really matter anymore anyways.

To summarize, the device can be saved, but needs a bit more work once you've first obtained it than SanDisk would lead you to believe.

Edited May 27, 2015 by Cooper

[Cleafspear]

What happens when you change the root password and then reflash the firmware? Does the modified root password retain its value or is it changed back? It would significantly reduce the attack surface if you could change it to something more sensible.

attempted this, it sadly reset the root password back to the original value. which means its hard coded in the upgrades and CONFIRMS all devices have the EXACT same root password.This is Very Bad.

When you say ssh is locked down does it mean it's not available by any real means or does it simply provide a proper version of it?

the ssh is actively refused from any client.

i agree on the rest of your ideas to improve onto this device. however on the recommended change for ftp, i would also have the web interface locked down to read only until authenticated to write/delete. same as with the app.

i also made a mistake in the processor listing i realized. its 800Mhz, not 200.......i cannot seem to correct this.

[cooper]

You need something like 5 posts on the forum before you get the ability to edit your posts.

[Joebuddah]

Could someone tell me if aircrack would work on this device? I've been trying to get it to compile unsuccessfully. My idea was to have aircrack run deauth as a service. My idea is to use it as physical Trojan horse during penetration testing. Attach it to a bunch of keys, and drop it in the parking lot. My thinking is that the majority of people would turn in keys to lost and found.

[cooper]

But it won't do anything until lost & found actually plugs it in. There's no power source within the device itself (or, for that matter, room to add it yourself).

edit: I'm an idiot.

Edited February 8, 2016 by cooper

[Cleafspear]

@ Cooper, the device contains a battery that can run for 12-18 hours.

@joebuddah due to damage to the device I had, I could not test whether or not you could add software to it. I speculate that you would need to compile it using firmware that was released on git hub after I had asked them on it. I am unsure if they have implemented all the code required to properly compile for the device.

Edited February 8, 2016 by Cleafspear

[cooper]

@ Cooper, the device contains a battery that can run for 12-18 hours.

Apologies. I had this thing mixed up with a different device.