blog.scottlowe.org

Security researchers recently uncovered a zero-day vulnerability in Microsoft Word that allows attackers to install a backdoor Trojan horse on the affected computers.

More information on this vulnerability can be obtained from the following links:

Alert Raised for MS Word Zero-Day Attack
<http://www.eweek.com/article2/0,1759,1965042,00.asp>

Microsoft Word Malformed Object Code Execution Vulnerability
<http://secunia.com/advisories/20153/>

Microsoft Security Advisory (919637): Vulnerability in Word Could Allow Remote Code Execution
<http://www.microsoft.com/technet/security/advisory/919637.mspx>

SecuriTeam Blogs: Mitigating Newly-Reported Word Vulnerability
<http://blogs.securiteam.com/index.php/archives/421>

As described in the above articles, there are a number of ways to protect yourself against this vulnerability:

• Don’t log in with administrative privileges.  The exploit fails to work if the user doesn’t have administrative privileges.
• Use an older version of Microsoft Office.  The vulnerability only affects Word 2002/XP and Word 2003.  Users of Word 2000 and earlier are apparently not affected.
• Use the Word Viewer to view documents, as the Viewer is not affected by this vulnerability.

Anti-virus vendors are updating their signatures to try to catch this, but I wouldn’t rely solely upon anti-virus to protect against this vulnerability.  A patch has not yet been released from Microsoft, which anticipates releasing a patch for this issue in June.

The level of comment spam I’ve been receiving over the last few days has suddenly skyrocketed (as in approximately 200 spam comments in just a couple of days).  It was time to do something.

That something was Akismet, a highly-regarded spam mechanism for blocking comment and trackback spam.  I’ve now installed Akismet to protect this weblog, so we’ll see how well it works.  Blog spammers beware!

Back in March, I posted an entry describing a problem with the new Intel-based Macs on networks using VLANs and 802.1q.  By all reports, that issue has now been resolved.

The same forum that alerted me to the issue in March is now reporting that the Mac OS X 10.4.6 update and/or the Intel firmware update has resolved the problem, and the massive packet loss users were previously seeing is no longer occurring.  Some users are reporting success having only applied the 10.4.6 update; others indicate that both the OS update and the firmware update corrected the problem.

Continuing in my “semi-automatic” theme, here’s some information on using command-line utilities to help automate account maintenance.  By combining dsquery and a third-party replacement for Dsmove (since Dsmove has some problems), we can streamline account maintenance policies for Active Directory.

First, the problem with Dsmove.  The Dsmove.exe utility is supposed to be able to take DNs on standard input (stdin) and move them (with or without a rename operation at the same time) to a new location in Active Directory.  Unfortunately, it doesn’t work; for some reason, Dsmove won’t accept the output of Dsquery, even though that output works with Dsmod and Dsrm.  I found numerous references to this same problem (here’s one) via a Google search, so I know I’m not alone.

Fortunately, there’s a free third-party replacement that steps up to the plate to fill in for dsmove, and it’s call AdMod.  AdMod does more than just move objects; it can also modify objects as well.  For our purposes, however, we’re just going to use it to move objects.

We’ll start out with the Dsquery command again, this time to find inactive accounts:

dsquery user -inactive 4

This will find all the user accounts have have been inactive (not logged into) for more than 4 weeks.  Pipe this into the Dsmod command to automatically disable them:

dsquery user -inactive 4 | dsmod user -disabled yes

This ensures that any account that has not been used in more than 4 weeks will be automatically disabled.  Now, we can bring in AdMod to help us keep those disabled accounts manageable:

dsquery user -disabled | admod -move “ou=Disabled
Accounts,dc=example,dc=net” -safety 100

This will automatically gather all the disabled accounts and move them into the Disabled Accounts OU automatically.  Note the “-safety 100” parameter; this means that if more than 100 objects will be affected, the command won’t proceed.  This can be replaced with the “-unsafe” parameter if this fail-safe isn’t necessary.

So, put this into a batch file, schedule it to run once a week, and it will take care of those inactive accounts that are no longer being used.  (This will make those security guys pretty happy.)

One really cool feature of Exchange Server 2003 is query-based distribution groups.  This feature allows organizations to define LDAP queries and then dynamically populate distribution groups based on the results of the LDAP query.  Unfortunately, there’s no built-in equivalent for security groups, but here’s a reasonable workaround to create that same kind of functionality.

Using the Dsquery and dsmod tools in Windows Server 2003, we can create a command that issues an LDAP query, then stuffs the result of that LDAP query into an already-existing security group.  Here’s how it works.

First, we use the “dsquery *” command, which allows us to define a custom LDAP query to find any kind of object within Active Directory.  Let’s say we are interested in automatically populating departmental security groups based on the department attribute for each user object.  To find all the members of the Engineering group in Atlanta, we’d use a command like this (this has been broken into three lines for readability, but should be typed in as a single line):

dsquery * ou=Users,ou=Atlanta,ou=Locations,dc=example,dc=net
-filter “(&(objectcategory=person)(objectclass=user)
(department=Engineering))” -limit 1000

This command will return the DNs of those user objects in the Locations/Atlanta/Users OU whose department attribute is set to Engineering.  We can then pipe that output to the Dsmod command, like so (again, lines have been broken for readability but this should be entered as a single line):

dsquery * ou=Users,ou=Atlanta,ou=Locations,dc=example,dc=net
-filter “(&(objectcategory=person)(objectclass=user)
(department=Engineering))” -limit 1000 | dsmod group “cn=Atlanta
Engineering Dept,ou=Groups,ou=Atlanta,ou=Locations,
dc=example,dc=net” -addmbr

This command takes the output of the Dsquery command and pipes it to the Dsmod command, modifying the group named Atlanta Engineering Dept in the Locations/Atlanta/Groups OU.  (If you anticipate more than 1,000 users in Atlanta in the Engineering department, adjust the “-limit” parameter accordingly.)

There’s a couple of problems, however.  Once the command has run once, then subsequent times will generate an error because the users will already be a member of that group.  In addition, this command doesn’t take into account those users who have left the Engineering group.  To fix this, we need a couple more commands.

First, we get the members of the group using the Dsget command:

dsget group “cn=Atlanta Engineering Dept,ou=Groups,
ou=Atlanta,ou=Locations,dc=example,dc=net” -members

This returns a list of the DNs for those users that are currently members of the specified group.  We pipe that to the Dsmod command again to clear the group out:

dsget group “cn=Atlanta Engineering Dept,ou=Groups,
ou=Atlanta,ou=Locations,dc=example,dc=net” -members | dsmod group
“cn=Atlanta Engineering Dept,ou=Groups,ou=Atlanta,ou=Locations,
dc=example,dc=net” -rmmbr

This command sequence removes all the current members of the group.  Run this command before the Dsquery, and both problems (the error about users already being a member and “stale” members not being removed) are corrected.

By wrapping these commands into a batch file and then scheduling the batch file to run on a regular interval (an interval to be determined by your organization), you have created semi-automatic security groups that will repopulate every time this command runs.

There are some caveats, of course.  Since groups memberships are only updated on the access token when a user logs out and logs back in again, the changes to the group membership won’t take effect immediately.  For this reason, it’s probably best to only run these scripts once a day during the off hours.  Second, this technique is only effective if your organization is making sure the information in Active Directory is up-to-date (of course).

In earlier posts (on the pcn0 driver in OpenBSD 3.8 and on running OpenBSD 3.8 on VMware ESX Server 2.5) I’ve provided information on running OpenBSD in a virtualized environment.  With the release of OpenBSD 3.9 a few weeks ago, I’ve completed some testing.  Here are the results.

Here’s the configuration of the virtual machine under ESX Server that I used for my testing:

• Guest operating system set to FreeBSD (OpenBSD is not an officially supported guest OS)
• Single CPU (virtual SMP is not supported)
• 128MB of RAM
• LSI Logic SCSI controller (this is a change from the default BusLogic controller)
• Standard vlance network controller

I have not yet tested to see if the BusLogic controllers works under 3.9; it for sure did not work under 3.8 (OpenBSD wouldn’t see the disks).  If time permits, I will test that soon.

I am very happy to report that the pcn driver now works as expected; it’s no longer necessary to disable the pcn driver and use the le driver instead.  It is my understanding that the pcn driver is faster and more efficient than the older le driver, so I’m pretty excited that this is now working as expected.  My subjective analysis indicates that there is a small performance gain, at least in my environment.

If I run across any additional information, I’ll be sure to share it here.

A short while ago, I published an entry discussing the integration of VMware ESX Server with Active Directory for the authentication of virtual machine management.  In that entry, I noted that I had not created a keytab as part of the configuration of Kerberos authentication.  I was curious as to why it worked, so I did some research.  Here’s what I found.

Seeking expertise, I started a thread on the comp.protocols.kerberos Usenet group about the presence or absence of the keytab, and its impact on the operation of pam_krb5 for authentication.  Based on the feedback received there, the keytab should be used to protect against a KDC spoofing attack, i.e., to verify the identity of the KDC against which pam_krb5 is attempting to authenticate and retrieve tickets.  Richard E. Silverman (of “Secure Shell: The Definitive Guide” fame) stated:

pam_krb5 verifies your password against Kerberos, right? In that case, there *should* be a keytab, due to the issue alluded to earlier in this thread: the module should obtain a host ticket to defend against a KDC spoofing attack. If it let you in without that, perhaps there’s a “verify KDC” option that’s turned off (and ideally, should be turned on).

With that in mind, I set out to see if pam_krb5 supported just such an option.  According to this pam_krb5 man page, there is a “validate” option that is supposed to force pam_krb5.so to “verify that the TGT obtained from the realm’s servers has not been spoofed.  Note that the process which is performing authentication must be able to read the keytab in order for validation to be possible.”

However, even with this option set (and the permissions set on the keytab so that it is readable by any user), this validation still did not take place (as evidenced by the fact that pam_krb5 still authenticated users against Active Directory even when the keytab wasn’t present).  The presence or absence of the keytab did not appear to affect the operation of pam_krb5 in any way.

Russ Alberry added this comment in the Usenet thread:

The pam_krb5 modules that I’ve used either don’t do this or only do this when the keytab is available, presumably doing a security vs. ease of deployment tradeoff.

So, apparently, even though the option is there, pam_krb5 still doesn’t perform validation of the TGT to ensure that the KDC wasn’t spoofed.

To test all of this, I used a freshly-built server running CentOS 4.3 and pam_krb5.  The server was authenticating against Active Directory running on Windows Server 2003 R2, where a computer account had been created and a principal mapped to that account using ktpass.exe.  The keytab generated by ktpass.exe was securely copied over to the Linux server and placed in the “/etc” directory as krb5.keytab.  Initially, only root had any permissions on the file, but read permissions were added later to see if that affected the behavior of the Kerberos module.

The final answer still remains unknown.  The man page for pam_krb5.so module indicates that the validate option should force the behavior we are seeking; but the tests that I’ve conducted so far don’t support that statement.  I plan to conduct additional tests and more research to see what other information I can uncover.

In the meantime, any Kerberos experts out there are invited to add their comments to this article and share any additional information.

Late last year, I published an entry that described a method for making mass password changes in Active Directory.  After some additional work on the topic, I have found a much better way of accomplishing the same thing.

In my previous example, I used ldifde to extract information from Active Directory.  Unfortunately, that information was a bit too complete, and it included fields and attributes that we didn’t need.  As a result, we had to parse down the ldifde output and remove everything except the DN field.

I have since discovered the use of the dsquery command, which will output DNs for objects easily from a single command:

dsquery user ou=Accounts,dc=testlab,dc=net

This command will produce a list of DNs for all users in the Accounts OU of the testlab.net AD domain.  Appending a “ > filename” to the command would redirect the output into a file that could be used later.  One caveat to this command:  be sure to use the “limit -XXX” parameter if there are more than 100 objects that you are trying to enumerate.  Otherwise, you’ll get only the first 100 objects.

Instead of redirecting the output of this command to a file we can pipe it to another command, such as dsmod:

dsquery user ou=Accounts,dc=testlab,dc=net |
dsmod user -pwd newpass1 -mustchpwd yes

This command will query all the users in the Accounts OU of the testlab.net AD domain, then set their passwords to “newpass1” and force a password change at next logon.  (Although this command is shown on two lines above, it should all be entered as a single line.)

Note that these commands work equally well against Active Directory domains running both Windows 2000 and Windows Server 2003.

Lest anyone think that I am ignoring the fact that Mac OS X has flaws, too, I’d like to mention that Apple just released updates to both Quicktime and Mac OS X that addressed a total of 43 separate security problems.

As noted in this report by Dark Reading (and this report by eWeek), Apple Security Update 2006-003 fixes flaws in the Finder, Mail, Safari, and other components.  The Quicktime update brings the version to 7.1 and corrects problems in both the Macintosh and Windows versions.

It’s important to note that some of these flaws were particularly dangerous.  As noted by Dark Reading:

The two affecting Mail, the operating system’s e-mail client, could result in a Mac being hijacked if its user simply views a specially-crafted message, Apple said in its alert. The bug in Apple’s Safari Web browser, meanwhile, can be exploited by drawing users to Web sites and duping them into downloading a malicious archive file.

The security updates are available via Software Update or directly from the Apple web site.  I’ve already patched my system (my PowerBook G4) and haven’t seen any issues, although there have been some reports of problems from the updates.

Technorati Tags: Apple, Macintosh, Security

I have a variety of miscellaneous tidbits to mention, in case you haven’t already heard about them.

• ODF for Microsoft Office:  Now that OpenDocument format (ODF) has been approved as an ISO standard, the OpenDocument Foundation has announced a plug-in for ODF that allows Microsoft Office (as far back as Office 97) to open, render, and save files as ODF.  This, in my opinion, is a great thing, as it allows those organizations that can’t use an alternate office suite to still take advantage of open file formats.
• Vista’s Security Implications:  While Microsoft touts the impressive security benefits of Windows Vista, others are disagreeing.  A recently published report believes that the new security measures interfere so heavily with users that they’ll end up getting turned off.  Furthermore, the new features and their administrative overhead will likely cause significant delays in the adoption of Vista.
• Resource Manager Web Interface:  Jason Conger has released the Web Interface for Resource Manager.  If you use Citrix Resource Manager, this is a must-have add-on.
• Virtual Security:  Joining Reflex Security (which unveiled its Reflex VSA virtual appliance a while ago—I hope to be able to review/demo this product soon and will provide more details here when that happens), Astaro has announced the Astaro Security Gateway for VMware.  The cool part is that users are encouraged to download a trial copy from Astaro’s web site.