Making A “Unpickable” Lock

November 29, 2020 by Danie Conradie 51 Comments

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

November 27, 2020 by Inderpreet Singh 5 Comments

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

November 25, 2020 by Jenny List 33 Comments

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

November 20, 2020 by Jonathan Bennett 6 Comments

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

November 19, 2020 by Mike Szczys 4 Comments

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” →

Teardown: Recon Sentinel

November 16, 2020 by Tom Nardi 35 Comments

It might be hard to imagine now, but there was a time when the average home had only a single Internet connected device in it. This beige box, known as a “desktop computer” in those olden days, was a hub of information and productivity for the whole family. There was a good chance you might even need to wait for your turn to use it, since it’s not like you had a personal device in your pocket that let you log on from ~~the bathroom~~ whatever room you might be in at the time. Which is just as well, since even if you had broadband back then, you certainly weren’t shooting it around the house with the Magic Internet Beams that we take for granted now.

Things are a lot more complicated today. Your computer(s) are only part of the equation. Now there’s mobile phones and tablets sharing your Internet connection, in addition to whatever smart gadgets you’ve brought into the mix. When your doorbell and half the light bulbs in the house have their own IP address, it takes more than a fresh copy of Norton AntiVirus to keep everything secure.

Which is precisely what Cigent Technology says the Recon Sentinel was designed for. Rather than protecting a single computer or device, this little gadget is advertised as being able to secure your entire network by sniffing out suspicious activity and providing instant notifications when new hardware is connected. According to the official whitepaper, it also runs a honeypot service Cigent calls a “cyber deception engine” and is capable of deploying “Active Defense Countermeasures” to confuse malicious devices that attempt to attack it.

It certainly sounds impressive. But for $149.99 plus an annual subscription fee, it better. If you’re hoping this teardown will tell you if it’s worth springing for the $899.99 Lifetime Subscription package, don’t get too excited. This isn’t a review, we’re only interested in cracking this thing open and seeing what makes it tick.

Continue reading “Teardown: Recon Sentinel” →

This Week In Security: Platypus, Git.bat, TCL TVs, And Lessons From Online Gaming

November 13, 2020 by Jonathan Bennett 9 Comments

Git’s Large File System is a reasonable solution to a bit of a niche problem. How do you handle large binary files that need to go into a git repository? It might be pictures or video that is part of a project’s documentation, or even a demonstration dataset. Git-lfs’s solution is to replace the binary files with a text-based pointer to where the real file is hosted. That’s not important to understanding this vulnerability, though. The problem is that git-lfs will call the main git binary as part of its operation, and when it does so, the full path is not used. On a Unix system, that’s not a problem. The $PATH variable is used to determine where to look for binaries. When git is run, /usr/bin/git is automagically run. On a Windows system, however, executing a binary name without a path will first look in the current directory, and if a matching executable file is not found, only then will the standard locations be checked.

You may already see the problem. If a repository contains a git.exe, git.bat, or another git.* file that Windows thinks is executable, git-lfs will execute that file instead of the intended git binary. This means simply checking out a malicious repository gets you immediate code execution. A standard install of git for Windows, prior to 2.29.2.2, contains the vulnerable plugin by default, so go check that you’re updated!

Then remember that there’s one more wrinkle to this vulnerability. How closely do you check the contents of a git download before you run the next git command? Even with a patched git-lfs version, if you clone a malicious repository, then run any other git command, you still run the local git.* file. The real solution is pushing the local directory higher up the path chain. Continue reading “This Week In Security: Platypus, Git.bat, TCL TVs, And Lessons From Online Gaming” →