How Exposed To Hackers Is the WordPress Website You Built?

×

    🚩 Report

    How Exposed To Hackers Is the WordPress Website You Built?

    I just want to share this article from the backtrack community because I think it will really help lots of people to secure their WordPress websites with this tips, you can download the PDF version here full credit for the backtrack blog for sharing this pdf file

    WordPress is likely the most popular website framework used on the web today. With over 65 million downloads and a very active community you can accomplish many goals with ease using WordPress.

    Not only does the standard WordPress package include many cool features but the number of
    easy to install WP plugins available continues to grow, which in turn continues to multiply the number of uses for WordPress. The problem with so many WordPress installations all with different variations of WordPress themes and WordPress plugins is the fact that many people will launch a WordPress site and think everything is safe and sound moving forward. That is not the case, however. As technologies evolve and hackers figure out new ways to generate money, new holes will be located within the core WordPress code, WordPress plugins, WordPress themes, and in sloppy system administration. The article below will provide you with a basic understanding of the types of attacks to which your WordPress site may be vulnerable, along with various methods to minimize your risk by using basic Linux commands and the tools within Backtrack Linux.

    A Short Story About Incorrect WordPress File Permissions & The Possible Damage That Can Follow

    You may be thinking that your WordPress site would never be a target for attackers, however, regardless of content, your WordPress blog is a target. (Many of the most effective WordPress exploits I have seen over time typically involve the quantity of breached websites versus the quality of the breach itself.)? One of the more tricky exploits I have seen with WordPress involved an attacker adding some simple PHP code to files on a WordPress server that had permissions set incorrectly which is a very common mistake among do it yourself web developers. The attacker adds the malicious code to specific files within the WordPress file structure, which redirects traffic with a referrer of a set list of search engines. An example of the malicious code in action would be someone searching for XYZ on Google which happens to relate to an article you have written on your WordPress site, so they click the result that takes them to your article, but instead of displaying the article you posted about XYZ, they are instead redirected to another website that is full of ads or full of malicious code that could infect your browser and/or PC.

    The benefit to the attacker is that they are either making money from the ads, or they are exploiting your users’ systems upon being redirected. Regardless of the scenario, the outcome is a horrible experience for the person visiting your website. The genius behind this type of attack is that it is extremely hard to track down and nearly impossible for inexperienced web developers or system administrators to locate. When this type of redirect issue is reported the person troubleshooting the problem typically visits the WordPress site in question and everything appears to be working as expected because they were not visiting the site through Google.

    Therefore they assume the issue was on the reporting users end. File permissions are extremely important and should be understood and followed when installing and/or managing a WordPress installation. There are plenty of details on the WordPress Codex pages that can assist anyone not familiar with file permissions. The primary steps to take, however, include making sure files are not owned by the webserver process, setting directories permissions to 755, and setting file permissions to 644. Having the proper file permissionswill keep the attacker’s WordPress bots at bay.

    Lisring 1. Enumerate WordPress Usernames Using WPScan In Backtrack Linux
    ###################################################
    root@bt:/pentest/web/wpscan# ./wpscan.rb -e u[1-25] --url wordpress.example.com
    ____________________________________________________
    __ _______ _____
    / / __ / ____|
    / / /| |__) | (___ ___ __ _ _ __
    / / / | ___/ ___ / __|/ _' | '_
    / / | | ____) | (__| (_| | | | |
    / / |_| |_____/ ___|__,_|_| |_| v1.1
    WordPress Security Scanner by ethicalhack3r.co.uk
    Sponsored by the RandomStorm Open Source Initiative
    _____________________________________________________
    | URL: http://wordpress.example.com
    | Started on Wed May 23 11:27:31 2012
    [!] The WordPress theme in use is called 'drawar' v1.0
    [+] We have identified 1 vulnerabilities for this theme :
    | * Title: WooThemes WooFramework Remote Unauthenticated Shortcode Execution
    | * Reference: https://gist.github.com/2523147
    [!] The WordPress 'http://wordpress.example.com/readme.html' file exists
    [!] WordPress version 3.3.2 identified from rss generator
    [+] We have identified 1 vulnerabilities from the version number :
    | * Title: WordPress 3.3.1 Multiple CSRF Vulnerabilities
    | * Reference: http://www.exploit-db.com/exploits/18791/
    [+] Enumerating plugins from passive detection ... 2 found :
    | Name: woo-tumblog
    | Location: http://example.wordpress.com/wp-content/plugins/woo-tumblog/
    | Name: jetpack
    | Location: http://example.wordpress.com/wp-content/plugins/jetpack/
    |
    | [!] WordPress jetpack plugin SQL Injection Vulnerability
    | * Reference: http://www.exploit-db.com/exploits/18126/
    [+] Enumerating usernames ...
    We found the following 5 username/s :
    admin
    superadmin
    bob
    wiwi
    [+] Finished at Wed May 23 11:27:54 2012
    root@bt:/pentest/web/wpscan#
    #######################################################

    Below are two quick examples of what the file
    permissions should look like on the wp-content folder
    and the wp-cache-config.php file.

    Changing File Permissions Example From
    WordPres Codex

    *****************************
    For Directories
    find /path/to/your/wordpress/install/ -type d -exec chmod
    755 {} ;
    For Files
    find /path/to/your/wordpress/install/ -type f -exec chmod
    644 {} ;
    *****************************

    Use Backtrack Linux To Proactively Audit Your WordPress Installation

    An exploit of sorts that was initially made public many years back is username enumeration which allows a would be attacker to easily obtain a real time list of users who likely have access to the /wp-admin or administration section of your WordPress site. This doesn’t necessarily mean your WordPress site is immediately vulnerable but what it does mean is an attacker now has 50% of the necessary information to gain access to your entire website. There are numerous methods in Backtrack that provide some form of user enumeration including my personal favorite which is called WPScan and which has been specifically created for auditing WordPress sites. It will be a tool we will visit numerous times within this article. The wpscan.rb Ruby script written by Ryan Dewhurst (@ethicalhack3r) is classified as a WordPress vulnerability scanner which checks the security of WordPress installations taking a black box approach. Currently WPScan is the most comprehensive tool available on Backtrack Linux to test various security flaws within WordPress, including username enumeration, WordPress version info, and WordPress plugin info/vulnerabilities. WPScan also provides a method to brute-force WordPress logins once you have enumerated the usernames. To see basic information for WPScan including the list of command line switches available and a couple of example wpscan.rb commands, issue “./wpscan.rb — help” from the /pentest/web/wpscan directory. The first bit of information we will gather from a fake WordPress site will be a list of usernames using WPScan which by default will attempt to enumerate usernames with UID’s or user id’s 1 through 10. However, a new option in WPScan allows you to specify any range of UID’s you prefer, as shown in the example below. Along with the username enumeration we will also get other default information output in our WPScan query which is also shown in the below example.

    Enumerate WordPress Usernames Using WPScan In Backtrack Linux

    See Listing 1.

    Lets first analyze the command that was issued at the top of the above output to provide the results that were returned from WPScan. We issued two switches with the wpscan.rb command including “-e u[1–25]” which tells WPScan to enumerate usernames with UID’s 1 thru 25 and “ — url wordpress.example.com” which specifies the WordPress site URL. The WPScan output above is divided into four sections below, which include WordPress theme information/vulnerabilities, basic WordPress information/vulnerabilities, WordPress plugin
    information/vulnerabilities, and WordPress username information.

    WPScan WordPress Theme Information & Vulnerabilties

    The wpscan.rb output was able to determine that the theme in use is the drawar theme provided by Woo Themes that it then notes has a vulnerability that allows remote code execution. When following the link in the drawar theme vulnerability output you can see that a would be attacker could execute remote code such as adding a Twitter follow me button on the remote site depending on the drawar theme version. You may or may not have a vulnerability or a list of vulnerabilities listed, depending on the theme name that is enumerated. WPScan is really accurate, however, in enumerating the theme name which provides a would be attacker more information than they had initially.

    WPScan Basic WordPress Information & Vulnerabilities

    Basic WordPress information is also output that shows a would be attacker the version of WordPress that is running along with any known vulnerabilities within that WordPress version. As you can see in the output above WordPress version 3.3.1 had a CSRF or Cross Site Request Forgery vulnerability that allows would-be attackers access to change data on the site such as WordPress Post Title using CSRF and the WordPress Quick Edit Function.

    WPScan WordPress Plugin Information & Vulnerabilties

    Within the WPScan root directory, which is /pentest/ web/wpscan on Backtrack Linux 5, there is a file in the data directory named plugins.txt which has a fairly large list of WordPress plugins that WPScan will query to see if they exist on the target site. Once a plugin has been verified not only will it be output, but the plugin and plugin version will checked against a list of known vulnerabilities and will also output any matchessuch as the JetPack plugin SQL Injection Vulnerability noted in the example output above.

    WPScan WordPress Username Information:

    One of the items that really impressed me when I first ran WPScan some time ago was the ability to enumerate usernames from a WordPress site. While in my opinion this is a security flaw within WordPress that should be resolved, it is still exciting to query a WordPress site and have the primary admin users returned back to you. Notice that in this example we attempted to enumerate UID 1 through UID 25 and we were returned 25 results that include a user named admin and a user named superadmin. While the usernames themselves are not directly vulnerable, it does provide a would be attacker with 50% of the data necessary to brute force a login to your WordPress site which, if accomplished, would be devastating to your WordPress site. Below we discuss the WordPress username enumeration security flaw in more detail including how to manually enumerate the usernames so you can better understand the basis of automated tools such as WPScan.

    How To Manually Enumerate WordPress Login ID’s And Usernames

    Open the following URL but change the domain to the domain running your WordPress site: URL: http:// www.wordpressexample.com/?author=1. If you have not deleted the default admin user created during your WordPress install you will be redirected to a URL similar to the following: URL:http://www.wordpressexample.com/authors/admin. So as you can see you now know that the default admin user still exists, its user id is 1, and the login is actually the default admin. Now if you received an error such as a 404 indicating that this user does not exist you could move right along to the next URL such as the following: URL: http://www.wordpressexample.com/?author=2. If the above URL is successful in being redirected to something that means you will now know another user id and user name. It would obviously be easy to write a script that would walk through thousands of user ids in a short amount of time and in the end you would know all of the WordPress user id’s that are active and their corresponding WordPress logins. The WPScan application within Backtrack Linux is one of numerous tools available to assist in auditing your WordPress installation. Other tools that are useful include wfuzz, w3af, nmap, and metasploit. These tools will be expanded on during a follow up article discussing auditing WordPress with Backtrack Linux. Now that we see how easy it is to enumerate various data from WordPress, lets look at a couple of methods to begin locking your WordPress site down, so potential attackers are discouraged and move on to another site that will be easier for them to exploit.

    Begin Taking Steps To Lock Down Your WordPress Site

    Now that you can see how easy it is to locate vulnerabilities within WordPress and gather data about a specific WordPress installation I will now discuss numerous security measures that can be put in place to minimize your WordPress installation’s exposure. Below it is discussed how to manually add an entry to .htaccess which will block username enumeration followed by various plugins that provide different security benefits which make exploitation of your WordPress installation more difficult.

    How To Defend Against WordPress User ID And Login Enumeration

    I have not seen the below fix implemented previously and I am not sure if there are any hidden problems caused by utilizing such an .htaccess entry. For me, however, it is worth the risk, as any issues that may arise from blocking this query would likely be minimal. It would take me much longer to have to restore my entire site from scratch if it were hacked and defaced or destroyed after someone enumerated the WordPress usernames and then brute-forced an administrator login to my WordPress site. I have implemented the solution below on numerous WordPress installations for months without any issues. To block user login enumeration we are going to add a couple lines to the .htaccess file located in the root web directory of your WordPress web site as shown below. You will want to add this near the top of the .htaccess file because if it is added below the normal redirect, it is useless.

    Code To Add To .htaccess File To Block WordPress User Enumeration

    ######
    RewriteCond %{REQUEST_URI} ^/$
    RewriteCond %{QUERY_STRING} ^/?author=([0-9]*)
    RewriteRule ^(.*)$ http://www.wordpressexample.com/
    some-real-dir/ [L,R=301]
    ######

    The code above tells the web server that any request made to the WordPress site matching the query string of “/?author=should be redirected to http:// www.wordpressexample.com/some-real-dir/. I have this code right under “ServerSignature Off” which is at the top of the .htaccess file in the WordPress root directory. Once you add these lines to the .htaccess file, user enumeration is now blocked. Continue below for discovering other security measures to take with 80 03/2012 EXPLORE YOUR PC your WordPress site. Please note that /some-real-dir/ could be any existing URL on your site or you could make a page that explains that user enumeration or viewing authors in this manner is not allowed for security reasons. It is always best practice to backup any file before making changes to do that and the .htaccess file is no exception.

    Minimize WordPress Data Available Such As Block WordPress Version From Displaying

    To accomplish the goal of minimizing the WordPress information that is exposed, I install a WordPress plugin called Secure WordPress. A quick search for Secure WordPress on the WordPress plugins site should return the Secure WordPress plugin at the top of the results. Just by installing and activating Secure WordPress you will resolve numerous security holes, including the hole allowing attackers to see your WordPress version. It also provides some protection against malicious URL requests, and removes the Really Simple Discovery link in wp_head. I also like to enable all checkboxes except for the Error Messages check box, and one option that is not checked by default but I do check is Windows Live Writer. I would also suggest signing up for WebSiteDefender as you will get a free scan of your web site which can be accomplished via the Secure WordPress settings page. WordPress Plugin Secure WordPress AdminView

    See Figure 1.

    Block Various SQL Injection Attempts To WordPress & Secure Other WP Areas

    Another plugin I install is called BulletProof Security and it is also available on the WordPress site in the plugins directory. The WordPress plugin BulletProof Security is a bit more complex as you will first generate .htaccess files for various locations on your WordPress site, and then be required to merge them into existing .htaccess files. Make sure that when you merge the changes that the redirect for author that we previously added stays near the top of the .htaccess file located in the WordPress root directory. BulletProof Security provides a bunch of rules that minimize your exposure to SQL Injection and other nasty attacks. Make sure to backup the current .htaccess files before merging any new changes into them.

    #####
    RewriteCond %{QUERY_STRING} (;||’|”|)|%0A|%0D|%22|
    %27|%3C|%3E|%00).*(/*|union|select|insert|drop|delete|
    update|cast|create|char|convert|alter|declare|order|
    script|set|md5|benchmark|encode) [NC,OR]
    #####

    There are dozens of .htaccess entries similar to the
    above example entry. As you can see in the provided example BulletProof security will simply block malicious requests made to your WordPress site such as possible SQL Injection attempts. Keep in mind that implementing any plugin such as BulletProof Security that modifies web requests to your server could cause potential issues on your site so any changes made should be thoroughly tested.

    Remove readme.html File In WordPress Root Directory

    This one is self-explanatory. During the installation of WordPress a readme.html file is generated in the root WordPress directory so make sure to remove it. You can remove this file via FTP or using “rm” from the command line as shown in the below example.

    ####
    [root@dev ~]# rm /path/to/wordpress/root/dir/readme.html
    rm: remove regular file `/path/to/wordpress/root/dir/
    readme.html’? y
    [root@dev ~]
    #####

    Other WordPress Security Plugins To Consider Depending on the WordPress installation, I also install several other plugins related to security, including the Login Lockdown WordPress plugin, the AntiVirus WordPress plugin, the Login Logger WordPress plugin,

    Figure 1. WordPress Plugin Secure WordPress Admin View

    Figure 2. WordPress Comment Form Captcha

    and The WP Block Admin WordPress plugin. You should also consider utilizing something like Really Simple Captcha and you should make sure to include a Captcha on any contact form installed on your site, which will also cut down on SPAM. Another item that can become a hassle quickly with WordPress is the amount of SPAM received via comments attached to each WordPress post. To combat this you can install a WordPress plugin such as SI CAPTCHA Anti-Spam which will add a captcha to comments attached to WordPress posts and or WordPress pages as shown in the below example image.

    WordPress Comment Form Captcha

    Last but not least, make sure permissions are correct throughout the entire WordPress directory. If you provide the incorrect write permissions for vulnerable WordPress files, you are guaranteed to be hacked in a short amount of time

    (Figure2).

    Keeping Your WordPress Installation SecureMoving Forward

    Once the above security measures are firmly in place, the task of defending your WordPress site against potential attackers is still not complete. If you want your WordPress site to be secure on a long term basis, you will need to employ a proactive approach. You will need to continue using tools such as WPScan combined with other relevant tools in Backtrack Linux.. You will also need to update WordPress itself, to update your WordPress plugins, and possibly to use a third party service that runs automated scans against your WordPress site, all performed on a regular basis.

    We will be happy to hear your thoughts

        Leave a reply

        Pinoyscreencast
        Logo
        Compare items
        • Total (0)
        Compare
        0