Two vulnerabilities. Firstly the SCM_RUN_FROM_PACKAGE environment var within the Azure Function container contained a “Shared Access Signature” (SAS) that was scoped for r/w. This means an attacker who compromised the function could replace/backdoor the package that would be run.

The second issue was the CONTAINER_START_CONTEXT_SAS_URI which pointed to a MS owned blob, and was an encrypted configuration file for the function. Decrypted using the CONTAINER_ENCRYPTION_KEY. Being able to read your own config isn’t much of an issue, but the SAS was scoped to be able to read any of the configs (encrypted) within the same bucket.

This, the author thought could be chained with another bug in the Init Mesh HTTP service, which would decrypt the a “restricted token” that is passed in. It had verbose error messages, including a warning if the padding was incorrect. This meant that the author could potentially run a padding oracle attack by passing in the encrypted config as the token against a victim init mesh service. Unfortunately the service didn’t do padding validation correctly so this wasn’t an option, but really only luck saved the Azure team here unless that incorrect calculation was for security purposes.