A week on from MS00-078. The exploitation pattern has played out as I expected — mass scanning within 24 hours, public exploit code within 48 hours, widespread compromise of unpatched IIS servers within the week. The cleanup is ongoing.
Time to step back and think about what this category tells us. Not the specific bug — that is patched, the immediate response is over — but the pattern and what it implies for the next year.
What was actually exploited
From my Snort sensor and from conversations with operators of various IIS shops:
Approximately 30% of internet-facing IIS servers were probed within 12 hours. Mass-scanner activity was visible from a broad range of sources, including many compromised hosts being used as scanning platforms. The probes were short — single HTTP requests — and easy to log but hard to block in real time.
Approximately 15% of probed servers were vulnerable. This is the fraction that had not been patched in the preceding hours. The vulnerable population was dominated by smaller installations — corporate intranets, small-business websites, university departmental servers — that did not have central patch management.
Compromised servers were repurposed within hours. I have seen reports of servers exploited at lunchtime being used for DDoS daemons by evening. The pipeline from compromise to operational use of the compromised resource is short.
Defacement was rare. Despite some attention-seeking groups using the bug for high-profile defacements, most compromised servers had their content untouched. The attackers preferred quiet repurposing — installing trojans, joining botnets, using the bandwidth — over public messaging.
This is consistent with what I predicted last year and with the threat model that has emerged from the broader honeypot work. Compromised hosts are economic resources; they get used commercially.
The structural lessons, again
A few things this incident has reinforced.
Patch timelines remain too long. The patch was available the day the vulnerability was disclosed. The exploitation began within 24 hours. The window during which patching could have prevented compromise was, for most operators, hours. Most patching processes are not that fast.
This is the same observation I have made several times. Microsoft's patching cadence has improved; operators' patching cadences have not kept pace. The gap is the vulnerability window.
Default configurations remain the problem. The vulnerability was exploitable specifically because IIS, by default, allowed CGI execution from broad path patterns and ran with a user (IUSR) that had broad filesystem access. A more restrictive default — CGI only from specific paths, IUSR with explicitly minimal permissions — would have made the bug substantially harder to exploit even before the patch.
Microsoft is moving in this direction. The URLScan tool ships with much more restrictive defaults than the base IIS. The next major IIS release will, on the available signals, default to more restrictive settings. This is the right direction; it is too slow.
Monoculture costs continue to compound. Roughly 25-30% of internet-facing web servers run IIS. The IIS install base is the proximate substrate for every IIS-targeted attack. The economic incentive to attack IIS is high because the vulnerable population is enormous. The defensive costs scale with the install base.
This is the same monoculture problem I described after the consultancy incident. The structural answer is platform diversity. The structural reality is that diversity is hard to deploy.
Scanning automation has matured. The scan-and-exploit pipeline observed this week is fully automated. Vulnerability scanner detects vulnerable host; exploit module compromises it; backdoor is installed; host is added to the controller's pool. No human intervention beyond initial setup. This is the kind of automation that makes the worm-propagation arithmetic look conservative for the next major bug.
What I expect over the next year
A few predictions, in roughly increasing order of confidence.
Several more IIS advisories will follow this pattern. The IIS codebase has not had its structural issues addressed. Each new advisory will produce a similar wave of compromise. By the end of 2001, IIS-targeted advisories will have produced cumulative damage that exceeds what any pre-2000 single advisory has done.
An IIS-targeted worm appears within 9 months. Combination of trivial-to-exploit vulnerabilities, large vulnerable population, mature scanning infrastructure, and growing botnet substrate. I would not be surprised to see an automatically-propagating IIS worm by mid-2001.
Microsoft accelerates the security response. The visible pressure on Microsoft from these incidents is producing measurable changes — the Trustworthy Computing initiative discussions are early signs. Real change in the development process will take years; the early signals of intent are visible now.
The defensive advantage will shift to organisations with mature patching processes. Smaller organisations, without central patch management, will be increasingly disadvantaged. The gap between large-org and small-org IIS exposure will widen, with the small organisations bearing disproportionate cost.
Network segmentation becomes a regulatory expectation. Some specific incident — possibly involving a regulated industry — will produce explicit regulatory requirements for network segmentation in critical-infrastructure deployments. The conversation is starting; the requirements will follow.
What individual operators can do
For anyone running IIS:
Apply MS00-078 if you have not already. The exploitation is now widespread; an unpatched server is being compromised in hours.
Apply URLScan or equivalent. The default IIS configuration is too generous. URLScan provides a structured way to restrict it.
Restrict IUSR's filesystem access. Explicit deny on system directories; explicit allow only on the document root.
Monitor for exploitation attempts. Snort rules for the Unicode encoding patterns are widely available; deploying them is a few-minute exercise.
Plan for the next IIS advisory. The next one is coming. The patching workflow you wish you had today is the patching workflow you should be building this quarter.
For anyone running other web platforms:
The lesson is the same, even if the specific bug does not affect you. Apache has had its share of advisories; the structural problems of complex parsing, generous defaults, and slow patching apply more broadly than just IIS.
A closing note
MS00-078 is not, in the medium term, going to be remembered as a particularly consequential vulnerability. It is one of dozens of similar advisories. Within five years it will be a footnote.
What it represents is more interesting. The pattern — major vulnerability published, patched, mass-exploited, industrially compromised, eventually contained — is now the standard rhythm of internet operations. We are no longer in the era where an advisory was an unusual event. We are in the era where there is approximately one of these per quarter, with more in flight.
The operational discipline this implies is one I have been writing about all year — fast patching, structural defences, forensic readiness, diversity. None of these is new. All of them are now operationally non-optional. The cost of running infrastructure has, structurally, increased.
More as the year develops.