Hi I hope you all are well I have found that there is no rate limit on this login page https://odkcentral.pps.wur.nl/#/login?next=/
Weakness:
Improper Restriction of Authentication Attempts
Steps to reproduce:
1 Go to https://odkcentral.pps.wur.nl/#/login?next=/
2 Enter the victim's email and a random password
3 Click on login and capture the request with burp
4 Now using burp intruder Bruteforce victim's password
5 You will not get any 429 responses which mean there is no rate limit
Impact:
An attack can brute force victim's password and can gain access to it
For fix: Add proper rate limit or use CAPTCHA verification
We do not yet have an ETA. We'll update the issue once we do.
As a workaround, you can reduce the attack surface by restricting web user logins to specific IPs. Modify your files/nginx/odk.conf.template to look like this.
server {
...
location /- {
proxy_pass http://enketo:8005/-;
proxy_redirect off;
proxy_set_header Host $host;
}
# matches app user endpoints
location ~ ^/v\d/(test|key)/.+/projects/\d+/(submission|formList|forms) {
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://service:8383;
proxy_redirect off;
set $max_chunk_size 16384;
set $max_body_size 134217728;
rewrite_by_lua_file inflate_body.lua;
proxy_request_buffering on;
proxy_buffering off;
proxy_read_timeout 2m;
}
# matches web user endpoints
location ~ ^/v\d {
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://service:8383;
proxy_redirect off;
set $max_chunk_size 16384;
set $max_body_size 134217728;
rewrite_by_lua_file inflate_body.lua;
proxy_request_buffering on;
proxy_buffering off;
proxy_read_timeout 2m;
# allow/deny ips
allow 172.18.0.1; # customize based on installed network interface
allow 127.0.0.1; # allow localhost connections
allow 1.2.3.4; # external example 1
allow 4.5.6.7; # external example 2
deny all; # deny everything else
}
...
}
Thanks for bringing this up. In general, if you believe there is a security-related issue in ODK tools, please do use the vulnerability disclosure process.
While we can provide some ideas and advice on how to run a secure Central deployment, please note that it is the service provider's ultimate responsibility to harden their installation according to their needs. Security is all about tradeoffs and what makes sense in one context on one type of infrastructure may not make sense in another.
There is no HTTP rate limiting, that's correct. However, Central uses bcrypt for password storage which provides its own form of rate limiting. Password validation is limited by the server's CPU. For example, a server with 2 CPUs at about 3GHz can only process about 20 password validation requests per second.
The appeal of bcrypt is that passwords take time to brute force even if hashed passwords are leaked and an attacker has direct access to them. Central requires at least 10 characters in a password.
If you believe you are at particular risk for brute force and denial of service attacks, consider using a service like Cloudflare. They have options for features like managed challenges, an improvement over always showing a CAPTCHA.
The strategy @yanokwa described above can also be a really good one if you know where your traffic is supposed to come from.
If they do believe they can reproduce a brute force attack, please ask them to share with us using the vulnerability disclosure process.
@alxndrsn has been thinking through this with us -- please add anything you think would be valuable to this conversation!
