Now we want to look at the actual templates that were used to create the CloudFormation stacks that we see. We can do this with the CloudFormation GetTemplate command. This command works like the DescribeStacks command, where we can pass in a template name to the --stack-name parameter to retrieve the template for that specific stack. It also works the same in the way that, if you are looking to retrieve the template of a deleted stack, you need to specify the unique stack ID instead of the name. To get the template of our demo stack, we can run the following AWS CLI command:

aws cloudformation get-template --stack-name Test-Lamp-Stack --region us-west-2

The response should include the JSON/YAML template that was used to create the stack we named.

Now there are a few things we can do, but manual inspection of the template is the most effective. Before we start manual inspection though, it might be useful to run a security scanner against the template itself to try and discover any security risks in the assets specified in it. Some of the tools created for this purpose are meant to be set up and used in Continuous Integration (CI)/Continuous Deployment (CD) environments, such as "cfripper" by Skyscanner (https://github.com/Skyscanner/cfripper/). For this example, we'll use "cfn_nag" by Stelligent (https://github.com/stelligent/cfn_nag), which can also be run against individual files/directories containing CloudFormation templates. These tools generally won't catch everything, but they can be a big help in identifying certain insecure configurations.

To use cfn_nag (at the time of writing, this may change as the tool updates), we will assume we have Ruby 2.2.x installed, so we can install the cfn_nag gem with the following command:

gem install cfn-nag

Then, we can save the template we retrieved from the AWS API to a file, such as template.json or template.yaml, depending on the type of template you have. For our demo, we saved it to template.json, so we can run the following command to scan the template:

cfn_nag_scan --input-path ./template.json

The output should look something like this:

The output shows that the template we scanned output 1 failure and 2 warnings. All three are associated with "WebServerSecurityGroup" and its inbound/outbound rule sets. The two warnings are about overly permissive inbound rules allowed through that security group, but if that security group is also defining the SSH inbound rules, then it makes sense that those two warnings showed up. This is because we know that inbound access to SSH is allowed from the 0.0.0.0/0 range , which is not a /32 IP range, and that it means the world is allowed access. Even with that information, it is still worth checking out manually.

The failure that cfn_nag reported will likely be irrelevant until we find a way to compromise the EC2 instance behind the security group—then we will start caring about what outbound access rules are set up. Given that no rules are specified (according to cfn_nag), that means all outbound internet access is allowed and that we won't need to worry about it.

After scanning the template, it is most likely time for manual inspection. Manual inspection will provide us with a lot of information about the resources the template sets up and it is possible we could find other sensitive information stored throughout. After opening the template in our favorite text editor, we can browse through with a few things in mind. We should check out the parameters again to see whether there are any hardcoded sensitive default values, but also because we can possibly get a description of exactly what that parameter is.

Like we expected earlier, looking at the "SSHLocation" parameter, we can see that there is a description that says the IP address range that can be used to SSH to the EC2 instances. Our guess earlier was correct, but this is a good way to confirm those kinds of things. The "Default" key contains the "0.0.0.0/0" value, which means that the stack we have been looking at is using the default value for the "SSHLocation" parameter. Maybe we can find default passwords or IP addresses hardcoded into the templates in some situations.

Next, we will want to check out the resources defined in this template. In here, there are all kinds of possibilities of things we could encounter. One example of this would be startup scripts for EC2 instances that are created. We can read through those looking for anything sensitive, while gaining knowledge about the setup/architecture of the environment that this stack has deployed.

The template that we used for our stack has a few setup scripts that seem to set up a MySQL database and a PHP web server. Ideally, we gain access to one or both of those, so we can scroll down to the "WebServerSecurityGroup" that cfn_nag flagged previously, and we see the following:

"WebServerSecurityGroup" : {
  "Type" : "AWS::EC2::SecurityGroup",
  "Properties" : {
    "GroupDescription" : "Enable HTTP access via port 80",
    "SecurityGroupIngress" : [
      {"IpProtocol" : "tcp", "FromPort" : "80", "ToPort" : "80", "CidrIp" : "0.0.0.0/0"},
      {"IpProtocol" : "tcp", "FromPort" : "22", "ToPort" : "22", "CidrIp" : { "Ref" : "SSHLocation"}}
    ]
  }
}

This tells us that the web server security group allows inbound access to port 80 from any IP address (0.0.0.0/0) and inbound access to port 22 from the "SSHLocation" parameter, which we know was also set to 0.0.0.0/0. Now we can go back to the output values that we checked out earlier for this stack to get the hostname of the server again, where we now know port 80 is open. If we navigate to that URL (http://ec2-34-221-86-204.us-west-2.compute.amazonaws.com/) in our browser, we are presented with the following page:

Beyond what we have just done, CloudFormation templates can be inspected to determine the setup of the various resources that the stack deployed, which could help us to identify resources, misconfigurations, hardcoded secrets, and more, all without the requirement of having AWS permissions that grant access to those actual resources.