Holidays – a time to switch off, relax and forget about your daily stresses. But could you be exposing yourself to more than just too much sun?

Holiday WiFi

Having just returned from a week in beautiful Cornwall with my family I’ve realised two things.

  1. The term “holiday” when used in conjunction with a baby is a total oxymoron
  2. How easy it is to be complacent with regards to security on holiday and how a lot of holiday homes could present a simple attack vector

Let me explain…

After arriving at a lovely old cottage in the middle of the countryside I wasn’t particularly surprised to see that the WiFi was just broadcasting on an open SSID. Lets face it most coffee shops and airports are the same, except this time the chances of someone carrying out a man-in-the-middle (MiTM) attack are pretty slim. I’m literally surrounded by fields in all directions. My only real risk from this perspective is perhaps the owner who lives in the adjoining cottage. I’m probably fine to just use it right? Maybe. What about if the WiFi was encrypted? Should I feel safer then?

Open WiFi isn’t the real problem in this particular scenario. I should be more concerned about who has been here before me and what they could have done. Anytime you are connecting to an untrusted network there are risks.

Physical security

Unlike in a lot of coffee shops/airports, the wireless access point/router in the cottage was easy accessible. There it was – right next to the TV. Given the owner’s day job was farming would he have had the knowledge or inclination to change the admin login? Maybe – just because he is a farmer doesn’t mean he isn’t security conscious! But even if he had changed it, with physical access to the device it is more than likely that I could just restore to factory-defaults anyway. Needless to say I didn’t attempt to login or reset the device (I’m far too much of a goodie goodie for that) but it made me think.

What if someone that stayed at the cottage prior to me wasn’t as well behaved. What sort of things could they have been up to on that router? They may have been able to root the device and install some malicious software on there – but I’m thinking much simpler than that. What if they just logged into the device’s settings, pointed DNS to a malicious server that they controlled and left?

It would be pretty trivial to have a server spun up somewhere running DNS and a proxy service. The DNS requests forwarded by the router would resolve to an IP of the attackers choosing. This allows them to point wireless client’s web traffic to a proxy server they control and carry out MiTM attacks. Nasty. And persistent too unless the holiday home owner realises and does something about it.

HTTPS to the rescue

Well… maybe. It depends on how the site is configured and how you access it. Yes, if you try to access a site via HTTPS then the attacker is (hopefully!) unlikely to be able to generate a valid certificate at which point your browser will throw up a warning. But do you always type https:// into the URL bar? Or do you just whack in the name of the site and hit enter? The latter is more likely right? With this behaviour in mind there are a couple of things the attacker could do:

  1. Proxy the connection just over HTTP – If you just type the domain name in without the HTTPS prefix then the connection would (likely) just be over HTTP. The attacker could just keep the proxied connection going over HTTP on the client-side. Unless you are being vigilant (which hopefully you are) you may well miss the fact that the page is presented over HTTP instead of securely over HTTPS at which point it is game over – the attacker can start gleaning your login details etc. Fortunately there are some fixes to this which site owners can implement. I will cover them in the next section
  2. Redirect type a typo-squatted domain – If the attacker wanted to present a HTTPS page for sites to gain your trust then in theory they could have acquired a valid public cert for a similarly named domain. As an example – they may own the domain and have a registered certificate for “m1keguy.co.uk” instead of “mikeguy.co.uk”. When I initially request “mikeguy.co.uk” over HTTP they send a redirect to “https://m1keguy.co.uk”. One character difference – but that is all it takes. If the end user doesn’t spot this they are presented with a nice secure looking web page

Site owner protection mechanisms

Site owners can actually help protect their end users, without requiring them to do a single thing! I will run through some of these at a high-level, but there are some fantastic detailed articles written by a chap called Scott Helme. I will provide links to these rather than trying to rewrite some already great articles.

HTTP Strict Transport Security (HSTS)

HSTS is an additional HTTP header that allows a website to inform the browser it should only ever be accessed securely over HTTPS. So, even if you don’t explicitly type the https:// prefix, the browser will automatically add it on your behalf. What does this header look like? Taking the one I use on my site as an example you can see it is pretty simple…

strict-transport-security: max-age=31536000 ; includeSubDomains ; preload

The different values mean the following:

  • max-age=31536000 – The browser should cache this response (and only access securely) for the next 31536000 seconds (one year)
  • includeSubDomains – This setting should also apply to any subdomains under mikeguy.co.uk. So if I had “test.mikeguy.co.uk” as well – this would be accessed securely as well
  • preload – The site is suitable for pre-loading (more on that below)

Now, as you can see from above I have it set to cache for one year. If my site was not already accessible over HTTPS before implementing HSTS, then people aren’t going to be able to access it until either 1) I fix it and enable HTTPS or 2) the cache expires! So you need to be careful when implementing this and make sure you start with a low max-age initially for testing.

As mentioned – HSTS is a HTTP header, so in order to receive it you have to have connected to the website in the first place. If you don’t explicitly type https:// when you first access the site (and lets be honest – a lot of people don’t) then this leaves a small window of opportunity for a MiTM attack. An attacker could intercept that first connection (or subsequent ones if the max-age expires) and carry out the same tricks highlighted earlier. This is where the preload option comes in to play. After adding that to your header, it allows you to submit a “preload” request, so that future Chrome browser builds will have this hard coded in. No more window of opportunity – all requests, even the first, will be HTTPS.

Tying this back to the earlier scenario – how does it help with the MiTM attack? Well, the attacker can still intercept your DNS request and send you to their proxy, but this time your browser will try connecting with HTTPS regardless. At this point the attacker will not be able to generate a valid certificate (unless they’ve compromised a valid CA – in which case there are much bigger problems) and the connection will flag up a warning in the browser. The great thing about HSTS is the browser also prevents you from bypassing the warning too.

Obviously this requires the site to be implementing HSTS in order for you to be protected. Fortunately, this is increasingly common. Some of the common sites you’d expect are using HSTS, including:

  • Google
  • Amazon
  • Facebook
  • Twitter
  • My site – mikeguy.co.uk!

For more information on HSTS I’d recommend having a read of the following articles – The Missing Link in TLS and HSTS Cheat Sheet

Certificate Transparency (CT)

Remember earlier I gave the example of “m1keguy.co.uk” being used? Well what if I hadn’t implemented HSTS on my site – this would still be a possibility. The attacker could reply to my DNS requset with his server’s IP. This server could redirect the initial “http://mikeguy.co.uk” request to “https://m1keguy.co.uk” (which also resolves to the proxy). The server could then provide a valid certificate and carry out a man-in-the-middle attack. This typo domain-squatting attack isn’t just limited to this MiTM scenarios though – it is something that has been going on in general to try and catch users who make mistakes typing addresses into the address bar.

This is where certificate transparency can help. On it’s own it doesn’t actually protect the connection (though there are additional headers such as Expect-CT that I won’t get into here), but it does allow site owners to monitor for unexpected certificate issuance of your domain and of registration of domains suspiciously similar to theirs.

So what is certificate transparency? In simplistic terms, when you obtain a certificate the Certificate Authority (CA) registers it in several different “certificate logs”. These public logs can be monitored by anyone and used to identify certificates issued without their knowledge (or ones that look suspiciously similar to theirs) and take action. For example, reviewing certificate transparency logs at https://crt.sh for my domain I see the following:

Certificate Transparency Log

If I was to click on one of the entries I can drill down into the details of the certificate that was issued. Facebook offer a great little log monitor tool here that allows you to monitor issuance of certificates for your domain and for possible similar phishing domains. So if someone does manage to issue a certificate for your domain that wasn’t you – you can find out about it quickly and take action. Similarly, if you see a possible phishing domain that is clearly mimicking your site then you can take action with the relevant service providers to try and get it removed.

But what if the attacker registers with a CA who doesn’t register it in a log? It is possible at the moment. But browsers are moving (and have moved in some cases) to warning users when a certificate has not been registered in a CT log. Ultimately, this will push all CAs to make sure they are registering certificates in logs and visibility all round. Expect-CT is also a new header that works in conjunction with CT to basically tell the browser to only trust the connection if the certificate is present in a CT log.

Again I would highly recommend you check out Scott Helme’s blog articles on these points – here and here.

This is not an exhaustive list of things site owners can do to help protect users using their sites. This article (again, another Scott Helme article!) is worth a read too for some other tips I won’t delve into. The only one to disregard from that list really is HTTP Public Key Pinning (HPKP). This has pretty much been abandoned now due too many misconfigurations causing major problems.

As you can see, Scott Helme writes a lot of good posts and has been involved in the development of some new web security features and tools. Check him out!

Protecting yourself

I’ve mainly focused on some of the protection mechanisms site owners can implement to help users. However, there are a number of things you can do to help protect yourself in these scenarios as well.

Remain vigilant

Keep an eye on the website you are browsing to. Is it using HTTPS? Does it usually use HTTPS but isn’t now for some reason? What about if you explicitly type the https:// prefix? All things to watch out for that could be indicators of something going wrong.

If you ever see a certificate warning in your browser – DO NOT BYPASS IT! The only people that should ever be bypassing warnings are administrators setting up new devices to put a proper certificate on them! Be very wary if someone ever asks you to bypass a warning in your browser. They are there to keep you safe.

Set your DNS manually

One option could be to manually set your device’s DNS settings to point to something like CloudFlare’s DNS resolvers (1.1.1.11.0.0.1) or those from Google (8.8.8.8 or 8.8.4.4). Be warned though, this only gets around the specific problem highlighted at the beginning of the article surrounding the upstream device forwarding DNS requests to an attacker. If an attacker has compromised the router in other more elaborate ways, then this DNS traffic could still be intercepted. The only real way to ensure you are talking to a DNS server you expect is to…

Encrypt your DNS

DNS in the “last mile” (between your browser and the DNS server) is one of the weakest points of all Internet communication. It is here that a MiTM usually happens, and often here you need to focus on ensuring it is secure.

This typically boils down to one of three solutions – DNSCrypt, DNS-over-TLS and DNS-over-HTTPS (which is basically DNS-over-HTTP-over-TLS). These are all different options for encrypting DNS requests. Unfortunately none of them are supported natively in Windows that I am aware of and require additional software or browser plugins.

I don’t have much experience with these solutions from a personal use perspective. I’ve worked a fair bit with Cisco’s Umbrella client (previously known as OpenDNS) in enterprise environments however this won’t be relevant to many people from a personal perspective. With that in mind I can’t really comment on, nor recommend a specific solution for personal use. Helpful blog post huh?! I know – I’m sorry! I will look to spend some time investigating some of the common options, review them and do a follow up blog post at some point.

The other option for securing your DNS in the last mile is to use a VPN to tunnel your requests to a trusted DNS server. That way, an attacker can’t intercept your DNS in the first place. This could be a VPN to your home, corporate firewall (if permitted) or a trusted public VPN provider.

Don’t use the WiFi!

Sounds simple right – but before you connect to an untrusted WiFi network, ask yourself if you really need to? Can posting your holiday pics wait till you are back home? If you need to use the Internet do you have a mobile that you could tether (WiFi hotspot on your phone) onto instead?

What I do

The reason I’ve probably been so unhelpful above in providing recommendations is because I tend to avoid public WiFi altogether most of the time. Fortunately the phone plan I am on provides a generous amount of data for tethering, so I tend to just use that instead. The data between my laptop and phone is then encrypted before being routed onto the providers 4G network. Unhackable? Probably not. Nothing is! But it is a lot more secure than open public WiFi.

Alternatively, my home router/firewall also provides VPN capabilities, so if I need to I can just connect back there. That way at least I know my traffic isn’t being intercepted on the local network (you need to make sure your DNS is going through the VPN though).

Finally failing that I can also be careful which sites I use. If I ensure that I manually type https:// or use sites I know implement HSTS already I can alleviate some of the risk of using public WiFi and browse relatively safely. If certificate errors start popping up I know something is awry.

What about the holiday home owners?

Ideally, the owners of these holiday homes could secure the device – both physically and from an admin point of view. Pre-shared-keys could be rotated after every visit. The device could be reset to ensure someone hasn’t managed to tamper with settings. They could use an expensive(ish) cloud based solution to prevent local management. But lets be realistic – these things are unlikely to happen.

Holiday homes are likely to continue providing open WiFi (or a simple PSK) with a cheap consumer grade router. With that in mind, it is up to you to understand the risks and take appropriate actions to protect yourself.

Recommendations?

As mentioned above, I haven’t really got any recommendations for DNS encryption tools or public VPN providers at the moment. I’ll do some research and do a follow up post, but if you have any recommendations on providers/tools you use I would love to hear them.

Get in touch via a comment, email or Twitter.