Security
Headlines
HeadlinesLatestCVEs

Headline

CVE-2023-5089: Discovering Hidden wp-admin.php Page URLs in Wordpress Using GravityForms

The Defender Security WordPress plugin before 4.1.0 does not prevent redirects to the login page via the auth_redirect WordPress function, allowing an unauthenticated visitor to access the login page, even when the hide login page functionality of the plugin is enabled.

CVE
#vulnerability#web#wordpress#php#perl#auth

Hiding the default login page for WordPress sites is a common practice to help mitigate brute-force attacks by unwanted attackers. By changing the directory to a secret location only known to you, and redirecting all other login page directories to a 404 page, you can prevent hackers from creating unnecessary traffic trying to guess valid credentials and ultimately takeover your WordPress installation.

This is typically accomplished with security plugins in WordPress or web server ACL rules. There are a couple you can choose from, but they all work more or less the same. However, the effectiveness of this strategy relies on the user rather than the plugin they choose, as there is still a chance that the correct directory could be discovered through brute force.

Locating the Login URL

During a recent pentest, unusual interactions were observed between the GravityForms plugin and the WordPress login page. While testing for common vulnerabilities in GravityForms, an administrative login page was discovered that was previously inaccessible due to the use of wp-defender. It was determined that a security plugin was being used to conceal the correct location of the login page, but it was quickly discovered through GravityForms.

By targeting the following endpoint and passing in a random string, GravityForms will prompt you to authenticate first. This results in the unauthenticated user being redirected to, in this case, the obscured administrative login page name “hiddenpage”:https://target.com/?gf_page=randomstring

By making a request and passing in a random string to gf_page, GravityForms will check if the user is authenticated or not. If the user is not logged in, they will get automatically redirected to authenticate.

The behavior so far is normal. However, the expected behavior when the login page is hidden, is for the request to throw a 404 or other error, similar to what occurs when attempting to access wp-admin.php normally.

Security Plugins Mishandling Interactions

During testing, it appeared that the security plugin was not handling this interaction correctly, allowing us to bypass the security measures altogether. In fact, after further research and testing other plugins that redirect or hide the login page, none of them handled this scenario properly when Gravity Forms was installed.

The following plugins were tested on a WordPress Sandbox site one at a time with the latest version of GravityForms at the time of writing (Version 2.7.1). For brevity, only the results of two of these plugins will be shown, WPS Hide Login and Defender.

  • WPS Hide Login
  • Defender/WP-Defender
  • iThemes Security
  • WP Hide & Security Enhancer
  • Hide My WP Ghost

WPS Hide Login

In settings, the default login page has been changed to “wps-hide-login-page” and it has been ensured that requests to /login, /wp-login.php , and /wp-admin.php are redirected to the default 404 page.

The expected behavior can be viewed below:

Normal Behavior

This time, however, if the gf_page function is called with a random string, the user will be redirected to the login page located at /wps-hide-login-page.

gf_page bypass

Defender

Defender works more or less the same but will return a 500 error stating the feature is forbidden for security reasons.

Normal Behavior

You can also set it to redirect to a custom URL to mess with any would-be hackers.

Redirect Enabled

Despite this, if gf_page is requested, the website will still redirect the user to the new hidden page located at /wp-defender-secret-login-page, effectively ignoring the prior redirect setting.

gf_page bypass

This behavior is only possible because attackers can call the gf_page function directly without authentication. However, it is the responsibility of security plugins to ensure this behavior is handled correctly. It is difficult to determine who is responsible for remedying this behavior. Nevertheless, none of the tested plugins could prevent the disclosure of the login page by GravityForms.

WPScan’s Point of View

After informing WPScan about this behavior, they believe that the issue lies not with GravityForms, but with every other security plugin stating the following:

“This issue should be considered a bug in the plugins which attempt to hide the login URL (such as WPS Hide Login) as they may need to implement special handling for the usage of the auth_redirect function.”

They also stated:

“WordPress does not consider the location of the login page to be sensitive information”

This message is somewhat confusing because of the many security plugins designed to hide this information, as well as CVEs created in the past due to certain plugins revealing the login page (such as CVE-2019-15823 and CVE-2021-24917). Until this issue is fixed, if you find the default login page on a WordPress site is missing, see if they have GravityForms installed first.

Conclusion

The interaction between GravityForms and popular WordPress security login plugins exposes a vulnerability that allows attackers to bypass security measures and access the hidden login page. While this may not pose a significant security risk, it underscores the importance of adopting a comprehensive approach to WordPress security.

To mitigate brute force attacks and other threats, website administrators should consider implementing additional measures, such as two-factor authentication or IP whitelisting, to ensure the highest level of protection for their WordPress installations.

CVE: Latest News

CVE-2023-50976: Transactions API Authorization by oleiman · Pull Request #14969 · redpanda-data/redpanda
CVE-2023-6905
CVE-2023-6903
CVE-2023-6904
CVE-2023-3907