White hat hacking

Security holes? Who cares?

ArneBlankerts
cheese

To err is human, but to ignore the warnings of independent security researchers is just downright silly, writes Arne Blankerts.

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.

Author
Comments
comments powered by Disqus