Day 19/100 Hack and Improvement

2 minute read

Day 19 comes with Account takeovers due to chain vulnerabilities and CSRF attacks with couple examples!

Cross Site request forgery

From Rajesh Ranjan. Cross-site request forgery (also known as CSRF) is a web security vulnerability that allows an attacker to induce users to perform actions that they do not intend to perform CSRFs are typically conducted using malicious social engineering, such as an email or link that tricks the victim into sending a forged request to a server. As the unsuspecting user is authenticated by their application at the time of the attack, it’s impossible to distinguish a legitimate request from a forged one.

CSRF Example

Before executing an assault, an attacker typically studies an application in order to make a forged request appear as legitimate as possible.

Example: Suppose a typical GET request for a $100 transfer might look like

GET http://netbank.com/transfer.do?acct=PersonBankAcc&amount=$100 HTTP/1.1

A hacker can modify this script so it results in a $100 transfer to their own account. Now the malicious request might look like:

GET http://netbank.com/transfer.do?acct=AttackerAcc&amount=$100 HTTP/1.1

An attacker can embed the request into an innocent looking hyperlink:

<a href="http://netbank.com/transfer.do?acct=AttackerAcc&amount=$100">Read more!</a>

Next, he can distribute the hyperlink via email to a large number of bank customers. Those who click on the link while logged into their bank account will unintentionally initiate the $100 transfer

Source: https://www.imperva.com/learn/application-security/csrf-cross-site-request-forgery/ Tomorrow I’ll explain more about the CSRF attacks, like how can bypass the CSRF protection even if there is defence mechanism is present. I’ll also show some of my reports in which how I bypassed the CSRF protection

Account Take Overs

From Sam (CoffeeJunkie). Account take overs can be vulnerabilities that might have a severe impact for the company and the user. Althought its complexity fully depends on the kind of the web application that the hacker is testing on. In this case we have brought different case scenarios of account take overs that can be relatable and usable in your hunting tasks. Most of the cases here has been brought from write ups gathered from Pentester Land. As a side note, some of the explanations will be related about chained bugs and misconfigurations that leads account take overs.

Account Take Over Through Business Logic and CSRF

The attacker saw a business logic flaw which allowed him to reset the password from other account due to the logic flaw. Something else to note here is that there was not any kind of CSRF protection where the attacker created a PoC in order to chain the logic flaw and achieve account take over.

Account Take Over Through CSRF Bypass

The attacker was able to reset the victims password, change emails and other verification capabilities due to a CSRF vulnerability and CORS misconfiguration. The attacker was able to bypass the CSRF protection due to the token was in the body and header, the logic here was that as long the body and the header matches, it would be detected as a valid token.

Account Take Over Through Password Reset Poisoning

In this case, the attacker was testing the “Forget Password” functionality in order to see how it works and if he can achieve password reset poisoning. After testing it, the attacker added " X-Forwarded-Host: bing.com" which will forward the token to bing.com, in this case bing.com can be reseted by attacker page which the attacker used ngrok in this case. AS a conclusion, the attacker was able to redirect the token to other server.

Leave a comment