Loading HuntDB...

Rate-limit protection get executed in the last stage of the registration process, allowing enumeration of existing account.

Low
U
Unikrn
Submitted None
Reported by tolo7010

Vulnerability Details

Technical details and impact analysis

Violation of Secure Design Principles
Summary: ====== This may be low risk impact but I need to suggest on improvement on your existing rate-limit protection on the registration page, It is an easy workaround and make the current protection more secure. Description: ======== Unikrn increases the registration security by requiring user to enter a secured password and providing a rate limit on registration, after several attempt the server denies over-registration by returning "Suspicious Activity - Multiple Accounts Detected. Please contact support at [email protected] with further questions". However the rate limit get executed in the last stage of the registration process, still allows the attacker to enumerate account on this page. Steps To Reproduce: ============== 1. Go to https://unikrn.com/ and click "Sign up" 2. Fill in the registration form 3. Upon submitting the form, use proxy (burp) to intercept the connection and send to repeater After the research - except the normal successfully registration, we can categorize the server responses into 3 cases (in the following log from burp repeater): Request/Response Case 1 - Existing email with secured password, the server returns message "Email address already registered": [REQUEST]: POST /apiv1/register HTTP/1.1 Host: unikrn.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0 Accept: application/json, text/plain, */* Accept-Language: en-US,en;q=0.5 Referer: https://unikrn.com/ Content-Type: application/json Application-Version: v3.8.5-28-g570b4be Content-Length: 161 Cookie: [Long Cookie CUT] Connection: close {"email_address":"[email protected]","day":"1","month":"1","year":"1999","state":null,"password":"a12345678","password_confirm":"a12345678","session_id":null} [RESPONSE]: HTTP/1.1 200 OK Date: Thu, 24 Aug 2017 02:38:22 GMT Content-Type: application/json Connection: close Access-Control-Max-Age: 86400 Cache-Control: no-store, no-cache, must-revalidate CI: M-production C-1 V-1.2.0 Content-Security-Policy: default-src 'none'; frame-ancestors 'none' Expires: Thu, 19 Nov 1981 08:52:00 GMT Pragma: no-cache Set-Cookie: CW=ghocb7rti601hf8k9valkk6r0mq2fua2; expires=Sun, 03-Sep-2017 02:38:22 GMT; Max-Age=864000; path=/; domain=.unikrn.com; secure; HttpOnly Strict-Transport-Security: max-age=31536000; includeSubDomains; preload Vary: Accept-Encoding Vary: Origin X-XSS-Protection: 1; mode=block Server: cloudflare-nginx CF-RAY: 3932ef5ab9ab3198-SIN Content-Length: 174 {"error":true,"success":false,"msg":"Email address already registered.","msg_trans":"Email address already registered.","data":null,"code":124,"flds":null,"flds_errors":null} Request/Response Case 2 - Non-Existence email with secured password - after several attempts the server block the registration by sending the message "Suspicious Activity - Multiple Accounts Detected. Please contact support at [email protected] with further questions". [REQUEST - header omitted]: {"email_address":"[email protected]","day":"1","month":"1","year":"1999","state":null,"password":"a12345678","password_confirm":"a12345678","session_id":null} [RESPONSE - header omitted]: {"success": false, "error": true, "msg": "Suspicious Activity - Multiple Accounts Detected. Please contact support at [email protected] with further questions.", "msg_trans": "Suspicious Activity - Multiple Accounts Detected. Please contact support at [email protected] with further questions.", "code": 0, "flds": null, "data": null} Request/Response Case 3 - Non Existence with unsecured password - the server returns a message "Password must be at least 8 characters long and contain one capital letter and one number". [REQUEST - header omitted] {"email_address":"[email protected]","day":"1","month":"1","year":"1999","state":null,"password":"12345678","password_confirm":"12345678","session_id":null} [RESPONSE - header omitted]: {"error":true,"success":false,"msg":"password_invalid","msg_trans":"Password must be at least 8 characters long and contain one capital letter and one number.","data":null,"code":0,"flds":null,"flds_errors":null} Analyze the registration process: ===================== As we can see from the server response, if we provide existing email the server responses "Case 1", if we provide non-existence email the server responses "Case 2" and "Case 3" just by the secured password condition: if we enter secured password Case 2 will be returned, else returns Case 3. From this we can analyze the registration process as: 1. The user fill in the form and send data to the server 2. The server receives request from the client and do the following task in order: - Check if email provided already in the database, if true -> return Case 1 and end the process. (Impact: user enumeration) - Check if password provided are secured (one char+numbers = 8 chars min), if false -> return Case 3 and end the process. (Impact: user enumeration) - [Rate-limit protection] Check if the attempt count reach limit, if true -> return Case 2 and end the process. (Impact: user enumeration) - If the above test pass, register the new user and return successful page. Recommendation: ============ the rate-limit protection must be place on the first stage of processing, this is to disable user enumeration attack: 1. The user fill in the form and send data to the server 2. The server receives request from the client and do the following task in order: - [Rate-limit protection] Check if the attempt count reach limit, if true -> return Case 2 and end the process. (No user enumeration impact: not knowing whether the email are existing or not) - Check if email provided already in the database, if true -> return Case 1 and end the process. - Check if password provided are secured (one char+numbers = 8 chars min), if false -> return Case 3 and end the process. (Impact: user enumeration) - If the above test pass, register the new user and return successful page. Optional improvement: =============== - There is no CSRF token / Captcha in the registration page, this make the enumeration process even easier. As I say this may be low risk, but the fix is easy and increase more security on the existing protection scheme. Regards, Tolo

Report Details

Additional information and metadata

State

Closed

Substate

Resolved

Submitted

Weakness

Violation of Secure Design Principles