[BlueOnyx:05469] Re: Dealing with /admin URL 'hijacking

Sun Sep 26 01:00:23 -05 2010

Just from a quick google, an example of shell execution from a php exploit:

http://forum.joomla.org/viewtopic.php?f=432
<http://forum.joomla.org/viewtopic.php?f=432&t=516818> &t=516818

And if the hacker gets to upload programs (a recent zen cart and wordpress
hack enabled attackers to upload arbitrary files)

http://projects.webappsec.org/OS-Commanding

http://www.securityfocus.com/archive/1/502434

Other examples would be hacking the cms/cart to place files on the site
which could be used to for just about any miscreant purpose which might
allow the attacker to get a priviledge elevation or exploit some unpatched
bug to do server wide damage. When does this become an issue for the host? 

What alarm bells are you referring to? A php program doing a system call()?
What do you use to detect this and set off the bells? A hacked site is a
risk to the server.

Another way a hacked site can risk the server is by creating a spam relay -
sending out spam messages through the server and getting the IP blacklisted.
I do have log checks that will usually catch this for me, but this is
usually after the fact. I know if you have had to play the "get my server
out of the RBL's game you will probably agree it's a game noone really likes
to play.

I do try to keep my servers reasonably locked down. Certainly there is a
perpetual tug-of-war between security and keeping a server open enough to be
useful to clients.

With respect to hosting company liability, if some hosting company turns on
register globals (not a good idea, but they don't want to break old software
that depends upon it) in their php config and this leads to a client getting
hacked, do you say that the host has no liabilitiy in this in those places
like the UK and Oz? 

Is the hosting company required to notify the client of this less secure
configuration? Is this an area where the hosting company might be consider
complicit in the site getting hacked through their configuration choice? I
think at the least, in the US, it might be arguable. Might not stand up in a
trial, but enough to cause a big PitA with a client angry and looking for
compensation and someone to blame.

We could argue this forever, but should we clog the list with this sort of
back and forth when we agree on a good bit?

            -Stephanie

From: blueonyx-bounces at blueonyx.it [mailto:blueonyx-bounces at blueonyx.it] On
Behalf Of James Darbyshire
Sent: Sunday, September 26, 2010 12:31 AM
To: BlueOnyx General Mailing List
Subject: [BlueOnyx:05468] Re: Dealing with /admin URL 'hijacking

Hi Steph,

At risk of turning this into a email yo-yo, (and please don't take this, or
anything I have said as an attack on you or your chosen best practises) I
reply to your email. I am always up for a good debate, and hearing other's
points of view - especially when there is no clear-cut answer, and all
methods are mainly someone's interpretation/education of what 'best
practise' is. Important to note that best practise changes, and yesterdays
best may be today's worst.

As stated in my previous emails, I agree, changing the default path from
/admin to something different is definitely best practise, and I actually
encourage anyone to do this, however my warnings were against the myriad of
people who think that placing something in a directory which is unlikely to
be found is security. This is something I have found in the past, where
hosting companies have provides directories such as /adm-a8r30 or provided
an obscure port number for the admin panel.

What I fail to understand from your emails, is how breaching something like
a CMS would allow access to a shell. Surely if someone is using the same
access credentials for their CMS as their shell then the alarm bells should
be on overdrive. Current best practise suggests that security is
compartmentalised, meaning that a breach in one area does not mean we are
nearing the apocalypse for all areas.

If a client gets hacked, yes it is bad. And yes it should have been spotted
and acted upon years ago. And yes as the host you are responsible for
guiding them in the right direction to ensure it does not happen again.
However, I doubt that there are many sites out there, which, if hacked,
would cause the parent company to be shutdown. The days of merchant accounts
being redirected to another account number causing someone to go bust are
pretty well gone, and even if it does happen, in most cases you are
protected for the entirety of your 'lost' capital.

As I stated in my previous email, I can only talk for the Australian (and
British) legal systems, where the host is responsible for the security of
the server, and the client is responsible for the security of the installed
software, so in these systems there would be no legal defence costs for a
host, as there is simply no problem with a CMS being hacked, those
credentials having access to shell, and then gaining access to the root user
of the system. I am not saying that it can't happen, but with proper
planning and security measures it becomes such a small possibility that it
is not worth persisted worry about.

FYI we restrict access to the root user and other 'administrative' users to
come from one public IP, meaning that in order to shell into our box you
have to be connected to the VPN first. It works a charm, because even if
someone does know your public IP they cannot gain access to the most
important areas.

Regards,

James Darbyshire

On 26 September 2010 13:07, Stephanie Sullivan <ses at aviaweb.com> wrote:

Ah, James,

Indeed security through obscurity is not security. However, changing default
paths improves the odds of avoiding an attack and can be an important part
in an overall security plan. In fact suggesting one thing is "the answer" is
not at all my intention and I hope you are not trying to suggest there is "a
solution"...

And if the client is breached, gets shell, and well, whatever, the server is
potentially much more at risk. Far more so than if the client was not
breached.

In any case, I may not have been clear in my wording when I was writing
about who is responsible where. The client may claim the hosting company had
some complicit negligence. Even if not true, legal fees can be staggering
and the overhead of a defense great.

Reputations can be trashed, even when not deserved, and that has
repurcutions. 

If my client gets hacked it's bad for them and that is bad for my buisness,
especially if they go out of business.

            Thanks,

                        -Stephanie

From: blueonyx-bounces at blueonyx.it [mailto:blueonyx-bounces at blueonyx.it] On
Behalf Of James Darbyshire
Sent: Saturday, September 25, 2010 7:38 PM

To: BlueOnyx General Mailing List

Subject: [BlueOnyx:05466] Re: Dealing with /admin URL 'hijacking

Steph,

But what you are suggesting is that security by obscurity is the answer in
this case - which is a dangerous path to follow.

It may be easier for someone to break into the CMS than into the BO backend,
but once they are into BO then they can do everything you suggested, not
only to one site, but to every site on that host.

I don't know how uou run your business, or how the law works in the US, but
here in Australia the client is responsible for the security of what they
install on their website, and the host is responsible for the security of
the server. If a CMS was hacked, I would not be responsible.

Of course the optimal solution would be to use some kind of TLS and
intelligent intrusion detection software on both systems which locks access
out when it thinks an attack is taking place.

Rashid, I suspect you are correct on saying that BO authentication is
probably harder to crack than that of a stock CMS, but the point sound be
that yes an attacker can get into one website and cause havoc, but only
within that CMS on that specific site. Other sites will be unaffected. I
would also hazard a guess that many people are not as vigilant as you or I,
and do not frequently change their passwords.

In short, I don't believe security by obscurity is the answer in either
case, but I would rather the attacker accessed one site only, and not the
server which has access to all.

Regards,

James Darbyshire

Sent from my Samsung DroidT

On 26/09/2010 1:28 AM, "Stephanie Sullivan" <ses at aviaweb.com> wrote:

I must not concur. That's not the worst thing. Picture this:

They break into my client's zencart, oscommerce or CC processor integrated
cms (as joomla and drupal have plugins/extensions and I have clients using
them). The get into the client's site and modify the CC credentials to
process using their bogus merchant account. Maybe they put a hack in to
steal their CC numbers. Now you have a security breach that has big legal
implications that you and/or your client have to legally disclose in the US.
You probably have clients screaming at you about bogus charges on their
card. Eventually the site is defaced and their tracks are covered by wiping
most of your database. 

Finally your client's reputation is damaged/destroyed and they are angry
with you and spread the word they got hacked on your platform damaging your
reputation, etc.

I would think it's far from the worst thing. Of course it may be worse if
you are the client than the hosting company.

                Thanks,

                                -Stephanie

From: blueonyx-bounces at blueonyx.it [mailto:blueonyx-bounces at blueonyx.it] On
Behalf Of James Darbyshire
Sent: Saturday, September 25, 2010 10:30 AM

To: BlueOnyx General Mailing List

Subject: [BlueOnyx:05461] Re: Dealing with /admin URL 'hijacking

I disagree. Certainly it is not best practise for any admin functions to be
accessible through ...

_______________________________________________
Blueonyx mailing list
Blueonyx at blueonyx.it
http://www.blueonyx.it/mailman/listinfo/blueonyx

_______________________________________________
Blueonyx mailing list
Blueonyx at blueonyx.it
http://www.blueonyx.it/mailman/listinfo/blueonyx

-- 
Regards,

James Darbyshire
jamesdarbyshire at gmail.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.blueonyx.it/pipermail/blueonyx/attachments/20100926/7352328b/attachment.html>