Every now and then, things go wrong. This is how life is and there is probably nothing we can really do about it. On the other hand, we automate more and more things, have computers and machines take over to reduce the potential of humans making mistakes. Happily ignoring the fact all those machines are built and programmed by humans, we blindly trust the device at hand. And if things go wrong anyway, it’s not a human mistake but a computer glitch. Just as if the computer has a bad day, did not sleep well last night or is hung over.
Luckily, more and more companies seem to realize that, even given their best effort, their software may not be as free of bugs and security issues as they wish. And following up on that notion, they offer a dedicated email address or web form to contact them in case of bugs or security problems. Some go even as far as offering money – called bug bounty – for reports of security relevant issues. But have you ever tried reporting such a problem?
What happened to two security researchers in Germany when contacting PayPal about a problem they discovered feels rather odd, yet typical: Thank you for your time but no, that is not a problem, everything is fine. Quite comparable to how the security team at Facebook replied to some other white-hat hacker when he was pointing out a security relevant problem. That hacker though, not willing to give in, chose to demonstrate the problem in a drastic fashion: He wrote a post to Mark Zuckerberg’s personal wall, which should not have been possible. That at least got the attention the problem deserved and the bug got fixed. Facebook though refused to pay the bug bounty but instead banned the hacker for violating the terms of service.
The two hackers talking to PayPal chose not to remain silent either, but refrained from any drastic actions. Finally, after three months of arguing, PayPal acknowledged and fixed the problem. They also paid the bug bounty without any complaints.
The experiences these hackers had when talking to a big enterprise strongly remind my of my own attempts of reporting security relevant problems. If I actually found a way to contact their technical staff and not just marketing or sales people, I either got ignored, was told that there is no problem or eventually got threatened to get sued for hacking into their computer systems.
The risk of being sued seems to grow quite a bit when the company in question has a lot to loose or the problem is too big (read: potentially expensive). A team of researchers for instance found a way to circumvent the immobilizer of Volkswagen cars and, before they could publicly speak about it, got sued to remain silent.
But of course it does not always have to be that bad. One company I reported a security problem to some years ago initially refused to admit the issue, but changed their minds only a few minutes after asking me whether I would be up to the challenge and prove it to them. They even went the extra mile of providing me with a test database I should run the exploit against. Conceiving a working SQL injection to fetch the information stored in that database took only a few minutes – given that they already provided me with details like database and table names, it was hardly a complicated task. So much for a challenge. I convinced the developers and together we fixed those pressing issues on their website.
Looking at the issues I reported in the past, as well as what the other researchers reported to PayPal and Facebook, the technical aspect of the problems is hardly new. Or complex, for that matter. They actually are quite standard and consist of common mistakes that are well documented. This makes me sad, given that the Sans Institute released a list of the top 25 most dangerous yet common programming mistakes in website development as early as in January 2009: Cross site scripting, SQL injections, mail header injections, cross site request forgery – you name it.
But of course web security does not stop at the development level and so the recently-updated Top Ten list provided by the OWASP (open web application security project) adds additional aspects and common mistakes to the mix. The list, available since 2004 and updated from time to time, contains common flaws in maintaining a safe environment, mistakes when implementing or using cryptographic algorithms and of course the all time favorites like XSS and other injection bugs.
When comparing the various versions and iterations of said lists, one thing stands out: Even if the order of the items changes, there seems to be hardly any real change in terms of content. The standard mistakes keep being ranked high in all lists. And while that makes perfect sense for a list sorted by risk or potential damage, the fact that the lists sorted by prevalence hardly change (sadly) seems to indicate that people fail to learn. Too often, software keeps being developed with the happy path in mind, ignoring all the potential issues and unhandled conditions which lead to ‚random features‘.
So let us – for the sake of a safe browsing experience – hope that the white-hat hackers keep up with their good work, despite the hard time many companies give them. After all, those hackers seem to be the only ones who really care, and try to help companies to make their software better.
Arne Blankerts consults for thePHP.cc, solving IT problems long before many companies realize that they even exist. IT security is his passion, which he pursues with almost magical intuition, creating solutions that always bear his hallmark. Companies around the world rely on his concepts and Linux-based system architectures.