Defence-in-depth – protecting us from ourselves

It really is astonishing how many cyber-attacks we hear about in the media. How can these companies that have become household names be so vulnerable to attack?

It’s a little bit disillusioning, in a lot of ways like finding out that a superhero isn’t real. We waggle our finger and chastise, but sometimes it’s worth taking a step back and looking at our own cyber hygiene. The tech industry is booming, and for a long time the mantra has been “how easy can we make this for the consumer?”. At the end of the day, this has done the average computer user a tremendous disservice. It’s all of our responsibilities to follow secure practices, and the best way to do that is to practice what the security community refers to as “defense-in-depth”.

By making sure that we follow secure practices every step of the way, we can protect ourselves from one or even many failing. Some of the biggest offenders might surprise you, and some you might have been aware of but never had it hit home exactly how this can be exploited. This article aims to take a practical approach at how failing to follow safe practices can easily be manipulated.

 

Thinking HTTP is okay on your local network:

Gone are the days where we can trust your local network. Each piece of equipment should be configured such that it believes every other piece of equipment is potentially malicious. BYOD (Bring Your Own Device) has become a very popular paradigm for corporations, but it means that someone might bring an infected device onto the network. It’s absolutely trivial for say, malware to put the infected user’s NIC into promiscuous mode and sniff specifically for authentication over HTTP. Then, your credentials get stolen and possibly used to log into a machine that allows RDP access for all domain members (any machine).

Numerous privilege escalation attacks exist allowing the attacker to then simply monitor main memory (RAM) for juicier credentials. Always use https, for all of your communications, and ideally only allow ECDHE ciphers to allow for Perfect Forward Secrecy.

Not treating your private keys like a valuable:

As you should all know by now, SSL/TLS functions by establishing a shared session key (symmetric encryption) by forging a temporary secure channel via public key cryptography (asymmetric encryption). This relies on generating a public/private keypair.

The private key is known only to the secure web endpoint, and the public key is your certificate which must be signed by a trusted third party (a CA, like SSLTrust.AU) for browsers to mark it as safe to visit. What happens if you’re lax with the private key though? Well, it depends. If communication is over SSL/TLS with a cipher that utilized Diffie-Hellman with large enough parameters, you’re still safe.

This kind of cipher guarantees that even if the private key is compromised, the communication remains illegible by use of constantly changing session keys. Without this special kind of cipher though, an attacker could have been sitting on your communication for months, waiting for you to do something insecure like generating the keypair on your laptop and then leaving it in the open. Then, the attacker merely needs to open up wire shark, provide it with the private key, and can read the communication – passwords and all! Protect your private keys – they are passwords.

The best way to store these certificates is in an HSM – a hardware module that makes absolutely sure the key can never leave the device. They’re expensive, but if you can afford one they’re well worth it. Did you know that even if you mark a private key as non-exportable in Windows that it can still be easily exported?

Blindly trusting certificates, or worse, root certificates:

How many times has it happened to you? “Just click past the SSL/TLS warning. Trust the cert.” This one boggles my mind how many professionals don’t realize this – a self-signed cert is its own root certificate. They’re not inherently dangerous, in that if you take proper precautions you’re limiting your exposure, but how many of you realize that every time you add a self-signed cert to your root certificate store that that route certificate can now be used in conjunction with manipulating your routing in order to pose as legitimate for any site or service?

With an SSL/TLS intercepting forward proxy, an attacker can sit between you and any legitimate service, inspecting all traffic in the clear. All they have to do is control any hop before you get to the internet, and they can route through their own malicious service. If they can run an executable on your machine with an administrative user’s context, they can also poison your static route table and accomplish the same thing. If this happens, the only thing protecting you from sure ruin is that your browser does not trust the SSL/TLS cert of their malicious endpoint!

If you ever hop onto a free Wi-Fi hotspot, and it wants you to install something on your computer before you connect, it’s game over. That’s both protections from your traffic being decrypted transparently being stripped in one fell swoop. Make sure you don’t reuse keys between different services if it’s not needed, however tempting!

Not using Extended Validation certs for your business:

Hear me out on this one. I know that they’re more expensive and that we have a vested interest in selling them to you, but they really do make a difference. The extra verification procedures protect the end user against a lot of shenanigans – time and time again people are able to game automated systems that use a poor algorithm for choosing administrative contact email addresses for verification. Having to revoke a certificate, especially a wildcard certificate, that your clients trust can do a lot of harm to your reputation.

Conversely, extended validation certificates can help bring in security conscious clients who see that you’ve gone the extra mile for them to conduct business with you safely. They can’t see the measures you’ve got behind the scenes. They need to accept on blind faith that you hash and salt their credentials correctly. This is something they can see, and it does make a difference.

Security for your websites should definitely be a priority for your privacy and your users privacy, and while taking measures to minimize breaches make it more secure, there is no fool proof way to 100% secure a website.

As they say “Prepare for Disaster: Recover Faster”