How To Build A ProxyHam Despite A Cancelled DEFCON Talk

July 14, 2015 by Brian Benchoff 196 Comments

A few days ago, [Ben Caudill] of Rhino Security was scheduled to give a talk at DEFCON. His project, ProxyHam, is designed for those seeking complete anonymity online. Because IP addresses can be tied to physical locations, any online activities can be tracked by oppressive regimes and three letter government agencies. Sometimes, this means doors are breached, and “seditious” journalists and activists are taken into custody.

With the ProxyHam, the link between IP addresses and physical locations is severed. ProxyHam uses a 900MHz radio link to bridge a WiFi network over miles. By hiding a ProxyHam base station in a space with public WiFi, anyone can have complete anonymity online; if the government comes to take you down, they’ll first have to stop at the local library, Starbucks, or wherever else has free WiFi.

[Ben Caudill] will not be giving a talk at DEFCON. It wasn’t the choice of DEFCON organizers to cancel the talk, and it wasn’t his employers – [Ben] founded and is principal consultant at Rhino Security. The talk has been killed, and no one knows why. Speculation ranges from National Security Letters to government gag orders to a far more pedestrian explanations like, “it doesn’t work as well as intended.” Nevertheless, the details of why the ProxyHam talk was cancelled will never be known. That doesn’t mean this knowledge is lost – you can build a ProxyHam with equipment purchased from Amazon, Newegg, or any one of a number of online retailers.

Continue reading “How To Build A ProxyHam Despite A Cancelled DEFCON Talk” →

True Random Number Generator For A True Hacker

June 29, 2015 by Voja Antonic 103 Comments

How can you generate random bits? Some people think it’s not easy, others will tell you that it’s pretty damn hard, and then there are those who wonder if it is possible at all. Of course, it is easy to create a very long pseudorandom sequence in software, but even the best PRNG (Pseudorandom Number Generator) needs a good random seed, as we don’t want to get the same sequence each time we switch on the unit, do we? That’s why we need a TRNG (True Random Number Generator), but that requires special hardware.

Some high-end microprocessors are equipped with an internal hardware TRNG, but it is, unfortunately, not true for most low-cost microcontrollers. There are a couple of tricks hackers use to compensate. They usually start the internal free running counter and fetch its contents when some external event occurs (user presses a button, or so). This works, but not without disadvantages. First, there is the danger of “locking” those two events, as a timer period may be some derivative of input scan routine timing. Second, the free running time (between switching on and the moment the unit requests a random number) is often too short, resulting in the seed being too close to the sequence start, and thus predictable. In some cases even, there is no external input before the unit needs a random seed!

Despite what has already been discussed, microcontrollers do have a source of true randomness inside them. While it might not be good enough for crypto applications, it still generates high enough entropy for amusement games, simulations, art gadgets, etc.

Continue reading “True Random Number Generator For A True Hacker” →

Code So Sneaky You Have To Explain It

June 15, 2015 by Mike Szczys 47 Comments

Your mission, should you choose to accept it, is to code a program that leaks information to the user but does so in a way that can’t be discovered in a code audit. This was the challenge for the 2014 Underhanded C contest; the seventh time they’ve held the event. [Richard Mitton] took part and wrote a very entertaining entry. He didn’t win, but he did just share the details of his super-sneaky code.

The challenge set out for the Citizen-Four-like coders set up a scenario where they were writing a program for a shady company (or sketchy government entity) which makes completely secret decisions based on publicly posted social media. The twist is they were tasked with getting code past an audit that leaked the decisions made by this program to the users being secretly observed.

Above is the core trick which [Richard] used after taking inspiration from Heartbleed. The struct assignment has an off-by-one error in it which is shown corrected in the lower code block. This, used in conjunction with malloc and free, allows memory to be used under the guise of storage during the encryption process. Secretly, this same bit of memory is accessed later and leaked to the user being targeted.

Have your own Underhanded C that you’re dying to share? We want to hear about it so send us a tip!

Hacking The IM-ME To Open Garages

June 8, 2015 by Anool Mahidharia 32 Comments

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

June 8, 2015 by Rick Osgood 82 Comments

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

May 24, 2015 by Mike Szczys 17 Comments

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.

bank-of-america-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

What 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

May 22, 2015 by Mike Szczys 4 Comments

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!