There are two sides to every coin. Instead of swiping or using a chip reader with your credit card, some companies offer wireless cards that you hold up to a reader for just an instant. How convenient for you and for anyone who might what to read that data for their own use. The same goes for RFID enabled passports, and the now ubiquitous keycards used for door access at businesses and hotels. I’m sure you can opt-out of one of these credit cards, but Gerald in human resources isn’t going to issue you a metal key — you’re stuck hauling around that RFID card.
It is unlikely that someone surreptitiously reading your card will unlock your secrets. The contactless credit cards and the keylock cards are actually calculating a response based on a stored key pair. But you absolutely could be tracked by the unique IDs in your cards. Are you being logged when passing by an open reader? And other devices, like public transit cards, may have more information stored on them that could be harvested. It’s not entirely paranoid to want to silence these signals when you’re not using them.
One solution is to all of this is to protect your wallet from would-be RFID pirates. At this point all I’m sure everyone is thinking of a tin-foil card case. Sure, that might work unless the malicious reader is very powerful. But there’s a much more interesting way to protect against this: active RFID scrambling with a project called GuardBunny. It’s a card that you place next to whatever you want to protect. It’s not really RFID — I’ll get that in a moment — but is activated the same way and spews erroneous bits back at any card reader. Kristin Paget has been working on GuardBunny for several years now. As of late she’s had less time for active development, but is doing a great thing by letting version 1 out into the world for others to hack on. In her talk at Shmoocon 2016 she walked through the design, demonstrated its functionality, and shared some suggestions for further improvement.
Continue reading “GuardBunny Active RFID Protection Going Open Hardware”
On December 2, 2015, [Syed Rizwan Farook] and [Tashfeen Malik] opened fire at a San Bernardino County Department of Public Health training event, killing 14 and injuring 22. This was the third deadliest mass shooting in the United States in recent memory, and began a large investigation by local, state, and federal agencies. One piece of evidence recovered by the FBI was an iPhone 5C belonging to one of the shooters. In the days and months after the shooting, the FBI turned to Apple to extract data from this phone.
A few days ago in an open letter to customers, [Tim Cook], CEO of Apple, stated they will not comply with FBI’s request to build a backdoor for the iPhone. While the issue at hand is extracting data from an iPhone recovered from the San Bernardino shooting, [Cook] says building a new version of iOS to extract this data would allow the FBI to unlock any iPhone. Needless to say, there are obvious security implications of this request.
Apple does not publish open letters to its customers often. Having one of the largest companies on the planet come out in support of privacy and encryption is nearly unprecedented. There is well-founded speculation this open letter to the public will be exhibit A in a supreme court case. Needless to say, the Internet has gone a little crazy after this letter was published, and rightly so: just imagine how better off we would be if AT&T said no to the NSA in 2002 – [Snowden] might just be another IT geek working for a government contractor.
There is a peculiar aspect of public discourse that doesn’t make any sense. In the absence of being able to say anything interesting, some people have just decided to add a contrary viewpoint. Being right, having a valid argument, or even having evidence to support assertions doesn’t matter; being contrary is far more interesting. Look at any comment thread on the Internet, and you’ll find the longest comment chain is the one refuting the parent article. Look up the ratings for a cable news channel. You’ll find the highest rated show is the one with the most bickering. When is the last time you saw something from the New York Times, Washington Post, or LA Times on Facebook or your favorite news aggregator? Chances are, it wasn’t news. It was an op-ed, most likely one that was espousing a view contrary to either public opinion or public policy.
As with any headline event on the Internet, the contrarians have come out of the woodwork. These contrarians are technically correct and exceedingly myopic.
Continue reading “The Contrarian Response To Apple’s Need For Encryption”
[virustracker] has been playing around with barcodes lately, and trying to use them as a vector to gain control of the system that’s reading them. It’s a promising attack — nobody expects a takeover via barcodes. The idea isn’t new, and in fact we’ve seen people trying to drop SQL attacks in barcodes long ago, but [virustracker] put a few different pieces together and came up with a viable attack.
The trick is that many POS terminals and barcode readers support command characters in their programming modes. Through use of these Advanced Data Formatting (ADF) modes, [virustracker] sends Windows-Key-r, and then cmd.exe, ftps a file down, and runs it. Whatever computer is on the other side of the barcode scanner has just been owned. ADF even supports a delay function to allow time for the command window to pop up before running the rest of the input.
The article details how they got their payload from requiring more than ten individual barcodes down to four. Still, it’s a suspicious-looking attack to try to pull off where other people (think cashiers) are looking. However, we have many automated machines in our everyday life that use barcodes. How many of these are vulnerable is an open question. [virustracker] suggests lottery machines, package-delivery automats, and even hospitals.
The defense is simple, and it’s the same as everywhere else: disable the debug and configuration modes in your production systems, and sanitize your input. Yes, even the barcodes.
The Internet of Things is slowly turning into the world’s largest crappy robot, with devices seemingly designed to be insecure, all waiting to be rooted and exploited by anyone with the right know-how. The latest Internet-enabled device to fall is a Motorola Focus 73 outdoor security camera. It’s quite a good camera, save for the software. [Alex Farrant] and [Neil Biggs] found the software was exceptionally terrible and would allow anyone to take control of this camera and install new firmware.
The camera in question is the Motorola Focus 73 outdoor security camera. This camera connects to WiFi, features full pan, tilt, zoom controls, and feeds a live image and movement alerts to a server. Basically, it’s everything you need in a WiFi security camera. Setting up this camera is simple – just press the ‘pair’ button and the camera switches to host mode and sets up an open wireless network. The accompanying Hubble mobile app scans the network for the camera and prompts the user to connect to it. Once the app connects to the camera, the user is asked to select a WiFi connection to the Internet from a list. The app then sends the security key over the open network unencrypted. By this point, just about anyone can see the potential for an exploit here, and since this camera is usually installed outdoors – where anyone can reach it – evidence of idiocy abounds.
Once the camera is on the network, there are a few provisions for firmware upgrades. Usually, firmware upgrades are available by downloading from ‘private’ URLs and sent to the camera with a simple script that passes a URL directly into the shell as root. A few facepalms later, and [Alex] and [Neil] had root access to the camera. The root password was ‘123456’.
While there’s the beginnings of a good Internet of Camera in this product, the design choices for the software are downright stupid. In any event, if you’re looking for a network camera that you own – not a company with a few servers and a custom smartphone app – this would be near the top of the list. It’s a great beginning for some open source camera firmware.
Thanks [Mathieu] for the tip.
News comes from The Guardian that the iPhone 6 will break because of software updates due to non-authorized hardware replacements. Several thousand iPhone 6 users are claiming their phones have been bricked thanks to software updates if the home button – and the integrated TouchID fingerprint sensor – were replaced by non-Apple technicians.
For the last few iPhone generations, the TouchID fingerprint sensor has been integrated into the home button of every iPhone. This fingerprint sensor provides an additional layer of security for the iPhone, and like everything on smartphones, there is a thriving market of companies who will fix broken phones. If you walk into an Apple store, replacing the TouchID sensor will cost about $300. This part is available on Amazon for about $10, and anyone with a pentalobe screwdriver, spudger, and fine motor control can easily replace it. Doing so, however, will eventually brick the phone, as software updates render the device inoperable if the TouchID sensor is not authorized by Apple.
According to an Apple spokeswoman, the reason for the error 53 is because the fingerprint data is uniquely paired to the touch ID sensor found in the home button. If the TouchID sensor was substituted with a malicious TouchID sensor, complete and total access to the phone would be easy, providing a forehead-slapping security hole. Error 53 is just Apple’s way of detecting devices that were tampered with.
In fairness to Apple, not checking the authenticity of the touch ID would mean a huge security hole; if fingerprint data is the only thing keeping evil balaclava-wearing hackers out of your phone, simply replacing this sensor would grant them access. While this line of reasoning is valid, it’s also incredibly stupid: anyone can get around the TouchID fingerprint sensor with a laser printer and a bit of glue. If you ever get ahold of the German Defense Minister’s iPhone, the fingerprint sensor isn’t going to stop you.
This is a rare case where Apple are damned if they do, damned if they don’t. By not disabling the phone when the TouchID sensor is replaced, all iPhones are open to a gaping security hole that would send the Internet into a tizzy. By bricking each and every iPhone with a replacement TouchID sensor, Apple gets a customer support nightmare. That said, the $300 replacement cost for the TouchID sensor will get you a very nice Android phone that doesn’t have this problem.
[menkveldj] built a service that encrypts files which self destruct in 24 hours. The download link can only be used once. If the wrong people were to get the link and download the file, they’d need many years on a pretty powerful computer to crack the 256AES encryption.
The sender shares a file that is encrypted client side using a password generated Pbkdf2 key to encrypt the data before uploading it to the s3 storage service. The sender is then provided the one-time-use link to share with the recipient. After the first download, or 24 hours, the link and the encrypted file are both deleted. The receiver must enter the same password to decrypt and recover the file. No one but the sharer and receiver know what the actual file is.
It’s still work in progress, so chime in with your comments and suggestions. To dig into the code, check out his repository on Github, which also has instructions to build and run it if you’d like to do your own version.
Oh, and you’ll like this. If want to thumb your nose at the powers that be, the site has a redirect for the whimsical domain: NSAfu.com.
Security researchers can be a grim crowd. Everything, when looked at closely enough, is insecure at some level, and this leads to a lot of pessimism in the industry. So it’s a bit of a shock to see a security report that’s filled with neither doom nor gloom.
We’d previously covered Somerset Recon’s initial teardown of “Hello Barbie” and were waiting with bated breath for the firmware dump and some real reverse engineering. Well, it happened and basically everything looks alright (PDF report). The Somerset folks desoldered the chip, dumped the flash ROM, and when the IDA-dust settled, Mattel used firmware that’s similar to what everyone else uses to run Amazon cloud service agents, but aimed at the “toytalk.com” network instead. In short, it uses a tested and basically sound firmware.
The web services that the creepy talking doll connected to were another story, and were full of holes that were being actively patched throughout Somerset’s investigation, but we were only really interested in the firmware anyway, and that looked OK. Not everything is horror stories in IoT security. Some stories do have a happy ending. Barbie can sleep well tonight.