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 will have. 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. Some very approximate calculations on the size of a three-letter agency data center would suggest that devoting the entirety of one of these data centers to this 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. This whole mess was definitely a failure on LastPass’s part, and their post-incident report certainly leaves something 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, lead signer of Bitcoin Knots software, and suffered a major security breach. This may be an incident resulting from a November physical attack, where someone managed to reboot their collocated server from a flash drive and install a backdoor. This one 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 treated this as a complete 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 with addiction confusionattack, active between December 25 and December 30. The problem here is that PyTorch hosts a torchtriton package as part of its nightly repository, and this package name has not been claimed on PyPi. So everyone had to do was come over and 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 them to h4ck.[dot]cfd(Archive link). That bit isn’t too bad, even though environment variables are sure to include authentication tokens. The kicker is this bash story, /etc/hosts, /etc/passwd, ~/.gitconfig, ~/.ssh, and the first 1000 files in the home directory are also all packaged and downloaded. On a modern system, the passwd the file does not 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 a security search, and promises that all data will be deleted. The stolen data was allegedly intended to positively identify the victim, presumably for the purpose of collecting bug bounties. It has some element of credibility, but it really doesn’t matter, because all the secrets leaked in this incident should be revoked regardless. The silver lining is that no malicious code is executed simply by installing the package, but a Python script should do an explicit import triton to trigger the payload. The PyTorch project renamed the package to pytorch-tritonand reserved this project name on PyPi to avoid a repeat incident.
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 and made by researchers at Fox It, part of the NCC group, wonder. Is there a way to determine the version of the version a Citrix device from the pre-authentication HTTP response? Spoiler: There are. The /vpn/index.html the endpoint contains a hash which 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 older versions as qcow2 ramdisk image – pretty easy to grab 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 built. 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 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, exit the Lua interpreter to get the shellcode execution. 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 gang of fun hackers did. To the credit of the many vendors who have been affected, just about every vulnerability ends with “they fixed it right away”.
0 Comments