Recently, a researcher discovered an RCE vulnerability on
Instagram’s website. The researcher used
this RCE to gain access to the system, pivoted, and extracted data including
password hashes, AWS keys and other non-customer data. The researcher thought he was perfectly
within his rights according to Facebook’s bug bounty program guidelines. Facebook wasn’t too happy with this
researcher’s tactics and there is now a war of words between Facebook’s CISO
and the researcher. The security
community, as usual, has picked sides and I’m going to guess we are going to
hear about this for a few weeks until the community gets bored and turns to
something else. This incident provides
an opportunity to further define what a bug bounty program should look like.
Bug bounty programs have exploded in popularity in the last
year. Organizations are already being
scanned and poked and prodded by good and bad guys alike so why not pay them
for finding something interesting? There’s
a great cost-benefit for running one of these programs. Pen tests can run anywhere from $5000 on the
very low end to $20,000 and up. After a
traditional time-boxed pen test you might have a few XSS findings and some
other less interesting findings. Was
that really worth $20,000? Bug bounties,
on the other hand, pay per bug. Those
few XSS findings that cost you $20,000 from a traditional pen test might cost
you less than $1,000 through a bug bounty program. The bean counters in the organizations love
this! But it’s been my experience that
bug bounty programs produce some really clever exploits that don’t usually get
found in a time-boxed pen test.
How should a bug bounty program be defined? That really depends on the risk appetite of
the organization. How hard does the
organization want to get hit and how quickly can they respond? With a bug bounty program you’re putting up a
billboard saying come at me (not like the bad guys weren’t coming at you
before). But bug bounty programs in
their infancy attract a lot of attention and this creates a lot of noise for
your incident response team. These
programs should be nothing more than a vulnerability assessment and the program
should be structured that way. The line
should be clearly defined that as soon as a bug is found it is reported and
nothing more is done. There is too much
liability allowing an unknown researcher to rummage around your network dumping
password hashes and cracking them. Most
pen test vendors provide some sort of liability clause in their contract. Researchers don’t have that luxury and the
penalties could be severe. That’s why it’s
best for the researcher to stop once when they’ve successfully exploited a
vulnerability. Snooping around the
network and exfiltrating data doesn’t demonstrate a vulnerability. The vulnerability in this case was the
RCE.
I’m a big fan of bug bounty programs. I’ve seen the value they provide to an
organization. There will always be an
incident or two like this one that makes executives cringe and rethink
continuing the program. I trust that
there are a lot of very good, ethical researchers who will test applications
with the organization’s best interest in mind knowing there could be a very
good payday as a result. Let’s not ruin
this opportunity. I would much rather
pay out $250 for a XSS finding in a bug bounty program than $20,000 for a XSS
finding from a pen test.
No comments:
Post a Comment