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.

CVE-2020-17023

Some times, a bug has a story to tell, and CVE-2020-17023 is one of those bugs. With a score of 7.8, it’s not the most critical vulnerability of all time, but it could be of specific interest to the HaD audience, as it was in Visual Studio Code. This open source editor is widely considered to be quite good, and is gaining a following. Microsoft has a habit of being less than forthcoming with their security bulletins, but perhaps the open source nature of this project will be helpful. Running to their GitHub and searching for the CVE leads to this issue.

Let’s break down what we have here. First, [Justin Steven] is explaining details about a previous flaw, CVE-2020-16881. That flaw was a result of using a .exec() function, which has all the same problems as a system() call. It acts like it’s executing something on the command line, so all sorts of command injection trickery is possible. The worst part is that hovering over a malicious package is enough to trigger the exploit. Microsoft fixed this earlier problem, and all was well, right? Well, no. Their fix was to add a filter to catch invalid package names, rather than remove the unsafe system call. As you can guess, there is a loophole — not all failures are treated equally. The filter function can fall through, and return True, even when the name is invalid. MS eventually implemented the right fix, using a safer exec function, and even credited [Justin] with a CVE of his own.

What Harm is an Open Redirect?

There’s a class of website vulnerability that seems very innocuous at first glance — open redirects, and similar problems like subdomain hijacking. What harm could these possibly cause? Both of these can lead to subtle vulnerabilities in web applications, and today we have a good example of how an open redirect can be used as part of an account takeover attack.

First, what exactly is an open redirect? It’s a page on someone’s website that will automatically redirect the visitor to a different page. Redirection is only half the definition, though. An open redirect takes the redirect target as one of its parameters, and can send the user anywhere that parameter points. Not every example is straightforward. Requesting a URL like http://local.dev?source=message&script_name=ggg might redirect you to http://local.devggg/welcome/index. If instead of “ggg”, we inject “mybaddomain.com”, we can suddenly redirect a user to a domain we control. This is the exact pattern that William Bowling, AKA [vakzz], discovered in GitHub Enterprise.

The attack goes like this, then. Send someone a GitHub Gist link, but add a “script_name” parameter, that points to a domain that you own. They click on the link, go through GitHub’s authentication process, but get redirected to your domain. Since their session information is in the URL, configure your server to log that information, and then redirect them to the proper next URL in GitHub’s authentication flow. It happens quickly enough that no-one knows the difference. However, take the logged information, and you can recreate the session and act as that user.

You may notice that we’re a little short on stories this week. I’m sure our collective hair will be on fire next week to make up for it. If you see something you think we should cover, drop it in the tips line, or tag me directly on Twitter.