Hacking banks for fun and profit

Greetings, this is my first blog post. In this post I will be detailing some vulnerabilities I have identified after doing some quick tests on several banks. It’s a sad state of affairs when you can find vulns such as XSS, CSRF and LFI on many major banks.

I’ll start up with some of the more minor vulnerabilities, while the banks generally *do* tend to have good XSS filters in place, they seem to forget about the dangers of redirects (in some of these cases the redirects can easily be turned into XSS).

The banks I start with are JPMorgan / Chase, within 5 minutes I found some open redirect vulnerabilities, with no authorisation required to redirect to an external site, and no warning message to tell the user they’re about to be redirected. Below are the examples (redirecting to my blog for the case of this example):

http://commercialbanking.chase.com/etrack.ashx?M=1725.7b601f6c-c54d-456a-b31b-364c5c501873&L=29102&URL=https://ret2libc.wordpress.com/

Note: these are both using the same thing to redirect.

http://jpmts.jpmorgan.com/etrack.ashx?M=1212.721a7f5a-1828-4e96-b937-d73ca54e3033&URL=https://ret2libc.wordpress.com/

The security risk here, of course, is that an unsuspecting user could click a seemingly innocent URL which appears to be part of the bank’s website, and then be redirected to a phishing page where they are prompted to enter their account details.

Another risk related to open redirects is cross site request forgery, as a user could redirect another user of the bank to links that are still part of the site but that could be used to execute unauthorised actions from the account of the victim who clicks the link.

One trick is to redirect directly to a data: URI with a base64 encoded input cotaining your HTML/JavaScript, allowing you to build the fake login page in the context of the victims browser itself rather than within the context of another site. It could be argued that this offers further obfuscation as the victims address bar won’t display a phony URL but will instead just display ‘data:’ (assuming that padding is added to the uri, in which case the base64 encoded inputs will not be displayed in the address bar)

An example payload would look something like:

data:text/html;base64,PHNjcmlwdD5hbGVydCgnRXhhbXBsZScpPC9zY3JpcHQ+

the first part of the string is telling the browser what kind of data to be expecting, and the second part of the string (after the comma) is the base64 encoded input that would contain your HTML for your phishing page or whatever you decided to use on the victim,

to break that down:

HNjcmlwdD5hbGVydCgnRXhhbXBsZScpPC9zY3JpcHQ+

is a base64 encoded version of:

alert(‘Example’)

A live example of the URL can be found here:

http://commercialbanking.chase.com/etrack.ashx?M=1725.7b601f6c-c54d-456a-b31b-364c5c501873&L=29102&URL=data:text/html;base64,PHNjcmlwdD5hbGVydCgvWFNTUE9TRUQvKTwvc2NyaXB0Pg==

It should be noted that the above URL is only working in Firefox, here is another example in another large bank (HSBC):

http://fundexpress.tw.personal-banking.hsbc.com/FileProxy.aspx?url=data:text/html;base64,PHNjcmlwdD5hbGVydCgvWFNTUE9TRUQvKTwvc2NyaXB0Pg==

The fact that this can be used to spear phish and force malicious downloads is kinda scary, but the fact that the uri is operating under the context of the victims browser rather than the site means that hijacking cookies via this method is not possible, which brings me onto the next section of this blog post. Having an XSS that affects a bank wherein cookie hijacking is a real possibility seems like an interesting challenge, so I moved onto my next target, World Bank.

After maybe 5 minutes of searching, I found a valid vulnerability (although some user interaction is required, It requires them to interact in the way that they would be expected to anyway).

It is again using a URL= GET paramater, but it is loading the javascript within the context of the site this time rather than within the context only of the victims browser (in other words, it’s reflected)

Here is the vulnerable URL (in order to trigger it you must click ‘here’):

https://wbssoextcl.worldbank.org/regconfirm.jsp?URL=javascript:alert%28document.cookie%29

Screenshot:

XSS Vulnerability in a bank, affecting cookies (albeit reflective). At this point I decide to do some more digging and look for something more major, and I come across the following URL:

https://remittanceprices.worldbank.org/en/corridorgenpdf?url=

At first I assume its an open redirect, but then I realized its something far more interesting. You give it a URL and it takes the URL as an input, converts it to PDF format, and prompts the user to download it. Here is a working example:

https://remittanceprices.worldbank.org/en/corridorgenpdf?url=http://twitter.com/ret2libc

It coverts the user-supplied URL into PDF format as seen here:

Now the risk associated with this is that a user could be served content as a PDF from a trusted source (world bank) and that PDF could contain contact information that puts the victim right in touch with a fraudster or links them to a phishing website. It would just be a case of setting up the output you want to be served to the user on one of your servers, then setting it as the input for ?URL= param. Pretty interesting vector (comparable to the CEMI aka CSV Excel Macro Injection bugs that have been floating around lately), but still not too high of a security risk – probably about the same level as a reflective XSS or the redirects to data: URI’s as displayed at the start of this post.

My next thought was, if it’s getting remote URL’s and serving them as PDF’s, what’s to stop it from getting local URL’s?

I then attempted some testing for SSRF / XSPA and it worked like a charm.

The following URL was inputted for testing (in attempt to see whether I could probe for info on their SMTP daemon):

https://remittanceprices.worldbank.org/en/corridorgenpdf?url=http://127.0.0.1:25

as you can see from the screenshot below, here is the output, converted to a PDF file by a script on their server and downloaded for anyone to view:

Here’s another test, this time probing the MySQL port to see if the version info is disclosed, using the following input:

http://127.0.0.1:3306

Once again, worked with no issues:

The SSRF alone is a pretty nasty vuln, but instantly after finding this my next thought is can it be leveraged to LFI via the file:/// handler?

Short answer: yes, it can. Easily.

First I tried probing for /etc/hosts, via the following input:

file://etc/hosts

the result? a blank PDF. I then try using only one foward slash rather than 2, example:

file:/etc/hosts

Worked instantly. Readable local system files on a large financial institution:

The final test I made before reporting (nope, I’d rather not exploit this – I appreciate my anal virginity) was using the file:/// handler to see if /etc/passwd was readable, and once again there it is, served to me straight away as a PDF file:

After this I find a ?filename= param while searching for some more XSS (preferably one that requires no user interaction). I immediately begin testing for LFD and at first it fails, using the following method:

../../../../../../../../etc/passwd

I notice the foward slashes are being stripped, and a file extension is being appended by default, so I try some encoding and the addition of a nullbyte to see if I can get around it, my payload now looks like this:

..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2Fetc%2Fpasswd%00

and it works instantly (despite throwing a 404 message at me):

After finding these vulnerabilties, my next thought is to report them to allow the sysadmins some time to patch – so I start looking for a contact method which leads me to their next huge failure.

I find an email contact form, located at http://web.worldbank.org/external/default/main?pagePK=50041377&piPK=50041375&theSitePK=225714&contentMDK=22879511

You can see the form below:

I enter my own email address as the recipient’s email, then I enter admin@worldbank.org as my own email, as seen below:

I enter the captcha and click ‘send’ and instantly get a prompt confirming that the mail has been sent:

I check my email to confirm, and here we go, a message from DO_NOT_REPLY@worldbank.org telling me that admin@worldbank.org has sent me a message:

The fact someone has INTENTIONALLY made this is kinda scary, a site like this should not have such incompetent sysadmins. This could be paired with the XSS in worldbank.org to effectively hijack cookies or launch other attacks, here is an example attack scenario:

• Attacker obtains a list of email addresses associated with worldbank.org
• Attacker then sends out mail seemingly from admin@worldbank.org to the emails in the list
• Emails contain a link to the XSS with a payload setup to hijack cookies and store them on the attackers server
• victims click link
• ???
• PROFIT

Generally it would be time consuming for an attacker to obtain a list of emails associated with a site, but in the case of world bank it’s trivial, simply request the page to view a list of email notification subscribers:

https://icsid.worldbank.org/apps/ICSIDWEB/_layouts/mobile/view.aspx?List=08cea935-2ea4-4c00-8943-137e4974068e&View=4496ef14-9fde-4f3b-ba03-89a02d8f6a7b

List of subscribers available for anyone to read:

Not only that, but if an attacker wanted to personally tailor the emails to a target, they can find out their personal information by simply clicking their name within the subscriber list:

As of publishing this blog post, i’ve recieved no reply from worldbank.org – I have recieved a reply from Chase/JPMorgan, but no reply from HSBC – I have something similar (SSRF/LFD) in HSBC but since they actually seem to care about their security I will withhold this information until after a patch.

Happy Hunting,

M.