This week safe: Lastpass Takeaway, Bitcoin Loss and PyTorch

[ad_1]

We mentioned the LastPass story at the end a few weeks ago, but details were still a little scarce. The hope was that LastPass would release more transparent information about what happened and how many accounts were accessed. Unfortunately, it looks like the December 22 press release is all we’ll get. For LastPass users, it’s time to make decisions.

To recap, an attacker used information from the August 2022 breach to target a LastPass employee with a social engineering scheme. This was successful, and the attacker was able to gain access to LastPass backups, specifically a customer account database and customer vaults. There was no official word on how much user data was included, but the indication is that it was the full data set. And to make matters worse, the encrypted vault is only partially encrypted. Recorded URLs were exposed in plain text to the attacker, although usernames and passwords were still encrypted using your master password.

So what should a LastPass user do now? It depends. We can assume that whoever owns the LastPass Vault data is currently dumping all available password lists into it. If you’ve been using a weak password – derived from words in any language or previously compromised – it’s time to change all your passwords that were in the vault. They are burned.

Whether you stick with LastPass or switch to another solution, it’s only a matter of time until your vault is cracked. Worse still, some old Lastpass accounts only use 5,000 turns of the Password-Based Key Derivation Function (PBKDF2) hash. New accounts are configured to use over 100,000 iterations, but some older accounts may still use the old setting. The result is that an attack against the encrypted vault executes much faster. The iteration count is almost certainly in the stolen data, so those counts will likely be tested first. If you are a long-time user, change all passwords stored in the vault.

There is some good news. Vaults use a salt to accompany passwords – additional data that is built into the PBKDF2 feature. This means that the password cracking procedure must be performed individually per user. If you are just another uninteresting user, you may never be targeted for the crack. But if you’re likely to be interesting or have URLs that look interesting, there’s probably a higher chance of being targeted. And unfortunately, it was plain text.

So how does the math stack up? Fortunately for us, [Wladimir Palant] ran the numbers for us. A minimum complexity password, using the 2018 Rules for a LastPass Password, yields 4.8×10^18 possible password combinations. An RTX 4090 can sustain around 1.7 million guesses per second on an account using just 5,000 iterations of PBKDF2, or 88,000 guesses per second on a properly secured account. It’s 44,800 years and 860,000 years to open a safe, assuming an RTX4090 is working there. Very rough calculations on the size of a three-letter agency data center would suggest that devoting the entirety of one of these data centers to the task would crack the least secure vault in less than 4 months . With an account using full security settings, that jumps to nearly six years. Keep in mind that this approach is a best-case scenario for an attacker and represents devoting a $1.5 billion data center to the task for an extended period of time. But that also assumes that you chose your password randomly.

But here’s the catch: While the risk is enough to drive you into action, changing your LastPass password isn’t enough. Whether you stay with LastPass or switch to another solution, you’ll need to change the master password first, then go through the grueling process of changing every password in your LastPass vault. The whole mess was definitely a failure on LastPass’s part, and their post-incident report certainly leaves some transparency to be desired. The unencrypted URLs associated with each saved password are unfortunate. But the central tenet, that not even LastPass can access your saved passwords, seems to have held up.

Bitcoin Hacker Hacked

Luke Dashjr is a Bitcoin Core developer, the main signer of the Bitcoin Knots software, and suffered a major security breach. This may be an incident following a physical attack in November, where someone managed to restart their co-located server from a flash drive and install a backdoor. This was caught and the malware was apparently removed. Luke lost a total of around 200 bitcoins, on his active (hot) and offline (cold) wallets. He treats this as a total compromise and warned that his PGP key should also be suspect. This means that recent versions of Bitcoin Knots should also be suspect.

Several theories have been put forward, ranging from a “boating accident” to avoid paying tax, to a known issue with random number generation on the Talos system he uses (CVE-2019-15847). None of this seems as likely as the idea that it was a missed rootkit on the compromised server and a sideways rollback in [Luke]home network. Either way, it’s a terrible mess, and we’re hoping for a positive resolution.

PyTorch Nightly Compromise

The PyTorch-nightly package was hit by a dependency confusion attack, active between December 25 and December 30. The problem here is that PyTorch is hosting a torchtriton package as part of its nightly repository, and the package name hasn’t been claimed on PyPi. So all someone had to do was download a package under that name, and presto, any new pip install of PyTorch-nightly grabbed the PyPi version. The malicious package sucks system data, such as current nameservers, hostname, username, working directory, and environment variables, and sends it to h4ck[dot]cfd (archive link). That bit isn’t too bad, even though environment variables are sure to include authentication tokens. Most importantly, bash history, /etc/hosts, /etc/passwd, ~/.gitconfig, ~/.ssh and the first 1000 files in the home directory are all packaged and downloaded as well. On a modern system, the passwd file doesn’t actually contain any password hashes, but the .ssh folder may well contain private SSH keys. Yeah.

Now the developer behind this fake package has been found and claims it was for security research and promises that all data will be deleted. The stolen data was meant to be used to positively identify the victim, presumably for the purpose of collecting bug bounties. This has some element of credibility, but really doesn’t matter, because any secrets leaked in this incident must be revoked regardless. The silver lining is that no malicious code is executed simply by installing the package, but a Python script would have to perform an explicit import triton in order to trigger the payload. The PyTorch project renamed the package to pytorch-triton and reserved that project name on PyPi to avoid a repeat crash.

Mapping vulnerable Citrix installations

A few critical vulnerabilities were patched recently in Citrix ADC and Citrix Gateway, one of which caused an NSA advisory that an Advanced Persistent Threat (APT) was actively compromising systems with the bug. Fixed version numbers are known, prompting researchers at Fox It, part of the NCC group, to wonder. Is there a way to determine the version of a Citrix device from the pre-authentication HTTP response? Spoiler: There are. The /vpn/index.html endpoint contains a hash that seems to vary from version to version. The only trick left was to find a quick way to map the hash to the version.

Enter Google’s Cloud Marketplace, which offers a one-click option to launch a new Citrix virtual machine. An SSH session then confirmed the version and corresponding hash. It’s one less. Google’s service also includes a zip file with information about older versions, including image names that can be used to download previous versions as a qcow2 virtual disk image – easy enough to retrieve the hash and version number from there. Between these images and the Citrix download page, a number of known hashes were identified, but strangely, some hashes seen in the wild did not appear to match a known version. By finding a specific read-only file that is also remotely accessible, it is possible to get an accurate timestamp of when a given firmware was created. This fills in the gaps of known version numbers and allows them to determine exactly which versions were appearing in the wild.

Since the hash was part of the data collected by analysis services such as Shodan, it is possible to view the history of installed versions, as well as the current status. There is a very noticeable change in the deployed builds, matching the NSA’s warning nicely. Even then, many deployed Citrix servers still appear to be running vulnerable firmware, although deployment details may mean they are not in imminent danger. It’s a very interesting look at how we end up with statistics like these.

Bits and Bytes

Synology’s VPN server has a critical vulnerability, CVE-2022-43931, which has a CVSS score of 10 and allows an unauthenticated attacker to execute arbitrary commands. Corrected versions are available. The flaw itself is an out-of-bounds write to the Remote Desktop service, so there is hope that this vulnerable service is not widely exposed to the open Internet.

Here’s the exploit you didn’t know you needed, breaking out of the Lua interpreter to get shellcode running. The trick here is to encode the shellcode as numbers and then trick the runtime into unaligned access, which skips program execution in the data. Another fun trick is that the target Lua interpreter will allow you to run Lua bytecode and trust it like normal Lua code. So what is the purpose of all this? Sometimes the fun is in the journey.

What do you get when bored security researchers decide to dig into the electric scooter mobile app? Lots of scooters honking and flashing mysteriously. And when those same researchers raise the bar and try to get cars to honk? A truly impressive list of remote vulnerabilities in vehicles of all brands. From live GPS tracking to turning on lights, unlocking doors, and even remotely starting vehicles, [Sam Curry] and his band of merry hackers did. To the credit of the many vendors who have been affected, just about every vulnerability ends with “they fixed it right away”.

[ad_2]