Monetr — CraftedSignal Threat Feedhttps://feed.craftedsignal.io/vendors/monetr/Trending threats, MITRE ATT&CK coverage, and detection metadata — refreshed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioThu, 02 May 2024 12:00:00 +0000Monetr Lunch Flow SSRF Vulnerabilityhttps://feed.craftedsignal.io/briefs/2024-05-monetr-ssrf/Thu, 02 May 2024 12:00:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-05-monetr-ssrf/A server-side request forgery (SSRF) vulnerability in Monetr's Lunch Flow integration allows authenticated users on self-hosted instances to send HTTP GET requests to arbitrary URLs, potentially exposing sensitive information.A server-side request forgery (SSRF) vulnerability was identified in the Lunch Flow integration of Monetr, affecting self-hosted instances. This vulnerability allows any authenticated user to cause the Monetr server to issue HTTP GET requests to arbitrary URLs, with the response body from non-200 upstream responses reflected back in the API error message. The URL validator on the POST /api/lunch_flow/link endpoint lacked sufficient filtering, failing to block loopback, RFC1918, link-local, or cloud-provider metadata addresses. This allows attackers to potentially access internal resources or cloud instance metadata. The vulnerability was addressed in Monetr version 1.12.5. The hosted my.monetr.app service is not affected because LunchFlow.Enabled is set to false.

Attack Chain

  1. An attacker registers an account on a vulnerable self-hosted Monetr instance where public sign-up is enabled (AllowSignUp=true).
  2. The attacker authenticates to the Monetr instance.
  3. The attacker crafts a malicious POST request to the /api/lunch_flow/link endpoint, providing a URL pointing to an internal resource, such as a cloud metadata endpoint (e.g., http://169.254.169.254/latest/meta-data/).
  4. The Monetr server, due to insufficient URL validation, accepts the malicious URL.
  5. The Monetr server issues an HTTP GET request to the attacker-supplied URL.
  6. The external service or internal resource responds to the Monetr server.
  7. If the response is not a 200 OK, the Monetr server reflects the response body in the API error message within the JSON response to the attacker.
  8. The attacker observes the reflected response body, potentially revealing sensitive information like cloud instance metadata or internal service details.

Impact

Successful exploitation of this SSRF vulnerability can lead to the exposure of sensitive information, such as cloud instance metadata (e.g., AWS EC2 IMDS). This could allow an attacker to gain unauthorized access to other cloud resources or internal systems. The vulnerable instances are self-hosted Monetr deployments running the default configuration with LunchFlow.Enabled=true and AllowSignUp=true. An attacker could also cause a denial-of-service by providing a URL that returns a very large response body, exhausting the server’s memory.

Recommendation

  • Upgrade to Monetr version v1.12.5 or later to patch the SSRF vulnerability. This version introduces a new config field LunchFlow.AllowedApiUrls and caps response body reads at 10 MiB.
  • For operators who cannot upgrade immediately, set MONETR_ALLOW_SIGN_UP=false to disable public sign-up, limiting access to the vulnerable endpoint to trusted users.
  • Alternatively, disable Lunch Flow entirely by setting lunchFlow.enabled: false in your config file. This will cause the vulnerable endpoints to return 404.
  • Implement network-level egress restrictions to limit outbound HTTP traffic from the Monetr pod/container to only lunchflow.app (or other legitimate Lunch Flow hosts), mitigating the SSRF primitive.
]]>mediumadvisoryssrfmonitrgithub-advisory