Multi Sensor Security Camera Has You Covered

August 21, 2016 by James Hobson 14 Comments

Security in the home — especially a new home — is a primary concern for many. There are many options for security systems on the market, but for those will the skills, taking matters into your own hands can add peace of mind when protected by a system of one’s own design. [Armagan C.] has created their near-ideal multi-sensor security module to keep a watchful eye out for would-be burglars.

Upgrading from their previous Arduino + Ethernet camera — which loved to trigger false alarms — [Armagan] opted for a used Raspberry Pi model B+ camera module and WiFi connection this time around. They also upgraded the unit with a thermal sensor, LPG & CO2 gas sensor, and a motion tracking alarm. [Armagan] has also set up a live streaming feature that records video in 1hr segments — deleting them daily — and circumvented an issue with file descriptor leak by using a crashed drone’s flight controller to route the sensor data via serial port. It is also proving superior to conventional alarms because the custom software negates the need to disarm security zones during midnight trips to the washroom.

Continue reading “Multi Sensor Security Camera Has You Covered” →

Universal Serial Abuse

August 17, 2016 by Jenny List 26 Comments

It’s probable that most Hackaday readers are aware of their own computer security even if they are not specialists. You’ll have some idea of which ports your machines expose to the world, what services they run, and you’ll know of a heap of possible attack vectors even if you may not know about every last one.

So as part of that awareness, it’s likely you’ll be wary of strange USB devices. If someone drops a Flash drive in the parking lot the chances of one of you blithely plugging it into your laptop is not high at all. USB ports are trusted by your computer and its operating system, and to have access to one is to be given the keys to the kingdom.

Our subject today is a DEF CON talk courtesy of [Dominic White] and [Rogan Dawes] entitled “Universal Serial aBUSe“, and it details a USB attack in which they create an innocuous USB stick that emulates a keyboard and mouse which is shared across a WiFi network via a VNC server. This gives an attacker (who can gain momentary physical access to a USB port to install the device) a way into the machine that completely bypasses all network and other security measures.

Their hardware features an AVR and an ESP8266, the former for USB and HID work and the latter to do the heavy lifting and provide WiFi. They started with a Cactus Micro Rev2, but graduated to their own compatible board to make the device more suitable to pose as a USB stick. Both hardware and software files can be found on their GitHub repository, with the software being a fork of esp-link. They go into significant detail of their development and debugging process, and their write-up should be an interesting read for anyone.

Below the break you can find a video description of the attack. It’s not a shock to know that USB ports have such little defense, but it is a sobering moment to realize how far attacks like this one have come into the realm of what is possible.

Continue reading “Universal Serial Abuse” →

The First Evil Maid-Proof Computer

August 9, 2016 by Brian Benchoff 157 Comments

It doesn’t matter how many bits your password has, how proven your encryption is, or how many TrueCrypt volumes are on your computer. If someone wants data off your device, they can get it if they have physical access to your device. This is the ‘evil maid’ security scenario, named after hotel maids on the payroll of a three-letter agency. If someone has physical access to a laptop – even for an hour or two – the data on that laptop can be considered compromised. Until now, there has been no counter to this Evil Maid scenario, and for good reason. Preventing access to data even when it is in the possession of an Evil Maid is a very, very hard problem.

Today, Design Shift has released ORWL (as in George Orwell), the first computer designed with physical security in mind. This tiny disc of a computer is designed to defeat an Evil Maid through some very clever engineering on top of encryption tools we already use.
Continue reading “The First Evil Maid-Proof Computer” →

How To Detect And Find Rogue Cell Towers

August 9, 2016 by Brian Benchoff 61 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 53 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” →