If you’ve worked in security, or worked with security professionals, chances are you’ve heard about MS08-067. If the discussion was between security and another department, chances are it was a heated discussion. Just how bad is MS08-067? Are the security professionals exaggerating?
MS08-067, a Microsoft patch released on October 23, 2008, fixed the last really reliable remote code execution bug in Windows operating systems. All Windows NT-based operating systems prior to Windows 7 and Windows 2008R2 were susceptible to this vulnerability out of the box. It was an out-of-band release.
Remote code execution and why it’s bad
I’ve gotten into conversations where I said the words “remote code execution” and it was clear the other person didn’t understand the phrase. Look at it this way. A reliable remote code execution bug like the one MS08-067 has is like being able to run a tool like psexec without authentication. Worse yet, in some cases I can send the system the code to run. So even though most MS08-067 demos run calc.exe or some other harmless program, the point is that an attacker can run whatever code they want. And it won’t be calc.exe.
Many organizations don’t allow psexec because they don’t want authenticated users running code on systems they aren’t logged into. MS08-067 allows unauthenticated users to do that. That’s why it’s a big deal. And when someone tries to run the exploit and does it wrong, they can bluescreen the system. That’s also a big deal. Outages are bad.
Metasploit, one of the tools of choice for penetration testers, says MS08-067 is great. You don’t want things that tools like that call great bouncing around your network. Metasploit says it’s great because penetration testers like being able to run code on systems they aren’t logged into. So do illegitimate hackers.
Reliable exploits for MS08-067 have existed for a long time. But on April 8, 2017, a group called The Shadow Brokers released a set of weapons-grade exploits stolen from the NSA. One of the Shadow Brokers exploits targeted MS08-067. Weapons grade exploits tend to be more reliable. That means more code execution and fewer bluescreens.
What patch was MS08-067 replaced by?
MS08-067 was replaced by MS12-054, so MS08-067 doesn’t show up in SCCM anymore. MS08-067 doesn’t show up in patch management tools like SCCM anymore, so asking for MS12-054 pays off.
Pulling the Qualys or Tenable patch report for the affected system and noting the absence of MS08-067 will tip you off to that.
Is Windows NT4 vulnerable to MS08-067?
Microsoft never publicly released MS08-067 for Windows NT 4, because it went end of life December 31, 2004. Paid support was available, so if you still had paid support in 2008, you got the update, but couldn’t share it with anyone. By 2008 I had a limited number of Windows 2000 systems and no NT4 systems, so I didn’t have to worry about paid support.
But Windows NT 4 has the bug. I’ve never seen it demonstrated on NT 3.51, 3.5, or 3.1 but we have to assume those operating systems also had it.
How rare is a missing MS08-067 patch?
Nobody knows for certain. I’m under the impression that people think it’s rare. I don’t think it is. It’s becoming less common because the operating systems affected by it are end of life now, but old systems don’t automatically disappear just because Microsoft declares them EOL. Security professionals joke about the possibility of there being Windows NT 3.1 boxes floating around out there somewhere. But we’re actually half serious.
There’s always a reason why a system never got MS08-067. Usually it happens in companies that didn’t have an established patching cadence in 2008, and when they did start deploying patches on a regular basis, they deployed the new ones, but didn’t go back and pick up the old ones. Over time it falls away due to attrition. Older servers tend to be slower and less reliable than new ones, so the major systems get upgraded. But there are always a few holdouts, usually servers running an application that never got certified for the newer operating system.
One organization I once worked for had a couple of Windows NT 4.0 boxes around much longer than they wanted, mostly because they ran a business-critical application. The problem was the vendor had gone out of business, and nobody knew where the installation media was, so they couldn’t even try it on a newer system themselves.
These things happen. The bigger the organization, the more frequently they happen.
What to do when you can’t deploy MS08-067
If you didn’t save the MS08-067 patch for Windows 2000 or 2003 and can’t get it now, or if you have NT4 systems that never publicly received the patch, you don’t have a lot of options. But you have some. The most common, and cheapest option is just to shut the systems down and power them back up on an as-needed basis, then power them back down again. When these applications aren’t something you need every day, this is a viable option.
If you can’t keep the systems shut down most of the time, limit access to them. Chances are only a few people need to use them. Limit access to just those people’s workstations, and whatever other servers they need to function. If at all possible, run them as standalone servers, not in a domain, so they don’t need access to Active Directory. If you can put them on an out-of-band network, that would be even better.
How to motivate people to deploy MS08-067
Misunderstandings about MS08-067 tend to be due to people talking past each other. Talking in person often helps. One time I got a scathing e-mail message from someone saying in his day, he kept systems for 35 years, so keeping unpatched Windows 2003 around until at least 2038 is completely reasonable and prudent. Later that week, I spotted a former coworker at the company picnic. I walked up to him, shook his hand, and he introduced me to the guy sitting next to him: the guy who blasted me over e-mail.
It turned out he was a much more reasonable guy in person. And when I talked to him about my concerns, it was much easier when I could see his facial expressions. If he looked confused, I knew I needed to explain something a different way. It turned out to be a productive conversation, and we eventually got his machine upgraded.
Sometimes it’s just a language issue. People in my echo chamber all assume everyone knows what MS08-067 is. But you’ll get a lot further with infrastructure people if you ask for MS12-054. And not all security people recognize MS08-067. But they may be familiar with Conficker, or the Shadow Brokers dump. When you associate MS08-067 with one or both of those, you can typically come to an understanding more quickly. One time I was talking with another security professional and Conficker turned out to be the magic word. He had more clout than me, and once he understood he had a Conficker issue, he got that issue taken care of in a matter of hours.
MS08-067 and me
I deployed MS08-067 when I was a system administrator. I don’t recall having any great trouble with it. It was an out-of-band release, outside of the normal Microsoft Patch Tuesday schedule.
My practice was to deploy all applicable updates every month after a week or so of lab testing. When I got the OK from the lab, I put in a change control, spent a week deploying patches and rebooting systems, and another day or so making sure everything took. I had a clean network, with no missing patches, by the time the next Patch Tuesday rolled around.
An out-of-band patch disrupted that cycle. But if it was worth interrupting Microsoft’s normal release schedule, it was worth deploying. Setting a due date was way above my pay grade, but October 23 would have been about halfway through my patch cycle. The question would have been whether we delayed October patching altogether to give ourselves time to test MS08-067, or if I did two cycles. It’s been more than 10 years so I don’t remember what we did.
I do remember having to provide evidence, specifically, that I’d deployed MS08-067, and I also remember having to scan my network for indicators of compromise regarding Conficker at some point. It was a fair bit of disruption, but at that point I’d been pushing patches for a living nearly seven years. CVE-2008-4250 was just another one of the 800,000 vulnerabilities I patched in my career.