Summary :
The Sysdig Threat Research Team identified a logging issue with Amazon Bedrock APIs in CloudTrail, where failed API calls were logged as successful, complicating threat detection. AWS has since resolved the issue. #CloudTrail #APILogging #ThreatDetection
Keypoints :
- Sysdig TRT discovered that failed Amazon Bedrock API calls were logged as successful in CloudTrail.
- The issue could lead to false positives and hinder detection efforts.
- AWS was notified and quickly addressed the logging issue.
- The absence of error codes in API responses complicates security investigations.
- Attackers may exploit this logging behavior for reconnaissance without raising alarms.
MITRE Techniques :
- Reconnaissance (T1598): Attackers use API calls to test access to LLMs.
- Command and Control (T1071): Improper logging can obscure malicious activity.
Indicator of Compromise :
- [file name] invoke-model-output.txt
- [ip address] 38.60.146.78
While working on Amazon Bedrock APIs and developing detection mechanisms for Sysdig customers, the Sysdig Threat Research Team (TRT) discovered an unusual behavior in the way some of these APIs were logged in CloudTrail. Specifically, failed Bedrock API calls were logged in the same manner as successful calls, without providing any specific error codes. The lack of error information in API responses may hinder detection efforts by generating false positives in CloudTrail logs. Without this detail, security tools may misinterpret normal activity as suspicious, leading to unnecessary alerts and potential oversight of genuine threats. The Sysdig TRT reported the issue to AWS and they were able to quickly resolve it.
Disclosure timeline
The following image summarizes the interaction between the Sysdig TRT and AWS Security Team from when the issue was found and reported till the final update release:
- July 16: The Sysdig TRT sees incorrect logging.
- July 17: The Sysdig TRT notifies the AWS Security Team.
- July 22: AWS responds, confirming the issue and notifying the Sysdig TRT of the intent to push out a code change to Amazon Bedrock CloudTrail logging.
- August 9: AWS informed the Sysdig TRT that they resolved the issue.
- August 22: The Sysdig TRT responded, confirming the fix. The team also notified AWS about a possible discrepancy in logging the Converse API between the CLI command and the Python SDK.
- August 23 through November 8: Review process for the latest observed behavior.
- November 14: Meeting call between the Sysdig TRT, AWS Security, and Bedrock engineering teams. The latter explained that the observed logging behavior is actually intended, but not documented yet.
Technical details
Over the last few months, the Sysdig TRT has researched how attackers abuse Amazon Bedrock using unauthorized access. During that time, the team noticed a change in the way some Bedrock APIs are logged in CloudTrail.
Most Bedrock Runtime APIs throw several errors (see InvokeModel_Errors), including ValidationException. Until July 8, 2024, events with this error code were logged in CloudTrail with the errorCode and errorMessage fields populated, such as:
"errorCode": "ValidationException",
"errorMessage": "Malformed input request, please reformat your input and try again."This error message can be useful in detecting reconnaissance attempts, as this is one method attackers use to determine if they have access to a specific LLM. The impact of this issue was indeed limited to reconnaissance purposes, and customer data was not exposed at any point.
The last CloudTrail log the Sysdig TRT has for an InvokeModel event with that error code was from July 8, 2024. After this date, the Sysdig TRT began experiencing a different behavior in the API response: Calling InvokeModel or Converse APIs that were previously throwing a ValidationException error no longer contained the error code and message fields. Looking at the log in CloudTrail, the API call appeared successful when it had actually failed.
For example, with the InvokeModel API using an invalid max_tokens_to_sample parameter:
aws bedrock-runtime invoke-model --model-id anthropic.claude-v2 --body '{"prompt": "nnHuman: tell me a random jokennAssistant:", "max_tokens_to_sample" : -1}' --cli-binary-format raw-in-base64-out invoke-model-output.txt --region us-east-1Both before and after the issue was introduced, the API reports the following error as output:
An error occurred (
ValidationException) when calling the InvokeModel operation:max_tokens_to_sample: range: 1..1,000,000
A similar error can be thrown with the Converse API using a negative top_k parameter, as shown below:
aws bedrock-runtime converse --model-id anthropic.claude-3-sonnet-20240229-v1:0 --messages '{"role": "user", "content": [{"text": "Create a list of 3 pop songs."}]}' --additional-model-request-fields '{"top_k": -1}'An error occurred (
ValidationException) when calling the Converse operation:top_k: -1 is not greater or equal to 0, please reformat your input and try again.
Even in this case, despite the API responding in this way, the CloudTrail log did not contain any sign of the error.
The bonus hack for Converse API
The Converse API wraps inference parameters in a single format, simplifying the invocation management of different Bedrock models. This API supports passing inference parameters via inferenceConfig and additionalModelRequestFields, as shown in these examples. By default, Converse requests containing invalid inference parameters are not logged on CloudTrail, because parameters are validated on the client side. This is due to the parameter_validation configuration setting, which has the default value True.
The Sysdig TRT observed that, by passing an invalid parameter within additionalModelRequestFields, an event is still logged in CloudTrail. As a Bedrock engineer explained, parameters passed within additionalModelRequestFields are always checked on the server side because they go through model provider checks. Instead, parameters passed within inferenceConfig do not require reaching the server, but can be validated on the client side. Thus, the request will not be logged on CloudTrail if this validation fails.
It’s important to note that this does not represent a security issue since the client-side validation comes before the authentication check. Therefore, adversaries cannot leverage this technique to check the permissions of the compromised AWS keys bypassing the logging, because the client-side error is thrown regardless of their permission to call the Converse API.
Impact
The main impact of this logging issue was the inability to distinguish between successful and unsuccessful API calls in CloudTrail. CloudTrail is essential for troubleshooting and security investigations to understand what transpired. Without clear differentiation in the API responses, diagnosing issues quickly becomes challenging and problematic.
To improve detections, reducing the number of alerts and prioritizing critical issues often involves excluding APIs that return errors. This approach aims to avoid unnecessary alerts for every API failure, however, it can result in numerous false positives. In essence, the absence of error codes in API responses may obscure the true nature of those calls.
The Sysdig TRT has observed several attackers calling the Bedrock Runtime APIs and throwing these client errors to test their access to LLMs and the availability of those models. This technique allows them to conduct reconnaissance without immediately raising alarms, thereby making it difficult to distinguish attackers’ queries from legitimate LLM queries.
The post Bedrock Slip: Sysdig TRT Discovers CloudTrail Logging Missteps appeared first on Sysdig.
Full Research: https://sysdig.com/blog/bedrock-slip-sysdig-trt-discovers-cloudtrail-logging-missteps/