Parse error: syntax error, unexpected uri.php on line 757

[cotharyus]

Hello,
I am an employee with IX. This thread was brought to my attention by one of our customers, and I have seen this issue myself on my own site which I host with IX. I want you all to know that I would like to see this sorted out. I would ask that each of you please PM me with your domain name. I am collecting information to confirm every possible detail of this compromise and have it permanently taken care of. I want to thank all of you for the time you take to provide me with this information so that I can help you.

[scottyj]

Hey cotharyus, appreciate you guys looking inot this.
Sadly it has come to late for our account, as we have just been suspended for our 3rd violation of the TOS. I'll still PM you, hopefully we can work this whole thing out.

Scott

[AZ SnakePit]

Our account was compromised once again, with a phishing script uploaded to the cache directory. At least we spotted it within a couple of hours. Is there an issue a) with this folder being 777, and b) disabling the permissions. Alternatively, can the cache folder be relocated to an area that cannot be accessed online?

All the phishing attacks seem to come through these 777 folders. The IX Web Hosting rep I spoke to said that this basically allows hackers to run scripts which will upload anything into these folders and then chown them to httpd: seems a little doubtful to me?

[cotharyus]

More specifically, 777 is global full permissions. It gives the httpd process permission to write to the folder, thus files can be created by httpd, and since created by, hence owned by httpd. Unfortunately, move the directory to a non-web accessible location can require some programming abilities, the other option is simply taking a known folder name (such as cache) and renaming it something obscure (yes, security through obscurity is BAD) which will at least keep the script kiddies from being able to use a standardized script designed to utilize the cache folder to perpetrate this sort of thing.

[nathalie77]

I am also with IX webhosting and I have this problem. It is happening on all of my wordpress installations, in all of the php files. (I realize this is a joomla site, but I just wanted to mention that it's happening on other platforms too!) I have many domains and this is really unacceptable!

[cotharyus]

nathalie, I have confirmed instances of joomla, wordpress, oscommerce, e107, phpbb and at least two types of photo gallery having this issue. The specific vulnerability that's causing this has been narrowed down and is being worked on. I cannot begin to address, in a forum, the complexity of making the changes we need to make in the environment we have, but I want to assure you that this problem, having been brought to the full attention of the people responsible for taking care of it, is receiving the highest attention. I will try to keep anyone watching aware of any official information as I receive it. Thanks to you all for your input on this.

[MurrayB]

This issue is currently happening to me, was about to launch my site again today, after a [* spam *] hack injected my 1.0.13 site, so I decided to reinstall and migrate to 1.5.6 was about to launch today, except my site had the following:
Parse error: parse error, unexpected '<' in /hsphere/local/home/XXXXXXX/mydomain.org.au/cms15/libraries/joomla/environment/uri.php on line 757

This original [* spam *] hack was not detected until we did a view page source and discovered:

My thoughts are that is has something to do with HsPhere. previous posts and searches all have HSPHERE as part of the host package.

I dont beleive this to be a Joomla fault, other wise it the above code would be contained to just my Joomla folder, but the script was in many of my .php files.

I will keep you updated, hopefully this will help those who have gone through the same pain as me.

Murray

[depaulus]

h**p://www.hostexcellence.com belongs to IXwebhosting

Yesterday after just a week and a half two of ny buisness accounts were injected for a 3rd time in a month.16 websites infected AGAIN!!


Yet again I spoke to support, and yet again the blame gets pointed elsewhere.. This time I also spoke to a "Manager" who was very honest and admitted that IXweb has a problem, but said it was very difficult to fix due to the fact that it is a shared server enviremont.. And because certain (old) software will not run...

As mentioned before, so far EVERY site I know of that has this problem is hosted at IX or Hostexcellence that they own.

Thing is, most people do not even know they have been injected!!

Please everyone with an acoount that has been infected, PM me your website name, and / or Buisness plan # If I have enough evidence, I will take matters further .

And contat IXweb, and ask for a Manager. The more people that do this, the quicker IX will hopefully do something about it

[AZ SnakePit]

One thing I did find out, was that my FTP access was apparently compromised too, even though my password was a strong one. I examined the FTP logs, and saw that my account was being logged into from a Dutch IP. I have reset my FTP password, so we'll see if that helps. It may be worth requesting the FTP logs for your account from IX and seeing whether that is happening to you too.

[mothnrust]

i too am with ix although running wordpress, or was

this is the response i received from tech support:

I have checked few WordPress forums and have found that this issue is related to php syntaxes. If you will take a look at http://wordpress.org/support/topic/135844 you will find out that even 2.3 WP versions require higher PHP version then you have. You current server support only php v 4.3.11 and you need 5 versions to use WP version 2.6 without errors. I may suggest you to move to a server with PHP 5 if you are going to use this WP version.

All folders and files that created via php will have owner "httpd". That is why you can't change permissions for them. Please use next steps to change owner:
1) Log in control panel
2) Enter FTP service
3) Enable FTP (or click edit if you already enabled it)
4) Click Add near Virtual ftp-directories
5) Add directory which contents files with incorrect owners (it can be yourdomain.com/ ) and click Submit.
6) Now click on the trash icon near this directory
7) Disable Virtual FTP

reclaiming ownership of the files worked perfectly - great - but it's not addressing the root problem

just thought i'd pass on the info,

j

[AZ SnakePit]

My site was compromised again, with the same injection into the jos_mambots table. More worryingly, the script in question which was being executed was entirely outside of my account. The path to it was [some identifying data removed for security]:

../../../../../../../../../../../../../../../../../../../../../hsphere/local/home/****/********/images/*****1.gif�

It seems a huge security loophole on the IX Web Hosting servers that a script on another account can be accessed and executed from my own account. I've created a support ticket pointing this out, but the location of this file does seem to support the theory that the source of the issue is a flaw in the H-Sphere software.

[mothnrust]

SnakePit i have something very similar. managed to get my site back up and running but when i went into plugins found the following message:

'The plugin ../../../../../../../../../../../../../../../../../../../../../hsphere/local/home/sarpicas/gallery.animeepisodes.net/data/606/thumbs/0_667_13.jpg has been deactivated due to an error: Invalid plugin.'

i've also raised a ticket

[AZ SnakePit]

SnakePit i have something very similar. managed to get my site back up and running but when i went into plugins found the following message:

'The plugin ../../../../../../../../../../../../../../../../../../../../../hsphere/local/home/sarpicas/gallery.animeepisodes.net/data/606/thumbs/0_667_13.jpg has been deactivated due to an error: Invalid plugin.'

i've also raised a ticket

I'd recommend using the phpMyAdmin Search facility to look for a string in that filename in your database. It looks like something may have been injected in there for your application. It appears increasingly that H-Sphere is indeed the source of the problem at IX.

[mothnrust]

thanks for the tip - didn't find anything though, but i'd already cleared out a lot of stuff that didn't seem relevant. having regained permissions and set up access controls everything seems to be working ok. found a security plugin that protects and monitors access etc, so maybe that'll also help (for WP).

no response yet from ix.

hope you're sorted,

j

[undertaker]

I host my websites with IX Web too, and ALL of my hosted sites got attacked every 1-2 week since July!!

I use none of joomla, wordpress, oscommerce, e107, or phpbb in ALL of my sites. Couple of my sites are simple PHP and HTML pages only. These sites also got attacked. Files ownership change to http:http or root:root. ALL files (php and html) with </body> tag get injected some [* spam *] ad before the tag.

I've contacted with IX Web support and created support tickets every time I got attacked; however, it still not solved till today. All they could offer is to use the backup to restore the websites.

I got their reply today, and they said the attack was relates to the Joomla sercurity "HOLE". I just want to confirm from Joomla Team that the attacked is indeed relates to Joomla. My question is, Joomla is not been used in ALL of my hosted sites, how come I got attcked? If the attack is from one of other website which shared the same hosting server, the cross site attack should relate to IX Web's server sercurity??

Here's IX Web's reply from their System administrators team:
"Thank you for contacting our technical support team!

Our system admins carefully investigated issues described at the forum you provided and confirmed that they relate to Joomla security "holes" only. They also suggested to verify several links in order to prevent such issues in the future:
http://alistapart.com/articles/secureyourcode
http://alistapart.com/articles/secureyourcode2
http://www.networkworld.com/news/2008/0 ... toweb.html
http://www.security-hacks.com/2007/05/1 ... n-scanners
http://en.wikipedia.org/wiki/SQL_injection"

[AZ SnakePit]

The people answering front-line IX tickets are very good at cutting and pasting canned answers, without actually looking at the issue, and that's about all they are good for. I got more or less the same response from them, despite pointing out to them that an account should not be able to execute a script located on another, entirely separate account.

I have re-opened the ticket, asking for it to be passed to a manager, or someone who will read the ticket and can understand the issue. I'd suggest you do the same: for IX Web Hosting to suggest it's a Joomla security issue when you aren't even running Joomla is completely laughable.

Anyone recommend a good Joomla host with decent security and support? Because I am increasingly certain that IX are not it.

[just462]

I don't think ix is being very honest with it's clients! I also host my non-joomla website on ix and I was hacked during the very same timeframe and in the exact same manner as everyone is mentioning in this thread.

I came across this thread by chance when I googled the malicious code.

I called ix this morning for the 3rd time and was lucky enough to get a hold of a manager that was kind enough to tell me the truth. According to what I was told this "is" an ix issue and it's one they have known about for a while and also something they are currently trying to fix.

The manager explained to me that the problem lies within the control panel. If you have an account that uses their new control panel your fine, but if your account uses their old control panel you are potentially vulnerable! They've known about this problem for some time and apparently they are trying to create an internal fix, but in the mean time their affected clients suffer.

My site has been banned in Google because of this and I can't begin to count the wasted hours spent trying to correct a problem that it turns out is uncorrectable on my end. All this after making repeated calls to ix where I was always told the problem was due to chmod or scripting vulnerabilities on my web folders or files.

Now I don't know if anyone else at ix is going to own up to this as the truth, but this is what i was told. I won't reveal the managers name that told me this because I'm sure he may take some heat for telling me the truth, but he did say that he is the ix employee that has previously posted on this thread. I would advise all to call them and demand to speak to someone that's capable of giving you a straight answer.

After dealing with their server fiasco back in Jan/Feb of this year when my site was offline for 2-3 weeks I have finally had enough of ix and will be moving my site immediately. If what I was told is true, I think it is very unethical for a company to withhold this type of info while their clients are adversely affected.

Can anyone reccomend a reliable web hosting company?

[nathalie77]

I have been searching for a new host as well. I am going with either media temple or dreamhost, but I've read about issues with both... though nothing as bad as these hacking attacks.

I wish everyone who stays with IX the best of luck. My sites are moving as of Monday.

[AZ SnakePit]

Thanks just462 for that info. I do feel some sympathy for IX. The last thing they want to do is to admit in any public way that their servers have been compromised and are insecure, so I don't blame them for playing their cards close to their chest in this: any admission could render them legally responsible for damages, etc. But this has now been going on since at least the 3rd, and it seems that the 'bad guys' know all about the exploits, so keeping their customers in the dark like this is simply fueling a lot of frustration.

[depaulus]

The Manager at IXweb I spoke to a couple of days ago also admitted it was an IX issue, he even went as far as to say that a lot of people do not even know they have been affected. He said that someone somewhere on the server cluster has a bad (shell) script, and someone is injecting the whole server through that script.
I have 4 accounts with IX, and 2 are getting injected every 10-14 days.
The support is terrible, although the people you actually speak to are very friendly, they just do not have a clue!!.. the only thing they think, is that any folder with 777 permission is a massive risk, even after you tell them you have a .htaccess in the folder to protect it.

The written support that comes from Eastern Europe is just a joke, written clearly but someone who can't read English, so does not even know what the problem is.

IX blames every script under the sun.. all my plain html sites were injected, as were joomla and Wordpress.

If IX does not fix this problem soon, I will post all the evidence I have to various sites and blogs, and the complaints bureau.

My sites were injected for a 3rd time on Sept. 17th.. I will bet anyone that it will happen again round about the 28th Sept.

We all need to stick together and get IX to finally and openly admit that they have a massive security issue.

[depaulus]

For anyone interested just how big this problem is, check this google query I did.

http://www.google.com/search?hl=en&sugg ... art=0&sa=N

(dont just check the first page, there are hundreds!!!)

Note all the : /hsphere/local/home/******/******. com

[scottyj]

Just a reminder to everyone, that whilst I'm sure IX are doing whatever they can to fix it, in our case, we got locked out after 3 attacks, and no amount of arguing would get them to reopen our account. Nor would they refund our remaining 6 months. Fair enough if this was our fault, but it clearly wasn't, and I'm still a bit peeved at their attitude to help us (which was to cut and paste answers already prepared). We have also been added to a phlishing site, which lists bad sites, and as a legitmate business, this also peeves me off.
The problem is clearly on their end, and if they feel it is the software we use has holes (such as Joomla! and oscommerce), then they shouldn't provide it as a software option (Oscommerce is provided and supported by them on the hosting plans). Simple.
FYI I've moved to Globat, which so far is a faster server, but the control panel is not as good, and they have removed access to a few .htaccess commands, one of which I particurly needed.

[just462]

Now that ix knows that the truth of the situation is coming out, here is the response I got to a recent ticket:

"We are truly sorry for any delays in getting back with you and also for the issues you have experienced with our services. We are currently aware of these issues and are currently working on a permanent resolution. We kindly ask that you bare with us as we make internal changes to prevent these issues from ever returning. We thank you for providing us with this link. If you should have any further questions, please update this ticket with those and we will answer them as quickly as possible."

After all of this we're supposed to just bare with them, just be patient. No acknowledgment of the considerable damage that has already been done. Simply Unbelievable!

[AZ SnakePit]

And, hey, another of my accounts - again, with a strong password - was accessed through FTP, from the same Dutch IP address that uploaded content to my first one. It looks like there has been a widespread, possibly wholesale, breach of security at IX Web Hosting. As mentioned before, I would strongly recommend requesting the FTP logs from them for your accounts and checking the IP addresses, to see if your account has been compromised in that way, as well as any of the standard hackage.

[sclemance]

At this point in the thread, I'd just like to say a thing or two about security. A lot of blame is being placed at the feet of IX Webhosting, and although this is understandable, there is a grim reality we must each accept. Ultimately, the buck stops somewhere, and a website admin can throw blame at whomever they wish, but it is the responsibility of the website admin configuring Joomla! to ensure that their site is secure. Web host selection is part of that. Understanding web security is part of that. If you think a halfway job is well enough, then you might as well not run a Joomla! site in the first place. Before you cry out "flame-bait", understand that Joomla! themselves state this very clearly in the Joomla Administrators Security Checklist.

Merely the fact that IX has register_globals set to on globally is evidence that they are probably a poor choice for someone wanting a secure shared hosting service. This is considered a huge flaw by any serious developer, and has been a deprecated setting for a very long time now, (and subsequently removed from PHP altogether as of version 6), so why they are forcing it on is beyond me.

Some of you have mentioned that IX has told you setting a directory's permissions to 777 is a huge risk. Well, here's a shocker - it is. Only set a directory to 777 if you want a hacker to have write-access to the directory as well. Joomla! doesn't suggest 755 permissions on all folders just to be cute. Even if you've disabled scripting through .htaccess, it is still going to allow saving and overwriting within that directory. Give your modules temporary access when need be. I know, it's a pain, but if you care about security, you will keep your access to folders locked down. As well, IX will allow you to use the ftp feature of Joomla! for everyday modification of content or any updates to the configuration of the site.

Now for a couple quick questions - how many of you have had sites hacked where your permissions were all locked down? And a second part to that question - if any of you had sites hacked where you also had exposed directories, (777 or 757 permissions on a directory), exactly what protection, (through .htaccess or otherwise), were you using on those directories? Finally, how many of you are certain that you have register_globals off? Seeing as responses from IX have been somewhat convoluted, I'd like to try and discover exactly what might be happening in the majority of these cases. It's obvious a lot of IX accounts are being hacked/targeted. If IX won't tell us in clear terms why this is happening, perhaps we can narrow it down a little.

Here are some quick tips for IX Webhosting customers:
First off: .htaccess. Many accounts on IX, especially older ones, do not have access to php.ini for modifying PHP settings. You are able to use php_flags within .htaccess to allow you to change some of these settings. By default, for heaven knows what reason, IX has register_globals on in their global php.ini. This is dangerous on several levels, especially because IX provides shared hosting and is probably susceptible to session poisoning. The best we can do is to turn it off locally. In addition, it's a good idea to turn off error reporting as well, to prevent cross-site scripting hacks. As per the security suggestions of Joomla!, you can also disable allow_url_fopen in your .htaccess as well. Just add this to the end of your .htaccess file:

Code: Select all

php_flag register_globals off
php_flag display_errors off
php_flag html_errors off
php_flag log_errors on
php_flag allow_url_fopen off

Important Note: If you do turn off the PHP error reporting, the "Parse error:" message will not appear if, heaven forbid, your site is hacked again. More than likely you will just end up with a blank white page. If you do get hacked, and really need to see the error messages, simply reverse the settings to re-enable the error reporting in your .htaccess file.

If you want to have a look at your current global and local PHP settings, simply copy this code and make a little file called phpinfo.php, (or whatever you want to call it), and upload it into your web's root, then browse to it:

Code: Select all

<HTML>
<BODY>
<?php phpinfo();?>
</BODY>
</HTML>

Don't forget to delete the file from your website when you're done. This will list all your PHP settings. Pay close attention to register_globals and other such security settings.

Finally, if you absolutely must have write access opened up on a directory, at the very least add a local .htaccess file which will prevent script execution from that directory, (see this post: http://forum.joomla.org/viewtopic.php?f ... 2#p1285547). Here is an example which you can modify to suit:

Code: Select all

# Don't list contents, that would be bad :D
IndexIgnore *
Options All -Indexes
# Secure directory by disabling script execution
AddHandler cgi-script .php .php2 .php3 .php4 .php5 .php6 .php7 .php8 .pl .py .jsp .asp .htm .html .shtml .sh .cgi
Options -ExecCGI
# Don't show this file, that would be bad as well!
<Files .htaccess>
order allow,deny
deny from all
</Files>
#Deny access to a specific file in the directory that has been set to 777, except the webuser (and ftp of course)
<Files configuration.php>
order allow,deny
deny from all
</Files>

Let me know if you have trouble with any of this. Note that these tips are helpful for other kinds of CMS software as well.

Cheers, and good luck.

[depaulus]

@ sclemance

Thank you vey much for the useful info,
However, I have tried every trick in the book, I even had IX put a php.ini into my root folder.... All of this means nothing if you are running a buisness account with 0 (ZERO) scripts, 100% html, and still all your sites get injected.
It is not acceptable that someone on a server has a bad (shell) script, and someone is using that to inject every file on the server .. every 644 is changed to .httpd.

Any ideas how to protect a 100% html account with zero 777 folders or scripts?

[sclemance]

All of this means nothing if you are running a buisness account with 0 (ZERO) scripts, 100% html, and still all your sites get injected.

Well, yes. Absolutely - and I agree that it really does seem like the security flaw is in the back end with this particular problem. What frustrates me the most is that IX not only hasn't informed their clients regarding the issue, they also haven't bothered informing half the techs employed there. If this is really something they are taking seriously, as has been suggested within this thread earlier, then why don't their techs know what is going on. Just spoke to one a few hours ago who claimed he had no idea there was a problem, yet over three weeks ago I talked to one who claimed they were aware there was an issue on their end, and were trying to resolve it. On top of this, IX insists on practices which make them appear immature as a technology driven business, such as forcing register_globals on, (which is intrinsically unsafe and unnecessary for web hotels, even if you can turn it back off locally - this has been discussed time and time again).

But this all echoes back to what I was mentioning before - if you don't have the facility to run your own webserver, selecting the right webhost is as much a part of security as configuring a server. I've given IX an opportunity to address this issue, and since I have been unable to get an consistent response from them, I will be moving my sites and clients elsewhere. I really do hope IX gets this sorted, because this time last year, they really did seem like a fantastic company to host with.

Cheers!

[AZ SnakePit]

Great stuff, sclemance - thanks a lot for that. I had already locked down permissions on my own folders to 755. As a sidenote, I think the Joomla installation would be improved if it included changing permissions to 755 post-installation, or at least mentioned the implications of leaving them at 777.

I have implemented your .htaccess suggestions, so that should be helpful. However, I experienced some issues trying to add some of the other security suggestions in the guide, in particular:

Code: Select all

open_basedir = /hsphere/local/home/******/******.*** 
disable_functions = show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open

[Some identifying information removed]

Trying to add either of the lines above to the .htaccess file for my site causes an immediate 500 Internal Server Error. I can see why the former may require some tweaking, but surely not the latter. Has anyone else had any success with this at IX? I particularly want to get the open_basedir restriction working, as IX settings appear to let a script uploaded to account X, be executed by a reference from account Y.

As depaulus noted, the issues at IX appear to extend beyond simple PHP settings. I have had two separate accounts, with strong passwords [mixed upper-case, lower-case, numbers and symbols] accessed through FTP and content uploaded that way. This is why I am actively looking for an alternative host. However, budget is unfortunately a consideration - it appears that getting register_globals turned off at the server level will require me to pay twice as much for hosting.

[sclemance]

Trying to add either of the lines above to the .htaccess file for my site causes an immediate 500 Internal Server Error.

If you get a 500 error, then there is a setting not supported by the server you are on, (IX has a batch of 'old' servers and a batch of 'new' ones, both configured with different versions of PHP and cPanel). I'll have a further look at it, but you may just need to exclude that portion from your .htaccess file. Again, it does appear that this may be a moot point in any case, as this may have no bearing on the problem at hand - but it certainly will help you add further security to your site.

Cheers

[sclemance]

Again, it does appear that this may be a moot point in any case, as this may have no bearing on the problem at hand -

Hrm... just reread what I wrote. It actually may -be- the point, as it clearly may have a bearing on the problem at hand. What I should have said was, this may not fix the issues, but it's a good thing to look into anyway.