ASW #201 – IE11 Goes to Zero

"...were previously believed to be secure" is always a fun phrase to come across in appsec. Here we have a remote side-channel attack that's purportedly able to infer cryptographic keys. The name is an excellent riff on Heartbleed. What's also interesting is that the attack is demonstrated against a constant-time implementation of an algorithm. "Constant-time" is a common countermeasure to side-channel timing attacks -- it's roughly metaphorical to other security recommendations like "use prepared statements". The clever trick here was discovering how the dynamic frequency scaling in modern CPUs appears correlated to the data being processed by a cryptographic constant-time function. An attacker could submit chosen ciphertext to a target that would cause the algorithm (SIKE) to consume less power and have a higher CPU frequency, which translates to an observably shorter time to complete the expected operations. The combination of chosen ciphertext and observable timing difference worked revealed individual bits of the algorithm's key, which made it possible for the researchers to recover the entire key in 36 and 89 hours against two different implementations. Unlike Heartbleed, this probably won't upend sysadmins plans or cause a rush to patching affected servers, but the FAQ notes how Cloudflare and Microsoft have already deployed workarounds. Check out the research paper at https://www.hertzbleed.com/hertzbleed.pdf

Orca Security reveals details of how they were able to bypass tenant isolation in Azure via command injection in a SAML authentication plugin. The walkthrough of the exploit demonstrates a clever use of the LOGIN_URL field for a database connection. Rather than returning a link, the field contains shell delimiters that causes the caller (coming from Azure) to execute the shell commands. It's yet another lesson on the implications of parsing, normalization, and the unfortunate surprises that arise from contexts that can be data or code.

Here's a detailed write-up about a Java deserialization flaw with a JSON-based attack vector. One takeaway is to be explicit about data types when deserializing data. Another is to revisit whether deserializing data is a desirable programming pattern in the first place.

Came across this from the https://riskybiznews.substack.com/ newsletter. The list of vulns here look like classic 90s-era C coding mistakes. The communication timeline looks like two years from discovery to disclosure. For as much as we talk about modern DevOps or point to security work from huge organizations like Google, there's clearly lots of companies out there -- especially in firmware, it seems -- that are still struggling to add security practices to their SDLC.

Ah, the hero's journey as exemplified by appsec: Vuln is fixed. Vuln returns due to refactor. Vuln rediscovered. Vuln is fixed. The catch here is the timeline of that journey and the implications for appsec in terms of the complexity of tracking bugs, creating effective tests, and tracking software changes over a decade.

Another package ecosystem moving to mandatory MFA. This is always good news. Better news is MFA based on FIDO2 keys. Two other details to pay attention to in these kinds of migrations are the timeline -- pretty aggressive -- and what the account recovery process looks like since that's another avenue into account takeovers.

Another package ecosystem moving to mandatory MFA. This is always good news. Better news is MFA based on FIDO2 keys. Two other details to pay attention to in these kinds of migrations are the timeline -- pretty aggressive -- and what the account recovery process looks like since that's another avenue into account takeovers.

Microsoft and Intel released a series of CVEs related to attackers being able to access stale data that previously was used by privileged processes