Let’s Encrypt Will Stop Working For Older Android Devices

Let’s Encrypt was founded in 2012, going public in 2014, with the aim to improve security on the web. The goal was to be achieved by providing free, automated access to SSL and TLS certificates that would allow websites to make the switch over to HTTPS without having to spend any money.

Hundreds of millions of sites rely on Let’s Encrypt for their HTTPS certificate needs. HTTPS security helps protect sites and users, and makes it harder for malicious actors to steal private information.

The project has just announced that, come September 1, 2021, some older software will stop trusting their certificates. Let’s look at why this has come to pass, and what it means going forward.

Certificates Expire

When Let’s Encrypt first went public in early 2016, they issued their own root certificate, by the name ISRG Root X1. However, it takes time for companies to include updated root certificates in their software, so until recently, all Let’s Encrypt certificates were cross-signed by an IdenTrust certificate, DST Root X3. This certificate had been around much longer, and was already supported by the vast majority of OSes and browsers in regular use. This allowed Let’s Encrypt to hit the ground running while they waited for the majority of software to support their own root certificate. Continue reading “Let’s Encrypt Will Stop Working For Older Android Devices”

Amazon Sidewalk: Should You Be Co-Opted Into A Private Neighbourhood LoRa Network?

WiFi just isn’t very good at going through buildings. It’s fine for the main living areas of an average home, but once we venture towards the periphery of our domains it starts to become less reliable.  For connected devices outside the core of a home, this presents a problem, and it’s one Amazon hope to solve with their Sidewalk product.

It’s a low-bandwidth networking system that uses capability already built into some Echo and Ring devices, plus a portion of the owner’s broadband connection to the Internet.  The idea is to provide basic connectivity over longer distances to compatible devices even when the WiFi network is not available, but of most interest and concern is that it will also expose itself to devices owned by other people. If your Internet connection goes down, then your Ring devices will still provide a basic version of their functionality via a local low-bandwidth wide-area wireless network provided by the Amazon devices owned by your neighbours. Continue reading “Amazon Sidewalk: Should You Be Co-Opted Into A Private Neighbourhood LoRa Network?”

Making A “Unpickable” Lock

Every time manufacturers bring a new “unpickable” lock to market, amateur and professional locksmiths descend on the new product to prove them wrong. [Shane] from [Stuff Made Here] decided to try his hand at designing and building an unpickable lock, and found that particular rabbit hole to be a lot deeper than expected. (Video, embedded below.)

Most common pin tumbler locks can be picked thanks to slightly loose fits of the pins and tiny manufacturing defects. By lifting or bumping the pins while putting tension on the cylinder the pins can be made to bind one by one at the shear line. Once all the pins are bound in the correct position, it can be unlocked.

[Shane]’s design aimed to prevent the pins from being set in unlocked position one by one, by locking the all pins in whatever position they are set and preventing further manipulation when the cylinder is turned to test the combination. In theory this should prevent the person doing the picking from knowing if any of the pins were in the correct position, forcing them to take the difficult and time-consuming approach of simply trying different combinations.

[Shane] is no stranger to challenging projects, and this one was no different. Many of the parts had to be remade multiple times, even with his well-equipped home machine shop. The mechanism that holds the pins in the set position when the cylinder is rotated was especially difficult to get working reliably.  He explicitly states that this lock is purely an educational exercise, and not commercially viable due to its mechanical complexity and difficult machining.

A local locksmith was unsuccessful in picking the lock with the standard techniques, but the real test is still to come. The name [LockPickingLawyer] has probably already come to mind for many readers. [Shane] has been in contact with him and will send him a lock to test after a few more refinements, and we look forward to seeing the results! Continue reading “Making A “Unpickable” Lock”

Shhh… Robot Vacuum Lidar Is Listening

There are millions of IoT devices out there in the wild and though not conventional computers, they can be hacked by alternative methods. From firmware hacks to social engineering, there are tons of ways to break into these little devices. Now, four researchers at the National University of Singapore and one from the University of Maryland have published a new hack to allow audio capture using lidar reflective measurements.

The hack revolves around the fact that audio waves or mechanical waves in a room cause objects inside a room to vibrate slightly. When a lidar device impacts a beam off an object, the accuracy of the receiving system allows for measurement of the slight vibrations cause by the sound in the room. The experiment used human voice transmitted from a simple speaker as well as a sound bar and the surface for reflections were common household items such as a trash can, cardboard box, takeout container, and polypropylene bags. Robot vacuum cleaners will usually be facing such objects on a day to day basis.

The bigger issue is writing the filtering algorithm that is able to extract the relevant information and separate the noise, and this is where the bulk of the research paper is focused (PDF). Current developments in Deep Learning assist in making the hack easier to implement. Commercial lidar is designed for mapping, and therefore optimized for reflecting off of non-reflective surface. This is the opposite of what you want for laser microphone which usually targets a reflective surface like a window to pick up latent vibrations from sound inside of a room.

Deep Learning algorithms are employed to get around this shortfall, identifying speech as well as audio sequences despite the sensor itself being less than ideal, and the team reports achieving an accuracy of 90%. This lidar based spying is even possible when the robot in question is docked since the system can be configured to turn on specific sensors, but the exploit depends on the ability to alter the firmware, something the team accomplished using the Dustcloud exploit which was presented at DEF CON in 2018.

You don’t need to tear down your robot vacuum cleaner for this experiment since there are a lot of lidar-based rovers out there. We’ve even seen open source lidar sensors that are even better for experimental purposes.

Thanks for the tip [Qes]

Zoombombing The EU Foreign Affairs Council

Those with security clearance are capable of making foolish mistakes, just like the rest of us. So is the story of how a Dutch journalist made an appearance on video meeting of the European Union’s Foreign Affairs Council (Dutch language, Google Translate link).

Ank Bijleveld's Tweeted picture, with the access details blacked out by Daniël Verlaan.
Netherlands Defence MInister Ank Bijleveld’s Tweeted picture, with the access details blacked out by Daniël Verlaan.

Like any other video call, if you had the link you could enter the meeting. So when Netherlands Defence Minister Ank Bijleveld Tweeted a photo of a video call last Friday, the address bar of the browser gave away the secret to anyone with a keen eye. Dutch journalist Daniël Verlaan working for the broadcaster RTL saw the URL on the screen and deduced the login credentials for the meeting.

We say “deduced”, but in fact there were five of the six digits in the PIN in the clear in the URL, leaving him with the difficult task of performing a one-digit brute-force attack and joining with the username “admin”. He joined and revealed his presence, then was admonished for committing a criminal offence before he left.

On one level it’s an opportunity for a good laugh at the expense of the defence ministers, and we certainly wouldn’t want to be Ank Bijleveld or probably the EU’s online security people once the inevitable investigation into this gets under way. It seems scarcely credible that the secrecy on such a high-security meeting could have sat upon such a shaky foundation without for example some form of two-factor authentication using the kind of hardware available only to governments.

EU policy is decided not by individual ministries but by delicate round-table summits of all 27 countries. In a pandemic these have shifted to being half-online and half in-real-life, so this EU defence ministers’ meeting had the usual mosaic video feed of politicians and national flags. And one Zoom-bombing journalist.

This Week In Security: SAD DNS, Incident Documentation Done Well, And TCL Responds

One of the big stories from the past few days is the return of DNS cache poisoning. The new attack has been dubbed SADDNS, and the full PDF whitepaper is now available. When you lookup a website’s IP address in a poisoned cache, you get the wrong IP address.

This can send you somewhere malicious, or worse. The paper points out that DNS has suffered a sort of feature creep, picking up more and more responsibilities. The most notable use of DNS that comes to mind is LetsEncrypt using DNS as the mechanism to prove domain ownership, and issue HTTPS certificates.

DNS Cache poisoning is a relatively old attack, dating from 1993. The first iteration of the attack was simple. An attacker that controlled an authoritative DNS server could include extra DNS results, and those extra results would be cached as if they came from an authoritative server. In 1997 it was realized that the known source port combined with a non-random transaction ID made DNS packet spoofing rather trivial. An attacker simply needs to spoof a DNS response with the appropriate txID, at the appropriate time to trick a requester into thinking it’s valid. Without the extra protections of TCP connections, this was an easy task. The response was to randomize the txID in each connection.

I have to take a moment to talk about one of my favorite gotchas in statistics. The Birthday paradox. The chances that two randomly selected people share a birthday is 1 in 365. How many people have to be in a room together to get a 50% chance of two of them sharing a birthday? If you said 182, then you walked into the paradox. The answer is 23. Why? Because we’re not looking for a specific birthday, we’re just looking for a collision between dates. Each non-matching birthday that walks into the room provides another opportunity for the next one to match.

This is the essence of the DNS birthday attack. An attacker would send a large number of DNS requests, and then immediately send a large number of spoofed responses, guessing random txIDs. Because only one collision is needed to get a poisoned cache, the chances of success go up rapidly. The mitigation was to also randomize the DNS source port, so that spoof attempts had to have both the correct source port and txID in the same attempt. Continue reading “This Week In Security: SAD DNS, Incident Documentation Done Well, And TCL Responds”

Remoticon Video: Firmware Reverse Engineering Workshop With Asmita Jha

Taking things apart to see how they work is an important part of understanding a system, and that goes for software as much as for hardware. You can get a jump start on your firmware reverse engineering skills with Asmita Jha’s workshop which was presented live at the Hackaday Remoticon. The video has just been published, and is found below along with a bit more on what she covered in her hands-on labs.

Continue reading “Remoticon Video: Firmware Reverse Engineering Workshop With Asmita Jha”