Pwning With Sewing Needles

If you don’t have root, you don’t own a device, despite what hundreds of Internet of Things manufacturers would tell you. Being able to access and write to that embedded Linux system in your new flashy gadget is what you need to truly own a device, and unfortunately this is a relatively uncommon feature. At this year’s DEF CON, [Brad Dixon] unveiled a technique that pwns a device using only a sewing needle, multimeter probe, or a paperclip. No, it won’t work on every device, and the devices this technique will work with are poorly designed. That doesn’t mean it doesn’t work, and that doesn’t mean the Pin2Pwn technique isn’t useful, though.

The attack relies on how an embedded Linux device boots. All the software needed to load Linux and the rest of the peripheral magic is usually stored on a bit of Flash somewhere on the board. By using a pin, probe, or paperclip to short two data pins, or two of the latch pins on this memory chip, the bootloader will fail, and when that happens, it may fall back to a uboot prompt. This pwns the device.

There are a few qualifications for this Pwn using a pin. If the device has JTAG, it doesn’t matter – you can already own the device. If, however, a device has a locked-down JTAG, unresponsive serial ports, or even their own secure boot solution, this technique might work.

Two data pins on a TSSOP Flash shorted by a multimeter probe
Two data pins on a TSSOP Flash shorted by a multimeter probe

This exploit works on the property of the bootloader. This bit of code first looks at a piece of Flash or other memory separate from the CPU and loads whatever is there. [Brad] found a few devices (mostly LTE routers) that would try to load Linux from the Flash, fail, try to load Linux again, fail, and finally drop to a uboot prompt.

As with any successful exploit, an equally effective mitigation strategy must be devised. There are two ways to go about this, and in this case, the software side is much better at getting rid of this attack than the hardware side.

Since this attack relies on the software falling back to uboot after an unsuccessful attempt at whatever it should be booting, the simplest and most effective mitigation technique is simply rebooting the device if the proper firmware can’t be found. Having a silent serial console is great, but if the attack relies on falling back to uboot, simply not doing that will effectively prevent this attack.

The hardware side is a little simpler than writing good firmware. Instead of using TSSOP and SOIC packages for storing the device firmware, use BGAs. Hide the pins and traces on an inner layer of the board. While this isn’t a foolproof way of preventing the attack – there will always be someone with a hot air gun, magnet wire, and a steadier hand than you – it’s hard to glitch a data line with a sewing needle if you can’t see the data line.

The Terrible Security Of Bluetooth Locks

Bluetooth devices are everywhere these days, and nothing compromises your opsec more than a bevy of smartphones, smart watches, fitbits, strange electronic conference badges, and other electronic ephemera we adorn ourselves with to make us better people, happier, and more productive members of society.

Bluetooth isn’t limited to wearables, either; deadbolts, garage door openers, and security systems are shipping with Bluetooth modules. Manufacturers of physical security paraphernalia are wont to add the Internet of Things label to their packaging, it seems. Although these devices should be designed with security in mind, most aren’t, making the state of Bluetooth smart locks one of the most inexplicable trends in recent memory.

At this year’s DEF CON, [Anthony Rose] have given a talk on compromising BTLE locks from a quarter-mile away. Actually, that ‘quarter mile’ qualifier is a bit of a misnomer – some of these Bluetooth locks are terrible locks, period. The Kwikset Kevo Doorlock – a $200 deadbolt – can be opened with a flathead screwdriver. Other Bluetooth ‘smart locks’ are made of plastic.

The tools [Anthony] used for these wireless lockpicking investigations included the Ubertooth One, a Bluetooth device for receive-only promiscuous sniffing, a cantenna, a Bluetooth USB dongle, and a Raspberry Pi. This entire setup can be powered by a single battery, making it very stealthy.

The attacks on these Bluetooth locks varied, from sniffing the password sent in plain text to the lock (!), replay attacks, to more advanced techniques such as decompiling the APK used to unlock these smart locks. When all else fails, brute forcing locks works surprisingly well, with quite a few models of smart lock using eight digit pins. Even locks with ‘patented security’ (read: custom crypto, bad) were terrible; this patented security was just an XOR with a hardcoded key.

What was the takeaway from this talk? Secure Bluetooth locks can be made. These locks use proper AES encryption, a truly random nonce, two factor authentication, no hard-coded keys, allow the use of long passwords, and cannot be opened with a screwdriver. These locks are rare. Twelve of the sixteen locks tested could be easily broken. The majority of Bluetooth smart locks are not built with security in mind, which, by the way, is the entire point of a lock.

[Anthony]’s work going forward will concentrate expanding his library of scripts to exploit these locks, and evaluate the Bluetooth locks on ATMs. Yes, ATMs also use Bluetooth locks. The mind reels.

Microsoft Live Account Credentials Leaking From Windows 8 And Above

Discovered in 1997 by Aaron Spangler and never fixed, the WinNT/Win95 Automatic Authentication Vulnerability (IE Bug #4) is certainly an excellent vintage. In Windows 8 and 10, the same bug has now been found to potentially leak the user’s Microsoft Live account login and (hashed) password information, which is also used to access OneDrive, Outlook, Office, Mobile, Bing, Xbox Live, MSN and Skype (if used with a Microsoft account).

Continue reading “Microsoft Live Account Credentials Leaking From Windows 8 And Above”

LastPass Happily Forfeits Passwords to Simple Javascript

Lastpass is a great piece of software when it comes to convenience, but a recent simple hack shows just how insecure software like it can be. [Mathias Karlsson] nabbed a nice $1000 bounty for its discovery.

Lastpass’s auto-fill works by injecting some html into the website you’re visiting. It runs a bit of Javascript to parse the URL. However, the parsing script was laughably vague. By changing the URL of the page, inserting a few meaningless-to-the server slugs into the URL, an attacker could get Lastpass to give it a password and username combo for any website.

The discussion in the HackerNews comment section more-or-less unilaterally agreed that most systems like this have their glaring flaws, but that the overall benefits of having secure passwords generated and managed by software was still worth the risk when compared to having a few commonly reused passwords over multiple sites.

One could get a more secure key manager by using software like KeePass, but it’s missing some of the convenience factor of remote-based services and relies on a user protecting their key files adequately.

Still, as scary as they are, openly discussing hacks like this after responsible disclosure is good because they force companies like Lastpass, who have some very big name clients, to take their code review and transparency more seriously.

BitCluster Brings a New Way to Snoop Through BitCoin Transactions

Mining the wealth of information in the BitCoin blockchain is nothing new, but BitCluster goes a long way to make sense of the information you’ll find there. The tool was released by Mathieu Lavoie and David Decary-Hetu, PH.D. on Friday following their talk at HOPE XI.

I greatly enjoyed sitting in on the talk which began with some BitCoin basics. The cryptocurrency uses user generated “wallets” which are essentially addresses that identify transactions. Each is established using key pairs and there are roughly 146 million of these wallets in existence now

If you’re a thrifty person you might think you can get one wallet and use it for years. That might be true of the sweaty alligator-skin nightmare you’ve had in your back pocket for a decade now. It’s not true when it comes to digital bits —  they’re cheap (some would say free). People who don’t generate a new wallet for every transaction weaken their BitCoin anonymity and this weakness is the core of BitCluster’s approach.

Every time you transfer BitCoin (BTC) you send the network the address of the transaction when you acquired the BTCs and sign it with your key to validate the data. If you reuse the same wallet address on subsequent transactions — maybe because you didn’t spend all of the wallet’s coins in one transaction or you overpaid and have the change routed back to your wallet. The uniqueness of that signed address can be tracked across those multiple transactions. This alone won’t dox you, but does allow a clever piece of software to build a database of nodes by associating transactions together.

Mathieu’s description of first attempts at mapping the blockchain were amusing. The demonstration showed a Python script called from the command line which started off analyzing a little more than a block a second but by the fourth or fifth blocks hit the process had slowed to a standstill that would never progress. This reminds me of some of the puzzles from Project Euler.

bitcluster-how-it-worksAfter a rabbit hole of optimizations the problem has been solved. All you need to recreate the work is a pair of machines (one for Python one for mondoDB) with the fastest processors you can afford, a 500 GB SSD, 32 GB of RAM (but would be 64 better), Python 64-bit, and at least a week of time. The good news is that you don’t have to recreate this. The 200GB database is available for download through a torrent and the code to navigate it is up on GitHub. Like I said, this type of blockchain sleuthing isn’t new but a powerful open source tool like this is.

Both Ransomware and illicit markets can be observed using this technique. Successful, yet not-so-cautious ransomers sometimes use the same BitCoin address for all payments. For example, research into a 2014 data sample turned up a ransomware instance that pulled in $611k (averaging $10k per day but actually pulling in most of the money during one three-week period). If you’re paying attention you know using the same wallet address is a bad move and this ransomware was eventually shut down.

Illicit markets like Silk Road are another application for BitCluster. Prior research methods relied on mining comments left by customers to estimate revenue. Imagine if you had to guess at how well Amazon was doing reading customer reviews and hoping they mentioned the price? The ability to observe BTC payment nodes is a much more powerful method.

A good illicit market won’t use just one wallet address. But to protect customers they use escrow address and these do get reused making cluster analysis possible. Silk Road was doing about $800k per month in revenue at its height. The bulk of purchases were for less than $500 with only a tiny percentage above $1000. But those large purchases were likely to be drug purchases of a kilo or more. That small sliver of total transactions actually added up to about a third of the total revenue.

bitcluster-logoIt’s fascinating to peer into transactions in this manner. And the good news is that there’s plenty of interesting stuff just waiting to be discovered. After all, the blockchain is a historical record so the data isn’t going anywhere. BitCluster is intriguing and worth playing with. Currently you can search for a BTC address and see total BTC in and out, then sift through income and expense sorted by date, amount, etc. But the tool can be truly great with more development. On the top of the wishlist are automated database updates, labeling of nodes (so you can search “Silk Road” instead of a numerical address), visual graphs of flows, and a hosted version of the query tool (but computing power becomes prohibitive.)

Bunnie and Snowden Explore iPhone’s Hackability

[Bunnie Huang] and [Edward Snowden] have teamed up to publish a paper exploring the possibility of introspection on the iPhone.

A rendering of the proposed introspection device attached to an iPhone6
A rendering of the proposed introspection device attached to an iPhone6

The idea is that phones are increasingly complex and potentially vulnerable to all kinds of digital surveillance. Even airplane mode is insufficient for knowing that your phone isn’t somehow transmitting information. The paper looks at the various radios on the iPhone, going so far as opening up the device and reading signals at each of the chips for cell, WiFi, Bluetooth, GPS, and NFC to determine whether the chip itself is doing anything, regardless of what the screen says. This introspection can then be used to be confident that the phone is not communicating when it shouldn’t be.

The paper goes on to propose a device that they will prototype in the coming year which uses an FPC that goes into the phone through the SIM card port. It would contain a battery, display, buttons, multiple SIM cards, and an FPGA to monitor the various buses and chips and report on activity.

Significant hacking of an iPhone will still be required, but the idea is to increase transparency and be certain that your device is only doing what you want it to.

Bunnie and EFF Sue US Government over DMCA 1201

This morning Bunnie Huang wrote about his reasons for suing the US Government over Section 1201 of the Digital Millennium Copyright Act (DMCA).

The DMCA was enacted in 1996 and put in place far-reaching protections for copyright owners. Many, myself included, think these protections became far-overreaching. The DMCA, specifically section 1201 of the act which is known as the anti-circumvention provision, prohibits any action that goes around mechanisms designed to protect copyrighted material. So much has changed since ’96 — software is now in every device and that means section 1201 extends to almost all electronics sold today.

So protecting copyright is good, right? If that were the only way section 1201 was enforced that might be true. But common sense seems to have gone out the window on this one.

If you legally purchase media which is protected with DRM it is illegal for you to change the format of that media. Ripping your DVD to a digital file to view on your phone while on the plane (something usually seen as fair use) is a violation. Want to build an add-on for you home automation system but need to reverse engineer the communications protocol first? That’s a violation. Perhaps the most alarming violation: if you discover a security vulnerability in an existing system and report it, you can be sued under DMCA 1201 for doing so.

Cory Doctorow gave a great talk at DEF CON last year about the Electronic Frontier Foundation’s renewed push against DMCA 1201. The EFF is backing Bunnie on this lawsuit. Their tack argues both that section 1201 is stiffling innovation and discouraging meaningful security research.

If it’s illegal to write about, talk about, or even privately explore how electronics are built (and the ecosystem that lets them function) it’s hard to really master creating new technology. A successful lawsuit must show harm. Bunnie’s company, Alphamax LLC, is developing hardware that can add an overlay to an HDMI signal (which sounds like the continuation of the hack we saw from him a few years ago). But HDCP would prevent this.

Innovation aside, the security research angle is a huge reason for this law (or the enforcement of it) to change. The other plaintiff named in the suit, Matthew Green, had to seek an exemption from the DMCA in order to conduct his research without fear of prosecution. Currently there is a huge disincentive to report or even look for security vulnerabilities, and that is a disservice to all. Beneficial security research and responsible disclosure need to be the top priority in our society which is now totally dependent on an electronically augmented lifestyle.