Bishop Fox named “Leader” in 2024 GigaOm Radar for Attack Surface Management. Read the Report ›

The Unmask IAM Permission: API Gateway Access Logging

Headshot of Chris Scrivana with blog title, Unmask IAM Permissions

Share

In the era of cloud computing, where businesses leverage platforms like Amazon Web Services (AWS) for their infrastructure and services, ensuring robust security measures is paramount. One critical aspect of this is identity and access management (IAM), which governs who has access to what resources within an organization's cloud environment. IAM permissions dictate the level of access granted to users, applications, and services, thereby playing a crucial role in maintaining data confidentiality, integrity, and availability.

However, while IAM permissions are fundamental for controlling access, it's equally essential to recognize the potential cybersecurity risks associated with identity and access management in the cloud. Misconfigured IAM policies, like those reported in our Cosmos: Protecting the Perimeter Report, can inadvertently expose sensitive data, leading to data breaches, regulatory non-compliance, and reputational damage for organizations.

Therefore, understanding the intricacies of IAM permissions, especially in services like AWS, becomes imperative for safeguarding against such threats. Specifically, Amazon API Gateway doesn’t encrypt access logging data by default; instead, these logs can be configured with data protection policies to mask them. However, these logs can still be viewed with the appropriate IAM permission.

API Gateway Access Logging

Access logging allows for detailed events that include full request and response logs. Amazon states this can be useful for troubleshooting, but sensitive data can also be logged. This makes sense, as most information may be transmitted in the request headers/body.

Note: We recommend that you don’t use Full request and response logs for production APIs.

Amazon also states this feature can be used to help troubleshoot API requests; however, it should not be used in production environments. Generally, the following role will be provisioned when setting up access logging - AmazonAPIGatewayPushToCloudWatchLogs.


Observation

You can view access logs in CloudWatch and get an idea of the logging details within the console. If data protection policies are defined (look closer), sensitive information will be masked, and these policies can be defined at the log group level. As an example, we’ll create a data protection policy on a single log group, shown below:

Ccreenshot of the configuration of a data protection policy

Figure 1 – Configure a data protection policy

In the example above, we are setting the AwsSecretKey data identifier. There are predefined data identifiers that will mask the field category based on a keyword. Additionally, you can create custom mappings using regular expressions. But what is data masking? There is a particular IAM permission that allows you to unmask logs. This is interesting because it doesn’t encrypt the data by default. If we were to compromise an AWS environment, we could potentially use this feature to uncover PII data or obtain credentials which could lead to lateral movement or unauthorized access.

Moving on, after we set and configure the data identifier, we can issue an example request using curl that contains a secret key, shown below:

curl --location --request GET 'https://7x18l9o7og.execute-api.us-east-1.amazonaws.com/ll/pets/2' --header 'Content-Type: application/json' --user $ACCESSKEY:$SECRETKEY --aws-sigv4 "aws:amz:us-east-1:execute-api" --data "{\"aws_secret_access_key\":\"K4zyL/[REDACTED]/W+Sr6u\"}"

Figure 2 – Curl request containing sensitive data

After we send the request, we can view the log details to see if the data was masked. We can do this in the AWS console or with the AWS cli. In this case, we’ll view the console first to see the redacted data:

Code showing redacted log in CloudWatch.

Figure 3 – Viewing redacted log in CloudWatch

Next, we’ll temporarily unmask the data:

Screenshot showing the option of unmasking logs through the AWS console

Figure 4 – Unmasking logs through the AWS console

Now, we can view the sensitive data:

Code showing the unmasked log containing secret key.

Figure 5 – Unmasked log containing secret key

However, it’s much easier to query these logs through the AWS cli. As a refresher, we can use the following command to show the current log groups:

$ aws logs describe-log-groups --query 'logGroups[*].logGroupName'
[ 
    "/aws/apigateway/welcome",     
    "API-Gateway-Execution-Logs_7x18l9o7og/ll"
]

Figure 6 – Describing log groups

Next, we’ll run a quick query against the API-Gateway-Execution-Logs_7x18l9o7og/ll log group with the unmask parameter with a search for the secret keyword.

$ queryId=$(aws logs start-query --log-group-names API-Gateway-Execution-Logs_7x18l9o7og/ll --start-time `date -ud "-6 weeks" +%s000` --end-time `date -ud "tomorrow 0 -1second" +%s000` --region us-east-1 --query-string "fields @timestamp, @message, unmask(@message) | filter  @message like /secret/ | sort @timestamp desc | limit 20
00" | jq -r ".queryId")

Figure 7 – log query using the unmask parameter

Finally, we display the query results which show the masked and unmasked data:

$ aws logs get-query-results --region us-east-1 --query-id $queryId
{
    "results": [
        [
            {
                "field": "@timestamp",
                "value": "2024-06-03 17:03:23.610"
            },
            {
                "field": "@message",
                "value": "(2c7a55d8-3d78-4753-8972-e57de7d5dca3) Endpoint request body after transformations: {\"aws_secret_access_key\":\"****************************************\"}"
            },
            {
                "field": "unmask(@message)",
                "value": "(2c7a55d8-3d78-4753-8972-e57de7d5dca3) Endpoint request body after transformations: {\"aws_secret_access_key\":\"K4zyL/[REDACTED]/W+Sr6u\"}"
            },

Figure 8 – query results containing masked and unmasked data

As mentioned earlier, if an account were breached, an attacker could steal PII or even gain access to other services based on the defined logging configuration. Logging can be an overlooked area but can prove fruitful in some cases within an AWS environment. If data protection policies are defined you should take a closer look to see what data identifiers are in use. If you have the unmask permission, you can review the logs and unmask them!

In conclusion, IAM permissions serve as the cornerstone of cybersecurity in cloud environments, particularly concerning services like Amazon API Gateway. As illustrated in the discussion above, a lack of proper access controls can leave organizations vulnerable to various threats and expose sensitive data. Therefore, organizations must prioritize the implementation of IAM best practices, such as configuring access logging with data protection policies, to mitigate these risks effectively.

Subscribe to Bishop Fox's Security Blog

Be first to learn about latest tools, advisories, and findings.


Chris Scrivana Headshot

About the author, Chris Scrivana

Senior Security Consultant

Chris Scrivana is a Senior Consultant at Bishop Fox with over eight years of experience protecting the infrastructure, network, and application stack for high-profile clients. He focuses on application security throughout the development lifecycle and is proficient in cloud and network penetration testing. Chris is adept at consulting with key stakeholders on best practices and future security strategies.

More by Chris

This site uses cookies to provide you with a great user experience. By continuing to use our website, you consent to the use of cookies. To find out more about the cookies we use, please see our Privacy Policy.