So what does WinRAR, day trading, and Visual Basic have in common? If you guessed “elaborate malware campaign aimed at investment brokers”, then you win the Internet for the day. This work comes from Group-IB, another cybersecurity company with a research team. They were researching a malware known as DarkMe, and found an attack on WinRAR being used in the wild, using malicious ZIP files being spread on a series of web forums for traders.

Among the interesting tidbits of the story, apparently at least one of those forums locked down the users spreading the malicious files, and they promptly broke into the forum’s back-end and unlocked their accounts. The vulnerability itself is interesting, too. A rigged zip file is created with identically named image file and folder containing a script. The user tries to open the image, but because the zip is malformed, the WinRAR function gets confused and opens the script instead.

Based on a user’s story from one of those forums, it appears that the end goal was to break into the brokers’ trading accounts, and funnel money into attacker accounts. The one documented case only lost $2 worth of dogecoin.

There was one more vulnerability found in WinRAR, an issue when processing malicious recovery volumes. This can lead to code execution due to a memory access error. Both issues were fixed with release 6.23, so if you still have a WinRAR install kicking around, make sure it’s up to date!

Panic at the DNS Disco

Captive portals are a security problem. Apparently. The story here is the ISP in Belarus uses SORM equipment, which allows for targeted surveillance and even HTTP traffic rewriting. And that HTTP traffic manipulation is where this gets interesting.

When you jump on the hotel/coffeeshop/hospital wifi, there’s usually a captive portal — a page with terms and conditions you must agree to before you can reach the internet. In the old days, this was just a simple DNS redirect, so the first web page you tried to pull up would land you here. When it became standard for every web page to support HTTPS, suddenly that model no longer worked. If the captive portal tried to redirect the HTTPS connection, it would trigger a security error in the browser. And if the connection just allowed port 443 traffic to flow unmolested, many users would never see the portal page at all.

The way most of those portals now work is that your OS pulls up an unencrypted web page, like http://www.msftconnecttest.com/connecttest.txt in the case of Microsoft Windows. If that page is redirected, the OS knows there’s a portal, and can display it for the user. But in this case, the ISP was selectively redirecting that DNS lookup, and sending targeted users to a fake Microsoft web page. Because the portal check has to use unencrypted HTTP, the fake page can get away with it too, even using a microsoft.com url.

That page shows a fake Windows update, and running the “installer” infects the target computer with Disco malware. Disco and it’s sibling malware, Nightclub, do the things you expect, like file exfiltration, system monitoring, and more. This malware campaign seems to be selective in targeting, with the known victims so far being embassy computers.

mTLS — Not a Silver Bullet

Years ago, I was involved in a working group for a new security solution, and one of the leaders was a true believer in mutual TLS as a solution for security woes. The idea is that not only would the server have a signed certificate, but the connecting client would, too. If each device trusted the other’s certificate, the connection completes and the protected service can be accessed. Sounds great, but there are some gotchas.

The first issue to be aware of is that unless you specify otherwise, any certificate signed by a trusted host will be trusted. Your mTLS solution can be defeated by a free Let’s Encrypt certificate. Probably not what you had in mind. But that can be fixed by managing what root certificates the server trusts.

Through the years there have been some other problems to keep in mind, like CVE-2023-2422, an attack that includes multiple certificates, with the sender certificate not actually being signed. Because the first certificate in the packet is trusted, the entire collection of certs are trusted.

And then the most fun attack is the revocation chain. A client authentication certificate can include a link to a revocation server, and in many cases the authentication server will follow the link. Even if that’s after the certificate is checked, there’s still quite the opportunity for a Server-Side Request Forgery. In one case, this scenario could even leak a server-side password to an arbitrary endpoint. Yikes. Follow the link for the full rundown.

NVMe — New Vulnerabilities Made easy

From Cyberark we have a walkthrough of using CppCheck to find a null pointer deference in the Linux kernel’s NVMe driver. In the code itself, the problem is an error handling if block, where a struct pointer is set to null, and then the program execution exits the block as if the check succeeded. It proceeds to try to write a log message, containing a member of that struct.

That would be a really minor issue, except for the existence of NVMe over TCP. The next step was triggering the system crash over the network, which works, but requires an authenticated host. But with a bit of manipulation, it is possible to reach this code unauthenticated with a malicious NVMe connection packet. Not great! Thankfully this one was found and fixed within a month, all taken care of on the kernel mailing list.

Bits and Bytes

Android apps use compression for distribution, and it’s possible to use some obscure compression settings to defeat anti-malware scanners. Another approach is to include files with names longer than 256 bytes. And apparently the Android Manifest XML and String pool header can be manipulated to crash inspection tools, and still install on an Android phone. Nifty.

Avanti patched a couple serious problems in Avalanche, their mobile device management system. The flaws allowed for authentication bypass for the administrator portal. In what appears to be a patch bypass, yet another flaw has been found allowing an attacker to bypass authentication. This one, unfortunately, was found in-the-wild. It seems that several customer deployments were exposing this admin portal to the broader Internet, and those deployments have been compromised.

And finally, if you have an install of Juniper Junos OS, be aware of an attack chain that achieves preAuth RCE. This one starts with attacker controlled environment variables, in what is likely an iteration on the Shellshock vulnerability.