Hacking My Bank. For teh lulz.

I have around 17 years experience making people feel bad by finding errors in their code. I like to think I’m pretty good at it.

My computing hobby developed into a career in internet marketing as services moved online. Converting knowledge from my hobby to improve the efficacy of marketing campaigns was easier than hacking banks… Or so I thought. I was recently employed by the leading marketing agency located in Brighton.

They are owned by a large multinational conglomerate which reported an anual revenue of $10 billion in 2014…

For Lulz – And To Protect My Mortgage

Legal disclaimer: I believe in following the laws of both the UK and host country when conducting security research. As the UK is one of the most oppressive regimes for a white hat hacker, it’s a good starting point from which I must restrict my activities. Jail isn’t fun. Been there. done that, got the t-shirt. The t-shirts itch.

Most white hat hackers publicise posts to show weaknesses in big institutions, demonstrate skill and/or gloat. If I’m being honest, I mocked the military more because I could than I wanted them to fix the issue.

I looked into security risks with Barclays for two reasons; I have a mortgage with them and I worked on their marketing campaign. A security breach would have been both professionally and personally inconvenient. I also assumed banking security had moved on from the days of sa:blank.

The “SSL = Secure” Myth

My initial research into the Barclays websites was fairly brief and in preperation for a job interview. It was obvious that the SSL implementation was very insecure and could easily allow MiTM attacks. Until patched, all it would have taken was a malicious access point setup in a busy branch (London, Brighton, etc) and one could easily exfiltrate account data for malicious purposes.

The first issue I reported was a redundant SSL cert installed on m.barclays.co.uk. The combination of a weak certificate and poorly configured server meant that customer data was at serious risk. The attack vector is somewhat esoteric, so I’ll omit it for brevity. I looked for further problems when I had a little more time…

XSS (Cross-Site Scripting)

I ran domains I suspected to be controlled by Barclays through a semi-automated XSS scanner I developed about a ago. I got a hit on barclaycardcentre.es. The hit was confirmed as McAfee had marked the website as being used as a phishing site. I reported the PoC and moved on…

barclaycardcentre.es/busqueda?criterio=1'autofocus/onfocus='prompt(String.fromCharCode(88,83,83))

After starting work on their marketing campaign I took another look at their network. I ran another list of Barclays domains through my XSS script. This time I spotted a similar XSS issue in barx.com, a website dedicated to stock trading…

barx.com/search-results.html?to=1451624400000&q=barclays "><svg/onload=prompt(/XSS/)>&from=1420088400000

I was a little concerned about how insecure my mortgage providers where by this point. I just decided to focus on the marketing campaign and try to get the security issues fixed when I could. Then I found a winning fail…

Public Application Connection Details

I discovered the most painful security issue in the Barclays network while looking for content related issues during an SEO audit. Two pages on the apps.barclays.mobi domain were showing PHP code as HTML, which seemed odd…

Both pages where saved in Google’s cache, so have been visible to the public for a while…

Checking the page source code showed connection details for the application…

$login = new MDG_ApplicationLogin('*snip*', '*snip*', '*snip*');

Enumerating a database once you have the application login details is fairly rudimentary. Having an admin username / password publicly available on a world leading bank is definitely a winning fail. The best case scenario is exfiltrated data. A proficient hacker will root the box and move through the network.

Stating The Obvious

It should go without saying but unfortunatly doesn’t; a global bank with total assets in the region of £1.12 trillion, and an entire team of security specialists, shouldn’t suffer from such basic security issues.

During my brief employment for the McDonald’s of marketing, I was allotted 1 hour 30 minutes to penetration test their portfolio of well known clients. I managed to find exploits on all of them. Which is just sad.

As always, the issues were fixed within days when I got in touch with the right person. The problem is that it can take months to get the right contact.

Ethical hackers are often given free swag as a way of saying thanks. It helps promote the companies we hack and they get secured in the process. All I received were legal threats from my previous employer.

Disclosure Timeline

• June 2015 – Initial report made over the phone. (first few days of the month).
• 13 July 2015 – SEO report conducted on Barclays for job interview. Weak SSL cert reported.
• 01 April 2016 – Started work on Barclays marketing. Reported 2x XSS and weak SSL again.
• 31 March 2016 – Issues escalated to Barclays IT security team. Then ignored.
• 04 April 2016 – Reported publicly available application login details.
• 13 June 2016 – Initial contact with Director of Cyber Response.
• 21 June 2016 – All issues fixed.
• 12 July 2016 – Post made public.