Another DDOS amplification technique has just recently been disclosed, NXNSAttack (technical paper here) that could be used against DNS servers.

We’ve covered amplification attacks before. The short explanation is that some UDP services, like DNS, can be abused to get more mileage out of a DDoS attack. The attacking machined send messages like this: “Hello Google DNS, This is the Hackaday server. Can you send me a really big DNS response packet?” If the DNS response is bigger than the request, then the overall attack is bigger as a result. The measure of effectiveness is the amplification factor. For every byte of DDoS sent by attacking machines, how much many bytes are actually sent to the victim machine? Mirai, for example, had an amplification factor of something around 2.6.

NXNSAttack has a theoretical per-byte amplification factor of 163. That’s not a missed decimal point, this has the potential to be quite the nasty problem.

To pull off the attack, the baddie needs to control a domain name server that’s authoritative for its own domain: evil.com. An innocent DNS is then asked for the IP address of a random machine in the evil subdomain. Since the innocent DNS has never seen the name before, it asks the root .com server for the IP address of the evil DNS server (ns1.evil.com) and then goes to ask there.

Normally, the evil DNS server would respond with the IP address of the machine in its own domain, and the story would end happily. But here the evil nameserver responds with the addresses of many “nameservers” in the target domain, all invented simply to generate traffic, and tells the innocent DNS server to go ask them:nslgb7vX.sucker.com and nseHOiF.sucker.com and so on. Here comes the amplification.

Many DNS resolvers will look up the IP address for each and every “nameserver” it receives, and will do this in parallel, because under normal circumstances these IPs are cached and they can sweep up an entire domain’s set of DNS servers in one go and never have to ask again. So the innocent DNS asks the root .comserver for the IP address of target’s authoritative server ns1.sucker.com, where it’s going to lookup all of the IP addresses for the fake nameservers.

But since all of the “nameserver” names are random and fake, the innocent resolver is fooled into hammering ns1.sucker.com with requests for the IP address of each of these fake nameservers. In practice, this multiplies the DNS requests a few-fold: 10-20x is plausible. The full attack uses two stages of redirections from the evil nameserver to essentially square the number of requests, which is how they end up with a factor of 163 in practice. In this scenario, the traffic from just a few malicious machines can quickly overwhelm the victim’s infrastructure.

NXNSAttack was privately disclosed to a handful of DNS vendors, so limited mitigations are already available. Running a recursive DNS server was already a difficult task, but now there is one more pitfall to watch out for.

15-year-old Vulnerability Finally Exploited

Some vulnerabilities are obviously exploitable, and get fixed ASAP. In other cases, code may technically be vulnerable, but in a way that seems extremely unlikely to ever be practically exploitable. It’s easy to dismiss these as non-issues, and never do the work to fix them. Qmail contained a trio of flaws for at least 15 years, and serves as a good example of why it’s important to fix “unexploitable” issues.

2005 was the era when x86-64 machines were first becoming available to the greater public. It shouldn’t be a great surprise that certain programming assumptions are safe to make on the 32-bit platform, and are no longer valid on a 64-bit machine. Qmail was written with the assumption that an array would never be allocated for more than 4 GB of memory — safe in the 32-bit era. CVE-2005-1513,1514, and 1515 were reported and dismissed, as reaching the 4 GB limit was considered impossible in any default, or sane, deployment.

Fast-forward to May 19th, 2020 and a way to exploit these bugs was finally found. The vulnerable code is also used in the qmail-local service, which by default isn’t limited to a set memory amount. A specially crafted 4 GB email can trigger the integer overflow, and lead to remote code execution. There are plenty of juicy details in the full write-up, so check it out for more.

300,000 Vulnerable QNAP Devices

QNAP makes a NAS device that’s rather popular with prosumer users. Going above and beyond simple file storage, these QNAP devices have features like an integrated photo organizer, music player, etc. [Henry Huang] discovered three separate vulnerabilities that can be chained together to gain a root webshell. So first off, any QNAP users out there, go check for updates!

Now that you’re up to date, let’s dig through the exploit chain. First, a remote API designed for interacting with sample albums is accessible without authentication. An attacker can create a sample album, and is returned an Album ID. The information from the created sample ID is used to craft a request, which can read any file on the file system, though unsanitized file names containing “../../” style characters. This is used to read an application login token.

That token is then used to log in, and another pair of vulnerabilities allows an attacker to drop PHP code in the web folder. All that’s left is to access the new page in a browser, and the injected PHP code is run. As the webserver on these devices runs as root, injecting a remote shell means full device compromise.

The Million Dollar Challenge?

The Houseparty social network, run by Epic Games put out a challenge on Twitter: Provide proof of a smear campaign about security problems on Houseparty, and they would pay a cool million dollar bounty.

We are investigating indications that the recent hacking rumors were spread by a paid commercial smear campaign to harm Houseparty. We are offering a $1,000,000 bounty for the first individual to provide proof of such a campaign to bounty@houseparty.com.

— Houseparty (@houseparty) March 31, 2020

That offer caught the attention of [Zach Edwards], who started looking into the security of Houseparty. What he found wasn’t pretty. The login page doesn’t use any Content Security Policy (CSP). Among other things, this means it could be embedded in a phishing page.

[Zach] kept digging, and discovered a number of “thehousepartyapp.com” subdomains that have been hijacked. It appears that there is a sophisticated credit card fraud campaign using these subdomains. The entire story is complex, and there is probably even more to the story. Unfortunately, it appears that Epic Games isn’t taking the discovery as seriously as one might hope.

Odds-n-Ends

The TrendMicro Rootkit Remover tool installs the TrendMicro Common Module driver. [Bill Demirkapi], who is only 18, decided to take a look, and discovered a few oddities. Among them, this driver detects when it’s being inspected by a tool like Driver Verifier, and cheats in order to pass the WHQL test. To put a cherry on top of his research, [Bill] describes a rootkit that hijacks the TrendMicro driver.

Supercomputers are apparently the next frontier in malware. Multiple machines have been compromised by what appears to be a rather sophisticated campaign — one that intentionally tries very hard to clean evidence of its activities. It’s unclear what exactly the purpose of the attacks are, but it’s a reasonable conclusion that as expensive as modern supercomputers are, the data they produce could potentially also be of great value, in certain situations. For a special bonus, the article calls out this situation’s resemblance to “The Cuckoo’s Egg” and everyone’s favorite, Clifford Stoll. (I suggest a Klein Bottle drinking game for every mention of Stoll, who seems to be everyone’s favorite guy.)

And finally, while a port scan isn’t a crime, it’s a bit rude for a website to run one from within your browser, just because you visited. Ebay is the given example, and interestingly, the scan is only run when the site is accessed from a Windows machine. It’s suggested that the port scanning is intended to discover visitors that are compromised.