<img src="//pixel.quantserve.com/pixel/p-_JKXxuL8SR7wu.gif?labels=_fp.event.Default" style="display: none;" border="0" height="1" width="1" alt="Quantcast">
blog-banner.jpg

Next-Gen CASB Blog

Preventing Man-in-the-Cloud Attacks with a CASB

By Rich Campagna | August 5, 2015 at 11:45 AM
As is common during the week of Black Hat, news is breaking on newly discovered vulnerabilities. The latest? The so-called "man-in-the-cloud" attack, discovered by researchers at Imperva. With man-in-the-cloud, attackers are able to hijack cloud-based file synchronization and sharing apps like Dropbox and Google Drive via exploits on the user's endpoint machine - a far easier target than a major cloud vendor's infrastructure. Once hijacked, the attacker is able to grab copies of all data in the user's cloud account.
 
If it sounds scary, that's because it is. Fortunately, there is a solution - a Cloud Access Security Broker like Bitglass.
 
How does it work? The man-in-the-cloud attack is executed by gaining access to the endpoint, and then replacing the application's OAuth token (which synchronizes to the user's legitimate account) with a token that will cause the app to synchronize to an account owned by the attacker. Once this is done, the app will synchronize every file to the attacker's account. 
 
Fortunately, Bitglass customers can rest easy. Bitglass is a Cloud Access Security Broker that intermediates traffic between cloud apps and the endpoint device. This central point of control fills in the security and compliance gaps typically left in cloud applications - including vulnerabilities to man-in-the-cloud attacks.
 
Any file synchronization and sharing app secured by Bitglass is protected from man-in-the-cloud attacks. The Bitglass service replaces each app's OAuth token with an encrypted token before delivery to the endpoint. As the app attempts to access the cloud app, the encrypted token is presented to the Bitglass service, where it is decrypted and presented to the app. If the attacker were to replace the token with their own, it would fail validation and decryption at the proxy and would not log the machine into the attacker's account.