Samba has a very serious vulnerability, CVE-2021-44142, that was just patched in new releases 4.13.17, 4.14.12, and 4.15.5. Discovered by researchers at TrendMicro, this unauthenticated RCE bug weighs in at a CVSS 9.9. The saving grace is that it requires the fruit VFS module to be enabled, which is used to support MacOS client and server interop. If enabled, the default settings are vulnerable. Attacks haven’t been seen in the wild yet, but go ahead and get updated, as PoC code will likely drop soon.
Crypto Down the Wormhole
One notable selling point to cryptocurrencies and Web3 are smart contracts, little computer programs running directly on the blockchain that can move funds around very quickly, without intervention. It’s quickly becoming apparent that the glaring disadvantage is these are computer programs that can move money around very quickly, without intervention. This week there was another example of smart contracts at work, when an attacker stole $326 million worth of Ethereum via the Wormhole bridge. A cryptocurrency bridge is a service that exists as linked smart contracts on two different blockchains. These contracts let you put a currency in on one side, and take it out on the other, effectively transferring currency to a different blockchain. Helping us make sense of what went wrong is [Kelvin Fichter], also known appropriately as [smartcontracts].
Alright. I figured out the Solana x Wormhole Bridge hack. ~300 million dollars worth of ETH drained out of the Wormhole Bridge on Ethereum. Here's how it happened.
— smartcontracts (@kelvinfichter) February 3, 2022
When the bridge makes a transfer, tokens are deposited in the smart contract on one blockchain, and a transfer message is produced. This message is like a digital checking account check, which you take to the other side of the bridge to cash. The other end of the bridge verifies the signature on the “check”, and if everything matches, your funds show up. The problem is that one one side of the bridge, the verification routine could be replaced by a dummy routine, by the end user, and the code didn’t catch it.
It’s a hot check scam. The attacker created a spoofed transfer message, provided a bogus verification routine, and the bridge accepted it as genuine. The majority of the money was transferred back across the bridge, where other user’s valid tokens were being held, and the attacker walked away with 90,000 of those ETH tokens.
The 9.8 CVE That Wasn’t
Dealing with security reports can be challenging. For example, English isn’t everyone’s first language, so when an email comes in with spelling and grammar mistakes, it would be easy to dismiss it, but sometimes those emails really are informing you of a severe problem. And then sometimes you get a report because someone has discovered Chrome’s DevTools for the first time, and doesn’t realize that local changes aren’t served to everyone else.
CVE-2022-0329 was one of those. The package in question is the Python library, loguru, which boasts “Python logging made (stupidly) simple”. A serious CVE in a logging library? The internet briefly collectively braced for another log4j style problem. Then more people started looking at the vulnerability report and bug report, and casting doubt on the validity of the issue. So much so, that the CVE has been revoked. How did a non-bug get rated as such a high security issue, that GitHub was even sending out automated alerts about it?
The theoretical vulnerability was a deserialization problem, where the pickle library, included as a dependency of loguru, does not safely deserialize untrusted data. That’s a valid problem, but the report failed to demonstrate how loguru would allow untrusted data to be deserialized in an unsafe way.
There’s a concept at play here, the “airtight hatchway”. In any codebase or system, there will be a point where manipulating program data can lead to code execution. This is behind the airtight hatchway when performing that attack requires already having control over the program. In this case, if you can build the object that pickle will deserialize, you already have arbitrary code execution. That’s not to say it’s never appropriate to fix such an instance, but that’s code hardening, not fixing a vulnerability.
That’s where this went off the rails. [Delgan], the developer behind loguru was convinced this wasn’t a true vulnerability, but he wanted to do some code hardening around the idea, so marked the original vulnerability report as accepted. This set the automated machinery in motion, and a CVE was issued. That CVE was set as extremely serious, based on a naive understanding of the issue, maybe also an automated action. This automated frenzy continued all the way to a Github advisory, before someone finally stepped in and cut the power to the out-of-control automaton.
Windows EoP PoC
In January, Microsoft patched CVE-2022-21882, an Escalation of Privilege in the Win32 code of Windows. Don’t let that fool you, it’s present in 64-bit versions of Windows, too. If you’re behind on your updates, you might want to get busy, as a Proof-of-Concept has now dropped for this bug. This has been reported as a patch bypass, making this essentially the same underlying problem as CVE-2021-1732.
QNAP Forced Pushed an Update
And Users Are Ticked
QNAP and other NAS manufacturers have been forced to step up their security game, as these style devices have become yet another tempting target for ransomware thieves. So when QNAP discovered a flaw that was being exploited in the “deadbolt” malware campaign, they opted to do a force push of the update to every user that had auto-update enabled. This means that where updates would normally install, and ask for permission to reboot, this one rebooted spontaneously, maybe causing data loss in the worst case.
QNAP has given their thoughts in a Reddit thread on the subject, and there’s some disagreement about how exactly this worked. At least one user is quite emphatic that this feature was disabled, and the update still auto-installed. What’s going on?
There is an official answer. In an earlier update, a new feature was added, the Recommended Version. This serves as an automatic update, but only when there’s a serious issue. This is the setting that allows forced pushes, and it defaults to on. (In fairness, it was in the patch notes.) Dealing with updates on appliances like these is always difficult, and the looming threat of ransomware makes it even stickier.
So what do you think, was QNAP just taking care of customers? Or was this akin to the notice of destruction of Arthur Dent’s house, posted in the basement in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.’? Let us know in the comments, or if Discord is your thing, the new channel dedicated to the column!
0 Commentaires