Various vulnerabilities have been published that (until patched) allowed an attacker to escape a sandboxed, cloud hosted system to gain access to the cloud platform itself. One example is the Azure 0day Cross-Site Scripting exploit published by Chris Dale in 2016. By using an XSS vulnerability in a web server, Chris has managed to crash a site and then attack the troubleshooting SaaS administrators via unauthorized Javascript execution in their browser. This was a relatively easy attack method and only covers a single platform. One thing is for sure; there are more of these vulnerabilities out there, most of them still unknown (to the public). Adequate system patching, regular penetration testing, and real-time security monitoring are the best risk mitigation measures to address these vulnerabilities. These measures will need to be covered by both the customer and the Service Provider to make it most effective. Security often focusses on the very interesting vulnerabilities and exploits, but there is usually less focus on common misconfigurations or bad implementations. A misconfiguration such as a simple or default password, an insecure API or a badly implemented and unpatched hypervisor can also lead to a security compromise. An API, for instance, can be used to manage systems, automatically push or pull data between systems, and many more administrative tasks. If such communication is not secure or there is no proper authentication in place, an attacker could manipulate requests, data, and even the systems itself. The best method to deal with these misconfigurations is to have proper Change Control systems in place, to include Security experts in the review panel and to have solid, secure configuration standards in place. This recently discovered attack method focusses on the manipulation and theft of a user’s cloud synchronization token. The victim is usually hit with malware via a malicious web page or e-mail after which the attacker gains access to their local files. By replacing the cloud synchronization token for one that points to the attackers’ cloud account instead and placing the original token into the selection of files that will be synchronized, the victim at some point unknowingly uploads their original token to the attacker. That token can then be used by the attacker to gain access to the victim’s actual cloud data. From a protection perspective, proactive malware prevention is key here. Detection alone might not be enough because the cloud synchronizations are often scheduled at short intervals. In a reactive environment, a security team member might not be able to respond in time. It only takes minutes for an attacker to download a few Gigabyte of data from a public cloud platform. Another protection control could be cloud-aware Data Leak Prevention (DLP). There does not seem to be much on the market in that area (yet) though. As a final resort, some organizations decide to block cloud applications and sites altogether. Successful attacks on Service Providers are rare, but their impact can be enormous, both to a provider and to its customers. This risk can be managed though. It does require a very broad approach, such as having the right security controls in place, monitoring their output in real-time, capacity planning and adequate change control policies. Expect to see more high profile attacks in this area in the future, with the growth of nation-state attackers and well-funded, well-resourced organizations of cyber-criminals. Attacking a Service Provider requires a higher skill level, more persistence and with that, more resources than attacking the more traditional targets.
