“All an attacker needed was a trial subscription to Office 365 and a SAML 2.0 Identity Provider installation. There is some bare minimum of SAML knowledge once must have, but the process of setting up SAML SSO with Office 365 is well documented and easy to follow,” the researchers said. “A more advanced attacker with slightly better SAML knowledge would be able to script a tool and perform the attack in an automated manner without the need of a SAML 2.0 Identity Provider.”
In January of this year, Microsoft patched a vulnerability affecting Office365 (and potentially every Office365 user) that could allow unauthorized access to other users Office365 account (and the data that it contained). The root problem was the way that Microsoft implemented SAML (which is used for federation). Federation is basically a way to allow a number of different / separate services (for example, your office network and Office365) to trust and grant access to one based on the access to the other. A popular tool for facilitating that trust is a technology called SAML (Security Assertion Markup Language).
We hear and see a lot of people making a switch to the cloud with the assumption that simply outsourcing their data to the cloud somehow will make their network magically secure. The reality is that, unless they make changes to their network to make it more secure, this simply means that they’re using their same insecure network to access their data that resides on a third party network somewhere on the other side of the Internet. The blue team in me sees this as a loss of containment and control and increasing the attack surface (instead of my small network being a relatively small target because it’s just me, I’m now a much larger target because the cloud provider is me plus everyone else that uses that provider). The red team in me however loves it because a) the original network is still just as insecure as it initially was, b) the data is now moving out of and in to that insecure network (rather than staying on that network) so I can now grab the data in transit without ever having to breach the original (insecure) network, c) with all of the moving parts (the local network, the Internet connection, the cloud service provider, etc.) glitches and hiccups are expected so I’ve got plenty of places to hide and d) there is a massive disconnect between the owner of the data and the person actually controlling the data, so I’ve got an opportunity to leverage social engineering to breach.
The take away here though needs to be two fold. First, simply moving your data (or some aspect of your operation) to the cloud will not make all of your things magically secure. Second, the cloud is simply technology and is not infallible.