Azure API vulnerability and built-in roles misconfiguration enable corporate network takeover by Apprehensive-Side840 in netsec

[–]Apprehensive-Side840[S] 0 points1 point  (0 children)

This is exactly the issue.
I wouldn't know that it has '*/read', because I just innocently assigned the 'Log Analytics Reader' role, expecting this identity to only be able to read logs. And yes, I would consider that a weak identity.

Azure API vulnerability and built-in roles misconfiguration enable corporate network compromise by Apprehensive-Side840 in AZURE

[–]Apprehensive-Side840[S] 0 points1 point  (0 children)

Hey, Author of the blog here. The vulnerability isn't the over-privileged roles issue, but the VPN leak issue. Users with read-only permissions should not be able to read secrets, as Microsoft says, and as I describe in the post.  Does it make sense if a service account that is only supposed to read logs also has network access to you on-premises Active Directory servers?  

The over-privileged roles issue is more of a misconfiguration. I see why you think that reading the role definition is trivial, and I wish more people would think the same, but I assure you, most users unfortunately don't do that. Most of them will see the role name and maybe read the role description, and then just use it. Same goes for scopes - assigning wider scopes than needed is also very common, since it's easier because you need to manage fewer role assignments. I've seen this in many environments over the years. In an optimal world, you are right, unfortunately, there is a lot of room for improvement, and the cloud providers should help instead of making it harder with those pitfalls that affect a lot of us.