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!

Neat.
https://github.com/amlweems/xzbot

.@amlw wrote a great proof of concept for #XZ to allow code execution via ssh.

Very important note: it doesn’t work in the wild as you need the private key, which only the threat actor(s) have. But you can create your own for exploiting your own servers.

https://github.com/amlweems/xzbot

Here's an exploit demo (yes, really) for the xz backdoor:

github.com/amlweems/xzbot

#CVE_2024_3094

this is how bots army and click fraud take place. your uniq mobile id means nothing. Here is How they build the 3rd gen, 20 mobiles into a server chassis? 3rd generation click farm fraud involves mobile device servers, centralised and operated by one.

@iagox86 Yeah, this looks like someone is TRYING to send an AJP packet your way (that 00 08 in the beginning is the giveaway) but they've screwed up converting it to hex from the raw bytes or something.

Without the Transfer-Encoding header I DEFINITELY wouldn't expect this to hit the same bug...I wonder what exactly is going on there.

Unfortunately this definitely end up getting used in the wild (https://arcticwolf.com/resources/blog/f5-big-ip-rce-vulnerability-actively-exploited-in-the-wild/) so I'm not surprised to see someone launching it at your infrastructure - though from that snippet you posted it shouldn't work so it could be worse =).

I wonder if they'll keep hitting you with variations...who knows, maybe there's a bypass for the fix or something.

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.

Yeah, we didn't explicitly mention the exact payload, though if you want an example you can check out nuclei's PoC at https://github.com/projectdiscovery/nuclei-templates/pull/8496/files#diff-4ce7a843fc5221b42f16c74f632c444ff8b7ba8fcbe2f324041b166ec05f65e5R39.

There's one other thing you need to do as well we didn't mention, which is calculate the appropriate _bufvalue parameter - it's a SHA hash based on concatenating a header (which we can provide via AJP smuggling) and the _timenow parameter. You can also just not provide the header apparently (per PD's payload):

_timenow=a&_timenow_before=&handler=%2ftmui%2fsystem%2fuser%2fcreate&&&form_page=%2ftmui%2fsystem%2fuser%2fcreate.jsp%3f&form_page_before=&hideObjList=&_bufvalue=eIL4RUnSwXYoPUIOGcOFx2o00Xc%3d&_bufvalue_before=&systemuser-hidden=[["Administrator","[All]"]]&systemuser-hidden_before=&name=<username> &name_before=&passwd=<password> &passwd_before=&finished=x&finished_before=

By passing this as the query string for your AJP packet, you can create a user.

@threathunt @pdnuclei @rootxharsh @iamnoooob

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

CitrixBleed in Citrix Netscaler/ADC is under mass exploitation. A ransomware group has distributed an exploit to their operators too.

#threatintel #mspaint
https://doublepulsar.com/mass-exploitation-of-citrixbleed-vulnerability-including-a-ransomware-group-1405cbb9de18?sk=6c6a183bfaa9f69eff86c9c25e4c2326

For what it's worth, we heard back from F5 that a separate security researcher had independently reported this bug to them in the last 2 weeks but wished to remain anonymous. Nature of the beast with this space - likely this is all just a series of coincidences.

Well, it turns out we're not the only folks to find something in F5 this month:

https://my.f5.com/manage/s/article/K000137368

Sounds like someone else found a post-auth SQL Injection vuln. There's also some kind of cache poisoning issue that someone identified. More details on that at https://blog.malicious.group/from-akamai-to-f5-to-ntlm/#on-the-f5-hunt.

For the last issue the author was annoyed there was no bug bounty so they told F5 they were just gonna full disclosure. I suspect our bug was just bundled in with this release to get ahead of it.

Part of me would have loved the idea of accidentally stumbling onto a legit 0-day in the wild, but at this point I'm going to assume that's not the case until I see it proven otherwise.

#f5 #sqlinjection #cachepoisoning #vr #fulldisclosure

@campuscodi

Yeah, there's hopefully going to be patches. At the moment it's just a hotfix script you run to force AJP secrets when connecting to the admin panel webapp. The entire process has been a bit 0-60. A few days ago we were discussing a February 2024 disclosure and suddenly it came out today with a few hours notice. Not entirely sure what's going on there, but I will say the F5 response team has been super friendly and responsive so I'm sure they have a good reason.

Had a very interesting vuln disclosure experience today. I found a pre-auth RCE in F5-BIGIP admin panels (yes...the same one that's had RCE issues for years - there's more) with my coworker Thomas Hendrickson.

We went to report to F5 at the beginning of the month and had some back and forth with them over the disclosure timeline. We're not in a rush, we figured it would take a month or two to disclose, but they wanted to publish it in February 2024. That's a long time to wait for a pre-auth RCE bug, so we asked for it to be sooner, but with 48 hours notice so we could coordinate with our customers appropriately. They said they were fine with that.

Then last night at 8PM ET, we get an email that they're dropping the advisory + hotfix in 16 hours. We asked why and were told "we believe this vulnerability is now known outside of F5 and Praetorian thus forcing our hands at an immediate disclosure". The advisory was published a few hours ago - https://my.f5.com/manage/s/article/K000137353. No patch, but there's a hotfix you can run on some versions of F5s. A few versions have been marked as "will not fix", so this is a permanent way to pop them.

Simultaneously, a blog post that we referenced heavily for AJP Request Smuggling disappeared off the internet (the author locked every post they'd made since 2016). The posts were live 10 days or so ago.

It's likely all a huge coincidence - but regardless, if you want to read about a bug-chain to pop internet exposed F5 Management Panels or learn about AJP Request Smuggling, take a look over at https://www.praetorian.com/blog/refresh-compromising-f5-big-ip-with-request-smuggling-cve-2023-46747/.

Once the patch has had a little bit of time to be applied, we'll drop the rest of the technical information about the bug.

If anyone here is aware of this being exploited in the wild, I'd love to hear about it. Tagging a few folks who are a bit more in the know (apologies if this is spammy, but I'm curious).

On the IoC side it's a bit tricky because the bug relies on abusing a bug in Apache, so I have no idea what it actually looks like in the logs. The raw request will have "Transfer-Encoding: <a valid value>, chunked" as one of the headers. For example "Transfer-Encoding: gzip, chunked" or "Transfer-Encoding: chunked, chunked".

I know it's no #citrixbleed, but this is a pretty bad bug if you're one of the thousands of orgs that still has an F5 config panel on the internet.

@GossiTheDog
@greynoise

#f5 #rce #vr #requestSmuggling #ajp #disclosure

Recently the Praetorian Labs team has been dabbling with some targeted Vuln Research and ended up finding a fairly serious issue in Qlik Sense Enterprise.

I'd never heard of this thing before we started poking it, but there's a fairly sizable number of them (~6000) that are exposed to the internet.

My co-worker Adam Crosser has written an excellent description of the process for finding and exploiting a complete unauthenticated remote code execution bug chain against Qlik - it's at https://www.praetorian.com/blog/qlik-sense-technical-exploit/ and it's a fun read, especially if you're a fan of HTTP Request smuggling.

It's a fairly long post so for folks that are looking for the TL;DR:

Bug: CVE-2023-41265, CVE-2023-41266
Product Security Advisory: https://community.qlik.com/t5/Official-Support-Articles/Critical-Security-fixes-for-Qlik-Sense-Enterprise-for-Windows/ta-p/2110801
Nuclei Detection Template: https://github.com/praetorian-inc/zeroqlik-detect
Detect it with curl [400s mean the server is vulnerable]: curl -H "X-Qlik-Xrfkey: 1333333333333337" -H "Host: localhost" -v -k --path-as-is https://targetserver/resources/qmc/fonts/../../../qrs/ReloadTask\?xrfkey\=1333333333333337\&filter\=.ttf