This Week in Security: Adblock for Security, ProxyNotShell Lives, and CVSS 10 to Not Worry About

The ubiquity of ransomware continues, this time with The Guardian announcing they were partially shut down from an attack. Staff are working from home as the incident is being investigated and data is recovered. Publishing seems to be continuing, and the print paper ran as expected.

There have been a couple reports published recently on how ransomware and other malware is distributed, the first being a public service announcement from the FBI, detailing what might be a blindly obvious attack vector — search engine advertising. A bad actor picks a company or common search term, pays for placement on a search engine, and then builds a fake web site that looks legitimate. For bonus points, this uses a typosquatted domain, like adobe[dot]cm or a punycode domain that looks even closer to the real thing.

The FBI has a trio of recommendations, one of which I whole-heartedly agree with. Their first suggestion is to inspect links before clicking them, which is great, except for the punycode attack. In fact, there are enough lookalike glyphs to make this essentially useless. Second is to type in URLs directly rather than using a search engine to find a company’s site. This is great so long as you know the URL and don’t make a typo. But honestly, haven’t we all accidentally ended up at website[dot]co by doing this? Their last recommendation is the good one, and that is to run a high-quality ad-blocker for security. Just remember to selectively disable blocking for websites you want to support. (Like Hackaday!)

Exchange Still Targeted

And the other report, a PDF from Prodraft, details the activities of FIN7, who have added ransomware to their criminal portfolio. These attacks are launched through multiple means, including malicious USB drives and using known Exchange vulnerabilities, such as CVE-2020-0688 and the ProxyShell family of problems.

And speaking of which, ProxyShell/ProxyNotShell isn’t dead, as there’s been another bypass found in-the-wild. This isn’t an effective bypass against the November 8th patch, but does bypass the rewrite rules that were touted as an effective mitigation. The reason is that this attack doesn’t use the autodiscover endpoint, but applies the same technique to the OWA (Outlook Web App) endpoint instead.

Password Manager Fail

LastPass isn’t the only password manager in the news, and the problems found in Passwordstate makes the recent LastPass issues seem like the most minor of inconveniences. Passwordstate is an enterprise solution for password management. Researchers at modzero started with the browser extension, that allows a user to access saved passwords. To authenticate, a token is generated and sent to the server. Turns out, that token is just the username and other user information, XOR’d with a static, universal key. And on the server side, the only check that happens is on the username. So on any Passwordstate install anywhere, if you can talk to the API, and know a valid username, you can pull every password accessible to that account.

That same API has another problem, any user can write to any other user’s stored passwords, including the login URL for a given password. And since the whole interface is web-based, Cross-Site Scripting attacks are the way to go. There is, of course, insufficient sanitisation. An administrator can use the API to run Powershell scripts. So spray the malicious link into other user’s URLs, and wait for an admin to use the interface to login somewhere. The powershell script runs, starting a reverse shell. And because the stored passwords aren’t usefully encrypted (AES encrypted, but the key is stored, obfuscated, on the same machine as the database), this allows an attacker to abscond with the entire database of passwords. The vulnerabilities have been fixed in release 9.6 Build 9653, though seeing the severity of issues and other problems, one has to wonder how effectively these problems were dealt with.

Linux Does the Samba (Badly)

There’s a perfect 10 vulnerability in the Linux kernel. CVE-2022-47939 is a problem in the ksmbd driver, that was added last year for the purpose of faster SMB performance. SMB here meaning the Server Message Block, the primary file-sharing protocol for Windows machines. The problem is a dangling pointer, allowing for a use-after-free. The solution is a one-line patch that sets the pointer to null upon close.

Now as scary as a CVE scoring a severity score of 10 seems, I’m pretty sure you have nothing to worry about, even if you are a Linux user or manage a Linux server. Why? Because while ksmbd is officially in the kernel, hardly any distros are compiling it into their official kernels, the Samba project isn’t using any of the vulnerable code, and it’s already a horrible idea to expose any SMB service to untrusted connections. Or put another way, if you’re making use of the ksmbd driver, you did it on purpose.

The Kernel config option is CONFIG_SMB_SERVER, and you can check your current config in either /proc/config.gz or /boot/config-$(uname -r). Alternatively, use lsmod to search for the ksmbd module. The real place where this could be a real issue is in a NAS appliance that runs Linux under the hood, though my guess is that the kernel module is new enough that none of the popular appliances on the market are making use of it. Be sure to let us know if you’re aware of a major distro that compiles the module in by default, or a NAS that uses it.

Google Home Takeover

Google’s smart home devices are based on the same firmware as the Chromecast, and use a similar under-the-hood approach to authentication. [Matt] noticed this, and started wondering, could that be a security problem? See, playing a video on a TV isn’t terribly dangerous, but a smart speaker has access to a few more important abilities. Chromecasts serve a key on a local API, and sending a request with that key off to Google links the device to your account. The intent is that anyone on the local network should be able to cast to the TV. It seems like it was unintentional that the process worked on other smart devices.

But wait, there’s more. These devices have a setup mode, where they broadcast an open WiFi network. All it takes to trigger this mode is to knock the device offline — and that’s as easy as sending spoofed deauth wireless packets. Connect to that network, make the API request, and you have the secret key. Let it reconnect to the real network, and you can authenticate as a new verified user. Smart home actions let you do some interesting things with other devices, but just the ability to make a quiet phone call from the device is creepy enough. Google agreed, and removed both the unintended auth flow and ability to call a phone number via a routine.

Bits and Bytes

The TYPO3 content management system fixed and announced an RCE earlier this month. This one was only accessible by authenticated users with access to the Form Designer module, but allowed injection of TypoScript that could be executed as PHP code.

Do not trust save games from the internet. This is good general advice, but specifically applies to games built on Ren’Py, a visual novel engine built on Python. For loading save games, the pickles library is used — it’s already notorious for being unsafe when unpickling untrusted data. It’s just not obvious that save games can deserialize themselves right over Python functions and take over program execution.

The Netgear RAX30, and possibly other models, run the pucfu application on on boot, checking for firmware updates from a Netgear domain. Researchers at NCC Group have discovered that if they control the JSON response to that request, the binary can be manipulated into command injection, leading to a reverse shell.

from Blog – Hackaday https://ift.tt/zyvHK4F