I thought this was an excellent post when it came to explaining the exploitation strategy, and has it dealt with encrypted pointers the exploitation was pretty cool to see documented. However I did have some problems following on the actual vulnerability details.
At its core, this is pretty easy to understand, and isn't especially novel, but it is an interesting area, stealing cars so worth covering.The core problem is simply that inside of a modern vehicle you have the Controller Area Network Bus (CAN Bus)...
At its core, we have a simple mistake that can be made pretty easily on all of the cloud platforms though this post focuses in on Azure App Services and Azure Functions.Being able to easily add authentication to your apps on either is nice, but they can easily be misconfigured...
The XSS here is fairly basic, attacker controlled data reflected without sanitization, whats a bit more interesting is the input source, plugin metadata processed by the global Jenkin's Update Center.There is a bit of a process to getting plugins listed in the Update Center, submitted a PR and the first plugin needs to be manually approved, though the authors note that this is mostly a procedural thing...
Relatively straight forward oauth hijack/account takeover flow with one interesting aspect in actually performing the login with the hijacked OAuth code.
A long, fairly beginner friendly post about attacking a Bluetooth lock, there is a lot of process information here as it was an intern's research project. What the vulnerability comes down to though is a lack of any real authoization checking instead only validating the integrity (poorly!) of the request and trusting the app did all the heavy lifting.
The vulnerability here isn't too interesting, just a case of user-input being reflected into a header without sanitizing new-lines (CrLf injection). What is interesting is how they leverage this header injection primitive to bypass Akamai's web application firewall.
A small bug in processing/validating the entries in the Merkel tree resulting in the theft of 2 million BNB ($586 Million USD at time of the original theft).
**tl;dr** Android Parcels have their own memory pool rather than being free'd all the way back to the general Java memory pool. This custom memory management, combined with a bug resulting in a dangling reference in a Parcel to an older version of the parcel creates a "use-after-free" like situation
A post on exploiting a bug that Jann Horn discovered in the linux kernel's memory management (MM) subsystem.The bug isn't detailed in this post and is fairly complex (there is a project zero bug report but it's difficult to understand without deep knowledge of MM internals), though they state it will be written up in a future blogpost...