We’ve covered a lot of ransomware here, but we haven’t spent a lot of time looking at the decryptor tools available to victims. When ransomware gangs give up, or change names, some of them release a decryption tool for victims who haven’t paid. It’s not really a good idea to run one of those decryptors, though. The publishers don’t have a great track record for taking care of your data, after all. When a decryptor does get released, and is verified to work, security researchers will reverse engineer the tool, and release a known-good decryption program.
The good folks at No More Ransom are leading the charge, building such tools, and hosting a collection of them. They also offer Crypto Sheriff, a tool to identify which ransomware strain got your files. Upload a couple encrypted files, and it will inform you exactly what you’re dealing with, and whether there is a decryptor available. The site is a cooperation between the Dutch police, Interpol, Kaspersky, and McAfee. It may surprise you to know that they recommend reporting every ransomware case to the authorities. I can confirm that at the very least, the FBI in the US are very interested in keeping track of the various ransomware attacks — I’ve fielded a surprise call from an agent following up on an infection.
Death and passwords: two things we just can’t avoid. With so much of our lives tied up in cloud services nowadays, there’s good reason to worry about what happens to these accounts if we drop dead tomorrow. For many of us, important documents, photos, financial information and other data will be locked behind a login prompt. Your payment methods will also expire shortly after you have, which could lead to data loss if not handled promptly. The most obvious way to address this is to give a trusted party access in case of emergency.
A Bad Solution
Let’s start with the simplest solution: using the same password everywhere. Great, all you need to do is put this on a Post-it note, stuff it in an envelope, and let someone know where to find it. Unfortunately, using a single password for many services is a terrible idea. Password breaches happen, and if you’re using a single password across the internet, they can be disastrous.
Password breaches are usually the result of an attacker finding a vulnerability that allows reading password data from an application’s database. Odds are high that your information has been leaked in one of these breaches. You can check if your email is on a list of known breaches with Have I Been Pwned. Don’t feel bad if you’ve been pwned, my email shows up on six different breaches, and this service only indexes publicly known breaches!
Depending on the competency of the company that was breached, your password may have been stolen in a few different formats. In the worst case, the passwords were stored as-is (i.e., cleartext), and the breach contains your actual password. Nowadays, storing passwords in cleartext is never considered acceptable. A hash of the password is stored instead. Attackers need to use a tool like hashcat to try to recover the passwords via brute force hash cracking. This is slow for complex passwords, but is always getting faster as GPUs improve.
So we really need to use different passwords everywhere, or our Tumblr account from 2013 could give access to our bank account. Given the large number of services we use and our inability to remember passwords, we’re going to need to use a password manager. Continue reading “The Postmortem Password Problem”→
Windows security problems due to insecure drivers is nothing new, but this one is kinda special. Plug in a Razer mouse, tell the install dialog you want to install to a non-standard location, and then shift+right click the Explorer window. Choose a powershell, and boom, you now have a SYSTEM shell. It’s not as impressive as an RCE, and it requires hands-on the machine, but it’s beautiful due to the simplicity of it.
The problem is a compound one. First, Windows 10 and 11 automatically downloads and starts the install of Razer Synapse when a Razer device is plugged in. Note it’s not just Razer, any branded app that auto installs like this is possibly vulnerable in the same way. The installation process runs as system, and because it was started automatically, there is no admin account required. The second half of the issue is that the installer itself doesn’t take any precautions to prevent a user from spawning additional processes. There isn’t an obvious way to prevent the launch of Powershell from within the FolderPicker class, so an installer running as SYSTEM would have to go out of its way to drop privileges, to make this a safe process. The real solution is for Microsoft to say no to GUI installers bundled with WHQL signed drivers. Continue reading “This Week In Security: Through The Mouse Hole, Zoom RCE, And Defeating Defender”→
For readers that might not spend their free time watching spools of PLA slowly unwind, The Spaghetti Detective (TSD) is an open source project that aims to use computer vision and machine learning to identify when a 3D print has failed and resulted in a pile of plastic “spaghetti” on the build plate. Once users have installed the OctoPrint plugin, they need to point it to either a self-hosted server that’s running on a relatively powerful machine, or TSD’s paid cloud service that handles all the AI heavy lifting for a monthly fee.
Unfortunately, 73 of those cloud customers ended up getting a bit more than they bargained for when a configuration flub allowed strangers to take control of their printers. In a frank blog post, TSD founder Kenneth Jiang owns up to the August 19th mistake and explains exactly what happened, who was impacted, and how changes to the server-side code should prevent similar issues going forward.
TSD allows users to remotely manage and monitor their printers.
For the record, it appears no permanent damage was done, and everyone who was potentially impacted by this issue has been notified. There was a fairly narrow window of opportunity for anyone to stumble upon the issue in the first place, meaning any bad actors would have had to be particularly quick on their keyboards to come up with some nefarious plot to sabotage any printers connected to TSD. That said, one user took to Reddit to show off the physical warning their printer spit out; the apparent handiwork of a fellow customer that discovered the glitch on their own.
According to Jiang, the issue stemmed from how TSD associates printers and users. When the server sees multiple connections coming from the same public IP, it’s assumed they’re physically connected to the same local network. This allows the server to link the OctoPrint plugin running on a Raspberry Pi to the user’s phone or computer. But on the night in question, an incorrectly configured load-balancing system stopped passing the source IP addresses to the server. This made TSD believe all of the printers and users who connected during this time period were on the same LAN, allowing anyone to connect with whatever machine they wished.
New code pushed to the TSD repository limits how many devices can be associated with a single IP.
The mix-up only lasted about six hours, and so far, only the one user has actually reported their printer being remotely controlled by an outside party. After fixing the load-balancing configuration, the team also pushed an update to the TSD code which puts a cap on how many printers the server will associate with a given IP address. This seems like a reasonable enough precaution, though it’s not immediately obvious how this change would impact users who wish to add multiple printers to their account at the same time, such as in the case of a print farm.
While no doubt an embarrassing misstep for the team at The Spaghetti Detective, we can at least appreciate how swiftly they dealt with the issue and their transparency in bringing the flaw to light. This is also an excellent example of how open source allows the community to independently evaluate the fixes applied by the developer in response to a discovered flaw. Jiang says the team will be launching a full security audit of their own as well, so expect more changes getting pushed to the repository in the near future.
We were impressed with TSD when we first covered it back in 2019, and glad to see the project has flourished since we last checked in. Trust is difficult to gain and easy to lose, but we hope the team’s handling of this issue shows they’re on top of things and willing to do right by their community even if it means getting some egg on their face from time to time.
Have you ever thought about all the complexities of a Single Sign On (SSO) implementation? A lot of engineering effort has gone into hardened against cross-site attacks — you wouldn’t want every site you visit to be able to hijack your Google or Facebook account. At the same time, SSO is the useful ability to use your authentication on one service to authenticate with an unrelated site. Does SSO ever compromise that hardening? If mistakes are made, absolutely, as [Zemnmez] discovered while looking at the Apple ID SSO system.
We’ve covered the right-to-repair saga, and one of the companies that have become rather notorious is John Deere. The other side to the poorly managed interconnected mess is security issues. There’s a certain irony to how this story started: Somebody noticed that John Deere equipment didn’t have any CVEs at all. A normal person might think that this must mean their products are super secure, but a security researcher knows that something more interesting is afoot. Our old friends [Sick Codes], [John Jackson], and a host of others saw this as a sure sign that there were plenty of vulnerabilities to be found, and it seems they were correct.
Remote Access and Code from 2014…
Vulnerabilities included a handful of cross-site scripting attacks, an authentication bypass via request smuggling, misconfigured security, SQL injections, RCEs and more. Put together, these vulnerabilities allowed for full control of the John Deere system, including the ability to manipulate all the equipment connected to the system.
During the Defcon presentation, linked below, [Sick Codes] recalled the moment when they realized they were working on an important problem. Rather than complain about not getting paid for the vulnerabilities found, a contributor simply noted that he valued having food to eat. A coordinated attack on JD equipment could cause big problems for a bunch of farms across a country.
They ended up contacting CISA, due to a lack of serious response from the vendors. CISA took the threat seriously, and the problems starting getting fixed. This isn’t a problem limited to one company. Case had similar issues that have also been fixed, and it was implied that other vendors have similar problems that are still in the process of being addressed. Continue reading “This Week In Security: John Deere, ProxyLogin Detailed, And Pneumatic Tubes”→
Have you ever been looking for a screwdriver, USB stick, or your keys, only to find them right where you left them in plain sight? We have. As many prolific geocachers know, hiding things out in the open is a great way to make sure that people overlook them.
Why hide bookmarks to begin with? A browser’s bookmark collection can give away the habits, interests, and needs of the person who put them there. Bookmarks to gifts, domestic abuse support websites, and other private destinations might be best kept away from prying eyes.
Inspired by port knocking — opening connections to specific network ports in sequence to gain access through a firewall — bookmark knocking requires clicking bookmarks in a specific order to open a link. When the bookmarks are accessed in the proper order, the third bookmark reveals a hidden site. It’s not only a novel approach to hiding things in plain sight, it’s very cool to use!
We especially appreciate [Jacob]’s motivation: Helping those who are vulnerable to protect themselves in any way possible. It’s a solid reminder that technology can be elevated to a higher stature when put to a noble use. Be sure to check out the demonstration so you can try it for yourself!
