Home

Podfeet Podcasts

Security Bits Logo no alpha channel

Security Bits — 8 March 2020

  • by Bart Busschots

    • Feedback & Followups

    Deep Dive(s)

    The Darkside of the iOS Clipboard

    Security researchers have demonstrated an interesting new abuse of the clipboard on iOS.

    For context, it’s important to bear in mind that iOS has been developed from the start to provide very strong isolation between apps. Initially apps were complete island universes onto themselves, and Apple have only very slowly added mechanisms for moving information between apps. While doing so, Apple have been very careful to keep that flow of information in the user’s control. In theory, unless a user pro-actively shares information between one app and another, apps absolutely cannot see each other’s data.

    What the researchers realised is that Apple’s clipboard APIs can be abused by malicious data to read information that originated in other apps that the user did not explicitly grant them access to.

    It turns out that background apps can paste from the clipboard as often as they like, allowing them to monitor for interesting information the user did not intend to share with them. Worse still, Today Widgets can do the same thing!

    The real kicker is that this behaviour extends to the so-called Universal Clipboard, the single unified clipboard managed by iCloud allowing you to copy on one device and paste on another. This means a malicious iOS app could see data copied on other iOS devices, or even Macs!

    Some data that often ends up on the clipboard can be a lot more revealing that users realise — an example pointed to by the security researchers is photos which still contain their EXIF data, which often includes GPS coordinates. Over time this could allow a malicious app to track your location quite accurately.

    For now at least, Apple are not considering this a vulnerability, so our only defence is to be selective about the apps we install. This has been my advice all along anyway, so it doesn’t change anything for me.

    If we start to see this technique used in the wild Apple could limit access to the clipboard to foreground apps, or, at the very least, block access to the clipboard for Today Widgets. Apple could even go so far as to make the user explicitly grant apps clipboard access. Only time will tell what Apple will choose to do about this weakness going forward.

    Links

    Safari Mandates 1 Year Certs?

    Questions from Allison:

    • Remind us what a certificate is?
      • What does it protect us against?
      • What does it not protect us against?
    • I’ve heard they’re not called SSL certs any longer, why is that?
    • What did Apple announce about this with regard to Safari?
    • It was a discussion item in a standards body from what I understand. Do we know why the other members didn’t want to do this when Apple pushed for it?
    • What is the real impact on web site providers?
    • What is the increase in safety to the end user over time?

    What is a Certificate?

    Note: we recorded a more detailed look at certificates etc. back in 2013.

    The maths at the heart of our Public Key Infrastructure (PKI) is so-called asymmetric encryption. Regular (symmetric) encryption is quite simple to understand — you take some plain-text, you use an algorithm that makes use of a key to turn that into encrypted text. To de-crypt you run the process in reverse, using the original key.

    Asymmetric Crypto is different — rather than a single key there is a key-pair. Anything encrypted with one of the pair can only be decrypted by the other. Note that both of the keys in the pair can be used to encrypt. When key-pairs are generated one is arbitrarily chosen to be kept secret and hence forth referred to as the private key, the other then becomes the so-called public key.

    The other vitally important piece of the PKI-puzzle is so-called digest, or hashing, algorithms. These take an arbitrarily long piece of plain text and digest it into a fixed-length fingerprint. For a digest to be considered cryptographically secure the following must be true:

    1. the algorithm must be one-way — it should be easy to go from pain-text to digest, but so difficult as to be effectively impossible to go from digest to plain-text.
    2. small changes in input must result in large changes in the digest
    3. it must not be feasible to alter the plain-text input in such a way as to cause it to digest to a specific desired value. You’ll hear this referred to as digests needing to be robust against collisions.

    A digital signature is a digest of some digital content that has been encrypted by a private key. Anyone with the public key can de-crypt the signature and re-calculate the digest to verify that the signed content has not been altered since it was signed, and that it was definitely signed by the private key that matches the public key.

    At the root of the PKI is a collection if pre-shared trusted public keys belonging to the so-called Certificate Authorities, or CAs. We refer to the CAs as the trust anchors of the PKI. Our OSes and browsers ship with the public keys for the trusted CAs, and software updates are needed to update them.

    A digital certificate is a public key and some meta-data that has been digitally signed by a certificate authority.

    There is a common format for these certs and their metadata that you may have heard of — X.509. It’s the metadata within the X.509 cert that determines what a cert can be used for. X.509 is used throughout the PKI to secure all sorts of things, not just HTTPS websites.

    Digital certificates can be used to encrypt and/or digitally sign digital content.

    Digital certificates are a vital component in the TLS/SSL suite of protocols that are at the heart of many of our secure protocols, including HTTPS for web browsing, many VPN protocols, and the secured versions of our email protocols.

    Everything up to this point applies very broadly, from here on we’ll be focusing on HTTPS, the secure web protocol.

    The Security Guarantees Offered by HTTPS

    HTTPS makes the following security guarantees:

    1. Confidentiality — information sent over HTTPS is encrypted and can only be read by the web server and web client, not by anyone in between.
    2. Integrity — the information sent over HTTPS has not been changed by anyone en-route.
    3. Authenticity — the information sent over an HTTPS request was sent by the owner of the certificate. Depending on the type of certificate that is more or less meaningfulL
      • Domain Control Validation (DCV or DV) — the certificate was issued to a person who has proven they control the domain name(s) the certificate is valid for. This is the lowest form of valuation, and what you get from automated services like Let’s Encrypt. It tells you you really are at the URL you think you are, but nothing more.
      • Organisation Validation (OV) — the certificate was issued to a person who has provided evidence they represent a specific named organisation and control the domain. The same as DCV, but also asserts an organisation.
      • Extended Validation (EV) — the same as OV but with more stringent rules.

    HTTPS does not make any sort of assertion about the trustworthiness of any website or organisation!

    A website being secure just means you are securely communicating with the owner of the domain in your address bar, or with someone who stole the private key belonging to the owner of the website.

    If your browser shows a padlock and the URL https://palpay.com/ and a page that looks identical to PayPal the padlock does not mean you are safe! You are simply securely sending your information to the bad guys!

    SSL or TLS?

    SSL is the old term, TLS the new. The first three versions of the protocol we now know as Transport Layer Security (TLS) were known as the Secure Socket Layer (SSL). TLS 1.0 is effectively SSL4.

    What Did Apple Announce?

    Safari will not accept any server certificate with a start date on or after the 1st of September 2020 that has a validity period of longer than 1 year as valid. In other words, all certs issued from September 2020 need to be 1 year or shorter or Safari will always mark them as invalid, regardless of whether or not they are properly signed by a trusted CA.

    This is a unilateral move by Apple, but given the prevalence of iOS, if effectively means all website owners will be limited to one-year certificates the next time their certificate expires.

    For context — almost exactly two years ago (1 March 2018), the CA forum collectively agree to reducing the maximum age for certificates from 3 years to two.

    Do we Know why Apple Chose to do a Solo Run This Time?

    Nope! (At least I don’t 🙂)

    What’s the Impact?

    For automated DVC certificate authorities like Let’s Encrypt this change has no effect at all — automated CAs already work off much shorter certificate life-time of 3 months.

    For certificate authorities issuing OV and EV certs like DigiCert this will require them to issue fresh certs twice as often for their customers. The issuance of certificates is not a big drain on CA resources though, so this will have a minimal impact. The real work of CAs is the organisation validation, and that has to be performed on an annual basis anyway.

    The biggest impact is on website owners. Running a website with an OV or EV cert will now require a new certificate be requested and installed twice as often.

    Thankfully it’s not looking like website owners will be charged more per-annum for their certificates. Details are still emerging, but an approach that is gaining traction is that of selling certificate subscriptions. The idea is that customers buy the right to a certificate for 3, 5, or even 10 years, and they can have that certificate re-issued as often as they like during that subscription.

    Does This Make us Safer?

    Yes, but only a little. IMO, this is a poor solution that’s easy to achieve because the CA forum are too timid or toothless to tackle the actual problem in an effective way.

    It’s all About Revocation, or Rather, the Lack of it!

    In theory, a certificate owner can ask a CA to revoke their certificate at any time. The most likely reason to want to do this would be a loss of control over the certificate’s private key, usually as a result of a hack or an accidental leak. Once the website owner realises they have lost control over their private key, they would request the existing certificate be revoked, the CA would oblige, and all browsers would start rejecting the cert. The website owner would then generate a new key-pair, and ask their CA to use their new public key as the basis for a fresh certificate.

    This all works as expected right up to the bit where browsers are supposed to check for certificate revocations and start rejecting the revoked cert. For efficiency reasons, no modern browsers effectively check for certificate revocations. This means certs effectively always live until their expiration date, even when the private key is compromised.

    The simplest solution to this problem is to reduce the validity period of certs, and that’s what the CA forum did two years ago, and what Apple continued with this announcement.

    How we got to this mess is interesting.

    The original approach for revocation was so-called CRLs, or Certificate Revocation Lists — simply black-lists of key fingerprints published by the CAs. When only a handful of websites used certificates it was practical for browsers to download the latest CRLs once a week, or even daily, and to keep a list of all known-revoked certs within the browser, and check each site against that list each time the user surfed to a secure URL.

    CRLs simply did not scale.

    The next approach was a real-time protocol hosted by the CAs, the so-called Online Certificate Status Protocol, or OCSP. Each CA would run an OCSP web server and the URL for that server would be embedded in each certificate they issued. Browsers would then check the URL for the cert each time a user browsed to a secure site.

    This proved impractical for a few reasons — it added extra work onto the browser, slowing things down, it required the CAs to run an ultra-efficient and reliable website, which they proved incapable of doing, and it required browsers to treat a failure to reach the OSCP server as a certificate failure. That opened users up to trivial denial of service attacks, because while a man-in-the-middle couldn’t alter the response from the OCSP server, they could simply block it!

    That’s how we arrived at today’s mess where browsers simply don’t even try to do any kind of reliable certificate revocation checking.

    OCSP Stapling Would be a Real Solution

    Most annoyingly, we now have a viable fix of the revocation problem — a technology called OCSP Stapling. Rather than the browser having to check the OCSP status of the cert, the web server periodically fetches a fresh short-lived OCSP assertion from the CA that the certificate has not been revoked, and attaches this assertion to the certificate that gets handed to the browser. The assertion is digitally signed by the CA, so the browser can validate it in the same way it validates the certificate itself.

    OCSP stapling exists, and works, but support is patchy. According to Steve Gibson on the most recent Security Now podcast, Microsoft’s IIS is the only web server with robust OCSP Stapling support ATM, and FireFox the only browser with mature OCSP Stapling support. There is some nascent support in Apache and NGINX, but it’s not ready for the big-time yet.

    If the CAs, browser vendors, and web server vendors got together and agreed to commit fully to OCSP stapling, the revocation problem could be solved within a year, with no need for ineffective hacks like simply reducing certificate lifetimes!

    ❗ Action Alerts

    Worthy Warnings

    Notable News

    Top Tips

    Excellent Explainers

    Interesting Insights

    Palate Cleansers

    From Twitter: “@ChrisBernie42: Due to #COVIDー19, all TCP applications will be converted to UDP to avoid handshakes. 🤓”

    Legend

    When the textual description of a link is part of the link it is the title of the page being linked to, when the text describing a link is not part of the link it is a description written by Bart.

    Emoji Meaning
    🎧 A link to audio content, probably a podcast.
    ❗ A call to action.
    flag The story is particularly relevant to people living in a specific country, or, the organisation the story is about is affiliated with the government of a specific country.
    📊 A link to graphical content, probably a chart, graph, or diagram.
    🧯 A story that has been over-hyped in the media, or, “no need to light your hair on fire” 🙂
    💵 A link to an article behind a pay-wall.
    📌 A pinned story, i.e. one to keep an eye on that’s likely to develop into something significant in the future.
    🎩 A tip of the hat to thank a member of the community for bringing the story to our attention.

    Leave a Reply

    Your email address will not be published. Required fields are marked *

    Scroll to top