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

Sat Sep 25 23:30:55 -05 2010

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 Droid™
>
> 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/10728721/attachment.html>