
Here’s why we keep getting hacked – clear and present Billabong failures - troyhunt
http://www.troyhunt.com/2012/07/heres-why-we-keep-getting-hacked-clear.html
======
dsirijus
Most of the companies I've worked with had absolutely no security
considerations. They've expected it to work out of the box, with, say, RoR and
Apache.

Needless to say, it didn't work. Also to be noted, there were no noticed
service disruptions caused by any 3rd party. We were small fish.

Which leads me to the following - security is a scaling issue. Sure, your
prototype even though ready for going live, need not really be secured in most
use cases. But once you start to grow, especially rapidly, things can easily
spin out of control.

You need some time to get a proper certificate, your database looks like
development version on your local machine, you've handed out few ssh keys via
e-mail and it's on few USB sticks lying around for root admin on deployment
server (since someone has to take care of it while you sleep), you login on
public networks to get company resources you need asap, etc.

What I'm really interested is - how does one scale it? What are the
priorities?

~~~
corford
I'm not sure if it's unconventional or not but I'm a big believer in doing as
much as possible correctly from the start i.e. having a dev -> staging ->
production setup, clearly documenting everything, devising and sticking to a
set of procedures and guidelines (for deployment, security, coding style
etc.), not taking "bah it will work for now" shortcuts with fundamental design
choices, using a proper bug tracker. And so on.

This adds a bit more up front planning pain to any project and also slightly
slows down the daily dev routine BUT it pays dividends further down the line
when you suddenly start getting noticed and your usage figures begin
multiplying every 24 hours. In that situation there isn't time to re-work
production dbms schemas, change the app code to deal with bcrypt'd password
hashes, change the deployment script to make it more secure so you don't end
up accidentally dropping a dev version of the site on your public servers etc.
etc.

Better to pay the up front cost of getting the basics correct at the beginning
of the project rather than dealing with an un-contained explosion later on
just as you hit the limelight.

Also, the up-front pain of doing this diminishes with every additional project
you do as a lot of the concepts, approaches and procedures are re-usable.

~~~
dhyasama
The idea of doing a little work up front to save yourself trouble later on is
good in theory, but the reality of the early stage startup world is if you
don't move fast enough you won't be around to experience that trouble later
on. Sometimes it makes sense, sometimes it doesn't. The trick is to find a
happy medium that works for your situation.

Totally agree on that last part. The pain rapidly diminishes as you come up
with simpler ways to do things in a reusable way. Also, the tools to do it are
getting better and better as more and more people are feeling the same pain.

~~~
wahnfrieden
Not only that, but it reduces the number of pivots you're able to try as a
startup that is seeking product-market fit.

------
unreal37
"If you had a dog when classic ASP was replaced, it’s probably no longer with
you."

Well written article that strikes the right tone.

~~~
alttab
Unless you have a dauschund. Those little guys can last 15-20 years if you
treat them right.

~~~
troyhunt
Yeah, but statistically even the loyal sausage dog would have a better than
average chance of having moved on since the ASP launch! (10 years ago avg age
would have been < 10 years)

~~~
omni
Fun fact: Dachshund actually translates to "badger dog." They're the perfect
shape to go digging around in holes in the ground hunting badgers, rabbits,
and the like.

------
rickmb
I have a problem with the constant "blaming the tools" in this article.
Blindly relying on the framework is one of the major causes of security
issues. Exploits will always be one step ahead of the frameworks, blaming the
tools breeds the wrong king of mindset when it comes to security.

~~~
reacweb
fully agree. A lot of microsoft fanboyism. The sql injection seemed serious.

~~~
troyhunt
Actually, I think it's very clear there were just a lot of bad dev practices
happening across the different technologies. Classic ASP on Impact Data, PHP
on the main Billabong site and current day .NET on the store. Clearly bad
things were done on all.

However, some of those basic injection flaws in classic ASP would not have
been possible on a more modern technology stack be that from Microsoft or
other. A 5 year old version of PHP also isn't going to do you any favours.
Newer frameworks are simply better at saving you from yourself - but that
doesn't excuse the sloppy practices.

------
davidandgoliath
This post is irrelevant, the author can reduce it to:
<https://billabong.com:8443/>

(Plesk.)

~~~
spiffytech
For those who don't know, Plesk has been a recent vector to compromise a large
number of websites: [http://krebsonsecurity.com/2012/07/plesk-0day-for-sale-
as-th...](http://krebsonsecurity.com/2012/07/plesk-0day-for-sale-as-thousands-
of-sites-hacked/)

~~~
davidandgoliath
Apologies! Should have expanded on that a bit. Overall gist: billabong.com has
plesk publicly available for login. Plesk allows root (full system access)
logins from a remote source and has all kinds of exploits available for
purchase and abuse.

This kind of stuff happens, but in essence Billabong's sysadmin needs to start
surfing exploit mailing lists more than he's surfing other places :)

------
UnoriginalGuy
This is actually a decent article but he spends far too long going on about
HTTPs. Yes it is insecure but it isn't why they had a massive password
compromise.

Ditto with XSS.

~~~
troyhunt
Quite right, and I did refer to that, the point was that if you can't get
simple things like these right (among others referred to), is it any surprise
that a major breach occurs?

------
freijus
I discovered a web site with XSS vulnerability. I sent them an email a year
ago about this security problem. Nothing has changed yet.

What should I do now?

Last time I pointed them out to some wikipedia articles relating to their
vulnerabilities.

~~~
ZoFreX
Write a blog post explaining exactly what is wrong and why it is a problem,
then tweet it to them and post it to their Facebook wall. If they won't fix
the security issues, then maybe you can save a fraction of their users by
convincing them to go elsewhere. (And by making noise publicly they are
probably more likely to actually do something about it)

~~~
dhimes
When you do this, at least at first, don't name the site. In your email to the
site you can tell them the blog is about them.

If you do feel the need to spill who is at fault, you can do it in the
comments or in a follow-up post at a later date.

~~~
alttab
Yeah its almost your civic duty to warn potential customers. But you have to
be careful at the same time not to attract more attention to it than
necessary.

~~~
ZoFreX
I'm not 100% on the rules of responsible disclosure, but isn't giving a
company more than a year to fix an incredibly basic error more than enough
time? The longer you wait the higher the chances a black hat will come along,
why should their customers burn due to the company's apathy?

~~~
alttab
Agreed. At that point I'd post it on an anonymous blog through a proxy just to
protect yourself in the case they want to be assholes.

------
vampirechicken
While people _expect/desire_ that form to be served via SSL, what matters is
the URI to which the form submits, and whether it submits over SSL.

You could apparently serve the author a form over SSL, have it post to a
malicious server, and he'd be none the wiser because he's focused on whether
the empty form was sent over an encrypted socket.

~~~
TazeTSchnitzel
Every link in the chain should be over TLS. Otherwise, you can change the
unencrypted part to point somewhere else. Both the form, the site linking to
it, and the URI it submits to should be over TLS.

~~~
vampirechicken
I can use LWP, Curl, Wget, etc. to submit a form over https to any HTTP
server.

I am unaware of any protocol semantics that allow an HTTP server to determine
how the submitted data was marshaled.

~~~
TazeTSchnitzel
Eh? I think you misunderstand me.

As Facebook learned, submitting to an HTTPS server isn't enough, the form must
be too. Otherwise you can be man-in-the-middle attacked on the form page.
Better yet, serve everything over HTTPS, so people can't change the links.

~~~
vampirechicken
So what what you mean to say is that if you don't use SSL all the time,
somebody with a sniffer can pull you session ID out of the air and impersonate
you by hijacking your session.

That's VERY different for a man-in-the-middle attack.

Do you think the coffee shop should have offered encrypted wifi?

------
benihana
A good article on security and XSS, but the conclusion is a little
disappointing. The headline makes it seem like the author knew why Billabong
got hacked, so the whole time I was reading, I was waiting for the big reveal.
But then when it comes down to it, his conclusion is, "I don't know, there's a
long list of things wrong with the site, but it was probably SQL injection."
Felt kind of like watching that M Night Shyamalan movie with the aliens.

~~~
rwmj
Nonsense. The author demonstrates a range of obvious vulnerabilities in the
site. The fact of which of these happened to be exploited this time is pretty
irrelevant when the website as a whole is so poorly implemented.

~~~
danso
Exactly...the smorgasbord of security failures _was_ the great point of the
OP. If the hack actually occurred because an employee decided to go
OfficeSpace on Billabong, that would not invalidate the value of the OP in the
least.

