Thanks to everyone who came out to see my DEFCON talk!

For folks who weren't able to make it - don't sweat it - you can watch it at https://www.youtube.com/watch?v=_qS01oRTvAk.

The code + slides are available at https://github.com/praetorian-inc/ChromeAlone.

It's been awesome to get to share this with everyone, and I'm already seeing a few users experiment with the code (and help me fix some bugs). If anyone has any issues getting anything running feel free to open an issue or ping me here and I'll respond as soon as I'm able to.

I'm stoked to be presenting at DEFCON this year!

I've been writing support tooling for red teaming for a while now, and the most successful tooling I've ever written has all revolved around abusing Chrome extension/app features. It's been getting my teammates access for 7+ years and we're still going from zero to GG on fortune 50 companies with this approach.

In a few weeks I'll be presenting on the techniques we use, some public and some not previously discussed. I'll also be releasing code that demonstrates how to turn your average Chrome instance into a full C2 implant with features like:

* Full SOCKS TCP proxying
* Shelling out from the browser
* Live credential capture
* Full file system read access
* WebAuthn phishing for physical security keys like Yubikeys

The code will include deployment scripts for server infrastructure as well as code for silently sideloading the above capabilities into Chrome in a post-exploitation context. It's not exactly Sliver, but there's more than enough to run amok in an organization and cause some problems.

If you happen to be at DEFCON, come see the talk live (defcon.org/html/defcon-33/dc-33-speakers.html#content_60300). Code's going live the day I present - looking forward to getting to share this with everyone!

When we're doing vuln hunting on internet appliances, we often want a shell in order to figure out what's going on. For the F5 research we were lucky, you could just SSH into the box and immediately get access to relevant config files and binaries. Lots of other appliances don't like to give out that access, they might give some kind of restricted/custom shell, or maybe they just don't expose anything at all.

In order to get around this, we'll often grab VM images and then boot from a live cd / alternate linux install and mount the disks. More recent Sonicwall appliances prevent this behavior, however. Their disk partitions are all LUKS encrypted, which prevents nosey researchers like myself from being able to mount them via another OS that doesn't have the encryption keys.

What's interesting though, is that if you boot from the base image (as intended), it just works. GRUB does have a mechanism for embedding decryption keys into the boot process, but this often means just leaving the decryption key in the boot partition, which is pretty easy to grab. This is not what Sonicwall NSV appliances do.

I got to spend a fun week diving into how GRUB works in order to figure out just what on earth was happening here - feel free to read about it at https://www.praetorian.com/blog/sonicwall-custom-grub-luks-encryption/.

The TL;DR is that Sonicwall modified their GRUB bootloader to perform decryption key derivation based off of the partition metadata. This is very much NOT default GRUB behavior (as far as I'm aware), so someone at Sonicwall went out of their way to bake this into the bootloader. It was a fun RE experience though, definitely got to learn a lot!

#sonicwall #nsv #grub #reverseengineering

Well, that didn't take long. #cve202346747 has now been reported by F5 as being exploited in the wild. This can be found in an updated section of the advisory towards the bottom at https://my.f5.com/manage/s/article/K000137353.

Interestingly enough, the in-the-wild exploitation is using the SQL injection vulnerability (CVE-2023-46748) in conjunction with the AJP request smuggling attack to achieve access. This vulnerability was also included in the same KB advisory as the AJP request smuggling attack.

Originally I wasn't sure if the SQL injection vuln report was the other security researcher(s) who had also reported the AJP Request Smuggling content to F5, but given the way this is being exploited in the wild it sure looks like this is the case.

Since @pdnuclei has posted a full PoC for #cve202346747 already, we've updated our blog post at https://www.praetorian.com/blog/refresh-compromising-f5-big-ip-with-request-smuggling-cve-2023-46747/ with all the technical details.

Kudos to @rootxharsh and @iamnoooob for SUCH a quick reproduction of the bug as well!

A warning for folks who are going to start spraying this around though:

The process of abusing AJP request smuggling causes Tomcat and Apache to get out of sync. So as you send more of these requests, the de-sync gets worse. Eventually the server gets so out of sync that it becomes incapable of actually serving the correct site once you ask for it.

During testing we regularly would get our F5-BIGIP so jammed up that it was just faster to do a full server reboot than it was to wait for things to clear out normally. There's a secondary bug here in that if you do this enough, you'll eventually catch the login session of someone else trying to hit the server, but given the fact that you can get RCE through this as well, it seems not to be as huge of a deal.

I do hope folks patched though - if you weren't paying attention on Thursday/Friday you're gonna get snuck by this one pretty badly. A 72 hour window isn't a massive amount of time unfortunately.

For what it's worth, at a glance there wasn't anything SUPER insane exposed on the internet when we did a check. We did find one cisa.gov server, which we notified them about and it was taken down before the ball started rolling on this stuff. Lots and lots of telecoms though.

Looks like the good folks at Project Discovery have implemented the full F5 RCE attack chain in a Nuclei Template already. That didn't take long at all, I suspect we'll be posting the rest of the blog this week.

https://github.com/projectdiscovery/nuclei-templates/pull/8496

#CVE202346747 #f5 #nuclei #projectdiscovery