Get Even More Visitors To Your Blog, Upgrade To A Business Listing >>

When Soatok Used Bugcrowd

I’ve worked in software Security for a long time. One of my earliest blog posts cited my HackerOne profile as a data point for taking my opinion seriously, but I never really considered myself a “bug bounty hunter”. I’m basically a software security expert that works in the cryptography (NOT cryptocurrency) space by day, cryptography blogging furry by night.

Sort of like that!
Credit: LvJ

Sometimes, when I wanted to Report a vulnerability to a product, service, or software project, I would be instructed to disclose my findings through a bug bounty platform such as HackerOne or Bugcrowd. When this happens, I might look around to see if any of the other programs interest me, but they rarely do.

As a consequence of this conduct, I’ve accrued a few thousand dollars over the years from both platforms. That may sound like a lot of money, but it’s basically a mobile phone bill’s worth of bounty money over 3+ years.

Most of my earnings went into private, direct action donations to people that need it (including helping LGBTQIA+ folks escape Russia). This was always done under the terms of “pay it forward” (because I don’t want to be paid back, or hold any leverage over people for once being in a vulnerable situation).

My point being: My participation in these platforms was never about the money for me. I’m a very curious person and want the products, services, tools, and code that people use to be as secure as possible so they don’t get hurt.

My ethical obligations as a security researcher are solely to protect users. I have no ethical obligation to protect the reputations of any vendors or companies, except as a byproduct of protecting users.

If immediate full disclosure will clearly better protect users, I will prefer that over coordinated disclosure or non-disclosure. However, I rarely have the visibility into the full scale of a project’s deployment, and therefore it’s difficult to ascertain what disclosure policy is best, so I generally default to coordinated disclosure if reasonably practical.

Past Friction With Bugcrowd

Earlier this year, my friends started a business. As their friend and technology consultant, I thought I’d compare password managers before making a recommendation for them to use. However, rather than just compare marketing copy and an Excel checklist of features, I thought I’d use my existing cryptography knowledge to study them in detail.

Most of the password managers have a bug bounty program on Bugcrowd. Every password manager can effectively be reverse engineered with dex2jar + Luyten (or, for browser extensions, Ctrl + Alt + L in a Jetbrains IDE to beautify the JavaScript code).

This presented a unique opportunity: Not only could I evaluate each password manager’s cryptography implementations, but if I did find any interesting bugs, I could evaluate their responses to security researchers as well.

Aside: Without getting into the details of what I’ve found and disclosed, 1Password is an excellent choice and treat security researchers with respect.

Can you guess what happened next?

How Bugcrowd’s triage team responds to every report of a cryptographic side-channel identified in the source code of a product.

This is their standard response to the kinds of reports I’d write, which included:

  • A direct link to the source code that was vulnerable
  • A description of why the particular snippet was vulnerable
  • References to other publicly available research into congruent side-channel attacks in similar software
  • A patch, accompanied by some writing that explains how/why it fixes the leakage

But my reports didn’t include exploit code, because exploit development is not my specialty, and it’s ludicrous to expect me to invest hundreds of hours of my life into learning and mastering an extremely advanced skill just to get a bug report that already contains all of the above to not get rejected by a triage team.

Consequently, I reached out to Bugcrowd support to complain that their standard processes and runbooks were failing. Cryptographic issues are already hella specialized, and expecting any reports to also include an orthogonal specialty (while demanding that only solo researchers report bugs, rather than teams) is frankly unreasonable.

After about four or so more rejections (which were often overriden by the program owners; i.e. the actual vendors), I started doing something a bit snarky: I’d include a “proof of concept” that merely demonstrated that their function was variable-time based on the bit patterns of the inputs. This isn’t an exploit PoC like Bugcrowd demanded, but it was enough to satisfy the box-checking mentality at work.

(If any of the bug bounty programs I reported issues to is reading this: Yes, that’s why I included such a stupid and pointless “proof of concept” in my reports. I wasn’t trying to insult your intelligence, I promise!)

Enter Xfinity Opensource

The Xfinity Opensource program on Bugcrowd (alternative archive) ostensibly exists for Xfinity (read: Comcast) to give back to the open source community.

Their program advertises the JSBN JavaScript big integer library as “in scope”; presumably because they rely on it for some sort of cryptography purpose (most likely RSA or SRP, but who knows?). The original JSBN project website uses the title, “RSA and ECC in JavaScript,” so the intent was clearly to be cryptographically secure.

When I wrote my guide to side-channel attacks and constant-time algorithms, and included a TypeScript implementation, I was vaguely aware of JSBN and suspected it wasn’t secure. But I also assumed it was legacy code, or abandonware, that only served as a crypto.subtle polyfill for old browsers. Seeing it included in the project’s scope here changed my mind and I decided to dive into their implementation.

On April 8, I disclosed my findings through the Xfinity Opensource bug bounty program on Bugcrowd.

Two days later (April 10), it was closed by a Bugcrowd employee as “not applicable” because I didn’t include exploit code. I pushed back on this, and requested disclosure. My reasoning for this request is simple: If it’s actually not applicable, then you’ve determined it’s safe to disclose. Otherwise, it’s actually applicable, and you’re just being weirdly hung up about a checkbox item.

Bugcrowd said they would check with the Comcast team and update me accordingly. On May 6, a member of the Comcast PSIRT responded to the ticket.

This program is intended to be supportive and beneficial to the open source community at large, and we do not have any direct control over these repositories. However, we do work directly with the maintainers concerning any security reports, bounties, and disclosures. In this case, we have contacted Andy to inform him of your report. Further, since he is the maintainer, we make the disclosure request decision with his input.

As soon as we are able to discuss with the JSBN maintainers, we will follow up on a disclosure determination.

An excerpt from the response (from my email records)

Today, on June 14, they denied the disclosure request, reasoning that since they don’t actually maintain the repository, it’s really not their place to disclose anything through the Bugcrowd platform. In their rejection, the same PSIRT member said:

Since we don’t author or maintain this code, we do not have any authority to grant a disclosure request. However you might be able to engage with them on the repository, or develope a further PoC that would enable validation of your claims.

From the Comcast employee (emphasis mine)

So I decided to engage with them on the repository.

Banned from Bugcrowd

Bugcrowd says: “NO U”

Setting aside the comical use of “your Github blog” to describe the issue tracker for JSBN (which is the repository in which I was instructed to engage with the maintainer), this sort of action doesn’t actually make sense for the kind of security research I do.

Bugcrowd’s vendors have mostly agreed to a Safe Harbor clause. This means they will not prosecute anyone who acts in good faith to report vulnerabilities through the Bugcrowd platform. This is a good thing to have if you’re sending packets over a network, lest the Computer Fraud and Abuse Act of 1988 (or congruent laws abroad) bit you in the posterior. But if you’re only reverse engineering software that runs on your own machine and critiquing the source code, the CFAA doesn’t really apply, and Bugcrowd has no real leverage over what you do with your expert opinions about how vendors’ software operates (since you don’t need a safe harbor to avoid procecution).

Also worth noting: Neither JSTOR nor MIT wanted to prosecute Aaron Swartz, but that didn’t stop federal prosecutors from doing so anyway, and he’s no longer with us. So, y’know, keep that in mind with the Safe Harbor agreements. Bastards will be bastards.

After I pointed out that a) a takedown would be pointless due to an archive already existing and b) I was instructed to engage with the maintainer via the repository (which is exactly what I did), the Bugcrowd support employee responded with a weird demand.

Pay attention to the wording of that second paragraph. This is the kind of language used by manipulative ex-partners or power-tripping school principals.

At first glance, because I do not operate archive.today nor have authorized access to their servers, I thought Declan was demanding me to hack into the archive site to remove the entry. That would be a federal crime under the CFAA. But it turns out I was mistaken, and he instead wanted me to leverage a “abuse report” mechanism to remove the archived copy.

I find it comical that anyone working in security hasn’t heard of the Streisand Effect in 2022, but maybe Declan is one of today’s lucky 10,000?

Of course, I’m not one to give into bullies, so I responded in the only appropriate fashion.

Some life advice: Any time anyone gives you an ultimatum, the correct answer is *not that person*.

The entire saga was captured on a Twitter thread, which is probably how many of you found this write-up in the first place:

What Happens Next?

Since I’m banned from Bugcrowd, if I ever discover another security issue in a project that uses Bugcrowd exclusively for vulnerability management, I have no other recourse than immediate public disclosure.

(If you use Bugcrowd, maybe make sure your security@ is actively staffed so I can contact your company directly?)

Since I don’t send packets to networks (what they call “website testing” or “API testing”), being excluded from Bugcrowd’s Safe Harbor negotiations won’t put me in any additional legal peril, so there’s no chilling effect at play.

However, other security researchers may depend on the Safe Harbor negotiations to avoid prosecution, and may be susceptible to such leverage when a disagreement with Bugcrowd employees occurs.

What I find most alarming is the attempt at emotional blackmail in these communications. The cavalier attitude towards post-disclosure censorship is noteworthy too.

If the nature of my security research was legally perilous like, presumably, most of their researchers, then this kind of manipulation would probably be even more pronounced. And that’s frankly alarming to me.

I can imagine how strong the implied legal threats would become, but I will not speculate publicly on such matters.

Regardless of how Bugcrowd management tries to respond to this issue, I won’t be returning to their platform.

I will never again support any bug bounty platforms that allow its employees to attempt to exploit or manipulate people less privileged than me into compliance. This is unacceptable and unethical.



This post first appeared on Dhole Moments - Software, Security, Cryptography, And The Furry Fandom, please read the originial post: here

Share the post

When Soatok Used Bugcrowd

×

Subscribe to Dhole Moments - Software, Security, Cryptography, And The Furry Fandom

Get updates delivered right to your inbox!

Thank you for your subscription

×