Let’s talk TCP. Specifically, how do the different TCP connections stay distinct, and how is a third party kept from interrupting a connection? One of the mechanisms that help accomplish this feat is the TCP sequence number. Each of the two endpoints of a TCP connection tracks an incrementing 32-bit number, corresponding to the bytes sent in the connection. It’s handy, because each side can use that value to track what parts of the data stream they have received. On missing packets, a message can be sent requesting bytes 7-15 to be resent, for instance.

Each side of the connection sets their own Initial Sequence Number (ISN), and it’s important that this number is unique, as collisions can cause stream confusion. That statement should make your security spidey sense tingle. If a collision can cause problems when it happens by chance, what can a hacker do with it intentionally? Potentially quite a bit. Knowing the current sequence number, as well as a couple other pieces of information, a third party can close a TCP stream or even inject data. The attack has been around for years, originally known as the Mitnick Attack. It was originally possible because TCP implementations used a simple counter to set the ISN. Once the security ramifications of this approach were understood, the major implementations moved to a random number generation for their ISNs.

Now to this week’s story: researchers at Forescout took the time to check 11 TCP/IP stacks for vulnerability to the old Mitnick Attack (PDF Whitepaper). Of the eleven embedded stacks texted, nine have serious weaknesses in their ISN generation. Most of the vulnerable implementations use a system time value as their ISN, while several use a predictable pseudorandom algorithm that can be easily reversed.

CVEs have been assigned, and vendors notified of “NUMBER:JACK”, Forescout’s name for the research. Most of the vulnerable software already has patches available. The problem with embedded systems is that they often never get security updates. The vulnerable network stacks are in devices like IP cameras, printers, and other “invisible” software. Time will tell if this attack shows up as part of a future IoT botnet.

Microsoft Patch Tuesday

Last week, Microsoft released their monthly round-up of patches, and there are a few interesting bugs. CVE-2021-24074 is a potential RCE resulting from improper handling of source routing packets. “Source routing” is one of the mostly forgotten IP options, though it does see some use in niche applications. Packets using this option are generally blocked by routers and security devices, making it essentially impossible to send such packets over the public internet. Windows clients also block these packets, but generate an ICMP response when such a packet is blocked. Reading between the lines, it seems that the vulnerability is triggered by the process of building the ICMP response. (Not a new problem) The patch is available, as is a simple workaround: simply dropping the incoming packets without a response.

Two other CVEs are potentially notable, though there is even less information available about them. CVE-2021-24078 is a wormable vulnerability in the Windows DNS server. Thankfully a server is only vulnerable if the DNS component has been turned on. The other is CVE-2021-26701, a rather vague “.NET Core Remote Code Execution Vulnerability”. It has a severity rating of critical, and Microsoft has indicated that the details are known in the wild.

Clubhouse Security Growing Pains

You may have heard that Clubhouse is the new social media flash-in-the-pan. Or, maybe it will stick around, who knows. If you haven’t looked into it, Clubhouse is something of an audio chatroom, where a celebrity or teacher can have a conversation with an audience. It’s still prelaunch, and there are already eight million downloads. As you might imagine, this success has put Clubhouse on the radar of security researchers, like the folks at Zerforschung. It seems that Clubhouse is built on the Agora.io platform, and the attack here is to talk directly to Agora.io rather than go through the Clubhouse app. The results? The attacker can leave the room, but maintain the connection to the backend. The username disappears, but still receives audio, and can even speak into the room. This breaks the ability to put a room into single-speaker mode and makes ejecting a user impossible.

Telegram Self-Destruct Messages

The problem? They aren’t actually destructed. [Dhiraj Mishra] did his research on the MacOS version of Telegram, and discovered that audio and video files sent in a self-destruct message is still available on the computer hard drive, even after the message timer has expired. For extra pwnage, this version of Telegram also stores the passcode in plaintext in some cases. Both issues have been fixed, so make sure you update if you use Telegram on MacOS.

More NPM Dependency Confusion

Last week we covered [Alex Birsan]’s dependency confusion attack, where a package can be uploaded to NPM that uses the name of a private package. If a company has their build system misconfigured, the public package can be pulled into the final build instead of the intended private package. Since [Alex] publicly announced the attack, nearly 300 such packages have been uploaded to NPM taking advantage of this technique. Note these are the packages that have been discovered, there are almost certainly more packages that are out there, but are yet to be discovered. [Alex] pointed out that some of these are likely other researchers aiming for bug bounties, but there might even be some legitimately malicious packages in the mix.

We’ll do our best to keep you up to date on these stories, and the rest that pop up each week, so stay tuned!