Notifications sent due to "Transfer report" functionality may be sent to users who are no longer authorized to see the report
State Resolved (Closed)
Disclosed publicly 2018-12-04T19:51:45.476Z
Reported To
Weakness Improper Access Control - Generic
Bounty $500
Collapse

Summary by npbhatter17

Summary

Users that were no longer part of a program were not unsubscribed from reports. Users may have seen an in-app notification of a report being transferred after they were no longer suppose to have access. This vulnerability was introduced on July 17, 2017.

Timeline (November 16th, all times PDT)

Time (PST) Action
9:55 AM Report submitted to H1 bug bounty program (this report)
10:27 AM Root cause was identified
10:36 AM Notifications that were sent for the two particular reports were deleted for all users
10:52 AM Internal HackerOne announcement went out not to use the "Transfer Report" functionality for the time being
11:10 AM "Transfer report" feature was disabled, blocking all usage of the feature, which avoids another occurrence
12:06 PM 2110 notifications were identified (affecting 21 programs) that were sent to people who didn't have access to the reports anymore
12:13 PM All 2110 notifications are deleted
2:26 PM Fix was released to production to make sure subscribers are now removed when they're no longer part of a program
2:30 PM "Transfer report" feature was re-enabled
5:09 PM Data migration was released to clean up unauthorized subscribers
5:13 PM Data migration was completed, 2.91M records deleted

Root cause

When a user was part of a program and they'd automatically be subscribed to incoming reports OR they'd manually subscribe, their User object was added to the subscribers relationship on a Report model. When they'd leave the program / be removed, this relationship wouldn't be deleted. This meant that every time we'd use the <report instance>.subscribers relationship, it may have included users who no longer had access to the <report instance>. This is what happened with the Notifications that were created when a report was transferred to another program.

This only affected notifications that were sent when a report was transferred to another program.

The changes that this would happen were rather slim. However, due to the SAML JIT incident, multiple people were added as subscribers to reports of other programs. We didn't clean those up, as this wasn't part of the TeamMember::Destroy interactor logic. When one of the affected customers of the SAML JIT incident moved one of their reports, all of the report subscribers received a notification, which included employees of other programs.

Timeline
submitted a report to HackerOne .
2018-11-16T17:55:52.234Z

Hi Hackerone team,

I am still able to access other program details etc. when i'm authenticated to HackerOne through SAML .
I'm not sure if it's the same bug i reported earlier or there is some weak authorization check in place. PFA for more info i can access related to ██████████ etc. See the date it's 16th November .

Quick Note:
Last time when i reported the issue the H1 team decided not to reward it. https://hackerone.com/reports/438306
However this time it's happening again. I can stop reaching out to H1 if they don't reward the ethical researchers who are willing to help their platform more secure.

Please consider this as a valid finding and reward it this time .

Impact

This could be a serious issue for HackerOne since the program owners will loose trust in the service and might stop using this platform .

Regards,
Frans

pei Activities::BugTriaged
2018-11-16T18:42:54.501Z
Hi @npbhatter17 - Thanks for bringing this to our attention! Our engineering team is evaluating the impact and making a fix as we speak. Will keep you updated!


npbhatter17 Activities::Comment
2018-11-16T19:09:17.459Z
@pei thanks for the update . Please feel free to let me know if more information needed on my side . I'm hoping this time H1 team will reward this finding . Thanks in advance .


npbhatter17 Activities::Comment
2018-11-21T22:01:10.544Z
@pei any update on this? Since I don't see the other program details anymore . I had email exchange with Reed Loden regarding 'delete any copies of any information you may have retained from having access to these other program' and i confirmed it's done already . Last time my finding was not rewarded, i hope this time it's not the same case . Great job with fixing and communicating to the other program owners .


jobert Activities::Comment
2018-11-26T00:41:47.555Z
Hi @npbhatter17 - we'll get back to you this week. Thanks for your patience!


jobert Activities::ReportSeverityUpdated
2018-11-26T19:37:32.456Z


jobert Activities::BugResolved
2018-11-26T19:53:07.706Z
Hi @npbhatter17 - thanks again for bringing this to our attention. The underlying issues were resolved the same day this was identified, but we waited to close this out until we had concluded our investigation and had posted a post mortem.


Activities::BountyAwarded
2018-11-26T19:54:11.298Z
Hi @npbhatter17 - we lowered the severity to Low because this only affected two reports and was amplified due to the [SAML JIT incident](/reports/438306). In all other cases, the people who had received the notifications had access to the report at some point. In that case, they'd only be able to see a report's title being changed. We don't believe that this would've leaked any (new) significant information. We'd like to thank you again for bringing this to our attention, it's much appreciated! Good luck and happy hacking!


jobert Activities::ReportTitleUpdated
2018-11-26T19:57:23.713Z


jobert Activities::AgreedOnGoingPublic
2018-11-26T19:57:54.456Z
This is ready to be disclosed. Thanks again, @npbhatter17!


npbhatter17 Activities::Comment
2018-11-26T21:12:57.720Z
@jobert Thanks for the reply and the bounty . I still think this was not a low finding . Given it's in the HackerOne platform itself. People trust H1 platform to allow researchers to share the findings and if such incident happen then H1 loose the good will . Sometime finding name is good enough to know where the underlying issue exists . I would request you to reconsider the reward amount since being an ethical researcher, i shared the info with H1 only and as Reed L. requested to delete all the info from my system ASAP, i did . Happy Thanksgiving .


jobert Activities::Comment
2018-11-26T21:49:42.260Z
Hi @npbhatter17 - thanks for following up, it's appreciated. I don't see a compelling argument to reconsider the bounty though. Don't get me wrong, this was a good find, but the overall security impact is Low. The only reason why this became a more urgent problem, was due to the SAML JIT incident. And even in those cases, you had access to the reports (albeit you being unauthorized to do so). This issue didn't give you any new information that you didn't have access to before.


npbhatter17 Activities::Comment
2018-11-29T17:54:29.639Z
Hi @jobert is it OK if i write about my experience for these two findings (https://hackerone.com/reports/438306 (no reward) and https://hackerone.com/reports/442843 (500 dollars) and how H1 rewarded them? I'm sure lot of my friends (security engineers) will understand why i think this was a Critical/High bugs and not a LOW finding. I don't think a bug in the H1 platform itself is LOW risk specially when external companies like ███ etc. are using H1 for researchers to report their finding. Those firms trust H1 as trusted 3rd party vendor. Otherwise everyone will have their own bounty platform similar to ████ . I think any finding in H1 which could lead even a fraction of information disclosure to other people which they are not allowed to see it a High risk. For example the H1 platform grey out the finding name sometime when it's public disclosed. If as a malicious user who does not have access to these finding, can read such information then it's a High risk for that program. I


jobert Activities::Comment
2018-11-29T23:10:04.171Z
Hi @npbhatter17 - thanks for following up. Feel free to blog about your experience! With that being said, I'd like to take a moment to reiterate both decisions. > [438306](/reports/438306): **Accidental Access to Programs Information via SAML Login** As stated in the report summary, you were not the first to identify the incident. As per our current policy, we don't award any duplicate findings, unless they've helped us uncover new information. This was not the case. I understand that this is may be frustrating, but that's policy. > [442843](/reports/442843): **Notifications sent due to "Transfer report" functionality may be sent to users who are no longer authorized to see the report** In your last comment, you argue the following: > I think any finding in H1 which could lead even a fraction of information disclosure to other people which they are not allowed to see it a High risk. We're in complete agreement with your statement. However, all the users who were sent information about reports due to the problem you submitted already had access to the reports at some point. You, in this case, were given access through the [SAML JIT incident](/reports/438306). This particular report sent two notifications of reports you had already access to and it's blast radius was extremely small. Of all the other notifications that were sent because of the underlying root cause were sent to people who legitimate access to the report at a given time. The lack of exploitability here, because one needed to be part of a program at some point and be subscribed to the particular report, is what made us decide to decrease the severity to low.


jobert Activities::ManuallyDisclosed
2018-12-04T19:51:45.336Z
As per [our policy](/security).


npbhatter17 Activities::Comment
2018-12-04T19:55:48.603Z
Thanks :) Will let H1 team know if i see similar issues in future. Great job once again with fixing the issue in timely manner and reaching out to program owners .