Another week of ransomware, and this time it’s the beef market that’s been shut down, due to a crippling infrastructure attack out of Russia — but hold up, it’s not that simple. Let’s cover the facts. Some time on Sunday, May 30, JBS USA discovered a ransomware attack against their systems. It seems that their response team did exceptionally well, pulling the plug on affected machines, and starting recovery right away. By Wednesday, it was reported that most of their operations were back in action.



The FBI has officially attributed the attack to REvil, AKA Sodinokibi, in a brief statement. REvil provides ransomware as a service, so it’s very possible that a different actor actually launched the attack. So far the details are scarce on how the initial infection happened. While the implication seems to be that JBS did not pay the ransom, I haven’t seen that confirmed either.

And if that isn’t enough ransomware news for you for the week, it’s being reported that Fujifilm has also been attacked, and is recovering their networks. I can’t confirm that it’s related, but when researching, I discovered that was down.

The We.Lock system of locks has a problem. Namely, a very insecure API that is still being supported. The good folks at Critical Security discovered the problem and attempted to report it in January of this year, and were met with deafening silence. Just over a week ago, the WeLock mobile app was updated, introducing a new, more secure API, but so far the legacy system is still running.

So how bad was the old API? To start with, the message data is encrypted with 3DES, which in itself is considered insecure. The real problem there is that 3DES is a symmetric encryption scheme, and every instance of the app uses the same hard-coded key. Worst of all, this key also serves to authenticate API calls. So how does a Bluetooth unlock request go? The app makes an API call, specifying the phone number associated with the account, and the API returns the details of each smart lock on the account, including each of their Bluetooth unlock passwords! A simple BLE packet containing this password will unlock any lock on the account. In short, all that’s needed to unlock a We.Lock smartlock in person is the phone number on the account.

There’s a strange story brewing around the Amazon Echo. Amazon Alexa devices are always listening for their “wake word”, and in practice this means that these devices are sometimes recording spontaneously. An example of those recordings being used is in criminal cases, where the recordings are subpoenaed. The idea of Amazon storing your private conversations on their servers might not sit well with you, and it might be illegal in a few states. The obvious solution might be a class-action lawsuit, but Amazon Echo’s terms of service specifically prevented class-action suits, and instead compelled arbitration.

What you might not realize is that when a company forces a customer into arbitration, case law and some state laws push the financial burden to the company. Put simply, Amazon forced me into arbitration, so they get to pay for it. That fee isn’t much for one or two people, but when 75,000 users all request arbitration at once, it’s expensive enough for even Amazon to notice. The ToS have dropped the forced arbitration language, but that change has no impact on the legal action already initiated. This approach has been used successfully against DoorDash, Patreon, and Uber.

The problem with building an unpickable lock is that lock pickers are clever, and don’t care that a design is “unpickable”. This week, we have a collaboration between [Stuff Made Here] and [LockPickingLawyer], where a pair of such unpickable locks were pretty quickly defeated. What’s interesting is that along with defeating each of the custom designed locks, our lawyer friend sent along suggestions for fixing the flaws he used to get in. We might get a followup attempt that fixes the identified flaws.

The trick to just about all of the unpickable designs is that they are designed to be very difficult to tension and manipulate the pins at the same time. In both of the locks in question, this is accomplished by a mechanism that locks the pins in place, as the lock rotates. The pins are no longer accessible when they actually interface with the locking mechanism. The trick to picking them? For the first lock, move the pins as far up as they will go and use a small hammer to bump them into position. The second lock is a bit trickier, requiring a mechanical bypass to put tension directly on the real core, at which point it is easily picked.

This week also brings a healthy set of short stories, like the release of Kali Linux 20221.2. This update to the penetration and forensics focused Linux distro includes the normal package updates and bug fixes, but introduces some interesting changes. Among those are full support for the Raspberry Pi 400, to get your cyberdeck on; disabling privileged ports, so you can run a tool that binds to a low-numbered port without becoming root; and the addition of Kaboxer, a containerized application system built on Docker, that integrated well into the package manager.

The framework recently fixed a pair of bugs in its matroska support. One of the bugs has already been demonstrated to be exploitable by playing a demonstration media file, so make sure you update to version 1.19.1 of the package.

The WordPress plugin Fancy Product Designer has a critical vulnerability that’s being exploited in the wild. It’s a file upload issue, where an attacker could bypass safeguards and upload executable PHP files to the site. If you manage a site running this plugin, make sure it’s updated to 4.6.9 as soon as possible, and check carefully for possible compromise.

If you ever find yourself with an obfuscated binary that needs to be examined, consider Python’s . [NapongiZero] steps us through the process of setting up the library to look for the right information, in this case a secret key. It’s a neat tool to have in your kit.

And finally, HaveIBeenPwned has released part of their backend code as open source. [Troy] has previously announced that he plans to make the entire operation open source, but comments here that it was a bigger task than expected, to package up his one-man project into an open source project. The .NET Foundation has stepped in to help, and there is now source code to show for their efforts. The first element to be released as FLOSS is Pwned Passwords, which is fitting, since many of us were too paranoid (rightfully so) to punch a password into the web form, and trust that everything was being done correctly to check it. Well now you can examine the source, and even run the entire service offline.

Source: Hackaday

Powered by NewsAPI.org