Azure functions is a way to run code in the context of Microsoft's Azure cloud platform. This is a nice feature to have because it allows quick code functions to run upon some trigger. This is similar to AWS Lambda functions.
This is remote code execution by design! So, restricting the environment abilities in a multi-tenant world is important. Otherwise, other users can see or alter the ENVs around them.
By inserting a remote shell in an Azure function, the author noticed an odd environment variable: SCM_RUN_FROM_PACKAGE. The code downloaded for the Azure function package had the r+w flag on the SAS token. By altering this package, an attacker could secretly plant a backdoor on the code package for the functions using this box.
Within an encrypted configuration blob were more SAS tokens. One of the SAS tokens was not scoped properly, which allowed the author to pull arbitrary configurations from other users. Although, these were encrypted.
The x-ms-site-restricted-token header used for authorization was extremely verbose on its error messages. Because of this verbosity the attacker was attempting to launch a padding oracle attack against this endpoint.
A padding oracle attack abuses the outputted error messages from the padding in order to byte by byte deduce the key. This is an extremely powerful vulnerability if it is discovered. This is not an issue with the algorithm itself; it is an issue with how the algorithm is being used.
Sadly, this attack did not work because the padding algorithm did not work properly. Encryption may not always be 100% necessary, but it made this cross-account configuration issue way less impactful. Adding encryption for a defense-in-depth measure can be a good idea.
Overall, interesting findings on Azure not restricting SAS tokens properly. This is likely seen in other places within Azure and other cloud platforms as well.