This Week In Security: Ransomware, WeLock, And Amazon Arbitration

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 fujifilmusa.com was down.

WeLock Unlocked

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.

Amazon Echo, Recordings, and Arbitration

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.

Unpickable Locks?

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.

One Shots

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 apt package manager.

The gstreamer 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 gst-plugins-good 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 angr. [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.

9 thoughts on “This Week In Security: Ransomware, WeLock, And Amazon Arbitration

  1. The real problem lies with coders these days. They focus to much on getting the task complete rather than thinking outside the box and checking for things that should never be done. For example, writing code for a DTMF keypad on your phone. Sure the coder checks for what digit you pressed, but did he then add code for obscure things like pressing two or three buttons at once? This is why things are able to be hacked, its all bad coding skills.

      1. Probably not just “hardware guy”, worse yet probably an “armchair engineer”. It’s easy to criticize when someone has little to zero practical experience in actual industry, under real life company/management in the specific field they are criticizing.

        Every flaw/bug is completely the fault of the programmer, totally has nothing to do with budget cuts, tight timelines, mismanagement, last minute design changes, corners cut at the design meeting decided by those above your pay grade, I could go on and on. I am lucky to have a unique perspective of seeing both sides of a design, being an embedded engineer, with my hands in both hardware and software.

        Nothing is as simple as most people without the experience assume. When I see a generalized statement like the problem is with “x” or “y” have gotten lazy today (replace x and y with whatever technical position that person has a vendetta against), all I can think is wow this person is talking out their %^& and fooling themselves into thinking their myopic view is reality.

      2. Maybe, maybe not. When I started my IT career, I worked as a QA/QC tester for several products. My specialty was “corner cases” — things theoretically possible but not normally considered because you have to go WAY out of your way to set up the test condition.

    1. Even worse is the fact that programmers take pride in specifically *not* doing anything more than the minimum. Sometimes not even using encryption where it is badly needed.

      Programmers want everything to be a simple educational proof of concept with some neat algorithms to play with.

      Actually making a finished product is about as interesting as toilet scrubbing work to them, and they actively encouraged useless weekend toy projects as a way to hone your skills….. When it seems to do the exact opposite if you aren’t careful what habits you pick up.

        1. They *can* be professional and have all the technical skills. They just don’t like the way modern software is done and are mediocre but passable at actually making useful products.

          And they’re really smart, so they generally technically have good reasons for doing stuff, but it falls apart when you look at the big picture.

          Like, if there’s a dozen legacy parts that use some crappy old but totally workable protocol that is trivial to add compatibility for, they’ll want to redo the whole system from the ground up.

          And they like “just right” solutions, as in “This language is perfect for expressing this! And wind up with 5 different technologies to deal with instead of just one that is 90% as good.

          I call it “project to process transition” when something becomes more of a scientific process of discovering new ways of doing things, rather than a project that will eventually be “done” in some sense.

  2. it was interesting to watch the picking of those locks – one immediately things that we all should go to electronic locks instead.. Then, of course, you read the rest of the article and see the massive problem with someone’s bluetooth locks..

    I’ve done a couple of rfid ones over the years – the main issue is power (you don’t want to be locked out with a flat battery) and if there is a problem. Most commercial ones have an ’emergency’ key – which defeats much of the purpose…

    For the battery the main thing that has helped is cheap wifi chips, that you can leave off most of the time. But if the battery is getting low you can log on to wifi an send a email alerting to the battery situation..
    Losing the rfid card is same as losing a key – have a spare at a friends place.
    And for general problems I want with the physical approach – ie if it happens forced entry will be the alternative.. Of course, that wouldn’t work for a commercial lock..

    1. Hmm …..
      If you can pick a lock or not that really doesn’t matter .
      If the lock is ‘ old school ‘ or ‘ smart digital ‘ doesn’t matter either .

      If a thief want to enter a house , then the last thing they would
      waste time on is picking a lock .
      They would find a weak spot to break into the house .
      Let it be windows or simply break door at doorframe ect .

      Not wasting time on picking the lock , for them its about
      get inside , search , steal , leave .
      All as fast as possible .

      Even a blaaring alarm doesn’t matter because they be out again so fast .

      Best to do is to make it as hard as possible to break in from windows , doors ect ect .
      Steel frames and fence on windows ect ect .

      Things that will make it take longer for a thief to break in .
      If it will take too long time to break trough doors ect , then the thief
      simply will find another place to do hes / her business .

      Longer time equal bigger risk to get caught . It is simple logic .

      Not if the lock can be picked or not .
      Or if it is old type or modern wifi digital …
      A thief doesn’t care .
      They just break in .

Leave a Reply to Ragnarok700Cancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.