How To Detect And Find Rogue Cell Towers

August 9, 2016 by Brian Benchoff 50 Comments

Software defined radios are getting better and better all the time. The balaclava-wearing hackers know it, too. From what we saw at HOPE in New York a few weeks ago, we’re just months away from being able to put a femtocell in a desktop computer for under $3,000. In less than a year, evil, bad hackers could be tapping into your cell phone or reading your text message from the comfort of a van parked across the street. You should be scared, even though police departments everywhere and every government agency already has this capability.

These rogue cell sites have various capabilities, from being able to track an individual phone, gather metadata about who you have been calling and for how long, to much more invasive surveillance such as intercepting SMS messages and what websites you’re visiting on your phone. The EFF calls them cell-site simulators, and they’re an incredible violation of privacy. While there was most certinaly several of these devices at DEF CON, I only saw one in a hotel room (you catchin’ what I’m throwin here?).

No matter where the threat comes from, rogue cell towers still exist. Simply knowing they exist isn’t helpful – a proper defence against governments or balaclava wearing hackers requires some sort of detection system.. For the last few months [Eric Escobar] has been working on a simple device that allows anyone to detect when one of these Stingrays or IMSI catchers turns on. With several of these devices connected together, he can even tell where these rogue cell towers are.

A Stingray / cell site simulator detector

Stingrays, IMSI catchers, cell site simulators, and real, legitimate cell towers all broadcast beacons containing information. This information includes the radio channel number, country code, network code, an ID number unique to a large area, and the transmit power. To make detecting rogue cell sites harder, some of this information may change; the transmit power may be reduced if a tech is working on the site, for instance.

To build his rogue-cell-site detector, [Eric] is logging this information to a device consisting of a Raspberry Pi, SIM900 GSM module, an Adafruit GPS module, and a TV-tuner Software Defined Radio dongle. Data received from a cell site is logged to a database along with GPS coordinates. After driving around the neighborhood with his rogue-cell-site detector sitting on his dashboard, [Eric] had a ton of data that included latitude, longitude, received power from a cell tower, and the data from the cell tower. This data was thrown at QGIS, an open source Geographic Information System package, revealing a heatmap with the probable locations of cell towers highlighted in red.

This device really isn’t a tool to detect only rogue cell towers – it finds all cell towers. Differentiating between a rogue and legitimate tower still takes a bit of work. If the heatmap shows a cell site on a fenced-off parcel of land with a big tower, it’s a pretty good bet that cell tower is legit. If, however, the heatmap shows a cell tower showing up on the corner of your street for only a week, that might be cause for alarm.

Future work on this cell site simulator detector will be focused on making it slightly more automatic – three or four of these devices sprinkled around your neighborhood would easily allow you to detect and locate any new cell phone tower. [Eric] might also tackle triangulation of cell sites with an RF-blocking dome with a slit in it revolving around the GSM900 antenna.

Pwning With Sewing Needles

August 8, 2016 by Brian Benchoff 23 Comments

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

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

August 8, 2016 by Brian Benchoff 48 Comments

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

August 2, 2016 by Moritz Walter 62 Comments

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

August 1, 2016 by Gerrit Coetzee 37 Comments

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

July 23, 2016 by Mike Szczys 8 Comments

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.

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

It’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

July 22, 2016 by Bob Baddeley 112 Comments

[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

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.

Hackaday

security hacks