Pages

Tuesday, February 22, 2005

More stuff on rootkits from Microsoft

I received an email this morning from Microsoft regarding a new page that's been posted regarding the Strider stuff I mentioned earlier. It's interesting that they've linked the papers and Bruce Schneier's comments...but they still haven't released the tools themselves. When I saw the section called "Tools", I jumped at it. Ugh. Anyway, the issue of detecting stuff hidden in NTFS alternate data streams is fairly simple to address...using the same technique listed, use LADS to scan a live system, and then run a diff between that and the output once you've booted to your CD.

It's interesting that one of the publications refers to a "Strider Ghostbuster Enterprise Scanner", but there's nothing available beyond a paper to download. If you're wondering what I would expect...well, how about instructions from MS regarding how to build bootable Windows CD (it would have to be from them, so as not to violate any licenses), and a downloadable archive of the actual tools themselves that you can add to the ISO image to create your own tool? I'm sure many of us could figure this out on our own, but the folks at Microsoft have already done so...surely they can provide the implementation that they're addressing in their papers.

Microsoft also discussed rootkits at RSA. I have to say that some of the verbage smacks of FUD...particularly where the term "newer" is used. Who are they trying to kid? "Newer" in what sense? While I agree that rootkit authors are smart, I don't necessarily think that it takes a great deal of effort to go undetected on a Windows system. After all, BO was fairly unobtrusive until someone connected to it and started opening and closing the CD tray and generally being annoying. Also, consider that spyware goes pretty much unnoticed until there's enough of it on a system to adversely affect the user experience.

My point is that this is not really that new at all. The chicken little "sky is falling" thing doesn't work that well anymore, guys.

2 comments:

  1. Anonymous10:44 AM

    Thanx for dropping by recently !

    New method proposed for RootKit prevention !


    I would like to suggest some possible ideas on how it may be feasable to prevent RootKits from EVER gaining access in the first place. I acknowledge i'm Not an expert in the field, just someone who takes an interest in the subject !

    Maybe you've heard the expression ( not being able to see the woods for the trees ) because some people are heavily involved in so many aspects of a particular project and concentrating Very deeply in a linear fashion. I DO fully appreciate and understand their dedication and hard work and take nothing away from them at All !

    Now Don't anybody take this the wrong way at All, but as i'm not engrossed in the minutie, i see things from a different perspective. More akin to standing back and seeing an overview of the problem. So on that basis i submit the following -

    A - The root section of a hard drive could be made to switch over to read only after the initial OS installation on a fresh HD. Some method could be devised whereby the user and/or admin would be required to authenticate an allow a Root write. Requests for Root write could be saved to a reserved scalable area RSCA of the HD and put in a queue. So these would not be lost, and also in case of a HD crash etc they could be retrieved on reboot. At the end of the session/day and/or intermittently at some selected interval, a prompt box could appear asking to valididate and give permission with an encrypted password for the Root write. How this would work in practice i leave to others, as i said i'm No expert, but i feel that something along these lines Could be achieved in some way. The RSCA would be similar in principle to the swap file area we already have.

    B - The RSCA and the Root area Should also be encrypted strongly. This would mean that NO unauthorised access could take place, EVER, and therefore the Root could NOT be tampered with in Any way. Any and All copys of the Root area would also be protected in a similar way. No more RootKits, problem solved ! - http://www.wilderssecurity.com/showthread.php?t=69658

    ReplyDelete
  2. Anonymous10:50 AM

    Thanx for dropping by recently ! Sorry to post twice, but i didn't want to post anonymously. I hope you can fix it.


    New method proposed for RootKit prevention !


    I would like to suggest some possible ideas on how it may be feasable to prevent RootKits from EVER gaining access in the first place. I acknowledge i'm Not an expert in the field, just someone who takes an interest in the subject !

    Maybe you've heard the expression ( not being able to see the woods for the trees ) because some people are heavily involved in so many aspects of a particular project and concentrating Very deeply in a linear fashion. I DO fully appreciate and understand their dedication and hard work and take nothing away from them at All !

    Now Don't anybody take this the wrong way at All, but as i'm not engrossed in the minutie, i see things from a different perspective. More akin to standing back and seeing an overview of the problem. So on that basis i submit the following -

    A - The root section of a hard drive could be made to switch over to read only after the initial OS installation on a fresh HD. Some method could be devised whereby the user and/or admin would be required to authenticate an allow a Root write. Requests for Root write could be saved to a reserved scalable area RSCA of the HD and put in a queue. So these would not be lost, and also in case of a HD crash etc they could be retrieved on reboot. At the end of the session/day and/or intermittently at some selected interval, a prompt box could appear asking to valididate and give permission with an encrypted password for the Root write. How this would work in practice i leave to others, as i said i'm No expert, but i feel that something along these lines Could be achieved in some way. The RSCA would be similar in principle to the swap file area we already have.

    B - The RSCA and the Root area Should also be encrypted strongly. This would mean that NO unauthorised access could take place, EVER, and therefore the Root could NOT be tampered with in Any way. Any and All copys of the Root area would also be protected in a similar way. No more RootKits, problem solved ! - http://www.wilderssecurity.com/showthread.php?t=69658

    ReplyDelete