FN–15 HackerOne

Disclosing BCC Recipients of an email

Disclosing BCC Recipients of an email

Summary

This post will cover an interesting logic flaw found in a private bug bounty program. Whilst the name of this company will be known as [REDACTED], the purpose of this post is to demonstrate how we can turn a feature into a bug. The feature in question allows users to send and receive emails in a secure manor but by checking a few response headers the integrity of the application is broken. Here's the report submitted via Hackerone albeit slightly redacted..

Report

The [REDACTED] product has an end point /rest/users/preauth which is used to validate whether a user has access to a certain object before redirecting them to a login page.

The issue is that this logic can be used against [REDACTED] to work out who an email was sent to. This itself may not be a huge worry but I am able to disclose whether a user is within the BCC field, without authentication - this would be a privacy issue and goes against concept of a blind carbon copy.

Steps To Reproduce

Lets say my business decides to use [REDACTED] as a product, we have 8 members of staff who's emails are as follows:

  • ashleyking@wearehackerone.com
  • ashleyking+original@wearehackerone.com
  • ashleyking+bcc@wearehackerone.com
  • ashleyking+user1@wearehackerone.com
  • ashleyking+user2@wearehackerone.com
  • ashleyking+user3@wearehackerone.com
  • ashleyking+user4@wearehackerone.com
  • ashleyking+user5@wearehackerone.com
  1. User ashleyking@wearehackerone.com sends an email to ashleyking+original@wearehackerone.com and BCC's ashleyking+bcc@wearehackerone.com.
  2. Both of the recipients receive an email - only ashleyking+original@wearehackerone.com is visible in the message headers
  3. ashleyking+original@wearehackerone.com can now use the Intruder feature of Burp Suite to see if any of their colleagues were BCC'd into the email.

Step 1

Create a new request in the Intruder tab, set the target to be hackerone.bounty.[redact].net and Port 443 (use HTTPS)

Step 2

Create the request in the positions tab. Where w= is followed by the ID of the email. You can find this in the link that was sent via the email.

We also need to include the header X-[redact]-Version with a value of [redact]

Step 3

Add your known list of users within the business to the `Payloads` tab. (encode the `+` symbol if necessary)

Step 4

Start the attack. For this particular example we will see the following output:

  • If we see a response status of 200 we can confirm that the user is a recipient of the email
  • if we see a response status of 403 we can confirm that the user is NOT a recipient of the email.

Impact

A user is able to validate whether any of their colleagues has been BCC'd into any email they receive. This defeats the original purpose of a blind carbon copy and breaks the integrity of the email sent from [REACTED].

This business logic issue was worth $750

Disclosure Findings are always reported privately to the vendor first. Technical detail is held back until fixes have been shipped.

006 Engagements

Want this kind of thinking aimed at your stack?

Web application pentesting, API assessment, Android analysis and bug bounty engagements — booked directly, no account managers in between.