Hacked - FreeBSD 7.1-Release
kama
kama at pvp.se
Mon Dec 14 14:51:34 UTC 2009
Hi!
This is (most probably) a php coding issue and not e FreeBSD related issue
per se.
I would look into what type of application you run on your website and the
permissions you have on your files. Check if there is something that can
be upgraded. I know that at least phpBB2 had these issues in the past.
I have seen this for years... If you take some text in from the
hacked site text and search google, you will probably not be alone. You
will probably also find out what application and what part of the code
that are causing this.
Also look into what modules that are loaded by php. If you dont need to
write anything to disk or execute programs from php, disable it.
You can make the files and directories that should be writable to have the
write flag and disable it for the rest. Or have another user owning the
files and enable write for that user. php does not use with .htaccess, so
you cant rely on that.
You will maybe find something in the apache access log that can make you
find out what have been done.
This is quite easy to do if you know what application is running and how
it works.
Just an example: (Tested and working)
If you have something like:
<?
echo exec($_REQUEST['a']);
?>
in filename.php. It does not seem too harmful. It will just echo the data
from what being executed from a form. like 'ls'.
But then you can just add to the URL something similar to:
http://www.anything.tld/filename.php?a=echo%20You%20have%20been%20hacked%20%3E%20index.php
Which, for clarity, represent:
http://www.anything.tld/filename.php?a=echo You have been hacked > index.php
This will execute exec("echo You have been hacked > index.php"); and
overwrite the file.
(That is if its writable and owned by the httpd process)
Then if you add a shell script, using 'find . -name index.php -type f'
and loop through the results, you end up with a whole site that is
"hacked".
I believe the script kiddie uses a more sophisticated way of executing the
overwriting code.
Its too easy to write dangerous code in php and you need to be careful
when writing it or else something nasty will hit the fan faster than you
say dr. Hfuhruhurr...
/Bjorn
On Thu, 10 Dec 2009, Ganbold wrote:
> Squirrel wrote:
> > I do have most of measure you've mentioned implemented. There is one website that is required to have register_global, which I have set on his directory/.htaccess to prevent site-wide. Currently, I'm in process of upgrading all my ports.
> >
>
> Don't forget to check vulnerable php codes for SQL injection, LFI/RFI,
> problematic file uploads etc.
>
>
> Ganbold
>
> > Thanks for info.
> >
> >
> > -----Original message-----
> > From: Matthew Seaman m.seaman at infracaninophile.co.uk
> > Date: Thu, 10 Dec 2009 02:24:34 -0600
> > To: squirrel at isot.com
> > Subject: Re: Hacked - FreeBSD 7.1-Release
> >
> >
> >> Squirrel wrote:
> >>
> >>> I've just finished the rtld patch. Now in process of regenerating
> >>> all the keys and certs. Next will look into php. But far as rtld
> >>> vulnerability, doesn't it require at least a local user account?
> >>> Looking at all the authentication, there wasn't any authenticated
> >>> session during the time frame. So I'm leaning more towards php
> >>> 5.2.9, and checking all my ports.
> >>>
> >> You don't necessarily need to have a login session (ie. recorded in wtmp)
> >> to exploit the rtld bug -- just control over some process and the ability
> >> to run commands through it. Although the rtld bug is "only" a local root
> >> compromise, since it is so simple to exploit it is a lot more dangerous
> >> than most, and in combination with just about any form of remote exploit
> >> it means your box get rooted.
> >>
> >> Upgrading PHP and all ports is a good move. portaudit(1) is a good idea
> >> but it doesn't necessarily address the direct route your attackers used_
> >> My suspicions (in the absence of any detailed forensic examination of
> >> your machine) are that you are running some vulnerable PHP code. This
> >> may be part of a well known application, or it may be something locally written.
> >>
> >> In this case, I'd recommend a number of measures:
> >>
> >> * Run a security scanner like nikto (ports: security/nikto)
> >> against each of the websites on your server. Do this at
> >> regular intervals, and take action to fix any problems it
> >> discovers.
> >>
> >> * Make sure that you only grant the minimum necessary permissions
> >> on the filesystem to allow apache to run your applications. In
> >> general, everything under your doc root should be *readable* by
> >> uid www but not *writable* -- don't be seduced by the idea of
> >> making the webroot owned by www:www --- root:wheel is a much
> >> better idea, and files should be mode 644, directories mode 755
> >> unless there's a good reason to have them otherwise.
> >>
> >> * Refuse to run any PHP application that requires you to have
> >> 'register_globals = YES' or to similarly poke enormous holes
> >> in security through php.ini. Any application developer that
> >> has not modified their code to use the $GLOBALS array by now
> >> is lazy and incompetent and their code is likely to have all
> >> sorts of other holes.
> >>
> >> * Similarly give your web application only the minimum necessary
> >> permissions it needs to access any databases. You'll frequently
> >> see instructions to do things like: 'GRANT ALL PRIVILEGES ON foo.*
> >> TO www at localhost WITH GRANT OPTION;' This is way too much and should
> >> be trimmed down. Web apps rarely have any need to make schema
> >> changes, and creating other UIDs is right out, so
> >> 'GRANT SELECT,INSERT,UPDATE,DELETE ON foo.* TO www at localhost' is a
> >> much more reasonable starting point.
> >>
> >> * Where a web application has a legitimate reason to want to write
> >> to the filesystem (eg. uploading files), preferably confine the
> >> write access to a separate directory tree outside the web root --
> >> /tmp or /var/tmp aren't bad choices, but it might be better to
> >> create a specific location for a particular application.
> >>
> >> * Where a web application has an administrative mode preferably
> >> arrange to run this over HTTPS thus protecting any passwords
> >> from snooping. If the administrative mode needs to have generic
> >> read/write access to the web tree, then consider running it in a
> >> completely separate Apache instance with different user credentials
> >> than the generally accessible web server.
> >>
> >> Making the last point work with some arbitrary web application is
> >> frequently challenging, but usually at least possible by a combination
> >> of mod_rewrite and mod_proxy functions in the Apache config.
> >>
> >> Cheers,
> >>
> >> Matthew
> >>
> >> --
> >> Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
> >> Flat 3
> >> PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
> >> Kent, CT11 9PW
> >>
> >>
> >>
> >>
> > _______________________________________________
> > freebsd-stable at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
> >
> >
> >
> >
>
>
> --
> I'm glad that I'm an American, I'm glad that I am free, But I wish I
> were a little doggy, And McGovern were a tree.
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>
More information about the freebsd-stable
mailing list