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.
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."
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.
Comments are closed for this story.
|Please contact us if you would like more information about our services, tools, or careers with us.|