[jupenur]

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

[noir_lord]

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

[Jweb_Guru]

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.

[jupenur]

Also a big issue here, as with many software vulnerabilities, is that the people the public disclosure would actually damage are the users, not the company making the vulnerable software. The bank would only start losing money if the users (personal customers, business customers using their APIs) would notice the hack and start demanding their money back.

[fulldecent]

It would be very nice if your security disclosure report included a section about how you have provide good faith upfront notice to the vendor and that based on research and belief it would be negligent for the company to not fix the issue by X date.

The wording you choose should be cognizant of your state's laws and the company's user agreement in such a way that the company is actually at risk if they ignore you.

When talking to people, "Reason is, and ought only to be the slave of the passions".

When talking to companies it is only necessary to discuss the impact on their profit.

[jupenur]

Just to be clear, I haven't really disclosed anything publicly, not regarding the e-payment API issue or any other issues for that matter. The SlideShare from my comment references the e-payment API vulnerability but doesn't disclose any technical details. It's not possible to reproduce the attack based on the slides alone.

[fulldecent]

This is not spite, please see full reply to parent.

[BrandoElFollito]

My credit card may be used for an online payement because it tells on a few information (number, cvv, etc.). This is obviously a security problem. Nobody cares: neither me as any payments which are not mine are immediately reverted (and then, maybe, the bank investigates), nor the bank for wom it is cheaper to write off this money then to fix the system.

So no, publicly exposing an issue does not always work if there are no incentives for anyone to fix it.

[rasjani]

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

[fulldecent]

You have reached zugzwang in game theory parlance.

The correct solution before this was to make an announcement:

"Here is the announcement I have made disclosing the problem. It is in both our best interest that it get fixed before publication. I have irrevocably given it to a blind drop that will publish it on DATE. And I believe that is a reasonable DATE that you could fix the problem. Let's work together to fix the problem."

What do you think about this type of approach? There is probably a name for it in Art of the Deal. (Whatever you think of the man, the book is worth reading.)

[jupenur]

The thing about setting deadlines like that (blind drop or not) is that it's very easy to look at it as some form of extortion. "This guy has cyberweapons, and unless we do what he tells us, he's going to release them on DATE. Better call the lawyers."