Tap ‘N Ghost: A Novel Attack Against Smartphone Touchscreens

Researchers have demonstrated a new vulnerability in NFC, a feature built-in to many smartphones sold today. The vulnerability allows the attacker to to generate ‘ghost taps’ against a device, effectively allowing an attacker to tap your phone without you looking.

The 18-page paper released by a team of three researchers based out of Waseda University in Japan consists of two techniques: an attack against NFC-enabled smartphones and an attack against capacitive touchscreens. It should be noted that nearly all phones have NFC, and nearly every phone released in the last decade has a capacitive touchscreen. Vunlnerable devices include, but are not limited to the Xperia Z4, the Galaxy S6 Edge, the Galaxy S4, Aquos Zeta SH-04F, Nexus 9, and Nexus 7.

The experimental setup consists of a signal generator, high-speed bipolar amplifier, a small transformer (taken from a toy plasma ball), a copper sheet, oscilloscope with high-voltage probe, and an NFC card emulator. No other special equipment is required. When the victim places their smartphone on a table top, the phone is fingerprinted, giving the attacker the make and model of phone. A dialog box then pops up and the phone connects to a network.

This attack can be replicated by anyone, and the tools required are simple and readily available. The mitigation is to disable NFC on your phone.

Continue reading “Tap ‘N Ghost: A Novel Attack Against Smartphone Touchscreens”

This Week In Security: Baltimore, MacOS Zipfile Security, And App Store Monopolies

Baltimore. The city was breached, crippled and held for ransom. The ransomware attack was discovered on May 7th, shutting down a major portion of the city’s infrastructure. The latest news is that an NSA-written tool, EternalBlue, is responsible for the attack. Except maybe it isn’t? First off, digging back through the history of an attack is challenging. It’s often hard to determine the initial attack vector with certainty.

The “initial attack vector” is the patient zero of the attack — how the first machine was compromised. An organization generally has a firewall separating the outside internet from the internal network. Once an attacker has found a way to access a machine inside the network, the separation is not nearly so strict. This takes many forms, but the most common is phishing. Close contenders are RDP and SMB (Remote Desktop and Windows File Sharing). A report at Ars Technica indicates that the initial vector into the Baltimore network was a phishing email.

The second step to consider is what’s called “lateral movement”, which describes an attacker using the compromised machine to target other machines in the organization. Often an attacker will have an entire toolkit of exploits to attempt to compromise other machines. One of the exploits used in this case was the same exploit contained in the NSA tool, EternalBlue. A clever program called psexec is usually part of any lateral movement campaign. While the exploit associated with EternalBlue was probably used to compromise a few of the machines on the Baltimore network, placing all the blame on the shoulders of the NSA is missing the point. The tool is only a small part of this attack.

MacOS and NFS Shares Inside Zipfiles

MacOS has a sometimes irritating feature, Gatekeeper, that only allows running signed binaries by default. The point of Gatekeeper is to prevent a user from running a malicious binary that has been downloaded from the internet. While it is sometimes an annoyance, it is helpful for some users. [Filippo Cavallarin] announced an exploit that completely bypasses Gatekeeper on the 24th. This exploit takes advantage of the fact that Gatekeeper considers network shares to be trustworthy, and doesn’t run the normal check before executing a binary located there. While interesting, this isn’t useful unless there is a way for an attacker to mount a malicious location as a network share. Enter the Mac’s ability to automatically mount network locations through the use of the /net path. The last piece of this puzzle is the fact that zip files can contain symbolic links. A zip file can be built with a link to the /net location, automounting an arbitrary NFS location. If binary files are located in this location, the OS will happily allow the user to execute those binaries whether signed or not.

This exploit may not be the most serious of the year, but it’s still a problem that needs fixing. [Filippo] contacted Apple back in February and disclosed the problem, even getting an assurance that they would fix it within 90 days. 90 days have passed, and Apple has begun ignoring his emails, so he has made the announcement and published steps to reproduce on his website.

There has been discussion in the comments of this column about vulnerability disclosure and publishing proof of concept code. This is a perfect example of why researchers publish their work. As far as [Filippo] knows, Apple has no intention of fixing the issue he discovered. He also has no reason to believe that no one else has stumbled on this discovery before he did. We mentioned EternalBlue above. The NSA discovered the SMB vulnerability that exploit targeted and used it silently for up to five years before it was stolen and finally disclosed to Microsoft and fixed. Make no mistake, public disclosures and proof of concepts get vulnerabilities fixed. For any given vulnerability, there is no guarantee that someone else hasn’t already found it.

Just a Little Document Leak

OK, maybe not so little. A Fortune 500 company, First American, managed to host millions of private documents in an accessible format. Imagine you upload a document to a company, and get a confirmation link that looks like “test.com/documents.php?id=0252234”. If you’re like me, you’re very curious what is at id=0252233. [Ben Shoval] is a real estate developer who apparently also wanted to know the answer to that question. To his surprise, millions of uploaded documents were available for anyone to view. He tried reaching out to First American, and when there was no response to his emails, he forwarded his findings on to Krebs on Security. After what was likely years of exposure, the database was finally taken offline Friday the 24th.

Walled Garden Monopolies

Staying on the Apple train, the App Store is pretty obviously a monopoly. Someone has finally asked whether it’s an illegal monopoly. As most of these questions go, it’ll take a drawn out court battle to decide. How is this security news? If the court finds that Apple has been violating antitrust laws, one possible remediation is to allow alternative app stores. While there is always the potential for a high quality alternative store like F-droid, sketchy app stores and downloaded are a real possibility. On the other hand, it would be nice to have an iOS app store that is compatible with the GPL.

Fail Of The Week: How Not To Do IoT Security

There are a lot of bad days at work. Often it’s the last day, especially when it’s unexpected. For the particularly unlucky, the first day on a new job could be a bad day. But the day you find an unknown wireless device attached to the underside of your desk has to rank up there as a bad day, or at least one that raises a lot of serious questions.

As alarming as finding such a device would be, and for as poor as the chain of decisions leading these devices being attached to the workstations of the employees at a mercifully unnamed company, that’s not the story that [Erich Styger] seeks to tell. Rather, this is a lesson in teardown skills – for few among us would not channel the anger of finding something like this is into a constructively destructive teardown – and an investigation into the complete lack of security consideration most IoT devices seem to be fielded with these days.

Most of us would recognize the device as some kind of connected occupancy sensor; the PIR lens being the dead giveaway there. Its location under a single person’s desk makes it pretty clear who’s being monitored.

The teardown revealed that the guts of the sensor included a LoRa module, microcontroller, a humidity/temperature sensor, and oddly for a device apparently designed to stick in one place with magnets, an accelerometer. Gaining access to the inner workings was easy through the UART on the microcontroller, and through the debug connectors and JTAG header on the PCB. Everything was laid out for all to see – no firmware protection, API keys in plain text, and trivially easy to reflash. The potential for low-effort malfeasance by a compromised device designed to live under a desk boggles the mind.

The whole article is worth a read, if only as a lesson in how not to do security on IoT devices. We know that IoT security is hard, but that doesn’t make it optional if you’re deploying out in the big wide world. And there’s probably a lot to learn about properly handling an enterprise rollout too. Spoiler alert: not like this.

This Week In Security: Zombieload, And Is Your Router Leaking?

Do you know what your router is doing? We have two stories of the embedded devices misbehaving. First, Linksys “Smart” routers keep track of every device that connects to its network. Right, so does every other router. These routers, however, also helpfully expose that stored data over JNAP/HNAP.

Some background is needed here. First, HNAP is the Home Network Administration Protocol, designed to manage routers and network devices. Originally designed by Pure Networks, HNAP is a SOAP based protocol, and has been part of security problems in the past. You may also see the term JNAP. It seems that JNAP is the JSON Network Administration Protocol, identical to HNAP except for using JSON instead of SOAP.

The odd part is that this is an old problem. CVE-2014-8244 was disclosed and fixed in 2014. According to the writeup at Badpackets.net, the problem was re-discovered as a result of observing active network attacks targeting JNAP. When Linksys was informed of the rediscovered problem, they responded that the problem was fixed in 2014, and devices with updated firmware and default settings are not accessible from the public internet. The presence of over 20,000 devices leaking data casts doubt on their response. Continue reading “This Week In Security: Zombieload, And Is Your Router Leaking?”

This Week In Security: Facebook Hacked Your Email, Cyber On The Power Grid, And A Nasty Zero-day

Ah, Facebook. Only you could mess up email verification this badly, and still get a million people to hand over their email address passwords. Yes, you read that right, Facebook’s email verification scheme was to ask users for their email address and email account password. During the verification, Facebook automatically downloaded the account’s contact list, with no warning and no way to opt out.

The amount of terrible here is mind-boggling, but perhaps we need a new security rule-of-thumb for these kind of situations. Don’t ever give an online service the password to a different service. In order to make use of a password in this case, it’s necessary to handle it in plain-text. It’s not certain how long Facebook stored these passwords, but they also recently disclosed that they have been storing millions of Facebook and Instagram passwords in plain-text internally.

This isn’t the first time Facebook has been called out for serious privacy shenanigans, either: In early 2018 it was revealed that the Facebook Android app had been uploading phone call records without informing users. Mark Zuckerberg has recently outlined his plan to give Facebook a new focus on privacy. Time will tell whether any real change will occur.

Cyber Can Mean Anything

Have you noticed that “cyber” has become a meaningless buzz-word, particularly when used by the usual suspects? The Department of Energy released a report that contained a vague but interesting sounding description of an event: “Cyber event that causes interruptions of electrical system operations.” This was noticed by news outlets, and people have been speculating ever since. What is frustrating about this is the wide range of meaning covered by the term “cyber event”. Was it an actual attack? Was Trinity shutting down the power stations, or did an intern trip over a power cord?
Continue reading “This Week In Security: Facebook Hacked Your Email, Cyber On The Power Grid, And A Nasty Zero-day”

This Owner Took Control Of Their Proprietary Alarm System

When a tip comes in and the tipster feels they have to reassure us that despite appearances their subject is not facilitating crime, it certainly gets our attention. [Flam2006] has a Brinks home security system which can only be configured using a special device only available to installers, and though they managed to secure one through an eBay sale they went to the trouble of reverse engineering its protocol and writing a software emulator in Python. When an owner hacks their own security system to gain full control of something they own, that’s right up our street.

The communication is via an RS485 serial line, and follows a packetised structure with binary rather than ASCII data. There is an almost plug-and-play system for identifying devices connected to a controller, though it is restricted to those devices which the controller already knows about. There is a video of the official method of programming the controller, as well as one of the software in action. We’ve posted them below the break for your delectation.

The ability to perform these tasks on your own property is an important right that has at times been placed under threat by legislation such as the DMCA. We’ve touched upon it countless times, but probably the most high-profile example that we and the wider media have covered are those stories concerning the parts lockdown on John Deere tractors.

Continue reading “This Owner Took Control Of Their Proprietary Alarm System”

Raspberry Pi Becomes The Encrypted Password Keeper You Need

Unless you’re one of the cool people who uses the same password everywhere, you might be in need of a hardware device that keeps your usernames and passwords handy. The Passkeeper is a hardware password storage system built on a Raspberry Pi. It encrypts your passwords, and only through the magic of a special key fob will you ever get your passwords out of this device.

The hardware for this device is built around the Raspberry Pi Zero. You might be questioning the use of a Pi Zero, but given that it’s an entire Linux system for just a few bucks, it only makes sense. The rest of the hardware is a tiny OLED SPI display, an RFID card reader, a few LEDs, some wire, and some solder. A 3D printed case keeps everything together.

Of course, this build is all about the software, and for that, the Passkeeper device is built in Go, with a system that builds a web interface, builds the firmware, and writes everything to an SD card. Usage is simply plugging the Passkeeper into the USB port of your computer where it presents itself as a network interface. Everything is available by pinging an IP address, and after that the web UI will log your usernames and passwords. All this data is encrypted, and can only be unlocked if an RFID key fob is present. It’s an interesting idea and certinaly inexpensive. It’s not quite as polished as something like the Mooltipass, but if you have a Pi around and don’t have a password keeper, this is something to build this weekend.