​The Shikra is a very powerful tool to have in ones toolbox. (See this blogpost for some of the neat things that can be done with it.) We actually created the device in response to our frustration with tools like the BusPirate, and as a reliable tool for our "Software Exploitation Via Hardware Exploitation" course.  See some screenshots of how others have used it on the product page.

The Shikra "just works" out of box. Other than the FTDI drivers, it needs no client-side software. You don't even have to terminal into it (w/ minicom, putty, screen, et al) as you do with the BusPirate (and other tools). This is actually its strength. Because it works entirely in hardware, it is several orders of magnitude faster than tools like the BusPirate for tasks like dumping flash with SPI, extracting firmware with JTAG, etc.

Even though the Shikra works out of box and requires no configuration, we wanted to provide a utility (for those interested in "going deeper" and tweaking the device functionality by programming the onboard EEPROM memory. What follows is a primer in simple binary data manipulation techniques (with Python) and a bit about hardware in general.

EEPROM is Electronic Erasable Programmable Read Only Memory, which is a mouthful. In short, it’s a place we can store configuration data to change the behavior of the Shikra device.  Due to the nature of EEPROM the data we store there will persist even after the Shikra has lost power and been unplugged. (We go into quite a bit of detail on PROM, EPROM, EEPROM, and FLASH in SexViaHex so we'll skip it here.) We can do cool things like change the device name, serial number, USB descriptors, and even change the onboard LED to blink on data transmission! The project is open source and available here: https://github.com/Xipiter/shikra-programmer ​

The Shikra is manufactured with a 93C56 EEPROM holding 128, 16 bit words of data. The EEPROM is a separate chip onboard the Shikra PCB, which is connected to the FTDI FT232H USB controller. We started by pulling data sheets from FTDI, and lots of them. If you have a question, chances are the answer is in a data sheet, somewhere. As you know, the life of a reverse engineer is basically spent in data sheets. The unfortunate part is that these data sheets can often be confusing and hard to read for someone new to the subject. One of the first things we did was get FTDI’s FT_PROG utility. This utility can talk to the FT232H and program the EEPROM. We plugged in a Shikra, and sure enough we got a screen full of 0xffff words. 

Cool, this utility program works, but it was hard to use. It also doesn't allow for much instrumentation (although there are some DLLs and COM objects) and there is no source code and the official release only runs on Windows. The website INT3 exists so we can make hardware available and ready-to-use for security researchers, so we embarked on writing a Python programming utility that gave the same functionality as the FT_PROG utility.

​Initially, we just wanted to write *something* to the EEPROM on a Shikra. After that, we could work on writing the right bytes to the right places. We brushed up on USB control transfers and set off. The first thing was to locate the Shikra on the USB bus. The FT232H defaults to Vendor ID 0x403 and Product ID 0x6014. Using pyusb we can search for devices matching those values and see if a Shikra is connected. Once we were able to locate the device, we tried doing USB control transfers to write data to the EEPROM. We were able to write 0x0000 to each word and then verify it worked by reading the EEPROM with FT_PROG. Yay!

​I noticed that FT_PROG’s hex dump screen was in big endian format, but the bytes when reading and writing were in little endian format. The EEPROM is mentioned in many data sheets, but never the layout of the actual configuration data. Generic statements say that things “are possible” with programming of the EEPROM, but no where is it mentioned *HOW* to do it. Apparently, that’s something you have to sign an NDA with FTDI to find out. Good thing a few other people have open source code that documents the EEPROM layout quite well (links are in the header of Shikra programmer code)
​
​Sneak peek of full EEPROM layout: 

​My goal was the write a barebones configuration to the EEPROM with my utility, and then read the data back in the FT_PROG utility in a correct way. This way we knew that what we programmed was correct enough for FTDI’s standards. Over the next couple of days we spent a lot of time plugging and unplugging the Shikra after tweaking values. We were unable to get the FT_PROG utility running on a Windows VM, so we fired up an old physical desktop to do the FT_PROG tasks (and hence going back and forth between computers. A lot.) The actual EEPROM programming is very boring. “Shikra, write 0x0000 to address 0x0!” And so on and so forth. Reading and writing values was the easy part. It’s all about knowing *WHAT* and *WHERE* to write values. We had to come up with a good way to model the Shikra EEPROM memory in Python and then “flush” the data structure to the EEPROM when programming. We ended up using the Struct library and a list. Each list/array element was a single 8-bit word of data. But didn’t we say that the EEPROM was addressing in terms of 16-bit words? Yes, we did mention that, which slightly complicates things. Every read or write would grab the two adjacent list elements and consider that one “word” to read or write to EEPROM. We wrote a few utilities that would take two 8-bit bytes and combine them into a 16-bit word and vice-versa.

​Everything in the Shikra programming utility uses a linear array of byte strings to represent EEPROM memory. This is literally represented in Python as a list of strings, where each element is a packed Struct object represented as a string. An example would be the 16 "byte" list:

​Each element is a struct.packed() value, stored as type string.

Some further explanation on the '>B' format string for packing and unpacking values:

Now that we can manipulate, read, and write data, we needed configuration to write to the device EEPROM. The first couple words on the EEPROM are reserved for FT232H mode, Vendor ID, Product ID, Release Number, and Current Draw. The next few words are essentially pointers to data mentioned later in the EEPROM. These pieces of data are the Manufacturer string, Serial Number, and Product String. In the beginning of EEPROM we write the starting address of each string, and it’s corresponding length. There is a large gap in EEPROM between these pointers and the actual strings, which we would later find out is where the *real* configuration goes on.

​At this point we have a barebones configuration written to the Shikra. We went through a lot of back-and-forth of reverse-engineering the layout specifics through trial and error of FT_PROG. We also looked at as much open source code as possible. Eventually this led to a moment when FT_PROG would read my EEPROM contents perfectly. This was pretty cool, but we hadn’t got to the main point — changing board pin configuration through programming. My first goal was to configure the onboard LED to blink.

​After reviewing the board layout, we determined the LED was connected to ACBUS9 on the FT232H controller (another reason FT_PROG is confusing is that this pin is called C9 within the utility). We programmed the Shikra using FT_PROG, making sure to set the state of the ACBUS9 pin. The pin has 5 states that are applicable to the LED: tx, rx, txrx, tristate, and drive 0. Tx, rx, and txrx blink the led according to data passing by. Tristate is the default ‘off’ configuration, and drive_0 will turn the LED on consistent. We would set the EEPROM contents with FT_PROG for the LED, and then would dump contents with my programming utility. This way we would know the slight differences between each LED mode, and could record them accordingly.

​This pin configuration data is stored in the space between the string pointers and the actual strings.

Please note that on older Shikra devices, the LED modes may not work!

​To review, we have been able to write the EEPROM contents with basic configuration data, as well as changing the FT232H pins to different states. we was able to change the operation of the pin connecting to the Shikra’s LED to blink under different circumstances. This was nice, but my code was pretty messy and was not very usable. We refactored most of the code, and wrapped it all in a nice Python interactive style interface with the Cmd library (as we do with quite a few Xipiter utilities). This way the utility has built in help, and has straightforward menus items. Here is a screenshot of the utility:

I hope the Shikra programming utility can be of use to you. We appreciate feedback and comments. This project helped me brush up on hexadecimal format, bit-shifting, the USB protocol, and many other things along the way. We got a good amount of hardware review and experience debugging electrical circuits with my multimeter. There were ups and downs, but overall the outcome is pretty slick!

Ben Reichert (@tgjamin) is formerly a Security Engineer at Xipiter. He is currently entry-level security Engineer with Senrio Inc. His background is in System Administration, DevOps, and Mobile security. Previously he has worked in large automation environments and maintained massive-scale websites. He has found a number of vulnerabilities in embedded systems, and Android applications. Ben enjoys reverse engineering, mobile web security, penetration testing, and hardware hacking. He (along with all of the Xipiter staff as of Jan 2016) is currently working on Senrio: enterprise-grade security for embedded systems.

 To opt out of using these apps/technologies is to effectively opt-out of participating in modern society (something that the reclusive and strongly opinionated  protagonist from "A Confederacy Of Dunces" might do).

A few weeks ago, as we were busy developing parts of the Senrio backend preparing to push new features to our beta-testers and pilot partners,  the Senrio platform noticed something funny about one of our developer's phones. Senrio repeatedly notified us so we decided to investigate to see if it was just a bug in the Senrio backend or if the alerting was genuine. What follows in this post is a story about our "trip down the rabbit hole" as we investigated and attempted to report issues in this one particular app. We've have MANY more stories like this that we'll share as soon as we can.

We found many critical issues which we will catalog below in the "Technical Details" section, but the short of it is that we found that we could:

• hijack a users' account
  
• post (publicly or privately) as a hijacked user
• view all of a user's current and past private messages 
  

In the course of this work we also discovered some other things that highlight the broader privacy issues especially as they relate to mobile apps and "anonymity" promising services. 

But before we go any further. We'll share a video that demonstrates us taking over an account and retrieving past and current messages for a hijacked user account (without the user knowing). As of this posting, this vulnerability is yet unfixed.

As you'll see in the "Chronology" below, the vendor denied that this was possible .

1. Senrio notified us (during our normal development work on the Senrio backend) that something was up with one of the Xipiter employees' mobile phones we were using for testing.
2. An Xipiter engineer spent some time investigating
3. Xipiter engineer Ben Reichert unveils about 5 critical vulnerabilities in the Whisper mobile app that caused the Senr.io alerts, and does a writeup of his findings.
   
4. Xipiter contacts a journalist about these findings and shares writeup.
   
5. Journalist contacts the vendor. The Vendor (careful to not deny) "deflects" issue severity. Vendor does however deny that message interception is possible.
   
6. 48 hours after receiving Xipiter report, Vendor quietly pushes a patch to App Stores to address each vulnerability in the Xipiter report. 
   
7. The Vendor again responds to the Journalist emphasizing that these issues are now patched and aren't critical . Vendor also states that the recent patch was to address other (not Xipiter's) reported vulnerabilities.
   
8. Journalist gets excited that Xipiter's vulnerabilities are validated by the Vendor's emergency patch (and the Vendor's general obstinance).
   
9. Xipiter's analysis of the app pre- and post- patch, reveals that virtually all changes made in the patch were to address Xipiter's reported vulnerabilities.
   
10. Vendor contacts Xipiter directly, acknowledges some (but not all) severity of Xipiter's vulnerabilities and offers Xipiter "reward" (which undoubtedly would come with non-disclosure conditions)
    
11.  Xipiter does not accept rewards from vendor.
    
12. Vendor contacts the journalist again and downplays the impact of these vulnerabilities claiming that they are also patched.
    
13. The journalist, initially excited, now balks and slows the article release requesting Xipiter demonstrate account hijack and "message interception" capability. (Side Note: Journalistic integrity of this kind is rare. So this was refreshing. We  laud his attention to detail...but still things are moving a little slow for our taste.)
    
14. Unbeknownst to the vendor, their emergency patched fixed some, but not all of the vulnerabilities.
    
15. Xipiter makes a video for the journalist clearly demonstrating a vulnerability allowing an attacker to retrieve a user's past private messages (a vulnerability that, btw, is still currently un-patched)
    
16. Xipiter, fed up with how long things were taking for the article, just posts everything here. We found many more vulns like this  in other apps (and Senrio has many alerts in the queue for us to investigate) and we want to get to them all, but we have to get back to our actual work..

When the app starts it generates some sort of userid token that it then uses for authentication. We uninstalled the app, re-ran it and the first request was one to https://prod.whisper.sh/user/new with a POST method. This returns a new userid, and PIN number. See example below: Which can be obtained through
curl "https://prod.whisper.sh/user/new" -X POST  which returns json with a new generated UID and PIN
{
"pin": "8888",
"uid": "051007c3c05e87532999917390ea7fb15b134f" 
}
Since they uids are generate on a request basis, they are not linked to anything like phone number, android id, etc. This also means that the account cannot be transferred between phones, or if the app is deleted the user will lose access to their account forever*.

When we were looking at subsqeuent https requests we noticed that they all, in some way or another, used this uid as authentication. This is a problem with the 'anonymous' applications like whisper and YikYak since they do not require a username/password combo, they instead rely on a private, unique identifier. The problem with this is that if at any point this uid is leaked, the users account can be taken over. There was a recent vulnerability in YikYak's service that leveraged exacly this. The YikYak users token was sent to a third-pary ad service in plaintext over http, so any MITM attacker could intercept this uid and take over the user's account. (see YikYak Ad Vulnerability) Since the uid is the only thing linking the phone to a user, it is used for everything, including ad services, api calls, and third-party data transactions, and just generally tracking the user's interactions.

When we were looking at requests made by the phone we noticed most of the requests use the uid as the sole method of authentication. There are no cookies, single use tokens, etc. We were surprised when we then saw a request that used a auth_token field in the url of a request. This request returns JSON with the user's generated username and password for the TigerText.me messaging service. An Example request is as follows:


curl "https://prod.whisper.sh/messaging/conversations/tt_auth?uid=050f036278f1ae9651664cf6e7151a3e3ada0d&auth_token=61370b16a0511020fcf80c63QILD410OMPI4SSF 

This returns basic auth user/password for the TigerText messaging service, which Whisper uses for messages between users. Of course, seeing this is the first time an auth token is used, we decided to see if it would work without an auth_token. And it did.

curl "https://prod.whisper.sh/messaging/conversations/tt_auth?uid=050f036278f1ae9651664cf6e7151a3e3ada0d&auth_token=9999"

Now, you still have to provide the auth_token field or the api endpoint complains about it missing, but what you put in it can be complete garbage and it couldn't care less. Just like the rest of the api services, the only thing you need to compromise an account is the uid. Ok, so enough about how this works, how would someone get my Whisper uid? You said that it's all over SSL so it should be hard to get right? Right? WRONG.

In our research we noticed that a good portion of the whisper.sh api runs on both port 80 and 443. The api itself doesn't care if you do requests over http or https. If you see where we're going with this, great! Why not just force the app to downgrade from https to http. SSLsplit is a widely used "rogue" AP software that does just this. When it sees a SSL connection to port 443 it tries to downgrade it to HTTP over port 80. This can be successful at times, and inconsistent at others as we found out. We also tried using MITMproxy for this as well, so we removed the MITMproxy self-signed certificate from our Android phone. Usually, this results in the phone refusing to connect through MITMproxy with SSL, since the cert is invalid. This test would replicate an unknowing user connecting to a "rogue" Access Point with MITMproxy running on it. While we were expecting the app to reject our SSL cert, it still sent traffic through MITMproxy! And we got the user's UID. This attack however, cannot be entirely remediated by Whisper, since one of the requests was to a third-party data collector called Mixpanel. See the request below: 

curl https://decide.mixpanel.com/decide?version=1&lib=android&token=c39eea2c9ad72a79d1688ca82c50cb94&distinct_id=050f036278f1ae965166  


The distinct_id is the UID that we want for account takeover. The worst part about this api service is that if if fails to connect over SSL, the app gives up and does over HTTP. So when security doesn't work, just turn it off, and we'll be just fine. We discovered this works when the unknowing phone connects to MITMproxy, or we just deny all outbound connections on port 443. The problem with the later is that the app basically stops functioning since it is smart and tries SSL connections, and will silently fail, but will not try to connect over HTTP. The user of the phone only notices that the app stops working, but the damage is already done. One could be smart about this downgrade attack and if leveraged properly the user would never know their account was hijacked. The unfortunate part for Whisper is that this is a third-party's api service, so they have no control to switch the API to https only.

Here we were able to simply downgrade the SSL connection to basic http and intercept the user's uid:

The Whisper app allows users to share links to whispers they like. When looking at the network request we thought it was a mistake it was done over HTTP. Of course, no private information is being transmit when getting a shortened url, right? Nope, of course it embeds the user's UID right in the url of the request. So, anytime a user shares anything in the app, they risk their account being hijacked. Example request follows:
 
curl -X GET "http://prod.whisper.sh/whisper/shortened/050f8caaca77a378697952b178afb1946582f6?uid=050f8c29de55a0828128c911a15637acba77

And here is the java source in the app responsible for this: 

We noticed that even after flushing app data and reinstalling the app that it restored the original account on that phone. After reviewing the network traffic from MITMproxy of this event we were a bit puzzled: the app seemed to know what the user's uid was before talking to the Whisper servers for the first time. This could only mean that the app was storing the uid on the sdcard. So we checked and there it was: 

SD card storage was never meant to be secure so any app on the phone can read the Whisper uid. Even Google'sAndroid documentation cautions against this: 

Before we dive into the next issues we discovered with this app we want you to take a look at the Whisper privacy statements and privacy policies. Keep them in mind as we explore the next parts of this app...

and....

Keep these in mind as we move forward and show you the next bits...

The app leaks a huge amount of data to third-party vendors. This is usually done with a base64 encoded POST. The data includes Android UID, Carrier, Phone model, type, device specifications, android version, log of everytime the app is opened, and log of how long the user is using the app (and a lot of other data!). "In addition, we may use and disclose certain Usage Data to third parties. This Usage Data doesn’t identify individual users." the Whisper Privacy Policy states.

The following data we intercepted appears to be a lot more than usage statistics and does link usage statistics to individuals through their uid: 

The first service we noticed the Whisper app sharing data with was Mixpanel.com, which receives a large amount of data from the app. This links the android phone hardware to the Whisper account. 

This would normally be fine, but in the "App Opened" data, they include the uid which then allows them to identify individual users from the data!

Here is the data on the wire:

We were able to figure out the encoding/encryption scheme (Base64 encoded, AES-128 with app embedded key), but with a quick peek inside the app there is no need to bother with decoding large blobs of data captured on the wire. Here is the code that generates that blob:

So while this is not technically PII as defined by the pure legal definition, it is (in our opinion) personal data. 
So now we'd like you to take a moment to perhaps scroll up to their privacy policy screenshots, or take a closer look at this other section of their privacy policy.

Whisper says they collect very little private information. To their credit, they do not include cell phone number, email addresses (and other information that falls under the legal definition of PII). But what they do however is link your account to your unique phone, which can then be linked back to your private information through other means. Furthermore they emphasize that THEY do not collect these metrics, and that much is true, they facilitate allowing third party vendors like Mixpanel and MobileAppTracking to do that work for them.

The security vulnerabilities we highlighted are egregious enough, but combined with the privacy implications of we just outlined above it really serves to frame the broader issue of the state of "Security" and "Privacy" that we as consumers are in.

Investors and "Industry Watchers" regularly regurgitate platitudes like: 'consumers don't buy privacy' and perhaps they're right. What we do know, however, is that we live in a climate where "chat" mobile apps (like Snapchat) can receive $19 Billion  valuations (as of Feb 2015) based solely on a user-base flocking for the promise of anonymity and security.   (Which, in the case of Snapchat,  turned out to be a lie. Yet no one noticed.) We already had mobile chat apps that skirted telecom charges by using data plans. They weren't new. What Shapchat offered that was new however was the promise of privacy and anonymity.  So "privacy" itself may not sell, but as evidenced by Snapchat and so many others it does inform consumer decision making. The market bears that out again and again. 

On the industry side, if embedded/IOT security doesn't seem like a mainstream security concern then consider this: Shodan, a search engine scanning the internet for Internet-connected devices, found that several of the security camera networks and HVAC systems at Google headquarters were freely accessible on the Internet.  Google takes information security very seriously, but the subcontractor that installed the cameras and HVAC systems did not. The recent Target Corporation compromise that resulted in one of the largest credit card thefts in history was found to be attributable to the insecure systems installed by just such — an HVAC sub-contractor.  (It is important to mention that Shodan has also found countless webcams, power-grid control systems, and even nuclear power plants openly accessible on the internet.)

Back in consumer-land, we see blips on the "privacy concern" radar almost daily:

And the "mobile app craze" and glut of IoT devices only continues to grow without mind to privacy.

Consumers need a gatekeeper. Consumers need a third-party trusted resource for the security and privacy ratings of apps and devices. Consumers need a "privacy consumer-reports". Consumers need a "privacy/security" National Transportation Safety Board.  FTC Chairwoman Edith Ramirez seems to get it. Michael Price of the NYU Brennan Center for Justice gets it. Currently, these are minority voices unfortunately. Hopefully, this will change.

The research we shared with you in this article is just ONE app. But security researchers see examples of this stuff regularly.

So we leave this question to you, the reader: If this is what we see in JUST ONE app, where do you plan to go to get authoritative information about the privacy impact of other apps and devices you use?

How will you look these up? Read hundreds of pages of End User License Agreements and Term Of Service?

Where will you get a veracious "privacy" rating on your apps and devices?

If you can't think of such a resource, then maybe it's time for one.

Since we've started teaching SexViaHex, many people (not just our students) have asked me (Joe Fitzpatrick) for equipment recommendations for doing their own hardware hacking. I own and use several tools with duplicate and overlapping purposes, since there's usually a 'best' tool for any given job. In the process of assembling the equipment and content forSexViaHex, I had a hard time whittling it down. The first answer to 'what should I buy first?' is and will likely continue to be the BusPirate (with a Saleae in close second). No single tool speaks so many protocols, and only a handful of tools provide lots of the diagnostic and passive sniffing features of the BusPirate. 

"So hold on a second" (you might be thinking) "First things first! How to we wire this Shikra up to stuff?"
It's really simple, the Shikra much like the BusPirate just has headers which you can use to jumper to your target. The pinouts of the Shikra are viewable in the documentation for it. 

According to the diagram to the above,  UART, the Shikra's pinouts are as follows:

TX: 1
RX: 2
GND: 18

Once wired up, the following command (from a *nix) machine will connect you through the Shikra to whatever you're targeting:

$ screen /dev/ttyUSB0 115200

Protip: I never worry about getting TX and RX right, since somewhere along the way they get mixed up, and it's usually easier to swap them once to get things to work than it is to make sure they're right in the first place.

We needed something different so we switched to a different FT232H-based board that worked well, but has had a very high failure rate (they'd burn up easily or stop working inexplicably).  We needed something more reliable. So after all that we decided to design something and the Shikra eventually replaced these tools.  The Shikra was equally as easy to get wired up for JTAG and use with OpenOCD:

Shikra JTAG Pinout:
TCK: 1
TDI: 2
TDO: 3
TMS: 4
GND: 18

OpenOCD Config File for the Shikra:
#shikra.cfg
interface ftdi
ftdi_vid_pid 0x0403 0x6014

ftdi_layout_init 0x0c08 0x0f1b
adapter_khz 2000
#end shikra.cfg

Of course, Shikra is not just for work. I recently got a Teclast Air II tablet (same panel as an ipad retina, but with an intel bay trail SOC and andriod/win8). I wanted to update it to a dual-boot bios, but accidentally bricked it because i flashed a bios file for the older Teclast Air 3G. Luckily i was able to resurrect it by using the Shikra + Pomona SOIC + Flashrom to directly flash the chip when it wouldn't boot otherwise.

In summary, I was pretty excited to get my hands on Shikra, and I'm looking forward to showing participants in our future SexViaHex classes how to use it to reverse engineer and hack up hardware devices!

When we last left off, we were setting the stage for sharing what the Interns found in a handful of "IOT" or internet connected devices they purchased. So we'll be starting with a simple one. One that only required simple techniques to compromise it. This first device is a "Smart"-Home Controller. For a bit of background on what's going on here, please see "Part One" of this series otherwise we're going to jump right in but first a disclaimer:

The following information is released FOR ACADEMIC RESEARCH PURPOSES ONLY. Xipiter staff did not at any time access the external or supportive infrastructure of any of the products mentioned herein. Furthermore, as a information security firm, Xipiter does not condone or encourage the use of the following material for the purpose of attacking or exploiting the devices of others. The purpose of this blog series is to raise awareness about the security risk posed by this new class of "IOT" or "Internet Of Things" devices.

Ben stepped through all the configuration steps as the device specified, but noticed something (by watching the network traffic intercepts).

In Step 4 of the configuration manual, it instructs you to connect to the manufacturer's website and enter the serial number and MAC address that is printed on underside label of the device. This presumably is to "pair" your user account with the hardware you purchased.  Ben noticed from the pcaps (from tcpdump) that immediately after entering this information, his web-browser was redirected to the local IP address of the device. It looked as though he was connected to the manufacturer's website, but there was an IFRAME actually pointing him at the device within the lab network. So the device is running a webserver.

Instead, when in "Secure Mode" the device spawned all of the daemons on 127.0.0.1 and SSH port forwarded them from the device through the manufacturers servers out on the internet.  This would allow you to access the device INSIDE your home network from out on the internet. (More on this "Secure Mode" later, because it is ironically the very feature that makes these devices open to potential remote attack.)

Ok so now that the device is set up and on the network, the interns opened the physical hardware it to see what they could see. As standard a procedure at Xipiter, everything is photographed through the lab scope right when it's opened so that serial numbers and model numbers can be recorded to download specification sheets (and so you don't have to remember to do it later for report writing). In the end, it'll turn out that none of the specification sheets were needed to compromise the device.

The first glaringly obvious thing is that the device is running an RALink core which we know from experience is a common MIPS based System On Chip popular with OpenWRT (We'll be validated shortly when we see in fact what it is running.)

In subsequent blogposts (in this series) and in our "Software Exploitation Via Hardware Exploitation" course we have to deal with using diagnostic tools and techniques to reach buried pins or discover which pins are responsible for what. But here, not only does thePCB Silkscreen clearly call out the pins but there are also headers soldered on. Clearly this manufacturer didn't iterate on the hardware design. These are all indications that the "development" and "release" revisions are the same hardware. 

The next step was to take a look around the filesystem...our goal is to find remotes so we want to find out what daemons are currently listening and which may be spawned by the system. 

After searching through the filesystem a bit for other references to the daemons in that process listing, it was determined that there was a light http daemon is used for service and setting files on the filesystem. 

The immediate next progression is to read the embedded HTTP config which revealed that this device has http configs that forward incoming requests to specific "endpoints" or web paths....So of course, some basic directory traversal stuff was tried. And eventually the interns landed on this:

So this is great. We are getting closer, we can get the password file unauthed remotely. BUT, one other thing to note is that the filesystem of the actual device is immutable including /etc/passwd (because it is distributed in the device as Mask ROM). To get around this and fake "mutable" parts of the filesystem, this manufacturer uses Non-volatile FLASH storage to basically store everything so that it can persist after reboot. 

They even use it to retrieve the root passwords stored in NVRAM ;-)

Ok, so let's review what we have so far:

• The device is using dropbear ssh daemon
  
• The device is using lighthttp with custom configs to serve files from the filesystem. There is an unauth'd directory traversal vuln here.
  
• We can fetch configuration values from NVRAM via the root console.
  
• The device has embedded SSH private keys on THE IMMUTABLE sections of the firmware image so we know that all these devices have the same embedded ssh key. It uses that key to access the manufacturers backend and set up ssh port forwards.

So at this point we need a tool to capture all of the "exploits" for these vulnerabilities.

So we now there is a need for a place to keep and release all vulnerabilities for these "Insecurity Of Things" posts. A place to keep them all bundled with easy access.....So we wrote a simple "modular" tool called idIOTic. 

This device was a very simple example, it didn't even require any of the fun stuff like "binary exploitation" to completely compromise the device and others like it. 

In the subsequent blogposts we'll go deeper and share more techniques from our SexViaHex class: 

• What if you cant easily access UART? 
  
• What if the firmware updates are signed or not easily downloadable?
  
• How can we use JTAG to pull firmware and analyze the firmware for vulns? 
  
• What if the embedded "webserver" is just some compiled C app servicing HTTP requests?
  
• What if there isn't a "full operating system" but just a RTOS?
  

We'll discuss all of this in more depth as we catalog what the interns found in a NAS, Access Point, and a Smart Thermostat (in the next post). With each post we'll also include PoC "exploit" modules for idIOTic.