The hot news this week is that Kaspersky is banned in the USA. More specifically, Kaspersky products will be banned from sale in the US starting on September 29. This ban will extend to blocking software updates, though it’s unclear how that will actually be accomplished. It’s reasonable to assume that payment processors will block payments to Kaspersky, but will ISPs be required to block traffic that could contain antivirus updates?

WordPress Plugin Backdoor

A Quartet of WordPress plugins have been found to have recently included backdoor code. It’s a collection of five Open Source plugins, seemingly developed by unrelated people. Malicious updates first showed up on June 21st, and it appears that all five plugins are shipping the same malicious code.

Rabbit AI API

The Rabbit R1 was released to less than thunderous applause. The idea is a personal AI device, but the execution has been disappointing, to the point of reviewers suggesting some of the earlier claims were fabricated. Now it seems there’s a serious security issue, in the form of exposed API keys that have *way* too many privileges.

The research seems to be done by the rabbitude group, who found the keys back in May. Of the things allowed by access to the API keys, the most worrying for user privacy was access to every text-to-speech call. Rabbitude states in their June 25 post, that “rabbit inc has known that we have had their elevenlabs (tts) api key for a month, but they have taken no action to rotate the api keys.” On the other hand, rabbit pushed a statement on the 26th, claiming they were just then made aware of the issue, and made the needed key rotations right away.

MOVEit is Back

Last year a severe vulnerability in MOVEit file transfer server led to some big-deal compromises in 2023 and 2024. MOVEit is back, this time disclosing an authentication bypass. The journey to finding this vulnerability starts with an exception, thrown whenever an SSH connection is attempted with a public key.

…the server is attempting to open the binary data representing our auth material, as a file path, on the server.

Uh-oh. There’s no way that’s good. What’s worse, that path can be an external SMB path. That’s even worse. This behavior does depend on the incoming connection referencing a valid username, but this has the potential to enable password stealing, pass-the-hash attacks, and username mapping. So what’s actually going on here? The SSH server used here is IPWorks SSH, which has some useful additions to SSH. One of these additions seems to be an odd delegated authentication scheme that goes very wrong in this case.

The attack flow goes like this: Upload a public SSH key to any location on the MOVEit server, log in with any valid username signing the connection with the uploaded key, and send the file location of the uploaded key instead of an actual key. Server pulls the key, makes sure it matches, and lets you in. The only pesky bit is how to upload a key without an account. It turns out that the server supports PPK keys, and those survive getting written to and read from the system logs. Ouch.

The flaws got fixed months ago, and a serious effort has been carried out to warn MOVEit customers and get them patched. On the other hand, a full Proof of Concept (PoC) is now available, and Internet monitoring groups are starting to see the attack being attempted in the wild.

Cat File: Pop Calc

We all know not to trust files from the Internet. Don’t execute the script, don’t load the spreadsheet, and definitely don’t install the package. But what about running cat or strings on an untrusted file? Apparently the magic of escape strings makes those dangerous too. The iTerm2 terminal was accidentally set to allow “window title reporting”, or copying the window title to the command line. Another escape code can set that value, making for an easy way to put an arbitrary command on the command line. One more quirk in the form of tmux integration allowed the injection of a newline — running the arbitrary command. Whoops. Versions 3.5.0 and 3.5.1 are the only iterm2 versions that are vulnerable, with version 3.5.2 containing the fix.

Putting LLM to Work During Naptime

There’s been a scourge of fake vulnerability reports, where someone has asked ChatGPT to find a vulnerability in a project with a bug bounty. First off, don’t do this. But second, it would be genuinely useful if a LLM could actually find vulnerabilities. This idea intrigued researchers at Google’s Project Zero, so they did some research, calling it “Project Naptime”, in a playful reference to napping while the LLM works.

The secret sauce seems to be in extending an LLM to look at real code, to run Python scripts in a sandbox, and have access to a debugger. The results were actually encouraging, that LLM could eventually be a useful tool. It’s not gonna replace the researcher, but it won’t surprise me to cover vulnerabilities found by a LLM instead of a fuzzing tool. Or maybe that’s an LLM guided fuzzer?

Github Dishes on Chrome RCE

Github’s [Man Yue Mo] discovered and reported CVE-2024-3833 in Chrome back in March, a fix was released in April, and it’s now time to get the details. This one is all about how object cloning and code caching interacts. Cloning an object in a particular circumstance ends up with an object that exists in a superposition between having unused property fields, and yet a full property array. Or put simply, the internal object state incorrectly indicates there is unused allocated memory. Try to write a new property, and it’s an out of bounds write.

The full exploit is involved, but the whole thing includes a sandbox escape as well, using overwritten WebAssembly functions. Impressive stuff.

Bits and Bytes

[Works By Design] is taking a second crack at building an unpickable lock. This one has some interesting features, like a ball-bearing spring system that should mean that levering one pin into place encourages the rest to drop out of position. A local locksmith wasn’t able to pick it, given just over half-an-hour. The real test will be what happens when [LockPickingLawyer] gets his hands on it, which is still to come.

Gitlab just fixed a critical issue that threatened to let attackers run CI pipelines as arbitrary users. The full details aren’t out yet, but CVE-2024-5655 weighs in at a CVSS 9.6, and Gitlab is “strongly recommending” immediate updates.