Jump to content

Archived

This topic is now archived and is closed to further replies.

Guest

Anatomy of a Hack

Recommended Posts

Guest

With more and more people claiming that their installations of CubeCart have been hacked, I thought it appropriate to explain a bit about how most hacks occur and what to do about them.

The first thing we need to clarify is a problem in terminology. If somebody really did HACK your site, they would have found a way in to your admin or FTP. This could have been by guessing the password or by a brute force or dictionary password attack. This is NOT what happens to most installations or servers. So what is happening? Exploits.

An exploit is finding an existing security hole and taking advantage of it. There are many known exploits out there with software payloads that do everything from spamming to running IRC bots to portscans to collecting personal info from users. MOST are spamming and botnet attacks.

What most people see when they've been "hacked" is extra files in their /images/upload/ folder. This is because those folders have permissions set to "777". This means the folder is world-writable by everybody, including the web server -- user "nobody" for you more technical types. This is done to allow you to upload images to this folder. The potential problem is that ANY process on the web server can then write to this directory.

Now, the big question, HOW does that stuff get there? In disecting several exploit packages, there are several similarities that we'll discuss. The simplest ones put their payload into /tmp or /var/tmp. These are temporary folders setup by the operating system on the server for....uhhh...temporary stuff. Sessions, process IDs, etc are stored there. They are also world-writable.

The exploit code loads a small script into the /tmp folder and executes it. Sometimes that's all that happens, the code runs from /tmp and it does what it needs to. But some scripts are sneakier. They will perform a search on the server for other world-writable directories. They don't care where they are. But they will frequently load their payload into ALL world-writable folders....including YOUR CubeCart installation.

Herein lies the problem. There is typically NO trace of how those files got into YOUR folders. Just because they were in your store folders does NOT mean that they came in through CubeCart. I found one such instance where the exploited script was a forgotten portion of a web site that hadn't been touched in nearly 3 years. It was an older version of a software package that wasn't used much anymore. Unfortunately there was a published attack for it. That hole was exploited and the server compromised.

These "hackers" are almost never programmers themselves. They are what's known as "script kiddies". They find these exploit scripts on sites out there and use them for their own jollies. They also rarely have ill intentions against the servers or sites they exploit. They just think it's cool to do.

If you find stuff in your folders that shouldn't be there, let your hosting company know. The things they'll want to check are unknown or unusual files and folders in /tmp, /var/tmp/, /usr/tmp, /usr/local/tmp, and/or /dev/shm. Those are common payload dropoff locations. Also watch for unusually high server loads or unfamiliar processes running as user "nobody" (or whatever user Apache runs as). This can be done easily with this command under Linux: ps -f --User nobody.

If anybody would like to go into more technical detail, I'll be happy to in a private discussion. The main think I wanted to make people understand is that what they think happened may not be what really has happened. As of this writing, there are no known security holes in CubeCart. Hopefully this explanation will help people understand what really happened on their sites when they're "hacked".

-- Sir William is a programmer and systems/network administrator at an ISP in Arkansas, USA. He has been working with computers for over 23 years. He is a modertor here at CubeCart.com and a founding Administrator at CubeCart.org. He's contributed several modifications and additions to the CubeCart base code and spends countless hours helping others in both free and paid-consultancy capacities.

:w00t:

Share this post


Link to post
Share on other sites

Thanks for the work Bill. Always looking out for our best interests.

Another way to thwart these exploits is to poney up for a private IP with your host. It's money well spent.

Share this post


Link to post
Share on other sites
Guest Brivtech

A nice article Bill, especially with the file permissions vunerability. To follow up, it would be good to mention some additional things people can also do to help prevent hacking:

- Make regular backups - If your site has been hacked, then at least a backup can get it back to where it was before the hack was made. Always the first piece of advice, and will save many tears if some idiot getsinto your site and corrupts your data. I have heard some hinting that CC3.1.0 will have a built in backup facility, so there will be no excuse! I store files that are FTP's into place in a folder, then when I've performed the FTP, I copy the folder onto a CD, label it, and put it away in an archive storage. We also have server backups made automatically, but going through an 800GB tape just to restore a few files can take forever! Backup your FTP files whenever you make changes (Because they don't otherwise normally change), and your SQL database on a regular basis (As it does change quite often).

- Don't use easy passwords. Password dictionaries are lists of words and commonly used passwords, and are fired at your login until the list is exhausted, or one of the words works. They often include combinations of numbers and letters, so one of the best ways around this is to jumble the password up even more, so it's pratically random (Cabage55, or Robert are bad passwords, whereas kw8pSM5jT is much more difficult to break). Use a mix of upper and lower case letters (If your passwords are case sensitive).

- Never give your passwords out (Unless you absolutely have to and there's no other choice). From my experiences, customers who have faced hacking have often done so because they gave someone a password to a friend who helped them out with something. A fallout with a friend later, and you could have a wrecked site. Which leads me directly onto the last point...

- Change passwords regularly. If someone does get a password, they may not always use it immediately. Changing passwords helps prevent this delayed access, and as I alredy mentioned, clears access from people with previous authorisation.

- Always update software you are running on your webserver on a regular basis! I know that's been covered but needs to be more obvious. I have seen lots of cases where an old version had security flaws, and a customer was hacked because they didn't want the hassle of re-applying MODs, not even for a major security update version.

Just to mention that these are all precautions, and will not guarantee that you will not be hacked.

Share this post


Link to post
Share on other sites
Guest

Good info Brivtech. Another point for those people who hire a programmer/developer to make changes to their site for them would be to change your password BEFORE you give it to them. Set the password to something simple, let them do their work, then change it back. ESPECIALLY if you're the kind of person who uses one password for nearly everything....you know who you are.

With CubeCart's admin functions, it's even easier. Simply create a new administrator login for the programmer then delete it when they're done. Poof. :D

:w00t:

Share this post


Link to post
Share on other sites

Well, great explanation Bill, addtional points Brivtech :w00t: Attention at computer viruses world too.

BIG majority of regular users NEVER do change passwords, do use EASY (family names, isp name, site name and so on....) and the same password for everything. Do some 'change action' when something occurs sometime is almost useless. IT WORKS and we'll do when occurs something - this is the result of human nature. :D

It was, it is and it will always be - thats my experiences in IT World since 1981. :)

I think this topic should read regular user daily as the Holy Bible.

Share this post


Link to post
Share on other sites

Absolutely brilliant piece of info and follow ups. Thanks chaps.

Share this post


Link to post
Share on other sites
Guest thimk

So can one simply chmod 777 after images are uploaded???

Or doesn't FTP offer a bypass of this problem?

By the way, how does one prevent image-link from spilling the beans?

Image right click copy link location gives

http://www.domain.com/cube/images/uploads/image.jpg

Or how should one chmod to prevent mischief?

Share this post


Link to post
Share on other sites
Guest Desire

Guys is this been Hacked. Please go check www.secretdesire.co.nz

cannot acces admin, site or ftp:

I will need help trying sort this out

This is the 2nd time I have been hacked in 1 month.

Is there anything I can do to stop it as it driving me crazy,

Every time i start getting head way in the no of hits i get this happens.

Please go check my website out and if you believe this is not hacked then please tell me how do i get it back.\

And if you believe it is hacked, how do i sort it out?

Share this post


Link to post
Share on other sites
Guest

So can one simply chmod 777 after images are uploaded???

Or doesn't FTP offer a bypass of this problem?

By the way, how does one prevent image-link from spilling the beans?

Image right click copy link location gives

http://www.domain.com/cube/images/uploads/image.jpg

Or how should one chmod to prevent mischief?

I think one of the main things that has been missed from the above articles has been the correct permissions for the images folder. If you are uploading via FTP or through the CubeCart control panel, you will be an authenticated user, so ideally, only the first number should be a 7. I would recommend a chmod to 744, for the images folders only, this is the most security concious approach. This allows an authenticated user on the webserver to load, execute and read files, but only allows reading of files by all other users.

The only time you should need any more than this is if you are running the batch conversion scripts, in which case 755 will do the trick, this allows execution of any scripts that are in place in the relevant folders. The important thing is that it prevents unauthorised users adding scripts that can then be run.

This should prevent any further mischief. In reality, starting from this premise (755) for all folders on a web server is not a bad idea. In theory, if it as upload from a user through cubecart or other PHP script, the actual writing to the database or webserver would be carried out by the script and as such, would be an autenticated user. Also permissions for the individual image files could and maybe should be changed via chmod to 644, as these should never need execute rights, this will help stop some of the potential issues that may be exploited in corrupt jpeg files.

Share this post


Link to post
Share on other sites
Guest

Martin, what you're saying is indeed true for CGI/Perl scripts, but the vast majority of servers pay no attention to file or folder permissions to execute PHP scripts. While this is good on one hand because so many people really don't understand permissions very well, it's also less secure overall.

Also on Linux/Unix servers, if you don't set the x bit on directories, you won't be able to access anything within them.

You say that they need to use 755. That won't work unless the server is setup with PHPsuExec. Without that, all PHP processes run as the same user as the server -- "nobody" in most cases. That means you'd need world write permissions set on the folders/files to be able to change them. This would be 757/777 for folders and 646/666 for files. To make them "safe" again after changes, you'd take them back to 755 and 644 respectively.

I try not to confuse people more than they already are. :)

;)

Share this post


Link to post
Share on other sites
Guest

As they say, every day is a school day!

My background has been as a UNIX user and so the file permissions become second nature, hadn't realised PHP was quite so loose for security. Leaves it fairly simple for the script kiddies if they can drop a file onto your server.

I stand corrected ;)

Share this post


Link to post
Share on other sites
Guest

The issue is not PHP so much as Apache in the way it handles it.

;)

Share this post


Link to post
Share on other sites
Guest

I was actually looking for a good place to say thanks to Al and the CC team for releasing the latest patch the way they did. It's very helpful to include the changelog (difference) file with any patch so that those of us with outrageously customized installations can easily implement the changes. THANKS for that!

But now that I found this thread, I think I'll add something to the collective pot...

For those of us who are running Apache servers, is there not a way that we can use htaccess as a preventive measure against many cross-site scripting exploits (which are distinct from the specific type of exploit that Sir William described above, but have ocurred several times with CC, including in this recent patch)? For example, if an exploit depends on including some random file from FCKeditor that turns out to be vulnerable, if we have added htaccess password authentication to the admin directory then there's no way to bypass this to include it from another site. Similarly, shouldn't the modules and includes and assorted other directories that never need to be accessed directly through a browser have htaccess files in them denying all direct access?

It seems to me as if this would protect against an entire class of attacks that prey on minor bugs like the one patched today. Anyone tried this? I have meant to experiment with this for a while now, but I've been too insanely busy to get around to it...

AFAIK, the only reliable defense against the type of exploit described by Sir William (images folders set to 777 permissions) is to change them back to 655 whenever you're not using the image upload/thumbnail creation scripts. Perhaps when more servers have switched to running PHP via Suexec we will be able to have a script within the admin area that toggles permissions on those directories before and after uploading images. But for now as Sir William says most servers are configured to run PHP as 'nobody', which doesn't protect sufficiently and complicates setting permissions via PHP.

Share this post


Link to post
Share on other sites
Guest

For those of us who are running Apache servers, is there not a way that we can use htaccess as a preventive measure against many cross-site scripting exploits (which are distinct from the specific type of exploit that Sir William described above, but have ocurred several times with CC, including in this recent patch)? For example, if an exploit depends on including some random file from FCKeditor that turns out to be vulnerable, if we have added htaccess password authentication to the admin directory then there's no way to bypass this to include it from another site. Similarly, shouldn't the modules and includes and assorted other directories that never need to be accessed directly through a browser have htaccess files in them denying all direct access?

It seems to me as if this would protect against an entire class of attacks that prey on minor bugs like the one patched today. Anyone tried this? I have meant to experiment with this for a while now, but I've been too insanely busy to get around to it...

OK I finally got around to it. And it seems to work fine. I think this completely closes the door on all remote file inclusion (cross-site scripting) attacks.

Basically I added .htaccess password-protection to the admin directory. Then I added "deny to all" .htaccess files in the following directories: classes, extra, includes, language, modules, and pear. This means that PHP scripts on the same server (index.php, cart.php, etc.) can access these files, but remote includes will be denied access.

So far the only thing that I've noticed is that the Apache login box pops up twice to enter the admin area (which is a minor annoyance for which there is probably a solution EDIT: Duh. This was just caused by me first loading the non-secure page and then being forwarded to the secure server. If I use the secure https:// URL to start with I only get one Apache login.). If you use other gateway modules that need to open independently of the main files (like perhaps the print order module) then you may need to explicitly allow those files in your .htaccess for that directory. I may find other issues as time goes on, but so far nothing has freaked out or broken since I did this.

Anyone see any potential problem with this method of locking down the server a bit better? Or anything I'm missing? It makes sense to me, but that doesn't necessarily mean that it makes sense...

Share this post


Link to post
Share on other sites
Guest Captain Bags

Do you know what would be absolutely fantastic?

A basic guide to these types of security approaches, written with the average shared hosting user in mind. That would cover 95% of CC users IMO.

I know we are all humonguously busy, but a new thread alonng those lines would be great. It could provide the raw material for the eventual tutorial. This would be CC specific, with some general guidelines also.

For example, after I modify my Homepage in the CC Admin panel, it displays the message "Configuration Updated. Please make sure the file permission have been set back correctly." Good. But permissions on which file or folder exactly? And to what CHMOD settings?

I'm sure somebody will point me to the appropriate thread or post that was put up months ago! I just now realise that I did not search before making this post. Slap on wrist accepted and already self-administered. ;)

Share this post


Link to post
Share on other sites
Guest

Also on Linux/Unix servers, if you don't set the x bit on directories, you won't be able to access anything within them.

Excuse the nit-pick, but seeing your years of experience as an admin, correct me if I'm wrong, the x bit on directories is what allows you to read the directory to search for a file. You can still access any file in the directory that has read permission set without there being any x bit set on the directory as long as you know the full path to that file. You cannot do a directory command 'ls' and see anything in the directory, but you can certainly access any files that you know exist, including getting directory listings for any further subdirectories that do have the x bit set.

Like, I say, it's a nit. I believe that you should have said...

Also on Linux/Unix servers, if you don't set the x bit on directories, you won't be able to see the contents. If your script knows what files to access, it can still read or execute them just fine. A script-kiddie, unfamiliar with your site or CC files won't bother.

-Carl

Share this post


Link to post
Share on other sites
Guest

Another XSS security patch today: http://www.cubecart.com/site/forums/index....showtopic=21540

And since I have register_globals set to OFF and .htaccess protection as mentioned above my site is protected from this and other similar attacks. I may still apply the patch anyway (Thanks again to Al for including a manual change log!), but it's nice to feel secure against a very common type of exploit.

Anyone else tried this method yet?

Share this post


Link to post
Share on other sites
Guest croakingtoad

I just found an exploit on my server and my customer's data has been stolen and exploited.

I found in /home/account/public_html/cart/pear/tmp/date/

a set of files as below--

drwxr-xr-x 3 user user 1024 Sep 7 00:49 ./

drwxr-xr-x 3 user user 1024 Aug 24 12:25 ../

drwxr-xr-x 9 user user 2048 Sep 1 23:36 dara/

-rwxr-xr-x 1 user user 871077 Jul 28 20:05 dara.tar.gz*

-rwxr-xr-x 1 user user 169494 Aug 30 17:23 input.php*

-rwxr-xr-x 1 user user 2409 Aug 31 21:11 main.php*

-rwxr-xr-x 1 user user 152613 Aug 9 10:49 turu.php*

How did these files get here and how can I lock this down from happening again?

Quick replies would be extremely helpful!!

Share this post


Link to post
Share on other sites
Guest

Things we need to know in order to give you useful advice:

* What type of server you are on (Linux/Windows, Apache, shared or dedicated, etc.)

* What version of CubeCart you are running

* What version of PHP and mySQL you are running

* If you have register_globals on or off

All I can tell from your post is that someone has complete access to your account. They were able to write and execute files, and apparently they were able to get to your mySQL info and access that as well. That could be anything from someone stealing your password to a XSS attack to an exploit of some unpatched software on your server.

You should of course change your server and mySQL and CubeCart passwords right away, and I would probably use .htaccess to password-protect the site while I figurd out what was going on and dealt with it.

If this is a commercial host, you should advise the admins of the situation and see if they can find any useful info in the server logs.

Share this post


Link to post
Share on other sites
Guest croakingtoad

Thanks for the quick reply, here's my info--

This is a linux server running php 5.0.5. This is on a shared server. Cubecart is 3.0.4 and mysql is 4.1.21-standard. Register_globals is ON.

Could someone have used an exploit in the software to upload to this /tmp file?

I'll start battening down the hatches and I appreciate any more information you-all can give me to lock the /tmp folders down.

Share this post


Link to post
Share on other sites
Guest

Thanks for the quick reply, here's my info--

This is a linux server running php 5.0.5. This is on a shared server. Cubecart is 3.0.4 and mysql is 4.1.21-standard. Register_globals is ON.

Could someone have used an exploit in the software to upload to this /tmp file?

I'll start battening down the hatches and I appreciate any more information you-all can give me to lock the /tmp folders down.

OK well that does explain what probably happened. There have been a few important security patches since CC 3.0.4, and at least two that I remember involved XSS (cross-site scripting) attacks that would have allowed a hacker to write and execute files to your server (and from there it's game over). So that's very likely what happened, and it is something that you can fix.

I would lock down your entire site with .htaccess password-protection while you're patching everything. I would then download a backup of all files on your site and then delete everything on your server. That's the best way to be sure that there are no other hacker scripts hidden somewhere that will force you to do this all over again in a few days.

Then you will need to upload all your files again, but do so from your clean original local copies (except for images that you may have uploaded, etc. - those are pretty safe to copy from the backup you just downloaded).

You should then be back to where you were a few days ago, so test out your site to see.

Then you should either upgrade your version of CubeCart to the latest or (if you have a heavily modified version) go through all of the patches since 3.0.4 and apply them.

You will now have a patched version of CC, which should not be vulnerable to the exploit that you got hit with. you should also make sure that you set register_globals to OFF to prevent many possible future attacks. To do this, just add the following line to your main .htaccess file:

php_flag register_globals Off

If your server doesn't allow you to set PHP directives via .htaccess you will get a 500 Server Error after you do this. In that case, remove it from your .htaccess and contact your host about adding this to your php.ini file. Changing PHP settings on shared servers via php.ini files can be somewhat more complex, so if you have a host who will help you to be sure that it's done right it's worth asking them.

Then you should be able to remove the password protection and go to a movie or something to unwind after all this stress...

Share this post


Link to post
Share on other sites
Guest GoodwearD

Hi there,

I'm not sure whether to post this here or somewhere else - but I'm sure someone will tell me either way! ;)

Have I been hacked or cross-site script exploited ? I have m0nty's excellent 'member approved' mod running. Just this week anyone who completes the 'register as a new customer' gets transferred to a new browser with the site http://gerryshaw.com.au which is another CC store...!

I have looked in images/uploads but cannot find anything fishy in there. Have you any ideas how I might track this one down ?

I'm running 3.0.10 btw.

Many thanks,

DG

Share this post


Link to post
Share on other sites
Guest Jethro

Just to add to everyones sense of well being.

If your hosting company uses cpanel, ensure they have patched to the latest release there's a huge hole in some of the previous versions.

We just moved to a very secure hosting company, costs a lot more than we are used to paying, but how much piece of mind ;)

Share this post


Link to post
Share on other sites
Guest spatulafish

Hi there - your info makes sense to me.

For the first time in what must be a couple of months I looked at the ftp folders on my site at www.constructionsupermarket.com and saw that there are some folders there which I do not recognise.

see attachment.

The folders are _vti_log (empty) and _vti_pvt in the main directory. vti_pvt contains files access.cnf, frontpage.lck, service.cnf, service.grp, service.pwd.

All of this looks a little strange to me?

ANy ideas please...? There is no 'sign' of hacking...

There is an outside chance that this is friendly fire form a consultant doing some work on the site, but he is away at the moment and I cannot check....

Appreciate any ideas

Alex

Share this post


Link to post
Share on other sites
Guest Arild

The files you mention here look likes it belong to frontpage extensions. And if they are on a CC site you can delete them all.

It may be that you are on a host that support frontpage extension, a windows server, or that you have turnd on frontpage extension.

Share this post


Link to post
Share on other sites

×
×
  • Create New...