The VPN Box Is the Target

In mid-December Fortinet published an advisory for CVE-2022-42475, a heap-based buffer overflow in the SSL-VPN component of FortiOS and FortiProxy. Unauthenticated remote code execution, scored 9.8 out of 10, in the part of the device that answers the internet. CISA added it to the known exploited vulnerabilities catalog on the thirteenth of December with a federal remediation deadline of the third of January, which is three weeks, and those three weeks run straight through the holidays.

The affected version list is the part I keep going back to. The bug is present in nine separate release branches of FortiOS, from the 5.0 series through 7.2.2, which means it is not a regression somebody introduced in a recent refactor. It is a defect that was carried forward, untouched and unnoticed, through years of releases into every branch a customer could plausibly be running.

And it is not a story about one vendor, which is easy to check. On the same day CISA added the Fortinet overflow, it added an authentication bypass in Citrix Application Delivery Controller and Gateway. Two remote-access products, two vendors, entering the exploited catalog together on one December afternoon, which is roughly the tempo this device class has been running at for four years.

So here is the claim, and none of the reasons behind it are accidents. The remote-access appliance is the most reliably exploited device class on a corporate network because of properties it has to have in order to be the thing it is: reachable from anywhere, parsing hostile input before anyone has authenticated, running a vendor operating system you cannot inspect, and unpatchable without taking remote access away from everyone who has it.

Reachability is the product. A concentrator that is firewalled off from the internet is not a concentrator. It must accept a connection from an unknown address on an unknown network, because the person connecting is at an airport. Every scan of the address space finds it, every time, and it answers, because answering is what you bought.

The parser runs before anybody has proved who they are. TLS termination, the HTTP front end, the login form handling: all of it accepts and interprets attacker-controlled bytes before authentication can possibly have happened. That is where this bug lives. A heap overflow in the SSL-VPN daemon is reachable by anyone who can open a socket, which is the definition of the service.

It is an operating system you are not allowed to look at. No endpoint agent, no package manager, a deliberately restricted shell. Whatever visibility you have is whatever the vendor's own logging offers, and whatever detection you have arrives when the vendor publishes indicators. On this class of device the defender's tooling is a subset of the vendor's roadmap.

It holds a credential path to the whole workforce. Directory integration, often a local user database as well, client certificates, session state for everyone currently working from somewhere else. Nothing else on the network sits that close to identity while also being deliberately exposed, and the two facts together are what set the price of a working exploit.

And it is a routing decision on both sides at once. The box exists precisely where outside traffic becomes inside traffic, which is why it was placed there and why it is worth taking. Code execution on it is not a foothold at the edge. It is a foothold on the device whose job is deciding what the edge means.

What they recovered was not commodity malware that happened to land on a network device. Fortinet describes a Linux implant customized for FortiOS: built for this platform, aware of its file layout, and installed to survive on it. Somebody had done the work of understanding a closed appliance operating system well enough to write software that belongs on it.

The detail I have not been able to put down is that the implant carried offsets and opcodes for twenty-seven FortiGate models, spanning FortiOS 6.0.5 through 7.2.1. That is a compatibility matrix. Somebody enumerated a vendor's release history, built against it, and tested the result, which is release engineering performed by an attacker for a product they do not own. You do that when you expect the target population to be large, uniform and still there next quarter.

And then it went after the logs. Fortinet reports the implant patching the FortiOS logging processes, miglogd and syslogd, so it could decompress event files, find and delete specific strings, reconstruct the file, and kill the logging daemons outright if that was easier. Read that alongside the previous section. The one device with any visibility into what happened at the edge is the device that was taken, and its account of the evening is now written by the intruder.

Fortinet assessed the actor as advanced and the activity as highly targeted at governmental or government-related organizations, and I would not stretch that into a claim that everyone is facing this. What generalizes is not the adversary, it is the arithmetic. That much engineering effort is only rational against a target class that is uniform, long-lived, exposed by design, and structurally difficult for its owner to inspect. Those conditions are not special to government networks.

The catalog opened with this class already in it. When CISA published its first known exploited vulnerabilities list in November 2021, it already contained a FortiOS SSL VPN path traversal from 2018, a Pulse Connect Secure file read from 2019, a Citrix Application Delivery Controller code execution from 2019, and an F5 BIG-IP management interface code execution from 2020. Four edge devices, four vendors, all being exploited years after the fixes shipped.

There are fifty-nine entries, and the number is mine not theirs. I went through the catalog and counted the entries added before today whose vendor is one of fourteen whose business is edge or remote access, Fortinet and Citrix and Pulse Secure and SonicWall and the rest. Fifty-nine. The vendor list is a judgment call I made, so treat that as an indication of density rather than a measurement of anything.

The old ones never age out. The FortiOS path traversal from 2018 was on the list the day the list was created and it is still there today, which tells you the half-life of an appliance bug. Software that updates itself stops being exploitable when the population turns over. An appliance stops being exploitable when somebody schedules a reboot, and some of them never will.

That is why the deadline was three weeks. CISA does not set a remediation date of three weeks over Christmas for a bug it thinks is theoretical. It does that when it has reason to believe the thing is being used, and the gap between that deadline and the date most affected devices were actually upgraded is the subject of the next section.

Patching a server means restarting a service, and for most services that is measured in seconds and covered by a load balancer. Patching an appliance means upgrading firmware and rebooting the device. While it reboots, nobody working remotely can reach anything. So it is not really a patch. It is an outage, and outages are scheduled.

They get scheduled into a maintenance window, which at most organizations is monthly, out of hours, and already contended for. That is the entire mechanism behind the gap. A federal remediation deadline of three weeks and an actual remediation three months later are both ordinary outcomes, and neither one requires a single person to have been careless about security. The calendar did it.

There is usually one of these devices, or a high-availability pair, and the pair is the same model running the same firmware, which means upgrading it is upgrading both halves of the arrangement that was supposed to let you upgrade one half at a time. Firmware upgrades on this class of device can also require stepping through intermediate releases, and they migrate a configuration between schema versions on the way. That risk is real and it is genuinely hard to rehearse, because the thing you would rehearse on is the thing in production.

Then the ownership question, which is where most of the delay actually accumulates. The advisory arrives at a security team. The device belongs to a network team. The outage lands on every remote worker, which makes it a change the business has to agree to. Three groups, three clocks, and a change request that has to survive all of them before anything reboots. None of those people are wrong to want the conversation, and the conversation is what the deadline was competing with.

Put those together and you have the condition the industry is in. A device class guaranteed to be reachable, guaranteed to be worth attacking, and structurally the slowest thing in the estate to change. Every incentive on the operational calendar argues for waiting until the window. Nothing is on the attacker's calendar at all.

A mesh has no concentrator to take. Peers hold each other's public keys and talk directly; an overlay adds a coordination service whose job is distributing those keys and telling peers where to find each other. Nobody's session terminates on a shared box, and no shared box holds everyone's session state. There is no single pre-authentication parser standing between the internet and the entire workforce, because at that layer there is no single anything left to compromise.

The code you have to trust is small enough to read. Donenfeld's paper states that WireGuard can be implemented for Linux in under 4,000 lines, and says the point of that plainly: it makes the thing easily audited and verified. Set that against a vendor appliance carrying a TLS stack, an HTTP front end, a portal, a management interface and a decade of accumulated compatibility, all of which is also reachable.

It declines to answer at all. A design goal in the same paper is to store no state before authentication and send no response to unauthenticated packets, which leaves nothing for a scanner to find. The transport argument for that deserves more room than it gets here. What matters for this piece is narrower: a service that never replies before authenticating has no pre-authentication parser to overflow.

And the upgrade stops being an outage. A kernel module or a client on each machine updates with that machine, independently, on whatever schedule the endpoint already has. Patching becomes a rolling operation across a population instead of a scheduled interruption at a chokepoint, which removes the exact incentive that leaves appliances unpatched over a holiday.

You have exchanged a memory-safety dependency for an identity dependency, and that is the honest description of the move. The appliance's failure mode was that a C program parsed hostile bytes badly. The mesh's failure mode is that whatever decides which public keys belong in your network can be talked into adding one, and the decision is being made by a coordination service and the identity provider behind it.

Tailscale describes its own coordination server as a shared drop box for public keys, notes that a private key never leaves the node that generated it, and delegates user authentication to whatever identity provider you already run. That is a good design and an honest one. It also means your single sign-on tenant is now the perimeter: an administrator account compromised there enrolls a device rather than stealing a session, and the enrolled device is a legitimate member. There are mechanisms to take that trust back, and hardly anybody turns them on.

And some things do not move at all. Anything that must accept an inbound connection from a system you do not control still needs something at the edge terminating it: partner integrations, older hardware with no client available, contractors on machines you cannot install software on. A mesh shrinks the set of things that have to listen on the public internet, which is a genuine reduction. It does not empty the set, and what remains is the awkward, old, badly documented residue nobody wanted to touch, now with fewer neighbors to hide among.

So I would not tell anyone with a working appliance to remove it this quarter. The first move is smaller and much cheaper: work out which populations are behind the concentrator only because that is where remote access happened to land, and move those off it. Then when the box has to sit unpatched across a holiday period, because it will, the number of people whose access depends on it is as small as you were able to make it.

I want to resist the reading where the vendors come out of this looking incompetent, because I do not think that is what the record shows. Writing a TLS front end that survives a decade of the internet aimed directly at it is genuinely hard, and these products do a great deal that a mesh does not do at all: per-user policy, device posture checks, session recording, the reporting an auditor asks for by name. Giving that up is a real loss, and I would rather say so than pretend the swap is free.

What I cannot get past is the table of twenty-seven models inside the implant. Somebody sat down with a vendor's release matrix and worked through it, because the effort pays: the boxes are identical, they are on the internet by definition, and the version running today will still be running in six months. The uniformity that makes an appliance manageable is the same property that makes it worth that much preparation. The only part of it a defender really controls is how many people's day stops when the thing finally has to reboot.