Canopy, a parental control app that offers a range of features meant to protect children online via content inspection, is vulnerable to a variety of cross-site scripting (XSS) attacks, states researchers.
The possible cyber-attacks include disabling monitoring, location-tracking of children & malicious redirects of parent-console users.
Third-Party Attack
The attacks could range from a child disabling the monitoring to a much more serious third-party attack delivering malware to parental users.
Canopy offers sexting prevention, on-device photo protection (through image filtering), screen-time monitoring, child communication alerts for parents, smart content filtering for weeding out inappropriate websites, plus, for the parents, remote device management & the ability to control the use of the applications & websites their child uses.
To perform this, Canopy uses an artificial intelligence engine & VPN filtering – plus a respectable number of device permissions.
Accessibility Support
“The installation process involved authorising a wide set of permissions including accessibility support, the ability to draw on top of other apps, installing a root CA & configuring a VPN,” explained Craig Young, Security Researcher at Tripwire, in a report published on Tues.
“The app can also optionally function as a device administrator to prevent app removal…This privileged access can introduce considerable risk to the security of protected devices & the privacy of the children using those devices.”
XSS Issues
It seems that he is right to be concerned. Looking into the Android version of the app, Young discovered several opportunities to mount XSS attacks, which occur when malicious scripts are injected into otherwise trusted websites.
That injection is usually conducted by entering malicious code into a web response or comment field & hitting enter, where the payload is then sent to a web server.
Malicious Scripts
Usually, these responses are validated on the server side so that malicious scripts are blocked. In Canopy’s case, those checks are lacking in several areas, Young discovered.
Once a website is compromised, any visitor to the site is potentially a victim, either from a ‘drive-by’ attack in a stored XSS scenario, or if the target can be convinced to click a link in a reflected XSS attack.
Concerns
The first set of problems has to do with the potential for a child to get around the app’s protective umbrella.
When Young evaluated a core Canopy function – blocking bad websites – he found that he was greeted with a block-notification page when he attempted to load a prohibited site on a test Android device. That notification page has a button allowing the child to ask his or her parents for access to the requested page anyway.
JavaScript Pop-Up
Young clicked the button from the test device but appended this response with a simple XSS payload script that creates a JavaScript pop-up on the parental website, to see what would happen. When he went to the portal, sure enough, the pop-up was there.
Then, he found the XSS worked in the opposite direction.
“I decided to deny the request & again insert an XSS payload as explanation text,” Young explained.
“The protected phone received a notification about the response. When I opened this notification, I was again greeted with my XSS pop-up.”
User Inputs
The vulnerability arises because the system is failing to sanitise user inputs. The input field allows 50 characters, Young found, “which was plenty to source an external script.”
He warned there are multiple ways to exploit the issue.
“An attacker (e.g. the monitored child) can embed an attack payload within an exception request. Although there may be a wide range of ways a clever kid could abuse this vulnerability, the most obvious would be to automatically approve a request,” he stated.
“My first test was a payload to automatically click to approve the incoming request. This worked well, & I quickly got another payload working to automatically pause monitoring protection.”
Attacks by Outsiders
While a variety of child-to-parent attacks could be conducted by a child with some scripting knowledge, Young also found that more series offensives could be mounted.
For example, he observed that the URL value in the block-notification page query (indicating which website is being denied) is displayed on the main page of the parent dashboard.
“I did a quick test of adding a script tag into the URL & loaded up the parent console,” he outlined, adding that he needed to play around with the syntax of the script for a while before getting a payload to “fire.”
Exception Request
Now, “the JavaScript executed when loading the main page of the parent dashboard. We now can submit an exception request which takes control of the Canopy app when the parent simply logs in to check on the monitored devices.”
Further, because the attack involves a crafted URL being blocked, it becomes possible for attacks to come from completely external third-party sources, he noted.
An attacker need only to establish a likely-to-be-blocked website with that appended script in its URL & convince a child to try to access it. When the notification about the access request goes to the parent console, the parents monitoring the account would become victims of the malicious script.
“Unfortunately, the attack surface for this vulnerability is quite a bit more substantial than what was discussed earlier with request explanation text,” Young explained.
Canopy API Design
That is not all. It seems that the Canopy API design could allow an external attacker to directly inject an XSS payload into a parent-account webpage by guessing the parent account ID. That would open the door to redirections to ads, exploits, malware & more.
Most sinisterly, an attacker could hijack access to the parental control app itself, installed on the child’s phone, & pull GPS coordinates from protected devices on the account.
“The account IDs are short numeric values, so it seems quite plausible that an attacker could seed the attack payload on every single parent account by simply issuing a block exception request for each ID value in sequence,” Young explained.
No Patches for Worst Canopy Attacks
Young outlined that he reached out to Canopy by phone & by email repeatedly, with little response, thus prompting his disclosure of the issues. The only fix the developer issued was to prevent the child-led attacks, he added.
“Canopy failed to do anything to protect against the parent to child XSS or XSS through the URL of a blocked page request before becoming unresponsive,” he explained.
“Canopy needs to implement sanitisation of all user-input fields but has failed to do so. After repeated attempts to work with the vendor, we are publishing this report with some details removed, so that others can learn from it & act accordingly.”
