As I’ve mentioned, I’ve been hard at work adapting the NIST Windows XP hardening guidelines in 800-68. Any hardening guideline should be examined for appropriateness to one’s corporate environment.
One thing I noticed about both NIST’s writeup and Microsoft is that neither provides an ADM template. They both have settings that are not part of group policy such as disabling autorun or disabling auto admin logon. Microsoft seems to be providing a vbscript that will “patch” the Security Configuration Editor to have these settings. That would work well when I am applying the security settings to a computer being used to create a disk image for future deployment, but I dont see how I could use that to deploy through group policy.
Unless someone has a better idea, it looks like I’m going to be creating my own ADM file soon.
Archive for October 2006
Where’s the ADM?
On-screen keyboards fail protect against password thieves
Some banks and kiosks have used on-screen keyboards in an effort to thwart keystroke loggers. Apparently the bad guys have caught on to that. There is an article on this here, and video posted here. When you connect to a bank site in the list of targeted sites, the malware will take a screenshot at every mouse click. The image will include a mark on the screen where you clicked.
SafeDllSearchMode
This evening, I’m working on creating a Windows XP sp2 hardening guide based on NIST document 800-68. In the document NIST suggests enabling SafeDllSearchMode. From reading Protect Your Windows Network by Jesper Johansson and Steve Riley I know that SafeDllSearchMode is turned on by default in Windows XP Service Pack 1 and higher.
I suppose they could be saying that creating the registry key and making sure it remains equal to 1 is easier than making sure it never gets created equal to zero. Hardening is more than just applying settings once, you need to make sure they remain set that way.
The way it comes across is they weren’t aware of the default value.
Yes, but is it best practice
On almost a yearly basis it seems like we have an audit for some reason. In each audit, the password policy has gotten flagged. We have a policy requiring Letters (uppers, lowers), numbers and special characters, 3 of the 4. We haven’t implemented the requirement in account policy. So each audit, a report goes to the executives with this as a highlighted item, and each time, they reject implementing what has been a company policy since the beginning of the company.
So we have this long list of external auditors who have made this recommendation. But that’s not good enough. The execs want it to be shown that its “best practice”. I guess someone is going to have to peer into he world of other companies our size and in our business and see what their password policy is. *sigh*
Symantec Virus Defs.
Symantec has had a problem with virus definition corruption in the past few versions. I must say the way it fails in version 10.0.2 is rather annoying. In versions 8 and 9 it would fail by having the service stop and it would no longer contact the parent server. So you would have to audit for missing machines in the SSC or use a product like SMS to look for systems with stopped Symantec Antivirus services. There is also an application log event indicating virus definition corruption.
In 10.0.2, the client still reports into the SSC, but it often does not list a scan engine number. the definition number does not update. This is better because you can look for systems that are online with out of date definitions or a blank scan engine number.
The part I find a problem is that in the application log of the afflicted computer, it says “virus definitions are current.” There is no indication to the user that their sav is broken. When you look at c:\program files\common files\Symantec shared\virus defs, I am seeing virus defs from a couple of days ago even though the SSC is reporting one of the older defs being in force.
So how do I fix it when I get into this situation? I’ve heard of some people at other companies who would replace the contents of c:\program files\common files\symantec shared\virusdefs\ and c:\documents and settings\all users\application data\symantec\… I guess I’m a bit scared to do that. I wonder if I have to match OS version. Do I have to match SAV versions? Writing scripts saves time in the long run, unfortunately you have to make time now to get it right. I just dont have that time. So I do things the manual way.
The Manual Way
In c:\program files\common files\symantec shared\virusdefs:
1. delete the most recent folder containing a virus def. In this case its 20061025.039
2. Edit definfo.dat to match the redaced number of virus defs. In this case CurDefs changes to 20061024.020 and last defs changes to 20060930.002
3. Edit usage.dat. There should be one “date” indication followed by a list of sav components. In my case I see:
[20060930.002]
navcorp_70=1
navcorp_70_2=1
[20061025039]
defwatch_10=1
This is wrong, there should be only one date. remove [20061025.039] and change the “date” at the top to match your most recent virusdefs. In this case its 20061024.020. I suspect my problems are caused by doing upgrades and causing both navcorp_70 and navcorp_70_1 being there. But I’m not sure about that.
4. Symantec says to check the incoming folder, that has rarely had anything in it. It should be empty.
5. If you see any folders ending in .tmp delete them.
Next go to c:\documents and settings\all users\application data\symantec\symantec antivirus corporate edition\7.5\. I remove all the files in this directory (not the folders). I then remove all the folders in the i2_ldvp.vdb folder.
Stop and then start the symantec service. If everything is happy it should create a new folder with todays defs in the virusdefs directory (assuming you are on a corporate network getting updates through vdtm) otherwise run liveupdate.
This rant seems to have turned into a knowledge base article. Keep in mind that symantec.com/techsupp is a much better place to get symantec help. I’m just rattling off some thoughts.
This is rather weird, every system has the 20061024.020 and the 20061025.039 defs in the folder but report in a previous def version. How very odd.
Yahoo! Messenger Vulnerability
A SecurityFocus entry reports a remote buffer overflow vulnerability in Yahoo! Messenger Service 8 with Voice.
Use of a personal firewall will help protect against this sort of attack.
Sending a Link
Tonight I’m working on a brief article for our the I.T. Department’s newsletter that is distributed to the company.
I’d noticed that some outbound email was being detected as a virus when people copied a webpage into an email and sent it. All that Javascript made the scanner unhappy. I think the rotating banner ad was also a problem because the email was then different each time it was loaded.
So the article was pointing out how to avoid the problem. The Exchange administrator advised the best way is to just send a link rather than the entire article. That reminded me that some infosec people don’t believe in sending links. Rather you’re supposed to just tell the recipient to go to site X and enter a search term.
I can see this now. “Go to www.fnord.ch and search on Bin Laden. You know this is not a virus because I’m making you type in the link and do a search yourself.” Where’s the protection there? Of course if its “Go to the BBC site and search on Bin Laden” then its safer. Its safer because people are to lazy to do that much work unless nudity is promised. 
Security through unusability may be acceptable to some, but its not to me.
Viruses Protecting themselves with EFS
Symantec wrote about the threat of EFS being used to hide viruses from administrator accounts and system.
Of course if you don’t run as administrator, the virus wouldn’t (as easiliy) get the chance to create to create a new administrative user and use that account to encrypt itself. Another suggested best practice when Windows 2000 first came out was if you aren’t using EFS, then disable it. If either of these practices were followed, this wouldn’t be a problem.
McAfee wrote about this problem 6 weeks ago.
There is a virus family now that uses this technique.
Training Students to defend networks and computers
If you have access to ACM there is an article “Training students to administer and defend computer networks and systems” by Brett Tjaden and Brian Tjaden. It is about the 2005 version of the Secure Operations course I took last spring.
The point of the course is that most people managing systems are not prepared to defend networks and systems. In the course people have a server (windows or Linux) that they must defend 24/7 against the attacks of their classmates and the instructor. There are four stages to the course. Each stage involves planning, documentation and configuration. I “won” the 2006 version of this course by “owning” the most computers without being taken out myself.
I found this article on the bulletin board of Dr Tjaden’s office. I kind of wonder how Secure Operations 2007 will operate if the new class reads this article and has a huge leg up on how to attack.
More Bad PII practice at JMU
We’ve all heard about the chocolote bar for your password surveys, you’ve probably also heard about the fake credit card application and ID theft for a free t-shirt. What I saw this past weekend was only slightly better.
I was down at my alma mater’s homecoming football game. After the game, I decided to check out old haunts by wandering though the music building. I found a signup envelop for Pep Band. Pep Band pays (very poorly) so people signing up for pep band have to include a University employment application, and a W-4. There was also a request for a copy of the applicants drivers license and Social Security Card.
So here in this unguarded unlocked university building hallway, I found 20-30 Pep Band applications. All of which included Social Security Number, Student ID number and home address. Some applications also had the requested copy of the drivers license and social security card.
Do people have no concept of protecting personally identifiable information?
Authority asked them to do something dangerous with their Personally Identifiable Info, not for a chocolate bar, but as part of the job application process. The paperwork submission process should not leave this information exposed in a hallway.
