[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <58DB1B68E62B9F448DF1A276B0886DF192FD95D6@EX2010.hammerofgod.com>
Date: Mon, 5 Sep 2011 19:50:51 +0000
From: "Thor (Hammer of God)" <thor@...merofgod.com>
To: Mario Vilas <mvilas@...il.com>, "paul.szabo@...ney.edu.au"
<paul.szabo@...ney.edu.au>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: Cybsec Advisory 2011 0901 Windows Script Host
DLL Hijacking
Excellent points - one slight addition, though:
>In fact, the Windows Script Host software is mostly used to write system maintenance scripts,
>so it's obvious its scripts can't be restricted or they'd be useless.
Scripts can certainly be restricted based on the account context they are executed under. There is actually plenty one can do with "normal user" scripts, but as you've pointed out, many of the options admins require scripts for need escalated privileges. This is obviously be design, and it helps to keep admins aware of best practices when choosing to deploy solutions via scripting. There are, of course, many many other ways once can accomplish system maintenance in a more secure way such as WMI, PS (which can require signed scripts) and of course GPO and/or any other number of solutions.
I thought it important to outline that since, in my experience with "real" admins, WSH is actually *not* used mostly for system maintenance per se, but for standard automation. Using scripts to perform actual administrative tasks/maintenance is just a bad idea to begin with.
t
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists