Schneier on Security
A blog covering security and security technology.
« Spray-On Explosive Detector |
| TPM to End Piracy »
May 28, 2008
Built-in Windows Command-Line Security Tools
Posted on May 28, 2008 at 2:59 PM
• 22 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
Impressive, we're almost catching up with *NIX (SCNR)
And then there is that one flaw... its got a microsoft tag on it.
Yeah, almost catching up, except that you have to reboot and accept a reportedly-large performance hit before the moral equivalent of fuser/lsof works. I don't understand how this can be expensive data to collect: surely the OS must be tracking it anyway...
Ha ha ha, "built-in", as if that is something special.
To use your car analogy, Bruce, I can't remember anyone telling me to use the "built-in" seatbelt, or the "built-in" brakes.
I can think of some other operating systems with command-line tools that include security features/functions. We don't refer to them as "built-in" any more than we think of the command line itself as "built-in". Heck, these OS even include a wait/sleep function so you can write proper security scripts. Wonder why that was never "built-in" for Windows. Skoudis suggests the ever popular "just ping into nul for five seconds" as if it's normal behavior.
Aren't wait/sleep POSIX? Doesn't Windows support POSIX to some degree?
If *NIX is your target, then you're aiming far too low. We can do far better than a security design rooted in the threat models of a non-Internet connected world.
Good stuff, Bruce. I'm sure Windows IT pros know this stuff, but I didn't, and it's good info. Thanks!
You should check out Mark Russinovich's command line tools (http://technet.microsoft.com/en-us/sysinternals/default.aspx)
I agree with Pat .. Mark's utilities are pretty good but most of them are basically a GUI which uses the WMIC stuff under the hood. THere will be situations where u want minimum contamination where CLI is the way. WMIC, Netsh and other CLI stuff are the best way to get info when required. you can directly dump the output using >> to a text file for later inspection
Cool! The WMI interface is provided by all current Windows versions; the WMIC console application was left out of XP Home. However, with OpenPegasus, one can access the WMI info remotely from a Linux box. Of course, to do that one has to do some contortions, like running a mapping proxy on one of the Windows boxes in your network which maps the non-standard WMI transport protocol to a more standard protocol.
It seems that MS is getting more and more conflicted between needing to provide access via standard open protocols (or rather, protocols which can be CALLED standard and open by their marketing guys) and wanting to keep everything locked-in and proprietary.
I remember when Ed Skoudis first started to collect these WMIC commands a few years ago. The point was to try to find the most information you can with a command line on a Windows machine that you could absolutely not install any new tools on.
@anon: "Doesn't Windows support POSIX to some degree?"
This was misleading marketing statements from Microsoft.
sleep is POSIX.2, and Microsoft said that they would not comply to POSIX.2 because it is not an ISO standard: http://www.microsoft.com/technet/archive/...
The same page explains why Microsoft would not comply to POSIX.N for N=2, 3, ..., 12.
In NT, only the kernel is POSIX.1 (basically, it is C calls).
XP and windows 2003 are no more POSIX according to http://support.microsoft.com/kb/308259 and http://www.google.fr/search?... unless Windows Services for Unix (SFU, or its successor SUA) is downloaded.
Their new tool Powershell is not POSIX either, despite having a misleading name.
You can still have a look at some marketing misleading statements here : http://technet.microsoft.com/en-us/library/...
I have always wondered why Microsoft buries these powerful tools (wmic, netsh, gpedit, dxdiag, regedit...) in the deep of Windows. Probably they believe the average user is too dumb to use them and he would make a mess if he knew about them. But for those with a more extensive knowledge of the machine, some documentation would be surely appreciated.
Mark Russinovich's Process Explorer displays all this information in a much more readable fashion. Command line is not always better than a GUI.
And of course I know that Sysinternals is now part of Microsoft.
@Ulrich: I'm a great fan of Russinovich's Process Explorer and other GUI tools such as Autoruns, but you know that he has also provided CLI versions of most of his tools, too. You can easily have it both ways.
My problem has never been being unable to find a big long list of arcane service names running on my machine; my problem has always been figuring out which of them are needed/useful/legitimate.
"I have always wondered why Microsoft buries these powerful tools"
The only powerful tools Microsoft buries is the competition's offerings.
Bookmark http://www.BoycottNovell.com/ for more . . .
"My problem has never been being unable to find a big long list of arcane service names running on my machine; my problem has always been figuring out which of them are needed/useful/legitimate."
BillP Studios WinPatrol 2008 does this and much more on a friendly level that seeks out answers (with the plus version) in a way we can all understand.
This, for those of us who lived through the GUI vs. command line wars of the late '80s and early '90s, is a brilliant quote:
"However, memorizing the obscure locations where Microsoft has buried various controls in its GUI is a bewildering task.
"Fortunately, users don't have to dig through the GUI to find what they want; instead they can rely on command-line shortcuts."
> GUI vs. command line wars of the late 80's...
You mean the holy wars? Next to distro cult wars or macintosh fanaticism, probably the most pointless argument in personal computing history :)
It's a fantastically crazy argument on both sides. Sometimes you want a GUI (usually, when you want visual representation of data). Sometimes, you want a CLI (usually, when you want optimized command-entry).
If you really want to explore WMI then the wbemtest GUI is a lot easier to use than wmic. But having found an interesting class in wbemtest you can read it through wmic or a script. I have a diagnostic script for Windows networking that is written in VBScript (for portability!) and reads just about everything through WMI.
hmm ... those links dont open on my mac browser ... anyone else experiencing that ?
Schneier.com is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc.