Security Bits – 30 November 2018

Followups

After it emerges that implementing one of Intel’s Spectre mitigations in the Linux kernel will incur as much as a 50% performance hit, Linus Torvalds has proposed disabling the mitigation by default, but allowing those who want it to enable it — nakedsecurity.sophos.com/…

Security Medium 1 — Don’t Misunderstand the Padlock!

In its latest latest report the anti-phishing firm PhishLabs found that 49% of the phishing sites it encountered in the previous quarter had valid TLS/SSL certificates — i.e. they were served over HTTPS without any kind of certificate error.

How is this possible? Easy — if you legitimately own a domain you can get a certificate for it no problems. In fact, you don’t even have to legitimately own it, you just need to prove you control it. Standard HTTPS certificates are actually DCV Certs, or Domain Control Validation Certificates — they certify that the owner of the certificate’s private key demonstrated control over the domain the certificate is for using one of the methods described within the rules certificate authorities have to operate under in order to remain trusted by web browsers.

Control is generally demonstrated by being able to perform an action using a cryptographic key provided by the certificate authority. The three most commonly used options are:

Email validation — the CA emails the cryptographic token to one of a small handful of permitted special email addresses at the domain, e.g. [email protected]
Web validation — the CA gives you a text file containing the cryptographic token which you must be able to publish at the root of the domain.
DNS Validation — you must publish a cryptographic token provided by the CA as a TXT record on the domain

So what does it mean if the browser shows a padlock? It means the web page you are seeing is legitimately at the URL shown in the address bar. If you go to https://www.bartb.ie/ and there is no certificate error that means you are really viewing www.bartb.ie (authenticity), and that the page you are seeing has come from my server, has not been altered in any way since leaving my server (integrity), and has not been seen by anyone between my server and your computer (confidentiality). Another way to say that is that seeing the padlock and not getting any HTTPS errors means your DNS queries were not spoofed and there has been no successful man-in-the-middle attack.

Authenticity, integrity, and confidentiality are valuable. Protection from spoofing and MITM is valuable. However, they make no claims about the site owner’s trustworthiness!

Phishing sites don’t rely on DNS spoofing or MITM attacks — they rely on using legitimate URLs that are confusingly similar to those of the site being impersonated. If I were to register www.pod-feet.com and publish a site that looks identical to www.podfeet.com but also delivered malware I could easily, quickly, cheaply (free if I use Let’s Encrypt), and legitimately get a TLS/SSL certificate for that site and serve it over HTTPS without errors.

Why does this matter?

Because a lot of half-informed people advise their friends and family that if they see a padlock the site is safe. This has never been true! The actual advice has always been “check the URL to be sure you’re at the site you intended to go to, and be sure there is a padlock and no security errors or warning”.

Now that half of all phishing sites have padlocks, the first half of that advice is becoming ever more critical!

Security Medium 2 — Sennheiser’s Big Mistake

News broke that the installer for Sennheier’s HeadSetup app for Windows and Mac installed a root certificate into the OS’s central trust store, and that the private key for that certificate was not adequately protected. Uninstalling the app does not remove the offending certificate from the trust store, but a software update for the app does.

Your computer’s central trust store acts as the trust anchor for TLS/SSL. What that means is that to be considered valid, every TLS/SSL cert needs to be chained to one of the certs in the central trust store. Out of the factory a PC’s trust store will only contain certificates for the officially recognised Certificate Authorities. Corporations often run their own internal CA, so additional certs are often added to the store by corporate IT. Sennheiser used this mechanism to add a certificate of their own.

Certificates that are not root certificates are signed by another certificate. This creates a chain of trust. The act if signing something with a certificate requires the private key. This means that the private keys for the trusted root certificates are absolutely central to the security of TLS/SSL, i.e., central to the security of HTTPS, and the secure variants of the email protocols.

If an attacker got hold of the private key that matches a trusted root certificate they can use it to sign a certificate for any domain, and that certificate will be trusted. So, since Sennheiser have lost control of the private key for this certificate they have installed into the central trust store of people’s computers, attackers can generate certificates for any site on the planet, including the big ones like Google and Facebook, and those certificates will be seen as genuine. This means that if an attacker can get between you and a website, they can successfully carry out man-in-the-middle attacks without generating any user-visible errors. The padlock will be there!

The only solution is to get that cert out of your trust store, either by manually deleting it, or, by running the latest software update from Sennheiser.

Notable Security Updates

Microsoft has released a patched version of a patch for Outlook 2010 that it had to withdraw earlier in the month because it crashed the app on launch — nakedsecurity.sophos.com/…

Notable News

🇪🇺 Consumer agencies from seven European countries have filed a complaints with their national data protection agencies alleging that Google is in breach of the GDPR for collecting location data without an appropriate legal basis, specifically, that the consent for the tracking is ‘not freely given’ — www.reuters.com/… & nakedsecurity.sophos.com/…
- Tom Merritt explained on Daily Tech News Show www.dailytechnewsshow.com/…
A weird FaceBook bug that re-posted old messenger messages from many years ago as new messages highlights just how much data Facebook retains over the long-term — nakedsecurity.sophos.com/…
🇬🇧 In an op-ed the technical director for the UK’s National Cyber Security Center (part of GCHQ) argued in favour of forcing messaging companies to inject keys for the government into encrypted chats as a mechanism for avoiding having to break encryption. The suggestion was immediately criticised by privacy advocates — www.macobserver.com/…

Palate Cleansers

🎞 Hacker breaks down 26 hacking scenes from movies & TV — www.loopinsight.com/… On YouTube: www.youtube.com/…

1 thought on “Security Bits – 30 November 2018”

Steve Davidson - December 8, 2018

[Repeating what I posted to the main Podcast blog in case someone comes here directly]

Regarding Marriott and Starwood… Starwood was the parent company for the Sheraton hotel chain. In 2015, Marriott and Starwood entered into an agreement whereby Marriott would buy Starwood.

https://www.wsj.com/articles/marriott-to-acquire-starwood-hotels-resorts-1447673866

Only very recently (early summer?) have they (finally!) merged their reservation and rewards system (prior to that, you had to manually/annoyingly request that Starwood points be converted into Marriott points).

Their IT systems were separate until quite recently. I think that is why the announcements made the point that the breach impacted Starwood (Sheraton) customers only, and not Marriott customers.

One can also assume that they had different IT departments prior to the merger, and one can hypothesize (but not know) that it was when the Marriott IT team got a good look at the Starwood IT infrastructure (and perhaps put their own security controls in place) that they noticed the breach. Speculating here: Perhaps if Marriott hadn’t absorbed Starwood the breach may still not be known.