So first off, go take a look at this curl bug report. It’s a 8.6 severity security problem, a buffer overflow in websockets. Potentially a really bad one. But, it’s bogus. Yes, a strcpy call can be dangerous, if there aren’t proper length checks. This code has pretty robust length checks. There just doesn’t seem to be a vulnerability here.

OK, so let’s jump to the punch line. This is a bug report that was generated with one of the Large Language Models (LLMs) like Google Bard or ChatGPT. And it shouldn’t be a surprise. There are some big bug bounties that are paid out, so naturally people are trying to leverage AI to score those bounties. But as [Daniel Stenberg] point out, LLMs are not actually AI, and the I in LLM stands for intelligence.

There have always been vulnerability reports of dubious quality, sent by people that either don’t understand how vulnerability research works, or are willing to waste maintainer time by sending in raw vulnerability scanner output without putting in any real effort. What LLMs do is provide an illusion of competence that takes longer for a maintainer to wade through before realizing that the claim is bogus. [Daniel] is more charitable than I might be, suggesting that LLMs may help with communicating real issues through language barriers. But still, this suggests that the long term solution may be “simply” detecting LLM-generated reports, and marking them as spam.

This is Why We Can’t Have Nice Things

Now on to another terrible idea, an automated torque wrench with network access. These devices are used in manufacturing, to tighten bolts to the proper torque — a critical step in many cases.

So, in fairness, it sort of makes sense that a manufacturer would want to record and automatically transmit torque history from the device, in an effort to catch problems right away. Except these devices have Swiss-cheese for firmware, with 23 identified vulnerabilities. The mix allows for an exploitation chain starting with a completely unauthenticated attacker, and ending with root code execution on the device.

The researchers behind this work are from Nozomine Networks, and they’ve created a couple of Proof of Concepts (PoCs) to demonstrate what a real attacker could do. The first is a ransomware program, asking for a tenth of a Bitcoin to make the drill operational again. The second is even sneakier, instructing the device to use incorrect torque settings, while still reporting the correct ones onscreen. Now that would make for some very sneaky industrial sabotage.

While the existence of the vulnerabilities have been announced, the technical details are still embargoed. Security fixes are expected to be available by the end of the month.

The Google Supercookie

One of the more convenient features of the Google ecosystem is the ability to have a device or browser permanently logged in to a user account. All those devices are supposed to be logged out on a password change, but there is apparently a wrinkle in that scheme. A black hat security researcher discovered that the account ID and security tokens taken from the internal state of a logged-in browser can be sent to the MultiLogin endpoint, and valid authentication cookies can be generated — even after a password change. That’s a pretty big deal, when part of the standard solution to a security issue is a password change. In this case, that doesn’t guarantee a malicious actor is kicked out of the account.

This is a zero-day problem that is part of several malware toolkits, and has yet to be patched by Google. The reason seems to be that the MultiLogin endpoint is a core part of Google account authentication flow. For now, if you suspect your Google account has fallen victim to this problem, the solution is to manually sign out of every browser or device session, do a password reset, and signing each session in again.

Ivanti

Also under active exploitation is a pair of vulnerabilities in the Ivanti corporate VPN solution. There isn’t yet a lot of information available, but we know that CVE-2023-46805 is an authentication bypass, while CVE-2024-21887 is a command injection flaw. Together, the two flaws seem to make a very effective attack chain leading to external unauthenticated code execution.

The first hint of these flaws has been found dating back to December 3. A mitigation is available, and full patches are planned to roll out in January. The limited exploitation has been attributed to a Chinese APT, but it’s likely that the flaws will be recreated by others and widely exploited.

Airdrop

Apple’s Airdrop is a nifty way to share files with local contacts. It even has an option to share files with everyone within WiFi or Bluetooth range. Way back in 2019, researchers identified a problem with how Apple was using simple hashing to identify users. Airdrop never makes the claim of being truly anonymous, but users rely on the functional anonymity, particularly in places like China where the free exchange of information is sometimes curtailed. That functional anonymity has proven to be incomplete, as Chinese authorities have found a way to identify the users sending and receiving messages.

Based on the information available, it appears that they have managed this by constructing a rainbow table of hashes and possible identifiers.

Rainbow tables are a very clever technique to achieve partial pre-calculation of a hash. There are broadly two extreme ways to reverse a hash and derive the secret. On one side, you can simply brute-force the hash, trying every possible combination and comparing the hashed guess to the hash you’re trying to reverse. This takes an extremely long time, but basically zero data storage. On the other hand, you could pre-calculate all those guesses, and just store the results in a lookup table. A hash could be reversed very quickly, but the data storage requirements would be insane.

A rainbow table splits the difference, by very cleverly storing a much smaller lookup table, and doing some of the computation when breaking the target hash. It works by using a reduction function, intended to take a hash and compute it back into something resembling another guess. When pre-computing the rainbow table, you start with a guess, then hash it with the target hash. You then use the reduction step to turn that into a different guess, and then hash that guess. This process continues for a set number of rounds, let’s use 100 as an example. Once the rounds are complete, the first round guess and the last round hash are stored. This process is done for many guesses, and the entire result is stored.

Then when trying to break a real hash, the same reduction/hashing process is done 100 times. If after any of those steps, the resulting hash matches one of the stored hashes, you know the secret is probably one of the guesses on that chain. The attacker simply has to re-walk the matching chain, and the matching secret and hash is found. Just an aside, for many years Windows user passwords were trivially easy to crack using free rainbow tables.

Now back to the Airdrop problem. Armed with the insufficient cryptography of Airdrop, Chinese authorities are using rainbow tables to trace the “inappropriate information in public places”. Of particular note is the fact that this wouldn’t be terribly difficult to secure. Apple has a good track record in the US of securing its users, even from government and law enforcement access. In my opinion, it would be rather damning if Apple failed to address this vulnerability being used by Chinese law enforcement.

Bits and Bytes

Adobe’s Coldfusion had Remote Code Execution (RCE) and arbitrary file read vulnerabilities that were used in the wild last year. SecureLayer7 has the inside scoop on exactly what caused the vulnerabilities. It was a JSON deserialization bug in the ColdFusion Java code.

Now here’s a clever idea. You can add CSS to theme your Office 365 page. As part of that CSS, you can include a file, for example a background image. If you also host that background image, you can watch your server logs in real time to see what page it’s being called from. If that URL happens to be something different than your actual login URL, then you just caught an Adversary-in-the-Middle (AitM) phishing attack!

We have a pair of Twitter X fails, first from the SEC losing control of their X account. The single post made by an attacker claimed that the SEC approved a Bitcoin ETF, which sent markets swinging wildly in response to both the fake post, and the news that it wasn’t real. And then Mandiant has released their promised information about their hacked X account. The official word is that it was a brute-force attack and 2 Factor Authentication temporarily turned off on the account.

We have finished our investigation into last week's Mandiant X account takeover and determined it was likely a brute force password attack, limited to this single account.

— Mandiant (@Mandiant) January 10, 2024

And finally, Wireshark has released version 4.2.1, with a handful of Vulnerability fixes in Wireshark itself. We’ve seen threat actors targeting security researchers over the last couple years, so it’s not unthinkable that a Wireshark packet capture could actually contain an exploit. Just like everything else, be careful opening untrusted pcap files!