I have around 17 years experience in making people feel bad. I do this by finding errors in their code. I like to think I’m pretty good at it.
My computing hobby developed into a career as marketing services moved online. Converting knowledge from my hobby to improve the efficacy of marketing campaigns was easier than hacking my bank… Or so I thought.
I was recently employed by a leading marketing agency, located in Brighton. They are owned by a large multinational conglomerate which reported an anual revenue of $10 billion in 2014…
Hacking For Lulz. And To Protect My Mortgage. Mostly Lulz.
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 an ethical 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 weaknesses in websites to 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. But I have morals.
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 basic issues such as default username/passwords, and simple input validation.
The “SSL = Secure” Myth
My initial research into the Barclays websites was fairly brief and only 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. When I had a little more time, I looked for other issues…
XSS (Cross-Site Scripting)
I ran domains I suspected to be controlled by Barclays through a semi-automated XSS scanner I developed for testing purposes — securing my own scripts. I got a hit on barclaycardcentre.es. The hit was confirmed as McAfee previously marked the website as being used as a phishing site. I reported the PoC and moved on…
// Barclaycard centre vector PoC
After starting work on their marketing campaign I took another look at their network. I ran another list of potential Barclays domains through my XSS tester. This time I spotted a similar XSS issue in barx.com, a website dedicated to stock trading…
The Proof of Concept test was:
I was a little concerned about how insecure my mortgage providers where by this point. I reported it and decided to focus on the marketing campaign, trying to get the security issues fixed when I could. Then I found a winning fail…
Public Application Connection Details
I discovered a critical security issue in the Barclays network while Googling for duplicate content issues during an SEO audit. Two pages on the apps.barclays.mobi domain were showing PHP code as HTML, which seemed odd.
The Google query is commonly used to check for duplicate pages:
Google had already cached both pages, so had been visible to the public for a while…
Checking the source code showed connection details for the application…
$login = new MDG_ApplicationLogin('*redacted*', '*redacted*', '*redacted*');
Once you have application login details, enumerating a database is fairly simple. 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 would get escalated access to the server (“root the box”), then pivot through the network (access other stuff), and probably steal a large sum of money.
Stating The Obvious
It should go without saying; a global bank with assets in the region of £1.12 trillion, and an entire team of security specialists, shouldn’t suffer from such basic security issues. Everyone slips up once in a while. Even the best.
The issues were, as always, fixed within days after I got in touch with the right person. Sometimes it can take months to get in touch with the right person, if they care at all.
During my brief employment in the McDonalds of marketing, I was allotted 1 hour and 30 minutes to test the portfolio of clients for infosec issues. I found exploits in all of them. Several in some cases, which made me a little sad. The best qualification I have is a reach truck licence (a tall forklift). If an inept autodidact like me can find basic security issues, what are other more proficient people with malicious intent doing?
The Director of Cyber Response at Barclays was understanding. The issues were fixed quickly. It’s a shame there isn’t a standardised way of reporting such issues. Ethical hackers usually do this in their spare time, with no expectation of a reward. We are sometimes given free stuff as a way of saying thanks, even if as promotional material for companies. We hack with altruistic intent, and the targets get secured in the process.
I received a few vague legal threats from my previous employer, but nothing more. Barclays Cyber Response team were slightly more receptive and at least thanked me.
You’re welcome Barclays.
I didn’t even get a free sticker.
I often dream about the island I could have bought ¬_¬
awkward silence … I guess “manners maketh the man” – William Horman
- 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 2 XSS issues and SSL Invariance exploit.
- 31 March 2016 – Issues escalated to Barclays IT security team. 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.