Online Services

eWorldLinx

Tag: WordPress Security

  • 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.

  • Cloned Spam Sites in Subdirectories

    Cloned Spam Sites in Subdirectories

    Cloned Spam Sites in Subdirectories

    In a recent post, we covered how attackers were abusing server resources to create WordPress sites in subdirectories and distribute spam. By adding a complete WordPress CMS installation into a directory and using the victim’s database structure, attackers were able to inject ads and promote their products – a very bold move.

    This time around, attackers used a different technique and structure to accomplish the same task.

    Infection Patterns

    Instead of adding WordPress subsites and using the local database, they decided to fetch all of the information from external sources under their control.

    Continue reading Cloned Spam Sites in Subdirectories at Sucuri Blog.

  • New XM1RPC SEO Spam and Backdoor Campaign

    New XM1RPC SEO Spam and Backdoor Campaign

    New XM1RPC SEO Spam and Backdoor Campaign

    We have been monitoring a new campaign specifically targeting WordPress sites, using hundreds of them for SEO spam distribution. We call it the XM1RPC campaign due to the common backdoor used across all of the compromised sites.

    The file is named in such a way as to confuse WordPress administrators who are familiar with XML-RPC.  This malware usually infects all sites that share the same FTP account, which means cleaning just one website won’t help, as hackers use the compromised site to reinfect all sites on the server in a matter of minutes.

    Continue reading New XM1RPC SEO Spam and Backdoor Campaign at Sucuri Blog.

  • Surviving Electmageddon: Protecting against a wave of DNS outages

    Two weeks ago, DNS provider Dyn was attacked in a very large DDoS attack. IoT devices were used to send an overwhelming amount of traffic to Dyn’s resolvers which resulted in Dyn effectively being taken offline for hours. This took out Netflix, Paypal, Github, Twitter and many other name brand services.

    The Dyn attack may have been retribution against a researcher from Dyn who collaborated with Brian Krebs – both of whom have been working to expose DDoS-for-hire and DDoS protection rackets. We think this explanation is more likely than it being a ‘state sponsored attack’.

    The Dyn attack was the result of Internet of Things or IoT devices being infected with a botnet. At the time about 500,000 devices were infected and only 10% of them were used in the Dyn attack. The source code for the Mirai botnet that was used in the Dyn attack was released some time before the attack on Dyn and this allowed any attacker to build their own botnet and launch a large DDoS attack on any target.

    Earlier this year, Russian hackers, codenamed ‘Fancy bear’ and ‘Cozy bear’ hacked into the Democratic National Committee which resulted in email leaks. This may have been an attempt to disrupt or influence the US election.

    The US election is on November 8th, less than 1 week from now. Some candidates may benefit if fear, uncertainty and doubt are cast on the election itself or the results. Launching a massive DDoS style attack on DNS providers on November 8th would achieve that objective. It would take many services off-line, including news, exit poll results, official candidate websites, official announcement sources and services we rely on like banking.

    We think that certain nation states may have reason to create this kind of disruption. We also think that malicious individuals with their own agenda may also try to create disruptions on November 8th. The Dyn attack demonstrated that by leveraging IoT devices and the Mirai source code, massive outages can be created by individuals or state actors.

    In light of the above facts and the climate we find ourselves in, we would like to make a recommendation to owners of mission critical websites to help them weather the storm that may arrive on November 8th. We are suggesting a change in DNS configuration that is technically complex and also increases operating costs. We recommend this change for business or mission critical websites who have a technical staff they can call on to help them implement this.

    We recommend that websites set up a secondary DNS provider via a different DNS vendor. By doing this, if your first DNS vendor is attacked, the second one will answer any requests for your domains IP address and your website or service will continue functioning as per normal.

    To do this, you need to have a primary DNS provider that allows “zone transfers”. That means that the primary provider must give you the ability to authorize another DNS provider to copy or replicate all your DNS records from time to time.

    The vendor you choose as a secondary DNS provider must have the ability to act as a secondary where another vendor is the primary. That means it must be able to do zone transfers from your primary DNS provider to replicate your DNS records.

    Wordfence is moving to this configuration over the next few days and we’re implementing it with our current DNS provider, DNSMadeEasy as primary and with Verizon’s Edgecast DNS service as the secondary. We have verified that they can work with this configuration and they will give us the performance our customers expect.

    The diagram below gives you a general idea of how a secondary DNS server keeps your website online if your primary DNS provider is attacked. Customers can’t lookup your website IP address and, rather than your website appearing offline, they are able to resolve your site IP with the secondary DNS server and connect to your website. DNS is more complex than the diagram indicates, but this gives you a general idea of how failover works from primary to secondary during a DDoS attack.

    Using a secondary DNS provider

     

    Finding a cost effective DNS provider that can act as secondary DNS to your primary provider can be a challenge. You may also have to switch primary DNS providers if your primary does not allow zone transfers to a secondary DNS provider. For example, Cloudflare does not appear to allow secondary DNS servers because they don’t allow zone transfers.

    We did an audit of the top 10,000 websites (Source: Alexa), and out of 1832 domains that use Cloudflare, only 3 have secondary DNS configured on another vendor. We think these three are using something other than the standard zone transfer to secondary configuration because Cloudflare technically doesn’t support doing that.

    Using a single DNS provider if you operate a mission critical website creates a single point of failure. As recent history has shown, this can leave you offline during a large DDoS attack. As the old Latin saying goes, if you wish for peace, prepare for war. We recommend mission critical websites make appropriate preparations in case we see a repeat of October 21st – and let’s all hope that November 8th comes and goes peacefully.

    The post Surviving Electmageddon: Protecting against a wave of DNS outages appeared first on Wordfence.