Thread by @MalwareJake

These newly disclosed vulnerabilities in tcpip.sys are a really interesting case study in why holistic security matters. Sure you should still be patching, but are your firewalls and IPs systems properly configured? If so, these probably aren't an issue 1/
msrc-blog.microsoft.com/2021/02/09/mul…

First, let's look at CVE-2021-24094/24086. Both involve the reassembly of packet fragments. If you've never dealt with issues IP fragmentation and never had to worry about the MTU across the network path, that's okay. It was a common thing many moons ago, but not much today. 2/

In IPv4 there are lots of variations in how fragments are handled, particularly for out of order delivery. It turns out the original standards weren't very clear on this so everybody did what was easy. But as IPv6 was being built, the standard is clear: no overlaps. 3/

We still have an issue of how long to keep IPv6 packet fragments in memory for. It turns out this is where the vuln is at. By sending too many packet fragments out of order, they must be stored somewhere pending reassembly at a later time (when all fragments are present). 4/

But here's the rub: you likely aren't seeing legitimate IPv6 fragmentation at all (if so I'd be REALLY interested to know what the use case is).

Take a look at your packet capture and determine "do I have these?" If not, block them from transiting network devices. 5/

Now on to CVE-2021-24074. This deals with IPv4 source routing, another blast from the past. Back in the day, some engineer thought "we need a way to specify in the IP header that we are smarter than the routers handling our packets." I'm sure it solved some problem at the time 6/

But in all of recent history (like 2+ decades), source routing has only been used maliciously. Microsoft even notes that Windows blocks source routing, but still processes the packets to send an ICMP error message back to the sender because that's part of the standard (🤷). 7/

So again, these packets have no place in your network in the first place. Block (and log) them at every network device that supports it and this was never an issue.

Now that we've touched on those two specific examples, let's back up a bit. 8/

I know zero-trust (ZTNA) is a huge buzzword right now (and shame on you, vendors who are abusing it). But I'm here to tell you that it works.

The core principle of ZTNA is "deny all, permit by exception." Most orgs take this to mean "learn IPs and ports in use and act there." 9/

But I suggest you take it a step further. Learn about core protocols (like IP) and block the heck out of anything you don't expect to see.

The TCP/IP stack is amazingly complex. I'm here to tell you that it is a HUGE attack surface in IoT devices. Want to be ready? Act now. 10/

Why don't more people do this? Because deep diving into protocol implementations isn't sexy. But it IS how the community keeps finding vulnerabilities like CRACK (WPA2), these, and countless others.

How many times have I said "back to basics?" I feel like a broken record. /FIN