This lab's email change functionality is vulnerable to CSRF.
To solve the lab, use your exploit server to host an HTML page that uses a to change the viewer's email address.
You can log in to your own account using the following credentials: wiener:peter
After logging in with the provided credentials, I intercepted the change email request and sent it to the repeater for further analysis:
I attempted to change the request method to see if it would still go through, but it resulted in the error Method Not Allowed. However, I noticed that if I removed the CSRF token from the request, it was processed successfully. This indicated that the CSRF token is only validated if it is present. Thus, if I can get the victim to submit the change email form without the CSRF token, I could potentially change their email.
To achieve this, I needed a CSRF proof of concept (PoC) without the token. I deleted the csrf parameter from the POST request, and by right-clicking the request and selecting Engagement tools > Generate CSRF PoC, I generated the following HTML:
I modified the email value to a new one to avoid any errors related to reused email addresses. After copying the CSRF PoC, I placed it in my malicious page on the exploit server.
By clicking Store and Deliver exploit to victim, I saw that the lab was solved, confirming the change of the victim's email.