Why Sasser did not infect Windows Server 2003



The Sasser worm took advantage of a defect in logging code within the Local Security Authority Subsystem (LSASS.) The entry point for this functionality is through an RPC interface, which is open by default for all users to access on Windows 2000 and Windows XP. The code existed in Windows Server 2003 prior to the security update (MS04-011, http://www.microsoft.com/technet/security/Bulletin/MS04-011.mspx); however, the Sasser worm did not affect Windows Server 2003!


 


Why?


 


To me, the answer is very important. Some years ago I realized that fixing code is honorable, and nothing is better than writing great code from the get-go. But people are imperfect, and code will be imperfect, so we need to do more than simply create better code, we need extra defenses, “just in case.”


 


And this is where attack surface reduction enters the picture. The RPC interface in question is NOT accessible by anyone on the Internet in Windows Server 2003. Even if the firewall is not turned on, only local administrators can access the RPC endpoint.


 


This is a very important point, attack surface reduction is not just about turning stuff off and shutting things down; it’s also about limiting who can access what by default. In this case, the RPC endpoint is an administrative interface into DCPromo, and it made perfect sense to limit the code to local admins only in Windows Server 2003.


 


SSSOOOoooo…. to attack this code in Windows Server 2003 requires the attacker be a local admin. In others a user with administrative rights seated at the console. Let’s be honest, if you have people attacking systems this way, a bug in DCPromo is the least of your problems!


 

Comments (8)

  1. Wayne Taylor says:

    Yea!

    Can’t agree more! I get tried of people attack MS all of the time….. even programmers who should know better.

  2. Chris says:

    As I understand it, this is because the server

    binds only to localhost (127.0.0.1) and does not

    bind to the external ip address. Is there a

    way to configure this kind of binding for

    services?

    For example, when I startup Apache Tomcat on my

    Win2k box, the admin shutdown port is 8005, and

    if you look at the open ports with a tool like

    tcpview, you’ll see that 8005 is bound only to

    127.0.0.1. Other processes are bound to either

    my external ip address or 0.0.0.0 (which binds

    to all available ips). That service on 8005 is

    not available to outside of my local machine.

    Is there a way to configure existing MS services

    to run this way?

    And why didn’t MS just configure the services

    to do this from the beginning?

  3. MIchael Howard says:

    It’s really up to the app in question. For example, you can limit IP addresses in IIS. It’s in the admin tool

  4. E-Bitz - SBS MVP the Official Blog of the SBS says:
  5. Peter says:

    With good hardening (which isn’t necessarily the way e.g MS’s/NSA’s checklists do it) there’s even no need for buying new licenses for W2K3 when old and paid installations of W2K still can stand these attacks.

    There are multiple places where security can be measured;

    one is the default cd that comes from vendor, and W2K3 is better in that than the W2K although it opens possibly unthought issues when people who shouldn’t be administrators open things on it to get things work.

    Then the other is the final installation when the box is just running and where careful admin has done work to harden the box.

    That being said; my installation of W2K was not affected by Sasser – without a patch.

  6. Dave Aitel says:

    You’re just making me want to go write a new exploit for 2003 when you say these sorts of things. :>

  7. Michael Howard says:

    Hi Dave!!! 🙂

  8. Sale says:

    I think Dave succeeded because my 2003 Server keeps picking up some derivative of SASSER. Can’t find a patch or asolution as yet.