Betrayed by the Guardian: Security and Privacy Risks of Parental Control Solutions
S. Ali, M. Elgharabawy, Q. Duchaussoy, M. Mannan, A. Youssef
BBetrayed by the Guardian:Security and Privacy Risks of Parental Control Solutions
Suzan Ali [email protected] UniversityMontreal, Quebec, Canada
Mounir Elgharabawy [email protected] UniversityMontreal, Quebec, Canada
Quentin Duchaussoy [email protected] UniversityMontreal, Quebec, Canada
Mohammad Mannan [email protected] UniversityMontreal, Quebec, Canada
Amr Youssef [email protected] UniversityMontreal, Quebec, Canada
ABSTRACT
For parents of young children and adolescents, the digital age has in-troduced many new challenges, including excessive screen time, in-appropriate online content, cyber predators, and cyberbullying. Toaddress these challenges, many parents rely on numerous parentalcontrol solutions on different platforms, including parental con-trol network devices (e.g., WiFi routers) and software applicationson mobile devices and laptops. While these parental control solu-tions may help digital parenting, they may also introduce serioussecurity and privacy risks to children and parents, due to theirelevated privileges and having access to a significant amount ofprivacy-sensitive data. In this paper, we present an experimentalframework for systematically evaluating security and privacy is-sues in parental control software and hardware solutions. Using thedeveloped framework, we provide the first comprehensive studyof parental control tools on multiple platforms including networkdevices, Windows applications, Chrome extensions and Androidapps. Our analysis uncovers pervasive security and privacy issuesthat can lead to leakage of private information, and/or allow anadversary to fully control the parental control solution, and therebymay directly aid cyberbullying and cyber predators.
CCS CONCEPTS • Security and privacy → Systems security . KEYWORDS
Parental control network devices, Android apps, Windows applica-tions, Web extensions, Privacy, Security
ACM Reference Format:
Suzan Ali, Mounir Elgharabawy, Quentin Duchaussoy, Mohammad Mannan,and Amr Youssef. 2020. Betrayed by the Guardian: Security and Privacy Risksof Parental Control Solutions. In
Annual Computer Security Applications
Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page. Copyrights for components of this work owned by others than theauthor(s) must be honored. Abstracting with credit is permitted. To copy otherwise, orrepublish, to post on servers or to redistribute to lists, requires prior specific permissionand/or a fee. Request permissions from [email protected].
ACSAC 2020, December 7–11, 2020, Austin, USA © 2020 Copyright held by the owner/author(s). Publication rights licensed to ACM.ACM ISBN 978-1-4503-8858-0/20/12...$15.00https://doi.org/10.1145/3427228.3427287
Conference (ACSAC 2020), December 7–11, 2020, Austin, USA.
ACM, NewYork, NY, USA, 15 pages. https://doi.org/10.1145/3427228.3427287
Many of today’s children cannot imagine their daily lives withoutinternet. A recent survey [66] shows that 42% of US children (4–14years) spend over 30 hours a week on their phones; nearly 70% ofparents think that such use has a positive effect on their children’sdevelopment [66]. While the web could be an excellent environmentfor learning and socializing, there is also a plethora of online contentthat can be seriously damaging to children. In addition, children areby nature vulnerable to online exploitation and other risk effectsof online social networking, including cyber-bullying and evencyber-crimes (see e.g., [3, 20]); the current COVID-19 pandemic hasonly increased these risks (see e.g., [73]).To provide a safe, controlled internet experience, many parentsand school administrators rely on parental control solutions thatare easily accessible either for free, or for a relatively cheap price.From recent surveys in the US, some forms of parental controlapps/services are used by 26–39% of parents [17, 53], indicating agrowing adoption of these solutions. Such solutions are also recom-mended by government agencies, e.g., US FTC [31] and UK Councilfor Child Internet Safety (UKCCIS) [72], despite their limited ef-fectiveness (cf. EU commissioned benchmark at: sipbench.eu), andquestionable morality since they, arguably, can act as surveillancetools [79]. This ethical/moral debate is outside the scope of ourwork.On the other hand, over the past few years, many attacks tar-geted parental control solutions, exposing monitored children’sdata, sometimes at a large scale [46, 54]. Aside from endanger-ing children’s safety (online and in the real-world), such leakedchildren’s personal data may be sold by criminals (cf. [81]). Re-cent reports also revealed several security and privacy issues inthe analyzed parental control solutions [4, 28, 77]. However, suchanalysis was limited to the privacy of Android apps, and only onenetwork device, even though popular parental control solutionsare used across different platforms: mobile and desktop OSes, webextensions, and network devices. Note that, unlike other vulnerableproducts (e.g., buggy gaming apps [78]), or non-complaint products(e.g., Android apps for children [62]), which can be removed whensuch concerns are known, parental control solutions are deemed a r X i v : . [ c s . CR ] D ec CSAC 2020, December 7–11, 2020, Austin, USA S. Ali et al. essential by many parents and schools, and thus are not expectedto be removed due to the lack of better alternatives.We undertake the first comprehensive study to analyze differ-ent types of parental control hardware and software solutions. Wedesign a set of security and privacy tests, and systematically ana-lyze popular representative parental control solutions available innetwork devices, Windows and Android OSes, and Chrome exten-sions. While developing our comprehensive analysis framework forsolutions in multiple platforms, we faced several challenges. Mostparental control solutions implement various techniques that hin-der traffic analysis (e.g., VPNs, SSLpinning and custom protocols).The use of proprietary firmware and code obfuscation techniquesalso poses challenges for static analysis. Understanding long-termbehaviors of these solutions by running them for hours/days in a re-alistic way (e.g., triggering all their features), is also time consuming(compared to simple, automated UI fuzzing).
Contributions.
Our contributions can be summarized as follows.(i) We developed an experimental framework for systematicallyevaluating security and privacy issues in parental control softwareand hardware solutions. (ii) We utilized this framework to conductthe first comprehensive study of parental control tools on multipleplatforms, including 8 network devices, 8 Windows applications,10 Chrome extensions, and 29 Android apps representing 13 An-droid solutions grouped by vendor. The in-depth analysis aims toinspect the apps’ web traffic for personally identifiable information(PII) leakage, insecure API endpoints authentication, potential vul-nerabilities, and the presence of third-parties and known trackers.(iii) Our analysis reveals 135 vulnerabilities among the solutionstested and highlights that the majority of solutions broadly fail toadequately preserve the security and privacy of their users—bothchildren and parents.
Notable findings and disclosure.
Our notable findings include: • The Blocksi parental control router allows remote commandinjections, enabling an attacker with a parent’s email address toeavesdrop/modify the home network’s traffic, or use the devicein a botnet (cf. Mirai [8]). Blocksi’s firmware update mechanismis also completely vulnerable to a network attacker. • • • • Among the parental control tools with a web interface, 9/13Android solutions, 4/8 network devices, and 3/8 Windows ap-plications are vulnerable to SSLStrip attacks (cf. [43, 44]), aman-in-the-middle (MITM) attack, due to the lack of HSTS. • An Android solution is typically composed of a child app, a parent app, and anonline parental dashboard. We consider an Android solution vulnerable if any of itscomponent is vulnerable. (Kidswatch) completely lacks HTTPS, and communicates withthe backend server via HTTP. • In this section, we first list a few example cases from real-worlddata breaches involving parental control tools, and then summarizerelated academic studies (mostly privacy analyses of Android apps).Over the past years, several parental control tools have made thenews for security and privacy breaches. The teen-monitoring appTeenSafe leaked thousands of children’s Apple IDs, email addressesand passwords [46]. Family Orbit exposed nearly 281 GB of chil-dren data from an unsecured cloud server [54]. In 2019, a privacyflaw in Kaspersky anti-virus and parental control application wasfound [24]. This application included a script to perform contentchecking on each page intercepted by a TLS proxy. However, someunique IDs were also included in the process, allowing the web-site to track the user. In 2010, EchoMetrix settled US FTC chargesfor collecting and selling children’s information to third-partiesthrough their parental control software [25].Between 2015 and 2017, researchers from the Citizen Lab (citizen-lab.ca), Cure53 (cure53.de), and OpenNet Korea (opennetkorea.org)published a series of technical audits of three popular Korean par-enting apps mandated by the Korean government, Smart Sheriff,Cyber Security Zone and Smart Dream [4]. The security auditsfound serious security and privacy issues in the three parental con-trol Android apps. For example, Smart Sheriff failed to adequatelyencrypt PII either on storage or in transit. Smart Dream allowedunauthorized access to children’s messages and search history.Feal et al. [28] studied 46 parental control Android apps for datacollection and data sharing practices, and the completeness andcorrectness of their privacy policies. They used the Lumen Androidapp (see https://haystack.mobi/) for their analysis, which is unableto analyze target apps with VPN or certificate pinning. Parentalapps and dashboards are also excluded. Our analysis frameworkhas no such limitations, and consequently we are able to identifynew critical security issues (e.g., leakage of plaintext authenticationinformation), even among the apps analyzed by Feal et al.Reyes et al. [62] analyzed children Android apps for COPPA com-pliance. Out of 5855 apps, the majority of the analyzed apps werefound to potentially violate COPPA, and 19% were found to send PIIin their network traces. Wisniewski et al. [79] evaluated 42 features etrayed by the Guardian ACSAC 2020, December 7–11, 2020, Austin, USA in 75 parental control Android apps, showing that most apps valuecontrol over self-regulation strategies, and boast the use of privacyinvasive techniques. Marsh [47] measured the effectiveness andusability of two parental control apps.Web extensions have been subjected to security evaluation forover a decade (see e.g., [14, 69]), but no past studies focused onparental control extensions. Windows parental control applicationshave been only studied for the security of their TLS proxies [19].Similarly, parental control network devices remained unexplored,except the Disney Circle, analyzed by Cisco Talos in 2017, andfound to have 23 different security vulnerabilities [77]. Amongother devices, we also analyzed Circle, but used a newer versionreleased in 2019.In contrast to previous work, we conduct a comprehensive, sys-tematic study of security and privacy threats in parental control so-lutions across multiple platforms: mobile (Android), desktop (Win-dows), web browser (Chrome extensions) and stand-alone networkdevices, as popular solutions are available in all these platforms.Our analysis therefore sheds light on the broader picture of securityand privacy risks of parental control tools. Compared to existingAndroid app studies, our framework is more in-depth (e.g., moni-toring the apps from the OS instead of the application level), andinclusive (e.g., analyze apps with VPNs and key pinning).
We use the term “parental control tools” to cover different types ofparental solutions: network devices, Android apps, Chrome exten-sions and Windows applications. Personally identifiable informa-tion (PII) refers to any information related to the user as defined bythe US FTC and Office of the Privacy Commissioner of Canada. Anyentity that is not directly related to a parental control solution, islabelled as a third-party; this includes but is not limited to trackersand advertisers. In what follows, we briefly discuss some commontechniques used by parental control tools, define our threat model,and list the vulnerabilities that we test against each solution.
Parental control tools generally allow the parent to remotely con-trol the child device, perform web filtering, and monitor activitieson social media. We derive the following monitoring techniquesfrom product documentation, our observations from installationprocedure and use/analysis of these solutions. These techniquesvary significantly across platforms, and are grouped here as such.
Network devices.
Being network-based, parental control devicescan monitor network traffic but cannot inspect the content of en-crypted traffic. The devices analyzed act as a man-in-the-middlebetween the client device and the internet router by using oneof two techniques: performing Address Resolution Protocol (ARP)spoofing, or creating a separate access point. ARP spoofing enablesthe network device to impersonate the internet router on the localnetwork. The device achieves that by sending forged ARP packetsthat bind the router’s IP with the network device’s MAC address.As a result, all the local network traffic is routed through the de-vice before going to the internet router. Alternatively, the network device may create an explicit access point exclusively for childrento enforce parental control filtering on all devices connected to it.
Android apps.
Android apps rely on several Android-specificmechanisms, including the following (see Table 6 in Appendix forper Android solution capabilities). (1) Device administration [5, 67]provides several administrative features at the system level, includ-ing: device lock, factory reset, certificate installation, and devicestorage encryption. (2) Mobile device management (MDM [45])enables additional control and monitoring features, designed forbusinesses to fully control/deploy devices in an enterprise setting. (3) Android accessibility service [6, 67] enables apps to performseveral functions including monitoring user actions by receivingnotifications when the user interacts with an app, capturing andretrieving window content, logging keystrokes, and controllingwebsite content by injecting JavaScript code into visited web pages.(4) Notification access enables Android apps to read or dismiss allnotifications displayed in the status bar; notifications may includepersonal information such as contact names and messages. (5) An-droid VPN, custom browsers, and third-party domain classifiers(e.g., Komodia.com [39]), which are used to filter web content. (6)Facebook [27] and YouTube OAuth [33] features, which are used tomonitor the child’s activities on Facebook (e.g., posts and photos),and YouTube (e.g., playlists and comments). (7) Miscellaneous tech-niques including: having browser history and bookmarks permis-sion, using custom browsers, or TLS interceptions via Android VPN. Windows applications.
As opposed to Android parental controlapps, Windows applications operate with more privileges, and usethe following techniques: (1) TLS-interception: a proxy is installedby inserting a self-signed certificate in the trusted root certificatestore. This allows the Windows applications to perform contentanalysis and alter content from HTTPS webpages. (2) Applicationmonitoring: user applications are monitored for their usage andduration. (3) User activity monitoring: some Windows applicationstake screenshots, record keystrokes, and access the webcam.
Chrome extensions.
With appropriate permissions, a parentalcontrol extension can use the Chrome API and retrieve the URLcontacted by the user, intercept and redirect traffic, read and modifypage content and meta-data including cookies.
We consider the following attacker types with varying capabilities.(1) On-device attacker: a malicious app with limited permissions onthe child/parent device. (2) Local network attacker: an attacker withdirect or remote access to the same local network as the child device.This attacker can eavesdrop, modify, and drop messages from thelocal network. (3) On-path attacker: a man-in-the-middle attackerbetween the home network and a solution’s backend server. (4) Re-mote attacker: any attacker who can connect to a solution’s backendserver. Attacks requiring physical access to either the child/parentdevice are excluded from our threat model. CSAC 2020, December 7–11, 2020, Austin, USA S. Ali et al.
We define the following list of potential security and privacy issuesto evaluate parental control tools (tested using only our own ac-counts where applicable). This list is initially inspired by previouswork [4, 19, 60, 68], and then iteratively refined by us.(1)
Vulnerable client product : A parental control product (includingits update mechanism) being vulnerable, allowing sensitive in-formation disclosure (e.g., via on-device side-channels), or evenfull product compromise (e.g., via arbitrary code execution).(2)
Vulnerable backend : The use of remotely exploitable outdatedserver software, and misconfigured or unauthenticated backendAPI endpoints (e.g., Google Firebase [35] in Android apps).(3)
Improper access control : Failure to properly check whether therequester owns the account before accepting queries at theserver-end (e.g., insecure direct object reference).(4)
Insecure authentication secrets : Plaintext storage or transmissionof authentication secrets (e.g., passwords and session IDs).(5)
SSLStrip attack : The parental control tool’s online managementinterface is vulnerable to SSLStrip attack, possibly due to lackof HSTS enforcement (cf. [43, 44]) .(6)
Weak password policy : Acceptance of very weak passwords (e.g.,with 4 characters or less).(7)
Online password brute-force : No defense against unlimited loginattempts on the online parental login interface.(8)
Uninformed suspicious activities : No notifications to parentsabout potentially dangerous activities (e.g., the use of parentalaccounts on a new device, or password changes).(9)
Insecure PII transmission : PII from the client-end is sent withoutencryption, allowing an adversary to eavesdrop for PII.(10)
PII exposure to third-parties : Direct PII collection and sharing(from client devices) with third-parties.
We chose solutions used in the most popular computing platformsfor mobile devices (Android), personal computers (Windows), webbrowser (Chrome), and selected network products from popularonline marketplaces (Amazon). We used “Parental Control” as asearch term on Amazon and Chrome Web Store and selected eightdevices and ten extensions. For Windows applications, we reliedon rankings and reviews provided by specialized media outlets(e.g., [13, 38, 52]), and selected eight applications. For Android apps,we searched the following terms on Google Play: “Parental Control”and “Family Tracker”. From a total of 462 apps, we selected 158apps with over 10K+ installations, and analyzed them automatically.We also downloaded the companion apps for four network devices(Circle companion app was already in our dataset as it had 50K+installs). For six of these apps, the developers made available (viatheir official websites) alternative APKs with additional features.These APKs were also included in the set of automatically analysedapps, adding up to 168 apps. We installed these apps on an Androidphone and removed 15 unresponsive/unrelated apps, making thetotal of apps analyzed to 153; 51/153 are pure children apps; 24 arepure parent apps; and 78 are used for both parent and child devices,which we termed as “shared apps”. For in-depth analysis, we picked As of May 2020, current market shares according one estimate (https://gs.statcounter.com) are: Android 72.6%, Windows 77% and Chrome 63.9%.
29 popular Android apps representing 13 parental control solutions.Each solution may include child app(s), parent app(s), and onlineparental dashboard.
We combine dynamic (primarily traffic and usage) and static (pri-marily code review/reverse-engineering) analysis to identify secu-rity and privacy flaws in parental control tools; for an overview,see Fig. 1. For each product, we first conduct a dynamic analy-sis and capture the parental control tool traffic during its usage(as parents/children); if the traffic is in plaintext or decryptable(e.g., via TLS MITM), we also analyze the information sent. Second,we statically analyze their binaries (via reverse engineering) andscripts (if available). We pay specific attention to the API requestsand URLs present in the code to complement the dynamic analysis.After merging the findings, we look into the domains contacted andcheck the traffic for security flaws (e.g., TLS weaknesses). Third, wetest the security and privacy issues described in Sec. 3.3 against thecollected API URLs and requests. Lastly, in case the parental controltool presents an online interface, we assess the password-relatedissues and test the SSLStrip attack against the login page.
We set up test environments for each solution, emulate user actionsfor hours to days, collect the traffic from the child, parent, andnetwork devices, and then perform relevant analysis (see Sec. 3.3).
We analyze eachsolution by manually mimicking regular users’ operations withthe goal of triggering parental control mechanisms. We test forpotential vulnerabilities in these mechanisms (see Sec. 4.1.2). Weevaluate the web filtering mechanism by visiting a blocked website(gambling/adult) and a university website. We also perform useractivities monitored by platform-specific parental control features(see Sec. 3.1, and Table 6 in the Appendix), and evaluate the so-lution’s operations. For example, on Android, we perform basicphone activities (SMS, phone call) and internet activities (Instantmessaging, social media, browsing, and accessing blocked content).The network devices are evaluated in a lab environment by con-necting them to an internet-enabled router (like in a domestic net-work setup) with the OpenWrt firmware [51]. We use test deviceswith web browsing to emulate a child’s device. If the parental con-trol device uses ARP spoofing, the test device is connected directlyto the router’s wireless access point (AP); see Fig. 2 (a). Otherwise,the test device is connected to the parental control device’s wirelessAP; see Fig. 2 (b). We capture network traffic on both the test deviceand the router using Wireshark and tcpdump, respectively.For Android apps, we maintain two experimental environmentsto concurrently record and inspect network traffic originating fromthe child and parent apps. We examine the child apps using a Sam-sung Galaxy S6 phone running Android 7.0; for the parent apps,we use a Nexus 4 with Android 5.1.1. We run a full Linux distri-bution with mitmproxy [48] and tcpdump on each experimentalenvironment by installing Linux Deploy [7], and configured An-droid’s network settings to proxy all traffic going through the WiFiadapter to the mitmproxy server. This enables us to capture thenetwork traffic directly within the mobile devices. etrayed by the Guardian ACSAC 2020, December 7–11, 2020, Austin, USA
YesIs trafficdecryptable? Extract domainscontactedAnalyze URLs andAPIsYesNoNo
Dynamic analysisStatic analysis
Check forcommunication flawsPerform code analysisIs code accessible? Uninformedsuspicious activities 3rd parties trackersOnline passwordbrute-forceWeak passwordpolicyVulnerable clientproductVulnerable backendInsecureauthenticationsecretInsecure PIItransmission Improper accesscontrolLack of HSTSenforcementHas an onlineinterface? Assess passwordrelated issuesYesExtract/downloadsource codeStart EndNo
Online interface analysis
Analysis techniques
Security and privacy issues
End
Figure 1: Overview of our evaluation framework.
SpoofedconnectionClient device
Network device
Internet (a) ARP poisoning case.
Client device Network device
Internet
Router (b) Dedicated Access Point case.
Figure 2: Network devices test environment. Wireshark is installed on both the client device and home router.
We test each Windows application and Chrome extension ona fresh Windows 10 virtual machine with Chrome, tcpdump andmitmproxy installed. We intercept inbound and outbound trafficusing mitmproxy on the host, and record packets using tcpdump.
After intercepting traffic, we parse and com-mit the collected tcpdump traffic to an SQLite database and checkfor the following security and privacy related issues.
PII and authentication secrets leakage.
We examine the col-lected traffic to check for PII and authentication secrets transmittedin plaintext, or leakage of PII to third-party domains. We create alist of possible PII (see Table 8 in the Appendix) that can be leakedvia the Request URL, Referer, HTTP Cookie, requests’ payload, andLocalStorage. We automatically search for PII items (i.e., case insen-sitive partial string match) in the collected traffic, and record theleaked information, including the HTTP request URL. We decodethe collected network traffic using common encoding (base64 and URL encoding) and encode possible PII using hashing algorithms(MD5, SHA1, SHA256, and SHA512) to find out obfuscated leaks.
Improper access control.
We parse the traffic to find API end-points with improper access control. First, we try to identify all theAPIs that can be potentially exploited (without strong authentica-tion), using Postman (postman.com) to replay the recorded HTTP re-quest stripped of authentication headers (e.g., cookies and authoriza-tion header). Any request successfully replayed is labeled as poten-tially vulnerable (in a database). Afterwards, we retrieve the parame-ters used by these APIs (e.g., keys, tokens, or unique IDs), and assessthe parameters in terms of their predictability and confidentiality.For instance, we deem a device’s access control insecure if its ownMAC address is used for API endpoints authentication, as the MACaddress can easily be found by an attacker on the local network.
Identifying trackers.
We use the EasyList [21], EasyPrivacy [22],and Fanboy [23] to identify known trackers. We also add known
CSAC 2020, December 7–11, 2020, Austin, USA S. Ali et al. trackers from past work [58, 75] to our list. To identify third-partySDKs in the parental control tools traffic, we use the WHOIS [57]registration record to compare the SDK owner name to the parentalcontrol website owner. In cases where the SDK information is pro-tected by the WHOIS privacy policy, we visit the SDK’s domainto detect any redirect to a parent site; we then lookup the parentsite’s registration information. If this fails, we manually review theSDK’s “Organization” in its TLS certificate, if available. Otherwise,we try to identify the SDK owner by searching in crunchbase.com.
Due to ethical/legal concerns, we re-frain from using any invasive vulnerability scanning tools to assessbackend servers. Instead, we look into the backends’ software com-ponents as disclosed by web servers or frameworks in their HTTPresponse headers, such as “Server” and “X-Powered-By”. We thenmatch these components against the CVE database to detect knownvulnerabilities associated with these versions. Additionally, we usethe Qualys SSL Test (Qualys 2020: ssllabs.com) to evaluate the secu-rity of the SSL configuration of the parental control tools’ backends.
During the interception and traffic analysis phase,we encountered several challenges. We summarize them here, in-cluding the tools and techniques we use to address them.
Network traffic attribution.
On Android apps, a key issue is toidentify the process that generated the traffic in the absence ofthe packets’ referral metadata. We test how the app behaves whenthe child uses her device normally (e.g., phone calls, messaging,browsing). These activities produce a large amount of traffic thatwe need to match to the corresponding processes. We use the mitm-proxy addon [48] to call netstat to detect the process name forevery packet. We directly use netstat from the underlying Linuxkernel (in our Linux Deploy setup) to capture the process ID andprocess name as soon as a connection is created, while previouswork [41, 59] read and parse the system proc directory from theAndroid Linux kernel by checking the directory periodically. Thispast approach misses connections that are opened and closed beforethe next time they check the proc directory, while our approachlooks into the live connection as soon as a connection is created. Wemay only miss very short-lived connections that are not detectedby netstat. To the best of our knowledge, we achieve more reliabletraffic-process attribution compared to past work. We leave a fullevaluation of the effectiveness of the technique to future work.
Traffic interception.
Most network devices use TLS for commu-nicating with their backends. This prevented us from inserting aroot certificate on these devices, so some of the network trafficgenerated by them is completely opaque to us. In these cases, werely on static analysis of the device’s firmware. In cases where anAndroid app uses certificate pinning to refuse server certificatessigned by any CA other than the pinned certificate in the app, weuse SSLUnpinning [1] to attach several hooks in the SSL classes inorder to bypass this feature and intercept the communication. Incases where the child app installs a VPN on the child device to filterand block websites, we intercept the traffic by deleting the VPN con-figuration from Android setting on the child device. If the app stopsfunctioning without the VPN, we update the app configuration filewhenever possible to disable the setup of the VPN on startup ofthe app on the child device. One Windows application, Qustodio uses its own encrypted certificate store, for which, we extract theassociated TLS proxy private key by dumping the process memory.It is possible that due to our employed measures for traffic analy-sis and attribution (e.g., rooted device, disabled VPN), some parentalcontrol solutions may have functioned differently, which is difficultto verify due to the use of heavily obfuscated code. Hence, ourfindings may be the lower-end of the actual privacy exposure.
Our static analysis aims to complement the dynamic analysis when-ever we could not decrypt the network traffic (e.g., in case of net-work devices using TLS). We use static analysis to identify PII leak-age, contacted domains, weak security measures (e.g., bad inputsanitization), or potential flaws in implemented mechanisms.
Network devices.
We analyze the network device firmware when-ever possible. We either attempt to extract the firmware directlyfrom the device (via JTAG, UART, or ICSP interfaces), or down-load the device firmware from the vendor’s website. We found 3/8network devices with an accessible serial UART port (KoalaSafe,Blocksi, and Fingbox) that we used to extract the firmware from thedevices. Another device (Circle) made its firmware available online.Among the remaining devices (without access to their firmware),we scan for the presence of open remote admin services (e.g., SSH),which are often closed or key-protected. To identify vulnerableservices, we scan the network devices with several tools (OpenVas,Nmap, Nikto [16] and Routersploit [61]), and match the identifiedsoftware versions against public vulnerability databases.
Chrome extensions.
We manually analyze the source code of theChrome extensions, which mainly consists of scripts, separated intocontent scripts and background scripts. As most Chrome extensions’codebase is relatively small, and do not involve serious obfuscation,we can investigate their operations and detect security and privacyissues (e.g., PII leakage, common JavaScript vulnerabilities).
Android apps.
We perform an automated analysis on all 153 An-droid apps using Firebase Scanner [63] to detect security miscon-figurations in Firebase. We also use LibScout [10] to identify third-party libraries embedded in these apps. Since LibScout does notdistinguish which libraries are used for tracking purposes, we useExodus-Privacy [56] to classify tracking SDKs. We use MOBSF [49]to extract the list of third-party tracking SDKs from all 153 appsbased on Exodus-Privacy’s tracker list.
The online user interface is the primary communication channelbetween parents and parental control tools. It displays most of thedata collected by the solutions, and may remotely enable moreintrusive features. Compromising the parent account can be verydamaging, and thus we evaluate the security of this interface.
SSLStrip attack.
To check for SSLStrip attacks, we first set up aWiFi AP with mitmproxy, SSLStrip2 [40] and Wireshark installed.Then, we connect the parental control tool to our WiFi access point.Wireshark is utilized to record network traffic while mimickingcommon use case scenarios with the goal of triggering all parentalcontrol monitoring and control UI and API requests looking for Google Firebase (https://firebase.google.com/) provides support for backend infras-tructure management for Android apps. etrayed by the Guardian ACSAC 2020, December 7–11, 2020, Austin, USA signs of successfully SSL Stripping attack on the traffic. We con-firm the effectiveness of the attack by comparing the result to thecorresponding traffic in a regular testing environment (i.e., withoutSSLStrip).
Weak password policy.
During the parental control tool’s accountcreation, we evaluate its password policy. We adopt a fairly con-servative stance and only labelled as weak the password policyaccepting password with 4 characters or less.
Online password brute-force.
We use Burp Suite [55] to performpassword brute-force attacks on our own online accounts. To keepthe load on the server minimal, we test for the presence of defensivemechanisms by 50 attempts on our account from a single computer.
Uninformed suspicious activities.
To determine whether thesolution presents measures to report suspicious activities, we testtwo scenarios in which the user should be notified: modificationof the user’s password, and connection to the account from anew/unknown device. We deem a parental control tool that doesnot alert (e.g., via email) in either case to be vulnerable.
Following the methodology in Sec. 4, we analyzed the parentalcontrol tools between Mar. 2019 to May 2020, which include: 8network devices, 29 Android apps representing 13 Android solu-tions, 10 Chrome extensions and 8 Windows applications. We alsoperformed an automated analysis of 153 parental control Androidapps to detect vulnerable backend databases and check for trackingSDKs. In this section, we report our findings on the tested securityand privacy issues (as outlined in Sec. 3.3); for an overview, seeTable 1.
Network devices.
The importance of securing the update mecha-nism has been known for years, cf. [11]. Surprisingly, the Blocksifirmware update happens fully through HTTP. An integrity checkis done on the downloaded binary image, using an unkeyed SHA256hash, again retrieved using HTTP, and thus rendering it useless.Therefore, an on-path attacker can trivially alter the update file andinject their own malicious firmware into the device. We confirmedthis vulnerability to be exploitable. We also found another vulner-ability that enables executing a command as root on the Blocksidevice via command injection (i.e., unsanitized user input is passeddirectly to a system shell for execution). We confirmed this vulnera-bility to be exploitable by sending a router_setGeneralSettings request to the Blocksi API endpoint, and injecting a command inthe timezone field in the request parameters. The settings changetriggers a WebSocket Secure (WSS) message to the Blocksi device.The device then reads the new configuration from the API endpointand updates its local configuration. We also found that KoalaSafe runs Dropbear v2014.63 SSH server/client(released on Feb. 19, 2014), associated with four known remote codeexecution vulnerabilities. Under certain conditions, the KoalaSafedevice opens a reverse SSH tunnel through its backend server, ex-posing the vulnerable SSH Dropbear server to an attacker outside The timezone value is passed as tz to [“echo” + tz + “> /etc/TZ”]. Thus, if tz is “$(ls)”,the ls command would be executed and its output written to /etc/TZ. the local network. By calling a KoalaSafe API endpoint, an exter-nal attacker can detect when a reverse SSH tunnel is open usingonly the victim device’s MAC address. If the tunnel is open, theAPI endpoint responds with the tunnel’s port number, 0 otherwise.For large-scale exploitation, an attacker can query the aforemen-tioned API endpoint to enumerate all KoalaSafe devices with thereverse tunnel open. This enumeration is feasible as KoalaSafe usesthe GuangLia network interface card (NIC), and MAC addressesassigned to GuangLia NICs [70] are limited to only values. Android apps.
We found 3/13 Android solutions (FamiSafe, Kid-sPlace and Life360) do not encrypt stored user data on shared ex-ternal storage that can be accessed by any other apps with thepermission to access the SD card. Examples of the sensitive infor-mation include: the parent’s email and PIN code, phone numbers,the child’s geolocation data, messages and social media chats, vis-ited websites, and even authentication tokens—which enabled usto read private information from the child account remotely.We also found that Kidoz, KidsPlace, and MMGuardian use cus-tom browsers to restrict and filter web content. The three browsersfail to enforce HSTS, and lack persistent visual indication if the web-site is served on HTTP. KidsPlace safe browser keeps the address barthat shows visited URL to help with visual identification. However,MMGuardian shows the URL in the address bar until the page isfully loaded and then the URL is replaced with the webpage title. Fol-lowing our disclosure, MMGuardian removed their custom browser.
Windows applications and Chrome extensions.
Other thanKidswatch, all tested Windows applications relied on TLS proxiesto operate. Some of these proxies do not properly perform cer-tificate validation. For example, Qustodio and Dr. Web acceptedintermediate certificates signed with SHA1, despite the enhancedcollision attack on SHA1 [42]. Dr. Web also accepted Diffie-Hellman1024 (considered weak [2], and deprecated in Safari and Chromesince 2016 [15]). In addition, none of the proxies rejected revokedcertificates. We also found that upon uninstallation of these appli-cations, the root certificates associated with the proxies remainedin the Windows trusted root certificate store, with four of themhaving a validity duration over one year.Two Chrome extensions (Adult Blocker and MateCode Blocker)download and run a third-party tracking script at run time. The do-mains hosting the scripts are not apparently related to the extensionproviders (or libraries from well-known companies). Note that run-time loaded scripts bypass the static control of Chrome for extensionsecurity, which has been exploited in the wild by tricking developersinto adding malicious scripts masquerading as tracking scripts [34].
Network devices.
Examples of vulnerable software componentsfrom our analysis of backend server API endpoints include: Apache2.4.34 with 11 CVEs in KoalaSafe; PHP 7.0.27 with 26 CVEs inKidsWifi; Nginx versions with the same 3 CVEs in KidsWifi, Circle,HomeHalo and Fingbox. The Blocksi’s API endpoint only indicatesthat it runs on OpenResty and Google Frontend (no version info).
Android apps.
Since 115/153 Android apps use Google Firebaseas a backend service, we analyzed their Firebase configuration for https://api.koalasafe.com/api/router/[MACaddress]/et CSAC 2020, December 7–11, 2020, Austin, USA S. Ali et al.
Table 1: Overall results for security flaws in parental control tools labelled following the threat model in Sec. 3.2. (cid:35) : On-deviceattacker;
ACSAC 2020, December 7–11, 2020, Austin, USA S. Ali et al.
Table 1: Overall results for security flaws in parental control tools labelled following the threat model in Sec. 3.2. : On-deviceattacker; : Local network attacker; : On-path attacker; : Remote attacker; - : not applicable; blank : no flaw found. Incase the vulnerability can be exploited by 2 types of attackers, we display the fullest circle applicable. Network devices Android solutions Chrome extensions Windows applicationsSecurity Flaw C i r c l e H o m e p l u s K o a l a S a f e K i d s W i fi B l o c k s i R o u t e r B i t d e f e n d e r R o q o s H o m e H a l o F i n g B o x C i r c l e F a m i l y T i m e F a m i S a f e F i n d M y K i d s K i d o z K i d C o n t r o l K i d s P l a c e L i f e MM G u a r d i a n M o b i l e F e n c e Q u s t o d i o S c r ee n T i m e S e c u r e T ee n B l o c k s i W e b F i l t e r P a r e n t a l c o n t r o l T i n y F i l t e r P o r n B l o c k e r A d u l t B l o c k e r A n t i - p o r n a dd o n M a t e C o d e B l o c k e r M e t a C e r t F a m i l y F r i e n d l y K i d s S a f e W e b Q u s t o d i o K a s p e r s k y D r . W e b N o r t o n S p y r i x K i d s w a t c h K i d L o gg e r K u r u p i r a Vulnerable client productVulnerable backendImproper access control - - - - - - - - - -
Insecure authentication secret - - - - - - - - - -
SSLStrip attack - - - - - - - - - - - - - - - -
Online password bruteforce - - - - - - - - - - - - - - -
Weak password policy - - - - - - - - - - - - - - -
Uninformed suspicious activities - - - - - - - - - - - - - -
Insecure PII transmissionPII exposure to third-parties security issues by performing an automated analysis using Fire-base Scanner [63]. Critical misconfigurations can allow attackersto retrieve all the unprotected data stored on the cloud server. Wefollowed a similar approach to Appthority’s work [9] on scanningapps for Firebase misconfigurations. We found 8/153 Android appswith insecure Firebase configurations. We then evaluated the typeof sensitive data exposed by each app to determine the impact ofthe data being leaked. For ethical reasons and to protect other cus-tomers privacy, we created a parental account on the eight apps.Then, we updated the Firebase scanner to automatically search forour test data in the its response and record the leaked informationfrom our own account. We found three apps exposing personalinformation: 1) FamiSafe with 500K+ installs exposes the parentemail; 2) Locate with 10K+ installs exposes the child name, phonenumber, and email; and 3) My Family Online with 10K+ installsexposes the child name, child and parent phone numbers, parentemail, and apps installed on child phone. FamiSafe fixed the Fire-base security issue following our disclosure. Additionally, we foundthat MMGuardian, MobileFence, and SecureTeen servers supportRC4, and SecureTeen backend is vulnerable to the POODLE attack.
Windows applications.
We found that some Windows applica-tions’ servers also do not use ideal TLS configurations. For instance,Qustodio’s server has an intermediate certificate signed with SHA1in its chain of trust. Qustodio and KidLogger servers support theRSA key exchange protocol which lacks forward secrecy.
Network devices.
The KoalaSafe API login endpoint requires threeparameters that are available to anyone on the local network: adevice-generated authentication token, the device’s date and time,and the device’s MAC address for successful authentication. Theseparameters can be obtained by visiting endpoints hosted by the KoalaSafe device. Thus, a local network attacker can easily collectthe information needed for authentication and use the API endpointto access sensitive information such as the profile name, emailaddress, and browsing history.For Blocksi’s login API endpoint, the device’s serial number (SN)and the registered user’s email are required to authenticate thedevice to the server. However, a remote attacker needs to knowonly one of these parameters to authenticate. This is because aremote attacker can retrieve a user’s email using their device SN orvice-versa. By sending both parameters to the API endpoint in aPOST message, any remote attacker can authenticate to the server,and access sensitive information about the home network, e.g., theWiFi password, and MAC addresses of connected devices.The HomeHalo device uses only the device’s SN and an HTTPheader called secretToken to authenticate to its API endpoint. Inour case, the secretToken had a fixed value of 100500. An on-pathattacker can intercept and modify these messages, and gain accessto admin controls, e.g., reading or changing the wireless SSID, pass-word, or even the device’s root password. Other privacy sensitiveinformation is also exposed, including: the devices connected toHomeHalo’s network and the parental control profile setup.The Circle Home Plus creates a profile for each child and stores itlocally on the device, including the child age groups, usage historyand statistics, child photo, and username (i.e., some parents mayuse child name). We identify two API endpoints used to transmitchild information in plaintext over the local network. The first APIendpoint sends child account usage history and statistics, and profileID . It insecurely relies on the requester’s MAC address to Authentication token and device time are available at https://device.koalasafe.com/auth.lua, and the MAC address at https://device.koalasafe.com/status.lua For SN to email, use https://service.block.si/config_router_v2/router_checkRouters/null/[SN], and for email to SN, https://service.block.si/config_router_v2/router_checkRouters/[email]. http://10.123.234.1/api/USERINFO?host=ios&nocache=1572292313630HTTP/1.1 : Local network attacker; (cid:71)(cid:35) : On-path attacker; (cid:32) : Remote attacker; - : not applicable; blank : no flaw found. In casethe vulnerability can be exploited by 2 types of attackers, we display the fullest circle applicable. ACSAC 2020, December 7–11, 2020, Austin, USA S. Ali et al.
Table 1: Overall results for security flaws in parental control tools labelled following the threat model in Sec. 3.2. : On-deviceattacker; : Local network attacker; : On-path attacker; : Remote attacker; - : not applicable; blank : no flaw found. Incase the vulnerability can be exploited by 2 types of attackers, we display the fullest circle applicable. Network devices Android solutions Chrome extensions Windows applicationsSecurity Flaw C i r c l e H o m e p l u s K o a l a S a f e K i d s W i fi B l o c k s i R o u t e r B i t d e f e n d e r R o q o s H o m e H a l o F i n g B o x C i r c l e F a m i l y T i m e F a m i S a f e F i n d M y K i d s K i d o z K i d C o n t r o l K i d s P l a c e L i f e MM G u a r d i a n M o b i l e F e n c e Q u s t o d i o S c r ee n T i m e S e c u r e T ee n B l o c k s i W e b F i l t e r P a r e n t a l c o n t r o l T i n y F i l t e r P o r n B l o c k e r A d u l t B l o c k e r A n t i - p o r n a dd o n M a t e C o d e B l o c k e r M e t a C e r t F a m i l y F r i e n d l y K i d s S a f e W e b Q u s t o d i o K a s p e r s k y D r . W e b N o r t o n S p y r i x K i d s w a t c h K i d L o gg e r K u r u p i r a Vulnerable client productVulnerable backendImproper access control - - - - - - - - - -
Insecure authentication secret - - - - - - - - - -
SSLStrip attack - - - - - - - - - - - - - - - -
Online password bruteforce - - - - - - - - - - - - - - -
Weak password policy - - - - - - - - - - - - - - -
Uninformed suspicious activities - - - - - - - - - - - - - -
Insecure PII transmissionPII exposure to third-parties security issues by performing an automated analysis using Fire-base Scanner [63]. Critical misconfigurations can allow attackersto retrieve all the unprotected data stored on the cloud server. Wefollowed a similar approach to Appthority’s work [9] on scanningapps for Firebase misconfigurations. We found 8/153 Android appswith insecure Firebase configurations. We then evaluated the typeof sensitive data exposed by each app to determine the impact ofthe data being leaked. For ethical reasons and to protect other cus-tomers privacy, we created a parental account on the eight apps.Then, we updated the Firebase scanner to automatically search forour test data in the its response and record the leaked informationfrom our own account. We found three apps exposing personalinformation: 1) FamiSafe with 500K+ installs exposes the parentemail; 2) Locate with 10K+ installs exposes the child name, phonenumber, and email; and 3) My Family Online with 10K+ installsexposes the child name, child and parent phone numbers, parentemail, and apps installed on child phone. FamiSafe fixed the Fire-base security issue following our disclosure. Additionally, we foundthat MMGuardian, MobileFence, and SecureTeen servers supportRC4, and SecureTeen backend is vulnerable to the POODLE attack.
Windows applications.
We found that some Windows applica-tions’ servers also do not use ideal TLS configurations. For instance,Qustodio’s server has an intermediate certificate signed with SHA1in its chain of trust. Qustodio and KidLogger servers support theRSA key exchange protocol which lacks forward secrecy.
Network devices.
The KoalaSafe API login endpoint requires threeparameters that are available to anyone on the local network: adevice-generated authentication token, the device’s date and time,and the device’s MAC address for successful authentication. Theseparameters can be obtained by visiting endpoints hosted by the KoalaSafe device. Thus, a local network attacker can easily collectthe information needed for authentication and use the API endpointto access sensitive information such as the profile name, emailaddress, and browsing history.For Blocksi’s login API endpoint, the device’s serial number (SN)and the registered user’s email are required to authenticate thedevice to the server. However, a remote attacker needs to knowonly one of these parameters to authenticate. This is because aremote attacker can retrieve a user’s email using their device SN orvice-versa. By sending both parameters to the API endpoint in aPOST message, any remote attacker can authenticate to the server,and access sensitive information about the home network, e.g., theWiFi password, and MAC addresses of connected devices.The HomeHalo device uses only the device’s SN and an HTTPheader called secretToken to authenticate to its API endpoint. Inour case, the secretToken had a fixed value of 100500. An on-pathattacker can intercept and modify these messages, and gain accessto admin controls, e.g., reading or changing the wireless SSID, pass-word, or even the device’s root password. Other privacy sensitiveinformation is also exposed, including: the devices connected toHomeHalo’s network and the parental control profile setup.The Circle Home Plus creates a profile for each child and stores itlocally on the device, including the child age groups, usage historyand statistics, child photo, and username (i.e., some parents mayuse child name). We identify two API endpoints used to transmitchild information in plaintext over the local network. The first APIendpoint sends child account usage history and statistics, and profileID . It insecurely relies on the requester’s MAC address to Authentication token and device time are available at https://device.koalasafe.com/auth.lua, and the MAC address at https://device.koalasafe.com/status.lua For SN to email, use https://service.block.si/config_router_v2/router_checkRouters/null/[SN], and for email to SN, https://service.block.si/config_router_v2/router_checkRouters/[email]. http://10.123.234.1/api/USERINFO?host=ios&nocache=1572292313630HTTP/1.1 security issues by performing an automated analysis using Fire-base Scanner [63]. Critical misconfigurations can allow attackersto retrieve all the unprotected data stored on the cloud server. Wefollowed a similar approach to Appthority’s work [9] on scanningapps for Firebase misconfigurations. We found 8/153 Android appswith insecure Firebase configurations. We then evaluated the typeof sensitive data exposed by each app to determine the impact ofthe data being leaked. For ethical reasons and to protect other cus-tomers privacy, we created a parental account on the eight apps.Then, we updated the Firebase scanner to automatically search forour test data in the its response and record the leaked informationfrom our own account. We found three apps exposing personalinformation: 1) FamiSafe with 500K+ installs exposes the parentemail; 2) Locate with 10K+ installs exposes the child name, phonenumber, and email; and 3) My Family Online with 10K+ installsexposes the child name, child and parent phone numbers, parentemail, and apps installed on child phone. FamiSafe fixed the Fire-base security issue following our disclosure. Additionally, we foundthat MMGuardian, MobileFence, and SecureTeen servers supportRC4, and SecureTeen backend is vulnerable to the POODLE attack. Windows applications.
We found that some Windows applica-tions’ servers also do not use ideal TLS configurations. For instance,Qustodio’s server has an intermediate certificate signed with SHA1in its chain of trust. Qustodio and KidLogger servers support theRSA key exchange protocol which lacks forward secrecy.
Network devices.
The KoalaSafe API login endpoint requires threeparameters that are available to anyone on the local network: adevice-generated authentication token, the device’s date and time,and the device’s MAC address for successful authentication. Theseparameters can be obtained by visiting endpoints hosted by the KoalaSafe device. Thus, a local network attacker can easily collectthe information needed for authentication and use the API endpointto access sensitive information such as the profile name, emailaddress, and browsing history.For Blocksi’s login API endpoint, the device’s serial number (SN)and the registered user’s email are required to authenticate thedevice to the server. However, a remote attacker needs to knowonly one of these parameters to authenticate. This is because aremote attacker can retrieve a user’s email using their device SN orvice-versa. By sending both parameters to the API endpoint in aPOST message, any remote attacker can authenticate to the server,and access sensitive information about the home network, e.g., theWiFi password, and MAC addresses of connected devices.The HomeHalo device uses only the device’s SN and an HTTPheader called secretToken to authenticate to its API endpoint. Inour case, the secretToken had a fixed value of 100500. An on-pathattacker can intercept and modify these messages, and gain accessto admin controls, e.g., reading or changing the wireless SSID, pass-word, or even the device’s root password. Other privacy sensitiveinformation is also exposed, including: the devices connected toHomeHalo’s network and the parental control profile setup.The Circle Home Plus creates a profile for each child and stores itlocally on the device, including the child age groups, usage historyand statistics, child photo, and username (i.e., some parents mayuse child name). We identify two API endpoints used to transmitchild information in plaintext over the local network. The first APIendpoint sends child account usage history and statistics, and profileID . It insecurely relies on the requester’s MAC address to Authentication token and device time are available at https://device.koalasafe.com/auth.lua, and the MAC address at https://device.koalasafe.com/status.lua For SN to email, use https://service.block.si/config_router_v2/router_checkRouters/null/[SN], and for email to SN, https://service.block.si/config_router_v2/router_checkRouters/[email]. http://10.123.234.1/api/USERINFO?host=ios&nocache=1572292313630HTTP/1.1 etrayed by the Guardian ACSAC 2020, December 7–11, 2020, Austin, USA identify the child device and communicate sensitive information.This API endpoint is called whenever a child device attempts toaccess a restricted domain. The second API endpoint fetches theprofile photo corresponding to the received profile ID. Android apps.
We found 8/13 Android solutions lack authentica-tion for accessing PII. Prominent examples include the following.In FamilyTime, a six-digit parameter childID is generated througha sequential counter incremented by one per user. An attacker canretrieve the child name, gender, date of birth, email address, andchild phone number through an API request that requires onlythe childID value. Hence, an attacker can remotely exploit thisvulnerability at a large scale, simply by trying all 6-digit values. In FamiSafe, an attacker can retrieve all the child social mediamessages and YouTube activities labeled as suspicious throughan API request that requires the following parameters: deviceid , memberid , client_sign , and access token . However, any appinstalled on the child device can access these parameters from theFamiSafe log file on the shared external storage. Network devices.
During the setup procedure of KidsWifi, thedevice creates an open wireless AP with SSID “set up kidswifi”,making it temporarily vulnerable to eavesdropping. The parent hasto use this AP’s captive portal to configure the KidsWifi device toconnect to the home network. Consequently, as this AP is open andthe client-device communication happens through HTTP, the homerouter’s WAN and KidsWifi’s LAN credentials become available tolocal attackers. We deem this a minor risk as the vulnerability isonly present for a limited duration (during device setup), and theattacker must be within close proximity.
Android apps.
In SecureTeen, we found an API endpoint that canbe used to authenticate the user to the parental control account.This API endpoint enables any adversary to remotely compromiseany parental account by knowing only the parent’s email. When theAPI request is invoked by the browser, the adversary is logged in tothe parental dashboard and obtains full access to the parent account,including the ability to monitor and control the child device. Kidoz exposes the user email and password in HTTP when the“Parental Login” link is clicked from the https://kidoz.net home page.KidsPlace and Qustodio leak session authentication cookies viaHTTP, with validity periods of one year and two hours respectively.Even with the 2-hour cookie in Qustodio, the attacker can easilyaccess sensitive information about the child including the child’scurrent location, and history of movements. The attacker can alsoaccess remote control functions on the child phone, such as blockall incoming/outgoing calls. In the case of KidsPlace, the attackercan access a wide spectrum of remote control functions to the childphone such as: disable the Internet, silently install a malicious app http://10.123.234.1/api/USERPHOTO?profileID=[profileID]. By using e.g., a cURL commad (the last parameter is childID): $ curl -v https://mesh.familytime.io/v2/child/Android/profile/456***. By using e.g., a cURL command: $ curl -v https://u.famisafe.com/load-page/index?page=suspicious-text/detail&access_from=1&device_id=165***&member_id=1045***&client_sign={fffff***-be**-19ec-0000-000075b3****}&access_token=dtwMtFarI********&lang=en. An example call to the API is as follows: https://cp.secureteen.com/auth.php?&productName=secureteen&resellerId=careteen&page=menu&loginFromApp=Yes&j_username=parentemail**@gmail.com&gType=monitoring. on the child device, or upload harmful content to the child mobile.The attacker can also lock the child phone making her unable tocontact the parent or perform an emergency call.
We found that nine Android solutions, four network devices andthree Windows applications transmitted the parent account creden-tials via HTTP under an SSLStrip attack. This allows an adversaryto compromise the parent account for a long time, particularly if theapp does not send any notification to the parent when the accountis accessed from a new device. More seriously, in Kidoz, we couldsee the parent’s credit card account number and email in HTTPwhen using their BlueSnap online payment solution [12], whileconnected to our WiFi access point. This was possible because theonline payment server is not configured to use HSTS. In Qusto-dio, we could extract the child Facebook credentials provided bythe parent during the configuration of the monitoring component.Following our disclosure, FamilyTime enabled HSTS on their server.In terms of defense against online password guessing, we foundthat two network devices and 10 Android solutions leave their on-line login interfaces open to password brute-force attacks. Also,two network devices, five Android solutions, and three Windowsapplications enforced a weak password policy (i.e., shorter than fourcharacters). We also observed that five network devices, 12 Androidsolutions and four Windows applications do not report suspiciousactivities on the parent’s account such as password changes andaccesses from unrecognized devices. These activities are possible in-dicators of account compromise and should be reported to the user.
Network devices.
We found that the KoalaSafe and Blocksi net-work devices append the child device’s MAC address, firmware ver-sion number, and serial number into outgoing DNS requests. Thiscan allow on-path attackers to track the child’s web activities [18].The HomeHalo device suffers from a similar problem: whenever adomain is requested by a user device inside its network, HomeHalosends an HTTP request, including the child device’s MAC address,to its backend server to identify the requested domain’s category.
Android apps.
Several Android solutions send cleartext PII, seeTable 9 in the Appendix. Examples include: FindMyKids (the child’ssurrounding sounds and photo); KidControl (the parent’s nameand email, geolocation, and SOS requests); and MMGuardian (theparent’s email and phone number, and child’s geolocation). MM-Guardian transmits the child visited URL (Base64 encoded) to athird-party domain classifier Komodia.com [39]) via HTTP. Whenwe contacted MMGuardian, they informed us that they are workingwith Komodia on a resolution. Other products using Komodia arealso apparently affected by this.
Windows application and Chrome extensions.
During the in-stallation phase of Kurupira, the user has to set up an SMTP serverwith the assistance of the application to receive activity reports.However, in case the user uses an SMTP server with an unencryptedprotocol, Kurupira does not warn about transmitting child activ-ity report in plaintext. Kidswatch sends child activity reports overHTTP. We also found that three extensions (Blocksi Web Filter,FamilyFriendly Parental Control, Porn Blocker) send the domain
CSAC 2020, December 7–11, 2020, Austin, USA S. Ali et al. contacted by the user to the extension’s server using HTTP to checkwhether or not the website should be blocked.
Some legislations (e.g., US COPPA and EU GDPR) regulate theuse of third-party trackers in the services targeting children (e.g.,under 13 years of age). We thus evaluate potential use of third-partytracking SDKs in the parental control tools. We found notable useof third-party SDKs in parental control tools, except in Windows.For network devices, we identified the use of third-party SDKs inthe companion apps but not in the firmware.
Trackers.
In Android, we found use of trackers in most apps viastatic analysis, including: the children apps (targeted for children’sdevices only, 44/51 apps with tracking SDKs), shared apps (the sameapp is used by both parents and children, 73/78 apps), and parentapps (targeted for parents’ devices only, 22/24 apps); see Table 7in the Appendix. Over 25% of children apps utilize advertisingnetworks (e.g., Google Ad and Doubleclick SDKs; see Fig. 3 in theAppendix) which could potentially violate US COPPA. For networkdevices, our static analysis for five companion apps reveals the useof tracking SDKs (2–12 unique trackers) in all those apps exceptfor KoalaSafe. For Chrome extensions, we found that half of theChrome extensions send behavioral information (e.g. web browserusage) to Google Analytics.We also identify tracking third-party SDKs from network traf-fic generated during our dynamic analysis from child device. Ex-cept SecureTeen, 12/13 Android solutions use tracking SDKs (1–16unique trackers; see Fig. 4 in the Appendix). Our traffic analysis con-firms violations of COPPA—over 30% of Android solutions utilizedoubleclick.net without passing the proper COPPA compliant pa-rameter from child device. We also found that one of the networkdevices’ companion app, Circle, includes a third-party analyticalSDK from Kochava. Every time the app is launched, or it returns tothe foreground, the following information is shared with Kochava:Device ID (enables tracking across apps), device data (enables de-vice fingerprinting for persistent tracking). Kochava provides anopt-out option ( app_limit_tracking=true ) that can be used tocomply with COPPA. However, the Circle transmits this flag as false from the child device. For Android solutions that have a safe custom browser, suchas Kidoz, MMGuardian, and KidsPlace, we found that all thesebrowsers allow visited websites to store persistent tracking HTTPcookies (or Local Storage) on the child device. These cookies arenot erased when the browser app is closed.
Restricted SDKs from past work.
We also study the SDKs iden-tified in past studies [28, 62] that are restricted by their developers(e.g., fully prohibited, or use with particular parameters) for usein children’s apps (as stated in their policies as of June 2020). Weevaluated the privacy policies for the seven prohibited SDKs de-tected, and concluded that four companies, Crashlytics, Amplitude,Braze (formerly Appboy), and Appnext, still prohibit the use oftheir SDKs in children’s apps; two others (Tapjoy and Branch) now The use of tfcd=1 marks an ad request as child-directed; see https://support.google.com/admanager/answer/3671211?hl=en. Note that Disney, a former partner of Circle, is the target of a class action lawsuit forusing a similar SDK in children’s apps; see https://unicourt.com/case/pc-db1-rushing-et-al-v-the-walt-disney-company-et-al-494632. require developers to set the appropriate parameters; and the lastone (Supersonic/ironSource) removed any restriction.From static analysis, we found several prohibited SDKs beingused: 25/44 children apps and 8/73 shared apps use Google Crash-Lytics; unGlueKids children app uses Branch SDK (without the do-no-track mode); and Limitly uses Appnext SDK. Aside fromGoogle CrashLytics, we also observed Branch (7 apps), Amplitude(6 apps), Braze (4 apps), and Tapjoy (1 app) SDKs in the shared apps.Through analysing traffic generated from child device, we con-firm that five Android solutions use prohibited SDKs. Also forLife360, we note that Branch SDK “do-not-track” mode was dis-abled since the network traffic from child device contains AndroidID, Android Advertising ID (AAID), and local private IP. Addition-ally, three Android solutions FindMyKids, KidsPlace, and Circlecontact Crashlytics prohibited SDK server (reports.crashlytics.com),and Qustodio communicates with the Braze prohibited SDK.
PII exposure to third-parties.
COPPA Safe Harbor providers.
We check the behavior of (3/13)(Kidoz, FamilyTime, FindMyKids) Android solutions certified by theUS FTC’s COPPA Safe Harbor program [74] (by kidSAFE [65]; wealso checked other programs under Safe Harbor, and the parentalcontrol tools websites/descriptions). Our traffic analysis collectedfrom the child device reveals that FindMyKids use three trackers andleak Android Advertising ID to at least two trackers graph.facebook.com and adjust.com. FindMyKids includes two flags when callingFacebook to enable application tracking and advertiser tracking(both were enabled) [26]. FindMyKids also shares child Android IDwith Yandex Metrica (appmetrica.yandex.net). Yandex Metrica pro-vides an option ( limit_ad_tracking ) that can be used to restricttracking. However, the FindMyKids transmits this flag as false from the child device [80]. We also found that FamilyTime sendsthe child’s name, email address and phone
In this section, we summarize the impact of exploiting some of thediscovered vulnerabilities in the analyzed parental control tools.
Device compromise.
Device compromise presents serious secu-rity and privacy risks, especially if a vulnerability can be exploited etrayed by the Guardian ACSAC 2020, December 7–11, 2020, Austin, USA remotely. We found multiple vulnerabilities in the Blocksi networkdevice that can compromise the device itself. These include an ex-ploitable command injection vulnerability and a vulnerability inprotecting the device’s serial number, which is used in authentica-tion. A remote attacker can use these vulnerabilities to take controlover the Blocksi device by simply knowing the parent’s email ad-dress (see Sec. 5.1 and Sec. 5.3). In particular, using the serial numberand email, an attacker can exploit the command injection vulnera-bility and spawn a reverse TCP shell on the device. At this stage, theattacker gains full control of the device, and can read/modify unen-crypted network traffic, disrupt the router’s operation (cf. DHCPstarvation [71]), or use it in a botnet (cf. Mirai [8]).
Account takeover.
Parental accounts can be compromised in mul-tiple ways. First, none of the parental control tools’ web interfaceexcept Norton enforced HSTS, and most were found vulnerableto SSLStrip attacks. Therefore, an on-path attacker can possiblygain access to the parent account using SSLStrip, unless parentscarefully check the HTTPS status. Second, login pages that allowunlimited number of password trials could allow password guessing(especially for weak passwords). Note that most parental controltools’ password policies are apparently weak (cf. NIST [36]); someproducts accept passwords as short as one character. Third, prod-ucts with broken authentication allow access to parental accountswithout credentials. For example, SecureTeen provides an API end-point (see Sec. 5.4) to access the parental account, by knowing onlythe parent email address. If logged-in, the attacker has access toa large amount of PII, social media/SMS messages, phone history,child location—even enabling possibilities of physical world attacks.
Data leakage from backends.
Failure to protect the parental con-trol backend databases exposes sensitive child/parent data at alarge scale. Firebase misconfigurations exposed data that belongsto 500K+ children and parents from three apps. Such leakage maylead to potential exploitation of children both online and offline.
PII on the network.
COPPA mandates reasonable security proce-dures for protecting children’s information [32]. However, we foundseveral parental control tools transmit PII insecurely. For example,FindMyKids leaks surrounding voice, and the child’s picture. Thiscould put a child in physical danger since the attacker can learnintimate details from the child’s voice records and her surrounding,and also recognize the child from her photo. KidControl allows thechild to send SOS messages when she is in a dangerous situation.However, an attacker can identify and drop the SOS message at willas it is sent via HTTP. Moreover, KoalaSafe and Blocksi networkdevices append the child’s device MAC address to outgoing DNSrequests, enabling persistent tracking.
Parental control solutions are used by parents to help them protecttheir children from online risks. Nevertheless, some of these solu-tions have made news in the recent years for the wrong reasons.Our cross-platform comprehensive analysis of popular solutionsshows systematic problems in the design and deployment of all theanalyzed solutions (except Bitdefender, TinyFilter, Anti-porn addon,Kaspersky, and Norton) from a security and privacy point of view.Indeed several of these solutions can undermine children’s onlineand real-world safety. As these solutions are viewed as an essential instrument to provide children a safer online experience by manyparents, these solutions should be subjected to more rigorous andsystematic evaluation, and more stringent regulations.
ACKNOWLEDGMENTS
This work was partly supported by a grant from the Office of thePrivacy Commissioner of Canada (OPC) Contributions Program.We thank the anonymous ACSAC 2020 reviewers for their insightfulsuggestions and comments.
REFERENCES [1] ACPM. 2016. SSLUnpinning - Xposed Module. https://github.com/ac-pm/SSLUnpinning_Xposed/.[2] David Adrian, Karthikeyan Bhargavan, Zakir Durumeric, Pierrick Gaudry,Matthew Green, J. Alex Halderman, Nadia Heninger, Drew Springall, EmmanuelThomé, Luke Valenta, Benjamin VanderSloot, Eric Wustrow, Santiago Zanella-Béguelin, and Paul Zimmermann. 2015. Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice. In
ACM CSS . 5–17.[3] Kendra Allison. 2018.
Online Risks, Sexual Behaviors, And Mobile TechnologyUse In Early Adolescent Children: Parental Awareness, Protective Practices, AndMediation . Ph.D. Dissertation. University of South Carolina.[4] Collin Anderson, Masashi Crete-Nishihata, Chris Dehghanpoor, Ron Deibert,Sarah McKune, Davi Ottenheimer, and John Scott-Railton. 2015. Are the KidsAlright? Digital Risks to Minors from South Korea’s Smart Sheriff Application.Article.[5] Android. Last accessed Oct. 2020. Android Device Administration. https://developer.android.com/guide/topics/admin/device-admin/.[6] Android. Last accessed Oct. 2020. UI/Application Exerciser Monkey. https://developer.android.com/studio/test/monkey.html.[7] Anton Skshidlevsky. Last accessed Oct. 2020. Linux Deploy. https://github.com/meefik/linuxdeploy/.[8] Manos Antonakakis, Tim April, Michael Bailey, Matt Bernhard, Elie Bursztein,Jaime Cochran, Zakir Durumeric, J. Alex Halderman, Luca Invernizzi, MichalisKallitsis, Deepak Kumar, Chaz Lever, Zane Ma, Joshua Mason, Damian Menscher,Chad Seaman, Nick Sullivan, Kurt Thomas, and Yi Zhou. 2017. Understandingthe Mirai Botnet. In
USENIX Security . 1093–1110.[9] Appthority. 2018. Appthority: ENTERPRISE MOBILE THREAT REPORT - Fire-base Vulnerability: Exposing Sensitive Data via Thousands of Mobile Apps.[10] Michael Backes, Sven Bugiel, and Erik Derr. 2016. Reliable third-party librarydetection in android and its security applications. In
ACM SIGSAC CCS . 356–367.[11] Anthony Bellissimo, John Burgess, and Kevin Fu. 2006. Secure Software Updates:Disappointments and New Challenges. In
USENIX HotSec
ACM SIGSAC CCS
Journal of Computer Virology and Hacking Techniques (2014).[19] Xavier de Carné de Carnavalet and Mohammad Mannan. 2016. Killed by proxy:Analyzing client-end TLS interception software. In
NDSS
CSAC 2020, December 7–11, 2020, Austin, USA S. Ali et al.
PETS .[29] OWASP Foundation. Last accessed Oct. 2020. HTML5 Security CheatSheet. https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html
Digital identity guidelines: Authentication and lifecycle management[including updates as of 12-01-2017]
ACM SIGCOMM C2B(I)D .[42] Gaëtan Leurent and Thomas Peyrin. 2019. From collisions to chosen-prefixcollisions application to full SHA-1. In
EUROCRYPT . Springer.[43] Xurong Li, Chunming Wu, Shouling Ji, Qinchen Gu, and Raheem Beyah. 2017.HSTS Measurement and an Enhanced Stripping Attack Against HTTPS. In
Se-cureComm . Springer.[44] Meng Luo, Pierre Laperdrix, Nima Honarmand, and Nick Nikiforakis. 2019. TimeDoes Not Heal All Wounds: A Longitudinal Analysis of Security-MechanismSupport in Mobile Browsers. In
NDSS .[45] Jack Madden and Brian Madden. 2013.
Enterprise Mobility Management: Every-thing you need to know about MDM, MAM, and BYOD
An Examination of Parenting Strategies for Children’s OnlineSafety . Ph.D. Dissertation. Carnegie Mellon University.[48] MITMProxy.org. Last accessed Oct. 2020. HTTPS proxy. https://MITMProxy.org/.[49] MOBSF. Last accessed Oct. 2020. Mobile-Security-Framework-MobSF. https://github.com/MobSF/Mobile-Security-Framework-MobSF.[50] Brendan Moran, Hannes Tschofenig, David Brown, and Milosch Meriac. 2019.
AFirmware Update Architecture for Internet of Things
NDSS .[59] Abbas Razaghpanah, Narseo Vallina-Rodriguez, Srikanth Sundaresan, ChristianKreibich, Phillipa Gill, Mark Allman, and Vern Paxson. 2015. Haystack: In situmobile traffic analysis in user space. arXiv preprint arXiv:1510.01419 (2015).[60] Bradley Reaves, Jasmine Bowers, Nolen Scaife, Adam Bates, Arnav Bhartiya,Patrick Traynor, and Kevin RB Butler. 2017. Mo (bile) money, mo (bile) problems:Analysis of branchless banking applications.
ACM TOPS (2017).[61] Reverse Shell Security. Last accessed Oct. 2020. Routersploit Embedded DevicesExploitation framework. https://github.com/threat9/routersploit/.[62] Irwin Reyes, Primal Wijesekera, Joel Reardon, Amit Elazari Bar On, Abbas Raza-ghpanah, Narseo Vallina-Rodriguez, and Serge Egelman. 2018. “Won’t somebodythink of the children?” examining COPPA compliance at scale.
PETS
MobiCom .[68] Sharon Shasha, Moustafa Mahmoud, Mohammad Mannan, and Amr Youssef.2019. Playing with danger: A taxonomy and evaluation of threats to smart toys.
IEEE Internet of Things Journal (2019), 2986–3002.[69] Oleksii Starov and Nick Nikiforakis. 2017. Extended tracking powers: Measuringthe privacy diffusion enabled by browser extensions.. In
WWW
IEEE ANTS arXiv preprint arXiv:1609.07190
ACM CSCW
In this appendix, we first provide some recommendations for parentalcontrol solution providers. Then, we present the corpus of parentalcontrol tools that we evaluated. Then, we provide a summary of thetechniques adopted by the analyzed Android solutions to monitorchild activities. Finally, we report our observations of tracking andPII sharing done by third-party SDKs and libraries embedded inthese parental control tools. etrayed by the Guardian ACSAC 2020, December 7–11, 2020, Austin, USA
In what follows, we list our recommendations for parental controlsolution providers.
Addressing vulnerabilities.
Because of the sensitivity of the in-formation manipulated by the parental control tools, companiesshould conduct regular security audits; the issues we listed inSec. 3.3 can serve as a starting point. Moreover, they should havea process to address vulnerabilities such as responsible disclosureand bug bounty programs. Currently, none except Kaspersky andBitdefender participates in such programs.
Enforcing best practices.
Parental control companies should relyon publicly available guidelines and best practices, including properAPI endpoint authentication and web security standards [29, 30].We also strongly encourage companies to adopt a strong passwordpolicy in their products, because the use of default, weak and stolencredentials has been exploited in many known data breaches [76].In the case of network devices, manufacturers should employ asecure firmware update architecture (see e.g., IETF [50]). Adoptingknown best practices is critical due to the especially vulnerableuser base of these products.
Monitoring account activities.
Parental control tools should re-port suspicious activities on the parent’s account such as passwordchanges and accesses from unrecognized devices. These activitiescould indicate account compromise.
Limiting data collection.
Parental control tools should limit thecollection, storage, and transmission of the children’s data to whatis strictly necessary. For instance, the solution should not store PIInot required for the solution’s functionality. The parental controltools should also allow the parent to selectively opt-out of the datacollection in certain features.
Securing communication.
Transmission of PII should happen ex-clusively over secure communication channels. The solution shouldutilize MITM mitigation techniques such as host white-listing, cer-tificate pinning, and HSTS [37].
Limiting third-parties and SDKs.
Parental control tools shouldlimit the usage of trackers and tracking SDKs in apps intended forchildren. For the SDKs that allow special parameter for children’sapps, those parameters must be used appropriately.
Tables 2, 3, 4 and 5 provide some information about the corpus ofthe parental control solutions analyzed throughout our study.
Table 2: List of parental control devices and their firmwareversions. Device Version
Circle Home Plus 3.10.0.2KoalaSafe 1.26825KidsWifi 1.165Blocksi Router 2.4Bitdefender 2.1.66.4Roqos 1.30.24HomeHalo 1.0.0.8Fingbox 0.5-2ubuntu4
Table 3: List of parental control Android solutions. * denotesversions downloaded from vendor websites with extra fea-tures; P , T refer to premium and trial versions, respectively. Solution Installs App package name Version
Circle 10K+ com.meetcircle.circle P2.8.0.2FamilyTime 500K+ io.familytime.dashboardio.familytime.parentalcontrolio.familytime.parentalcontrol( * ) P2.1.0.210P3.0.5.3196.psP4.0.6.4209.webFamiSafe 500K+ com.wondershare.FamiSafe P3.0.9.107FindMyKids 10M+ org.findmykids.apporg.findmykids.child T1.9.9T1.9.9Kidoz 1M+ com.kidozcom.kidoz.demo.go( * ) P4.0.5.8P4.0.6.3KidControl 1M+ ru.kidcontrol.gpstrackerapp.gpsme T4.0.9Tk5.2.10KidsPlace 5M+ com.kiddoware.kidsplacecom.kiddoware.kidsafebrowsercom.kiddoware.kidsvideoplayercom.kiddoware.kidsplace.remotecontrolcom.kiddoware.kidspictureviewer P3.5.6P1.7.8P1.7.8P1.4.5P1.0.9Life360 50M+ com.life360.Android.safetymapd T18.7.1MMGuardian 1M+ com.mmguardian.parentappcom.mmguardian.childappcom.mmguardian.childapp( * ) P3.6.4P3.7.7P10003.9.5MobileFence 1M+ com.mobilefence.familycom.mobilefence.family.plugin( * ) T2.9.3.1T1.4Qustodio 1M+ com.qustodio.qustodioappcom.qustodio.qustodioapp( * ) T180.14.2.2-familyT680.14.2.2-familyScreenTime 1M+ com.screentime.rccom.screentime T3.11.23T5.3.23SecureTeen 1M+ com.infoweise.parentalcontrol.secureteencom.infoweise.parentalcontrol.secureteen.childcom.infoweise.parentalcontrol.secureteen.child( * ) T8.0.0T1.6000.5T1.7001.0 Table 4: List of parental control Windows applications andtheir corresponding websites’ popularity (traffic/ranking);we analyzed the lasted versions available.
Application
Qustodio 27K US 85,673Kaspersky 1,400K IN, US, RU 2,114Dr. Web 84K US 40,515Norton 6,400K US 431Spyrix 21K UK 230,966Kidswatch NA NA 2,175,932KidLogger 4.2K PE 156,645Kurupira 17K BR 84,918
Table 5: List of parental control Chrome extensions.
Extension Installs ID Version
Blocksi Web Filter 40K+ pgmjaihnmedpcdkjcgigocogcbffgkbn 1.0.144Parental control 3K+ bdjgolepmhcchlgncgkmobepknekjbkd 1.0.22TinyFilter 20K+ epniipcfpbjliciholgdeipceecgcfmj 2016.11.1.1Porn Blocker 10K+ kmillccnmojidmkhhjngjlalnbhpobcl 1.5. 2Adult Blocker 80K+ onjjgbgnpbedmhbdoikhknhflbfkecjm 6.2.8Anti-porn addon 20K+ peocghcbolghcodidjgkndgahnlaecfl 2.20.0MateCode Blocker 80K+ gppopmmjibhcboobpmfombbkoehgicoh 1.0.5MetaCert 20K+ dpfbddcgbimoafpgmbbjiliegkfcjkmn 0. 10.18FamilyFriendly 7K+ epdelmeadnnoadlcalkmacoopocdafnp 0.9.0Kids Safe Web 3K+ lakceedfffnfheaipjadbcndkldlplnd 1.0.7
CSAC 2020, December 7–11, 2020, Austin, USA S. Ali et al.
Table 6 provides a summary of some techniques adopted by theanalyzed Android solutions. Four Android solutions (MMGuardian,MobileFence, Qustodio, and SecureTeen), distributed via their com-pany websites, support additional features compared to their GooglePlay store version.
Table 6: Techniques used to monitor child activities includ-ing web filtering, phone calls, SMS, and social media. (cid:32) : refers to service supported by Google Play version; (cid:71)(cid:35) : refers to a feature supported by a version distributed viathe company website.
ACSAC 2020, December 7–11, 2020, Austin, USA S. Ali et al.
Table 6 provides a summary of some techniques adopted by theanalyzed Android solutions. Four Android solutions (MMGuardian,MobileFence, Qustodio, and SecureTeen), distributed via their com-pany websites, support additional features compared to their GooglePlay store version.
Table 6: Techniques used to monitor child activities includ-ing web filtering, phone calls, SMS, and social media.: refers to service supported by Google Play version;: refers to a feature supported by a version distributed viathe company website.
Technique C i r c l e F a m i l y T i m e F a m i S a f e F i n d M y K i d s K i d o z K i d C o n t r o l K i d s P l a c e L i f e MM G u a r d i a n M o b i l e F e n c e Q u s t o d i o S c r ee n T i m e S e c u r e T ee n Superuser requestActivate device adminMonitor user actionsRetrieve window contentObserve typed textTurn on explore by touchEnhanced web accessibilityApp usage statisticsSetup VPN connectionInstall custom browserRun MDM AgentRead history bookmarksKomodia SDKMake/manage phone callsSMS permissionNotification accessAccess fine locationCustom SMS appFacebook LoginYouTube OAuthCustom video playerTake screenshot
Table 7 shows the use of third-party tracking SDKs in the ana-lyzed 153 Android apps. We used MOBSF [49] to extract the list ofthird-party tracking SDKs from all apps based on Exodus-Privacy’stracker list. On average, we found 4.5 SDKs per app (max 10 SDKs)in children apps. The average number of SDKs increases to about5.3 SDKs per app in shared apps and parent apps. We also foundGoogle Firebase Analytics, Google CrashLytics are present in over50% of all types of apps; see Fig. 3. We also identified tracking third-party SDKs from network traffic generated during our dynamicanalysis; see Fig. 4. FamiSafe Android app gets full access to the child’s YouTube account includingrights to view, edit, delete the child’s YouTube videos and playlists, and rate videos,post, edit/delete comments and captions. MobileFence initially setup by default to monitor both the child and parent devices. SecureTeen Android app uses a keylogger to record all social media activities on thechild device. G oog l e F i r e b a s e A n a l y t i c s G oog l e C r a s h L y t i c s F a ce b oo k L og i n F a ce b oo k Sh a r e G oog l e A n a l y t i c s G oog l e T ag M a n ag e r F a ce b oo k A n a l y t i c s F a ce b oo k P l a ce s G oog l e A d s G oog l e D o ub l e C li c k G oog l e F i r e b a s e A n a l y t i c s G oog l e A n a l y t i c s G oog l e C r a s h L y t i c s G oog l e T ag M a n ag e r G oog l e A d s G oog l e D o ub l e C li c k F a ce b oo k A n a l y t i c s F a ce b oo k L og i n F a ce b oo k Sh a r e F a ce b oo k P l a ce s G oog l e F i r e b a s e A n a l y t i c s G oog l e C r a s h L y t i c s F a ce b oo k L og i n F a ce b oo k Sh a r e G oog l e A n a l y t i c s G oog l e A d s F a ce b oo k A n a l y t i c s F a ce b oo k P l a ce s G oog l e D o ub l e C li c k G oog l e T ag M a n ag e r P e r ce n t ag e o f a pp s SharedChildrenParents
Figure 3: Tracking SDKs present in Android apps foundthrough static analysis, see Sec. 5.7. d o ub l ec li c k . n e t goog l e - a n a l y t i c s . c o m f a ce b oo k . c o m f a ce b oo k . n e t goog l e t ag m a n ag e r . c o m c r a s h l y t i c s . c o m goog l e . c o m goog l e a d s e r v i ce s . c o m goog l e . c a g s t a t i c . c o m c r a s h l y t i c s . c o m f a ce b oo k . c o m goog l e - a n a l y t i c s . c o m d o ub l ec li c k . n e t goog l e . c o m a d j u s t . c o m goog l e . c a goog l e a d s e r v i ce s . c o m n e w r e li c . c o m n r - d a t a . n e t P e r ce n t ag e o f a pp s ParentsChildren
Figure 4: Tracking SDKs present in Android solutions foundthrough dynamic analysis, see Sec. 5.7.Table 7: Use of tracking SDKs in children apps, shared apps(i.e., the same is used by both parents and children), and par-ent apps found through static analysis.Childrenapps Sharedapps Parentapps
Table 7 shows the use of third-party tracking SDKs in the ana-lyzed 153 Android apps. We used MOBSF [49] to extract the list ofthird-party tracking SDKs from all apps based on Exodus-Privacy’stracker list. On average, we found 4.5 SDKs per app (max 10 SDKs)in children apps. The average number of SDKs increases to about5.3 SDKs per app in shared apps and parent apps. We also foundGoogle Firebase Analytics, Google CrashLytics are present in over50% of all types of apps; see Fig. 3. We also identified tracking third-party SDKs from network traffic generated during our dynamicanalysis; see Fig. 4. FamiSafe Android app gets full access to the child’s YouTube account includingrights to view, edit, delete the child’s YouTube videos and playlists, and rate videos,post, edit/delete comments and captions. MobileFence initially setup by default to monitor both the child and parent devices. SecureTeen Android app uses a keylogger to record all social media activities on thechild device. G oog l e F i r e b a s e A n a l y t i c s G oog l e C r a s h L y t i c s F a ce b oo k L og i n F a ce b oo k Sh a r e G oog l e A n a l y t i c s G oog l e T ag M a n ag e r F a ce b oo k A n a l y t i c s F a ce b oo k P l a ce s G oog l e A d s G oog l e D o ub l e C li c k G oog l e F i r e b a s e A n a l y t i c s G oog l e A n a l y t i c s G oog l e C r a s h L y t i c s G oog l e T ag M a n ag e r G oog l e A d s G oog l e D o ub l e C li c k F a ce b oo k A n a l y t i c s F a ce b oo k L og i n F a ce b oo k Sh a r e F a ce b oo k P l a ce s G oog l e F i r e b a s e A n a l y t i c s G oog l e C r a s h L y t i c s F a ce b oo k L og i n F a ce b oo k Sh a r e G oog l e A n a l y t i c s G oog l e A d s F a ce b oo k A n a l y t i c s F a ce b oo k P l a ce s G oog l e D o ub l e C li c k G oog l e T ag M a n ag e r P e r ce n t ag e o f a pp s SharedChildrenParents
Figure 3: Tracking SDKs present in Android apps foundthrough static analysis, see Sec. 5.7. d o ub l ec li c k . n e t goog l e - a n a l y t i c s . c o m f a ce b oo k . c o m f a ce b oo k . n e t goog l e t ag m a n ag e r . c o m c r a s h l y t i c s . c o m goog l e . c o m goog l e a d s e r v i ce s . c o m goog l e . c a g s t a t i c . c o m c r a s h l y t i c s . c o m f a ce b oo k . c o m goog l e - a n a l y t i c s . c o m d o ub l ec li c k . n e t goog l e . c o m a d j u s t . c o m goog l e . c a goog l e a d s e r v i ce s . c o m n e w r e li c . c o m n r - d a t a . n e t P e r ce n t ag e o f a pp s ParentsChildren
Figure 4: Tracking SDKs present in Android solutions foundthrough dynamic analysis, see Sec. 5.7.Table 7: Use of tracking SDKs in children apps, shared apps(i.e., the same is used by both parents and children), and par-ent apps found through static analysis.Childrenapps Sharedapps Parentapps etrayed by the Guardian ACSAC 2020, December 7–11, 2020, Austin, USA
Table 8 lists the personal information used to detect PII data innetwork traffic. Tables 9 and 10 show the PII transmitted by Androidsolutions in plaintext through HTTP, and PII shared with third-parties, respectively.
Table 8: The list of personal information used to detect PIIdata in network traffic.
PII Description
AAID Android Advertising IDAndroid ID Android ID generated on device setupGSF ID Google Services Framework IDPhone Serial Mobile serial numberIMEI Phone equipment IDSIM ID SIM card IDAP BSSID MAC addresses of used hotspotsAP SSID SSIDs of used hotspotsNearby AP BSSID MAC addresses of surrounding hotspotsNearby AP SSID SSIDs of surrounding hotspotsMAC Address MAC address of the WiFi interfaceIP address IP address of the WiFi interfaceBD ADDR MAC address of the Bluetooth interfaceGoogle Email Google play account email addressUser credentials Account ID and passwordName User’s first and last namesEmail User’s email addressPhone
Table 9: Android solutions sending sensitive data in plain-text.
Solution Data Destination
Kidoz Account username/password kidoz.netKidoz Child name kidoz.netKidsPlace Child Android ID kiddoware.comKidsPlace Child phone serial kiddoware.comKidsPlace Parent email kiddoware.comKidControl Child Geolocation kid-control.comKidControl Parent email kid-control.comKidControl Parent name kid-control.comLife360 Child name pubnub.comLife360 Parent name pubnub.comMMGuardian Account username/password * mmguardian.comMMGuardian Parent email mmguardian.comMMGuardian Parent IMEI mmguardian.comMMGuardian Parent/child phone * : The parent’s password is hashed using SHA1 without salting. Table 10: Sharing PII with third-parties.