One of the nice features within WMIC is its ability to check whether a given patch is installed on a box using its Quick Fix Engineering (QFE) alias. (I know... QFE in my old life as a Solaris admin stood for Quad Fast Ethernet. Not anymore. Oh, and don't tell anyone that I used to be a Solaris admin. That's just our little secret.)
Anyway, we can query by KB article number for a given patch, using the following syntax:
C:\> wmic qfe where hotfixid="KB958644" list fullThis little gem will show whether the patch associated with MS08-067 is installed, which was the vulnerability the Conficker worm initially used to spread. This command, when used with the appropriate KB number, can really help you to determine whether a given patch is installed, and whether it was installed in a timely fashion. Yes, the output does include an "InstalledOn" date! That's especially helpful if you need to verify that your admins have moved quickly for an out-of-cycle patch, like the one associated with MS08-067.
You can make it run remotely, provided you have admin credentials on a target machine, by adding the following notation before the qfe:
/node:[IPaddr] /user:[admin] /password:[password]Leave off the password, and it'll prompt you. Change the [IPaddr] to "@[filename]", and it'll check all machines whose names or IP addresses you have listed in that file.
I was once teaching a class full of a bunch of auditors where this command came up, in a pretty comical fashion. There was a delightful little old lady in the class, just a grey-haired sweetheart with a nice grandmotherly voice. I was explaining wmic qfe to the class. She raised her hand, and meekly asked very slowly, "So, does this output include the date the patch was installed?" I responded, "Why, yes, it does." She shot back with an evil cackle, "Yesssss! I will be able to DESTROY people's lives with this!" Ahhh... auditors. You gotta love 'em. :)
Hal Says:
In this case, Ed has the advantage because he only has to deal with a single operating system. It seems like package and patch management is one of the things that no two Unix or Linux providers do the same way. So for purposes of this example, let me just pick two of the more popular Linux package management schemes: the Debian apt system and the Red Hat yum and rpm utilities.
On Debian-derived systems like my Ubuntu laptop, figuring out which packages need to be upgraded is straightforward:
# apt-show-versions -u
libjasper1/intrepid-security upgradeable from 1.900.1-5 to 1.900.1-5ubuntu0.1
libnss3-1d/intrepid-security upgradeable from 3.12.0.3-0ubuntu5 to 3.12.0.3-0ubuntu5.8.10.1
It's also pretty clear from the output that these are both security-related updates.
What's interesting is that Debian doesn't appear to track the install time for the various packages on the system, much to the disappointment of Ed's little old lady auditor I'm sure. However, when system updates are done the new packages are downloaded to /var/cache/apt/archives. If the system administrator doesn't clean up their package cache on a regular basis ("apt-get clean"), you could look at the timestamps on the various package files in this directory to find out when the last update occurred.
On Red Hat systems, "yum list updates" will show packages that need to be updated. However, unlike Debian systems, there's no clue about whether the given patch is security-related or just a functionality update. The good news is that as of RHEL 5.x, there is now a "yum-security" plug-in that you can install ("yum install yum-security") which will allow you to get information about and install only security-related patches:
# yum list-security # lists available security updates
# yum update --security # installs security-related updates
Red Hat systems do track package installation times. Here's a command to dump out the package name, version, and installation date of a single package:
# rpm -q --qf "%{NAME}\t%{VERSION}\t%{INSTALLTIME:date}\n" tzdata
tzdata 2008i Sun 23 Nov 2008 10:06:32 AM PSTYou can also generate a report for all packages on the system:
# rpm -qa --qf "%-30{NAME} %-15{VERSION} %{INSTALLTIME:date}\n"That will give you a nice, pretty-printed list with neat column boundaries.
Paul Chimes In:
Luckily since we are running OS X, we don't have to worry about vulnerabilities because the "fan boy's" operating system doesn't concern itself with such things. Ha! Kidding of course (however, most of our vulnerabilities and exploits are of the 0day flavor, so patches don't help us, *cough* Safari). OS X comes with a command line utility called softwareupdate. You can list packages that need to be installed using the following command:
# softwareupdate -l
Software Update Tool
Copyright 2002-2007 Apple
No new software available.
In the above command you can see that the system is up-to-date (I tend to apply software updates from Apple as soon as they come out, as usually the vulnerability and exploit has been out for some time). Having a command line version makes it easy to update systems remotely, provided you have root privileges on the remote system. If there were packages available to install I could use the following command to install them:
# softwareupdate -i -aWhich instructs OS X to install (-i) all available updates (-a). OS X is a different beast than Linux/UNIX (borrowing more from *BSD, which we haven't covered in any detail yet), so getting more information about installed software is different. One command I cam across was "pkgutil", which can be used to see which updates have been installed. You can run the following command (without root or administrator privileges):
$ pkgutil --packages | grep com.apple.pkg.update*
com.apple.pkg.update.os.10.5.3
com.apple.pkg.update.os.10.5.4
com.apple.pkg.update.security.2008.005
com.apple.pkg.update.os.10.5.5
com.apple.pkg.update.security.2008.007
com.apple.pkg.update.os.10.5.6
com.apple.pkg.update.security.2009.001
And it will list the currently installed software update packages on the system. Apple typically releases updates in the format of
# ls -l com.apple.pkg.update.*
-rw-r--r-- 1 _installer wheel 3420277 May 23 2008 com.apple.pkg.update.os.10.5.3.bom
-rw-r--r-- 1 _installer wheel 481598 Jun 20 2008 com.apple.pkg.update.os.10.5.4.bom
-rw-r--r-- 1 _installer wheel 876891 Sep 6 2008 com.apple.pkg.update.os.10.5.5.bom
-rw-r--r-- 1 _installer wheel 3111901 Dec 8 22:15 com.apple.pkg.update.os.10.5.6.bom
-rw-r--r-- 1 _installer wheel 122728 Jul 31 2008 com.apple.pkg.update.security.2008.005.bom
-rw-r--r-- 1 _installer wheel 460162 Sep 29 23:53 com.apple.pkg.update.security.2008.007.bom
-rw-r--r-- 1 _installer wheel 469254 Jan 30 21:51 com.apple.pkg.update.security.2009.001.bom
A "bom" file in OS X is a "Bill Of Materials" which in the case of an update, is a list of files that were installed as part of that package. Not as pretty as Hal's output, but then again, who's as pretty as Hal?
