As you make your journey into the public cloud, you’ll find an emerging trend of HTTP/s web enabled terminals. What I mean to say is, the remote access terminals like SSH and RDP are made available in a user friendly browser after the user has already authenticated to the public cloud console in their browser. Every major cloud appears to be adopting this standard … here’s a few of the big players …
As a developer, this feature seems very nice and quite convenient. In fact, your user permissions even get propagated into the web shell compute instance. Meaning the public cloud server hosting the “shell” can do everything you as a user can do… Unfortunately, these cloud shells run on “containers” that are not managed by your company and do not run your standard security software or even route traffic across your corporate circuits. Most of these shells are advertised as time-limited meaning, after the user sessions expires the shell’s compute are de-provisioned. However, a user’s home folder is detached and persistent, so the users scripts and local data storage are not completely wiped.
Whats the issue?
- Most of these cloud shells have direct internet access which bypasses your IDS/IPS/DLP and corporate proxies network routes
- Malware can either be side-loaded through the internet or via the external persisted storage with the user’s home directory path
- There’s no logs of the local actions, no logs of the internet egress and no antivirus or endpoint HIDS/HIPS
Instead of rehashing a bunch of work that others have done … here a a few articles demonstrating the attack vectors in both GCP and Azure …
Essentially, a simple supply chain attack that leads to the execution of arbitrary code can result in the malware assuming the permissions of the user and creating a command and control to the internet without IR / CIRT team even knowing. IR will be busy looking at the SIEM logs from the AWS platforms which would appear as “legitimate” traffic to the cloud APIs from the user’s shell. Assume the malware has successfully pulled data from a SQL, NoSql, or Object storage database, then data exfiltration outbound to the internet will likely go undetected because the egress does not back haul through your corporate circuits. And remember, this is a product feature not a bug …
What can you do?
Azure recommends you restrict access to the cloud shell FQDN using your corporate network devices but the shell will still be available in the console, for those users who can bypass the proxy restrictions.
GCP has a native option to disable the shell using the console which means the option is not even available any longer unlike the Azure advice.
AWS offers access control restrictions to cloud shell via their native IAM policies, meaning the users or roles must be explicitly mapped to the permissions.
The public cloud providers appear to be making other changes to these shells such as allowing them to be hosted and manged by you on your internal VPCs. At the time of this writing, self managed web shells is not common practice or feature. Although completely disabling such a convenient developer features seems like a draconian security approach, remember that your cloud shell can access company data, secrets and start and stop critical assets.
Typically, in corporate setting you get a bunch of “security for free” that you don’t even know exists. Security capabilities on the desktop, server and network which help detect and sometimes prevent issues from happening when you accidentally download and execute some nasty open source software. Unfortunately in this case, all that “typical” security protection has been removed and the public cloud provider pushes the “Responsibility” and risk back onto the customer.