Home

Podfeet Podcasts

Security Bits Logo

Security Bits – 14 July 2019

  • by Bart Busschots

    • Security Medium 0 (more of a Followup) — 3rd-party Parental Control Apps Return to iOS

    Editorial by Bart: I’ve seen some very lazy reporting on this story, and I think the context and nuance are important, hence giving this apparently simple story the ‘Security Medium’ treatment.

    To understand what happened this week, it’s important to cast our minds back to the very start of this story, and follow the events through from there to the present.

    * As best as I (Bart) can piece together from all the reporting, this all started back in April 2018 when Apple became aware of the potential for parental control apps to abuse Mobile Device Management (MDM) APIs to compromise user privacy.
    * During the remainder of 2018 Apple first investigated the potential issue and then started to contact developers asking them to stop using MDM for parental control. Having given developers some time to comply with those requests, Apple then began removing apps that did not alter their behaviour from the store. Without MDM many of the features these apps offered were not possible on iOS, so many developers refused to comply, and it seems that in December of 2018 Apple did a large purge of MDM-using parental control apps.
    * In April of 2019 the story first gained wide-spread notice when the NYT ran a very sensationalistic story claiming Apple removed the apps to prevent competition with the ScreenTime feature built into iOS. The story did not provide any evidence to support its claims, but being a negative story about Apple it inevitably went viral. (Editorial by Bart: the claims made by the NYT never made any sense because when you try follow the money you soon find there’s nothing to follow! Apple don’t monetise ScreenTime in any way, no subscription or paid upgrade to get extra features, nothing! If anything, Apple lose money on ScreenTime because it costs them developer time to create and maintain the feature, but it has no associated revenue stream.)
    * Apple responded to the NYT piece by pointing out that MDM was not intended for this use, and that it posed a real danger when used in this way. MDM was designed to allow organisations to centrally manage and control devices they own, it was not designed to allow app developers manage and control apps owned by app customers or their children!
    * One of the less-covered small announcements from WWDC was that Apple had updated their rules for the use of MDM. MDM could be used for parental control-type apps going forward, but under strict supervision from Apple. The apps would have to confine themselves to a sub-set of what the MDM APIs can theoretically do, and they would be subject to extra scrutiny from Apple during the app store approval process.
    * This week, the first such app, OurPact, successfully made its way through that extended review and returned to the iOS App Store

    Links:

    Security Medium 1 — Zoom & Ringcentral on the Mac

    Note: The focus of this story has been Zoom because it’s a very popular service, but the security researcher who found the bugs believes the *Ringcentral app by the same company is also vulnerable, though there does not appear to be a proof of concept for that app.*

    This week security researchers announced that they had found serious security vulnerabilities in the Mac client for the popular Zoom video conferring service. As well as installing the client their installer also installed a local web server app.

    Officially, this web server served two functions — it allowed the Zoom app to bypass the confirmation screen Safari 12 introduced before allowing apps access to users webcam, and, it would re-install the app automatically should the user try to join a Zoom call without having the app installed.

    Zoom considered both of these behaviours to be features that enhanced the user experience, and defended the web server’s existence. Even before we get it to the fact that the web server had vulnerabilities, let’s first look at whether this behaviour is ethical even if the web server was perfectly coded and did not contain any bugs or vulnerabilities.

    I would argue strongly that it’s not. Firstly, there was no informed consent. Users were not told that installing the Zoom client once installed a service that would remain running permanently, even after the app was un-installed, and that that permanently running service would grant webcam access automatically without confirmation from the user from that point forward. Users were also not clearly informed that this web service would act as a silent re-installer that would re-add and app they explicitly removed without even getting a confirmation from them. Speaking purely for myself (Bart), I consider this to be malicious behaviour. When an installer asks you to enter your password to grant it admin access we are trusting that that installer not to do anything more than it told us it would, and this installer clearly violated that trust. I can’t trust a company that could conscience such a move, so I’ve added Zoom to my personal naughty list, and am (probably) permanently boycotting them — maybe they can somehow re-earn my trust, but I can’t imagine how they could do that if I’m honest!

    So, even if the web server was perfectly coded, I would consider it malware, but, it was not! There were two problems with this web server:

    1. The web server was not limited to only accepting connections from the local device. There are legitimate reasons for apps to use a local web server, for example, it can enable inter-app communications between a helper app or plugins and a main app, but these kinds of local web servers are usually set up to only accept connections from the special localhost IP address 127.0.0.1 which can only be accessed from on the device itself. Zoom didn’t do that, so other users on the same LAN could interact with the web server. As best as I can tell, the only reason the web server would not generally be globally accessible is that most people use NAT routers, and a side-effect of NAT is that it acts as a one-way-valve on users internet connection. Security researchers were able to demonstrate that anyone who can talk to the web server can trigger a silent re-install of the Zoom app.
    2. Any website in the world could host a link that when clicked on would cause the local web server to launch Zoom, auto-join a meeting, and, if the users had no pro-actively changed the apps settings, auto-enable their webcam. So, you click on a link, and a few seconds later, your webcam is broadcasting your image to a call controlled by an attacker!

    Security researchers tried to work with Zoom to address these issues responsibly, but since Zoom didn’t agree the web server itself was fundamentally a security vulnerability, that didn’t work out, and the researchers went public with their findings, including proof of concept examples.

    Zoom initially responded with an update that addressed some of the bugs in the web server, but did not tackle the fundamental issue of the server’s existence, or its persistence even when the Zoom app is uninstalled. They also didn’t address the bypassing of the Safari 12 confirmation dialogue since they saw that as a feature, not a bug, and said so publicly.

    We feel that this is a legitimate solution to a poor user-experience problem, enabling our users to have faster, one-click-to-join meetings

    This initial response didn’t go down well with the broader internet community, and Zoom were soon forced to back-peddle!

    Zoom developed a second update that completely removes the web server and adds a menu option for uninstalling the app.

    Initially, we did not see the Web server or video-on posture as significant risks to our customers and, in fact, felt that these were essential to our seamless join process. But in hearing the outcry from our users in the past 24 hours, we have decided to make the updates to our service.

    While the big public argument was going on, engineers at Apple were busy responding to the situation through their process for dealing with a Mac malware outbreak, and prepared and pushed out a silent MacOS update that removed the web server. Apple have included an emergency auto-update feature that checks in with Apple daily as part of MacOS for many years now, and while they have used it on a few occasions before, they use it very sparingly. If you’re not comfortable with Apple pushing emergency security updates automatically, you can disable the behaviour from the Advanced window in the Software Update preference pane (I would not recommend doing this BTW).

    So, if you want to use Zoom, install their latest update.

    If you have never used Zoom, there’s nothing for you to do, but if you did use it once, and don’t want to use it in future, the advice I’m seeing most commonly from experts I trust is that you should install the latest update, and then remove the app. You could also just remove the app and trust Apple to clean up the web server if you prefer.

    Links:

    Security Medium 2 — 25 Million Android Devices Infected with Agent Smith Malware

    Security researches from the cyber-security firm Check Point have released details of a massive malware campaign that has successfully infected 25 million Android devices around the world, 300 thousand of them in the US.

    The malware was primarily distributed via 3rd-party app stores in China, and was able to spread by using a vulnerability in Android that allowed it to hijack legitimate apps as they updated themselves. The result would be a fully functional version of very popular apps like WhatsApp and Opera that also contained the malware. The malware could then use all the permissions the user had granted their host app.

    It’s not clear whether all the vulnerabilities exploited by the malware have been patched, but at least one of them was patched as far back as 2017. The fact that Android malware can spread widely in 2019 using a bug that Google patched in 2017 speaks volumes about how far Google still has to go to get their updates distributed widely and promptly.

    Another particularly note-worthy details discovered by the researchers is that until recently there were apps in the official Google Play store with dormant versions of this malware. The dormant copies of the malware would have been brought to life had those behind the campaign paid for an ad with a specific trigger word to be displayed by infected apps. While over 10 million infected but dormant apps were downloaded from the Play store, it does not appear the trigger word was ever sent to wake them up.

    The researchers give three pieces of advice to Android users:

    1. Keep your phone patched! (Editorial by Bart: if you can’t, you really do need to get a new phone!)
    2. Only download apps from the Play Store
    3. Run an ad blocker because “Ad blockers aren’t just to block ads”. The researchers point out that ads have a long history of being used to trigger exploits within legitimate apps, and in this case, they could have been used to activate malware downloaded from the Google Play store!

    One final silver lining here is that the attackers chose to use their powerful malware for ad fraud. This means infected users simply saw more ads or the wrong ads, and the attackers effectively stole money from ad networks rather than the owners of the infected phones. However, the big cloud within that silver lining is the fact that the same techniques could have been used to hijack banking apps and steal actual money directly from end-users!

    Links:

    Notable Security Updates

    Notable News

    Suggested Reading

    Suggested Listening

    • 🎧 A good description of the Zoom issue, the OpenID Foundation’s open letter to Apple regarding Sign in With Apple, and the major GDRP fines that made the news this week — The Checklist Episode 145: Zooming on Through — overcast.fm/…
    • 🎧 You’ve probably heard the term dark pattern as a term for commonly used design patterns that are designed to harm rather than help users. This episode of Reply All digs into one particularly egregious example of a dark pattern that’s resulting in many Americans needlessly paying Intuit for a service they’re entitled to get for free because of a deal the company struck with the US government. Reply All Episode 144: Dark Pattern — overcast.fm/…
    • 🎧 Reply All are on a real roll ATM, their next episode gives a very revealing insight into one of the darker sides of our modern world — the abuse of platforms like YouTube for bullying and harassment. Reply All Episode 145: Louder — overcast.fm/…

    Palate Cleansers

    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