# Authentication

### Account Registration



Using specific mail domain

Creating email with more that 200 character before the `@` symbol is then truncated to 255 characters. This _**identify**_ the vulnerability in the account registration page logic **flaw**. In the email below the `m` at the end of `@dontwannacry.com` is character 255 exactly.

<pre><code><strong>very-long-strings-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-strings@dontwannacry.com.exploit-0a59009f04dfcc6882ee1431018e0043.exploit-server.net
</strong></code></pre>





### Bypass Brute IP brute force block

1. Click **Resource pool** to open the **Resource pool** side panel, then add the attack to a resource pool with **Maximum concurrent requests** set to `1`. By only sending one request at a time, you can ensure that your login attempts are sent to the server in the correct order.
2. Click **Payloads** to open the **Payloads** side panel, then select position `1` from the **Payload position** drop-down list. Add a list of payloads that alternates between your username and `carlos`. Make sure that your username is first and that `carlos` is repeated at least 100 times.
3. Edit the list of candidate passwords and add your own password before each one. Make sure that your password is aligned with your username in the other list.
4. Select position `2` from the **Payload position** drop-down list, then add the password list. Start the attack.
5. When the attack finishes, filter the results to hide responses with a `200` status code. Sort the remaining results by username. There should only be a single `302` response for requests with the username `carlos`. Make a note of the password from the **Payload 2** column.



Password reset&#x20;

1.  &#x20;in Burp Repeater and add the `X-Forwarded-Host` header with your exploit server URL:

    `X-Forwarded-Host: YOUR-EXPLOIT-SERVER-ID.exploit-server.net`
2. Change the `username` parameter to `carlos` and send the request.
3. Go to the exploit server and open the access log. You should see a `GET /forgot-password` request, which contains the victim's token as a query parameter. Make a note of this token.
4. Go to the URL with password change code





#### Auth Token bypass Macro

> If the authentication login is protected against brute force by using random token that is used on every login POST, a Burp Macro can be used to bypass protection.



> Create Burp Macro

1. Open Proxy settings and select **sessions** under Project choices.
2. Scroll down to `Macros`, and add new macro.
3. Select **request** from the list to use for the value to be used.
4. click `Configure item` and add custom parameter location to extract.
5. Click **OK** to return to Sessions under Project choices.
6. Add a Session handling **rule**, and the editor dialogue opens.
7. In the dialogue, go to the "Scope" tab.
8. Under scope for the session handling rule editor, **check** Target, Intruder, and Repeater.
9. Still under "URL Scope", select `Include all URLs`.
10. Close Settings.



## Brute Force



### Stay-login cookie brute force



1. Logout as current user.
2. Send the most recent GET /my-account request to Burp Intruder.
3. Select the cookie: `stay-logged-in` as injection position.
4. Hash: `MD5`
5. Add prefix: `carlos:`
6. Encode: `Base64-encode`
7. Add **GREP** under settings tab, to check for the string in the response `Update email` indicating successfully logged in attack.



### New password error flow

Notice the behavior when you enter the wrong current password. If the two entries for the new password match, the account is locked. However, if you enter two different new passwords, an error message simply states `Current password is incorrect`. If you enter a valid current password, but two different new passwords, the message says `New passwords do not match`

1. Enter your correct current password and two new passwords that do not match. Send this `POST /my-account/change-password` request to Burp Intruder.
2.  In Burp Intruder, change the `username` parameter to `carlos` and add a payload position to the `current-password` parameter. Make sure that the new password parameters are set to two different values. For example:

    `username=carlos&current-password=§incorrect-password§&new-password-1=123&new-password-2=abc`
3. In the **Payloads** side panel, enter the list of passwords as the payload set.



\
**Response time enumerate for creds**

Intruder with brute force username and very long password, if response is longer than the user is exist.

Than use Inturder again to attack password.

If IP is blocked use second payload with X-Forwarded-For header

```
X-Forwarded-For: 12.13.14.15
```





### Brute force diffrent response

> _**Identify**_ that the login page & password reset is not protected by brute force attack, and no IP block or time-out enforced for invalid username or password.

> Tip for the BSCP Exam, there is sometimes another user with weak password that can be brute forced. Carlos is not always the account to target to give a foothold access in stage 1.
>
> Notice on the Intruder attack column for the GREP value, `Invalid username or password.` the one response message for a failed username attack do not contain full stop period at the end. Repeat the attack with this _**identified**_ username, and **Sniper** attack the password field to _**identify**_ `302` response for valid login.

Another scenario to identify valid username on the WEB APP is to provide list of usernames on login and one invalid password value. In the Intruder attack results one response will contain message `Incorrect password`.\
Intruder attack injection position, `username=§invalid-username§&password=SomeStupidLongCrazyWrongSecretPassword123456789`.





### 2FA bypass

1. change verify value to change username we want to get code for
2. intruder change post request for login2 parameter verify
3. brute force 2fa





## Password Reset

1. password reset functionality still works even if you delete the value of the `temp-forgot-password-token` parameter in both the URL and request body
2. &#x20;if you remove the `current-password` parameter entirely, you are able to successfully change your password without providing your current one





