The threat of Azure service tags

Like all real disruptions, firewall objects have a sunny and a dark side.

In Azure, the most important firewall objects are network Service Tags, which are managed by Microsoft, and IP Groups, which are managed by customers.

AWS counterparts are called prefix lists (some are AWS-managed, others are customer-managed).

The sunny side

In the Public Cloud, firewall objects are super useful when referenced in PaaS firewall rules (network security groups, application groups), because of the dynamic nature of services integration: services scale, assets get (re)deployed by infrastructure-as-code factories, ...

Also because of the shared cloud security responsibility model which demands an efficient, almost real-time way for a party to adapt when the order party changes things.

The dark side

When a single feature is used to serve two separate purposes, there is a high danger of confusion. Unfortunately, this is what happened to network service tags: yes, Microsoft manages all network service tags. No, Microsoft does not manage all assets hidden behind those tags.

All network service tags cannot be mapped to trusted Microsoft sources.

We've known this for years. We knew that, sooner or later, someone would leverage the confusion for the better or for the worst...

This is what happened yesterday! Liv Matan , a highly proficient security researcher working for Tenable proposed a proof-of-concept .

Microsoft's stand

On the blog of the security response center, Microsoft stated:

"we've updated our documentation to remind customers of the function of service tags".

This is no joke.

I don't know if customers should laugh or cry.

Analysis of Microsoft's stand

Microsoft seem to be facing three serious problems:

A security accountability issue. As already raised by the CSRB during the Midnight Blizzard incident investigation, Microsoft seems to deny part of the role it plays in the shared security responsibility model. If something is managed by Microsoft, it is not up to customers to compensate for poor design choices. Service tags and NOT IP groups: they fall clearly and squarely into Microsoft accountability domain.

A risk prioritization issue: clearly, security is not job zero at Microsoft (this was also a point raised by the CSRB). When in a bad mood, I would rather say security is "job null". How could the confusion between trusted and untrusted sources remain that long into the mind of security managers in charge of service tags (if any manager is in charge)?

A network reachability issue. Recently, Microsoft announced with bells and whistles that flow logs could produce synthetic data to help tracking connectivity issues... Synthetic data is the stone age of reachability analysis. Two years ago, I reverse-engineered sec Guru, a very powerful tool developed by Microsoft research to perform automated network routing policy updates validation.

I modified and enriched sec-Guru to support service tags :

If a lonely rider like me can do that as a local pet project, then why Microsoft network engineering teams wouldn't?

Ironically, AWS used sec Guru (and several other sources) to create Tiros, a downright, full-featured network reachability formal prover.

AWS doesn't need synthetic data to determine whether an asset is reachable.

Here is the claim from their original paper:

Could Tiros help prevent AWS-managed prefixes from being subverted to exploit customer assets? I strongly believe so.

What about you?