When [gdarchen] wanted to read some NFC tags, he went through several iterations. First, he tried an Electron application, and then a client-server architecture. But his final iteration was to make a standalone reader with an Arduino and use WebUSB to connect to the application on the PC.
This sounds easy, but there were quite a few tricks required to make it work. He had to hack the board to get the NFC reader’s interrupt connected correctly because he was using a Leonardo board. But the biggest problem was enabling WebUSB support. There’s a library, but you have to change over your Arduino to use USB 2.1. It turns out that’s not hard, but there’s a caveat: Once you make this change you will need the WebUSB library in all your programs or Windows will refuse to recognize the Arduino and you won’t be able to easily reprogram it.
Once you fix those things, the rest is pretty easy. The PC side uses node.js. If you back up a level in the GitHub repository, you can see the earlier non-Arduino versions of the code, as well.
If you want to understand all the logic that went into the design, the author also included a slide show that discusses the three versions and their pros and cons. He did mention that he wanted a short-range solution so barcodes and QR codes were out. He also decided against RFID but didn’t really say why.
CVE-2019-5700 is a vulnerability in the Nvidia Tegra bootloader, discovered by [Ryan Grachek], and breaking first here at Hackaday. To understand the vulnerability, one first has to understand a bit about the Tegra boot process. When the device is powered on, a irom firmware loads the next stage of the boot process from the device’s flash memory, and validates the signature on that binary. As an aside, we’ve covered a similar vulnerability in that irom code called selfblow.
On Tegra T4 devices, irom loads a single bootloader.bin, which in turn boots the system image. The K1 boot stack uses an additional bootloader stage, nvtboot, which loads the secure OS kernel before handing control to bootloader.bin. Later devices add additional stages, but that isn’t important for understanding this. The vulnerability uses an Android boot image, and the magic happens in the header. Part of this boot image is an optional second stage bootloader, which is very rarely used in practice. The header of this boot image specifies the size in bytes of each element, as well as what memory location to load that element to. What [Ryan] realized is that while it’s usually ignored, the information about the second stage bootloader is honored by the official Nvidia bootloader.bin, but neither the size nor memory location are sanity checked. The images are copied to their final position before the cryptographic verification happens. As a result, an Android image can overwrite the running bootloader code. Continue reading “This Week In Security: Tegra Bootjacking, Leaking SSH, And StrandHogg”→
A curious custom that survives from the pre-computer era is that of the business card. If you walk the halls at a trade event you’ll come a way with a stack of these, each bearing the contact details of someone you’ve encountered, and each in a world of social media and online contact destined to languish in some dusty corner of your desk. In the 21st century, when electronic contacts harvested by a mobile phone have the sticking power, how can a piece of card with its roots in a bygone era hope to compete?
It’s a question [Anthony Kouttron] has addressed in the design of his thoroughly modern business card, and along the way he’s treated us to an interesting narrative on how to make the card both useful beyond mere contact details as well as delivering that electronic contact. The resulting card has an array of rulers and footprints as an electronic designer’s aid, as well as an NFC antenna and chip that lights an LED and delivers his website address when scanned. There are some small compromises such as PCB pads under the NFC antenna, but as he explains in the video below, they aren’t enough to stop it working. He’s put his work in a GitHub repository, should you wish to do something similar.
Does anyone remember the Black Hat BCard hack in 2018? This hack has been documented extensively, most notoriously by [NinjaStyle] in his original blog post revealing the circumstances around discovering the vulnerability. The breach ended up revealing the names, email addresses, phone numbers, and personal details of every single conference attendee – an embarrassing leak from one of the world’s largest cybersecurity conferences.
To recap: The Black Hat conference badges included an embedded NFC tag storing the participant’s contact details presumably for vendors to scan for marketing purposes. After scanning the tag, [NinjaStyle] realized that his name was readily available, but not his email address and other information. Instead, the NFC reader pointed to the BCard app – an application created for reading business cards.
[NinjaStyle] decompiled the APK for the app to search for API endpoints and found that the participants each had a custom URL made using event identification values. After finding data that appeared to correspond to an eventID and badgeID, he sent a request over a web browser and found that his attendee data was returned completely unauthenticated. With this knowledge, it was possible to brute-force the contact details for every Black Hat attendee (the range of valid IDs was between 100000-999999, and there were about 18,000 attendees). Using Burp Suite, the task would take about six hours.
He was able to get ahold of BCard to reveal the vulnerability, which was fixed in less than a day by disabling the leaky API from their legacy system. Even so, legacy APIs in conference apps aren’t an uncommon occurrence – the 2018 RSA Conference (another cybersecurity conference) also suffered from an unprotected app that allowed 114 attendee records to be accessed without permission.
With the widespread publicity of leaked attendee data, event organizers are hopefully getting smarter about the apps that they use, especially if they come from a third-party vendor. [Yashvier Kosaraju] gave a talk at TROOPERS19 about pen testing several large vendors and discovering that Kitapps (Attendify) and Eventmobi both built apps with unauthenticated access to attendee data. It’s hard to say how many apps from previous years are still around, or whether or not the next event app you use will come with authentication – just remember to stay vigilant and to not give too much of your personal data away.
Regular Hackaday readers may recall that a little less than a year ago, I had the opportunity to explore a shuttered Toys “R” Us before the new owners gutted the building. Despite playing host to the customary fixture liquidation sale that takes place during the last death throes of such an establishment, this particular location was notable because of how much stuff was left behind. It was now the responsibility of the new owners to deal with all the detritus of a failed retail giant, from the security camera DVRs and point of sale systems to the boxes of employee medical records tucked away in a back office.
Ironically, I too have been somewhat derelict in my duty to the good readers of Hackaday. I liberated several carloads worth of equipment from Geoffrey’s fallen castle with every intention of doing a series of teardowns on them, but it’s been nine months and I’ve got nothing to show for it. You could have a baby in that amount of time. Which, incidentally, I did. Perhaps that accounts for the reshuffling of priorities, but I don’t want to make excuses. You deserve better than that.
So without further ado, I present the first piece of hardware from my Toys “R” Us expedition: the VeriFone MX 925CTLS. This is a fairly modern payment terminal with all the bells and whistles you’d expect, such as support for NFC and EMV chip cards. There’s a good chance that you’ve seen one of these, or at least something very similar, while checking out at a retail chain. So if you’ve ever wondered what’s inside that machine that was swallowing up your debit card, let’s find out.
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.
NFC locks are reaching a tipping point where the technology is so inexpensive that it makes sense to use it in projects where it would have been impractical months ago. Not that practicality has any place among these pages. IKEA carries a cabinet lock for $20USD and does not need any programming but who has a jewelry box or desk drawer that could not benefit from a little extra security? Only a bit though, we’re not talking about a deadbolt here as this teardown shows.
Rothult has all the stuff you would expect to find in an NFC scanner with a moving part. We find a microcontroller, RFID decoder, supporting passives, metal shaft, and a geartrain. The most exciting part is the controller which is an STM32L051K8 processor by STMicroelectronics and second to that is the AS3911 RFID reader from AMS. Datasheets for both have links in the teardown. Riping up a Rothult in the lab, we find an 25R3911B running the RFID, and we have a link to that PDF datasheet. Both controllers speak SPI.
There are a couple of things to notice about this lock. The antenna is a flat PCB-mounted with standard header pins, so there is nothing stopping us from connecting coax and making a remote antenna. The limit switches are distinct so a few dabs of solder could turn this into an NFC controlled motor driver. Some of us will rest easy when our coworkers stop kidnapping our nice pens.
Rothult first came to our attention in a Hackaday Links where a commenter was kind enough to tip us off to this teardown. Thanks, Pio! If this whets your appetite for NFC, we have more in store.