The Unmask IAM Permission: API Gateway Access Logging

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:

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:

Figure 3 – Viewing redacted log in CloudWatch

Next, we’ll temporarily unmask the data:

Figure 4 – Unmasking logs through the AWS console

Now, we can view the sensitive data:

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.