Home

Podfeet Podcasts

Security Bits – 30 September 2017

  • by Bart Busschots
  • 4 Comments

    • From Allison: I’ve just decided that it might be a nice enhancement to the podcast and blog if you could see Security Bits as a stand-alone blog post. Makes it easier to find and more importantly easier to reference when sharing with others. Bart will be shown as the author (since he IS the author) but I’ll write the excerpt for each post.

    In this week’s action-packed Security Bits, Bart brings some follow-up on the Equifax breach and more details about Apple’s Face ID. We have three security mediums this week. We cover the CCleaner compromise which infected over 2 million machines. Then we talk about the macOS Keychain vulnerability that was announced this week for macOS (something for everyone). In the third “medium” Bart explains cookies from inception and why they’re needed, through their evolution to help us into something that can track us. He walks us through all of this so we can understand how the changes Apple made in Safari 11 are reducing the tracking and why it’s making some types of advertisers cranky at Apple. Finally, Bart goes through Notable Security Updates, Notable News, Suggested Reading and has a couple of nice palette cleansers.

    Follow-up

    Security Medium 1 – CCleaner Compromised

    Attackers managed to inject malware into some downloads of the popular free Windows app CCleaner. The malware was not injected into all downloads, but it was downloaded more than 2 million times! The tainted downloads occurred in August and September of this year.

    When the tainted installer is run it phones home and asks for instructions. It seems the malware was designed to only truly attack a small number of carefully chosen targets – only infected machines phoning home from target networks were instructed to deploy their malicious payloads. The basic idea seems to be to spray the malware as far and wide as possible, hoping it gets in behind the corporate firewalls of a handful of carefully chosen high-value targets.

    This appears to be sophisticated malware deployed in a sophisticated attack, leading analysts to speculate that this is probably a state-sponsored attack.

    Links

    Security Medium 2 – keychainStealer macOS Keychain Vulnerability

    Security researcher Patrick Wardle discovered a zero-day exploit in macOS which allows an un-signed malicious app to read the full contents of a user’s Keychain when the user executes the app, and all without needing the user’s password. The vulnerability has been given the name keychainStealer.

    This is not a remote attack, so the sky is not falling, but it is still a significant bug because it means that you’re implicitly trusting every app you run not to steal the contents of your Keychain.

    It’s going to take Apple some time to fix this bug, so in the meantime, the standard advice is only ever running apps you trust downloaded from a source you trust goes double.

    Since the bug exists in both Sierra and High Sierra, this is not a reason not to upgrade.

    Links

    Security Medium 3 – Safari’s New Anti-Tracking Features

    Apple’s recently released update to their Safari browser comes with some nice new security and privacy features. While the most widely welcomes user-facing feature is the blocking of auto-play videos, the most significant privacy feature isn’t at all obvious to end-users.

    Apple have changed how Safari deals with Cookies so that it intelligently nips tracking cookies in the bud.

    Web trackers like those used by Google and Facebook rely on third-party cookies, and on those cookies being preserved in the long-term. Third party cookies have important legitimate uses, so blocking them completely brings along nasty side-effects, so that’s not what Apple have done. Instead, they’ve added some intelligence to how they treat third-party cookies that should let you have your cake and eat it too – allowing the desired uses of third-party cookies to continue to work, but blocking long-term tracking.

    To understand what Apple are doing, we first need to understand cookies in general, and then third-party cookies.

    The web was initially designed to be a stateless place. Your browser made a request for a URL to a server and got a reply. Then your browser made another request to another server and got another reply. Even if those requests were to the same server, there was no relationship between the requests – they were totally independent things. For a read-only web that’s fine, but without some kind of persistent state between requests, you can’t have any kind of long-term interaction with a website. If a server sees every request as separate, then it can’t maintain a shopping cart as you browse around a shop, or remember that you’ve logged into a site – the early web was like the proverbial gold-fish, it forgot about you the moment you clicked on a link or pressed a button!

    Cookies were retro-fitted to the HTTP protocol to work around this shortcoming. A cookie is nothing more to less than a token created by the web server but stored by the browser. A server that wants to remember generates a cookie, stores something about that cookie on its end, usually some kind of session ID, then hands the cookie to the browser on the understanding that the browser will store that cookie, and that from that point on, until the cookie expires, the browser will include a copy of it in every request it makes to that website.

    So – the first time you land on a website that wants to have a stateful relationship with you your browser won’t send a cookie because it won’t have one. The server will see that lack of a cookie and create a new so-called session for you, and generate a token to represent that session, usually a long random blob of text – we’ll just use ABBA123. The server keeps a copy of that session ID, and it tags everything about your interaction with the server with that ID. It then hands your browser that ID in a cookie. The browser gets the cookie and stores it. From then on, every time you go to that same site, the browser checks if it has a cookie for that site, it does, so it includes the cookie in the request headers. The server then gets a request, sees the cookie, so it knows this request is part of the session ABBA123, and can remember you and can know that you have 5 items in your cart, or that you are logged in, etc..

    That’s a first-party cookie; the URL you typed in the address bar gave you a cookie and your browser stores and returns it. You’re the first party, and the website you typed into the browser is the second party.

    So where does this so-called third party come from?

    When you visit a website, say www.bartb.ie, that site will return some HTML to your browser, which it will then interpret and display. That HTML can contain references to resources that it should fetch from other URLs – things like images, style sheets, and JavaScript files. Your browser has to make a request to a web server to fetch each of these resources. If all the URLs needed to render the original URL all point to the same website, then what you get is multiple requests between the same two parties, so the same cookie flies over and back multiple times until your browser has all the parts, and can display the page.

    But – there is no reason all the resources needed to build out a page have to come from the same site – the HTML for the original URL you browsed to can include URLs to other sites. When you go to www.bartb.ie you see a collection of my most recent photos – those are not coming from www.bartb.ie, they are coming from one of Flickr’s servers. Flickr just became a third party. You went to www.bartb.ie, but you got content from both www.bartb.ie and Flickr. You’re the first party, www.bartb.ie is the second party, and Flickr is the third party.

    There is nothing magical about an HTTP request going to a third party – an HTTP request is an HTTP request is an HTTP request – if your browser has a cookie for the third party site, it will include that cookie when it makes its request.

    So, when you go to www.bartb.ie your browser will include the cookie from my site in every request you make to my site, and it will include the cookie from Flickr in every request sent to Flickr to fetch the photos.

    So how does this enable tracking? Well – those third-party requests don’t only contain cookies – they also contain a so-called* HTTP Referrer*. Basically, the request to Flickr contains the original URL of the page the image is being loaded into.

    So – third parties know the URL of the first-party page, and, they get to give and receive cookies. If a third party can strike deals with millions of first-party sites that users actually visit to include an image or some other resource with a URL on the tracker’s server, then as users browse the web, they will keep having third-party interactions with the tracker, and those interactions will include the unique cookie the tracker gave the user, and, the URL the user is currently at. BOOM – tracking!

    This is why Facebook wants everyone to have a Like button – that button is an image that your browser has to fetch from Facebook’s servers. Each time you see a like button, Facebook knows you were at that URL! The same is true for all those other share buttons you see around the web.

    Images are at least visible, there’s no need for the third-party to be obvious, and the big-boy trackers like DoubleClick don’t use obvious images to track you – they just ask website owners to include a some JavaScript from one of their servers. The JavaScript doesn’t even have to do anything – the URL to it just has to be on the page so browsers will interact with DoubleClick’s servers. The user sees nothing from DoubleClick on the page, but behind the scenes, your browser had a conversation with DoubleClick, and they tracked your page view.

    Notice that with trackers like DoubleClick you, the user, have almost certainly never had a first-party relationship with DoubleClick – you’re visiting their home page – why would you! You only ever have a third-party relationship with these kinds of trackers.

    Blocking third-party cookies completely instantly neuters trackers like DoubleClick. If your browser never even stores a third party’s cookie then it can never send it back to the server, so the third party can never connect the dots – you’ll look like a completely new person every time the tracker meets you.

    A key point to note is that until now, browsers have generally maintained one single list of all cookies (called a cookie jar, seriously!). So, all your tabs in all your windows share one big cookie jar, so each and every time you interact with a tracker it’s always the same cookie from the same jar.

    So what are Apple doing differently in this new version of Safari? Apple are intelligently using separate cookie jars depending on what you the user are doing.

    If a third party hands Safari a cookie, and if you, the user, have not had a first-party relationship with that third party recently, then the cookie doesn’t go into the big jar, it goes into a temporary jar associated with the specific first party you’re visiting.

    Imagine both myself and Allison became evil and wanted to track you. We would set up www.eviltracker.com, and we would both include a URL to an invisible JavaScript file into both www.podfeet.com and www.bartb.ie. With a single cookie jar, your browser would send the same cookie for www.eviltracker.com as you navigated around both of our sites. Our tracker could watch as you moved from one of our sites to the other and know it was the same person. We could then start asking all our friends to include our tracker too, and start watching you as you went to the Mac Cast, to Mac Voices, and so on and so forth.

    Now – at no point have you ever intentionally visited www.eviltracker.com – you have only ever had a third-party relationship with it. Never a first-party one.

    So now you upgrade to the latest Safari, how do things change? You go to www.bartb.ie, it includes the script on www.eviltracker.com, so your browser dutifully makes the request to the third party, and a cookie gets created. New Safari checks to see if you have ever had a first-party relationship with www.eviltracker.com – you have not. So it does not put the cookie into the big central jar. It creates a temporary jar that only exists for www.bartb.ie, and it puts the cookie from www.eviltracker.com into that jar. From then on, whenever www.bartb.ie references www.eviltracker.com in a third-party context, Safari uses the special jar for www.bartb.ie and sends www.eviltracker.com that cookie. You still have state with the tracker, and it can see that you are on www.bartb.ie.

    Then you go to www.podfeet.com, and again, there is a third-party request to www.eviltracker.com. Safari checks whether or not you have a recent first-party relationship with www.eviltracker.com, and you do not – it then creates a whole new temporary cookie jar for www.podfeet.com, and pretends to www.eviltracker.com that it has no cookie for it. The tracker creates a new session, hands that cookie to Safari, and it saves it in the second jar. Then, as your browser around podfeet.com it dutifully returns that second cookie to the tracker. The tracker can watch as you move around podfeet.com.

    However – you now have two completely separate cookies for www.eviltracker.com – so it sees you browsing www.bartb.ie as a totally different person to you browsing www.podfeet.com – tracking has been stopped dead!

    Now – there is something very important you must notice – this does not stop sites with which you DO have a first-party relationship from tracking you!

    If you are a Facebook users, and actively browse to the Facebook site, then you have a first-party relationship with Facebook, so, Safari WILL send your true Facebook cookie each time you see a like button.

    However, people like me, people who do not use Facebook, we will not have a first-party relationship with Facebook, so we will not be trackable by Facebook.

    Now – most trackers don’t belong to sites that provide services to regular users, so we won’t have first-party relationships with those sites. So, this will stop the DoubleClicks of this world in their tracks. This is, of course, making the ad industry very very cranky indeed 🙂

    There is also a little confusion because the latest Safari has also added opt-in anonymous tracking of website performance. The feature uses differential privacy to protect user privacy and is tracking the performance of websites, not the browsing habits of users. Some news sites don’t seem to understand this rather important distinction.

    Links

    Notable Security Updates

    • Remember that all Apple’s new OSes contain security updates – www.intego.com/…
    • A critical security update has been release for the Mac app iTerm2 to fix a bizarre bug that could leak passwords via DNS queries – nakedsecurity.sophos.com/…

    Notable News

    Suggested Reading

    Palate Cleansers

    4 thoughts on “Security Bits – 30 September 2017”

    1. William Benson - October 1, 2017

      I like it! Even better: provide an rss feed to add to our rss reader so we can be rapidly informed when there is a new post.

    2. Charles Gousha - October 5, 2017

      A question on third-party cookies, particularly with Facebook:
      All well and good that Safari will treat all of those “like” buttons as third-party items… but only as long as they remain third-party. From the sounds of it, the MOMENT I click on a link to Facebook.com — for whatever reason — I’ve established a first-party relationship with them, and the tracking resumes. Did I miss something?
      Perhaps more importantly, is there a good way to remedy this if I’ve mistakenly clicked on one of their links?

    3. Jan - October 8, 2017

      second the RSS! would be VERY nice

    4. Digital Steps - April 5, 2021

      DigitalSteps.in: Complete SEO Solution and Digital Marketing Company in India. At Digital Steps, our agency plays the role of a web designer, web developer, and also does online marketing. So, the digital agency has competence in all these three segments of the business.

    Leave a Reply

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

    Scroll to top