Screencastify, a popular Chrome extension for capturing and sharing videos from websites, was recently found to be vulnerable to a cross-site scripting (XSS) flaw that allowed arbitrary websites to dupe people into unknowingly activating their webcams.
A miscreant taking advantage of this flaw could then download the resulting video from the victim’s Google Drive account.
Software developer Wladimir Palant, co-founder of ad amelioration biz Eyeo, published a blog post about his findings on Monday. He said he reported the XSS bug in February, and Screencastify’s developers fixed it within a day.
But Palant contends the browser extension continues to pose a risk because the code trusts multiple partner subdomains, and an XSS flaw on any one of those sites could potentially be misused to attack Screencastify users.
The Screencastify page on the Chrome Web Store says that the browser extension has more than 10 million users, which is the maximum value listed by store metrics. As Palant points out, the extension is aimed at the education market, raising some unpleasant possibilities.
“The extension grants screencastify.com enough privileges to record a video via user’s webcam and get the result,” he explains in his post. “No user interaction is required, and there are only minimal visual indicators of what’s going on. It’s even possible to cover your tracks: remove the video from Google Drive and use another message to close the extension tab opened after the recording.”
What’s concerning about this is that the extension code gives several other domains these same privileges: not just Screencastify, via the app.screencastify.com domain, but also Webflow, Teachable, Atlassian, Netlify, Marketo, ZenDesk, and Pendo, each via Screencastify subdomains.
And, Palant says, neither the Screencastify domain or the subdomains delegated to partners have meaningful Content Security Policy protection – a way to mitigate XSS risks.
Palant’s proof-of-concept exploit involved finding an XSS bug within the Screencastify code, which wasn’t a particularly difficult task because they’re quite common. The NIST database lists almost 20,000 of them from 2001 to the present. According to OWASP, “XSS is the second most prevalent issue in the OWASP Top 10, and is found in around two thirds of all applications.”
Palant found an XSS bug on an error page that gets presented when a user tries to submit a video after already submitting one for an assignment. The page contained a “View on Classroom” button that sent the user to Google Classroom using this code:
window.open(this.courseworkLink);
“It’s a query string parameter,” Palant explains in his post. “Is there some link validation in between? Nope. So, if the query string parameter is something like javascript:alert(document.domain), will clicking this button run JavaScript code in the context of the screencastify.com domain? It sure will!”
To make that happen, the attacker would still need to trick the victim into clicking on this button. But as Palant observed, the page contained no protection against framing, meaning it was susceptible to clickjacking. So his proof-of-concept attack did just that, loading the vulnerable page in an invisible frame and positioning it under the mouse cursor so any click would be passed through to the hidden button.
Thereafter, the page could message Screencastify to fetch the victim’s Google access token and ask Google for the user’s identity. It could also list Google Drive contents or start a recording session.
Palant said he reported the issue on February 14, 2022, and his message was acknowledged the same day. A day later, the XSS on the error page was fixed. The message he received also mentioned a long-term plan to implement Content Security Policy protection, but as of May 23, according to Palant, that hasn’t happened on app.screencastify.com nor www.screencastify.com, apart from the addition of framing protection.
The API, he observed, does not appear to have been restricted and will still produce a Google OAuth token that can be used to access a victim’s Google Drive, Palant said. So too is the onConnectExternal handler that lets websites start video recordings.
The Register asked Google whether it would care to comment on Palant’s observation that Google Drive access is too broadly scoped, but we’ve not heard back.
“So, the question whether to keep using Screencastify at this point boils down to whether you trust Screencastify, Pendo, Webflow, Teachable, Atlassian, Netlify, Marketo and ZenDesk with access to your webcam and your Google Drive data,” he concludes. “And whether you trust all of these parties to keep their web properties free of XSS vulnerabilities. If not, you should uninstall Screencastify ASAP.”
Screencastify did not immediately respond to a call and email messages seeking comment. ®