Issue E. Parallel Requests Bypass Exponentially Increasing Login Delay #825
Labels
Milestone
Comments
|
To be managed as part of Flood Resiliency Project https://github.com/globaleaks/globaleaks/issues?labels=Flood-Resiliency-Protection&milestone=&page=1&state=open |
|
Proposal: apply token also to the login, therefore, if too many attempt are triggered, protections [1] came in place. [1], delay, hashcash, captcha(s) |
This was referenced May 5, 2015
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Reported: 2014-01-30
Synopsis: GlobaLeaks implements an exponentially-increasing delay when a login fails. An attacker can get around this by sending requests in parallel.
Impact: An attacker can perform online login guessing attacks faster than expected.
Attack Resources: To perform this attack, the attacker must be able to establish multiple connections to
the GlobaLeaks web server in parallel.
Feasibility: This issue can be exploited by simply making requests in parallel rather than in series.
Verification: Verified by source code inspection and testing with the script provided in Appendix C. Script for Issue E. When requests are made sequentially, they are held up. When made in parallel, they aren't.
Vulnerability Description:
The login delay is implemented in security_sleep() in globaleaks/handlers/authentication.py. It is done by calling callLater(), which will freeze the current connection, but will not prevent the attacker from opening a new one.
The current defence only becomes effective when the attacker has exhausted all of the concurrent connections that the GlobaLeaks can accept, and GlobaLeaks cannot accept any more concurrent connections, i.e. it is effectively under denial of service.
Mitigation:
To mitigate this issue, GlobaLeaks Node administrators should monitor the rate of login requests to detect an attack and respond by either shutting down the server or using a firewall to to rate limit the attacker. To monitor the number of concurrent connections, the netstat -ptan command can be used.
Remediation:
It is difficult to find a long-term solution to this problem, since all of the obvious solutions make GlobaLeaks more vulnerable to denial of service attacks. A possible solution might involve requiring the client to solve a computationally- and memory-hard proof of work challenge for each authentication request. We leave this for future work.
Status: Confirmed.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: