htaccess hacked, re-directing traffic to xx.ru

[PhilD]

That's just kinda dumb. There are some sites that will draw a targeted attack, and even these in many cases these attacks can be minimized id not eliminated. Most peoples websites just don't warrant such an attack. For most sites Bots simply probe any site they run into with a shotgun approach using a kitchen sink of exploit code until it finds an exploit that sticks, your site responds in a favorable way, or the server responds in a favorable way at which time the bot will attempt to place a payload on the site using the found exploit.

Backups are no good if your site has been hacked as it is likely (statistically) the backup contains the hack. Using the backup to restore the site or to restore the site to a different server simply puts the hack back.
Backups are for prevention of data loss only.

So you just move to a new host after you get hacked? Sounds like you are letting your 'friend' mess around and your getting kicked off various hosting services for TOS violations.

[mandville]

Then, after my site is hacked, I just use the backup and transfer to a new hosting.

what is your url so that everyone knows to avoid you.
what your saying is that just because someone finds your site vulnerable, exploitable, hackers/spammers/phishers playground you should leave it that way and not do the moral thing of fixing it first?

[WebJIVE]

OK, we have had this issue in the past and still do on a daily basis. The injection point for us on a Joomla 1.5.26 site is, believe it or not, the /administrator/index.php?option=com_installer. We have done a couple of things to stop this.

The first is to install Configserver Exploit Scanner: http://www.configserver.com/cp/cxs.html
This will use Clamd to scan ANY uploaded file via PHP, FTP, etc. for fingerprints and know malware/hacks, then auto-delete or quarantine.

Next, protect your entry points into the server with this .htaccess mod:
(this has not been tested for Joomla 2.5 yet!!)

Code: Select all

## Disallow access to htaccess.txt and configuration.php-dist
RewriteRule ^(htaccess\.txt|configuration\.php-dist)$ - [F,L]

########## End - Advanced server protection rules exceptions ####

RewriteRule ^(images/stories/*\.(jpe[g,2]?|jpg|png|gif|bmp|css|js|swf|ico|htm[l]?))$ $1 [L]
RewriteCond %{REQUEST_FILENAME} -f
RewriteCond %{HTTP_REFERER} !^http://www\.xxx\.com [NC]
RewriteRule \.(jpe[g,2]?|jpg|png|gif|bmp|css|js|swf|ico|htm[l]?)$ - [F,L]

## Disallow visual fingerprinting of Joomla! sites (module position dump)

RewriteCond %{QUERY_STRING} (^|&)tmpl=component [NC]
RewriteRule ^(.*)$ $1 [L]
RewriteCond %{QUERY_STRING} (^|&)tp= [NC,OR]
RewriteCond %{QUERY_STRING} (^|&)template= [NC,OR]
RewriteCond %{QUERY_STRING} (^|&)tmpl= [NC]
RewriteRule ^(.*)$ - [F,L]

## Disallow PHP Easter Eggs (can be used in fingerprinting attacks to determine
## your PHP version). See http://www.0php.com/php_easter_egg.php and
## http://osvdb.org/12184 for more information
RewriteCond %{QUERY_STRING} =PHP[a-z0-9]{8}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{12} [NC]
RewriteRule ^(.*)$ - [F,L]

## Back-end protection
## This also blocks fingerprinting attacks browsing for XML and INI files
RewriteRule ^(administrator[/]?)$ administrator/index.php [L]
RewriteRule ^(administrator/index.htm[l]?)$ $1 [L]
RewriteRule ^(administrator/index.php)$ $1 [L]
RewriteRule ^(administrator/index[2,3].php)$ $1 [L]
RewriteRule ^(administrator/(components|modules|templates|images|plugins)/.*\.(jpe[g,2]?|jpg|png|gif|bmp|css|js|swf|htm[l]?))$ $1 [L]
RewriteRule ^administrator/(.*)$ - [F,L]

## Explicitly allow access only to XML-RPC's xmlrpc/index.php or plain xmlrpc/ directory
RewriteRule ^(xmlrpc/index\.php)$ $1 [L]
RewriteRule ^xmlrpc/(.*)$ - [F,L]

## Disallow front-end access for certain Joomla! system directories
RewriteRule ^(includes/js/.*)$ $1 [L]
RewriteRule ^(cache|includes|language|libraries|logs|tmp)/.*$ - [F,L]

## Allow limited access for certain Joomla! system directories with client-accessible content
RewriteRule ^((components|modules|plugins|templates)/.*\.(jp[g,2,eg]?|png|gif|bmp|css|js|swf|ico|htm[l]?))$ $1 [L]
RewriteRule ^((components|modules|plugins|templates)/.*index\.php(.*))$ $1 [L]
RewriteRule ^(templates/.*\.php)$ $1 [L]
RewriteRule ^(components|modules|plugins|templates)/.*$ - [F,L]

## Disallow access to htaccess.txt and configuration.php-dist
RewriteRule ^(htaccess\.txt|configuration\.php-dist)$ - [F,L]

## SQLi first line of defense
## May cause problems on legitimate requests

RewriteCond %{QUERY_STRING} concat.*\( [NC,OR]
RewriteCond %{QUERY_STRING} union.*select.*\( [NC,OR]
RewriteCond %{QUERY_STRING} union.*all.*select.* [NC]
RewriteRule ^(.*)$ - [F,L]

########## End - Advanced server protection

[mandville]

I assume you have informed jsst with full poc?

[WebJIVE]

I assume you have informed jsst with full poc?

@mandville, you talking to me, @webjive?

[PhilD]

Yes she is talking to you.

[WebJIVE]

@madville and @PhilD, what is JSST and POC? We have been using/developing on Joomla since day one of Joomla's roll-out but, those terms are a bit foreign to me.

[PhilD]

POC -->> proof of concept, or the reproducable method by which the exploit can be tested.

JSST -->> Joomla Security Strike Team -->> as part of their duties, the team members are tasked with investigating and respond to reported core vulnerabilities.

Report here:
http://developer.joomla.org/security.html

The Joomla! Project takes security vulnerabilities very seriously. As a member of oCert we follow some specific procedures when dealing with security issues.

If you find a possible vulnerability, please report it to the Joomla Security Strike Team first. You can contact the team via email at [email protected]. Also let us know via email if you find a reported vulnerability (reported elsewhere). Please include where you saw the report.

You can provide patches for any issues that you find when emailing the team.

[PhilD]

I don't believe there is an issue with the com_installer directory or any core files that reside within it. Rather it is just the random place the hack files were/have been placed. There is also a large likelihood you will find htaccess files residing outside of where they are supposed to be on the domain(s). Failure to remove all points of the hack and close the weakness that allowed the file injections to the domain means that it will likely come back.

As a caution to others reading this post. Adding rules to an htaccess file will not always stop or prevent a site being hacked. The htaccess hack will modify your htaccess file whether it is 'protected' or not.

When adding or using additional information within an htaccess file be aware that some rules may be server specific, cause '500 errors', or cause issues with extensions that have an external callback to files within their directory. Incorrect rule additions or syntax errors can render issues with your site or cause the htaccess file to not be parsed after point of error.

What has been posted in the above post looks to be an older copy of parts of the suggested master htaccess file or copied from a slightly different (code the suggested master was based on) source.

For those who wish Additional information on a suggested htaccess file is located here:
http://docs.joomla.org/Htaccess_example ... ccess_file
with full document page here:
http://docs.joomla.org/Htaccess_examples_%28security%29

The suggested master file is well commented and areas that may require adjustment to work properly have notes and/or warnings.

[WebJIVE]

PhilD, here's what we're seeing in the CXS scan. CXS records the URL from which the upload happened when the upload happened.

Also, to your point, correct! Be VERY careful with .htaccess files. They can 500 your site or cause some really weird things to the site. While this may work for our server configuration, it may not for others. We manage our own servers so, we know and control the environment tightly. We even have SSH disabled until its required.

Scan results from CXS (note actual URL altered)
Scanning web upload script file...
Time : Tue Oct 30 08:03:46 2012
Web referer URL : http://website.org/administrator/index. ... _installer
Local IP : 174.36.34.32
Web upload script user : nobody (99)
Web upload script owner: partners (664)
Web upload script path : /home/website/public_html/administrator/index.php
Web upload script URL : http://website.org/administrator/index.php
Remote IP : 89.106.12.164
Deleted : No
Quarantined : Yes [/home/quarantine/website/20121030-080344-UI-QMEPk9sIAAHtFMWoAAAAO-file-sSCySA.1351602226_1]


----------- SCAN REPORT -----------
(/usr/sbin/cxs --smtp --options mMOLfSGchexdnwZDR --filemax 10000 --ignore /etc/cxs/cxs.ignore --sizemax 500000 --summary --quarantine /home/quarantine --mail root --quiet --timemax 30 --qoptions Mv --doptions Mv --cgi --virusscan --clamdsock /tmp/clamd --exploitscan /tmp/20121030-080344-UI-QMEPk9sIAAHtFMWoAAAAO-file-sSCySA)

# ClamAV detected virus = [Trojan.PHP-43]:
'/tmp/20121030-080344-UI-QMEPk9sIAAHtFMWoAAAAO-file-sSCySA'

As you can see, they are using com_installer or the admin index.php file to upload the script and, this site is running the latest Joomla 1.5 rev, and the index.php file is pure with no scripts attached.

[Webdongle]

What you see is the script they uploaded after they hacked your site. It is not the original hack ... It's something they were able to do because your site had been previously hacked.

They could have hacked the site in one of many ways including(but not limited to), : sql injection via a vulnerable extension that you installed (that's why examining the access logs is vital). ... a Trojan on your computer that 'Sniffed' your passwords ... a Trojan on someone else's computer (that has ftp/admin access) ... A poorly set up server with an outdated CP that is vulnerable ... someone with admin access that uploaded an infected file ... ad infinitum.

Once they gain access through one of those(or other means) ... then they have access to upload the script that you found.

Again ... The file you found is the symptom not the cause !!!

[WebJIVE]

Well, @webdongle is flat out incorrect.

I have seen first hand where com_media (the joomla media manager) was used to upload one of these scripts. Even after fully reloading every script on the system to something clean, they still manage to find holes. The good thing is we run real-time scans so anything with a base64 or other way to call back to an outside system is quarantined.

As you say @bensword, Joomla does have some parts of the system with ways to get PHP uploads accomplished without a compromised script. I just thought I would share this experience but, some think differently than I do.

[Webdongle]

Well, @webdongle is flat out incorrect.

I have seen first hand where com_media (the joomla media manager) was used to upload one of these scripts. ...

Yes a script can be uploaded if you set Joomla to allow those types of uploads. That has nothing to do with com-media ... it is to do with the fact that you have allowed them to do it.

An analogy would be
Giving a delivery firm the keys to the main building instead of just one key to the delivery room.

It is not a weakness in com_media it is you allowing incorrect use of the tool.

[WebJIVE]

@Webdongle - More back at ya...

administrator/index.php?option=com_media&task=file.upload&tmpl=component&73ce891226b7d45e7a9c946a1eab0cc4=2c2fc789845ffab8f7a9c3d1f72b8e5d&e9aa075b9411e9fd7149e4b42a1027a6=1

That's how they are using com_media to put files on the server. Go look at the com_media code and it's right there in -> administrator/components/com_media/views/media/tmpl/default.php

Code: Select all

			<?php if ($canUpload) : ?>
				<form action="<?php echo JURI::base(); ?>index.php?option=com_media&task=file.upload&tmpl=component&<?php echo $this->session->getName().'='.$this->session->getId(); ?>&<?php echo JUtility::getToken();?>=1" id="uploadForm" method="post" enctype="multipart/form-data">

This action is also in
./views/images/tmpl/default.php
./views/images/view.html.php
./views/media/tmpl/default.php
./views/media/view.html.php

So, evidence that Joomla 1.5.26 does have a security hole. Note the code above is from a local unziped Joomla 1.5 on my HD, not the server

[Webdongle]

You omitted the lines that gets the user and defines the '$scanupload' variable
<?php $user = & JFactory::getUser(); ?>
<?php $canUpload= ($user->authorize('com_media', 'upload')); ?>

Now try explaining how a non authorised user can meet the criteria of
<?php if ($canUpload) : ?>

The only way a hacker can use that legitimate code to upload a file is to have hacked you and got the login details of a user authorised to upload. Therefore the weakness is not in the code but in the site security that allows hackers to sniff login details.

[WebJIVE]

@webdongle, The $canUpload doesn't stop you from initiating the code from the URL. The site IDs and passwords are not compromised. I don't get your beef with someone (not just me) having this issue.....

If they had the login id and password, then they could install some addons or other code to do WAY more damage.

[PhilD]

@webJive
if you have proof of concept of the security issue, then you should report it to the JSST as both mandville and myself suggested in earlier posts.
http://forum.joomla.org/viewtopic.php?f ... 0#p2928171

If you can show that the issue is reproducible on a known clean install (no added 3rd party extensions/templates/other stuff) of the Joomla 1.5.26 core then the JSST will take the necessary actions.

If you can not provide a proof of concept that is reproducible or elect to not report the issue, then nothing is likely to be done.

[Slackervaara]

If you are worried that guests might be able to upload files to the site, take a look at the security extension jHackGuard, which have the feature disable uploads for guests.
http://www.siteground.com/joomla-hostin ... rid=167798

[PhilD]

@Slackervaara
That has nothing to do with the conversation and won't stop the issue method that is being discussed.

Please stay on topic.

[WebJIVE]

@PhilD. thx! will do.

[Webdongle]

... The $canUpload doesn't stop you from initiating the code from the URL.
....

If that is true and the code run when the <?php if ($canUpload) : ?> statement were false then it would mean that no php if statements were adhered to. The code (in the <?php if ($canUpload) : ?> statement) only runs if the user is authorised to do so. Therefore by definition of the code ... a user must be logged in with the login details of user that has the correct authorisation.

... I don't get your beef with someone (not just me) having this issue.....

That's because I have no 'beef' with anyone who has been hacked. And your attempt at questioning my motives does not detract from the value of what I say.

...
If they had the login id and password, then they could install some addons or other code to do WAY more damage.

Exactly, so that means that it was a security breach in some other area that allowed the hacker to upload files. Because anyone uploading files via the media manager would be authorised to do so because of your settings in Joomla admin.

There are many ways to hack a site and focusing on one aspect without proof ... prevents the real cause from being found. To say 'all hacked sites had Joomla installed therefore Joomla is insecure' ... is like saying 'All horses have tails therefore all animals with tails are horses.

You pick a piece of legitimate code that is for authorised upload and then neglect to see that the code is only run when requested by an authorised user.

If the code can be used by non logged in, non authorised users and you have proof of that ... then you can (by the same knowledge) write the code in a way that only logged in authorised users can upload. And what is more, you would have placed that code in your files.

Also ... if the code you quote is vulnerable then the security moderators would have edited your post to prevent hackers from taking advantage of such knowledge.

[WebJIVE]

To @Webdongle - It was a compromised user login. They just don't login to keep under the radar. For those who have been following this thread.

1. Follow all the guidelines for Joomla esp. the ones posted in the forums (we have over the years)

2. Make sure Joomla is up-to-date. If you feel it's compromised, FTP a full copy of Joomla over the one you have.

3. Make sure your modules and plugins are the latest ones and re-install if you feel like they have been hacked.

4. Us a tool like OSE Antivirus to scan all files for base64 operations and other holes: http://extensions.joomla.org/extensions ... ction/8385

5. Change ALL manager and super admin passwords (this was our issue).

Lastly, this is for @webdongle (attached image). Us eating crow.

[PhilD]

Where is the cornbread?

[WebJIVE]

@phil, had it last night!

[PhilD]

The developers try hard to make sure and keep the core up to date and usually there are other reasons for a hack on a site as was found in this case. This does not mean a core never has security issues, they sometimes do, and is why a means is provided to report proof of concepts for testing.

While your recommendations of recovering from a hack are valid, doing them just as stated may leave the site hacked. This is because the matter of overwriting a full copy of Joomla would not remove any added hack files that may be hidden throughout the sites directories. Simply reinstalling extensions (even if updated) also won't remove any extra files contained within the extensions directories.

As far as repairing a hacked site, the Joomla community provides a number of easy to follow documents and forum posts to enable a successful recovery from a hack. The main one would be the "before you post" sticky topic http://forum.joomla.org/viewtopic.php?f=621&t=582854 It contains most of the information and links that are needed.

[WebJIVE]

@PhilD. Thx. We have un-hacked quite a few Joomla sites over the years. I was giving the LITE version of what to do. It's much more complex that most people think and takes a lot of time. We have about a half dozen tools in our arsenal to prevent and find hacked sites which is why our hosting is $20 instead of the $9 most companies charge. We keep the site updated to the latest Joomla, any addons the site has, and monitor them closely. Another thing that seems to be RARE these days is a hosting company that does nightly backups like we do.

[PhilD]

I suspected it was a lite version. It is just other readers that are less experienced in preventing/recovering from hacks reading it may think that's all that they have to do, which in many cases would leave a site hacked. So I usually point that out.

The documentation the community provides attempts to take a complex process and make it easy for non technical persons to follow and successfully clean and repair their sites. If you have suggestions to improve the documentation your welcome to PM me for discussion.

[WebJIVE]

@PhilD. I think you have some excellent points!

For the less experienced, it would be better for them to seek out a third party to repair the site vs doing it themselves. While Joomla may be free to download, many people translate that into, it should free to maintain, etc. Everything needs maintenance, and you need to view a Joomla (or other CMS) like a car/truck. You hate to have spend money on an oil change or new tires but, you do it to maintain your investment and keep rolling.

Websites are the same. You invest in a asset that gets your company/whatever out there so people can find you Some even make you money, even a LOT of it. Some of its just for fun but, in the end, all sites require time and money to keep them rolling.

Our challenge, as is 1000's of other design and hosting companies, is getting small businesses (and individuals) to understand the value of a professional support organization, vs trying to roll one yourself with say, Godaddy, Hostgator or other general hosting companies. We opted out of that market because their servers are setup to allow almost anything to run, which makes it easier for bad things to happen.

This has been a good thread to keep rolling so that newbs have a good thread to read and better understand what to do if they have a Joomla site or, if they should seek out a professional for help with issues.