Parental controls – Safer solutions or new pitfalls?

Suzan Ali, Mounir Elgharabawy, Quentin Duchaussoy, Mohammad Mannan, and Amr Youssef Concordia University, Montreal, Canada

Abstract—Parental control solutions are used by many parents to provide their children a safer digital environment. These solutions often require dangerous privileges to function. We analyzed privacy/security risks of popular solutions and found that many leak personal information and are vulnerable to attacks, betraying the trust of parents and children. Index Terms: Privacy, Security, Mobile and Personal devices

THEINTRODUCTION flaws in these solutions can lead to serious privacy leakage, and online and real-world security and Many children are now as connected to the In- safety issues. ternet as adults, if not more. The Internet provides an important avenue for education, entertainment To better understand privacy and security im- and social connection for children. However, the plications of parental control solutions, we design dark sides are also significant: children are by an experimental framework with a set of security nature vulnerable to online exploitation, internet and privacy tests, and systematically analyze pop- addiction, and other negative effects of online ular representative solutions: 8 network devices, social networking, including cyber-bullying and 8 Windows applications, 10 Chrome extensions, even cyber-crimes. To provide a safe internet and 46 Android apps representing 28 Android experience, many parents rely on parental con- solutions grouped by vendor (an Android solution trol solutions, which are also recommended by is typically composed of a child app, a parent government agencies, including US FTC and UK app, and an online parental dashboard). We found Council for Child Internet Safety. 170 vulnerabilities among the solutions tested; the majority of solutions broadly fail to adequately Parental control solutions are available for dif- preserve the security and privacy of their users— ferent platforms including desktop applications, both children and parents. browser extensions, mobile apps, and network devices that can monitor all connected comput- Our notable findings include: (i) The Blocksi ers and smart-devices. Most of these solutions parental control router allows remote command require special privileges to operate, such as mo- injection, enabling an attacker with a parent’s bile device administration/management capabili- email address to eavesdrop/modify the home net- ties, TLS interception, access to browsing data, work’s traffic, or use the device in a botnet (cf. and control over the network traffic. In addition, Mirai). Blocksi’s firmware update mechanism is they also collect a lot of sensitive user data, such also completely vulnerable to a network attacker. as voice, video, location, messages and social (ii) 9/28 Android solutions and 4/8 network de- media activities. Thus design and implementation vices do not properly authenticate their server

IEEE Security & Privacy Published by the IEEE Computer Society © 2021 IEEE 1 API endpoints, allowing illegitimate access to Our analysis across multiple platforms is in- view/modify server-stored children/parents data. spired by the existing work and past security (iii) 6/28 Android solutions allow an attacker incidents, and provides a broader picture of the to easily compromise the parent account at security and privacy risks of parental control the server-end, enabling full account control to tools. the child device (e.g., install/remove apps, al- low/block phone calls and internet connections). Background and Threat Model (iv) 8/28 Android solutions transmit Personally Identifiable Information (PII) via HTTP (e.g., kid- Monitoring Techniques SAFE certified Kidoz sends account credentials Network parental control devices can monitor via HTTP). network traffic but usually cannot inspect the As part of responsible disclosure, we shared content of encrypted traffic. The devices ana- our findings and possible fixes with all solution lyzed act as a man-in-the-middle between the providers. Two months after disclosure, only ten client device and the internet router as follows: companies responded, with seven custom and performing Address Resolution Protocol (ARP) three automatic replies. Notable changes after the spoofing, or creating a separate access point for disclosure: MMGuardian deprecated their custom all children’s devices. ARP spoofing enables the browser; FamiSafe fixed the Firebase network device to impersonate the home router, security issue; and FamilyTime enabled HSTS on and monitor all local network traffic. their server. Details of our findings and disclosure Android apps rely on several Android-specific responses are available in the ACSAC version of mechanisms, including the following. (1) Device our paper [7]. administration, which provides several adminis- trative features at the system level, including: Related Work device lock, factory reset, certificate installation, Over the past years, several parental control and device storage encryption. (2) Mobile de- tools have made the news for security and privacy vice management (MDM), which enables addi- breaches. Example exposures include: TeenSafe tional control and monitoring features, designed leaked thousands of children’s Apple IDs and for businesses to fully control/deploy devices in passwords; and Family Orbit exposed nearly 281 an enterprise setting. (3) Android accessibility GB of children’s photos and videos on a cloud service, which enables capturing and retrieving server. window content, logging keystrokes, and control- Between 2015 and 2017, researchers from the ling website content by injecting JavaScript code Citizen Lab (citizenlab.ca), Cure53 (cure53.de), into visited web pages. (4) Android VPN, cus- and OpenNet Korea (opennetkorea.org) published tom browsers, and third-party domain classifiers, a series of technical audits [1] of three popular which are used to filter web content. (5) Access Korean parenting apps mandated by the Ko- to Facebook and YouTube OAuth credentials, rean government, revealing serious security and which are used to monitor the child’s activities privacy issues in these apps. In 2019, Feal et on Facebook and YouTube. al. [2] studied 46 parental control Android apps Windows applications use the following tech- for data collection and data sharing practices, niques: a TLS proxy is installed by inserting a and the completeness and correctness of their self-signed certificate in the trusted root certificate privacy policies. In some of these apps, we fur- store, allowing content HTTPS content analy- ther identified new critical security issues (e.g., sis/modification; user applications are monitored leakage of plaintext authentication information) for their usage and duration; and user activity using our comprehensive app analysis framework. is monitored via screenshots, keylogging, and Reyes et al. [3] analyzed children Android apps accessing the webcam. for COPPA compliance. Out of 5855 apps, the Parental control Chrome extensions use majority of the analyzed apps were found to Chrome to monitor the user-requested potentially violate COPPA, and 19% were found URLs, including: intercepting and redirecting to send PII in their network traces. traffic, modifying page content and meta-data

2 IEEE Security & Privacy including cookies. 6) Weak password policy: Acceptance of very weak passwords (e.g., with 4 characters or Threat Model less). We consider the following attacker types with 7) Online password brute-force: No de- varying capabilities (but require no physical ac- fense against unlimited login attempts on cess to either the child/parent device or back- the online parental login interface (e.g., end servers). (1) On-device attacker: a malicious CAPTCHA). app with limited permissions on the child/parent 8) Uninformed suspicious activities: No noti- device. (2) Local network attacker: an attacker fications to parents about indicators of pos- with direct or remote access to the same local sible compromise (e.g., the use of parental network as the child device. (3) On-path attacker: accounts on a new device, or password a man-in-the-middle attacker between the home changes). network and a solution’s backend server. (4) Re- 9) Insecure PII transmission: PII from the mote attacker: any attacker who can connect to a client-end is sent without encryption, allow- solution’s backend server. ing an adversary to eavesdrop for PII. 10) PII exposure to third-parties: Direct PII Potential Security and Privacy Issues collection and sharing (from client devices) We define the following list of potential se- with third-parties. curity and privacy issues to evaluate parental control tools (tested using only our own accounts Selection of Parental Control Solutions We chose solutions used in the most pop- where applicable). This list was initially inspired ular computing platforms for mobile devices by previous work [1], [4], [5], [6], and then (Android), personal computers (Windows), web iteratively refined by us. browsers (Chrome), and selected network prod- 1) Vulnerable client product: A parental con- ucts from popular online marketplaces (Amazon). trol product (including its update mecha- We used “Parental Control” as a search term on nism) being vulnerable, allowing sensitive Amazon and Chrome Web Store and selected information disclosure (e.g., via on-device eight devices and ten extensions. For Windows side-channels), or even full product com- applications, we relied on rankings and reviews promise (e.g., via arbitrary code execution). provided by specialized media outlets, and se- 2) Vulnerable backend: The use of remotely lected eight applications. exploitable outdated server , and We selected 158 apps with over 10K+ in- misconfigured or unauthenticated backend stallations from Google Play, four companion API endpoints (e.g., Google Firebase in apps for network devices, six additional apps Android apps). available on their official websites with additional 3) Improper access control: Failure to prop- features, making the total to 153 (after removing erly check whether the requester owns the 15 unresponsive/unrelated apps); 51/153 are pure account before accepting queries at the children apps; 24 are pure parent apps; and 78 server-end (e.g., insecure direct object ref- are used for both parent and child devices. For erence). in-depth analysis, we picked 46 popular Android 4) Insecure authentication secrets: Plaintext apps representing 28 parental control solutions. storage or transmission of authentication secrets (e.g., passwords and session IDs). Methodology 5) SSLStrip attack: The parental control tool’s We combine dynamic (primarily traffic and online management interface is vulnerable usage) and static (primarily code review/reverse- to SSLStrip attacks that strip away the secu- engineering) analysis to identify security and rity provided by HTTPS, exposing private privacy flaws in parental control tools; for an information in plaintext; countermeasures overview, see Fig.1. For each product, we exist (e.g., HSTS) but must be correctly first conduct a dynamic analysis and capture implemented. the parental control tool traffic during its usage

Nov/Dec 2021 3 (as parents/children); if the traffic is in plain- apps. We test each Windows application and text or decryptable (e.g., via TLS interception), Chrome extension on a fresh virtual we also analyze the information sent. Second, machine with Chrome, and mitmproxy installed. we statically analyze their binaries (via reverse Traffic Analysis. After intercepting traffic, we engineering) and scripts (if available). We pay parse and commit the collected traffic to an specific attention to the API requests and URLs SQLite database and check for the following present in the code to complement the dynamic security and privacy related issues. analysis. After merging the findings, we look into We check for PII and authentication secrets the domains contacted and check the traffic for transmitted in plaintext, or leakage of PII to third- security flaws (e.g., TLS weaknesses). Third, we party domains. We automatically search for PII test the security and privacy issues listed under items (i.e., case-insensitive partial string match) “Potential Security and Privacy Issues” against in the collected traffic, and record the leaked the collected API URLs and requests. For the information, including the HTTP request URL. parental control tool with an online interface, we We decode the collected network traffic using assess the password-related issues and test the common encoding (base64 and URL encoding) SSLStrip attack against the login page. and encode possible PII using hashing algorithms (MD5, SHA1, SHA256, and SHA512) to find out Dynamic Analysis obfuscated leaks. Usage Emulation and Experimental Setup. We set To find API endpoints with improper access up test environments for each solution, emulate control, we first identify all the APIs that can user actions for hours to days, with the goal be potentially exploited (without strong authenti- of triggering UI events looking for signs of PII cation), by replaying the recorded HTTP request leakage, weak security measures, or potential vul- stripped of authentication headers (e.g., cookies nerabilities, and collect the traffic from the child, and authorization header). Then, we retrieve the parent, and network devices, and then perform parameters used by these APIs (e.g., keys, tokens, relevant analysis. We evaluate the web filtering or unique IDs), and assess the parameters in terms mechanism by visiting a blocked website (gam- of their predictability and confidentiality. bling/adult) and a university website. We also We compile lists of known trackers, and then perform user activities monitored by platform- identify communication to these trackers and specific parental control features and evaluate the other third-party SDKs in the parental control solution’s operations. For example, on Android, tools traffic (third-parties are defined as any do- we perform basic phone activities (SMS, phone main other than the product providers). call) and internet activities (Instant messaging, Backend Assessment. We only look into the back- social media, browsing, and accessing blocked ends’ software components as disclosed by web content). servers or frameworks in their HTTP response We evaluate the network devices in a lab headers, such as “Server” and “X-Powered-By”. environment by connecting them to an internet- We then match these components against the enabled router (like in a domestic network setup) CVE database to detect known vulnerabilities with the OpenWrt firmware. We use test devices associated with these versions. with web browsing to emulate a child’s device. If the parental control device uses ARP spoofing, Static Analysis the test device is connected directly to the router’s Our static analysis aims to complement the wireless access point (AP); otherwise, the test de- dynamic analysis whenever we could not decrypt vice is connected to the parental control device’s the network traffic (e.g., in case of network wireless AP. We capture network traffic on both devices using TLS). We use static analysis to the test device and the router using Wireshark and identify PII leakage, contacted domains, weak tcpdump, respectively. security measures (e.g., bad input sanitization), For Android apps, we use separate Android or potential flaws in implemented mechanisms. phones to concurrently record and inspect net- We analyze the network device firmware work traffic originating from the child and parent whenever possible. We either attempt to extract

4 IEEE Security & Privacy Figure 1. Overview of our evaluation framework. the firmware directly from the device (via physi- SDKs. We use MOBSF (github.com/MobSF/ cal interfaces), or download the device firmware Mobile-Security-Framework-MobSF) to extract from the vendor’s website. We then scan the the list of third-party tracking SDKs from all network devices with several tools (OpenVas, 153 apps based on Exodus-Privacy’s tracker list. Nmap, Nikto and Routersploit), and match the identified software versions against public vulner- Online Interface Analysis ability . The online user interface is the primary com- munication channel between parents and parental We manually analyze the source control tools. It displays most of the data col- code of the Chrome extensions, which lected by the solutions, and may remotely enable mainly consists of scripts, separated into more intrusive features. Compromising the parent content scripts and background scripts. We account can be very damaging, and thus we eval- perform an automated analysis on all 153 uate the security of this interface. To check for Android apps using the Firebase Scanner SSLStrip attacks, we first set up a WiFi Access (github.com/shivsahni/FireBaseScanner) to Point with a set of network interception tools detect security misconfigurations in Firebase, a installed. Then, we connect the parental control widely used backend infrastructure management tool to our WiFi AP, and launch the SSLStrip for Android apps. We also use LibScout script (github.com/moxie0/sslstrip). We confirm (github.com/reddr/LibScout) to identify third- the effectiveness of the attack by comparing the party libraries embedded in these apps. result to the corresponding traffic in a regular Since LibScout does not distinguish which testing environment. To test the password pol- libraries are used for tracking purposes, we icy, we check if the service accepts a password use Exodus-Privacy (reports.exodus-privacy. with 4 characters or less. We also use Burp eu.org/en/trackers/) to classify tracking Suite (portswigger.net/burp) to perform password

Nov/Dec 2021 5 brute-force attacks, and limit our script only to 50 The three browsers fail to enforce HSTS (a se- authentication attempts on our own account from curity protocol design to protect against SSLStrip a single computer. We also test two scenarios attack), and lack persistent visual indication if the in which a parent should be notified (e.g., via website is served on HTTP. email): modification of the user’s password, and Windows applications and Chrome extensions. connection to the account from a new/unknown Other than Kidswatch, all tested Windows appli- device. cations relied on TLS proxies to operate. Some of these proxies do not properly perform certificate Results validation. For example, Qustodio and Dr. Web We analyzed the parental control tools be- accepted intermediate certificates signed with tween Mar. 2019 to Sep. 2020, which include: SHA1, and none of the proxies rejected revoked 8 network devices, 46 Android apps representing certificates. Two Chrome extensions download 28 Android solutions, 10 Chrome extensions and and run a third-party tracking script at run time, 8 Windows applications. We present some of the bypassing the static control of Chrome for ex- most prominent findings on the tested security tension security, which has been exploited in the and privacy issues (further details in [7]); for an wild by tricking developers into adding malicious overview see Table1. scripts masquerading as tracking scripts.

Vulnerable Backend Vulnerable Client Product Android apps. Google Firebase is a popular back- Network devices. The Blocksi firmware update end service used in 115/153 of our Android happens fully through HTTP. An integrity check apps dataset. Critical misconfigurations can allow is done on the downloaded binary image, using attackers to retrieve all unprotected data stored on an unkeyed SHA256 hash, again retrieved using the cloud server. We found 8 Android apps with HTTP, and thus rendering it useless. Therefore, insecure Firebase configurations; prominent expo- an on-path attacker can trivially alter the update sures include (verified using our own accounts): file and inject their own malicious firmware into FamiSafe with 500K+ installs exposes the parent the device; see Fig.2. email; Locate with 10K+ installs exposes the child name, phone number, and email; and My Family Online with 10K+ installs exposes the child name, child and parent phone numbers, parent email, and apps installed on child phone. Following our disclosure, FamiSafe fixed the Firebase security issue.

Figure 2. Blocksi update mechanism flaw.

Android apps. We found 3/28 Android solutions (FamiSafe, KidsPlace and Life360) do not en- crypt stored user data on shared external storage that can be accessed by any other apps with Figure 3. Blocksi improper access control. the permission to access the SD card. Exam- ples of the sensitive information include: the parent’s email and PIN code, phone numbers, Improper Access Control the child’s geolocation data, messages and social Network devices. For Blocksi’s login API end- media chats, visited websites, and even authenti- point, the device’s serial number (SN) and the cation tokens—which enabled us to read private registered user’s email are required to authenti- information from the child account remotely. In cate the device to the server. However, a remote addition, Kidoz, KidsPlace, and MMGuardian use attacker needs to know only one of these param- custom browsers to restrict and filter web content. eters to authenticate as the attacker can retrieve a

6 IEEE Security & Privacy Table 1. Most significant results for security flaws in parental control tools labelled following our threat model. : On-device attacker; : Local network attacker; : On-path attacker; : Remote attacker; -: not applicable; blank: no flaw found. In case the vulnerability can be exploited by 2 types of attackers, we display the fullest circle applicable. Network devices Android solutions Chrome Windows

Security Flaw Circle Home plus KoalaSafe KidsWifi Blocksi Router HomeHalo FingBox FamilyTime FamiSafe Kidoz KidControl KidsPlace Life360 MMGuardian MobileFence Qustodio ScreenTime SecureTeen Sentry Safe Lagoon Locategy Easy parental control Keepers Child Safety Bosco Saferkid Blocksi Web Filter Porn Blocker FamilyFriendly Qustodio Dr. Web Spyrix KidLogger

Vulnerable client product Vulnerable backend Improper access control --- Insecure authentication secret --- SSLStrip attack ------Online password bruteforce - --- - Weak password policy - --- - Uninformed suspicious activities - --- - Insecure PII transmission PII exposure to third-parties user’s email using their device SN or vice-versa, to all installed apps). Bosco’s API endpoint fails and thus access sensitive information about the to check the relation between the provided secure home network, e.g., the WiFi password, and MAC authorization token provided and the information addresses of connected devices, see Fig.3. requested, allowing any parent account with a To authenticate to HomeHalo’s API endpoint, valid token to request information about any it uses only the device’s SN and an HTTP header registered child knowing only its ID, which is called secretToken (an apparently fixed value set to the Android advertising ID (AAID) by of 100500). An on-path attacker can intercept and Bosco. However, AAID is available to all apps, modify these messages, and gain access to admin and thus, enabling an attacker with an app on the controls, e.g., the wireless SSID, password, or child device to easily retrieve child PII (e.g., child even the device’s root password. geolocation, phone call history, and pictures). Android apps. We found 9/28 Android solutions lack authentication for accessing PII. Prominent Insecure Authentication Secret examples include the following. In SecureTeen, Network devices. During the setup procedure of we found an API endpoint that enables any KidsWifi, the device creates an open wireless AP adversary to remotely compromise any parental with SSID “set up kidswifi”, making it temporar- account by knowing only the parent’s email, ily vulnerable to eavesdropping. The parent has allowing the attacker to monitor and control the to use this AP’s captive portal to configure the child device. In FamilyTime, a six-digit param- KidsWifi device to connect to the home network. eter childID is generated through a sequential Consequently, as this AP is open and the client- counter incremented by one per user, allowing a device communication happens through HTTP, remote attacker to collect the child name, gender, the home router’s WAN and KidsWifi’s LAN date of birth, email address, and child phone num- credentials become available to local attackers. ber (by simply trying all 6-digit values for chil- Android apps. Kidoz exposes the user email dID). In FamiSafe, an attacker app can retrieve and password in HTTP when the “Parental Lo- all the child social media messages and YouTube gin” link is clicked from the https://kidoz.net activities labeled as suspicious through an API home page. KidsPlace and Qustodio leak session request that requires several parameters stored in authentication cookies via HTTP, exposing the a log file on the shared external storage (available child’s current location, history of movements,

Nov/Dec 2021 7 and remote control functions on the child phone tools. We found notable use of third-party SDKs (e.g., block all phone calls) in Qustodio. For in parental control tools, except in Windows. For KidsPlace, the attacker can lock the child phone, network devices, we identified the use of third- disable the Internet, install malicious apps and party SDKs in the companion apps but not in the upload harmful content to the child mobile. firmware. Trackers. We identify several tracking third-party SSLStrip and Online Account Issues SDKs from network traffic generated during our We found that 11 Android solutions, four dynamic analysis from child device. Except Se- network devices and three Windows applica- cureTeen and Easy parental control, 26/28 An- tions transmitted the parent account credentials droid solutions use tracking SDKs, 1–16 unique via HTTP under an SSLStrip attack, potentially trackers. Our traffic analysis confirms violations granting access to the parental interface for a long of COPPA—over 30% of Android solutions uti- time. In addition, we identified that the BlueSnap. lize doubleclick.net without passing the proper com online payment solution used by Kidoz was COPPA compliant parameter from child device. equally vulnerable, exposing the parent’s credit We also found that one of the network devices’ card information. In Qustodio, we could extract companion app, Circle, includes a third-party the child Facebook credentials provided by the analytical SDK from Kochava, and shares the parent during the configuration of the monitoring following: Device ID (enables tracking across component. Following our disclosure, only Fam- apps), device data (enables device fingerprinting ilyTime enabled HSTS on their server. In terms for persistent tracking). To comply with COPPA, of defense against online password guessing, we Kochava provides an opt-out option, which is not found that two network devices and 17 Android used by Circle. solutions leave their online login interfaces open Restricted SDKs from past work. We also study to password brute-force attacks. Also, two net- the SDKs identified in past studies [3], [2] that work devices, seven Android solutions, and three are restricted by their developers (e.g., fully pro- Windows applications enforced a weak password hibited, or use with particular parameters) for use policy (i.e., shorter than four characters). in children’s apps (as stated in their policies as of June 2020). Through analysing traffic generated Insecure PII Transmission by the child device, we confirm that 11 Android We found that the KoalaSafe and Blocksi solutions use prohibited SDKs. network devices append the child device’s MAC PII exposure to third-parties. We found that all address, firmware version number, and serial but one Android solution share personal and number into outgoing DNS requests, allowing unique device information with third-party do- on-path attackers to persistently track the child’s mains. Prominent examples include the follow- web activities [8]. HomeHalo also appends the ing. FamilyTime shares PII with 11 third-party child device’s MAC address to HTTP requests companies, including, the child name, email and to its backend server. Several Android solutions phone number, and parent device’s Android Ad- also send cleartext PII, including: FindMyKids vertising ID (AAID) with Facebook; the parent (the child’s surrounding sounds and photo); Kid- phone number is shared with FastSpring.com, Control (the parent’s name and email, geoloca- and the parent email is sent to 11 third-parties. tion, and SOS requests); and MMGuardian (the ScreenTime shares PII with four third-party com- parent’s email and phone number, and child’s panies, including the child Android ID with Face- geolocation). book. COPPA Safe Harbor providers. We check the Third-party SDKs and Trackers behavior of (3/28) (Kidoz, FamilyTime, Find- Some legislations (e.g., US COPPA and EU MyKids) Android solutions certified by the US GDPR) regulate the use of third-party trackers FTC’s COPPA Safe Harbor program (ftc.gov/ in the services targeting children (e.g., under 13 safe-harbor-program). Our traffic analysis col- years of age). We thus evaluate potential use of lected from the child device reveals that Find- third-party tracking SDKs in the parental control MyKids uses three trackers and leaks AAID to

8 IEEE Security & Privacy at least two trackers graph.facebook.com and messages, phone history, child location—even adjust.com. FindMyKids sets two flags when enabling possibilities of physical world attacks. calling Facebook to enable application tracking Data leakage from backends. Failure to protect the and advertiser tracking. FamilyTime sends the parental control backend databases exposes sensi- child’s name, email address and phone number tive child/parent data at a large scale, exacerbated (hashed in SHA256) to Facebook. Kidoz uses due to the collection and storage of a lot user data eight trackers and leaks the AAID to the third- by many solutions. Firebase misconfigurations party domain googleapis.com through the referer exposed data that belongs to 500K+ children and header. parents from three apps. Such leakage may lead to potential exploitation of children both online Potential Practical Attacks and offline. Device compromise. Device compromise presents Unprotected PII on the network. Sending plaintext serious security and privacy risks, especially if a PII over the network is in direct violation of vulnerability can be exploited remotely. We found certain regulations, such as the US COPPA, which multiple vulnerabilities in the Blocksi network mandates reasonable security procedures for pro- device that can compromise the device itself. tecting children’s information [12]. We found sev- These include an exploitable command injection eral parental control tools transmit plaintext PII vulnerability and a vulnerability in protecting over the network, enabling any network attacker the device’s serial number, which is used in instant access to such sensitive data. For example, authentication. A remote attacker can use these FindMyKids leaks surrounding voice, and the vulnerabilities to take control over the Blocksi child’s picture, and MMGuardian leaks the child’s device by simply knowing the parent’s email geolocation. This could put a child in physi- address. In particular, using the serial number and cal danger since the attacker can learn intimate email, an attacker can exploit the command injec- details from the child’s voice records and her tion vulnerability and spawn a reverse TCP shell surrounding, and also identify the child from her on the device. At this stage, the attacker gains photo, or by using geolocation data. KidControl full control of the device, and can read/modify allows the child to send SOS messages when she unencrypted network traffic, disrupt the router’s is in a dangerous situation. However, an attacker operation (cf. DHCP starvation [9]), or use it in can drop the SOS message at will as it is sent via a botnet (cf. Mirai [10]). HTTP. Moreover, KoalaSafe and Blocksi network Account takeover. Parental accounts can be com- devices append the child’s device MAC address promised in multiple ways. First, none of the to outgoing DNS requests, enabling persistent parental control tools’ web interface except Nor- tracking. ton enforced HSTS, and most were found vulner- able to SSLStrip attacks. Therefore, an on-path Recommendations for Solution attacker can possibly gain access to the parent Providers account using SSLStrip, unless parents carefully Addressing vulnerabilities. Because of the sen- check the HTTPS status. Second, login pages sitivity of the information manipulated by the that allow unlimited number of password trials parental control tools, companies should con- could allow password guessing (especially for duct regular security audits; our security and weak passwords). Note that most parental con- privacy framework can serve as a starting point. trol tools’ password policies are apparently weak Moreover, they should have a process to address (cf. NIST [11]); some products accept passwords vulnerabilities such as responsible disclosure and as short as one character. Third, products with bug bounty programs. Currently, none except broken authentication allow access to parental Kaspersky and Bitdefender participate in such accounts without login credentials. For example, programs. SecureTeen provides an API endpoint to access Enforcing best practices. Parental control com- the parental account, by knowing only the parent panies should rely on publicly available guide- email address. If logged-in, the attacker has ac- lines and best practices, including proper API cess to a large amount of PII, social media/SMS endpoint authentication and web security stan-

Nov/Dec 2021 9 dards (e.g., OWASP recommendations). We also regulations. For parents, they should favor restric- strongly encourage companies to adopt a strong tion apps over monitoring apps, as monitoring password policy in their products, because the use apps generally collect more data and access more of default, weak and stolen credentials has been sensitive resources in a continuous manner, which exploited in many known data breaches. In the then become available to more third-parties, and case of network devices, manufacturers should perhaps even to attackers if the solution is not employ a secure firmware update architecture (see properly secured. Parents may also consider using e.g., IETF [13]). Adopting known best practices only restrictions enabled by operating systems is critical due to the especially vulnerable user (available now in both desktop and mobile sys- base of these products. tems) to avoid exposure to third-party solution Monitoring account activities. Parental control providers. A possibly better approach would be tools should report suspicious activities on the to use non-technical measures such as educating parent’s account such as password changes and children about safe and effective use of technol- accesses from unrecognized devices. These ac- ogy. tivities could indicate account compromise. Limiting data collection. Parental control tools Acknowledgment should limit the collection, storage, and transmis- This work was partly supported by a grant sion of the children’s data to what is strictly nec- from the Office of the Privacy Commissioner of essary. For instance, the solution should not store Canada (OPC) Contributions Program. PII not required for the solution’s functionality. The parental control tools should also allow the REFERENCES parent to selectively opt-out of the data collection in certain features. 1. C. Anderson, M. Crete-Nishihata, C. Dehghanpoor, R. Securing communication. Transmission of PII Deibert, S. McKune, D. Ottenheimer, J. Scott-Railton, should happen exclusively over secure commu- “Are the Kids Alright? Digital Risks to Minors from South nication channels. The solution should utilize Korea’s Smart Sheriff Application,” 2015. MITM mitigation techniques such as host white- 2. A.´ Feal, P. Calciati, N. Vallina-Rodriguez, C. Troncoso, A. listing, certificate pinning, and HSTS. Gorla, “Angel or devil? a privacy study of mobile parental Limiting third-parties and SDKs. Parental control control apps,” Proceedings on Privacy Enhancing Tech- tools should avoid, or at least limit) the use of nologies 2020, no. 2 (2020): 314-335. trackers and tracking SDKs in apps intended for 3. I. Reyes, P. Wijesekera, J. Reardon, A. Elazari Bar children. They should use SDKs that are suitable On, A. Razaghpanah, N. Vallina-Rodriguez, S. Egel- for children (e.g., Google has a list of third party man, ““Won’t somebody think of the children?” examining libraries that have been self-certified as compliant COPPA compliance at scale,” Proceedings on Privacy with children legislation). For the SDKs that Enhancing Technologies 2018, no. 3 (2018): 63-83. allow special parameter for children’s apps, those 4. B. Reaves, J. Bowers, N. Scaife, A. Bates, A. Bhartiya, parameters must be used appropriately. P. Traynor, K.R. Butler, “Mo(bile) money, mo(bile) prob- lems: Analysis of branchless banking applications,” ACM Conclusion Transactions on Privacy and Security (TOPS) 20, no. 3 Our security and privacy evaluation identified (2017): 1-31. several systematic problems in the design and 5. X. de Carne´ de Carnavalet, M. Mannan, “Killed by proxy: deployment of most analyzed parental control Analyzing client-end TLS interception software,” In Net- solutions across different platforms. Even though work and Distributed System Security Symposium. 2016. many parents may use these products as their 6. S. Shasha, M. Mahmoud, M. Mannan, A. Youssef, “Play- children’s digital guardians, several solutions in ing with danger: A taxonomy and evaluation of threats fact can be abused to provide a new avenue to smart toys,” IEEE Internet of Things Journal 6, no. 2 to undermine children’s online and real-world (2019): 2986-3002. safety. Our findings call for greater scrutiny of 7. A. Suzan, M. Elgharabawy, Q. Duchaussoy, M. Mannan, these solutions, subjecting them to more rigorous A. Youssef, “Betrayed by the Guardian: Security and and systematic evaluation, and more stringent Privacy Risks of Parental Control Solutions,” In Annual

10 IEEE Security & Privacy Computer Security Applications Conference, pp. 69-83. Quentin Duchaussoy is a research assistant at the 2020. Madiba security research lab, Concordia Institute for 8. M. Cunche, “I know your MAC Address: Targeted tracking Information Systems Engineering, Concordia Univer- sity, Montreal, Quebec, H3G 1M8, Canada. He re- of individual using Wi-Fi,” Journal of Computer Virology ceived his Master’s degree in Information Systems and Hacking Techniques 10, no. 4 (2014): 219-227. Security from Concordia University in 2020. His re- 9. N. Tripathi, and N. Hubballi, “Exploiting dhcp server-side search interests include security and privacy issues ip address conflict detection: A dhcp starvation attack,” in parental control systems. Contact him at duchaus- In 2015 IEEE International Conference on Advanced [email protected]. Networks and Telecommuncations Systems (ANTS), pp. 1-3. IEEE, 2015. Mohammad Mannan is an associate professor at the Concordia Institute for Information Systems En- 10. M. Antonakakis, T. April, M. Bailey, M. Bernhard, E. gineering, Concordia University, Montreal, Quebec, Bursztein, J. Cochran, Z. Durumeric et al, “Understand- H3G 1M8, Canada. He received a Ph.D. in computer ing the mirai botnet,” In 26th USENIX security symposium science in the area of Internet authentication and (USENIX Security 17), pp. 1093-1110. 2017. usable security from Carleton University. His research 11. P. A. Grassi, J. L. Fenton, E. M. Newton, R. A. Perlner, interests lie in the area of Internet and systems secu- A. R. Regenscheid, W. E. Burr, J. P. Richer et al, “Digital rity, with a focus on solving high-impact security and Identity Guidelines: Authentication and Lifecycle Man- privacy problems of today’s Internet. Contact him at agement [includes updates as of 03-02-2020],” (2020). [email protected]. 12. US Federal Trade Commission, “Children’s online Amr Youssef is a professor at the Concordia In- privacy protection rule: A six-step compliance plan for stitute for Information Systems Engineering, Con- your business,” https://www.ftc.gov/tips-advice/business- cordia University, Montreal, Quebec, H3G 1M8, center/guidance/childrens-online-privacy-protection- Canada. He received a Ph.D. in computer engi- rule-six-step-compliance. 2017. neering in the area of cryptography from Queen’s 13. B. Moran, H. Tschofenig, D. Brown, M. University, Ontario, Canada. His research inter- Meriac, “A Firmware Update Architecture for ests include cryptography, network security, cyber- physical systems security, and privacy. Contact him Internet of Things. Internet-Draft draft-ietf-suit- at [email protected]. architecture-08. Internet Engineering Task Force,” https://datatracker.ietf.org/doc/html/draft-ietf-suit- architecture-08. Work in Progress. 2019.

Suzan Ali is a research assistant at the Madiba security research lab, Concordia Institute for Infor- mation Systems Engineering, Concordia University, Montreal, Quebec, H3G 1M8, Canada. She received her Master’s degree in Information Systems Security from Concordia University in 2020. Her research in- terests include security and privacy issues in public WiFi hotspots and parental control systems. Contact her at suzanne [email protected].

Mounir Elgharabawy is a research assistant at the Madiba security research lab, Concordia In- stitute for Information Systems Engineering, Con- cordia University, Montreal, Quebec, H3G 1M8, Canada. He is currently pursuing his Master’s de- gree in Information Systems Security at Concor- dia University. His research interests include se- curity and privacy issues in parental control sys- tems, and IoT and Android firmware. Contact him at [email protected].

Nov/Dec 2021 11