Live data from Hacker News

What Happens When You Send a Zero-Day to a Bank?

privacylog.blogspot.com

371–380 of 454 posts

Re: What Happens When You Send a Zero-Day to a Bank?

#371

Earlier quoted context omitted.

> Your definition would include tradesmen and craftworkers, then, who are not strictly professionals. According to what definition? > Anyone can work in wood long enough to say "That wooden bridge looks like it'll hold X people,"... I severely doubt that, given the complexity of trussed bridge designs [0]. There's a lot more to it than how much weight a 4-by-4 can support. > ... and not have any way of conveying how…

> According to what definition? The dictionary's. > You can't just throw out "circular definition is fallacy" and dismiss the idea. Your definition was illogical, and I dismissed it, so yes, I can.

Really? I put the effort into that response and this is all you have?

I'm pretty sure the correct reaction on my part here is:

Good day, sir.

Re: What Happens When You Send a Zero-Day to a Bank?

#372

Earlier quoted context omitted.

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…

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 havin…

> 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.

Re: What Happens When You Send a Zero-Day to a Bank?

#373
In Finland, most online stores allow you to pay for your shopping directly using your online bank. The way it works is the online store calls the bank's e-payment API, which in turn lets the user authenticate using their normal online bank credentials and accept the payment.

A few months back I did some research [1] on these e-payment APIs and noticed that one of the major banks had a serious flaw in their API implementation. It was possible for the end-user to manipulate the signed API calls to change the payment amount, effectively paying less than the actual price for products they buy.

I reported the issue to the bank and got a swift response where they acknowledged my report and said they were looking into it more closely. A few days later I got another email where they basically said "ok, this looks bad, and we can see it's pretty trivial to exploit, but... it's too expensive to fix, so we won't do anything".

I wasn't comfortable with this, so next I reported it to NCSC-FI/CERT-FI. They also agreed that it looked bad, but said that they had no way of forcing the bank to take action. So that got me nowhere either. I haven't heard from either NCSC-FI or the bank since, but the issue does appear to be partially mitigated now.

I've since found several other issues in the same bank's systems but haven't bothered to report them since they don't really seem to care.

[1] https://www.slideshare.net/JuhoNurminen/the-sorry-state-of-f...

Re: What Happens When You Send a Zero-Day to a Bank?

#374
post #21

Kudos to the author, and hopefully they don't get sued as a result. This bullshit with corporations trying to cover up security vulnerabilities (rather than fix them) needs to stop. "Sign this NDA or we will send the FBI to arrest you because you found that our banking website's security was completely fucking broken and told us about it." Jesus fucking christ.

No one should independently contact a company about this type of issue without first obtaining competent legal advice. And I do mean competent advice; most lawyers are very technically illiterate and will not be sympathetic, let alone familiar with the relevant areas of law. The researcher is lucky that TradeKing believed their NDA trick was sufficient. Even if the case here is weak, and I wouldn't necessarily assume…

...I'm worried of how much incentive there is to become a black hat. Either you risk prison... either earn a lot of bitcoin.

Re: What Happens When You Send a Zero-Day to a Bank?

#375

In Finland, most online stores allow you to pay for your shopping directly using your online bank. The way it works is the online store calls the bank's e-payment API, which in turn lets the user authenticate using their normal online bank credentials and accept the payment. A few months back I did some research [1] on these e-payment APIs and noticed that one of the major banks had a serious flaw in their API implem…

Post them anonymously and see how fast they become too expensive to not fix.

Re: What Happens When You Send a Zero-Day to a Bank?

#376
post #344

There needs to exist a legal entity/non-profit or company that acts as a shield and/or escrow for these kinds of situations. Basically, as a researcher you can have them deal with the company/organization for you, including dealing with any threats, collecting any bounties due, and such. The company could have domain expertise of the industry, laws, and generally be a force against these companies -- the analogy woul…

There was a guy who got thrown in prison for bringing a vulnerability to the attention of AT&T. He was thrown in solitary confinement for over a year. Then his sentence got vacated. What did he do as soon as he was released from prison? He went on CNBC to argue that independent security researchers should start a hedge fund that short sells the stocks of companies affected by vulnerabilities. https://youtu.be/jxUWRRD…

Company name is TRO LLC.

That is hilarious.

Re: What Happens When You Send a Zero-Day to a Bank?

#377

In Finland, most online stores allow you to pay for your shopping directly using your online bank. The way it works is the online store calls the bank's e-payment API, which in turn lets the user authenticate using their normal online bank credentials and accept the payment. A few months back I did some research [1] on these e-payment APIs and noticed that one of the major banks had a serious flaw in their API implem…

Post them anonymously and see how fast they become too expensive to not fix.

Unless you think this would actually lead to banks taking such vulnerabilities more seriously in general--which I don't believe is the case--taking an action like that is pure spite. Consider the possible outcomes for this particular vulnerability: [1] nothing happens, [2] it gets heavily exploited, customers lose money, and it doesn't get fixed, [3] the same thing happens and it does get fixed. In all three cases, the outcome is at least as bad as it would have been had you done nothing, except possibly earlier and worse.

I really take issue with the notion that security is important, so you're fully justified in screwing people and companies over as much as possible to prove a point. That seems to be a common attitude in the security community. I get the frustration people have with the intransigence of corporations and programmers, and people's general stubborn unwillingness to understand the severe impact of vulnerabilities, but if just security-shaming companies into fixing bugs actually worked we would have a much more secure internet today than we actually do. Unless you can get regulatory agencies to start holding companies and individuals legally accountable for security issues (that is, making it more expensive not to fix than to fix), nothing will change, even if you have all the technical solutions and social pressure in the world.

Re: What Happens When You Send a Zero-Day to a Bank?

#378

In Finland, most online stores allow you to pay for your shopping directly using your online bank. The way it works is the online store calls the bank's e-payment API, which in turn lets the user authenticate using their normal online bank credentials and accept the payment. A few months back I did some research [1] on these e-payment APIs and noticed that one of the major banks had a serious flaw in their API implem…

Post them anonymously and see how fast they become too expensive to not fix.

Check the slideshare link OP posted. (Pun intended?)

Re: What Happens When You Send a Zero-Day to a Bank?

#379

Earlier quoted context omitted.

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…

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.

Re: What Happens When You Send a Zero-Day to a Bank?

#380

Earlier quoted context omitted.

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 c…

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…

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.

Post reply on HN