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.

We play "spot the Shikra" frequently on "Hardware Hacking" tweets, presentations, and blogposts.

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 block diagram.

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 websiteINT3 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.

​Where to start?

​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!

​EEPROM Layout

​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:

The full Shikra EEPROM Layout

​Starting Programming

​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.

​An interim on Struct packing and unpacking

​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:

​Writing String configuration data

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.

​Changing pin options

​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.

​LED programming

​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!

​Wrapping it up all nice

​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!

About the author

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.

Everyday we hear about a newfangled mobile app or "Internet Of Things" (IoT) device. Kickstarter and IndyGoGo are rife with IoT ridiculousness. (Crowdfunding is the new "Skymall" after all.) Mobile Apps are a new kind of celebrity. A new kind of techno-fashion. The apps you use define the cliques (demographics) you participate in. Which, in turn, defines not only who you socialize with, but how you participate in public discourse.

So, if you have privacy concerns, do you opt-out of participating in modern society? Is that really currently the only option?

At Xipiter we perform quite a bit of security research on mobile and embedded devices. We teach classes, give talks, and perform services for governmental organizations, defense contractors, colleges, and large industry companies all on the security of mobile and embedded devices.We like to consider ourselves purely researchers and as such, have had very little public opinion on politically charged subjects like "privacy", "surveillance", "responsible disclosure", et al. We'd rather just do good work, make useful tools, give back to the community from whence we came, and make our clients happy.

What we've been building led to what we found...

We've been quietly (until now) developing a platform called Senrio™ and what we are discovering with it, is forcing us to form opinions about some of the above. In a very small nutshell, Senrio blends "big data" analysis, "machine learning", and security services to address the problem of lack of security visibility for internet connected devices and mobile phones. Senrio was initially designed to help companies protect and monitor their mobile devices, industrial control systems, and internet enabled hardware and it does this very well. But recently ,we've found that Senrio also can help consumers protect their privacy.

The newest version of the Senrio unit.

Senrio beta-tester and pilot partner units.

The Senrio devices work by acting like "security savvy" Access Points that monitor IoT devices, mobile devices, and even the apps running within mobile devices. Senrio then notifies when apps and devices behave strangely. This allows the Senrio user to proactively control how their devices contact the internet in real-time. Senrio effectively gives "visibility" into the behavior of all these otherwise black-box internet enabled appliances (and mobile phones).

SO THAT'S WHAT WE'VE BEEN BUILDING, here's how it found it:

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.

SO WHICH APP WAS IT?

Senr.io alerted on quite a few apps and we have much to share, but the one that is the subject of this post is apparently used by ~10-30million people according to app store downloads. It is called Whisper.sh. It allows posting of anonymous messages and facilitates "private" conversations between two or more Whisper users. Unbeknownst to us at the time of our investigation, Whisper had some privacy concerns publicized as early as last October (2014).

Senrio alerted on many more apps but the one that is the subject of this post is apparently used by ~10-30million people

so WHAT DID WE FIND?

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.

"private" message interception (video demo)

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

THE CHRONOLOGY OF "disclosure" :(over the last several weeks)

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.

An Xipiter engineer spent some time investigating

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.

Xipiter contacts a journalist about these findings and shares writeup.

Journalist contacts the vendor. The Vendor (careful to not deny) "deflects" issue severity. Vendor does however deny that message interception is possible.

48 hours after receiving Xipiter report, Vendor quietly pushes a patch to App Stores to address each vulnerability in the Xipiter report.

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.

Journalist gets excited that Xipiter's vulnerabilities are validated by the Vendor's emergency patch (and the Vendor's general obstinance).

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.

Vendor contacts the journalist again and downplays the impact of these vulnerabilities claiming that they are also patched.

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.)

Unbeknownst to the vendor, their emergency patched fixed some, but not all of the vulnerabilities.

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)

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..

The technical detailsif you aren't technical, you may want to skip down to the "conclusions" or the "how your data is handled"section.

user ids

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.

Subsequently, if someone gets ahold of your UID they have complete control of your account because there IS NO authentication

If someone gets a hold of your Whisper uid, they then have complete control of your account without you ever knowing. To make things worse, if using a traditional username/password combination you could at least reset your password and regain access to your account if it was compromised. Since this is a flaw with the single uid method, once someone has your userid token, there is no way to reset your account. You can only create a new account, and give up the old one to the attacker. But even this is cumbersome since the even after the app's data is deleted and reinstalled it restores the users original account (more on this later).

They try some message security, but fail.

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:

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.

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.

Stealing UIDs: https downgrade

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:

The distinct_id is the UID that we want for account takeover. The worst part about this api service is thatif 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 properlythe 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:

Shortened url uid leak

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 sharesanythingin the app, they risk their account being hijacked. Example request follows:curl -X GET "http://prod.whisper.sh/whisper/shortened/050f8caaca77a378697952b178afb1946582f6?uid=050f8c29de55a0828128c911a15637acba77And here is the java source in the app responsible for this:

SDcard insecure UId storage

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:

How your data is handled

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:

Mixpanel data

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!

This data is starting to look more and more personal...but it gets...worse.

Mobileapptracking.com 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:

We've circled them for you but some of the ones that might jump out at you are: GoogleID, FacebookID, Twitter ID, Gender, Latitude and Longitude, Mac Address, Country Code, Network Code, Carrier

So while this is not technicallyPII 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.

Conclusions and some thoughts..."if you aren't paying for the product you probably are the product"

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:

IoT Barbie dolls send recordings of children's voices to the cloud.

Samsung's documentation reveals that users of Samsung SmartTVs shouldn't have private conversations in front of the televisions.

On the policy side, we have HIPAA for patient records, and PCIDSS tries (often ineffectively) to set security standards for financial (credit-card) data. But what about biometric data from your fitness tracker, phone unique identifiers, or recordings of your voice? It's the Wild West right now for data that is clearly "personal data" but it's not legally classified as PII.

Everyone is complaining about "government agencies" and "mass surveillance" but these same complainers are willfully sharing their personal data with the private companies that power their favorite fashionable mobile apps. (Even the president has a location tracking FitBit).

Everyone is complaining about "mass surveillance" but unknowingly sharing private information with marketers and data brokers through apps and IoT devices

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

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?

Why "the Shikra"?

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.

Once you've identified all your pin-outs, protocols, data rates, and device addresses, It's usually best to move on to more robust single-purpose tools. (Techniques and tricks for doing this we focus on quite a bit in our SexViaHex course.). We had a hard time choosing which tools to include in the class since there are so many choices and limited time in our class, and limited space in our Student Kits.

FTDI's FT232H chip is the more powerful older brother to FT232R USB to UART adapter. The "-H" model of chips are widely used in JTAG adapters but also support several different serial protocols, plus the ability to bit-bang custom ones. The Shikra is Xipiter's nice, dead-simple FT232H device that allows you to use all these different modes. (FYI: Keeping with the "accipiter" theme at Xipiter, Shikra was also named after a bird of prey.)

So what practical things can you do with it? Here's a few things I've done with it so far.

The shikra for uart:

The bus pirate has several UART features like passive sniffing, baud detection, and a transparent passthrough mode. It should let you do most of what you need to over UART. Usually once i've figured out my pinout and baud rate, i switch to a simple USB TTL Serial cable to free up my bus pirate for better things. On the access-point/router shown below, UBOOT runs at 120kbps while the kernel (which loads after) boots at slower 115.2. The bus pirate tends to be very picky and fails if the baud rate is only slightly off, while a dedicated cable usually has a wider tolerance and can read both with no settings change. The Shikra had no problem with this.

The Shikra case.

"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.

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.

The Shikra acting as UART adapter to attack a router/access point.

The Shikra for JTAG:

The Shikra in a 3D printed version of its case .

JTAG adapters run $10 to $20,000 - but in the end they're all speaking the same protocol. For SexViaHex, we needed to use JTAG at the same time as UART so we knew we needed a second device. We tried using EZ-USB FX2boards, but had trouble reliably sourcing them. The first time we taught the class, we used the Bus Pirate since it is well supported by OpenOCD - however it's incredibly slow, and required frequent reconnecting for hardware reset.

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:

I've also been looking for a reliable JTAG adapter for FPGA configuration for the WTFPGA workshop I've been doing at some conferences. Thanks to some open source developers, there's an alternative to the pricey Xilinx Platform Cables that works with the native configuration tool. I followed the same process that Colin O'Flynn did for the older FT2232D:

The Shikra for SPI:

Embedded devices can add a few bytes to a few megabytes of storage for under a dollar with a tiny 8-pin SPI flash chip. There are also SPI network adapters, A/D converters, and all sorts of other devices, but the firmware on SPI flash chips is usually what's most interesting.(For more interesting devices that SPI can be found in, see the Xipiter talk "Hardware Hacking for Software People").

Where the BusPirate took ~30 minutes to extract a 4MB firmware image from a device, the Shikra took less than a minute!

A DediProg SF-100 Flash Programmer in the Xipiter lab.

One exercise we have in SexViaHex is to pull off the full firmware image from an embedded device. We use a clip like a Pomona 5250to directly contact the 8-pin SOIC chip's pins without having to desolder, and then we use the bus pirate and Flashrom to 'quickly' dump a 4MB firmware in 20 minutes - if it works the first time. Specialized devices like a Dediprog SF100 (pictured to the left) would be much quicker, but are a bit to large and expensive for us to buy 30 to put into our student kits for SexViaHex. Luckily Shikra supports SPI, and flashrom supports a generic FT2232 interface, allowing firmware dumps in less than a minute.

To dump an SPI flash with the Shikra we simply:$ flashrom -p ft2232_spi:type=232H -r spidump.bin

The Shikra "un-bricking" a tablet by overwriting firmware via SPI using a 8-pin SOIC clip. The SOIC clip made this "unobtrusive" not requiring the chip to be desoldered!

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!

Download a pdf of the shikra pinouts to the left!

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:

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.

Su casa es mi casa

This first device is billed as the "most flexible, powerful and affordable home controller on the market today. No monthly fees!" Neat. Now let's see how secure it is. The product descriptions and marketing material surrounding it also give us as "security researchers" a glimpse at the capabilities of the devices and to estimate attack surface: Lots of connectivity.

the setup and the Teardown

Now that we have a general idea of attack surface, let's set it up the way a normal user would. And in the process get more information by opening it up and seeing what we can see.

The marketing material was right, setup was very simple. It consisted of you just plugging the device into your local internet router via Ethernet. You then went to a predefined web page (out on the internet) and entered the MAC Address and Serial Number of your device. But before we do this, we'll want to see what it does.

So now that we know this thing is going to be talking to the internet for first configuration, the first thing was to intercept all of it's communication with the outside world. Ben, set up a router on his Raspberry Pi to do this so that all traffic could be intercepted and watched in real time. The RaspberryPis are ideal for this kinda stuff because they are cheap enough to buy a handful of, they run Linux, they support've got built in support for a handful of USB Ethernet and Wifi Adapters, and they can be packed away [as is] for easy reuse on other projects without rebuilding. Other tools like WiFi Pineapple are slow and frankly too "abstracted".)

The SSL tools are just-in-case the device decides to try to "call home" to it's servers over SSL. If it is poorly implemented it would allow us Man In The Middle his connection and peek at what he's doing (more on this later as it is a recurring theme in many of these 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.

"Secure mode"

Ben also noticed that the device could run in "Secure Mode" which (after a little digging) Ben discovered disabled all the daemons (like the web server) running on the device's "network facing" IP.

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.

For this device, we just simply handed the interns a UART USB cable plucked from one of the SexViaHex Student kits . (No Shikra needed for this one). With a little quick help from one of the Appendices of the SexViaHex Lab Manual (for the pinouts of the UART cable) the interns were connected to the device using screen (yea, it can do serial too ;-).

It took a few guesses at baud rate but just like that, the interns had a rootshell over UART. (We have an entire unit in SexViaHex about how you calculate baud rates using a Logic Analyzer to gain interactive control of a device. We'll also demonstrate this technique on two other devices in subsequent "The Insecurity Of Things" posts).

now the we got a rootshell, let's find a remote vulnerability

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.

This is a common technique used by hardware vendors. So to "fake" a mutable filesystem they have a custom binary on the filesystem called "nvget" that fetches from NVRAM using a "key/value" scheme. Here is an example of it in use in their boot scripts.

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 now we need an "exploitation" tool: id-iot-ic

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.

with this tool, 0wning your own device is "point and click" simple. And we'll just keep adding exploit modules as we go.

It has full interactivity and "point and click" simplicity to exploit the simple (and not so simple) vulnerabilities in the devices we'll be discussing in this blog series. It is modular (uses some simple python interpreter "monkey patching" to make it so new commands/functionality can be added by just dropping files in to the "modules directory").

animated gif of idiotic 0wning the device

Conclusions

With some really dead-simple techniques this device was easily compromised. Furthermore not only can you attack your own device, but an attacker could (without purchasing a device) potentially just download the firmware image from the manufacturer (as linked from the manufacturer's wiki), extract the filesystem image using binwalk and unsquashfs, and navigate to the right directories on the filesystem to retrieve the ssh private keys used to access the manufacturers backend.

From there potentially (if SSH works the way we think it does), this key can be used to access ALL THE OTHER devices like it in the world currently connected to the internet. It should be noted that as the interns discovered these vulnerabilities in this device, they found "prior art" vulnerabilities found by D. Crowley (then of Trustwave Spider Labs) although there was no explicit mention of the ability to potentially access all the other devices via the manufacturer's servers (via the hardcoded SSH keys).

While this a simple little device, the ability to attack it on the local network and potentially reach it THROUGH the manufacturers own servers as a beachhead to other computers on your home network is a reminder of why devices like this need to be understood better.

this extracted SSH key can potentially be used to access ALL THE OTHER devices like it in the world currently connected to the internet, through the manufacturer's backend no less.

Our next targets :

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?

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.