Posted: July 15, 2020 by

Last updated:

Website misconfigurations can lead to hacking, malfunction, and worse. We take a look at recent mishaps and advise site owners on how to lock down their platforms.

Website owners, listen up: There are lots of things you shouldn’t do with your site, and many more you should avoid with the domains you’re responsible for. Insider malice, bad luck, and the stars aligning in impossible ways can all give your online portfolio a bad hair day. However, if you want to tempt fate, you can bring on the mayhem with website misconfigurations and other ill-fortuned security and privacy errors.

In the last week, we’ve seen a few of these website mistakes go public, so we wanted to give site owners a gentle reminder to watch out for easily avoidable, but even easier to walk into—and pay the piper afterwards—errors.

Spoiler alert: Do not pay the piper.

Paying the piper: Salacious subdomains

Subdomains are a great way to add depth to your website, branching off from the main domain and allowing for content categorization. They can help make huge, unwieldy portals a little more manageable.

Problems arise when someone creates a bunch of complicated subdomains resolving to different places, and they later fall into a state of abandonment, as was the case with several mega-corporations, including Chevron, the Red Cross, and Getty Images. This unfortunately leads to issues the subdomains were never intended to address.

Opportunists took note of the sheer number of abandoned official subdomains and figured out a way to game the Azure system powering everything behind the scenes. If you didn’t know, Azure is Microsoft-powered cloud technology with a big splash of virtualisation thrown into the mix.

What did they do?

I’ll give you a straightforward, non-Azure related example. You set up a website, yourwebsite(dot)com. You don’t want to bother with managing hosting and all the nitty-gritty that comes with it, so you point your URL at a website hosted on a free platform. Let’s go with yourwebsite(dot)freebloggingplatform(dot)com.

After a while, you become bored with your website and it falls into disrepair. You haven’t touched it in months, but someone got their hands on the blog the URL was pointing at, compromised it, and turned it into a horrendous pornography spam farm.

Imagine something similar with Azure, except instead of a straightforward top-level domain (the landing page for your website), you created lots of subdomains like myfavouritemovies(dot)yourwebsite(dot)com and myfavouritebooks(dot)yourwebsite(dot)com.

Each of these subdomains pointed to hosted webspace on Azure, and when the organisation no longer needed the hosted space, it was released back into the wild for anybody else to grab. Unfortunately, someone in admin land forgot to stop pointing the subdomain(s) at the now relinquished Azure pages and it’s at this point the scammers swoop in.

Congratulations, website owner: You now have a forgotten-about subdomain with a good search engine page rank pointing at newly-created spam/porn/drugs/who-knows-what content.

It’s not just spam and dodgy deals you must be wary of. You could find yourself pointing your website at phishing scams, or malware installs, or potentially illegal content. It might be used for cookie harvesting or any number of awful Internet shenanigans you don’t want to get tangled up in.

You could easily be directed to a site playing host to credit card skimmers.

These so-called “dangling DNS entries” now have a support page over on the Microsoft portal, and it’s well worth a read if you expect to be managing subdomains in the near future. These kinds of attacks are almost certainly automated, so you can expect your org to be caught up if some spare subdomains are left out in the cold waving a large “please hijack me” sign.

Keep your subdomains safe, register your domains in Google Search Console, and make sure your big list of DNS antics are on an actual list. Here are some more tips on how to fix a subdomain takeover, if you’re interested.

Paying the piper: Any road is code

A CDN is a content delivery/distribution network. They’re the bits and pieces of the Internet tapestry theoretically close to where you’re located, with the task of bypassing bottlenecks and hurling content in your direction faster than it would’ve arrived otherwise.

And now, for the somewhat more cynical take: If you’ve ever loaded up a website and marveled at how slow the content was but how fast the 26 adverts were, loading before the site did: That’s the wonder of a decent CDN.

Anyway.

CDNs can be used to serve up various bits and pieces of a site as and when required. It’s not uncommon for chunks of code to be pumped into the page from multiple sources, but you must offset that against the risk of the site breaking.

But what if the CDN has been serving up bad files and finds itself on a block list? What if it simply fails to load and breaks the website’s functionality? There are all sorts of things that can go wrong with that kind of setup.

What happened?

Something you probably wouldn’t expect to see is a major bank using the Internet Archive as a CDN resource. The Internet Archive is where old websites and other content live on, and it’s tremendously helpful for archival purposes.

For some peculiar reason, Barclays bank was linking directly to an archived page to serve up their own JavaScript code. Barclays have no control over the content hosted on the Internet Archive, and if someone managed to tamper with the code, it could give banking customers quite the headache (or the site could simply lose functionality if Internet Archive went down or the page was removed for whatever reason).

Now I’m thinking back—again—to the various caveats and requirements banks place on customers to make sure they’re doing their due diligence. How would banking customers have any idea about this going on under the hood if it ended up causing them some sort of security issue? Would suspicion first fall upon the customer? How would they prove they weren’t to blame for something going wrong?

Sometimes organisations lose bits of code and have no backups. I don’t think that’s likely in this case, but if you don’t want to end up in a similar situation and start grabbing files/links from somewhere like Internet Archive, please make backups. (And check where, exactly, you’re copying and pasting code from.)

Paying the piper: breaking down the breakdowns

Those are just two of the most recent examples of website mishaps that can lead to malicious takeovers or simply result in an inability to function. Those aren’t the only ways for things to go wrong, though. What else should you be looking out for and doing?

Update, update, update. If you don’t, people could bludgeon their way into your content management system/blogging platform and stuff the site with SEO spam. If your site ends up in the news for an unrelated reason, you could inadvertently drive lots of visitors to potentially bad places.

Think about all those credentials you have tied to your platforms. Is everybody listed still working at your organisation? Or do you have lots of insecure admin accounts with basic passwords scattered about the place?

Has the platform you use to power your blog been abandoned? If it’s no longer updated, you could well receive a visit from the website hack inspector. Even the biggest organisations are not immune to the perils of platform mishaps. You’ll never know the impact until everything is already burning away in some sort of digital firestorm.

It may well be worth drawing up a short digital to-do list and giving your site an inspection, because so many intrictate moving parts almost demand the wheels coming off at some point. Get ahead of the curve, throw on your welding goggles, and give that site of yours the tuneup inspection of a lifetime.

Source: Malwarebytes.com

Powered by NewsAPI.org