Azure VMs are virtual machines running on Microsoft hardware; this is similar to EC2 instances at AWS. This is the essence of cloud computing.
Azure VM allows developers and admins to integrate custom plugins in order to add additional components to the VM, such as diagnostics, network watcher and others. These extensions are loaded via the Guest Agent. In order to update itself, the Guest Agent polls the Fabric Controller in order to deploy extensions.
The agent communicates with the controller by accessing a local IP address at 168.63.129.16. In order to communicate securely, asymmetric encryption are used. To get the keys to communicate, a Certificate endpoint is used in order to get the keys (cert in the configuration file).
By crafting your own key and certificate, the endpoint would simply send the keys over! So, this lack of validation of the user making the call is clear problem, as this leaks some serious information. With these keys, it was possible to decrypt the Azure VM extension configuration files, which sometimes held important secrets.
However, the bug above did not work as a non-root user because of IP tables setup to prevent that exact issue! In order to bypass the security mechanism, a different IP was used. The IP 164.254.164.254 was not blocked by the IP tables but resolved to the proper address. That was a really simple bypass!
Overall, these were two simple bugs: lack of proper authentication and a poorly implemented denylist. Reversing is sometimes the hard part while the bugs are the easy part.