This Week In Security: Discord, Chromium, And WordPress Forced Updates

[Masato Kinugawa] found a series of bugs that, when strung together, allowed remote code execution in the Discord desktop app. Discord’s desktop application is an Electron powered app, meaning it’s a web page rendered on a bundled light-weight browser. Building your desktop apps on JavaScript certainly makes life easier for developers, but it also means that you inherit all the problems from running a browser and JS. There’s a joke in there about finally achieving full-stack JavaScript.

The big security problem with Electron is that a simple Cross Site Scripting (XSS) bug is suddenly running in the context of the desktop, instead of the browser. Yes, there is a sandboxing option, but that has to be manually enabled.

And that brings us to the first bug. Neither the sandbox nor the contextIsolation options were set, and so both defaulted to false. What does this setting allow an attacker to do? Because the front-end and back-end JavaScript runs in the same context, it’s possible for an XSS attack to override JS functions. If those functions are then called by the back-end, they have full access to Node.js functions, including exec(), at which point the escape is complete.

Now that we know how to escape Electron’s web browser, what can we use for an XSS attack? The answer is automatic iframe embeds. For an example, just take a look at the exploit demo below. On the back-end, all I have to do is paste in the YouTube link, and the WordPress editor does its magic, automatically embedding the video in an iframe. Discord does the same thing for a handful of different services, one being Sketchfab.

This brings us to vulnerability #2. Sketchfab embeds have an XSS vulnerability. A specially crafted sketchfab file can run some JS whenever a user interacts with the embedded player, which can be shoehorned into discord. We’re almost there, but there is still a problem remaining. This code is running in the context of an iframe, not the primary thread, so we still can’t override functions for a full escape. To actually get a full RCE, we need to trigger a navigation to a malicious URL in the primary pageview, and not just the iframe. There’s already code to prevent an iframe from redirecting the top page, so this RCE is a bust, right?

Enter bug #3. If the top page and the iframe are on different domains, the code preventing navigation never fires. In this case, JavaScript running in an iframe can redirect the top page to a malicious site, which can then override core JS functions, leading to a full escape to RCE.

It’s a very clever chaining of vulnerabilities, from the Discord app, to an XSS in Sketchfab, to a bug within Electron itself. While this particular example required interacting with the embedded iframe, it’s quite possible that another vulnerable service has an XSS bug that doesn’t require interaction. In any case, if you use Discord on the desktop, make sure the app is up to date. And then, enjoy the demo of the attack, embedded below.

Continue reading “This Week In Security: Discord, Chromium, And WordPress Forced Updates”

This Week In Security: Too Little Too Late, And Other Stories

Microsoft has just announced a way to disable JScript in Internet Explorer. This would have been very useful a few years ago, to proactively prevent problems found in the now-ancient JScript engine, which ran their own slightly different version of standard JavaScript. Even though IE is no longer under active development, it still receives security updates. JScript, on the other hand, is basically done. If you’re one of the 1.06% that still use IE, then go flip the switch to protect yourself from additional JScript vulnerabilities.

Zerologon and Samba?

Samba is an open source re-implemenation of Microsoft’s SMB protocol. There’s a clever term that describes the reality of this situation: “Bug for bug compatibility”. Remember Zerologon, the flaw where a security token’s generation could be manipulated to vastly reduce the key space? Samba follows the specification, and therefore suffers from the same issue, though it seems to be unusual to actually run Samba in a vulnerable configuration.

Other implementations cannot say the same. QNAP in particular has been bitten by Zerologon when configured as a domain controller. What’s not clear is whether QNAP is running Samba on the NAS products, or if this is yet another vulnerable implementation. Either way, go update your devices. Continue reading “This Week In Security: Too Little Too Late, And Other Stories”

Do Your Part To Stop The Robot Uprising

One of the pleasures of consuming old science fiction movies and novels is that they capture the mood of the time in which they are written. Captain Kirk was a 1960s guy and Picard was a 1990s guy, after all. Cold war science fiction often dealt with invasion. In the 1960s and 70s, you were afraid of losing your job to a computer, so science fiction often had morality tales of robots running amok, reminding us what a bad idea it was to give robots too much power. As it turns out, robots might be dangerous, but not for the reasons we thought. The robots won’t turn on us by themselves. But they could be hacked. To that end, there’s a growing interest in robot cybersecurity and Alias Robotics is releasing Alurity, a toolbox for robot cybersecurity.

Currently, the toolbox is available for Linux and MacOS with some support for Windows. It targets 25 base robots including the usual suspects. There’s a white paper from when the product entered testing available if you want more technical details.

Continue reading “Do Your Part To Stop The Robot Uprising”

Google Meddling With URLs In Emails, Causing Security Concerns

Despite the popularity of social media, for communication that actually matters, e-mail reigns supreme. Crucial to the smooth operation of businesses worldwide, it’s prized for its reliability. Google is one of the world’s largest e-mail providers, both with its consumer-targeted Gmail product as well as G Suite for business customers [Jeffrey Paul] is a user of the latter, and was surprised to find that URLs in incoming emails were being modified by the service when fetched via the Internet Message Access Protocol (IMAP) used by external email readers.

This change appears to make it impossible for IMAP users to see the original email without logging into the web interface, it breaks verification of the cryptographic signatures, and it came as a surprise.

Security Matters

A test email sent to verify the edits made by Google’s servers. Top, the original email, bottom, what was received.

For a subset of users, it appears Google is modifying URLs in the body of emails to instead go through their own link-checking and redirect service. This involves actually editing the body of the email before it reaches the user. This means that even those using external clients to fetch email over IMAP are affected, with no way to access the original raw email they were sent.

The security implications are serious enough that many doubted the initial story, suspecting that the editing was only happening within the Gmail app or through the web client. However, a source claiming to work for Google confirmed that the new feature is being rolled out to G Suite customers, and can be switched off if so desired. Reaching out to Google for comment, we were directed to their help page on the topic.

The stated aim is to prevent phishing, with Google’s redirect service including a link checker to warn users who are traveling to potentially dangerous sites. For many though, this explanation doesn’t pass muster. Forcing users to head to a Google server to view the original URL they were sent is to many an egregious breach of privacy, and a security concern to boot. It allows the search giant to further extend its tendrils of click tracking into even private email conversations. For some, the implications are worse. Cryptographically signed messages, such as those using PGP or GPG, are broken by the tool; as the content of the email body is modified in the process, the message no longer checks out with respect to the original signature. Of course, this is the value of signing your messages — it becomes much easier to detect such alterations between what was sent and what was received.

Inadequate Disclosure

Understandably, many were up in arms that the company would implement such a measure with no consultation or warning ahead of time. The content of an email is sacrosanct, in many respects, and tampering with it in any form will always be condemned by the security conscious. If the feature is a choice for the user, and can be turned off at will, then it’s a useful tool for those that want it. But this discovery was a surprise to many, making it hard to believe it was adequately disclosed before roll-out. The question unfolded in the FAQ screenshot above hints at this being part of Google’s A/B test and not applied to all accounts. Features being tested on your email account should be disclosed yet they are not.

Protecting innocent users against phishing attacks is a laudable aim,  and we can imagine many business owners enabling such a feature to avoid phishing attacks. It’s another case where privacy is willingly traded for the idea of security. While the uproar is limited due to the specific nature of the implementation thus far, we would expect further desertion of Google’s email services by the tech savvy if such practices were to spread to the mainstream Gmail product. Regardless of what happens next, it’s important to remember that the email you read may not be the one you were sent, and act accordingly.

Update 30/10/2020: It has since come to light that for G Suite users with Advanced Protection enabled, it may not be possible to disable this feature at all. 

This Week In Security: BleedingTooth, Bad Neighbors, And Unpickable Locks

This week, the first details of BleedingTooth leaked onto Twitter, setting off a bit of a frenzy. The full details have yet to be released, but what we know is concerning enough. First off, BleedingTooth isn’t a single vulnerability, but is a set of at least 3 different CVEs (Shouldn’t that make it BleedingTeeth?). The worst vulnerability so far is CVE-2020-12351, which appears to be shown off in the video embedded after the break.

Continue reading “This Week In Security: BleedingTooth, Bad Neighbors, And Unpickable Locks”

Lowering The Bar For Exam Software Security

Most standardized tests have a fee: the SAT costs $50, the GRE costs $200, and the NY Bar Exam costs $250. This year, the bar exam came at a much larger cost for recent law school graduates — their privacy.

Many in-person events have had to find ways to move to the internet this year, and exams are no exception. We’d like to think that online exams shouldn’t be a big deal. It’s 2020. We have a pretty good grasp on how security and privacy should work, and it shouldn’t be too hard to implement sensible anti-cheating features.

It shouldn’t be a big deal, but for one software firm, it really is.

The NY State Board of Law Examiners (NY BOLE), along with several other state exam boards, chose to administer this year’s bar exam via ExamSoft’s Examplify. If you’ve missed out on the Examplify Saga, following the Diploma Privilege for New York account on Twitter will get you caught up pretty quickly. Essentially, according to its users, Examplify is an unmitigated disaster. Let’s start with something that should have been settled twenty years ago.

Continue reading “Lowering The Bar For Exam Software Security”

This Week In Security: Code Scanning, Information Gathering, And Seams In The Cloud

GitHub has enabled free code analysis on public repositories. This is the fruit of the purchase of Semmle, almost exactly one year ago. Anyone with write permissions to a repository can go into the settings, and enable scanning. Beyond the obvious use case of finding vulnerabilities, an exciting option is to automatically analyse pull requests and flag potential security problems automatically. I definitely look forward to seeing this tool in action.

The Code Scanning option is under the Security tab, and the process to enable it only takes a few seconds. I flipped the switch on one of my repos, and it found a handful of issues that are worth looking in to. An important note, anyone can run the tool on a forked repo and see the results. If CodeQL finds an issue, it’s essentially publicly available for anyone who cares to look for it.

Simpler Code Scanning

On the extreme other hand, [Will Butler] wrote a guide to searching for exploits using grep. A simple example, if raw shows up in code, it often signals an unsafe operation. The terms fixme or todo, often in comments, can signal a known security problem that has yet to be fixed. Another example is unsafe, which is an actual keyword in some languages, like Rust. If a Rust project is going to have vulnerabilities, they will likely be in an unsafe block. There are some other language-dependent pointers, and other good tips, so check it out.

Continue reading “This Week In Security: Code Scanning, Information Gathering, And Seams In The Cloud”