[SATLUG] My new site...would like some feedback

[K. Spoon]

On Tue, Oct 10, 2006 at 07:59:13AM -0500, Sexton, Art, ISD wrote:
> The bug you mention is, again, in a 3rd party extention...community
> builder:

I apologize if I didn't make that clear.

My point was that there are numerous vulnerabilities that are attributed
to Joomla (and other apps) through bugs in these 3rd party extensions,
and that it's usually the same bug in a different piece of code written
by a different person that presents the vulnerability.

> And, even if they get in via this means, they only get access to the
> admin console of Joomla and can only deface the site.  

That is incorrect.

The bug is in the fact that a variable, which can be overwritten through
the GET method, is passed directly to require_once() which evaluates the
code it is passed.  Since the variable is not sanitized before it's
used, it would be possible for an attacker to close out the
require_once() call early and insert their own code (through the GET
request) to be run when that line evaluated.

Since you can pass your own PHP to the interpreter, you can now tell the
target server to download an executable from a site of your choosing
to someplace like /tmp, chmod 755 it, and start it up.

There is no code in that script to do authentication before the
evaluation, so having it in the admin area isn't any protection, either.

I'm not trying to slam Joomla specifically here... it's just one handy
example out of a discouragingly long list of vulnerabilites from a large
number of web applications that exist.  I'm probably guilty of leaving a
fair number of these vulnerabilities in my wake over the years as well.

The problem isn't the app per se, but rather the methods that (inexperienced)
developers are using to add functionality to them.  An API that users
can use to scrub variables ahead of time, do safe includes/requires, and
verify authentication/authorization before it even tries to execute
anything would help improve the situation.

> One of the security benefits from a CMS like Joomla is that it can be
> installed and then a password given to the user for maintenance.  After
> this, there is no need to have a system user account, no shell access,
> no ftp access, etc. 

That doesn't matter.  What's being compromised is the account under
which the web server runs.  And denying that account stuff like a shell
or home directory in the /etc/password isn't protection, either... all a
hacked up version of telnetd needs is a uid, some space in /tmp, and a
free socket above 1024 to listen on.

> However, although security though obscurity is not ideal, one of the
> things I usually do before putting a Joomla/Mambo site online is to
> remove the tag showing what kind of CMS it is.  

That's a great idea.  :)

We have historical precedent for a worm that was tailored to seek out
specific versions of an application by checking the welcome message
(lion from 2001).  The only thing that saved the company I was working
for at the time from having to deal with hundreds of compromised RH 6.2
systems was that the wu-ftpd had been rebuilt internally and thus wasn't
recognized by the worm during its scans.

We turned off advertising versioning information in our default installs
shortly after that.  ;)

-- 
K. Spoon <kell at spoonix.com>