On July 23, multiple services related to Garmin were taken offline, including their call center and aviation related services. Thanks to information leaked by Garmin employees, we know that this multi-day outage was caused by the Wastedlocker ransomware campaign. After four days, Garmin was able to start the process of restoring the services.

It’s reported that the requested ransom was an eye-watering $10 million. It’s suspected that Garmin actually paid the ransom. A leaked decryptor program confirms that they received the decryption key. The attack was apparently very widespread through Garmin’s network, as it seems that both workstations and public facing servers were impacted. Let’s hope Garmin learned their lesson, and are shoring up their security practices.

KeePass

KeePass released an update this week addressing a couple flaws in the KeePassRPC service. The update announcement is light on the details, but thankfully we have the full story directly from [Philipp Danzinger], the student that discovered the vulnerabilities. Both vulnerabilities are in the implementation of the SRP-6(a) key exchange protocol.

The vulnerable component is the RPC. KeyPass is essentially a simple database containing passwords. That database is encrypted using the user’s password, so the contained passwords cannot be retrieved without that master password. When a user launches KeePass, he or she is first prompted for this master password, and the database is decrypted using that password. The KeePassRPC service allows other processes, like a browser plugin, to access the now-decrypted database. The first time a new client attemps to access the RPC service, a keypair is generated, and the user is prompted whether to allow the new connection. The public key is stored and marked as trusted, allowing that client to request passwords again in the future, so long as the database had been unlocked.

The authentication protocol is similar to a DH key exchange. A shared value is raised to the power of the secret key resulting in a value called A. This is sent as part of the key exchange, and the formal specification states that it is never allowed to be 0. The problem is that KeePassRPC doesn’t properly check that A != 0. When A is set to 0, the entire key exchange breaks down, as all the values end up equaling 0, as 0^x is always 0. This means that any client can spoof an already authorized client.

The second vulnerability is a weak random number generator used on the server side to generate the secret key b. That key is based on the current date and time, run through a pseudo-random function. Because that function is known, if an attacker can guess the exact time value used, then the secret key is easily calculated. It’s not quite as simple as it seems, as the time value is measured in “ticks”, each tick being 100 nanoseconds. It would take a bit of guesswork and a few thousand guesses to land on the right value, but without any rate limiting, that process would just take a few seconds.

What makes this attack very serious is the fact that modern web browsers allow Javascript running on a webpage to attempt to connect to localhost. If your KeePass database is unlocked, and you load a page running malicious JS, it could access the RPC port and spoof the authorized KeePass browser plugin and download your entire KeePass database. Thankfully this bug was disclosed privately and KeePassRPC has been updated to 1.12.1, which closes both vulnerabilities. Additionally, 1.13 has since been released with additional safeguards against this and similar attacks.

Twitter

Twitter has started displaying a security warning for some users. The details are extremely scarce, but lets see what details we can tease out. First, the warning specifies that the issue in question was a vulnerability in the Twitter Android app, but that it was related to an Android vulnerability, and then links to the October 2018 Android security update. Looking through the vulnerabilities disclosed, there doesn’t seem to be an obvious candidate for the related vulnerability.

KDE Ark

We’ve seen a very simple technique show up in countless security stories: path transversal. It’s simple, you can include a “..” as part of a file path to move up a directory. Often times this can be included in unexpected places to bypass security restrictions, or do other unintended things. Archive files are no exception, and there is nothing preventing a zip archive from having such paths. Most archive programs catch this behavior and don’t allow the archive to extract as it’s written. The venerable unzip command complains like this:

# unzip relative2.zip 
Archive:  relative2.zip
warning:  skipped "../" path component(s) in tmp/../../moo
 extracting: tmp/moo

KDE Ark, until recently, didn’t treat those paths as special, and would happily extract files to whatever path it was instructed to. The update doesn’t seem to be officially released at the time of writing, so be wary of blindly extracting archives until that update is available. There is a useful repository of archives that can be used to test for various transversal issues, and I’ve confirmed that one in particular (harmless zip file containing tmp/../../moo) does demonstrate the issue in Ark.

And Finally…

Remember Boothole? Multiple vendors pushed fixes to this Linux secure boot vulnerability, and a handful of unbootable systems was the result. For the case of RHEL and CentOS, another round of updated packages have been released, fixing the problem and making for bootable systems again.

And what does a criminal do with a database breach? Apparently after selling them, they release them for free. If it wasn’t stolen data, I’d call it a win. Once a breach has made as much money as the seller thinks it’s likely to make, it’s not uncommon for the data to be released for free. These aren’t very popular sites or services, but it might be worth a check to see if your data was included in the release.

source https://hackaday.com/2020/08/07/this-week-in-security-garmin-ransomware-keepass-and-twitter-warnings/

We love the simplicity of Arduino for focused tasks, we love how Raspberry Pi GPIO pins open a doorway to a wide world of peripherals, and we love the software ecosystem of Intel’s x86 instruction set. It’s great that some products manage to combine all of them together into a single compact package, and we welcome the recent addition of Seeed Studio’s Odyssey X86J4105.

[Ars Technica] recently looked one over and found it impressive from the perspective of a small networked computer, but they didn’t dig too deeply into the maker-friendly side of the product. We can look at the product documentation to see some interesting details. This board is larger than a Raspberry Pi, but its GPIO pins were laid out in exactly the same order as that on a Pi. Some HATs could plug right in, eliminating all the electrical integration leaving just the software issue of ARM vs x86. Tasks that are not suitable for CPU-controlled GPIO (such as generating reliable PWM) can be offloaded to an on-board Arduino-compatible microcontroller. It is built around the SAMD21 chip, similar to the Arduino MKR and Arduino Zero but the pinout does not appear to match any of the popular Arduino form factors.

The Odyssey is not the first x86 single board computer (SBC) to have GPIO pins and an onboard Arduino assistant. LattePanda for example has been executing that game plan (minus the Raspberry Pi pin layout) for the past few years. We’ve followed them since their Kickstarter origins and we’ve featured creative uses here and there. LattePanda’s current offerings are built around Intel CPUs ranging from Atom to Core m3. The Odyssey’s Celeron is roughly in the middle of that range, and the SAMD21 is more capable than the ATmega32U4 (Arduino Leonardo) on board a LattePanda. We always love seeing more options in a market for us to find the right tradeoff to match a given project, and we look forward to the epic journeys yet to come.

source https://hackaday.com/2020/08/07/odyssey-is-a-x86-computer-packing-an-arduino-along-for-the-trip/

Perhaps it’s just one of those things adults dream up to entertain their children, but were you ever told to count slowly the time between seeing a lightning flash and hearing the rumble of thunder? The idea was that the count would tell you how far away the storm was, but from a grown-up perspective the calibration accuracy of a child saying “one… two…three…” in miles seems highly suspect. It’s a valid technique though, and it can be used to monitor thunderstorms by the radio emissions created through the electrical discharge. It’s an area the SAGE project has been working in, and they’ve posted some details including a fascinating run-down of the software techniques , on how lightning can be detected with an RTL-SDR.

A lightning strike produces a characteristic wideband burst that shows up in the time domain as a maximum point that can easily be detected but could also be confused with radio interference from another source. Thus after identifying maxima they zoom in and perform a Fourier transform to spot the wideband burst. It’s all done in Python, and the pleasant surprise is how straightforward to understand it all is.

SAGE are working on a distributed sensor network, so we hope this work might one day give us real-time open lightning data. The FFT approach should ensure that it won’t be fooled by false positives as a traditional detector might be.

Via RTL-SDR.com.

source https://hackaday.com/2020/08/07/lightning-analysis-with-your-sdr/

[Ryan] wanted to hack the Google Chrome Dinosaur Game so he could control the dinosaur with his own movements. The game only requires two keyboard presses (up and down arrow keys), so controlling the game with the Arduino Keyboard library only requires a few simple function calls.

He uses the Arduino MKR board in his build, but notes any number of other boards would work as well. A force sensor detects his jumps and a stretch sensor detects him ducking. Both the stretch and force sensors are resistive transducers, so two simple voltage divider circuits (one for each sensor) are needed to convert changes in force to a voltage. You may need to adjust the sensor threshold to ensure the code responds to your movements, but [Ryan] makes that pretty easy to do in software as both thresholds are stored as global variables.

It’s a pretty simple hack, but could make for some good socially-distanced fun. What other hackable Google Chrome extensions do you like?

source https://hackaday.com/2020/08/06/google-chrome-dinosaur-game-in-real-life/

When you think of iRobot, you probably think of floor cleaning or military robots. But they also have a set of robots aimed at education. The Root robot — an acquisition the company made in 2019 — originally targeted classrooms and cost about $200 each. A new version costs about $130 and is a better fit for home users.

The original version  — Root rt1 — is still available, but the rt0 version has several missing features to hit the desired price. What’s missing? Apparently, the rt1 can stick to a whiteboard using magnets, but that feature is missing on the rt0. There are also no “cliff” sensors or color scanner.

On the plus side, there is a new $20 option that allows either version of the robot to mount Lego creations. Usually, the robots can draw with a marker underneath and retract it on command. The rt1 can also erase the marker. With the Lego base, though, you can use that same mechanism to actuate something like the catapult in the video.

The robots can be coded using something that looks like Scratch or using text-based coding. The editor — you can even simulate it online for free– has three levels, depending on the student’s ability to read and code. In addition, there are many free exercises and activities.

For $130, these seem as though they’d be easily hackable as a robot platform. Of course, you want this for your kids and we wouldn’t say otherwise.

Educational robots are not a new idea. If you want to stick with iRobot for the big league stuff, you can also get a Roomba that doesn’t suck.

source https://hackaday.com/2020/08/06/irobot-makes-learning-robot-more-affordable/