Post

Ok so We do have a for sure, certified vulnerability, that if ASLR if off should work like a charm, but ASLR has been a standard for 20 years, so this is unreliable at best yes? Cloudflares boasting they've implemented defenses, against what exactly?

We know /someone/ has the real POC exploit that does actually work, quite a few someone, but I can not for the life of me find any actual details of what that exploit looks like. Watchtower / Cloudflare claim they're seeing it. but is that actually the exploit?

Does it reliably work with ASLR turned one? And if so have they published the expected incoming structure of the attack? Like I've seen SIGMA rulesets looking for PHP logs AFTER the attack would have worked, but not the actual attack sequence

And like I know part of this is our great Security Theater where we hide stuff for a little bit but like I had a pretty cognizant query string for log4j within an hour. I've seen nothing that isn't vibe coded slop for this.

I guess I say this because like your WAF has been shooting down 1=1 SQL injections for literal decades, and like yeah technically its' defending you against a SQL injection, but much like conficker like it's just not a real threat.

Like with shit like this I expect Query Strings, I expect sample POST headers, something that makes it clear what data is actually being passed to a PHP based webserver to get the OOM exploit working. All I've seen is terminal screens with a .py script they can't show returning a UID for php.

The more I dig into this, the more convinced I become that there isn't actually a working publicly available POC and the "attacks" the honeypots are getting wouldn't work against real systems.

Like with the netscaler vulnerability, I knew literally within an hour of Citrix's patch what the actual POC would look like in network logs. It's been nearly 14 hours since PHP's patch dropped and I still can't for the life of me find examples of what this looks like.

0 reposts0 likes