This Week In Security: Garmin Ransomware, KeePass , And Twitter Warnings

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 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 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.


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 
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.

9 thoughts on “This Week In Security: Garmin Ransomware, KeePass , And Twitter Warnings

  1. Every person in charge of funding allocation for infosec should do the following:
    Determine the maximum amount that would be spent in the event of a ransom attack. Start spending that money on improved security now.

      1. I’ve read some analyses that say it is the law, and that it also applies to third party transactions, like Garmin contracts with security company X and pays them $10M and says “whatever you have to do to get it fixed, do it” and they pay the ransomware people. So there are at least some people out there saying this broke federal law. Not that I expect anyone’s actually going to do anything about it.

  2. Can we get a clarification on the KeePass vulnerability? The article says that it’s a flaw in KeePass, but the link and the lack of updates on the official KeePass page seem to suggest that the vulnerability is in a third-party KeePass plugin called KeePassRPC which allows the software created by *KeeVault* to access a KeePass 2 database in addition to their cloud-based service.
    The specific module mentioned in the article is KeePassRPC.plgx which is not part of KeePass, and KeePass itself released their last update in May of this year.

    1. contains the official announcement and various discussions relating to it (as Craig says, GitHub releases also links to the information there).

      I can confirm that the article should be modified to say “Kee Vault released an update…”. KeePassRPC is a KeePass plugin but the wording on this article implies an official association with the developer of KeePass, which is not the case.

  3. You guys totally missed the Intel leaks (20GB) yesterday.
    >Intel ME Bringup guides + (flash) tooling + samples for various platforms
    >Kabylake (Purley Platform) BIOS Reference Code and Sample Code + Initialization code (some of it as exported git repos with full history)
    >Intel CEFDK (Consumer Electronics Firmware Development Kit (Bootloader stuff)) SOURCES
    >Silicon / FSP source code packages for various platforms
    >Various Intel Development and Debugging Tools

    etc etc

Leave a 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.