Hacking The IM-ME To Open Garages

If you have a wireless controlled garage door, a child’s toy can wirelessly open it in a few seconds. [Samy Kamkar] is a security researcher who likes to”think bad, do good”. He’s built OpenSesame, a device that can wirelessly open virtually any fixed-code garage door in seconds, exploiting a new attack he’s discovered in wireless fixed-pin devices, using the Mattel IM-ME toy.

The exploit works only on a gate or garage which uses “fixed codes”. To prevent this type of attack, all you need to do is to upgrade to a system which uses rolling codes, hopping codes, Security+ or Intellicode. These are not foolproof from attack, but do prevent the OpenSesame attack along with other traditional brute forcing attacks. It seems there are at least a couple of vendors who still have such vulnerable products, as well as several more whose older versions are affected too.

Before you read further, a caveat – the code released by [Samy] is intentionally bricked to prevent it from being abused. It might work, but just not quite. If you are an expert in RF and microcontrollers, you could fix it, but then you wouldn’t need his help in the first place, would you?

The IM-ME is a defunct toy and Mattel no longer produces it, but it can be snagged from Amazon or eBay if you’re lucky. The Radica Girltech IM-ME texting toy has been extensively hacked and documented. Not surprising, since it sports a TI CC1110 sub-GHz RF chip, an LCD display, keyboard, backlight, and more.  A good start point is the GoodFET open-source JTAG adapter, followed by the work of [Travis Godspeed] , [Dave] and [Michael Ossmann].

One issue with fixed code systems is their limited key space. For example, a remote with 12 binary dip switches supports 12 bits of possible combinations. Since its binary and 12 bits long, that’s 2^12, which is 4096 possible combinations. With a bit of math, [Samy] shows that it takes 29 minutes to open an (8-12)-bit garage, assuming you know the frequency and baud rate, both of which are pretty common. If you have to attempt a few different frequencies and baud rates, then the time it takes is a multiple of 29 minutes. If you don’t transmit the codes multiple times, and remove the pauses in between codes, the whole exercise can be completed in 3 minutes.

The weak link in the hardware is how the shift registers which decode the received codes work. Each bit is loaded in the register sequentially, gradually moving as additional bits come in and push the previous ones. This, and using an algorithm [Samy] wrote based on the De Bruijn sequence, the whole brute force attack can be completed in just over 8 seconds. OpenSesame implements this algorithm to produce every possible overlapping sequence of 8-12 bits in the least amount of time.

You can take a look at understanding how the code works by checking it out on Github. [Samy] loves doing such investigative work – check out his combo lock code breaker we featured recently, the scary, keyboard sniffing wall wart and the SkyJack – a drone to hack all drones.

Continue reading “Hacking The IM-ME To Open Garages”

Hard Drive Rootkit Is Frighteningly Persistent

There are a lot of malware programs in the wild today, but luckily we have methods of detecting and removing them. Antivirus is an old standby, and if that fails you can always just reformat the hard drive and wipe it clean. That is unless the malware installs itself in your hard drive firmware. [MalwareTech] has written his own frightening proof of concept malware that does exactly this.

The core firmware rootkit needs to be very small in order to fit in the limited memory space on the hard drive’s memory chips. It’s only a few KB in size, but that doesn’t stop it from packing a punch. The rootkit can intercept any IO to and from the disk or the disk’s firmware. It uses this to its advantage by modifying data being sent back to the host computer. When the computer requests data from a sector on the disk, that data is first loaded into the disk’s cache. The firmware can modify the data sitting in the cache before notifying the host computer that the data is ready. This allows the firmware to trick the host system into executing arbitrary code.

[MalwareTech] uses this ability to load his own custom Windows XP bootkit called TinyXPB. All of this software is small enough to fit on the hard drive’s firmware. This means that traditional antivirus cannot detect its presence. If the owner of the system does get suspicious and completely reformats the hard drive, the malware will remain unharmed. The owner cannot even re-flash the firmware using traditional methods since the rootkit can detect this and save itself. The only way to properly re-flash the firmware would be to use an SPI programmer, which would be too technical for most users.

There are many more features and details to this project. If you are interested in malware, the PDF presentation is certainly worth a read. It goes much more in-depth into how the malware actually works and includes more details about how [MalwareTech] was able to actually reverse engineer the original firmware. If you’re worried about this malicious firmware getting out into the wild, [MalwareTech] assures us that he does not intend to release the actual code to the public.

The Ease of Adding Trojans to Major Financial Android Apps

This was both an amusing and frightening talk. [Sam Bowne] presented How to Trojan Financial Android Apps on Saturday afternoon at the LayerOne Conference. [Sam] calculates that 80-90% of the apps provided by major financial institutions like banks and investment companies are vulnerable and the ease with which trojans can be rolled into them is incredible.

Some Background

[Sam] did a great job of concisely describing the circumstances that make Android particularly vulnerable to the attacks which are the subject of the talk. Android programs are packaged as APK files which are easy to unpack. The “compiled” code itself is called smali and is readable in a similar way as Java. It’s super easy to unpack and search this byte code using grep. Once the interesting parts are located, the smali code can be altered and the entire thing can be repackaged. The app will need to be resigned but Google doesn’t control the signing keys so an attacker can simply generate a new key and use that to sign the app. The user still needs to install the file, but Android allows app installation from webpages, email, etc. so this isn’t a problem for the bad guys either.

The Attack

So what can be done? This is about information harvesting. [Sam’s] proof of concept uses a python script to insert logging for every local variable. The script looks at the start of every module in the smali code, grabs the number of local variables, increments it by one and uses this extra variable to write out the values through logcat.

ADB Log shows the Credit Card Number

He demonstrated live on the Bank of America app. From the user side of things it looks exactly like the official app, because it is the official app. However, when you register your account the log reports the card number as you can see here. Obviously this information could easily be phoned-home using a number of techniques.

As mentioned, the vast majority of banking and financial apps are vulnerable to this, but some have made an attempt to make it more difficult. He found the Bancorp app never exposes this information in local variables so it can’t just be logged out. However, the same trojan technique works as a keylogger since he found the same function kept getting called every time a key is pressed. The same was true of the Capital One app, but it echos out Google’s Android keymap values rather than ascii; easy enough to translate back into readable data though.

The Inability to Report Vulnerabilities

bowne-schwab-twitter-security-reportWhat is the most troubling is that none of these companies have a means of reporting security vulnerabilities. It was amusing to hear [Sam] recount his struggle to report these issues to Charles Schwab. Online contact forms were broken and wouldn’t post data and several publicly posted email addresses bounced email. When he finally got one to accept the email he later discovered another user reporting on a forum that nobody ever answers back on any of the Schwab accounts. He resorted to a trick he has used many times in the past… Tweeting to the CEO of Charles Schwab to start up a direct-message conversation. This itself is a security problem as @SwiftOnSecurity proves by pointing out that whenever @SamBowne Tweets a CEO it’s because he found a vulnerability in that company’s platform and can’t find a reasonable way to contact the company.

There is Hope

Although very rare, sometimes these apps do get patched. The Trade King app was updated after his report and when [Sam] tried the exploit again it crashes at start-up. The log reports a verification failure. This indicates that the injected code is being noticed, but [Sam] wonders if the verification is included in the app itself. If it is, then it will be possible to track it down and disable it.

This may sound like all of us Android users should despair but that’s not the case. Adding verification, even if it’s possible to defeat it, does make the apps safer; attackers may not want to invest the extra time to try to defeat it. Also, there are obsfucators available for a few thousand dollars that will make these attacks much more difficult by making variable names unreadable. The free obsfucator available now with the Android development suites doesn’t change names of everything… local variables are left unaltered and programmers have a habit of using descriptive names for variables. For instance, BofA used “CARDNUM” in the example above.

The Slides

[Sam Bowne’s] slides and testing results for the entire talk are available under the “Upcoming Events” part of his website.

See You at LayerOne this Weekend

LayerOne, the first level of security. [Brian Benchoff] and I are excited to take part in our first LayerOne conference this Saturday and Sunday in Monrovia California.

Anyone in the Los Angeles area this weekend needs to get out of whatever they have planned and try out this conference that has a soul. Get the idea of a mega-con out of your head and envision a concord of highly skilled and fascinating hackers gathering to talk all things computer security. Speakers will cover topics like researching 0day exploits, copying keys from pictures taken in public, ddos attacks, social engineering, and more.

It’s not just talks, there is a ton of hands-on at LayerOne as well. I plan to finally try my hand at lock picking. Yep, I’ve covered it multiple times and we’ve even had a session led by [Datagram] at the Hackaday 10th Anniversary but I’ve never found time to give it a roll. Of course electronics are my game and [Brian] and I will both be spending a fair amount of time in the hardware hacking village. We’ll have a bunch of dev boards along with us if you want to try out an architecture with which you’re unfamiliar. This year’s LayerOne badges are sponsored by Supplyframe; we’ll have something in store for the best badge hacks we see during the weekend.

See you there!

Hacking a Thin Client to Gain Root Access

[Roberto] recently discovered a clever way to gain root access to an HP t520 thin client computer. These computers run HP’s ThinPro operating system. The OS is based on Linux and is basically just a lightweight system designed to boot into a virtual desktop image loaded from a server. [Roberto’s] discovery works on systems that are running in “kiosk mode”.

The setup for the attack is incredibly simple. The attacker first stops the virtual desktop image from loading. Then, the connection settings are edited. The host field is filled with garbage, which will prevent the connection from actually working properly. The real trick is in the “command line arguments” field. The attacker simply needs to add the argument “&& xterm”. When the connection is launched, it will first fail and then launch the xterm program. This gives the attacker a command shell running under the context of whichever user the original software is running as.

The next step is to escalate privileges to root. [Roberto] discovered a special command that the default user can run as root using sudo. The “”hpobl” command launches the HP Easy Setup Wizard. Once the wizard is opened, the attacker clicks on the “Thank You” link, which will then load up the HP website in a version of Firefox. The final step is to edit Firefox’s default email program association to xterm. Now when the attacker visits an address like “mailto:test@test.com”, Firefox (running as root) launches xterm with full root privileges. These types of attacks are nothing new, but it’s interesting to see that they still persist even in newer software.

Race Conditions Exploit Granted Free Money on Web Services

[Josip] has been playing around with race conditions on web interfaces lately, finding vulnerabilities on both Facebook and Digital Ocean. A race condition can occur when a piece of software processes multiple threads using a shared resource.

For example, [Josip] discovered that he was able to manipulate page reviews using just a single Facebook account. Normally, a user is permitted to leave just one review for any given Facebook page. This prevents a single user from being able to skew the page’s overall ranking by making a bunch of positive or negative reviews. The trick to manipulating the system was to intercept the HTTP request that submitted the page review. The request was then replayed over and over in a very short amount of time.

Facebook’s servers ended up processing some of these requests simultaneously, essentially unaware that multiple requests had come in so close together. The result was that multiple reviews were submitted, artificially changing the pages overall ranking even though only one review actually showed up on the page for this user. The user can then delete their single review, and repeat this cycle over and over. It took Facebook approximately two months to fix this vulnerability, but in the end it was fixed and [Josip] received a nice bounty.

The Digital Ocean hack was essentially the exact same process. This time instead of hacking page reviews, [Josip] went after some free money. He found that he was able to submit the same promotional code multiple times, resulting in a hefty discount at checkout time. Digital Ocean wasted no time fixing this bug, repairing it within just ten days of the disclosure.

D-Link Fails at Strings

Small Office and Home Office (SOHO) wireless routers have terrible security. That’s nothing new. But it is somewhat sad that manufacturers just keep repurposing the same broken firmware. Case in point: D-Link’s new DIR-890L, which looks like a turtled hexapod. [Craig] looked behind the odd case and grabbed the latest firmware for this device from D-Link’s website. Then he found a serious vulnerability.

D-Link's DIR-890 Router

The usual process was applied to the firmware image. Extract it, run binwalk to find the various contents of the firmware image, and then extract the root filesystem. This contains all the code that runs the router’s various services.

The CGI scripts are an obvious place to poke for issues. [Colin] disassembled the single executable that handles all CGI requests and started looking at the code that handles Home Network Administration Protocol (HNAP) requests. The first find was that system commands were being built using HNAP data. The data wasn’t being sanitized, so all that was needed was a way to bypass authentication.

This is where D-Link made a major error. They wanted to allow one specific URL to not require authentication. Seems simple, compare string A to string B and ensure they match. But they used the strstr function. This will return true if string A contains string B. Oops.

So authentication can be bypassed, telnetd can be started, and voila: a root shell on D-Link’s most pyramid-shaped router. Oh, and you can’t disable HNAP. May we suggest OpenWrt or dd-wrt?