We mentioned the LastPass story in closing a couple weeks ago, but details were still a bit 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 22nd news release is all we’re going to get. For LastPass users, it’s time to make some decisions.

To recap, an attacker used information from the August 2022 breach to target a LastPass Employee with a social engineering ploy. This succeeded, and the attacker managed to access LastPass backups, specifically a customer account database and customer vaults. There has been no official word of how many users’ data were included, but the indication is that it was the entire dataset. And to make matters worse, the encrypted vault is only partially encrypted. Saved URLs were exposed as plain-text to the attacker, though usernames and passwords are still encrypted using your master password.

So what should a LastPass user do now? It depends. We can assume that whoever has the LastPass vault data is currently throwing every password list available at it. If you used a weak password — derived from words in any language or previously compromised — then it’s time to change all of your passwords that were in the vault. They are burned.

Whether you stick with LastPass or go to another solution, it’s just a matter of time until your vault is cracked. Making matters worse, some old Lastpass accounts only use 5,000 rounds of PBKDF2 (Password-Based Key Derivation Function) hashing. New accounts are set to use over 100,000 iterations, but some older accounts could still use the old setting. The result is that an attack against the encrypted vault runs much faster. The number of iterations is almost certainly in the stolen data, so these accounts will likely be tested first. If you’re a long-time user, change all of the passwords stored in the vault.

There is some good news. The vaults use a salt to go with the passwords — additional data that gets folded into the PBKDF2 function. It means that the password cracking procedure has to be done individually per user. If you’re just another uninteresting user, you might not ever get targeted for cracking. But if you might be interesting, or have URLs that look interesting, there’s likely a higher chance of being targeted. And unfortunately, these were plain text.

So how does the math stack up? Lucky for us, [Wladimir Palant] ran the numbers for us. A minimum complexity password, using the 2018 rules for a LastPass password, results in 4.8×10^18 possible password combinations. An RTX 4090 can sustain in the ballpark of 1.7 million guesses per second on an account using only 5,000 iterations of PBKDF2, or 88,000 guesses per second on a properly secured account. That’s 44,800 years, and 860,000 years to break a vault open, assuming one RTX4090 working on it. Some very rough math on the size of a three-letter-agency datacenter would suggest that devoting the entirety of one of these datacenters to the task would crack the less secure vault in under 4 months. With an account using the full security settings, this rises to nearly six years. Keep in mind, this approach is a best-case scenario for an attacker, and represents devoting a $1.5 billion datacenter to the task for an extended period. But it also assumes you chose your password randomly.

But here’s the rub: If the risk is enough to push you to action, it’s not enough to change your LastPass password. Whether you stay with LastPass or move to another solution, you’ll need to change the master password first, and then go through the grueling process of changing every password in your LastPass vault. This whole mess was certainly a failing on the part of LastPass, and their post-incident reporting certainly leaves some transparency to be desired. Unencrypted URLs associated with each saved password is 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 primary signer of the Bitcoin Knots software, and has suffered a major security breach. This may be a follow-on incident from a November physical attack, where someone managed to reboot his co-located server from a flash drive, and install a backdoor. That one was caught, and the malware was seemingly removed. Luke lost a total of about 200 bitcoin, out of both his active (hot) and offline (cold) wallets. He’s treating this as a total compromise, and has warned that his PGP key should be suspect as well. That means recent releases of Bitcoin Knots should be suspect, too.

There have been several theories floated, everything from a “boating accident” to avoid tax liability, to a known problem with random number generation on the Talos system he uses (CVE-2019-15847). None of this seems quite as likely as the idea that this was a missed rootkit on the compromised server, and lateral movement back into [Luke]’s home network. Either way, it’s a terrible mess, and we’re hopefully looking forward to a positive resolution.

PyTorch Nightly Compromise

The PyTorch-nightly package was hit with a dependency confusion attack, active between December 25th and December 30th. The issue here is that PyTorch hosts a torchtriton package as part of its nightly repo, and that package name wasn’t claimed on PyPi. So, all someone had to do was come along and upload a package under that name, and presto, any new pip install of PyTorch-nightly grabbed the PyPi version. The malicious package vacuums up system data, like current nameservers, hostname, username, working directory, and environment variables, and sends those to h4ck[dot]cfd (Archive link). That bit isn’t so bad, though environment variables are sure to include auth tokens. The kicker is that bash history, /etc/hosts, /etc/passwd, ~/.gitconfig, ~/.ssh, and the first 1000 files in the home directory are all packaged up and uploaded, too. On a modern system, the passwd file doesn’t actually contain any password hashes, but the .ssh folder may very well contain private SSH keys. Yikes.

Now, the developer behind this bogus package has been found, and claims that this was intended to be security research, and promises that all data will be deleted. The stolen data was claimed to be in order to positively ID the victim, presumably for the purpose of collecting bug bounties. This has some element of believability, but really doesn’t matter, as any secrets leaked in this incident need to be revoked regardless. The silver lining is that no malicious code is run simply by installing the package, but a Python script would need to do an explicit import triton in order to trigger the payload. The PyTorch project has renamed the package to pytorch-triton, and reserved that project name on PyPi to avoid a repeat incident.

Mapping Vulnerable Citrix Installs

There have been a couple of critical vulnerabilities fixed recently in Citrix ADC and Citrix Gateway, one of which prompting a notice from the NSA that an APT (Advanced Persistent Threat) was actively compromising systems with the bug. The fixed version numbers are known, and that made researchers at Fox It, part of NCC Group, wonder. Is there a way to determine the release version of a Citrix device from the pre-authentication HTTP response? Spoiler: There is. The /vpn/index.html endpoint contains a hash that seems to vary between release versions. The only trick left was to find a quick way to map the hash back to the version.

Enter Google’s Cloud Marketplace, which has a one-click option to spin up a new Citrix virtual machine. One SSH session later confirmed the version and corresponding hash. That’s one down. Also part of Google’s service is a zip file that has information about older versions, including image names that can be used to download previous versions as a qcow2 virtual disk image — easy enough to grab the hash and version number from there. Between these images and the Citrix download page, quite a few of the known hashes were identified, but strangely, there are some hashes observed in the wild that didn’t seem to line up with a known release. By finding a specific read-only file that is also accessible remotely, it’s possible to get an accurate timestamp on when a given firmware was built. That fills in the gaps on the known version numbers, and let them chart out exactly what versions were showing up in the wild.

Because the hash was part of the data collected by scanning services like Shodan, it’s possible to look at the history of installed versions, as well as the current state. There’s a very noticeable change in the deployed versions, nicely corresponding to the NSA warning. Even at that, there are many deployed Citrix servers that still appear to be running vulnerable firmware, though the details of the deployment 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, that scores a CVSS score of 10, and allows an unauthenticated attacker to execute arbitrary commands. Patched releases are available. The flaw itself is an out-of-bounds write in the Remote Desktop service, so there is some hope that this vulnerable service isn’t 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 execution. The trick here is to encode shellcode as numbers, then trick the runtime into unaligned access, which jumps program execution into the data. Another fun trick is that the target Lua interpreter will let you run Lua bytecode and trusts it just like regular Lua code. So what’s the purpose of all this? Sometimes the fun is in the journey.

What do you get when bored security researchers decide to poke at the mobile app for electric scooters? Lots of mysteriously honking and flashing scooters. And when those same researchers up the ante and try to make cars 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 made it happen. To the credit of the many vendors that were affected, pretty much every vulnerability ends with “they fixed it right away.”