Exploiting CSRF as a Privilege escalation vulnerability
Index
Description
· CSRF in GET Requests
· CSRF in POST Requests
Exploit CSRF with Automated POC
Preventive Measures /Mitigation
Description
CSRF is an attack that forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With the help of social engineering (like sending a link via email/chat), an attacker may force the users of a web application to execute actions of the attacker’s choosing.
Example
· Change the email address on their account
· Change their password
The attacker might be able to gain full control over the user’s account. If the compromised user has a privileged role within the application, then the attacker might be able to take full control of all the application’s data and functionality.
NOTE: CSRF mostly happens, when web application cannot make difference whether the request is originated by a legitimate user or a third party user.
CSRF in GET Requests
So, whenever a user edits his profile on Test.com suppose this is the form that submit the user’s value on the server
Code snippet of form
<form action=” update_profile.aspx” method=” get”>
<input type=”text” placeholder=”user email” name=” email”>
<input type=” submit” value=” submit”>
Now there is no token that can verify whether this request is originated from the legit user or a third-party user. An attacker will use this to craft a malicious request look at this snipped.
<form action=”update_profile.aspx?useremail=’malicious@email.com’” method=”get”>
<input type=” submit” type=” hidden” value=” Click here to win $500”>
Now since the attribute of input type is hidden they are not going to render on the page. The user will only see a button stating that he can win $500 by clicking on this.
As soon as the user click on the button, and since he is already authentication on Test web application a request will go to the server to update the email (user have no idea about this). And it will update the attacker’s email on the server instead of user and after that attackers can take over this account by password reset
CSRF in POST Requests
Post requests are equally susceptible to CSRF. An attacker will need to make use of JavaScript to
Submit the POST request.
In the below code snippet, web application not handling CSRF token this URL https://www.evil.com/user/update/email.
So, the hackers crafted an Html form and send it to a server to update the email address of Alex.
HTML Form
<html>
<body>
<form method=” post” id=” newform” action=” https://www.evil.com/user/update/email”>
<input type=” hidden” name=” email” value=” alex@evil.com”>
<input type=” hidden” name=” testing” value=”11111”>
<input type=” submit” name=” submit” value=” click here to win $500”>
</form>
</body>
</html>
When user clicks on the “win $500” button all the values get submitted to the server and since there is not verification the email of attacker gets added in victim account.
Exploit CSRF with Automated POC
In a successful CSRF attack, the attacker causes the victim user to carry out an action unintentionally.
AIM: Our aim is to get account approved by admin.
This is one enterprise web application where CSRF functionality exists. When I clicked on “Private” named tab I got below mentioned screen.
And in Contact tab we have some comment functionality.
So what we will do with it??. We will create automatic CSRF POC on basis of “Profile” tab and submit with comment functionality. First we take a look of profile tab.
It shows us Username as “abc” which I gave at the time of registration but this Status is disabled. So to enable it we took the help of inspect element.
So from above code we removed disabled=”” by implementing this we can see status check box is enabled.
Now we intercept the traffic to check the name and value of the fields. Here I used burp for this.
So now we are going to create automated POC on basis of this request which can work without any user intervention. Automated POC means HTML that causes a javaScript-enabled browser to automatically issue the CSRF request when the page is loaded.
<html>
<head> poc </head>
<body>
<form name=”test” enctype=”multipart/form-data” method=”POST” action=”http://<https://test.com>?action=profile">
<input type=”hidden” name=”username” value=”abc” />
<input type=”hidden” name=”status” value=”on”/>
<input value=”submit”>
</form>
<script>document.test.submit()</script>
</body></html>
- Enctype: This attribute specifies how the form-data should be encoded when submitting it to the server. “Enctype” attribute can only be used only if method=”POST”
So when we see form’s enctype attribute is pulled directly from the intercepted request. We used it in our POC.
2. <script>document.test.submit()</script>: <script>document.<form name>.submit();</script>
This submit function /works as form loaded.
After submitting this POC by comment functionality we got below mentioned message on UI
Now we click on Private tab we got Message of Good Job .
So by using above steps we can get our account approved by the admin.
So to avoid by pass of CSRF we have some mitigation , we will discuss those in next section.
Preventive Measures /mitigation
1 CSRF TOKEN: CSRF token is used to facilitate the CSRF prevention. Thetoken pattern requires the generation of random “challenge” tokens that are associated with the user’s current session. These challenge tokens are inserted within the HTML forms and links associated with sensitive server-side operations. When the user wishes to invoke these sensitive operations, the HTTP request should include this challenge token. It is then the responsibility of the server application to verify the existence and correctness of this token.
CSRF Token should involve the following attributes:
· The CSRF token should be unique for each user session.
· The CSRF token should be a cryptographically random value of the significant length.
· The CSRF token should be cryptographically secure, that is, generated by a strong pseudo-random number generator (PRNG) algorithm.
2 Same Site Cookies: The Same Site cookie attribute can be set on cookies to instruct the browser to disable third-party usage for specific cookies. The Same Site attribute is set by the server when setting the cookie and requests the browser to only send the cookie in a first-party context. Therefore, the request must originate from the same origin — requests made by third-party sites will not include the Same Site cookie.
This effectively eliminates Cross-site Request Forgery attacks without the use of synchronizer tokens. Unfortunately, this method of CSRF protection is not yet effective in all web browsers.
Some Methods to Bypass the CSRF protection
· There are some methods which you can use to bypass the csrf protection
· There are many webapp which only verifies the length of the CSRF token which
means create an account on that website and note down the length of the CSRF token. Now send any arbitrary CSRF token of the same length and it will get accepted.
· You can also use GET method instead of POST method to bypass CSRF protection.
· There is missing best practice in many of the website. After logging in they generate a CSRF token for us and this token remains same on every request until we do logout. But if we note down the same token and try a CSRF attack on any other persons account it will be successful.
· So from my opinion CSRF token should have to be unique per use and they have to expire after use does the logout.
· There is also a flaw exists which makes many Webapp vulnerable which generates the CSRF token and then save them to cookie and on each and every request they verifies the token in the POST request with the token in the cookie.
