Online Services

Tag: Wordfence

  • Avoid Malware Scanners That Use Insecure Hashing

    In this post I’m going to discuss a major problem that exists with several WordPress malware scanners: The use of weak hashing algorithms for good and bad file identification. Some malware and antivirus scanners outside of WordPress suffer from this same issue.

    For brevity, I’m going to refer to this as the “weak hash scanner” issue.

    This issue may allow an attacker to hide malware that is undetectable to scanners using the MD5 hashing algorithm. Below I will explain how hashes are used in the security industry, what the problem is and how to solve it. I’ll also point you to research demonstrating this issue and further reading. I’ll also describe how Wordfence uses a secure hashing algorithm for our malware scanner.

    How we use hashes in the security industry to find bad things

    In the security world we have a commonly used process of running a file through a piece of logic, called an algorithm, and generating a unique number. That number is used to uniquely identify files. This process is called a hashing algorithm and the unique number is called a ‘hash’.

    We use hashing algorithms for all kinds of really cool and useful stuff. We can take a piece of malware, create a hash for it and then store that hash. Later, we can create a hash of a file we’re scanning to check if it contains malware. If that hash matches the hash of the malware we created earlier, then we know the file is that malware.

    We can also use hashes to identify “known good” files. At Wordfence we have created hashes of every file we know is safe in the WordPress universe. We have hashes for every theme, plugin and core release in WordPress history. In fact, we have hashes of every file in every version of WordPress core ever released and every version of every theme and plugin ever released.

    Right now Wordfence tracks hashes for:

    • 205,146 WordPress core files that Wordfence knows are safe. 

    • 5,967,361 WordPress theme files that Wordfence knows are safe.

    • 23,527,261 – yes that’s 23 Million – WordPress plugin files that are known to Wordfence to be safe. This is every version of every file in every plugin ever released. 

    Hashes are a way for security companies like us to store a small piece of data that uniquely identifies known bad or good files, and then use that data to check if those files exist on a system we’re scanning. Then we can make a decision about whether to preserve the file or get rid of it.

    The diagram below illustrates how malware scanners use hashing to identify good and bad files.

    How scanners use hashing

    Not all hashing algorithms are equal: MD5 vs SHA-2

    There are various ways to create a hash. When you run a file through one of these hashing ‘algorithms’, they create a unique number of a fixed length. MD5 is a hashing algorithm that was created in 1991 by Professor Ron Rivest at MIT. It was incredibly useful but is now quite old and has some problems.

    Another newer and much more secure hashing algorithm called SHA-2 was developed by the National Security Agency and released by the National Institute of Standards and Technology in 2001. Today SHA-2 is widely used and considered secure enough for commercial use.

    MD5 is quite old now and the problem with it is something called ‘collisions’. It’s easy to understand the issue: With MD5, it’s possible to create two different files that have the same MD5 hash, or unique signature. This could be used, for example, to fool a malware scanner into thinking a malware file is actually a known-good file.

    That is why we use SHA-2 in Wordfence to track known good files. It prevents an attacker from creating a bad file that has the same hash as a known good file and avoiding detection.

    The weak hash scanner problem

    Unfortunately not all security products do this. In the WordPress space, some malware scanners uses plain old MD5 to hash files when searching for malware. Sucuri’s WordPress plugin and “Shield WordPress Security”, for example, use MD5 to detect core file changes. The way they do this is they grab the newest MD5 hashes from api.wordpress.org.

    The API these products use was not designed to be used for malware scanning. It was originally created for the WordPress upgrade process back in 2013 to help determine which files need to be upgraded. The MD5 algorithm used by this API is not cryptographically strong enough to be used to detect malicious or safe files.

    At Wordfence we use SHA-2 and this is one of the reasons we have created our own API endpoint that we use for malware scanning. Doing this allows us to use a cryptographically strong hash function to ensure that malware can’t evade detection by exploiting weak hash algorithms. We have been using SHA-2 since 2012, when the very first version of Wordfence was released as version 1.1.

    Last week a security researcher demonstrated how it’s possible to create two windows executables that both have the same MD5 hash. This allows an attacker to create one friendly executable and another malicious file that will later replace the friendly file and avoid detection.

    In 2014 Nat McHugh showed how to create two different PHP files and two different image files with the same MD5 hash. This demonstrates the same concept in PHP – that an attacker can create a friendly file which becomes trusted and later replace it with a malicious file that avoids detection by MD5 scanners.

    This research has actually been around for some time now. The attack is called a ‘chosen prefix’ attack on MD5 in the security industry. It first came to light in a paper in 2005 written by Xiaoyun Wang and Hongbo Yu at Shandong University in China in which they refer to it as a modular differential attack on MD5.

    In 2007, Marc Stevens created an open source toolkit as part of his masters thesis which actually exploited this weakness in MD5. These tools are what were used by the researchers above to create different files with identical MD5 hashes.

    This research demonstrates that it’s already possible for an attacker to exploit MD5 to provide a safe file and later replace it with a malicious file that will avoid detection by scanners using MD5. It may soon be possible to create a malicious file that shares the same MD5 hash as a legitimate WordPress core file. For this reason it is important that malware scanners avoid MD5 and use strong cryptographic hash functions to verify file integrity.

    What to do about this

    The goal of today’s blog post is to encourage two things:

    1. If you are a customer of a security product, make sure your product is using SHA-2 or another secure hashing algorithm for malware scanning and other checks. If a product uses MD5, it risks being fooled into thinking a file is safe when it is dangerous.
    2. If you are a security vendor and have not already switched to SHA-2 or a secure hashing algorithm, it’s time to do so now in the interests of your customer’s security.

    As always I’m happy to respond to questions and comments below.

    Mark Maunder – Wordfence Founder/CEO.

    Footnotes:

    You can learn more about hashing, how it is used for passwords and how to crack passwords using consumer GPU hardware by visiting our Password Authentication and Password Cracking article in the Wordfence Learning Center.

    The post Avoid Malware Scanners That Use Insecure Hashing appeared first on Wordfence.

  • Hacking 27% of the Web via WordPress Auto-Update

    At Wordfence, we continually look for security vulnerabilities in the third party plugins and themes that are widely used by the WordPress community. In addition to this research, we regularly examine WordPress core and the related wordpress.org systems. Recently we discovered a major vulnerability that could have caused a mass compromise of the majority of WordPress sites.

    The vulnerability we describe below may have allowed an attacker to use the WordPress auto-update function, which is turned on by default, to deploy malware to up to 27% of the Web at once.

    Choosing the most damaging target to attack

    The server api.wordpress.org (or servers) has an important role in the WordPress ecosystem: it releases automatic updates for WordPress websites. Every WordPress installation makes a request to this server about once an hour to check for plugin, theme, or WordPress core updates. The response from this server contains information about any newer versions that may be available, including if the plugin, theme or core needs to be updated automatically. It also includes a URL to download and install the updated software.

    api-normal

    Compromising this server could allow an attacker to supply their own URL to download and install software to WordPress websites, automatically. This provides a way for an attacker to mass-compromise WordPress websites through the auto-update mechanism supplied by api.wordpress.org. This is all possible because WordPress itself provides no signature verification of the software being installed. It will trust any URL and any package that is supplied by api.wordpress.org.

    api-compromised

    WordPress powers approximately 27% of all websites on the Internet. According to the WordPress documentation: “By default, every site has automatic updates enabled for minor core releases and translation files.”. By compromising api.wordpress.org, an attacker could conceivably compromise more than a quarter of the websites worldwide in one stroke.

    Below we describe the technical details of a serious security vulnerability that we uncovered earlier this year that could compromise api.wordpress.org. We reported this vulnerability to the WordPress team via HackerOne. They fixed the vulnerability within a few hours of acknowledging the report. They have also awarded Wordfence lead developer Matt Barry a bounty for discovering and reporting it.

    Technical Details of the api.wordpress.org vulnerability

    api.wordpress.org has a GitHub webhook that allows WordPress core developers to sync their code to the wordpress.org SVN repository. This allows them to use GitHub as their source code repository. Then, when they commit a change to GitHub it will reach out and hit a URL on api.wordpress.org which then triggers a process on api.wordpress.org that brings down the latest code that was just added to GitHub.

    The URL that GitHub contacts on api.wordpress.org is called a ‘webhook’ and is written in PHP. The PHP for this webhook is open source and can be found in this repository. We analyzed this code and found a vulnerability that could allow an attacker to execute their own code on api.wordpress.org and gain access to api.wordpress.org. This is called a remote code execution vulnerability or RCE.

    When a request arrives at api.wordpress.org, presumably from GitHub, the api.wordpress.org webhook verifies that it is in fact GitHub making the request by using a shared secret and hashing algorithm. The way this works is that, as GitHub is about to send JSON data, it combines the data it’s about to send with a secret value that has been pre-shared with api.wordpress.org. It then hashes the combination and it sends that hash along with the JSON data to api.wordpress.org.

    When api.wordpress.org receives the request, it takes the JSON data, also combines it with the shared secret and computes a hash of its own. If its hash matches the hash that GitHub just sent, then GitHub must know the shared secret and that proves that GitHub is allowed to make the request it’s making.

    GitHub uses SHA1 to generate the hash and supplies the signature in a header: X-Hub-Signature: sha1={hash}. The webhook extracts both the algorithm, in this case ‘sha1’, and the hash to verify the signature. The vulnerability here lies in the fact the code will use the hash function supplied by the client, normally github. That means that, whether it’s GitHub or an attacker hitting the webhook, they get to specify which hashing algorithm is used to verify the message authenticity, as you can see in the code below.

    function verify_github_signature() {
    	if ( empty( $_SERVER['HTTP_X_HUB_SIGNATURE'] ) )
    		return false;
    
    	list( $algo, $hash ) = explode( '=', $_SERVER['HTTP_X_HUB_SIGNATURE'], 2 );
    
    	// Todo? Doesn't handle standard $_POST, only application/json
    	$hmac = hash_hmac( $algo, file_get_contents('php://input' ), FEATURE_PLUGIN_GH_SYNC_SECRET );
    
    	return $hash === $hmac;
    }
    

    If we can bypass the webhook authentication mechanism, there is a POST parameter for the GitHub project URL that is passed unescaped to shell_exec which allows us to execute shell commands on api.wordpress.org. This allows us to compromise the server. You can see the shell_exec call in the code sample below:

    $repo_name = $_POST['repository']['full_name'];
    $repo_url  = $_POST['repository']['git_url'];
    
    if ( ! $this->verify_valid_plugin( $repo_name ) ) {
    	die( 'Sorry, This Github repo is not configured for WordPress.org Plugins SVN Github Sync. Please contact us.' );
    }
    
    $svn_directory = $this->whitelisted_repos[ $repo_name ];
    
    $this->process_github_to_svn( $repo_url, $svn_directory );
    
    function process_github_to_svn( $github_url, $svn_directory ) {
    
    	putenv( 'PHP_SVN_USER=' . FEATURE_PLUGIN_GH_SYNC_USER );
    	putenv( 'PHP_SVN_PASSWORD=' . FEATURE_PLUGIN_GH_SYNC_PASS );
    
    	echo shell_exec( __DIR__ . "/feature-plugins.sh $github_url $svn_directory 2>&1" );
    
    	putenv( 'PHP_SVN_USER' );
    	putenv( 'PHP_SVN_PASSWORD' );
    }
    

    The challenge here is to somehow fool the webhook into thinking that we know the shared secret that GitHub knows. That means that we need to send a hash with our message that ‘checks out’. In other words it appears to be a hash of the message we’re sending and the secret value that only api.wordpress.org and GitHub know – the shared secret.

    As we pointed out above, the webhook lets us choose our own hashing algorithm. PHP provides a number of non-cryptographically secure hashing functions like crc32, fnv32 and adler32, which generate a 32bit hash vs the expected 160 bit hash generated by SHA1. These hashing functions are checksums which are designed to catch data transmission errors and be highly performant with large inputs. They are not designed to provide security.

    If we can find a weak enough hashing algorithm, it lets us brute force attack the webhook. We just need to send a series of hashes, trying to guess the hash value of the shared secret and the data we’re sending, until we get it right and api.wordpress.org allows the request.

    By using any one of these weak hashing algorithms, we reduce the brute force space, or number of guesses we have to make, significantly (2^160 down to 2^32). But it is still not feasible to launch this attack over the network to api.wordpress.org without it being incredibly noisy as we make a large number of guesses.

    Of these weak algorithms, the one that stood out the most was adler32, which is actually two 16 bit hashing functions with their outputs concatenated together. It also has a known implementation flaw when used on short messages. When combined with PHP’s hash_hmac function, the second round of hashing will only ever pass 68 bytes of data to adler32 which severely limits the amount of possible hashes that can be generated given any input at the start of the hashing process.

    Not only are the total number of hashes limited, but there’s also significant non-uniformity in the hash space. This results in many hashes being the same even though they were supplied with different inputs. The distribution of possible checksum values are similar to rolling dice where 7 is the most likely outcome (the median value), and the probability of rolling any value in that range would work its way out from the median value (6 and 8 would have the next highest probability, and on it goes to 2 and 12).

    The proof of concept supplied in the report utilizes the non-uniformity by creating a profile of most common significant bytes in each 16 bit hash generated. Using this, we were able to reduce the amount of requests from 2^32 to approximately 100,000 to 400,000 based on our tests with randomly generated keys.

    This is a far more manageable number of guesses that we would need to send to the webhook on api.wordpress.org which could be made over the course of a few hours. Once the webhook allows the request, the attack executes a shell command on api.wordpress.org which gives us access to the underlying operating system and api.wordpress.org is compromised.

    From there an attacker could conceivably create their own update for all WordPress websites and distribute a backdoor and other malicious code to more than one quarter of the Web. They would also be able to disable subsequent auto-updates so that the WordPress team would lose the ability to deploy a fix to affected websites.

    The CVSS vulnerability score for this vulnerability is:

    Are You at Risk?

    We confidentially reported this vulnerability on September 2nd to Automattic and they pushed a fix to the code repository on September 7th. Presumably the same fix had been deployed to production before then.

    We still consider api.wordpress.org a single point of failure when distributing WordPress core, plugins and theme updates. We have made attempts to start a conversation with members of Automattic’s security team about improving the security posture of the automatic update system, but we have not yet received a response.

    Starting three years ago, there has been some discussion about providing an authentication mechanism for the code that the WordPress servers distribute. So far there has been no progress on this. The issue came up again this week on a security mailing list.

    Should api.wordpress.org or a similarly critical server be compromised, it is possible that an attacker could compromise WordPress sites en-masse across the web in a very short amount of time and simultaneously remove the ability for the WordPress/Automattic security team to push out a security update or a fix.

    This would clearly be a disaster for the Web and the online community. The phrase “too big to fail” comes to mind. With 27% market share, WordPress powers over a quarter of all websites. A failure of this magnitude would be catastrophic for the Web. Furthermore, it would provide a massive attack platform for the attacker, who would control millions of web hosting accounts from which they could launch further attacks.

    Disclosure Timeline

    • 2016-09-02 21:08 (-0400) – Initial report submitted to Automattic via Hackerone.
    • 2016-09-06 19:48 (-0400) – Automattic acknowledges the report.
    • 2016-09-07 02:02 (-0400) – A fix for the vulnerability is pushed to the repository.
    • 2016-09-21 17:17 (-0400) – The report is resolved and closed.
    • 2016-10-29 05:21 (-0400) – Bounty is awarded by Automattic.
    • 2016-11-22 – Public disclosure.

    Credits

    We would like to congratulate Lead Wordfence Developer Matt Barry for this spectacular research. Matt tackled this project in his spare time and handled the disclosure of this via HackerOne to the Automattic team. Matt is also the technical author of this post with some minor assistance from the rest of the Wordfence team.

    The post Hacking 27% of the Web via WordPress Auto-Update appeared first on Wordfence.

  • Revslider, MailPoet, GravityForms Exploits Bypass Cloudflare WAF

    Last week we blogged about the advantages of endpoint security over a cloud firewall solution. We wrote about how cloud WAFs can be bypassed. We also blogged about how it is more challenging for a cloud WAF provider to write complex firewall rules because cloud WAFs don’t know if a user is signed in or what their access level is.

    Part of the forensic research we do at Wordfence involves analyzing attack data we receive from sites that use Wordfence. We use a scaleable database cluster to perform big data analysis on WordPress attack data. We identified many attacks that were bypassing Cloudflare and being blocked by Wordfence. So we dug a little deeper.

    Cloudflare Pro provides a web application firewall that is designed to perform a similar function to the Wordfence WAF. We are in that sense, direct competitors. We wanted to evaluate the Cloudflare WAF and to get access to it you have to get a paid ‘Pro’ account for $240 per year or $20/month. So we bought and paid for the Cloudflare WAF.

    The default Cloudflare WAF sensitivity setting is ‘Medium’. We increased the sensitivity setting to ‘High’.  That is the highest sensitivity setting before your users have to get through a captcha to access your site.

    We also enabled every rule we could find in the Cloudflare WAF. That includes 11 rules in the “Cloudflare ruleset” and 20 rules in the “OWASP ModSecurity Core Rule Set”. We also put that ruleset on “High” sensitivity. We also enabled the “browser integrity check”.

    We enabled absolutely everything we could find and put everything on “High” sensitivity.

    We then confirmed that we could bypass the Cloudflare Pro WAF with the following attacks using no special techniques:

    • Revolution Slider – We gained a remote shell. This went through completely undetected.
    • MailPoet – We gained a remote shell. Also completely undetected.
    • Gravity Forms – We gained a remote shell. Also completely undetected.
    • Timthumb – Gained a remote shell using the .phtml form of the attack. Detected but not blocked.

    These results were surprising. We used off-the-shelf hacker scripts without any special modifications. It’s well known that RevSlider, Gravity Forms and Timthumb are three of the leading causes of hacked websites. According to one report, 25% of hacked sites are hacked through one of these three WordPress exploits. Cloudflare Pro at $240/year with a ‘High’ sensitivity setting and all rules enabled allows these attacks through.

    The free version of Wordfence blocks all of these attacks.

    Why do these well known attacks bypass Cloudflare?

    We don’t know why Cloudflare allows these attacks through, as surprising as it is, but I’d like to share a few observations. Firstly, Cloudflare is not WordPress specific. They are trying to be a firewall for all web platforms which is a difficult, perhaps impossible, challenge. Wordfence is WordPress specific, so we are able to tailor our rules for attacks that we know target that platform specifically.

    Cloudflare is a ‘cloud WAF’ and, as we have pointed out previously, because their servers and rules run out on the Internet, they don’t have access to authentication and authorization data to make their rule decisions. Wordfence on the other hand knows if a user is signed in, what their identity is and what their access level is, so we are able to write more complex and stricter rules.

    Demonstration

    We have created a video demonstrating Cloudflare being bypassed by these exploits. In the first test we have a site that is filtering traffic through Cloudflare Pro with all rules enabled and on a ‘High’ sensitivity setting. In this test we also enable the free version of Wordfence on our target site. This allows us to see the attacks bypassing Cloudflare and being blocked by Wordfence.

    cfwf2

    In the next test, we remove Wordfence completely from the target site and demonstrate how, without it, the site is exploited by an attacker, completely bypassing the Cloudflare Pro WAF on ‘High’ sensitivity.

     

    cfexploited1

     

     

    The following is a video demonstration of this attack. In it we use two Linode servers, one as our attacker and another as our ‘Victim’. We use a Cloudflare Pro account on ‘High’ sensitivity with all rules enabled. We also download and configure the free version of Wordfence for the first part of the demo, and then remove it.

    Why does this matter?

    The free version of Wordfence blocks all of these attacks. They are what we consider “the basics” when it comes to WordPress security. If you pay us $99 a year you also get a real-time feed of emerging threats. Cloudflare are selling a web application firewall for $240 per year that allows through the best known and most dangerous WordPress attacks.

    That means you can get better protection by using our free product than by using the $240/year Pro Cloudflare WAF. Then, if you choose to upgrade to our paid option, you know you’re protected against the newest emerging threats against WordPress.

    It’s important to us that our customers know this. We feel we would be doing you a disservice if we didn’t share this comparative data. If you want to protect your WordPress site from a hack, you need a WordPress specific firewall that runs on the endpoint and protects you against “the basics” and also against emerging threats.

    Conclusion and Technical Notes

    We have provided a public Github repository that include tcpflow packet captures from the perspective of the attacker and from the perspective of the victim. The repository also includes the four exploits we used. Note that you will need to edit the exploit files to add in your own target hostnames. In the case of Timthumb you will also need to add a server from which timthumb can download an attack shell.

    We have not included the vulnerable plugins or theme. However, we are supplying their versions. They are: Gravity Forms 1.8.1, MailPoet 2.6.4, Revslider 2.3.91 and Timthumb version 1.12. You can find these in the WordPress.org repository, in other repositories on github and elsewhere.

    If you do download and test one of these vulnerable products and find you’re not able to exploit them, you may be using an old version that has a back-ported security fix. So please note that you need to find both a vulnerable ‘version’ of the product and one that has not had a back-ported security fix applied.

    As always I welcome your comments and questions.

    Trademark notice: All product names, logos, and brands are property of their respective owners. All company, product and service names used in this website are for identification purposes only. Use of these names, logos, and brands does not imply endorsement.

    The post Revslider, MailPoet, GravityForms Exploits Bypass Cloudflare WAF appeared first on Wordfence.

  • We are removing Falcon Cache from Wordfence. Here’s what you need to know.

    Version 6.2.1 of Wordfence was just released and you may have noticed in the changelog that we’ve announced that we will be removing Falcon from Wordfence. I thought I’d go into some detail about why we made this decision.

    When we launched Falcon, the caching feature that is part of Wordfence, it was a ground breaking caching engine that was faster than any cache available for certain user configurations. But caching is a complex beast and we have learned a lot during the past few years. When Falcon launched, we were just a team of two people. Wordfence is now a team of 23 people and our area of specialization is high performance security. Not caching.

    During the past few months we have been working with hosting providers and what we’ve learned is that, for certain hosting provider configurations, Falcon cache actually can slow things down slightly and it’s preferable for the customer to instead rely on a much faster front-end cache that the host provides. The reason for this is because some hosts use slow local disk for their WordPress hosting but use very fast front-end caches. In those configurations, Falcon generates unwanted disk IO trying to outperform the front end cache, which it will never do.

    Some of the hosting providers we’ve worked with have told us that they want the awesome security that Wordfence providers, but they don’t want users to slow down their customer sites by enabling Falcon. Remember, this only applies to certain hosts. But this is one of the reasons we have chosen to remove the feature.

    The second, and main reason is that Wordfence is really all about security. It’s what we know and what we’re incredibly good at. We have a sizable team now of forensic experts, analysts, senior developers, operations people and customer service experts and we’re all completely focused on securing WordPress websites. We’d like to stay 100% focused on that and not be distracted by trying to support a feature that is outside our area of focus.

    And so with that in mind, we’d like to announce that Wordfence 6.2.1, released yesterday, is phasing out Falcon cache. For this release, if you’re using Falcon, you will receive a notice that you should manually disable it. If you don’t have Falcon enabled or have a newly installed Wordfence installation, you will notice that the Falcon menu has been removed for you.

    Our QA team has worked through many scenarios to ensure that this transition is painless for the relatively small percentage of users using Falcon. An upcoming release will disable Falcon and remove the feature if you haven’t already manually disabled Falcon. We recommend that you remove it manually because an attended installation is always safer than having things happen automatically.

    We currently have no timeline for when Falcon will be completely removed, but it will be relatively soon and we recommend you take action now. We won’t completely remove Falcon for at least another 4 weeks.

    If you’re looking for a replacement WordPress caching plugin, you can find a few recommendations with benchmarks on this page. But I strongly recommend you first consult your hosting provider because what we’ve found is that in some cases, it’s better to rely on the caching that your host already provides.

    Going forward, Wordfence will be 100% focused on security and in particular providing the best firewall and malware scanner available for WordPress.

    Minor update: As a helpful user on reddit pointed out, it’s unclear in the post above if we’re also removing the ‘basic’ cache. Yes, we’re removing what we refer to as ‘Falcon’ cache which is the .htaccess based caching engine and we’re also removing the ‘Basic’ cache which is the PHP based caching engine. If that’s not clear or if you have any more questions, please post in the comments. Thanks. ~Mark.

    The post We are removing Falcon Cache from Wordfence. Here’s what you need to know. appeared first on Wordfence.