Why should we undertake security testing of the cloud?
The point here is to emphasise that pentesting in a cloud environment is different from a generic web/api/infra pentest. User-owned entities, identity and access management, user permissions setup, and use of the AWS API linked into the AWS ecosystem are all possibilities and are part of the attached surface to be targeted. Targeting and compromising AWS Identity and Access Management (IAM) keys, gaining access via backdoor functions offered by various services, testing S3 bucket configuration and permission issues, and hiding tracks by obfuscating CloudTrail logs are just a few instances.
The problem this pentesting methodology is trying to solve
The problems reported in the AWS environment have the most serious consequences. There does not appear to be much information accessible when discussing vulnerabilities discovered in a cloud context, as there is no unique exploit scenario. These problems differ dramatically from one cloud provider to the next. Because a cloud environment operates on a shared responsibility paradigm, these issues are far more complicated than they appear to be. This can lead to an underestimation of the danger that an organisation faces. However, from the perspective of an organization’s security, this makes the configuration of the AWS platform and traditional application code or assets in the environment even more critical.
What makes pentesting AWS or cloud environments interesting?
No standard approach exists for pentesting AWS settings because it depends on the kind and size of infrastructure and AWS services. A configuration/feature can be utilised to perform an unexpected action. The AWS security audit/assessment adds value to the application owner’s company because these weaknesses would not have been spotted by any tool, basic pentesting (based on OWASP Top 10 or WASC Classification), or scanner. The fact that users/testers are introduced to several pentesting tools, cloud-specific environments, and a wide array of short and useful demos, makes pentesting an awful lot of fun!
Where can this methodology be applied?
Targeting and compromising Account IAM keys, gaining access using backdoor functions provisioned through various services, testing cloud bucket configuration and permission issues, and obscuring service logs are just a few examples, where the AWS technique could be used.
Why do we think this is an important topic?
There are many myths and misunderstandings about the security of apps hosted in the cloud. One such assumption is that the CSP is in charge of application security. Given that the IPS (Intrusion Prevention System) and anomaly detection systems are used by the Cloud Service Provider to protect against Network-Layer threats, it would be more than okay to conclude that the cloud provider’s network components are well-configured and hardened, so we can trust them.
About the Author
Ankit Giri is an expert in application security, specializing primarily in web application and mobile application security. Part time bug bounty hunter. Featured in Hall of fame of EFF,GM,SONY, HTC, Pagerduty, HTC, AT&T,Mobikwik and with multiple other Hall Of Fames. He loves speaking in conferences, has been a feature at AWS Community Day 2020, DeepSec Austria 2019,BSides Ahemdabad 2019, RSA APAC 2018, BSides Delhi 2017, CSA, Dehradun,Cyber Square Summit, OWASP Jaipur and has been a regular feature at Infosec meetups like Null and OWASP Delhi Chapter, TestTribe and Peerlyst meetups. He is currently working as Tech Lead – Security in DevSecOps practice in Tavisca, a cxLoyalty Technology Platform (Division of JP Morgan Chase & Co.).