Normalization gone wrong, Mastodon, when attempting to normalize a domain would intend to remove any trailing /from it, however they did this using .delete("/") which removes all / characters from the string instead of just a trailing /. This meant that someone could use an account like [email protected]/cial to spoof the account [email protected].

A request smuggling to global cache poisoning chain impacting Akami Edge nodes in front of an F5 BigIP server.

The request smuggling is interesting, its a CL.0 style smuggling, where the Content-Length is incorrectly treated as 0, so the body of the request gets treated as a new request all together. In this case they are using a malformed Content-Length header by including a single space before the header name, eg. ` Content-Length:. This results in Akami recognizing and reading the value from the malformed header as the proper Content-Length` value, but when it forwards the request it does so with the malformed header present, and the F5 service does not recognize the malformed header, and defaults to a length of 0 and then reads the request body as a new request, giving an attacker control over the start of the next request. Meaning the attacker controls the request line and can point the request anywhere, along with including unexpected headers in the smuggled request. As the F5 server would cache responses for requests from Akami (any further constrains or keying is not discussed in the original post) they also provided a global cache poisoning primitive.

So the next question is what request to hijack the cached response for, and where to point it. They went for what they referred to as a Host header injection attack, through by including the full URL of the target in the request line, eg. GET http://example.com HTTP/1.1\r\n. Ultimately leading to hijacking SSO pages and redirecting it to an attacker controlled location. Following the redirect they found some requests were leading Authorization: headers, and some were even looking to authenticate via NTLM and so setting up responder allowed them to leak NTLM credentials.

Ultimately I think the request smuggling on this is the most interesting part of the attack, I haven’t seen any other writeups abusing malformed Content-Length headers, so its a nice find and nice to see it mentioned.

Just a somewhat common and vulnerable use a cryptography. The signature of a firmware was not truly a signature but a hash of the content + a secret key, as the binary code that verifies the firmware is present on the device the “secret” key used is not kept secret and one could create their own firmware that would pass the signature check but contain arbitrary content. We covered this post on our bounty-hunting episode, and while few bounty hunters are looking at firmwares, this sort of crypto issue appears all over the place. Developers sometimes see crypto as something they can kinda just sprinkle into their applications, without necessarily understanding the nuances of the different options, we’ve definitely seen similar hashes appear on the web for integrity checks before.