Summary

We recently received a critical server-side request forgery (SSRF) vulnerability report through our bug bounty program. The issue allowed attackers to make internal requests from our application servers by exploiting a lack of output sanitization in an error message. By crafting malicious requests, an attacker could have accessed internal AWS services and obtained temporary credentials.

Upon receiving the report, we were able to reproduce and verify the issue. We have implemented a fix that is now deployed in production. Below you can see that element[:template] wasn’t properly sanitized in the error message. The value being returned html_without_layout is being fed into a library that converts this into a PDF.

Diff:

             
html_without_layout = elements.map do |element|
  case element[:type]
  when 'template'
    path = template_path(element)
    if path
      ApplicationController.new.render_to_string(
        partial: path,
        layout: false,
        assigns: {
          include_css: true,
        },
        locals: {
          query_results:,
          constants: PSR_CONSTANTS,
          retesting_reports: retesting_reports,
          reporters: reporters,
          total_submission_count: total_submission_count,
          in_scope_asset_count: in_scope_asset_count,
          report_asset_count: report_asset_count,
        },
      )  
    else
-    "Missing template for element: #{element[:template]}"
+    "Missing template for element"

We have also added regression tests to prevent future occurrences of this vulnerability.

Our forensic investigation concluded that there is no evidence this issue was exploited prior to the report.

We have rated this vulnerability CVSSv3 10 (Critical) based on the potential impact of exposed credentials:

CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N/CR:H/IR:H/AR:H.

We want to thank @mega7 for sending in their report; reports like this one are invaluable for us to continue enhancing our security posture. We also appreciate them for stopping at the right point in testing, demonstrating a responsible and ethical approach.

Report Conclusion:

• The Main Issue:

I was able to access AWS Credentials using an SSRF vulnerability by injecting an <iframe> tag into template element when generating a PDF of analytics reports.

• The potential impacts of this vulnerability:

1. Ability to read internal files.
2. Unauthorized Access to AWS Credentials.
3. Manipulating AWS resources.
4. Possibility of Data Loss.
5. Accounts Takeover.
6. Executing Arbitrary Commands.

• What did I do when I found this vulnerability:

I quickly reported this issue as soon as I found it, then I was trying to find the quickest way to alert Hackerone team as quickly as possible, especially because I know it could take some days for a response. then I thought about sending a message to some of the Hackerone triage team, I was expecting a response within a few hours but it doesn't happened. So I decided to send a message to @jobert, and I was really surprised by his quick and kind response.

• How the Hackerone team was responsible for fixing this issue and how they responded:

I was really surprised by Hackerone quick response, they have fixed the issue and let me retest it in less than 24 hours. They are a very collaborative team.

• Supporting Material/References:

• What to Do If You Inadvertently Expose an AWS Access Key.
• How to prevent server-side request forgery. (SSRF)
• How to prevent HTML injection.
• How to write high quality reports.
• How To: Server-Side Request Forgery (SSRF)

Thanks for reading and have a nice day!

Best Regards, @Mega7