Home

Podfeet Podcasts

Security Bits Logo no alpha channel

Security Bits – 21 September 2019

  • by Bart Busschots

    • Security Medium 1 — SimJacker

    A remotely exploitable vulnerability has been found in the firmware running on billions of SIM cards around the world. The vulnerability can be triggered by sending a malicious SMS message to the phone number served by the victim SIM card. Once the SIM card is infected it can then reach into the cellphone it is inserted into and exfiltrate sensitive data. The user won’t even see the SMS message that infected their SIM card because it’s a special type of SMS message used for network management and similar tasks by carriers.

    There is nothing end users can do to protect themselves, or, as far as I can tell, to even detect that their SIM card is infected. Thinking about it, getting firmware updates to all SIM cards in the world seems an impossible task, so my first fear was that there would be nothing that can be done to protect the billions of us around the world who use GSM-based cellphone networks.

    Thankfully, while end-users are powerless to protect themselves, there is someone who can protect us all — our carriers. The special SMS messages the attack relies on should only ever be used by carriers to manage their own network, so so such SMS messages should ever enter the network from outside. In fact, the carrier should know exactly which sources are valid for these messages since they should be the only source for them. This means that all that’s needed is some firewall config. Can we trust our carriers to actually follow through on this? I guess we’ll have to wait and see.

    Links

    Security Medium 2 — iOS 13, Bluetooth Permission & Surreptitious Location Data Gathering

    Apple have added a number of new privacy features into iOS 13, and one of them might seem a little strange at first glance, but it’s actually very sensible, and is having an immediate impact. Starting in iOS 13, apps will need your permission to make use of bluetooth.

    What has that got to do with privacy? It’s not something that’s been high on our collective radars, but apps have been using bluetooth devices installed at known locations to track users, even when they have location services disabled.

    So-called beacons are a good example of bluetooth being used to detect a person’s location. Just like with traditional location services, beacons are not inherently malicious, but they can be abused. Traditional location services based on cell towers, wifi signals, and GPS work well when you’re outside, and when you don’t need to know your position down to the nearest few feet, but, they’re useless in many indoor situations, especially when a price location is needed. Beacons were invented to solve this problem.

    If you’re wondering what beacons were intended to be used for, it’s things like venue apps that can accurately guide you to the important indoor landmarks like specific rooms or perhaps the nearest bathroom. You can be guided towards the correct route to your seat in large stadiums, to the correct shop in large malls, or told about the specific exhibits you’re standing in front in a museum. Entering greyer areas they can be used within stores to guide you towards specific products you like, or to particularly good deals. They can of course also be used to track how long you spend in each isle, hence figuring out the kinds of things that interest you most.

    In all these examples the user is interacting with an app that is explicitly providing them with location-based functionality. Where things go down-hill fast is when apps use bluetooth to infer your location behind your back without showing you what they are doing, let alone getting your permission. As users have become more and more hesitant about granting access to location information, seedy developers have started to rely on ever more indirect methods of inferring your location, including bluetooth.

    The only way to stamp out abuses of a useful feature without killing the legitimate uses is to make it impossible to use the feature behind users backs, hence Apple’s move to make apps ask for permission before they can use bluetooth.

    The bluetooth prompts aren’t the only location-related privacy changes iOS 13 brings. Apple are also introducing new notifications that will let you know how often and when apps that you grant location data access to make use of that access.

    These privacy improvements are highlighting all sorts of shady practices, and frightening companies like Facebook into pre-emptively attempting to explain what their apps do before users get to see for themselves, and presumably revolt.

    IMO Facebook deserve some extra criticism because not only were they using Bluetooth without telling users, their blog post ‘explaining’ their actions make it clear that even when you explicitly deny them location data they will still try to infer your location from information you can’t easily hide like you IP address. I can’t think of any way of describing doing the exact opposite of what the user explicitly told you to do is anything but user-hostile, and frankly obnoxious. I’m definitely more sure than ever that I made the right decision when I deleted my Facebook account about a decade ago.

    Bottom line — unless an app has a clear need for bluetooth access, say no, it’s probably an attempt to track your physical location 🙁

    Links

    Security Medium 3 — DoH Rolls Out to Major Browsers

    In a recent CCATP Lite I chatted with Allison about DNS over HTTPS, explaining the problems it solves, what it does, and how it does it. I ended by saying that DoH was ready for the vanguard of geekitude (nerds like us) to start experimenting with, that it was not quite ready for prime-time yet, but that it would be soon. Well, it turns out that ‘soon’ was much sooner than I imagined!

    As we discussed on CCATP, FireFox has DoH support and it can be enabled in the browsers settings. By default it will use Cloudflare’s 1.1.1.1 DNS resolvers. Starting in late September FireFox will start automatically enabling DoH for desktop FireFox users in the US. The roll out will be slow, and Mozilla will keep a close eye on how it goes. If things go well they’ll them push DoH by default to all users.

    Note that because of how iOS works, FireFox on iOS won’t be getting DoH via Mozilla. Apple will need to add DoH support to WebKit for that to be possible.

    Google are a little behind FireFox, but not by much. Starting with Chrome 78 (due on October 22nd), Chrome on Windows, Mac & Android will start to automatically upgrade users to DoH if their currently configured DNS provider supports DoH. In other words, they won’t change your DNS provider, instead, they’ll upgrade to using encrypted communications with that same server.

    There has been some criticism of browsers moving to DoH by default, (much of it ill-informed and utterly OTT IMO). Because Mozilla will be defaulting users to Cloudflare’s DNS resolves they are coming in for the strongest criticism.

    While I think its reasonable to gripe with defaulting people to a given provider rather than pro-actively offering them a choice, the other common criticism I’ve heard is factually wrong. It has been widely asserted that DoH will ‘break’ people’s networks. This is hogwash! However, it’s hogwash based on a kernel of truth, so it warrants deeper examination.

    It’s very common, especially in managed corporate environments, for the DNS resolvers computers are configured to use to have a so-called split horizon. This means that the resolvers host a bunch of private DNS records that don’t exist on the public internet, as well as resolving public DNS records. Without DoH browsers use the computer’s DNS services to do name lookups, so they will see the private records when there is a split horizon. If a browser starts to use DoH to a resolver that only resolvers public IPs (like the one from Cloudflare FireFox will use) for everything, then private sites will stop working in that browser. That could cause chaos within a corporate environment.

    So, it is true that if FireFox were to simply enable DoH for all DNS queries in all situations they would break things, but that’s not what they’re doing! Firstly, they’re automatically detecting a number of common scenarios in which automatic DoH would not be desirable (including managed corporate environments and parental control software that filters DNS queries), and not automatically enabling DoH in those situations. Secondly, they are implementing OS-fallback, so if an address fails to resolve over DoH they’ll ask the OS for the same DNS query, just like they did before DoH. This means you get the security of DoH when ever possible, while retaining all the functionality you had before, including support for split horizons.

    Bottom line, if you want DoH you’ll soon be able to pro-actively enable it on both FireFox and Chrome, and if you do nothing, you may well get some added security for free, and it’s extremely unlikely to cause you any problems what so ever. So basically, win-win as far as I’m concerned!

    Links

    Notable Security Updates

    Notable News

    Suggested Reading

    Note: 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.

    Leave a Reply

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

    Scroll to top