AWS - Utilizing Access for Unauthorized Actions

Test at your own risk.

Just for education purpose.

AWS has developed several "best practices" for operations and security when using its cloud platform. This guidance has been modified over the years to better align with a more secure design. However, the changes are not retroactive, so customers who did not follow the design guidance will need to adjust their operations. AWS itself has struggled with its original infrastructure design, which predates today's generally accepted best practices for security and operations. AWS is one of the first, if not the first, cloud providers to have a backward compatibility problems. Many of its customers have operationalized what would not be considered best practices for cloud component connectivity and management today. By understanding how AWS environments work and how they have instructed their end users in building and operating their systems, we can understand how to break into them more easily.

AWS attacker tools can help automate many of the actions we want to perform, and not every tool is integrated with a framework we are used to using. However, we can use scripts and tools to perform complex queries and attacks. Let take a look at some of these tools to understand how best to use them and how they work. This can help you develop your own attack tools and fill the gap you will find in attack-focused tools for AWS.

RedBoto is another collection of tools, mostly one-off scripts that wrap the Boto library like the other tools, but it is not a framework. It does, however, contain some notable scripts that are worth mentioning because they can help with operations offensively:

• A script to enumerate the locations where CloudTrail is enabled. This is useful for enabling tools like GuardDuty and other monitoring and security systems.
• A script to check what kind of user data is available on a system. This can be useful because to command is rather difficult for inexperienced users.
• A script to execute commands through the Amazon SSM system, which is manager for commonly used systems.

RedBoto consists of a number of scripts, and one of the scripts is used to exploit AWS services. Some of the RedBoto scripts are designed as one-offs and have little uniformity or error handling. Still, for many who use these scripts, practice is key. Let's run the script:

The describeInstances.py script is a simple EC2 enumeration script goes against a list of regions. While this is not a full list of regions, the script is designed for simplicity over complexity.

Differences Between Azure and AWS

Since we just covered AWS in this article, it would be good to discuss the key differences between the two cloud environments - specifically, what you might encounter as an attacker that might surprise you.

The first is that many enterprises use Azure AD in some form. AWS does not provide users with an identity provider (IdP), but uses API keys for programmatic access. AWS uses its IAM to describe exactly what services and resources you can use in the AWS system.

AWS system can use. If you are coming from Azure or AWS and trying to move assets between these two systems, the permissions and structures in their application will be very different. This may confuse you or you may just not like how they work in comparison.

Aside from permissions, another big difference between AWS and Azure is some of the out-of-the-box features of these services. Azure offers several out-of-the-box ways to automate the management of systems. Azure VMs have a feature called "run-command" that allows code to be executed. There are also a number of options in tools such as Custom Script Extensions for executing system operations.

These toolsets are built-in and available by default. In contrast, with AWS, you have to set up the tools to do this.

Finally, there are differences in the way some of the services are built, with very little separation on the same host. One example is Azure Functions for Windows. Azure Functions are like Lambda in AWS, with subtle differences. Azure Functions in Windows that are created in the same "application", "Application" share the same drive and have no separation of drives. This is because Windows has not worked with containers in the past, so Azure Functions for Windows has this problem.

Azure uses the concept of a user account or service Principal, which works like a service account. Azure AD, because it is an IdP, can use different OAuth flows. This is different from AWS, which uses static or volatile API keys. This also means that we will be doing attacks on the APIs in Azure that are username and password based, since access to these users is both via the web and the command line interface (CLI), which is very powerful.

References:

Gray Hat Hacking: The Ethnical Hacker's Handbook.

#AWS #Azure #Pentest #CloudSecurity