Up first this week is a report from vpnMentor, covering the unsecured database backing a set of dating apps, including 419 Dating. The report is a bit light on the technical details, like what sort of database this was, or how exactly it was accessed. But the result is 2.3 million exposed records, containing email address, photos — sometimes explicit, and more. Apparently also exposed were server backups and logs.

The good news here is that once [Jeremiah Fowler] discovered the database door unlocked and hanging open, he made a disclosure, and the database was secured. We can only hope that it wasn’t discovered by any bad actors in the meantime. The app has now disappeared from the Google Play store, and had just a bit of a sketchy air about it.

WooCommerce Under Siege

Back in March, CVE-2023-28121 was fixed in the WooCommerce plugin for WordPress. The issue here is an authentication bypass that allows an unauthenticated user to commandeer other user accounts.

Within a few months, working exploits had been derived from the details of the patch plugging the hole. It wasn’t hard. A function for determining the current user was explicitly trusting the contents of the X-WCPAY-PLATFORM-CHECKOUT-USER request header. Set that value in a request sent to the server, and ding, you’re administrator.

And now the cows are coming home to roost. Active exploitation started in earnest on July 14, and the folks at Wordfence clocked a staggering 1.3 million exploitation attempts on the 16th. What’s particularly interesting is that the Wordfence data gathering system saw a huge increase in requests for the readme.txt file that indicates the presence of the WooCommerce plugin on a WordPress site. These requests were observed before the attacks got started, making for an interesting early warning system.

OpenSSH Has an RCE

But don’t panic. Yes, there’s an RCE. And yes it bypasses Address Space Layour Randomization, Position Independent Executables, and the No eXecute bit. The good news is that it’s only reachable by going back down an SSH connection that has ssh-agent forwarding enabled.

This calls for a bit of background. SSH is the Secure SHell program, which allows remote command line connection across the internet. Ssh-agent is a helper program than runs automatically and manages SSH keys — those keys that let you log in to another machine without a password. One of the tricks that a sysadmin has is agent forwarding, enabled with the -A flag on the ssh command. This allows the SSH binary on the remote machine to pull keys from the local machine’s ssh-agent process, in order to authenticate an SSH session initiated off to yet another endpoint. It’s always had a warning that it shouldn’t be done with an untrusted machine, to avoid abuse of those keys.

Well now we have yet another reason not to do ssh-agent forwarding. The core observation made by researchers at Qualsys was that the remote machine can trigger a load and unload of all the shared libraries in the /usr/lib* folders. And notably, those libraries load in the context of the ssh-agent application, which is not the intended behavior of many of those libraries. The question then becomes, what mischief can be had with just those two primitives?

To find some interesting misbehavior, a fuzzing approach was used, where all of the available libraries in the Ubuntu repositories were run in this condition and an strace captured. There were some interesting findings, like several libraries setting the stack to executable, and some having the nodelete flag set. Then a handful of libraries set up a segfault handler, and fail to properly deregister it when unloaded. And some libraries just crash right away with a segfault.

This does suggest an attack that might work, using library loads and unloads: Make the ssh-agent stack executable, register a SIGSEGV handler and then unmap the code from under the handler. Then load a nodelete library, which puts useful code under the handler pointer, and finally load a library that crashes, jumping execution to the segfault handler. The right code gadget being executed then jumps to the stack, where shellcode can be waiting in a buffer.

It’s brilliant, and thankfully a very narrow windows of exposure for most of us. The flaw was fixed in an update of OpenSSH this Wednesday. The broader suggestion is to avoid using ssh-agent forwarding, and instead use ssh jump hosts. Or there’s always ssh port forwarding.

Forager

Truffle Security has announced Forager, a search engine for leaked secrets. The idea is that individuals and companies routinely publish things to GitHub that they really didn’t intend to make public. Across all of GitHub, Truffle sees something like 1,800 new secrets leaked a day.

What Forager intends to do is automate the confirmation that those secrets are legitimate, make an attempt at informing the organization of the leak, and then categorize those results in a sane way. If you go to Forager now, you can search through the results, but unless you log in with an organization email address, all the results are redacted.

Bits and Bytes

If you ever wanted to know more about MacOS pen testing, and despaired because nearly every resource is aimed at Windows and Linux, then Cyberark has you covered. In the first installment of what will hopefully be a long series, we’re introduced to the basics of applications in MacOS, covering details like sandboxing, GUI and network testing, and more. This is one to bookmark, for future reference and further articles.

Gigabyte has gotten some free security analysis of its Baseboard Management Controller firmware, since it was all dumped in a ransomware attack a couple years ago. Turns out, that firmware had some really dire vulnerabilities, which Eclypsium found in a code review. Two separate CVEs chain together to make a worst-case CVSS 10 attack scenario. Eclypsium has a bit of grim fun at the expense of lights-out management, calling this finding “Lights Out Forever”.