Tag: security

  • Introducing Wordfence, the Ultimate WordPress security plugin.

    Exec Summary: Last year this WordPress blog was hacked which led me to discover the timthumb vulnerability you may have heard of. I fixed timthumb and worked with Ben, the author to release timthumb 2.0. Then I started work on Wordfence, what I hope will be the best security plugin in the business for WordPress. Wordfence is now completing beta testing. Install it, it’s free and it will help protect your site and keep you off Google’s malware list and in the search results. For beginners: you install Wordfence by going to your WordPress blog’s “Plugins” menu, clicking “Add New” and searching for “Wordfence”.

    Full Post:

    Last year on August 1, this WordPress blog was hacked. Thankfully I caught it quick enough to stay of Google’s malware list. I retraced the hacker’s steps and discovered a zero day vulnerability in many WordPress themes and plugins in the form of a popular image resizer called timthumb.php.

    So I rewrote timthumb.php and worked with the author of timthumb and some of the WordPress team to merge my code into timthumb and we launched it as timthumb version 2.0.

    But getting hacked made me realize that as awesome as WordPress is, it can do security better.

    So I dropped everything and spent the last few months writing what I hope will be the last word in WordPress security.

    A few days ago I quietly released Wordfence into the WordPress plugin repository. Since then I’ve been working with some amazing WordPress publishers to make Wordfence even better and I’ve been rapidly rolling out improvements, enhancements and (yes, believe it or not) a few bug fixes. I’d say Wordfence is getting close to finishing Beta testing at this point.

    Except for two (rather minor) features, Wordfence is completely free. It is also backed up by a cluster of cloud based scanning servers that do most of the heavy lifting to keep your site running super fast.

    Here are some of the more notable ways Wordfence enhances your WordPress security:

    • Scans your core files against a reference copy which I maintain in our cloud servers.
    • Lets you see what has changed, how the file has changed and even repair it.
    • Scans your comments, posts and all files including core, themes, plugins and everything else under your WordPress root directory for malware, virus signatures, vulnerabilities and (very importantly) URL’s that are known to host malware or viruses.
    • I want to re-emphasize the last point. Wordfence keeps known dangerous URL’s, including ALL URL’s that are on Googles’ safe browsing list, out of your comments, pages, posts and files. This is by far my favorite feature because it’s virtually gauranteed to keep you off the dreaded red-page-of-death-malware-list that Chrome and Google use to ban sites.
    • Wordfence comes with a complete firewall that lets you set up rules based on the type of traffic and either throttle or block offenders with an SEO safe 503 (come back later) HTTP message.
    • Another favorite feature of mine is that you can block fake Google crawlers. I actually added this after I tested Wordfence on this site because I couldn’t believe how many scrapers were pretending to be Googlebot. So now they are all instantly blocked.
    • Wordfence uses Google’s recommended reverse-forward DNS verification to sift the fake Googlebots from the real ones.
    • It includes login security against every form of brute force attack out there including abusing your lost-password form.
    • And what’s the point of having all this awesome security if you can’t see who is visiting, who’s getting blocked and what humans and robots are doing? So Wordfence includes real-time traffic that wait..for…it…
    • …Includes crawlers, scrapers, robots and all non-human traffic. Something you can’t get from Google Analytics or any other Javascript based analytics package.
    • I’ve even broken out Googlebot, other crawlers, 404 errors, humans and there’s an All Hits view.
    • And of course it includes commercial grade city-level geolocation which is another feature that comes from our cloud servers.
    • Wordfence is also built using much of the knowledge I’ve gained building Feedjit’s real-time analytics so it is careful to minimize any impact on network, website and mysql database performance and keep your website running super-fast.

    Most importantly, Wordfence comes with a commercial license if you prefer first-class support and support forums for free users including a generic WordPress security forum where I’m happy to answer general config questions.

    Improving WordPress security is going to be a marathon, not a sprint. I’m in this for the long haul. So check out Wordfence now by installing it on your blog and work with me to make the Web and WordPress more secure.

     

  • WordPress Security: Which is more secure? A VPS or a VHost?

    Big News [April 24th, 2012]: I’ve launched Wordfence to permanently fix your WordPress site’s security issues. Click here to learn more.

    In web server admin parlance, a VPS is a Virtual Private Server and a VHost is a virtually hosted website. There were a few questions regarding security on VPS’s and VHosts in my previous post on “Seven ways I could hack into your WordPress website“, so I thought I’d clarify what the difference is between WordPress hosted on a Virtual Private Server (VPS) vs WordPress on a Virtual Host (VHost) and what the security implications are of each configuration.

    A Virtually Hosted Website (VHost)

    In the early days of the web, you would have a single physical machine running a single operating system running a single web server. That web server would serve up a single website.

    HTTP 1.0 introduced the optional “Host:” header and HTTP 1.1 made it mandatory with any web request that a browser sends. The effect of this is that when a web browser sends a request to any web server, it lets the server know which website it wants to see. Because web servers know what website a browser expects, they can now host an unlimited number of websites. This is called virtual hosting.

    When you have a virtually hosted website, you are sharing a single server and operating system with many other websites. Your files and the files of other websites are stored on the same operating system. You all share the same web server and the server chooses which of your websites it needs to serve based on what a web browser requests when it connects to that web server.

    Usually on a virtually hosted website, you won’t have access to other website files and they won’t have access to yours. This is usually done by giving you a unique username that you use to sign in and your username only has permissions to view your files.

    A Virtual Private Server (VPS)

    A VPS is a little different. Normally when you install any operating system, you install it directly on a machine like a server or workstation. With a VPS, you first install a base operating system like Windows or Linux. Then you install a virtual machine hosting platform called a Hypervisor. Examples of Hypervisor’s are VMWare and Xen.

    Within the Hypervisor you can then install multiple virtual machines. These pretend to be physical hardware and when you boot them up you get a BIOS message similar to when you boot up a physical machine.

    Within these virtual machines you can then install an operating system like Linux or Windows. Using this config you can have potentially hundreds of virtual machines running on a single physical machine.

    So to summarize, you have a physical machine running an operating which runs a hypervisor which runs multiple virtual machines and each virtual machine runs its own operating system. Within these operating systems you run your own web server, have the files for your website and do anything else you feel like doing. It’s impossible for someone on another virtual machine to access your virtual machine.

    Linode is one of the most popular virtual machine hosting providers and they use the Xen Hypervisor to host Linux virtual machines.

    So which is more secure?

    By now you’ve probably already figured it out: Running your own virtual machine that is completely segmented from everyone else is usually the more secure option. Here are a few reasons why:

    1. If your web host messed up the machine configuration or permissions, then other users may be able to access your files.
    2. If another user’s WordPress installation gets hacked, it may be possible for the hacker to gain read or in rare cases read and write access to your files.

    Another thing I like about having a VPS instead of a VHost is that you have your own IP address. On the Internet, IP addresses can get blacklisted, particularly if you’re sending email. If your web application sends email e.g. if you’re using the WordPress “Subscribe to Comments” plugin, then your emails may be flagged as spam if another user on the same server is sending a lot of spam.

    With a VPS you have your own IP address, so as long as the IP address wasn’t already black-listed when you got it from your web host (I’ve seen it happen) then only you are responsible for how that IP address is perceived on the Net.

    In conclusion: While VPS’s tend to cost slightly more (about $20/month from Linode), they are well worth the extra cost when it comes to protecting your website and your reputation. As always please post any questions in the comments and I’ll either answer them directly or in a future post.

    Caveat: I have generalized greatly when it comes to VPS and VHost configurations. There are many variants including Type I and Type II Hypervisors, shared hosting where a single OS hosts one web server instance per website and many more. I’ve described two common VPS and VHost configs above for illustrative purposes, however the VPS config I describe is probably the most common configuration used by VPS providers.

     

  • Breaking: Google starts to block hacked WordPress blogs as attack widens

    Big News [April 24th, 2012]: I’ve launched Wordfence to permanently fix your WordPress site’s security issues. Click here to learn more.

    I’ve had two reports in the last 12 hours of WordPress blogs that were compromised via the Timthumb hack being listed as malware by Google. If you try to visit either site, you are confronted with the following:

     

    These sites are listed with the warning that “This site may harm your computer” in Google’s search results and Google blocks access to the site with a warning forcing you to manually type the URL into your location bar if you really do want to visit the site:

    One of the site owners sent me the detailed info that Google Webmaster Tools was giving her:

    This malicious code is appearing intermittently on this author’s WordPress site. I’ve seen this same pattern recently in blogs I’ve repaired and the way it works is that the site is periodically downloading new PHP code from a remote site run by the attacker and re-injecting it into the wordpress code. That allows the attacker to add, remove and update whatever code he/she is executing on your blog. So they could for example update any spam links every few hours.

    To prevent your site being listed as malware clean it as fast as possible

    The fastest way to do this, although it doesn’t gaurantee a complete clean, is the following:

    1. Remove all old plugins and themes you aren’t using.
    2. Upgrade all your plugins and themes to the latest versions and make sure none of them use an old version of Timthumb.
    3. Clean any Timthumb cache directories.
    4. Upgrade your entire wordpress installation, even if it’s at the latest version. This overwrites all wordpress files.
    5. Search your directory tree for any remaining suspicious files that contain base64_decode wrapped in an eval() statement or URL encoded data. More info on how to do this search here. Delete any files you find. NOTE: If you don’t find any additional infected files in this step, it’s highly likely that your site is not clean. Every attack that I’ve seen so far using Timthumb gets in by uploading a file into the cache directory and then uploads an additional file into a writeable directory on the blog to ensure continued access once the cache is cleaned. Make sure you find that additional file.
    6. Make sure the only directory that is writeable in your wordpress installation is wp-content/. Directories like wp-admin and wp-includes should be read only by the web server.

    If you are already listed as malware by Google, here is what to do

    Clean your site using the above steps. You can find more suggestions on how to clean your site on this page.
    The fastest way to get your site removed from Google’s malware list is to request a review through Google Webmaster Tools. You can find the help file on requesting a malware review on this page.
    The process takes about 24 hours to get your site removed. You can find out more about Google’s Malware list and safe browsing report on this page.

     

    Potential long term impact of this vulnerability

    The fact that I’ve seen the same domain being used by attackers on multiple blogs suggests this attack may be partially or fully automated. The worst case scenario is that we end up with a WordPress botnet with thousands or tens of thousands of servers on high bandwidth links compromised and able to send spam emails or launch a huge DDoS attack.

    Keep in mind that most botnets are compromised windows machines on relatively slow home broadband connections. Their uplink speeds are around 512kbps. These WordPress servers are on links that are a minimum of 10 Megabits per second each, so they have plenty of firepower for a coordinated attack. One WordPress server is equal to at least 20 infected PC’s in terms of pure bandwidth firepower.

     

  • Routers treat HTTPS and HTTP traffic differently

    OSI Network Model

    Well the title says it all. Internet routers live at Layer 3 [the Network Layer] of the OSI model which I’ve included to the left. HTTP and HTTPS live at Layer 7 (Application layer) of the OSI model, although some may argue HTTPS lives at Layer 6.

    So how is it that Layer 3 devices like routers treat HTTPS traffic differently?

    Because HTTPS servers set the DF or Do Not Fragment IP flag on packets and regular HTTP servers do not.

    This matters because HTTP and HTTPS usually transfer a lot of data. That means that the packets are usually quite large and are often the maximum allowed size.

    So if a server sends out a very big HTTP packet and it goes through a route on the network that does not allow packets that size, then the router in question simply breaks the packet up.

    But if a server sends out a big HTTPS packet and it hits a route that doesn’t allow packets that size, the routers on that route can’t break the packet up. So they drop the packet and send back an ICMP message telling the machine that sent the big packet to adjust it’s MTU (maximum transfer unit) size and resend the packet. This is called Path MTU Discovery.

    This can create some interesting problems that don’t exist with plain HTTP. For example, if your ops team has gotten a little overzealous with security and decided to filter out all ICMP traffic, your web server won’t receive any of those ICMP messages I’ve described above telling it to break up it’s packets and resend them. So large secure packets that usually are sent halfway through a secure HTTPS connection will just be dropped. So visitors to your website who are across network paths that need to have their packets broken up into smaller pieces will see half-loaded pages from the secure part of your site.

    If you have the problem I’ve described above there are two solutions: If you’re a webmaster, make sure your web server can receive ICMP messages [You need to allow ICMP code 4 “Fragmentation needed and DF bit set”]. If you’re a web surfer (client) and are trying to access a secure site that has ICMP disabled, adjust your network card’s MTU to be smaller than the default (usually the default is 1500 for ethernet).

    But the bottom line is that if everything else is working fine and you are having a problem sending or receiving HTTPS traffic, know that the big difference with HTTPS traffic over regular web traffic is that the packets can’t be broken up.

  • How to mirror someone elses web server with iptables

    It took me a while to find this – I needed it for testing purposes, nothing malicious. If you’d like your web server somewhere on the web to pretend to be any other web server, even a secure one, you can do the following. x.x.x.x is your own server and y.y.y.y is the ip of the server you’re trying to mirror. I’m also assuming you only have one network card in the machine and it’s called eth0. The following will mirror a secure web server. If you’d like to mirror a regular web server, replace 443 with port 80.

    iptables -t nat -A PREROUTING -p tcp -i eth0 -d x.x.x.x --dport 443 -j DNAT --to y.y.y.y
iptables -t nat -A POSTROUTING -p tcp -o eth0 -d y.y.y.y --dport 443 -j MASQUERADE

    If this doesn’t work you probably have to enable packet forwarding like this:

    echo 1 > /proc/sys/net/ipv4/ip_forward