Threaded Race Condition in Authentication Allows Bypass of Authentication Attempt Restrictions in zammad/zammad
Reported on
Jun 27th 2022
Description
A threaded race condition exists in how the application handles authentication attempts in the application. The application recognizes and protects against single-threaded attempts with a five-attempt lockout function. By increasing threads in an authentication brute force attack it is possible to exponentially increase the number of allowed attempts without a lockout. Tester was able to increase attempts by a factor of 40 (5 attempts times 40 threads). Additional thread counts were inconsistent, but in one testing scenario the tester was able to find a valid authentication attempt at number 499 (at the highest).
CVSS - AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Proof of Concept
Authentication Brute Force PoC - This is the Burp Intruder payload
POST /api/v1/signin HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:101.0) Gecko/20100101 Firefox/101.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost:8080/
Content-Type: application/json
X-Requested-With: XMLHttpRequest
X-CSRF-Token: jA18mk7hOGTpj+qgmFfs0z7Mx/EtYoeliFT9nphfSQ44r7+ETthl4fJMvNnp7HQeMYYYXd5Ws34mSdltjpvRtg==
Content-Length: 88
Origin: http://localhost:8080
DNT: 1
Connection: close
Cookie: _zammad_session_a138cfd0f37=d7a577940ea805561fe5f8ad93998bd3
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
{"username":"lowpriv@mayorsec.com","password":"PassworD123!","fingerprint":"-781305443"}
Impact
The immediate impact is the possibility for an attacker to make up to 200 consistent attempts at authenticating to a user's account with an unknown password. A skilled attacker with a known user list and common password list would be able to make hundreds of attempts against the application. If an attacker can identify an account password in those 200 attempts per account, they would gain full access to the user account.
References
@admin FYI on the second report. Can we consider CVE status for both please? Thank you.
Of course :) Just for reference, @maintainer, you are able to opt-in to a CVE by adjusting the CVE to "Yes" at the top right of the report.
@dievus we decided to try and fix the brute force prevention issue by proper DB synchronization rather than rack_attack.
To verify, would you be able to test the changes? Just exchange the valid? method in lib/auth.rb with the following code:
def valid?
validated = auth_user&.user&.with_lock do
if auth_user.can_login? && backends.valid?
auth_user.update_last_login
true
else
auth_user.increase_login_failed if increase_login_failed_attempts
false
end
end
avoid_brute_force_attack if !validated
validated == true
end
That should prevent the issue (after server restart, of course) no matter how much concurrency is involved. I would highly appreciate your feedback on this.
Of course, @maintainer. I'll test it sometime today/tonight. In the meantime, can you validate both reports and apply CVEs to them? Thanks!
@maintainer, I've updated the code in the container appropriately. Anything after request #9, regardless of the threads, appears to be locked out. Anything up to request #9 is still making it through. This is consistent.
Thank you @maintainer. Please keep me updated with posting of the CVE.
Hi @maintainer, is there any update to the CVE on this finding and the other one that I submitted?
Thank you.
We received CVE-2022-35490 from MITRE to identify this issue. I'm not able to update this report any more. Could @admin or @researcher please change it?