When Cybersecurity Goes Wrong

Today's post is a cautionary tale about the importance of diligence in your organisation's cybersecurity, protecting your customers' data and how to handle the fallout when things go wrong (or how not to, in this case).

Look up to the left

If you cast your eye up to the address bar in your browser right now, you should see a nice little padlock icon or something similar and - depending on your browser and settings - maybe https:// in front of the davegebler.com. If you're the kind of person who ends up reading my blog, it's probably fair to say I don't need to tell you what HTTPS and TLS are. Your connection to this site is end-to-end encrypted. You submit a comment, or search at the top, or even just click on a post, all the data your browser sends at the HTTP layer - right down to the particular page you've asked for in the URL - is securely encrypted. I dont even collect any confidential data from you on my site. You'll never enter your personal details, banking information, credit card number etc. (or, I mean, you can if you want but I certainly don't ask you for those things)

Indulge me, try something for a minute. Edit that address in the top bar and take out the little important "s", then hit enter to reload the same page but over plain, unencrypted HTTP.

Are you back? Great. Look what happened. You couldn't get to my site over HTTP. The second you tried, you were redirected back to the secure version. If you've previously hit my site on HTTPS, your browser won't even try the unencrypted HTTP version even if you explicitly ask for it, because my site serves the Strict-Transport-Security header to tell your browser it should only be accessed over a secure connection. So your browser will upgrade that protocol before it even sends anything.

This means any normal user of my site never has a risk of their request data being sent over the internet as plain-text, from their browser to my server.

Why do I do this, as someone whose website doesn't even collect or ask for private data from its users? Two reasons; first and foremost, I believe in the principle the web should be secure by default. There is literally no reason for any site to not serve over HTTPS. Hell, even certificates recognised by all major browsers can be obtained for free now. You and I, as users of any website, should not have to check or question whether our data is private and secure. It always should be, no ifs no buts.

The second reason is Google happens to agree with the first point and there's a little SEO boost for your site being secure. I'm not an expert in SEO but I know enough about it that within the topics I write about here, my site is pretty damned well optimised. It performs well in search rankings for what are granted quite niche subjects, but you might be surprised by how much traffic I get. So there's a little SEO tip for you; HTTPS should always be on.

Why end to end encryption matters

Quite simply, if HTTPS isn't enabled, any data you send to a website can be sniffed and read by any of the numerous routers and computers it travels through to physically get from your browser to the website. And you have no way of knowing who owns and operates those pieces of equipment, or what they'll do with the information you give them. One of the most common ways of sniffing unencrypted confidential data is through unsecured public WiFi.

But TLS and HTTPS don't stop with end-to-end encryption. The idea of TLS is to ensure confidentiality between you and another trusted entity. And I want to underscore this point - a lot of people think the purpose of TLS is encryption, but that's not quite true. Encryption is the means to the end and the end is a secure, confidential channel of communication between you and a verified identity.

To give a practical example, when I go on to my bank's website (let's say SuperAwesomeBank.com) and enter my login details, the thing I want to know isn't that my username and password are encrypted between my computer and SuperAwesomeBank.com, it's that the data is being sent securely to and can only be read by a computer which is definitely owned by Super Awesome Bank PLC.

It's a subtle difference, but an important one - encryption is no good if you're sending your data securely encrypted to a spoof website set up by scammers. It's identity we care about, encryption is just the means by which we can ensure only the identity we want to read our data can read our data.

Bureaucracy comes in to play

In the UK, we have adopted and enshrined in law the EU General Data Protection Regulation. GDPR - you've no doubt heard of it. And without being a legal expert, the gist is you have an obligation as an organisation to keep data about your customers and users secure and only able to be accessed by people who should have access.

The regulatory oversight of GDPR and the holding of personal data is governed by the Information Commissioner's Office (ICO), who have the power to issue substantial penalties when organisations are found to have breached the requirements.

To the best of my knowledge, GDPR does not specifically mention or mandate HTTPS, however it does place an onus on an organisation in respect of security which effectively mandates HTTPS for any website which gathers personal data, because you can't in practice hold up an argument that data has been kept secure if it could have been picked up by anyone in transit. So not only is HTTPS a good idea, if you're in GDPR scope it's not really a choice.

And now to set the scene

...and the scene is a business which apparently never learned any of the above lessons and did everything wrong.

Have you ever had a payday loan? I have. I had quite a few back in my 20s. Some of them were from lenders who subsequently went out of business. If you're not familiar with the British political-economic scene, basically at some point it was decided by regulators that a lot of these frankly parasitic companies had failed in their duty to protect their customers and carried out unfair lending practices, for example lending to people at high rates of interest who should have had a risk profile indicating they would struggle to make full repayments.

I have little to no idea about the intricacies of all this, but I do know to this day, every now and then, I randomly get an email from an old lender or administrators acting on their behalf telling me that in combing through the old accounts, they've determined I should be due a refund of some fees and interests for loans I paid off years ago. It's not quite the windfall it might seem - unfortunately once these businesses have gone bust, the refunds ("redress" as they usually call it) available are only pennies in the pound. You are an unsecured creditor and pretty much at the bottom of the pile for whatever crumbs are left once the asset pie has been divvied up.

So the other day I get one of these emails. Now, I'm not going to name the company or administrator involved, but in short it ended with a request to go on to a website and enter my bank account number, sort code and address/postcode for whatever small sum of money is due to me to be paid.

To enable us to be able to make a payment to you, we request that you upload the bank account details where you wish payment to be made via the following secure link. [Link] Please be assured that all bank account information entered by you is encrypted and held securely. Failure to update your bank details by 5 June 2022 may result in payment being forfeited by you.

The sense of urgency in the last sentence - act now or lose your money type thing, is actually quite typical of a scam or phishing attempt. There was even another paragraph after:

We are acutely aware that a request for bank account information can be a cause for concern, particularly at a time where online fraud is prevalent. To provide you with some additional peace of mind, you can contact the Joint Administrators by calling [phone number]...

So the administrators of our now-defunct lender are aware that people might be concerned about being scammed and the security of their data. It's right there in their email.

💡️ The email is genuine, by the way - I just want to be clear about that. It's not a fake or phishing attempt, or anything like that.

Okay, so having satisfied myself through some basic checks that I'm not about to click a dodgy link set up by scammers to harvest my bank details and/or infect my computer with malware, I open the link provided. The link itself, I see before I click, is https:// but goes to a domain belonging to one of those CRM or email marketing management services. This URL in turn redirects my browser to another, different URL on a different domain.

Houston, we have a problem

The page the link has redirected me to is not secure. Again, as I don't want to identify the organisations involved, let's pretend the original lender is called Ripoff and the site I've been redirected to is a cloud hosted site operated by Super Awesome Cloud Inc., who own the domain superawesomecloudwebsites.com (I haven't checked if that's registered, so apologies if there really is a superawesomecloudwebsites.com and I'd like to make it clear they are not in any way affiliated with this story, it's just an example).

The URL I've been sent to, then, is something like http://ripoffcrm.superawesomecloudwebsites.com

There's no redirect to a secure site, there's no little padlock, there's no oh-so-important little "s" after the "http". I'm looking at a form asking for my name, bank account information and postcode on an unencrypted, plain-text connection to a subdomain on a third party cloud hosting site which could have been set up by anyone. Even the browser warns me quite prominently the page is insecure and to not enter any personal information.

At this point, despite having already taken some reasonable steps to satisfy myself the original email was genuine, I'm taken aback - could it have been a phishing scam after all?

It wasn't. Direct communication with what I've checked are actually the legit, for-real administrators for this lender confirms it - the email and link did come from them.

I send them an email highlighting that the site they've set up to collect client bank details is not secure, and point out the assurances they made in their email that "all information entered by you is encrypted and held securely."

I also point out the use of a cloud hosting service provides no means of verifying the identity of who set it up.

I might have been a little harsh, but as I've said - security is important - and I in no uncertain terms tell them they look very much like a phishing scam, that it's poor form and risks personal data being leaked.

A poor response

The next day, I receive a short email back. None of the very valid concerns I raised are addressed, at all. Instead I am informed "due to the high volume of traffic to the website, it has been temporarily suspended" and that I should try again later. I am also told they request I "refrain from chasing for updates as this will delay our process."

Now I'm what you might call a tad annoyed. High volume of traffic? You're telling me the globally renowned and highly popular Super Awesome Cloud Inc. can't handle a site getting what can have realistically at most been a couple dozen simultaneous visitors? Bullshit. My blog can handle more than that and it runs on a tiny VPS with less power than your average phone.

I mean, call me a stickler (or maybe just, you know, a professional) but when you commit a fuck-up of the magnitude of potentially exposing customer bank details to the world, you don't deny it, try to cover it up or rudely brush off the client who brought it to your attention. You profusely apologise, tell them you're investigating what went wrong and give assurances you have immediately taken all appropriate steps to remedy the problem and notify anyone affected.

I email them back. Once again, I am forthright, quoting their line about traffic and tell them straight up "a cynical person might think you've suspended the site to urgently put in place HTTPS after it was pointed out to you the link was taking people to a form on an unsecured page."

Is it brusque? Sure, but I don't like being bullshitted. I don't like it when we live in an age of rampant cyberfraud and issues pertaining to security of customer data aren't taken seriously. I tell them I am not comfortable entering my details on their form even if it does come back up with encryption in place - how can I trust their care of the security of my data when they didn't even acknowledge the very real problems I raised to them? I suggest they look up my bank details from the lender's old system directly.

The next reply to me is equally brusque. It informs me they are unable to look up my details and "should you not provide your bank details, we will not be able to process the dividend to you."

So their response, much like the last line I quoted from their original email, is to threaten to withold money from me if I don't comply (as if I'm bothered by the probably about fifteen quid I might miss out on once they've worked out how few pennies in the pound each client will be due).

At this point, I'm more angry about their communication and handling of my queries than anything else. I was trying to do them a favour by pointing out their HTTP problem, to help them catch what is genuinely a serious problem from an information governance point of view before it impacted dozens or hundreds of members of the public.

If when I first emailed them about it, they'd acknowledged it, done the right thing and maybe just tagged on a quick "thanks for bringing this to our attention", I wouldn't have complained or made a fuss about it. Instead, I send a formal GDPR complaint using the template letter format from the ICO website.

The response, this time, is not only much swifter but more contrite.

Dear David, thank you for your email. Unfortunately, the form being unsecure was an oversight which should have been picked up by our developers. As soon as this was realised, we corrected the problem and I apologise for this issue. I can reassure you that your data is held securely and that there has been no breach. It was only the form that was unsecure, until the SSL Certificate was in place. Once the form is submitted, the data is sent through to the database via a secure API.

I do email back once more to highlight the problem here is that anyone who entered their details and submitted the form before they corrected the issue will have had those details sent over the public internet from their browser to the server without being encrypted, and it therefore doesn't really matter if they are held securely after that fact - they still potentially exposed private data to a breach.

This is pretty much the end of the story. I may forward my complaint and chain of communication to the ICO and leave it to them decide whether there is anything further they should investigate. Not because I'm an asshole who wants to cause trouble for people, but because it's sincerely worrying when a company which holds data about me and maybe you strongly gives me the impression they don't really give a shit about their obligations to properly control who can get access to it.

The company concerned do also let me know they are, contrary to their earlier communication, happy to issue me a cheque. The question is, how do I securely get my address to them so they know where to send it? Maybe they'll send me a link ;)

---

Comments