The watchTowr folks published an in-depth article today covering the Palo Alto Networks unauthenticated RCE at: https://labs.watchtowr.com/palo-alto-putting-the-protecc-in-globalprotect-cve-2024-3400/

Even more impressive is they also disclosed a zero-day directory traversal vulnerability in the #golang gorilla/sessions package (used far and wide). The gorilla vulnerability only applies to code using the FilesystemStore, but it is still likely to impact a huge range of products and services. A pull request to fix this is open at https://github.com/gorilla/sessions/pull/274

Huge thanks to @alizthehax0r and the watchTowr team as well as @moloch of Bishop Fox for co-discovery (and providing a fix for) of the gorilla/sessions bug.

Palo Alto - Putting The Protecc In GlobalProtect (CVE-2024-3400)

Welcome to April 2024, again. We’re back, again. Over the weekend, we were all greeted by now-familiar news—a nation-state was exploiting a “sophisticated” vulnerability for full compromise in yet another enterprise-grade SSLVPN device. We’ve seen all the commentary around the certification process of these devices for certain

watchTowr Labs - Blog
@hdm @alizthehax0r @moloch A colleague pointed out that the docs of the Session.ID field where Palo Alto is putting attacker controlled data say “The ID of the session, generated by stores. It should not be used for user data.” so this might not be gorilla/session’s fault really.
@filippo @alizthehax0r @moloch ah! good to hear! hopefully most applications aren't passing ~hot garbage~ user input into the Session ID, sounds like additional digging is needed to see what's vulnerable.
@hdm @filippo @alizthehax0r I do think that is correct based on my understanding, however it seems to me to be "more correct" for the session code call filepath.Base since it's clearly intended to be joining a single path segment, and makes it harder to misuse the library.
@moloch @hdm @alizthehax0r oh 100%, the robustness change is definitely good, thanks for sending it. Just important in understanding how other projects will be affected.

@moloch @hdm @alizthehax0r you know, I am not too convinced this is even in gorilla/sessions.FilesystemStore?

https://labs.watchtowr.com/palo-alto-putting-the-protecc-in-globalprotect-cve-2024-3400/ has it in a thing called SessDiskStore which calls paloaltonetworks_com_libs_common_Warn. Maybe they copy-pasted the unsafe code?

gorilla/sessions actually uses github.com/gorilla/securecookie to store the session ID in the cookie, not a plain SESSID.

Palo Alto - Putting The Protecc In GlobalProtect (CVE-2024-3400)

Welcome to April 2024, again. We’re back, again. Over the weekend, we were all greeted by now-familiar news—a nation-state was exploiting a “sophisticated” vulnerability for full compromise in yet another enterprise-grade SSLVPN device. We’ve seen all the commentary around the certification process of these devices for certain

watchTowr Labs - Blog

@moloch @hdm @alizthehax0r

I'm growing convinced this is not a vulnerability in gorilla/sessions.FilesystemStore at all, but in a Palo Alto internal gorilla/sessions.Store implementation called SessDiskStore which works similarly but critically doesn't protect the session ID with securecookie.

https://github.com/gorilla/sessions/blob/3eed1c4ffcde6f23b6f88068c63c1ef6190df331/store.go#L191

sessions/store.go at 3eed1c4ffcde6f23b6f88068c63c1ef6190df331 · gorilla/sessions

Package gorilla/sessions provides cookie and filesystem sessions and infrastructure for custom session backends. - gorilla/sessions

GitHub

@filippo @moloch @hdm @alizthehax0r I just now came to the exact same conclusion after tracing how I’m using gorilla/sessions in scan2drive.

They must have implemented their own store, which puts user data into the field that gorilla explicitly labels as “do not put user data here”: https://pkg.go.dev/github.com/gorilla/sessions#Session

sessions package - github.com/gorilla/sessions - Go Packages

@filippo @hdm @alizthehax0r From my, admittedly cursory look, I think at a minimum you need to pass user input to the session ID, which doesn't seem to be a common use case from looking around Github at other projects implementing the library. So notifying other projects may not be nessisary short of an abundance of caution.