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.