Welcome to the third part of our series! Today I hope to spark a conversation amongst the readers about an important topic in a world filled with IoT: access to device firmware. And not just (at best) encrypted opaque blobs provided for device updates, but usable images that can be deconstructed, evaluated, and reconstructed.

There are a few categories of devices for which firmware access would apply. These are consumer, enterprise, medical, and military. My coworkers and I have dealt with all of these to varying degrees. You might think military procurement would always include full firmware/source code access; I mean, they'll want to make sure the device is not designed in a way that is counter to their interests in the same way that I want to ensure the same thing when I (and most other people for that matter) also purchase a device. Mumble mumble...

What about consumer or enterprise grade devices? Most vendors have some support level (i.e. price point) at which they'll give an enterprise customer access to firmware. But for smaller organizations, or one-off purchases, they are often told what I am as a consumer a majority of the time: "no". In the last two parts of our series, I'll go into deeper thought on firmware access using current and upcoming examples from our vulnerability disclosure program.

An advisory for the first example I'll use has been released in coordination with this blog under CVE-2015-2874. The advisory, KL-001-2015-007.txt, is for an undocumented account in a portable NAS developed by Seagate.

Download URL: http://www.seagate.com/support/downloads/item/satellite-firmware-master/

The firmware of the affected device is designed so that the end user of the device has complete control of the underlying operating system. They have root. While I love this concept for a product, it certainly doesn't mean the product has no faults. An undocumented account is certainly a fault that should be corrected. Seagate quickly acknowledged the account's existence and within a few weeks had produced a patch that removed the account. The account didn't have any privilege, but did allow shell access. The reason I reported it is because from a incident response perspective, it's hard to triage an issue about an account on a device that you didn't know existed. Here is how I found it.

I started off by running binwalk:

root@itsasmallworld:/tmp# binwalk satellite_firmware_xf_DVT_1.3.7.001.bin 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             POSIX tar archive (GNU)

Since this file is in the tar format, I'll use the tar command to extract it.

root@itsasmallworld:/tmp# tar xvf satellite_firmware_xf_DVT_1.3.7.001.bin
uImage
uImage_md5sum_pc
rootfs.jffs2
rootfs.jffs2_md5sum_pc

After extraction, we're left with a few other files which includes a jffs2 filesystem image.

root@itsasmallworld:/tmp# ls
rootfs.jffs2  rootfs.jffs2_md5sum_pc  satellite_firmware_xf_DVT_1.3.7.001.bin
uImage        uImage_md5sum_pc

We can easily extract the files and directory structure from the image using unjffs2. This application is developed by Craig Heffner of the devttys0.com blog.

root@itsasmallworld:/tmp# unjffs2 rootfs.jffs2 jfroot/
FATAL: Module mtdchar not found.
Error: Module mtdram is not currently loaded
97280+0 records in
97280+0 records out
49807360 bytes (50 MB) copied, 0.880434 s, 56.6 MB/s
JFFS2 image mounted to jfroot/
root@itsasmallworld:/tmp# cd jfroot/
root@itsasmallworld:/tmp/jfroot# ls
bin             home            media           sbin            sys
boot            include         mnt             share           tmp
dev             lib             proc            srv             usr
etc             linuxrc         satellite_app   static          var

Now we'll browse to the /etc directory and review the associated passwd files.

root@itsasmallworld:/tmp/jfroot# cd etc
root@itsasmallworld:/tmp/jfroot/etc# ls
angstrom-version     init.d               org_passwd           rpc
autoUpdURL           inittab              passwd               scsi_id.config
avahi                inputrc              passwd-              services
busybox.links        internal_if.conf     profile              skel
dbus-1               ipkg                 profile.d            syslog.conf
default              iproute2             protocols            terminfo
device_table         issue                rS.d                 timestamp
device_table-opkg    issue.net            rc0.d                tinylogin.links
fb.modes             localtime            rc1.d                ts.conf
filesystems          mke2fs.conf          rc2.d                udev
fstab                motd                 rc3.d                udhcpc.d
group                mtab                 rc4.d                udhcpd.conf
host.conf            network              rc5.d                udhcpd_factory.conf
hostname             nsswitch.conf        rc6.d                version
hosts                opkg                 rcS.d
root@itsasmallworld:/tmp/jfroot/etc# cat passwd
root:VruSTav0/g/yg:0:0:root:/home/root:/bin/sh
daemon:*:1:1:daemon:/usr/sbin:/bin/sh
bin:*:2:2:bin:/bin:/bin/sh
sys:*:3:3:sys:/dev:/bin/sh
sync:*:4:65534:sync:/bin:/bin/sync
games:*:5:60:games:/usr/games:/bin/sh
man:*:6:12:man:/var/cache/man:/bin/sh
lp:*:7:7:lp:/var/spool/lpd:/bin/sh
mail:*:8:8:mail:/var/mail:/bin/sh
news:*:9:9:news:/var/spool/news:/bin/sh
uucp:*:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:*:13:13:proxy:/bin:/bin/sh
www-data:*:33:33:www-data:/var/www:/bin/sh
backup:*:34:34:backup:/var/backups:/bin/sh
list:*:38:38:Mailing List Manager:/var/list:/bin/sh
irc:*:39:39:ircd:/var/run/ircd:/bin/sh
gnats:*:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:*:65534:65534:nobody:/nonexistent:/bin/sh
xoFaeS:QGd9zEjQYxxf2:500:500:Linux User,,,:/home/xoFaeS:/bin/sh

The xoFaeS user is not discussed in the GoFlex documentation and the hash cracked to etagknil. The root user is documented and the hash cracked to goflex.

Here is something interesting about the xoFaeS account: It was the first real _user_ on the system. The UID 500 and generalized account description typically correlate to the first user created after system installation. Between that fact and the quick recognition and removal of the account, I would bet this was merely an accident. But, that's OK! Because Seagate has allows end users to access firmware I was able to discover the account and help ensure it got removed. How about a vendor that doesn't put in that kind of effort? Lets use Linksys as an example.

Week one of my series was spent discussing a series of vulnerabilities in the Linksys EA6100 access point. Linksys allows end users to access firmware. They also allow for custom firmware to be installed on many of their devices. However, they weren't exactly responsive to our disclosures. In fact, they didn't respond at all. They eventually violated our disclosure policy through a lack of response and as such we disclosed the vulnerabilities so that end users may take steps to address them on their on. Most of the issues were centered around information being disclosed through a CGI file sysinfo.cgi which returned copious amounts of information about the operation of the device. Since Linksys has an open position on firmware and hardware access, simply removing that CGI file resolved some of the discovered issues.

So, we've discussed two devices whose firmware can be easily accessed. Although the vendor response was mixed, ultimately the issues could be addressed on an individual basis. So why wouldn't every device manufacturer take the same position? Maybe you can augment my list, but I've seen a few scenarios. Lets go back to my earlier statement: "I mean, they'll want to make sure it's not designed in a way that is counter to their interests in the same way that I want to ensure the same thing when I purchase a device."

Sometimes, devices aren't designed entirely how we perceive them to be. One thing I have come to learn quite well is that when you purchase a device you may or may not be done paying for it. Sometimes a payment isn't money but rather information. What the heck does that mean? Well.. Take the Blossom for example. The Blossom is a relatively cheap device (~$100) that you install on your network and eventually controls the watering of your lawn. I discussed the Blossom in detail in part two of our series but I will quickly re-highlight a passage in their privacy policy that is pretty important to the thesis of this part:

What We Collect

[snip]
We also collect passive information such as your IP address on certain
IConservo Products, your ZIP code, as well as information about your
IConservo Product such as MAC addresses, product model numbers,
software versions, chipset IDs, and region and language settings.
Passive information also includes information about the products you
request or purchase, the presence of other devices connected to your
local network, and the number of users and frequency of use of
IConservo Products and Services. We also collect passive information
regarding customer activities on our website. Some passive information
may be associated with personally identifying information. [snip]

Who We Share With

We work with third parties in connection with some aspects of the
ICONSERVO Products and Services, such as but not limited to processing
payments and providing marketing assistance. 
[snip]

So we're back to: "the presence of other devices connected to your local network." Remember, sometimes information is our payment. This type of data collection can be turned around, packaged, and sold to advertisers. Now, that may or may not be the case here. You can decide for yourself based on the full policy located at: http://myblossom.com/legal/iconservo-privacy-statement/

This type of approach actually allows manufacturers to make IoT devices at a cheaper price because you're never really done paying for it. This isn't the only reason (I think) I have been told no when requesting firmware for devices I purchase though. Businesses can take an extreme perspective on intellectual property. Should the device have a novel feature there could then be paranoia that the feature may be reverse engineered and suddenly spring up in other devices. I suppose I can be somewhat sensitive to that issue, but I still side with the notion that if I have purchased a device then I should very well be able to inspect that device to whatever degree I determine to be acceptable.

What about a device manufacturer hoping to retain security through obscurity by denying firmware access to consumers? How often have we in the industry seen this approach be successful? Join us next time (There may be a small delay in our disclosure process so it likely will not be next week) where we will continue this discussion using that exact argument. Spoiler alert: Denying access doesn't make your device more secure than it already isn't.