Joomla .htaccess hacked to xxx.ru

[PhilD]

The exploit (at least the ones within this thread) are one or more files uploaded to the site somewhere by a LFI or local file include. This usually means an insecure extension on one or more sites. It can also mean that they got the super admin user and password for one or more sites (see below) and simply used an extension to upload the files. Usually within the tmp directory and sometimes within the template directory. The media directory is another place. By not inspecting and replacing the contents of the media and templates directories, you probably are not getting rid of the hack.
The files masquerade as harmless looking v bulletin files, but that is to just hide the hack. Within these files is a preg_replace statement with the e switch. In that statement is a packed and coded binary file. this file gives access to your entire domain.

It has been reported elsewhere that the hackers are brute forcing (or using dictionary attack) admin usernames and passwords.

This hack can affect all php software as all of it operates much the same basic way. The hack has also been found on html only sites, and will cross contaminate other sites within the same account. this includes vps servers as they are just basically shared servers. You have to include include dedicated servers if you have more than one site under a main account.

If you fix the htaccess file, then the hack simply puts the redirect code back in the new htaccess file. The hack also hides some htaccess files outside of normal areas with the redirects in them. Probably to use as a base for writing the file again after you fix it.
The hack also attempts to place a server root kit on the hacked site as logs generally show attempts to do this at around the same time as the htaccess hacking occurred.
This will happen almost as fast as you can fix the htaccess file.



On 204.197.244.61
It is interesting as I have seen this place before; Privatesystems Networks Tx

[Webdongle]

It can also mean that they got the super admin user and password for one or more sites (see below) and simply used an extension to upload the files

Would this include Trojans on computers that have ftp connection to the site ? If it does then that can be a big problem because even if the software is upto date if someone is maintaining a site but the site Owner's computer is infected then it can create a circle of reinfection.

• The site is wiped and new files replaced
• The infected computer reinfects the site and/or passes the new ftp details on via the Trojan
• The infected computer is cleaned
• The reinfected site then infects the computer again.

And round and round it goes.

Also worth noting that when removing malicious files from a PC with Windows OS ... make sure 'System Restore' is off otherwise the malicious files will hide in there and reproduce.

Other things to check on PC's with Windows OS that when the antivirus or filrewall have popped up that the exploit was not inadvertently allowed. Because if it was it will still be allowed when it reinfects ... but on the next occasion it will not trigger the antivirus or firewall.

Most people are aware of the programs on the market for connecting to your computer remotely. But there are programs out there that do it without your knowledge or permission. There are many ways these vile programs are introduced to a PC is by accepting a file on chat ... opening an email attachment and many others. Once on a computer they email the IP every time the computer is booted up. The recipient of the email places the ip into a program they have. And then they access your computer from their keyboard like you can from yours.

They can then install other software but unlike when you install software there is no notification. They can install keyloggers and see what you have typed when they have been off line. If one of those Trojans is on a computer that has ftp access to the site then it will know all the new passwords.

[Bernard T]

Would this include Trojans on computers that have ftp connection to the site ? If it does then that can be a big problem because even if the software is upto date if someone is maintaining a site but the site Owner's computer is infected then it can create a circle of reinfection.

• The site is wiped and new files replaced
• The infected computer reinfects the site and/or passes the new ftp details on via the Trojan
• The infected computer is cleaned
• The reinfected site then infects the computer again.

And round and round it goes.

Sure it includes Trojans, that's one of their most common usage - gaining access to your personal computer and get whatever they will, including FTP passwords. One of the common issues that enabled web-defacements and other infections of websites in last 2 years that I've been seeing is theft of FTP credentials via some Trojan malware. And it's so kindly enabled by all of users that use "remember password" in FTP software, most probably controversal Filezilla, which saves them in plain-text file. And the author of Filezilla is well aware of it, but decides to do nothing about it ... So - generally - don't save passwords in FTP programs, especially not Filezilla!

And if you site got compromised in some kind of way - go change all credentials first, to prevent any further attempts if credentials were stolen:

• hostpanel pass
• ftp pass
• db pass
• all superadmins passes

[Webdongle]

...
And if you site got compromised in some kind of way - go change all credentials first, to prevent any further attempts if credentials were stolen:
...

Sorry to disagree but changing passwords should not be first.

• The first thing to do is delete everything on the server.
• The second check all computers that have ftp/admin access
• Third change passwords

Because if you change passwords first then the new passwords are stolen. And you get reinfected. The malware/exploit must be completely irradiated before the passwords are changed.

[brinw05]

Hi All,

Thanks to all your brilliant analyses overhere, i found the messy rules in my .htaccess that redirects to the xxxxx.ru site. It's on top of it and indeed far at the right side so you can't see it.

The rights are 444. Now, what is the best thing to do? As i understand there must be a component/module/plugin that gave access, right? Anyone a suggestion? Someone here was writing about NoNumber framework? Is that proven?

Now, as this finding supports the view of this topic, what is the best thing to do? I know i have one site that is not fully up to date (that is, it's fully up to date with Joomla but not with the components/modules/plugins). If there is 1 site in my vps in this state, can this affect all the other sites? Or does every infected site must have the one 'bad' component/module/plugin to be infected?

This is what i use (specificly on the 'outdated' site):
Components: Joomfish (older version), Akeeba Remote (older version), ccNewsletter (up to date), CQI Custom Quick Items (up to date) and UpdateManager (no version visible).
Modules: PWeb AJAX Popup Contact form (up to date, commercial), Google Analytics Tracking Module (use it for some time now, outdated?), YOOlogin (perhaps outdated)
Plugins: simple Image Gallery Plugin and Simple Image Gallery (replaced very recently, perhaps the old version was bad?), Modules Anywhere, NoNumber! framework, jSecure Authentication, YOOeffects.

Recently i activated Mootools upgrade because it was necessary for a module (pweb).

Now, what's the best step for us to do right now? Hopefully my information will ring bells.

[Webdongle]

...
Now, what's the best step for us to do right now? ...

• Wipe all the folders/files on the site where you found the redirect
• Scan all computers with ftp/administrator access (that includes your customers computers and will probably be the hardest to verify)
• And every thing else on http://forum.joomla.org/viewtopic.php?f ... 4#p2371858

Then cross your fingers because if that doesn't do it for whatever reason(possible change of passwords before all the computers were cleaned) then you will need to wipe all 50 of the sites on your server.

[brinw05]

Hi Webdongle,

Thanks for your quick reply. The strange thing is that in my case 'only' 19 of the 50 sites are infected. It so happened that we had to swap Simple Image Gallery to a newer version about a month ago because there were problems with a new contact component (Pweb). It also happenes that on all the infected sites so far Simple Image Gallery is active. I know that in website land we speak in facts in stead of feeling but my feeling is that it could have something to do with.... SimpleImageGallery?

Anyone here who also uses SIG?

[brinw05]

Update!

I removed the malicious .htaccess file from one of my infected sites and after about 5 minutes it returns. This confirms what is said here before. The .htaccess file has a timestamp of today (easy to find :-)).

Now i have to find the code that's reproducing this .htaccess file. If anybody knows, please give me some hints so i can look for it (and hopefully find it).

Oh by the way, i'm planning to make backups per site, restore them locally, delete the malicious code or combine it with a fresh Joomla installation, connect the fresh installation with the 'old' database, copy the files from /images to the new /images, backup it again and restore it on a new VPS. If something is in the VPS it can't infect the cleaned site anymore. Should this do the trick? Please advise.

[mandville]

which simpleimagegallery? name the developeror send an email to the vel team velATjoomla.org

[brinw05]

Hi Mandville,
Simple Image Gallery. Developer: JoomlaWorks.

[Webdongle]

... The strange thing is that in my case 'only' 19 of the 50 sites are infected. ...

Well that's 19 sites you need to delete and rebuild and hope the infection has not spread.

[Bernard T]

Sorry to disagree but changing passwords should not be first.

• The first thing to do is delete everything on the server.

and why do that as the first thing??? ...removing all pieces of "evidence" what files were changed?

Nothing evasive should be done before evidence is gathered ... while you still don't know the way your website was infiltrated, changing passwords is a good thing to do for start. Maybe it's not your computer that's infected (do your scan in meanwhile), it can be your co-worker's/client's if they too have credentials etc... Changing passwords cannot harm, but definitely can help in many cases...

...The .htaccess file has a timestamp of today (easy to find :-)).
Now i have to find the code that's reproducing this .htaccess file. If anybody knows, please give me some hints so i can look for it (and hopefully find it).

go to Apache access.log and search for the URL's accessed in the time of the .htaccess modification timestamp. You might find some accesses to ./tmp/some_file.php, or in other folders like reported by PhilD (./templates, ./media) ... I've made a scanning script for those files, it has to be tested and I'll publish it soon... When you find the file that's infected, note his name and his creation timestamp and delete it. Then go to access.log and search for this timestamp/name to find how it entered your system...

[Webdongle]

and why do that as the first thing??? ...removing all pieces of "evidence" what files were changed?

Nothing evasive should be done before evidence is gathered ...

Not all users have the ability to do that. Many users can only install Joomla using a Host's one click install. They would have little or no idea how to look let alone what to look for. But for those who know what to look for then a good 'nose' around would be a good idea.
And it does appear that it is the less experienced user that is being hacked rather than someone who would know what to look for. Also, many of the hacked sites(where they have run the FPA) show old software, 777 file permissions extensions that have been listed in the VEL

...
while you still don't know the way your website was infiltrated, changing passwords is a good thing to do for start. Maybe it's not your computer that's infected (do your scan in meanwhile), it can be your co-worker's/client's if they too have credentials etc... Changing passwords cannot harm, but definitely can help in many cases...

Again ... And it does appear that it is the less experienced user that is being hacked rather than someone who would know what to look for. So, although changing the password may not do any harm, doing it before eradicating the exploit instead of after is the wrong order for many inexperienced user.

Like you said

Sure it includes Trojans, that's one of their most common usage - gaining access to your personal computer and get whatever they will, including FTP passwords. One of the common issues that enabled web-defacements and other infections of websites in last 2 years that I've been seeing is theft of FTP credentials via some Trojan malware.

OK, yes if you are the webmaster then the Trojan may be on a customers PC rather than your own. In which case changing the passwords for your customers access would be a good idea.

But again, And it does appear that it is the less experienced user that is being hacked rather than someone who would know what to look for. That's the reasoning behind my putting changing passwords after eradicating the exploit and not before. Looks like we will have to agree to differ on this one.

[brinw05]

Hi There,

Last night i cleaned 3 infected sites. This morning 2 out of 3 are infected again (as expected). Only 1 is still clean. I check the clean one every hour. I checked it again about 10 minutes ago and there is 1 .htaccess file back in the root. NOT in the maps. It's empty, rights 644. In my general settings the use of .htaccess is disabled.

Question: Is there a process in Joomla that creates an .htaccess file for one of another reason?

[mandville]

cpanel automatically makes a blank hta if there is none present, joomla does not natively do that

[brinw05]

Ok. Thanks. That explains it. I think i've got it.

My provider advised me to change the rights of configuration.php in 600 in stead of 644.

As i wrote before, the malicious code puts .htaccess files in the root and all folders within the root. In the tmp map there are a lot of files of backups, updates and installs but also jos_core.php and another joomla look-a-like file (something like jos_jkes.php or jos_uuiy.php). Esspecially the last file mentioned is the problem, i think. I looked into it and there is binary code in it. As i can remember PhilD mentioned something about this lots of messages ago.

My solution to clean the website is first remove every file in tmp. After that, i immediatly delete all the .htaccess files (in root and all maps in the root).

As far as i can see now this must be the trick. Just ask Google to crawl your site again.

[PhilD]

Jos_core.php, jos_eq4h.php, jos_lz5j.php were the files I found in one sites tmp directory. The jos_core file was blank and the other two each contained the hack script. The names may vary so it is best not to depend solely on looking for names.

In the htaccess file(s) you may have missed the stuff hidden at the bottom and to the right. any error (404, 403 etc.) onsite will send user to a .ru site. The htaccess is altered both above and below what the file normally contains.

You also may have missed the htaccess file that was created outside of the public_html directory as a sort of backup of the hacked file that is within the public_html directory.

This hack appears to be from a local file include (LFI) which means access could have been gained by an insecure extension, out of date Joomla install, brute forcing the Joomla admin user/password. In addition to making sure everything is cleaned properly and up to date, also check for any extensions installed that you did not yourself install that may assist in loading the files upon the site.

I also have suspicion ( but no concrete proof) that the initial access to a site preparing for the addition of the hack files may have been back in November of last year. This is thanks to a site that runs the one line (the ctime) script posted in security checklist 7 from cron on a regular basis.

[Slackervaara]

I use Keepass Password Safe for my passwords. When I log in on my site I use Ctrl + Alt + A, which takes the username and password from Keepass and I never have to type it and reveal the password for hackers (if keyloggers are on my PC). Another way is to type a lot of gibberish and place the password inside it. Then one copies the password and paste it in the login area.

[PhilD]

They are probably not attacking your computer for the user/password, but rather trying user names and passwords with a script. You will be surprised at how many people use admin and 123abc or other very simple password for a username/password combo.

KeePass is a very good tool to manage sensitive information and keep it safe.

[Bernard T]

As promised, I have written a small script called JAMMS that scans files for fingerprints of some malware, and it should detect infected files from this topic. It's still under heavy development, so I'd appreciate any feedback from anyone that's willing to test ...

The script only reports if there was some malware-fingerprint found, it doesn't do any cleanup, yet. For cleanup go with many times repeated steps in this topic...

JAMMS direct download

[Webdongle]

...
Last night i cleaned 3 infected sites. This morning 2 out of 3 are infected again (as expected). Only 1 is still clean. I check the clean one every hour. I checked it again about 10 minutes ago and there is 1 .htaccess file back in the root. ...

So you cleaned 3 infected sites ...

• Did you delete all the folders/files of those sites ?
• Could they have got reinfected by the other infected sites on the server ? (the ones you never cleaned).

[brinw05]

Hi Webdongle,

Yesterday i cleaned 3 out of 19 infected sites. I made up 3 different scenarios i used for the 3 sites. 1 of the scenarios was based on no infection by the vps itself, meaning the virus must be encapsulated within the account (not on the server totally). That in mind, i cleaned the tmp map and the cache map totally (not even look at the other files,... everything out!).

This morning i had contact with my hostingprovider, he looked into the server and acknowledged that there were no other processes active. No strange files also. He also produced a history file of 15 and 30 days ago and the strange thing was that they were simular. He produced both reports again and they were still exactly the same. The infection must have started earlier. My conclusion is still that it's within the Joomla installation and not at a higher level.

Looking at the infected sites i'm pretty convinced that:
- populair and active sites were hacked first (i have 50 sites and the 19 sites infected are very active);
- It must have started at the beginning of march (2012-03-01);
- they did a second 'thing' to make it active (2012-03-22);
- Joomla released 1.5.26 on 2012-03-28;
- it took the searchengines about 5 to 8 days to pick up the infected sites (2012-04-01);
- i updated all my sites (50) on wednesday 2012-04-06. On saterday we saw that the infections didn't extend any further (19 sites). At this moment it's still 19 sites and i cleaned them all tonight;
- I asked Google to do a googlebot request (i don't know how they call it exactly but i want them to crawl the sites again) and i expect within 4 to 6 days that the problem in Google will be cleared.

I'm pretty convinced that it must have been something that was fixed in version 1.5.26.

I use Joomla for 4 years now. I really think that when a new release is there, they should tell us more specificly what to do (regular, update, urgent and critical). This one was, in my opinion, really critical. My experience is that, in case of an update, it is better to wait a few days and install the updates. Most of the updates are updated again because of one or more errors. I don't want to update my 50 sites every 3 days. Lots of work.

Anyway,... within 4 to 6 days i will inform you about the cleaning results. As far as i can see right now the infected sites are clean. Tomorrow i will check them all again. Tomorrow i will move all not-infected sites from my current VPS (php 5.2) to a new VPS (php 5.3). I will keep the cleaned sites on my current VPS. After 2 weeks, when they are still clean, they will be moved to my new VPS also. I take this measure to be absolutely sure that the hack was not in my old VPS anyway and that i won't infect my new VPS.

[Webdongle]

I'm pretty convinced that it must have been something that was fixed in version 1.5.26.

Security

High Priority - Core - Password Change Vulnerability. More information »
Low Priority - Core - Information Disclosure. More information »

http://www.joomla.org/announcements/rel ... eased.html

I use Joomla for 4 years now. I really think that when a new release is there, they should tell us more specificly what to do (regular, update, urgent and critical)

An update is an update and surely any update should be treated as 'urgent' ?

[MoonfireArt]

I am curious about something. Several people on this thread have mentioned the NoNumber Framework as being on the vulnerable extensions list. As I run NoNumber extensions extensively on the network of websites I manage, I wanted to know more about this.

I checked the VEL and it was indeed on there. I then went to the noNumber forums to inquire about this. The NoNumber developers claim that they have fixed the problem and that is why it is now listed in white on the VEL.

What I would like to know is: is that statement by the NoNumber developers true, or are the extensions still vulnerable? I have updated to their newest versions and run Joomla 2.5.4 (business websites, so concerned about security). So far, I have not been affected by this [censored] so and so running these .htaccess hacks, and would really like to keep it that way.

edited: I suppose I got so wrapped up in this interesting thread that I failed to notice That this is the 1.5 forum. Nonetheless, i think my question is still valid.

[mandville]

I checked the VEL and it was indeed on there. I then went to the noNumber forums to inquire about this. The NoNumber developers claim that they have fixed the problem and that is why it is now listed in white on the VEL.

actually its listed in white as the report fell outside the normal process. they had fixed it before it was reported.
there are currently no reported exploits reported to the vel team on nonumber extensions

[MoonfireArt]

Thank you for the quick reply Mandville! This is the type of quick and reliable support I have come to expect of the Joomla Community.

[Bernard T]

I asked Google to do a googlebot request (i don't know how they call it exactly but i want them to crawl the sites again) and i expect within 4 to 6 days that the problem in Google will be cleared.

it's important to note that this infection has nothing to do with Google itself, it's caused by your local .htaccess redirect, so it affects users only coming from search engines to your sites (they actually land on your site) and only thereafter redirected by your .htaccess/Apache to some random .RU site

I checked the VEL and it was indeed on there. I then went to the noNumber forums to inquire about this. The NoNumber developers claim that they have fixed the problem and that is why it is now listed in white on the VEL.

actually its listed in white as the report fell outside the normal process. they had fixed it before it was reported.
there are currently no reported exploits reported to the vel team on nonumber extensions

... but it's important that NoNumber Framework extension (-set) is listed there in VEL, as the previus versions are know to have not one but several vulnerabilities, both LFI and RFI. Unfortunately, NoNumber is listed in most of the exploits-data sites so it's vulerability is well documented and now used as a good target for malware-seeding attacks. The additional problem with NoNumber is that the components which are using it are easy to spot via simple googlesweep or pintests on J! installations...

[brinw05]

Hi Webdongle,

You have to consider that i have 50 sites. I remember the update from 1.5.9 to 1.5.10. Within 1 day i updated all my sites... after 3 days there was another update (1.5.11) and i updated again, and after 2 days another (1.5.11) and after 3 days another (1.5.12). Within 1 week i updated 50 sites 4 times! It was the big update of TinyMCE.

But i think this is not the right place for this discussion. I cleaned 19 sites yesterday and this morning i checked them. They are still clean. Now i just have to wait for the searchengines to crawl the sites again.

[Webdongle]

I realise updating can be a pain. I only have a few sites to update mine and a few friends(yes I do have friends ). I do it for free and can imagine how difficult it can be to update 50. And deleting everything and replacing with fresh must be a nightmare.

Nevertheless, by what most Post in here appear to indicate ... deleting everything is the only way to be sure. And even then there is no guarantee that it will not reinfect.

check to see if the impacted sites
have a file manager along the lines of extplorer? This seems to be an
possible common thread in some other reports

May be relevant to some in this thread ?

[brinw05]

Well Webdongle, since 2 months i use JoomlaUpdate and JoomlaUpdatePro... that's really perfect. I installed a 'management' site for myself and within that site i manage all my other sites. But for this kind of events i have to rely on my hands :-(.

Is there anyone who used my solution already? Any results?