This Week In Security: Hardware Attacks, IoT Security, And More

This week starts off with examinations of a couple hardware attacks that you might have considered impractical. Take a Ball Grid Array (BGA) NAND removal attack, for instance. The idea is that a NAND chip might contain useful information in the form of firmware or hard-coded secrets.

The question is whether a BGA desolder job puts this sort of approach out of the reach of most attackers. Now, this is Hackaday. We regularly cover how our readers do BGA solder jobs, so it should come as no surprise to us that less than two-hundred Euro worth of tools, and a little know-how and bravery, was all it took to extract this chip. Plop it onto a pogo-pin equipped reader, use some sketchy Windows software, and boom you’ve got firmware.

What exactly to do with that firmware access is a little less straightforward. If the firmware is unencrypted and there’s not a cryptographic signature, then you can just modify the firmware. Many devices include signature checking at boot, so that limits the attack to finding vulnerabilities and searching for embedded secrets. And then worst case, some platforms use entirely encrypted firmware. That means there’s another challenge, of either recovering the key, or finding a weakness in the encryption scheme. Continue reading “This Week In Security: Hardware Attacks, IoT Security, And More”

Put APIs To Work Wth This ArduinoJson Walkthrough

One of the things this community is famous for is the degree to which people will pitch in to fill an obvious need. Look at the vast array of libraries available for Arduino as an example of how people are willing to devote their time to making difficult tasks easier, often for little more than a virtual pat on the back.

One level up from the library writers are those who go through the trouble of explaining how all these libraries work in real-world applications. [Brian Lough] recently rose to that challenge with a thorough explanation of the use of the ArduinoJSON library, a very useful but often confusing library that makes IoT projects easier.

The need for an ArduinoJSON explainer no knock on its author, [BenoĆ®t Blanchon], who has done excellent work documenting the library; it’s more of a realization that the nature of JSON itself means a library that works with it is going to be complex. [Brian]’s contribution here is sharing his insights into getting ArduinoJSON up and running in a real-world ESP32 example, and dealing with the potential pitfalls of parsing a human-readable text file that can be used to represent almost any data object using the limited resources of a microcontroller. Along with the basics, we found the warning about how pointers refer back to the dynamic JSON document object particularly helpful; the bit about using filters to winnow down a large data set was useful too.

Thanks to [Brian] for taking the time to put this valuable information out there. Here’s hoping this encourages others to share the wealth of hard-earned knowledge in a similarly clear and concise manner.

Continue reading “Put APIs To Work Wth This ArduinoJson Walkthrough”

This Week In Security: BGP Bogons, Chrome Zero Day, And Save Game Attacks

Our own [Pat Whetman] wrote about a clever technique published by the University of Michigan, where lasers can be used to trigger a home assistant device. It’s an interesting hack, and you should go read it.

Borrowing IP Addresses

We’ve lived through several IPv4 exhaustion milestones, and the lack of available addresses is really beginning to show, even for trolls and scammers. A new approach takes advantage of the weak security of the Border Gateway Protocol, and allows bad actors to temporarily take over reserved address blocks. These particular providers operate out of Russia, operating network services they advertise as “bulletproof”, or immune to takedown requests. What better way to sidestep takedowns than to use IP addresses that aren’t really yours to begin with?

BGP spoofing has been at the center of other types of attacks and incidents, like in 2018 when a misconfiguration in a Nigerian ISP’s BGP tables routed traffic intended for Google’s servers through Chinese and Russian infrastructure. In that case it appeared to be a genuine mistake, but little prevents malicious BGP table poisoning.

Chrome Zero-day

Google released an update to Chrome on the 31st that addresses two CVEs, one of which is being actively exploited. That vulnerability, CVE-2019-13720, is a race condition resulting in a potential use-after-free. Kaspersky Labs found this one being actively used on a Korean news site. The attack runs entirely from Javascript, and simply visiting a malicious site is enough for compromise, so update Chrome if it’s installed.

Anti-anti-doping

What do you do when you feel you’ve been unfairly targeted by an anti-doping investigation? Apparently hacking the investigating agency and releasing stolen information is an option. It seems like this approach is more effective when there are shenanigans revealed in the data dump. In this case, the data being released seems rather mundane.

Firefox Blocking Sideload Extensions

Mozilla made a controversial announcement on the 31st. They intend to block “sideload” browser extensions. Until this change, it was possible to install browser extensions by copying them to a particular folder on the computer. Some legitimate extensions used this installation method, but so did malware, adware, and other unwanted software. While this change will block some malicious add-ons, it does present a bit of a challenge to a user installing an extension that isn’t on the official Mozilla store or signed by Mozilla.

As you might imagine, the response has been… less than positive. While making malware harder to install is certainly welcome, this makes some use cases very difficult. An example that comes to mind is a Linux package that includes a browser extension. It remains to be seen exactly how this change will shake out.

Save Games as Attack Vector

An oddball vulnerability caught my eye, published by [Denis Andzakovic] over at Pulse Security. He discovered that a recent indy game, Untitled Goose Game, can be manipulated into running arbitrary code as a result of loading a maliciously modified save file. The vulnerability is rooted in a naive deserialization routine.

If you’re interested in a deeper dive into .net deserialization bugs, a great paper was submitted to Blackhat 2012 discussing the topic. The short version is that if a programmer isn’t careful, the deserialization routine can overwrite variables in unexpected ways, potentially leading to code execution.

At first glance, a vulnerability triggered by a malicious save file seems relatively harmless. The level of access needed to modify a save file on a hard drive is enough to compromise that computer in a multitude of better ways. Enter cloud save synchronization. Steam, for instance, will automatically sync save games across a user’s install locations. This is a very useful feature for those of us that might play the same game on a laptop and a desktop. Having the save game automatically synced to all your devices is quite useful, but if an attacker compromised your Steam account, your save games could be manipulated. This leads to the very real possibility that an attacker could use a save game vulnerability to turn a Steam account compromise into an attack on all your machines with Steam installs.

This Week In Security: SACK Of Death, Rambleed, HIBP For Sale, And Oracle Weblogic — Again!

Netflix isn’t the first name to come to mind when considering security research firms, but they make heavy use of FreeBSD in their content delivery system and do security research as a result. Their first security bulletin of the year, not surprisingly, covers a FreeBSD vulnerability that happens to also affect Linux kernels from the last 10 years. This vulnerability uses SACKs and odd MSS values to crash a server kernel.

To understand Selective ACKs, we need to step back and look at how TCP connections work. TCP connections provide guaranteed delivery, implemented in the from of ACKnowledgement (ACK) packets. We think of a TCP connection as having a dedicated ACK packet for every data packet. In reality, the Operating System makes great effort to avoid sending “naked” ACK packets, and combines multiple ACKs in a single packet. An ACK is simply a flag in a packet header combined with a running total of bytes received, and can be included in a normal data packet. As much as is possible, the ACK for data received is sent along with data packets flowing in the opposite direction. Continue reading “This Week In Security: SACK Of Death, Rambleed, HIBP For Sale, And Oracle Weblogic — Again!”