Handling Cookies is a Minefield:
inconsistencies in the HTTP cookie specification and its implementations have caused a situation where countless websites (including Facebook, Netflix, Okta, WhatsApp, Apple, etc.) are one small mistake away from locking their users out.
https://grayduck.mn/2024/11/21/handling-cookies-is-a-minefield/
David Schinazi mentioned @april's cookie blog post and I'm sorry but I had to do a "I told you so".
On the httpbis list.
https://lists.w3.org/Archives/Public/ietf-http-wg/2024OctDec/0231.html
How to debug Windows service processes in the most old-school possible way...
We found our first #Y2K38 bug today, in #Keycloak‘s Client credential rotation feature. https://github.com/keycloak/keycloak/issues/35104
Will probably not be the last one - the runup to 2038 will be interesting.
HOPE XV videos just dropped on YouTube! https://www.youtube.com/channel2600
#CISA has been doing a really good job promoting sensical #infosec practices over the last few years.
I'm not looking forward to the change in direction that Jen Easterly's departure and whatever ghastly appointees the new administration comes up with will mean.
https://www.nextgov.com/people/2024/11/cisa-director-jen-easterly-depart-inauguration-day/401036/
What's with the "/.js.map" addition to the URI in the first request to a vulnerable server?
Usually PHP installations will be set up with the web server to handle PATH_INFO as passed arguments to a PHP endpoint. For example, a request URI to /target.php/lol.wtf will result in the PHP web server treating "target.php" as the endpoint code to run, and passing "lol.wtf" as a PATH_INFO sent to PHP.
This is all fine and good, EXCEPT for when app authors configure the server to handle endpoints differently depending on what the URI target is. For example, I might say that targets ending in .txt are perfectly safe, so I don't need to do any of that pesky security stuff. So, if I configure my web server to handle requests targeting *.txt to do something, I need to realize that a request for /target.php/lol.txt is NOT a request that is targeting lol.txt. It is targeting target.php, and "lol.txt" is passed to it via PATH_INFO.
What's happening in CVE-2024-0012?
Palo Alto is handling locations that end in .js.map don't need to bother with setting X-pan-AuthCheck header values (no inclusion of proxy_default.conf)
The problem? a request to anything.php/.js.map will match the nginx directive for the location, but at the same time will be sent to anything.php. This isn't the first time such semantic ambiguity leads to vulnerabilities in software. The same technique was used to exploit OwnCloud's CVE-2023-49103:
By requesting "GetPhpInfo.php/.css", an attacker is able to bypass all of the Apache rewrite rules, since the URI ends in .CSS and CSS files are harmless. 😂
Except whoever wrote those rules was apparently unaware of Apache's AcceptPathInfo configuration behavior.
Trellix: When Guardians Become Predators: How Malware Corrupts the Protectors
A malware campaign drops a legitimate Avast Anti-Rootkit driver (BYOVD) to terminate security processes, disable protective software, and seize control of the infected system. Indicators of compromise provided.
#byovd #avast #ioc #threatintel #infosec #cybersecurity #cyberthreatintelligence #cti
In an ideal world for reverse engineering, every function would have a name, and every variable would be correctly typed. Take a step towards that world, learn to build your own custom Ghidra Data Types in my latest post: https://medium.com/@clearbluejar/everyday-ghidra-ghidra-data-types-creating-custom-gdts-from-windows-headers-part-2-39b8121e1d82
here at macrosoft we offer only the most bloated software for your SSD to fight for its life over. Because it’s not as funny when your PC isn’t on the verge of bursting into flames when it boots
the c2.com wiki (the very first wiki) now requires javascript to render. the web i knew is dead