raymor
01-07-2008, 09:24 PM
According to SANS Insititute, the single most frequently attacked vulnerability in 2007 was
PHPs "allow_url_fopen" setting. allow_url_fopen is a PHP setting which tells PHP to treat a
URL as a file and potentially run a PHP script on your server that the cracker has put on his
site. Combined with suexec, running PHP as your FTP user name, these two settings are
virtually the same thing as giving all visitors to your site SSH shell access into your server.
The number one thing you can do to secure your server today in five minutes or less is to
turn off allow_url_fopen in /etc/php.ini. allow_url_fopen is used by crackers to install
root kits on Linux and FreeBSD servers and to totally take control of Windows servers
by using PHP’s SMB file wrappers. Once rooted in this way, the server is essentially
trash and has to be completely re-installed. There is no other way to clean up the server
and secure after such a breach.
Several of the other top security issues in 2007 are PHP related and can be avoided
with some simple configuration changes in /etc/php.ini, so I highly recommend securing
your PHP by following a howto such as:
http://aymanh.com/checklist-for-securing-php-configuration
Once your PHP is secured, some scripts may give errors. This is, in my opinion, a flaw
in those scripts which should be fixed. Fixing a script to run in a secure environment is
normally a pretty quick and easy job for the script's author, so I would insist that they fix
the insecure lines in the script before using it.
Another big problem we saw in 2007 is a lot of SQL injection attacks.
There are a couple of reasons for the rise in SQL injection attacks and the
number of PHP related attacks generally. One is that PHP makes it very
easy to write scripts using MySQL, even when MySQL isn't the best tool for the job.
Because PHP makes writing scripts easy and makes using MySQL pretty easy, the
combination attracts "scripters" who are not qualified programmers. These individuals
have not taken classes in programming or security and have read few if any books
on the subject, so while they manage to make the script "work", they are not educated
in how to do so securely and other aspects of quality programming and systems
design.
Another reason for the rise in attacks is the rise of "Web 2.0", user generated content.
Blogs, message boards, wikis and many other technologies allow any visitor to your site
to modify your site, generally by using PHP scripts which run off a MySQL database.
While much of the user generated content is valuable, a certain perecentage is added
maliciously, with crackers using your site to attack your visitors browsers or submitting
carefully crafted submissions which do harm to your database or other parts of your site.
A common example of what we call an SQL injection attack takes advantage of code that
looks like this, which is supposed to check to see if the user is an admin:
SELECT is_admin WHERE username='$user'
The idea is that the visitor enters a username such as "Dave" and PHP sends the
following query to the database to see if "Dave" is an admin:
SELECT is_admin WHERE username='Dave'
However, consider what happens if I enter my username as "nobody' or is_admin='true"
Subsituting that "username" into the query ends up doing something entirely different
from what the script author wanted:
SELECT is_admin WHERE username='nobody' or is_admin='true'
Using that fake username I'll ALWAYS be granted admin access!
This is the type of attack that we were able to use in testing to
get admin access to this very forum a couple of years ago. (We fixed
it after that, of course, so don't bother trying it now - it won't work here.)
To avoid SQL injection attacks and other similar attacks, ensure that
any script you have which accepts ANY type of input from the user is
always up to date with the latest security pataches. Especially for any
custom scripts, insist that the programmer properly sanitizes all user input
and uses a php function called mysql_real_escape_string() for all SQL
queries involving user input. Note that mysql_real_escape_string is NOT
enough by itself - the script must first check the input for disallowed
characters such as the equals sign, etc. Perl has a similar function that
is slightly more secure than PHP's mysql_real_escape_string(). When using
Perl, ensure that all qeries are first prepare()d using question marks for values
with any user input passed into the execute() call to avoid SQL injection.
That's the new information this week, covering the top server security issues of 2007.
Remember, though, always the number one best way to secure a script is to get rid
of it. A cracker can't use a script that you've deleted, so take a look in your FTP and get
rid of any unused or unnecesary scripts, and be sure that you have a SOLID back up
plan in place so that you can recover from any security breaches.
We can help you with some of the best back up in the world. CloneBox creates an
exact replica of your server just as it was 24, 48, and 72 hours ago, ready to take over
at a moments notice in case of any problems with your main server.
PHPs "allow_url_fopen" setting. allow_url_fopen is a PHP setting which tells PHP to treat a
URL as a file and potentially run a PHP script on your server that the cracker has put on his
site. Combined with suexec, running PHP as your FTP user name, these two settings are
virtually the same thing as giving all visitors to your site SSH shell access into your server.
The number one thing you can do to secure your server today in five minutes or less is to
turn off allow_url_fopen in /etc/php.ini. allow_url_fopen is used by crackers to install
root kits on Linux and FreeBSD servers and to totally take control of Windows servers
by using PHP’s SMB file wrappers. Once rooted in this way, the server is essentially
trash and has to be completely re-installed. There is no other way to clean up the server
and secure after such a breach.
Several of the other top security issues in 2007 are PHP related and can be avoided
with some simple configuration changes in /etc/php.ini, so I highly recommend securing
your PHP by following a howto such as:
http://aymanh.com/checklist-for-securing-php-configuration
Once your PHP is secured, some scripts may give errors. This is, in my opinion, a flaw
in those scripts which should be fixed. Fixing a script to run in a secure environment is
normally a pretty quick and easy job for the script's author, so I would insist that they fix
the insecure lines in the script before using it.
Another big problem we saw in 2007 is a lot of SQL injection attacks.
There are a couple of reasons for the rise in SQL injection attacks and the
number of PHP related attacks generally. One is that PHP makes it very
easy to write scripts using MySQL, even when MySQL isn't the best tool for the job.
Because PHP makes writing scripts easy and makes using MySQL pretty easy, the
combination attracts "scripters" who are not qualified programmers. These individuals
have not taken classes in programming or security and have read few if any books
on the subject, so while they manage to make the script "work", they are not educated
in how to do so securely and other aspects of quality programming and systems
design.
Another reason for the rise in attacks is the rise of "Web 2.0", user generated content.
Blogs, message boards, wikis and many other technologies allow any visitor to your site
to modify your site, generally by using PHP scripts which run off a MySQL database.
While much of the user generated content is valuable, a certain perecentage is added
maliciously, with crackers using your site to attack your visitors browsers or submitting
carefully crafted submissions which do harm to your database or other parts of your site.
A common example of what we call an SQL injection attack takes advantage of code that
looks like this, which is supposed to check to see if the user is an admin:
SELECT is_admin WHERE username='$user'
The idea is that the visitor enters a username such as "Dave" and PHP sends the
following query to the database to see if "Dave" is an admin:
SELECT is_admin WHERE username='Dave'
However, consider what happens if I enter my username as "nobody' or is_admin='true"
Subsituting that "username" into the query ends up doing something entirely different
from what the script author wanted:
SELECT is_admin WHERE username='nobody' or is_admin='true'
Using that fake username I'll ALWAYS be granted admin access!
This is the type of attack that we were able to use in testing to
get admin access to this very forum a couple of years ago. (We fixed
it after that, of course, so don't bother trying it now - it won't work here.)
To avoid SQL injection attacks and other similar attacks, ensure that
any script you have which accepts ANY type of input from the user is
always up to date with the latest security pataches. Especially for any
custom scripts, insist that the programmer properly sanitizes all user input
and uses a php function called mysql_real_escape_string() for all SQL
queries involving user input. Note that mysql_real_escape_string is NOT
enough by itself - the script must first check the input for disallowed
characters such as the equals sign, etc. Perl has a similar function that
is slightly more secure than PHP's mysql_real_escape_string(). When using
Perl, ensure that all qeries are first prepare()d using question marks for values
with any user input passed into the execute() call to avoid SQL injection.
That's the new information this week, covering the top server security issues of 2007.
Remember, though, always the number one best way to secure a script is to get rid
of it. A cracker can't use a script that you've deleted, so take a look in your FTP and get
rid of any unused or unnecesary scripts, and be sure that you have a SOLID back up
plan in place so that you can recover from any security breaches.
We can help you with some of the best back up in the world. CloneBox creates an
exact replica of your server just as it was 24, 48, and 72 hours ago, ready to take over
at a moments notice in case of any problems with your main server.