Hacker News Reader

Comment by Animats | Hacker News Reader

There is. Carnegie-Mellon University's CERT. Here's the form for reporting a vulnerability.[1] For this kind of problem, select "Request Vulnerability Coordination Assistance". You can even do this anonymously.

The report isn't public yet, but it's on record. You've reported it to the organization funded by Homeland Security to take such reports. In 45 days, CERT will disclose it to the public.[2] CERT may contact the bank themselves. If you do, you can cite the CVE vulnerability number they give you. This gives you some advantages when talking to a bank. "Have your technical people contact Homeland Security's US-CERT at (888) 282-0870 regarding CVE-NNNN" will usually deal with a bank's people. They can't make the problem disappear.

[1] https://vulcoord.cert.org/VulReport/ [2] http://www.cert.org/vulnerability-analysis/vul-disclosure.cf...

View on HN

I don't recommend submitting to CERT unless you genuinely don't care about the outcome of reporting.

Yes, reporting to CERT is "safe"; you almost certainly aren't going to get sued for doing it. But don't count on CERT coordinating a fix or even figuring out how to report flaws to. It's unlikely that anyone at CERT knows who "Zecco" is.

CERT themselves ask you not to submit to CERT unless your vulnerability fits some specific criteria. "Unresponsive vendor" is one of those, but CERT's fine print says that they prioritize severe, multi-vendor vulnerabilities.

Anyone who runs a bug bounty program can tell you how unrealistic it is to rely on CERT for this stuff: triaging reports for just one vendor is a full-time job. CERT wants to get early warnings of things like OS and platform vulnerabilities. I don't think it's a good idea to report those to CERT either, but regardless, CERT isn't set up to handle your CSRF report in some random website.

Even if CERT doesn't do much actively, you've put the problem on record and can refer to that record when dealing with vendors. Most companies can ignore security vulnerability reports if they choose, but a bank cannot. They have an obligation to report the vulnerability to their auditors. It triggers certain Sarbanes-Oxley reporting requirements.[1] It's easier to fix the problem than deal with the problems of having a logged, unfixed vulnerability.

[1] https://www.a2q2.com/blog/sox/29-cyber-security-and-sox/

Sure banks can. Source: did software security for a number of banks. Big banks are chock full o' CSRFs, XSS, SSRFs, and SQLIs. They get found all the time. For every valid report they get, they get 3 that aren't valid. Nobody's hair achieves ignition over this stuff.

There are two types of financial service organizations: the big banks, and random firms (like Zecco was, before Ally bought them).

There's no point in contacting CERT about a Bank of America vulnerability. CERT won't prioritize the report and won't know the right person to talk to, but also, you're a Google search away from finding out who to report to at Bank of America (spoiler: it's Hacker One). These kinds of things don't happen at BofA, not because vulns are hair-on-fire there, but because there's a process in place to handle them.

There's not much point in contacting CERT about a Zecco vulnerability. CERT doesn't know who to contact and doesn't know how to find them and won't spend the time trying. CERT isn't going to publish an unconfirmed report. All CERT is going to do is go to Mitre; you can do that too, and note the guidelines for what will get you a CVE.

The issue here is just TANSTAAFL. It takes a fuckload of effort to triage and confirm vulnerability reports. There's no magic "this is a real vulnerability" certificate you can get CERT or Mitre --- or really anyone who doesn't spend a lot of money to maintain the capability for their own products. If there was, Hacker One wouldn't make half their money selling triage services. :)

I'm pretty surprised at this:

>For every valid report they get, they get 3 that aren't valid.

Because taking the time to write and to submit an invalid report is a total waste of the reporter's time. Reports aren't the type of thing that someone will accidentally say "oh this is a severe vulnerability! here's some cash" even though the researcher has submitted bullshit.

So can you talk about "3 that aren't valid" for every valid report? Who makes these? Weird, obscure cranks, of the type who in other industries would be churning out perpetual motion devices? I would expect 80%+ of vulnerability reports to be serious and real - quite different from what you just wrote.

Whether you run a bug bounty or not, there are now hundreds of people in Asia and Eastern Europe who hope to make $500 every time they find a page without X-Frame-Options set. A lot of them have pirated Burp Suite and are hoping to simply cash in on the scanner output.

I used to manage a bug bounty for a bank. It's nightmarish how accurate this is.

As someone who has been on the receiving end of a bug bounty's mailbox, 3-to-1 sounds about right. We got a ton of invalid "security vulnerabilities" that were essentially either people reporting OAuth as a vulnerability or not understanding how XSS actually worked. Most of these came from teenagers in southeast Asia.

I've also seen lots of reports of some serious vulnerability - "major product X doesn't validate TLS certificates" - where it looks like the reporter forgot they had added their own cert to the OS's trust store.

super-interesting - thanks.

Here is some context for what I'm about to write: I managed a bug bounty for a sizable arm of BBVA. I have temporarily managed bug bounties for many smaller tech companies. In 2014, I surveyed the the industry as BugCrowd and Hackerone were coming into prominence.

Bug bounties, on average, have a signal:noise ratio that is horrible. I advocate for the programs completely, but they require a lot of planning in order to prevent them from becoming overwhelming. I personally know security engineers at Google and Facebook whose full time job is sorting through nonsense bug bounty reports.

What Tom said about people in Eurasia wanting to cash in on bug bounties is spot on. If you start a bug bounty program, expect to get a deluge of nonsense reports for bullshit like having the Trace HTTP method allowed on an API endpoint. For every one valid report, three - five will be bullshit. Of those that do not reproduce, half will be incomprehensible, and the other half will blatantly ignore the program guidelines or be low effort spam ("content spoofing"). If you offer a cash reward, expect the ratio of valid to invalid to be closer to 1 in 10.

It's a numbers game for these people. The security research industry is bifurcated between rare, sophisticated and highly paid freelancers who do it mostly for passion outside of their day jobs, and opportunistic amateurs who couldn't write a curl command.

BBVA? I have been trying to get in touch with them regarding an app of theirs (Access Key Extranet by BBVA Bancomer, S.A. https://appsto.re/us/4QEKfb.i) which does not properly validate TLS certificates.

Thanks for this detailed write-up! Super informative.

A lot of vulnerabilities are basically the same thing. From what I've seen, even legitimate researchers will have form reports. It's just an obvious optimization.

From there it's pretty easy to see that "vulnerability spam" would be a thing.

I guess it's various consulting firms that want to expand there market like e. g. KPMG cyber security division and the likes.

>finding out who to report to at Bank of America (spoiler: it's Hacker One)

Hacker One doesn't have a program for BofA. You probably found this dummy (and slightly misleading) page: https://hackerone.com/bofa

> but a bank cannot.

Why not? If anything the story above shows that a financial institution very much can and post-2008 I believe there many things a government cannot do but there are very few things a bank cannot do.

Who is Zecco?

The financial entity the article is written about.

You're suggesting we send our exploits to the company that hacked Tor for the FBI? How much do they pay you?

Reply on news.ycombinator.com