This Week in Security

291 Articles

This Week In Security: SAD DNS, Incident Documentation Done Well, And TCL Responds

November 20, 2020 by 6 Comments

One of the big stories from the past few days is the return of DNS cache poisoning. The new attack has been dubbed SADDNS, and the full PDF whitepaper is now available. When you lookup a website’s IP address in a poisoned cache, you get the wrong IP address.

This can send you somewhere malicious, or worse. The paper points out that DNS has suffered a sort of feature creep, picking up more and more responsibilities. The most notable use of DNS that comes to mind is LetsEncrypt using DNS as the mechanism to prove domain ownership, and issue HTTPS certificates.

DNS Cache poisoning is a relatively old attack, dating from 1993. The first iteration of the attack was simple. An attacker that controlled an authoritative DNS server could include extra DNS results, and those extra results would be cached as if they came from an authoritative server. In 1997 it was realized that the known source port combined with a non-random transaction ID made DNS packet spoofing rather trivial. An attacker simply needs to spoof a DNS response with the appropriate txID, at the appropriate time to trick a requester into thinking it’s valid. Without the extra protections of TCP connections, this was an easy task. The response was to randomize the txID in each connection.

I have to take a moment to talk about one of my favorite gotchas in statistics. The Birthday paradox. The chances that two randomly selected people share a birthday is 1 in 365. How many people have to be in a room together to get a 50% chance of two of them sharing a birthday? If you said 182, then you walked into the paradox. The answer is 23. Why? Because we’re not looking for a specific birthday, we’re just looking for a collision between dates. Each non-matching birthday that walks into the room provides another opportunity for the next one to match.

This is the essence of the DNS birthday attack. An attacker would send a large number of DNS requests, and then immediately send a large number of spoofed responses, guessing random txIDs. Because only one collision is needed to get a poisoned cache, the chances of success go up rapidly. The mitigation was to also randomize the DNS source port, so that spoof attempts had to have both the correct source port and txID in the same attempt. Continue reading “This Week In Security: SAD DNS, Incident Documentation Done Well, And TCL Responds” →

This Week In Security: Platypus, Git.bat, TCL TVs, And Lessons From Online Gaming

November 13, 2020 by 9 Comments

Git’s Large File System is a reasonable solution to a bit of a niche problem. How do you handle large binary files that need to go into a git repository? It might be pictures or video that is part of a project’s documentation, or even a demonstration dataset. Git-lfs’s solution is to replace the binary files with a text-based pointer to where the real file is hosted. That’s not important to understanding this vulnerability, though. The problem is that git-lfs will call the main git binary as part of its operation, and when it does so, the full path is not used. On a Unix system, that’s not a problem. The $PATH variable is used to determine where to look for binaries. When git is run, /usr/bin/git is automagically run. On a Windows system, however, executing a binary name without a path will first look in the current directory, and if a matching executable file is not found, only then will the standard locations be checked.

You may already see the problem. If a repository contains a git.exe, git.bat, or another git.* file that Windows thinks is executable, git-lfs will execute that file instead of the intended git binary. This means simply checking out a malicious repository gets you immediate code execution. A standard install of git for Windows, prior to 2.29.2.2, contains the vulnerable plugin by default, so go check that you’re updated!

Then remember that there’s one more wrinkle to this vulnerability. How closely do you check the contents of a git download before you run the next git command? Even with a patched git-lfs version, if you clone a malicious repository, then run any other git command, you still run the local git.* file. The real solution is pushing the local directory higher up the path chain. Continue reading “This Week In Security: Platypus, Git.bat, TCL TVs, And Lessons From Online Gaming” →

This Week In Security: In The Wild, Through Your NAT, And Brave

November 6, 2020 by 12 Comments

Most of the stories from this week are vulnerabilities dropped before fixes are available, many of them actively being exploited. Strap yourselves in!

Windows Kernel Crypto

The first is CVE-2020-17087, an issue in the Windows Kernel Cryptography Driver. The vulnerable system calls are accessible from unprivileged user-space, and potentially even from inside sandboxed environments. The resulting buffer overflow can result in arbitrary code executing in the kernel context, meaning this is a quick jump to root-level control over a victim system.

What exactly is the code flaw here that’s being attacked? It’s in a bit of buffer allocation logic, inside a binary-to-hex conversion routine. The function accepts an unsigned short length argument. That value is used to calculate the output buffer size, by multiplying it by six, and using an unsigned short to hold that value. See the problem? A sufficiently large value will roll over, and the output buffer size will be too small. It’s a value overflow that leads to a buffer overflow.

Because the problem is being actively exploited, the report has been made public just seven days after discovery. The flaw is still unpatched in Windows 10, as of the time of writing. It also seems to be present as far back as Windows 7, which will likely not receive a fix, being out of support. [Editor’s snarky note: Thanks, closed-source software.] Continue reading “This Week In Security: In The Wild, Through Your NAT, And Brave” →

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

October 30, 2020 by 42 Comments

[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: BleedingTooth, Bad Neighbors, And Unpickable Locks

October 16, 2020 by 17 Comments

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” →

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

October 9, 2020 by 6 Comments

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” →

This Week In Security: PunkBuster, NAT, NAS And MP3s

October 2, 2020 by 4 Comments

Ah, the ever-present PDF, and our love-hate relationship with the format. We’ve lost count of how many vulnerabilities have been fixed in PDF software, but it’s been a bunch over the years. This week, we’re reminded that Adobe isn’t the only player in PDF-land, as Foxit released a round of updates, and there were a couple serious problems fixed. Among the vulnerabilities, a handful could lead to RCE, so if you use or support Foxit users, be sure to go get them updated.

PunkBuster

Remember PunkBuster? It’s one of the original anti-cheat solutions, from way back in 2000. The now-classic Return to Castle Wolfenstein was the first game to support PunkBuster to prevent cheating. It’s not the latest or greatest, but PunkBuster is still running on a bunch of game servers even today. [Daniel Prizmant] and [Mauricio Sandt] decided to do a deep dive project on PunkBuster, and happened to find an arbitrary file-write vulnerability, that could easily compromise a PB enabled server.

One of the functions of PunkBuster is a remote screenshot capture. If a server admin thinks a player is behaving strangely, a screenshot request is sent. I assume this targets so-called wallhack cheats — making textures transparent, so the player can see through walls. The problem is that the server logic that handles the incoming image has a loophole. If the filename ends in .png as expected, some traversal attack checks are done, and the png file is saved to the server. However, if the incoming file isn’t a png, no transversal detection is done, and the file is naively written to disk. This weakness, combined with the stateless nature of screenshot requests, means that any connected client can write any file to any location on the server at any time. To their credit, even Balance, the creators of PunkBuster, quickly acknowledged the issue, and have released an update to fix it.

Continue reading “This Week In Security: PunkBuster, NAT, NAS And MP3s” →