The Joomla! Forum ™

hi
im comming to joomla after i didnt find any solution or similar case to my problem.
i have joomla 2.5
i have noscript addon of firefox installed to see what script is running in my website.

so everytime when i make changes or install something or edit file or publish new file or.. i get new russian website script attached to my joomla, i see it in noscript addon.
its like it generate the sites.
twittto.ru
twitt-to.ru
link-twi.ru
pang-rui.ru
...........and so on .
so when i close firefox and clean history this fake script disapear , so when i edit some files again in joomla it comes other russian script again !!
im tired from this scripts they get me nervous , i looked in joomla files but i didnt find anything , and i dont think its virus because this script comes only when i change/edit/ add/...files in joomla.
any help please?
i have other site with joomla 1.5 but this is working very good even if i edit or do something nothing happen , only in joomla 2.5.
hope joomla developpers know what is it , thx

Probably you have installed a free template from somewhere. Try to use the default Beez_20 template which comes with the Joomla installation. If the problem doesn't occur, then check your newly installed template files!!! Look for the code with 'eval(a_very_long_and_unreadable_string)', which is generating all that crap...

It seems like you have been hacked by a redirect script, possibly by using a free Template that was infected. If you have then viewtopic.php?f=621&t=582854

_________________
http://weblinksonline.co.uk/joomla-faq.html

hi guys and thx for your reply .
im using Beez_20 template , i didnt install any other template , i start with the original template because i liked it. so if the problem is there maybe from this template !!
i have search with "eval" and nothing found about long string and not readable.
what do i must check pls now
thx

hi

you do not have much info on setup.

anyway if your template is clean.

check your htaccess file if are using such and have access to it.

there will be lines of crap in it if a problem, sometimes a lot a blank spaces before see them so check carefully and fully.

also if the problem review you access settings.

Then the hack was from somewhere else. Please run the Forum Post Assistant
Like it said in the post I linked to. and post the results here.

What is your url ?

_________________
http://weblinksonline.co.uk/joomla-faq.html

Hey guys, don't want to hijack the thread, but I've been working on the same problem. In my case the WSO Web shell had been placed in a file in the tmp directory. It was different to the previous attacks I've seen (eval(base64) etc.. in that the eval code was obfuscated in a regex with execute modifier.

Searching for:

preg_replace("/.*/e"

pulled up the offending file.

Hope that helps the OP.

After a recent htaccess hack recovery i found that hack content had been stored in the google cache. This meant that even after cleaning the site it was reinfected by the google search function.
I found the only solution was to isolate the site from any search engine until tier caches were refreshed (2-3 days)
and no I am not totally sure the above is correct, however isolating the search engines did the job.
Possibly it is something worth considering.
the google bot was. triggering a script hidden in the sites files generating the htaccess files (it appears)

Then your site is still infected ?

_________________
http://weblinksonline.co.uk/joomla-faq.html

it was part of determining the extent of the infection that led to the realisation that the search engine cache was being usd by the hacker to prevent cleaning of the site.
Removing the hacked htaccess files was a waste of time as they simply got regenerated after the google bot had visited.
so with this event
1] it confirmed that all folders and files needed to be replaced [ as finding a single or multiple corrupted file(s) would be very difficult]
2] That simply removing the htaccess files would not be sufficient
3] that the hijacking method was very sophisticated to use the google bots cache
I guess the idea of it all was to promote a sense of security in the site owner after an initial file cleaning and until you allowed time for the Bot to refresh it's cache the problem will keep reinfesting your root with htaccess files
I noticed the association by noticing the difference when i went to the siet using the address bar URL [ copy and paste -result site clean] and a google search results link [result site infected.] so the conclusion was that the Google search engine was somehow infecting this site with ht access files. [ as the htaccess fils woudl re-appear in the root after I used the link provided by google]
My investigation was not conclusive but enough evidence appeared to indicate google search bot involvement somehow.
Solution was ultimately to isolate the site until the google bot had refreshed it's cache. and then after confirming the extent of the hackimg replace all files and isolate again [ 2-3 days]

Also what compounded the problem was that I had 6 sites [6 domains using a shared hosing account] and the htaccess files kept re-appearing in the root of each domain and also most importantly the root of the "global" account. So finding the infection source site was incredibly difficult until I isolated all the sites from the google bot. [ as the bot was providing what I would call an "infinite variable"]

if google didnt see any new content , it would not refresh its pages and therefore leave the bad link cache version on line. have you told webmaster tools to revisit it?

_________________
HU2HY- Poor questions = Poor answer
Un requested Help PM's will be added to the foe list and possibly just deleted
{Community.Connect Administrator }{ Showcase & Security Moderator}

What I did was put up a html landing page which google used to refresh with as part of "site under reconstruction" policy when a site has to be more than just taken offline.

Basically . I don't know the detail except the only tools i have are replacement of site files and time.
The incident certainly indicated a strong BOT - server correlationship as the htaccess files would only appear in the server after clicking the link on the cached google link.
And I believe certainly worth investigating... further or at least noting...which is why I posted here.

This is a little hard for me to explain in a way that makes sense and is not meant to necessarily be an absolute, but rather a somewhat general idea of what is happening.

What mandville was saying was that if/when Google revisited the site and no content had been changed, or nothing changed on certain pages, then it is unlikely that Google would have updated any of the cached stuff related to the site or at least related to certain pages. The Google bot only looks for things changed since the last crawl. If one of those unchanged pages contained a link to the place where the hack was. In order to get around this so to speak, and force Google to completely crawl the site again, you need to use the Google Webmaster Tools and request through there that the Google bot crawl the site again and refresh it's cache.

The issue I an seeing on your site from reading the posts is that the hack files are likely still onsite. Though you may think so, the hack is really not particularly sophisticated, or well hidden, it is rather clever in design. The basic way the htaccess hack works is script files are uploaded through an insecurity in your site and placed inside an existing directory. A copy of your main htaccess file is made and some hidden redirects are added to the top and bottom of the file. A copy (actually 2 copies in different places) is stored for use later if you attempt to fix the changed htaccess file and you have not removed the scripts that generated the hack in the first place. ANY site access is likely to run the code contained locally onsite and cause the main htaccess file to be compared to a stored (on your domain) version. If the two differ as they would if you cleaned the main htaccess file for the site, then the main htaccess file is overwritten with the hacked version. This comparison is done for every access to the hacked site no matter who or what (visitor, you, bot) did the access The entry point for the hack that I have seen is an insecure extension that allows the hacker to upload and place the files on your site. The sites I have fixed, this hack was done late last year, and the hackers waited until just recently to activate and access the hack. The hack also attempts to place a root kit on the site. Sometimes this is successful and sometimes it is not. The root kit would allow the hacker easy access to your entire domain, no passwords required, including any areas outside of the public_html area.

While Google could have cache to some page on your site that contains the trigger, and upon someone using that cached page trigger the hack, Google does not have the files for the hack and therefore can not automatically put those files back on your site nor can a cached copy of a page download the files from somewhere else to your site, and then run them. Google also does not cache system (.htaccess) files. The security compromise if it is still on the site will allow the hacker to place the files back on your site at will. Generally hackers use automated bots designed specifically to probe for a weakness and if one is found, deposit a payload.

As you mentioned in one of your posts and If you are still having trouble then, you need to follow what I am posting below.
You will have to first kill the script files that generate the hacked htaccess file. Generally this is best done when you delete All files/directories contained within the public_html area as outlined below. You then need to find and delete any hidden copies of the hacked htaccess file. One copy is normally located somewhere outside of the public_html area. On some hosts you apparently (though you should on a good host) may not have access to the area it resides in and will need to ask tech support to remove any copies of the htaccess file that reside outside of the public_html area. The other copy should have been deleted when you deleted all the files within the public_html area of the site and the active htaccess file would also have been deleted at that time. Then you can replace the removed files and directories with clean fresh copies. Any files such as photos, documents etc. that may be reused on the clean site should be inspected individually. Don't just say "well this directory contains just photos, so I will save some time/effort and upload the directory" as the directory may contain scripts to hack your site again.

In order for everyone to be able to fix their site in a way that is effective, and reasonably easy to both follow and do, the following checklist and associated documentation was created.

_________________
PhilD -- Unrequested PM's and/or emails may not get a response.
Security Moderator

Thanks PhilD, your advice is most appreciated!
You have only confirmed what I have already instigated as policy.

We can only assume that we CAN NOT KNOW the extent of the hack nor the degree of sophistication involved. The hacker may even wish us to think that he is just a teenager hack out for some fun... and we can not know either way.
Given the complexity and numbers of files a site contains there is only one way to approach the issue once a site is known to suffer a hack problem and that is to simply replace the site with a fresh build and hope the files downloaded from Joomla are hack free.

Building a site to stable and then backing it up with a stable copy kept separate from any subsequent backups.

I guess what I am opinionating is that "hackers" are an unfortunate fact of NET life and it is best to be prepared for the need to replace with a fresh build at all times. [As this is the only way to maximise confidence that you are solving the immediate problem and not accidently perpetualising it.]
I would also suggest that the web master identifies clearly what he holds as high value or critical value to the sites function and future [ ie. member list and details, financials etc [and take steps to secure and immunise oneself from long term loss] and allow for a site down time period for rebuilding works. [re: terms and conditions]

I think you will find that in most countries there are legal requirements for sites that accept financial details. And that the regulations require additional specific software.

_________________
http://weblinksonline.co.uk/joomla-faq.html