Robert Hensing's Blog

Software Security . . . and stuff.

Blogs

The Blame Game - I won't go there.

  • Comments 14
  • Likes

So I'm getting some 'interesting' and frankly un-expected comments on my most recent 'Anatomy of . . . ' posts where I delve into examples of a hack involving certain vulnerabilities (one of which wasn't even in one of our products I'd like to point out).

Look folks - my intent with these blogs is not to place blame and I'm not in the habbit of blaming the victims for getting attacked as the finger can be pointed at either us or them (or the miscreants who commit the crimes but why does no one ever think to blame them when all is said and done?!  Think about it . . . ).

If I had to - I'd gladly take the blame on behalf of Microsoft over customers any day and will gladly fall on my sword.

My intent with this blog is to simply share knowledge about how these attacks are occuring, why they are occurring, what IR teams at other organizations can look for and what security practitioners should be doing to secure systems in a way that most people can understand interspersed with some humorous wit and colorful commentary strewn throughout.

My team always tries to get to root cause on each and every case because by demystifying how these intrusions occur for our customers they will start to see how easy it really is to take basic precautions to avoid getting hacked.  Patterns will emerge.  Sure we have hundreds of pages of guidance on this that or the other but it's really quite easy to avoid getting hacked when you come right down to it at the end of the day:
Patches, passwords and ports. 
If you can manage all 3 of those in your environment - you'll do just fine and need not worry (excessively <G>).

I want to make clear here that I do not enjoy, nor am I proud of the fact that our customers are getting hacked in droves.
I don't take pleasure in pointing out how easy it would have been for them, in retrospect to avoid getting hacked (with these last two blogs either a firewall or a software update would have prevented it).
That said I certainly do enjoy the hell out of my job - I like hunting the hunters and being a good guy and I think my team is quite good at it and I'm proud to be a part of it offering the service we do for our customers.

With every hacking case we get - we close the case with a series of recommendations on how to not get hacked going forward and I will continue to share those assesments with you in each post - but please don't take offense at the casual way in which I mention the recommendations (which are all documented best practices anyways).  I realize some organizations struggle with passwords.  I realize some organizations struggle with patches.  If these are sensitive topics for you - don't take it out on me.  I'm just the messenger (perhaps more like the ghost of Christmas future showing you via my blog what's in store for you if you don't resolve your struggles and soon <G>).

And finally - I'd like to point out that Windows 2000 was not an operating system designed with security in mind and it is the reason a disproportionate number of hacking cases are for Windows 2000 when used by people who are not security focused.  Think about some of the features of Windows 2000 out of the box.

  • It allows for blank admin passwords and they can and will be used against you.
  • It does not require strong passwords during setup should you decide to put one on the admin account ('password' or 'dog' are okay to use during setup)
  • no firewall
  • everything's on by default

You may have seen mention in my post a hint about WS2003 and how you'll likely see me post very little about hax0r3d WS2003 boxes. 
There is a non-marketting reason for that (I am NOT a marketting guy and I'm not working a bit harder so Initech can ship a few more widgets).
WS2003 is a 'secure by default' operating system (our first, followed by XP SP2) that received code review and myriad defense in depth improvements.

Think about some of the features of WS2003 out of the box (some of these you may not have known about - but have been quietly helping to protect customers for years now):

  • It allows you to set a blank admin password during setup BUT . . . if you do, you get yelled at and then you can't authenticate to the server using that account on the network (i.e. can't access the admin shares using 'administrator' with no password.  It's a security policy and it's enforced by default - so actually a blank admin password is better than having a password like 'password' for example.
  • Speaking of lame passwords like 'password' - should you decide to create a password for the administrator account during setup - you will be forced to choose a better one (i.e. one that meets password complexity requirements).  You won't be able to use 'password' for example.
  • Built-in firewall - not on by default - but change is coming.
  • Everything's off by default - you won't find IIS or a myriad of other services listening by default that increase your exposure needlessly
  • Stack smashing protection - the majority of the OS has been compiled with the /GS compiler flag to place stack cookies around important functions

In the coming months we'll be releasing WS2003 SP1 with even more creamy goodness to help protect our customers (more on that I'm sure will come later).

In the mean time - you need to realize - we are fighting back for our customers without placing blame (oh and occasionally we help law enforcement arrest the bad guys - so maybe just a little well-deserved blame aimed at those who break the law <G>).

Comments
  • ok, don't place blame lets just poke fun and the poor bastards..

    anyway I'll keep my mouth shut so I can read more of your posts!

  • Hey, Robert! Don't fret, man. You're doing a good job.

  • do not let morons get to you....

  • yeah, ignore the trolls, i love your blog; its great reading material for lunch breaks :)

  • The content of your blog is awesome. It is valuable, and I look forward to reading more.

    Try to avoid language that could be misinterpreted as blaming your customers. For example:

    "This box is at severe risk as it is missing multiple security updates that are remotely exploitable including SQL updates! Worse still - the box only has a 6 character minimum password policy and the passwords never expire!"

  • Okay now we're getting somewhere . . .
    I didn't think I was assigning blame to anyone with that statement - I was simply stating a fact - this box really IS at severe risk for the reasons I listed.

    I'm open for suggestions on how I can re-word the above information to make this . . . less blame-ful?

  • In my opinion Microsoft should release an SP5 for Win2000. Not everyone will upgrate to WS03 soon so packaging the 50 or so patches released since SP4 in a Service Pack will help administrators. Most importantly it will pass them the message of updating. If you issue only a cumulative update or anything less than a new service pack many administrators will not even notice its presence. Remember, even the blaster patch is not found in SP4, so a freshly installed Win2000 even with SP4 is at serious risk.
    Also, it will be a good idea if you can give as some mor insides on Windows. I mean like what processes are running on a Windows box by default and what they are used for and what there normal properties are, like are they all signed. Or like what services should be running by default, their names, other registry info and on what port they are listening as well as generally how we can detect signs of hackers. I know that the info about services can be found in MS guidance but by sharing it also here will make it more simple and accessible I guess to us who like your blog. Finally, what are all the methods for autostarting an app at boot and how can we untangle and understand this registry mess.

  • We are releasing a post SP4 update for Windows 2000 that was announced recently. It won't be called SP5 but it will basically be a cumulative update rollup so you can install one update instead of 50 or so.

    Anyone can fine out what processes run by default by installing a fresh copy of Windows 2000 and dumping all the running services using a variety of tools like SC.EXE, SCLIST.EXE etc. It's really easy to do and not something I think would be useful in my blog.

    As for signing - all OS binaries are signed . . . well they have their hashes computed and stored in a .CAT file undert catroot and this .CAT file is itself signed with an authenticode signature. You can use tools like sigverif.exe to verify the integrity of the OS hashes - this will probably be something I blog soon as soon as *I* figure it out. :)

    Finally - for auto start points, perhaps the best tool to use there is 'Autoruns' from Sysinternals - my favorite 3rd party tool authors

  • Just dropping by, Already told you I am a big fan of your blog. So do not fret the people that just do not get what the blog is for. Speak your mind, write what you want, thats what make the blog interesting.

    BTW just noticed you turned back on the comments.

  • Funny, my "3 P's" for the past few years have been Passwords, Patches and Policy (as in either "Group Policy" or, more lately, organizational policies). I've never been a huge fan of firewalls that focus on Layer 4 (block 53/udp, allow 80/tcp) given all the "tunnelling" and spoofing that goes on, but I presume you really mean "knowing & controlling what apps are running behind which Layer 4 listeners". I can get down with that - hell, I'll even start talking about the "4 P's" - though for no good reason, I'm more attracted to the elegance of 3 than to 4...

  • Robert, this is unbelievable:

    "And finally - I'd like to point out that Windows 2000 was not an operating system designed with security in mind"

    I'm sorry, were you on the Win2k team? Are you aware that it was promoted as the most secure OS ever made by Microsoft?

    There is a relativism and odd sense of historical blindness here. Win2k was a pretty secure OS. It did rely a bit more on admin knowledge, but so does Linux/Unix. It did have vulnerabilities, and so does win2k3, despite the much-publicized code reviews. In fact, for all the work done for 2k3... it still has only half the number of reported vulnerabilities as win2k. Not even an order of magnitude.

    Far from suggesting that Win2k3 is junk, I'm suggesting that Win2k wasn't that bad. Win2k3 will wither under the test of time and when the next OS is released, will you claim that Win2k3 was not "designed with security in mind"??

    I hope you have the presence of mind to admit that security has gotten better, without maligning the foundation upon which it was built. Your new "designed for security" OS will not look as great with hindsight either, though it was a good step in the right direction (as was Win2k).


  • Well please allow me to retort! No I am not on the 'Win2k team' (I presume you refer to the development team) but I WAS around at Microsoft 7 years ago when we were developing and planning the release of Win2k and I can assure you *security* of the operating system was not as high a priority as say, backwards compatibility or the ability to make migrations from NT domains to Active Directory seamless. Fast forward 4-5 years . . . Win2k3 is being prepared for release and while a bit later in the cycle, security was definitley made the priority for Win2k3's release. This is why it underwent numerous 'attack surface reductions' that make it provably more secure than Win2k. You seem to imply that security is directly related to security vulnerability and bug-counts. This is fundamentally flawed. Sure you can say Win2k3 has less / fewer vulns and is therefor more secure - but I urge you to review the vulns closely and have a look at the ones that exist for both Win2k and Win2k3 and then look at the vulnerabilities severity on both platforms. You will find that many that are 'critical' on Win2k may only be important or moderate on Win2k3. Why is that? The answer lies in our other approach to security with Win2k3 - attack surface reduction. We focused on both finding and fixing security bugs during our secure code reviews, but we also focused on making the OS 'secure by default'. We did this through ASR's.

    For example:
    1. Numerous services are disabled by default.
    2. The services that are NOT disabled by default run with lower priviliges (RPCSS now runs as localservice for example - a LUA account)
    3. The services that are network facing have been compiled with /GS which helped mitigate vulnerabilities like the one used by blaster on this platform
    4. Win2k3 SP1 is going to get 'Software DEP' which is a form of data execution prevention that can prevent specific types of stack-based exploits on all CPU's.
    5. Services like IIS that are complicated and highly configurable, when enabled (since they are disabled by default) get enabled in a secure way (i.e. only HTTP listener enabled by default) and you have to loosen the security of the product, not tighten it.
    6. The Win2k3 setup requires either a blank admin password (which can't be used for any network based authN thus can't be used to hack your machine) OR it tries to get you to enter a strong password (and prompts you if you don't).


    I can assure sir, as a security practitioner and an incident response person, Win2k is provably WAY more secure than Win2k and it will be in 2 years from now after its been out roughly as long as the current versions of Win2k and it's not just marketting - it's fact. We fixed security bugs we hardened the OS and we implimented tons of ASR's. While it IS possible (obviously) to make Windows 2000 secure - your job is FAR easier on Win2k3 and you have more safety nets to rely on in the case something bad happens. This is why I only see a few hacking cases / years involving Win2k3 and they are ALL becuase of password guessing or weak SA passwords on MSDE or SQL installed on top of Win2k3.

    When Longhorn ships am I going to comment on Win2k3's lack of security? Of course not - Win2k3 was the first OS where we put security as a #1 priority and longhorn isn't going to change that - Longhorn is going to be a natural extension of this philosophy and will of course be at least as secure if not more secure than Win2k3 due to architecture changes and even more security bug fixes and safety nets (like attack surface reductions). Expect to see us focusing on another huge problem in Lonhorn - that of people logging in and using admin accounts all the time - expect there to be a focus on running as a limitted user account.