I re-read The Cuckoo’s Egg by Clifford Stoll this week. I last read it about 10 years ago as I was just starting my career.
Reading it now, it kind of funny to see that the debates haven’t changed. If you are new to this field, you might think that Dan Greer invented the concept of Operating System diversity. As I read the book, I found that Cliff mentioned this twice. Of course then the diversity was Unix, Berkeley Unix, and the VAX.
Passwords were another point of contention that hasn’t changed. Cliff was complaining that admins made their passwords requirements too stringent (such as system selected) and as a result the users wrote them down. Of course, Cliff later found that when users select the passwords, they are often dictionary words and that was easily brute forced.
In the book, Bill Chandler of Mitre is quoted as saying, “simply impossible. We’re running a secure shop. No one can break in” when told that a hacker had abused their systems to attack others. Lets not similarly stick our head in the sand when it comes to security issues.
Archive for September 2007
Cuckoo’s Egg
Packaging the Cisco VPN Client Part 2
Last week I wrote in a semi-literate fashionabout my difficulties in packaging the Cisco VPN client. This week I continued trying to package the CiscoVPN client.
The problems continued this week. During the install of 5.0.01.0600 neither the profile or the rootcert were imported. I was able to fix the profile import issue. It turns out there is a bug article saying the install path should not have dashes in the folder names. TAC tells me the rootcert import issue will not be fixed in 5.0.02 and possibly not for a couple revisions after that.
This leaves me in a quandary. Can I deploy 5.0.00.0340 instead? The later version does solve a privilege escalation issue. However that can be resolved by removing the permission for “interactive” on cvpnd.exe. I dont see any other pressing fixes in the release notes. Perhaps I’ll even be able to stick to the installshield version and not be forced into using the MSI.
Passwords: everyones favorite topic
Steve Riley writes about our favorite topic to beat into the ground, passwords. He hits three key points, account lockouts, disabling unused accounts and password expiration.
I more or less agree with him about account lockouts. They are a poor substitute for good passwords. They cause (a few) calls to the helpdesk, and open a vulnerability to a denial of service attack. The problem is how do you then enforce the 15 character passphrase that he recommends. While it is both more memorable and more secure, that doesn’t mean it wont get fought hard.
Can you really do away with account lockouts? Lockouts are still seen by many as a requirement for account security. I heard a story recently of a satellite ground system that wanted to lockout their operators accounts until an administrator could perform a reset. During the night the operators would be unable to access their terminals because the administrators only worked during the day. The computer systems are in a secure area on a private network. Does the perceived benefit of account lockout justify the threat to the satellite and its data? I’d say no. Section AC-7 of NIST SP 800-53 lists requirements for account lockouts. If you’ve got an audit, account lockouts are probably on the list of things they are looking for.
Steve pretty much says that disabling unused accounts is an HR problem. While it is true that the accounts process needs to be hooked into HR, this will only give you hires, terms, and if you’re lucky people transitioning to an “on-call” roll. If you have a policy than an account is created for every employee, there will be employees who don’t use the accounts.
Finding a good program or script to disable unused accounts is not easy. You want it to run on a schedule. You dont want to have to do this yourself manually. It must be able to exclude users by account name, security group or OU. It must be able to notice when “password never expires” is set so it ignores those accounts. If you’re running a Windows 2000 domain it needs to collect last logon from each domain controller and find the most recent time for each account. If a Windows 2003 domain, there is an AD account attibute that collects this and replicates it for you. Lastly it must be able to disable the account without modifying the other attributes. This is kind of a pain since the account disable attribute is actually part of userAccountControl which stores a bunch of things.
Password expiration helps prevent the bad guy from having access forever if he does penetrate the account It also annoys the crap out of people who are sharing accounts (against policy). To me it makes sense for sensitive accounts to be changed more often then regular accounts. I don’t think this can be done with Windows currently. I recently used Anixis Password Policy Enforcer to create separate 60 day expiration for users with domain administrator privileges. (Regular users have a 90 day expiration).
Password Policies generate a lot of discussion. It seems to be like “is antivirus dead”. Every 6-12 months someone kicks off the same discussion.
Forefront for Sharepoint Eval
We’ve decided that McAfee Portalshield for Sharepoint isn’t cutting the mustard so its time to look for other products. The Sharepoint guys are working on upgrading to Sharepoint 2007. From what I’ve heard McAfee doesn’t support Sharepoint 2007 yet. McAfee Portalshield has had a couple annoying habits anyway. Once we installed it, we had to restart IIS on a scheduled basis, otherwise the sites would become unavailable. We also had one compressed file that would constantly get detected, and we could never figure out where the file was located.
One of the sysadmins installed Forefront for Sharepoint and asked me to check it out. I really don’t remember why we didn’t go with this a year ago. I like Sybari products and this should be pretty much the same thing as the newer Microsoft Forefront branded products.
As I began to eval, I attempted to upload an eicar file. Forefront successfully detect this, but I also received a detection from Symantec Antivirus Corporate Edition (the file system antivirus) for Eicar in C:\Program Files\Microsoft Forefront Security\SharePoint\Data\ADF\VxData\eicar.00.ext. I figure that I need to exclude the data directory in SAV. It would be nice to find a KB indicating that, but no joy thus far.
Next, I uploaded cain.exe into my Sharepoint My Site. Actually, it rejected cain.exe because it is an executable so I renamed the file to cain.ex_. Sybari had a incredibly stupid configuration where they only scanned file types known to be potentially malicious (this setting isn’t visible to the admin and is on by default). It seems that this behavior has held over to Microsoft Forefront, because cain.ex_ is not detected on upload. I initiated a quickscan of My Site in Sharepoint. Forefront still detects nothing, but I received a detection
File: C:\WINDOWS\Temp\3e540056.$$$
Virus: CainAbel
It appears that Forefront is unpacking its scanned files in Windows\Temp. This seems incredibly foolish. I’m wondering if this has something to do with using the Clean setting rather than the delete setting. Either way, this shouldn’t happen.
Housekeeping – Upgraded Templates
I decided to upgrade from the Movable Type template that I’ve been using since version 2.6. You should now be able to use OpenID and Live Journal logins when commenting in addition to the typekey logon you could use before.

