General: January 2007 Archives

At our company we implemented a mandatory screensaver about a month ago. In my testing I found that if I allowed the user to select the screensaver, that they could select "none" and no screensaver would run. Obviously that isn't something you want to happen. I also found if a computer did not have the specific mandatory (corporate logoed) screensaver then that was the equivelent of not having a screensaver.

We rolled it out using logon.scr as the default intending to later change that. I figured that if we named the new screensaver logon.scr then systems that had received the new screensaver would run that, otherwise they'd have the default flying windows screensaver.

Tonight I was looking into it, and it seems that logon.scr is protected by Windows File Protection. Not sure what the next step is.

In Windows Domain Cached Credentials are a local hash of your password, which allows you to log into the computer in case the domain controller isn't available.

CacheDump is a tool that allows you to easily extract that cache, for offline password cracking. You could use John the Ripper (with a plugin) or PasswordsPro ($$ for full features).

CacheDump pulled my own credentials and another set of credentials. While I haven't tested further than sounds like anyone with local admin rights would be able to export the cached credentials of anyone who had logged into that computer. So say a support person's account is local admin on all desktops, and they do support work at a user's computer. That user could export the hash and attempt to crack the password.

Of course a strong password helps.

Crazy day at work today. I got into work early. My office is right over the main entrance so I tend to notice any odd occurrences. Around 9:30 , I noticed multiple Fairfax Country police cars parked at the front door. I had to get ready for a meeting, but I heard at 10am that the east side of the building from 1-3 had been evacuated due to a suspicious package. Since this didn't effect the room we were in (and I really wanted to have my meeting) we went ahead with the meeting. Around 11:30 we wrapped up the meeting. I went back to my office and found just about everyone outside the window.

It seemed like a scene from a movie, you look out the window and there are cops, feds, firetrucks, the bomb squad, and a schoolbus (we have a nursery in the building). It was incredible. We were advised over the company's internal intercom at 11:30 am that the building was being evacuated and that we should go home.

According to FCW.com after the employees evacuated, a bomb detection robot removed the package from the building, and they imploded it. We received an email at 3:45 pm that everything was safe. The suspicious package contained only papers. I haven't heard if the papers were just normal papers, or if there were threats. FCW reported that there have been a string of suspicious packages delivered to my company. We haven't evacuated for previous suspicious packages, so either the police were exceedingly careful, or there was more to this one.

It seems that GoDaddy is now acting as internet content police. They disabled the domain registration for Seclists.org based on a complaint from myspace.com. Seclists.org is a web archive of many security lists. I use their RSS feeds to follow many security discussions.

It seems part of this content included the list of 53k usernames and passwords found to be collected on a phishing site. Myspace didn't like that.

I'm of two minds on this. When I'm trying to take down sites hosting malicious content, it's often beneficial to send a desist email to every possible link in the chain. On the other hand this is a slippery slope where a domain could get yanked for any reason.

People enticed by cheap domains held their nose when reading the fine print. GoDaddys ToS says they "reserve the right to terminate your access to the services at any time, without notice, for any reason whatsoever."

You still shouldn't mess with Fyodor.

Apple has provided a fix for the RTSP exploit announced during the month of Apple bugs. Unfortunately, the update is quite hidden for Windows users. The Apple security document only has a link for Apple users, there is no link for Windows 2000 and XP users. Interesting.

The ISC diary has posted some instructions to download the patch, but you need to have Apple Software Update installed. If you have it, its probably on the start menu. You need to have recently gotten iTunes or Quicktime to have this installed. I only have it on one of my computer. I cant figure out where to download the patch for the other computers. I ran the "check for updates" from within Quicktime and it says I am up to date! This is not going to be good for enterprise software updates. We were already asking why Quicktime is on our ghost load.

I used Microsoft Process Monitor while downloading the patch on the one computer with Apple Software Update installed. That allowed me to capture a MSI file from my Temporary Internet Files; %userprofile%\Local Settings\Temporary Internet Files\Content.IE5\M7CLQPIX\SecurityUpdate2007-001[1].msi (your location will probably vary).

After installing the patch, my Quicktime was still version 7.1.3 when I checked the help, about quicktime from within the program.

The update creates a registry key HKEY_LOCAL_MACHINE\SOFTWARE\Apple Computer, Inc.\QuickTime\Security Updates\2007-001 Version=7.1.3.191 (need to double click on version to see the value). The quicktimeplayer.exe is now version 7.1.3.191 as well. Previously the version was 7.1.3.100. These two items will help differentiate patched systems from unpatched systems.

Now, I need to figure out how to deploy this. Next, I will check if the 7.1.3 version from www.apple.com/quicktime is the new version. If so, I'll probably update my install package and do a bit of testing. Hopefully it won't be necessary to slipstream or daisy chain this SecurityUpdate2007-001.msi and the existing 7.1.3

It looks like bank account and retirement account theft are going to be this years "stolen laptop." By that I mean it will be the story that is reported with increasing frequency.

Today's story is found in Techworld. It seems that some participants in the Governments Thrift Savings Plan had a keystroke logger installed on their computers. The bad guy used the login and account information to electronically transfer cash to other accounts.

"External penetration testing has demonstrated that our system has not been breached," the TSP said. "There is no evidence of any successful attacks against the system to identify a PIN and thus obtain access."

This is kind of a strange quote. The failure of an external pen test to identify any holes does not demonstrate that the system hasn't been breached. To determine if the system has been breached, you would need to examine the system logs, IDS logs, etc. To trust those logs it would be necessary to have used a third party log server to preserve the integrity of the logs. A forensic examination of the systems may be needed.

If I were creating a caching proxy, I think I would have it tune by assuming the content needed to be refreshed frequently. Only after a history is established should it save bandwidth by checking for updates less frequently.

We implemented a transparent caching proxy this week. I'm seeing cache freshness issues. When I talk to the vendor about this they blame bad websites. Most websites, use HTTP headers to indicate when the content expires. The problem with this response, is you have to take the Internet as it comes to you. Without this proxy, my users are just fine. Adding the proxy is supposed to make things work better not worse. In my opinion its the vendors responsibility to make it work.

So I'm left with promises that as I add more users, and time passes, the proxies freshness algorithms will learn and I wont see these issues. The vendor points out they have 70% of the caching market so they must be good. I'm left looking at yesterdays news.

Today's virus of the day is being detected as win32.small.dam in our inbound email.

The recipient addresses so far are very old. I guess this is one spammer group that hasn't been sold our corporate addressbook.

The only reason I mention the virus, is the lurid subject lines got a laugh out of me.
"U.S. Secretary of State Condoleeza Rice has kicked German Chancellor Angela Merkel"
other subjects:
"Naked teens attack home director"
"British Muslims Genocide"

Attachment named "full clip.exe" and video.exe

Here's a link to F-Secure's blog entry on this virus.

I had heard that Adobe Reader 7.0.9 is out, so you no longer have to upgrade to 8 to avoid the vulnerabilities mentioned in their security advisory. The problem is, according to this advisory they are only making 7.0.9 available as a full upgrade and not as a patch. I guess that is part of their program to encourage upgrading. Does this upgrade do anything besides replace one dll?

According to a Federal Computer Week article the GAO has approved a request by the US Patent and Trademark Office that it be allowed to pay high-speed Internet access for patent and trademark teleworkers.

The ability to telecommute itself is a benefit. Now these highly paid workers want the Government to pay for their internet connection too?

What's kind of funny is that although the GAO is allowing the PTO to pay for the access, they cannot pay for any hardware costs. That encourages the employee to connect directly to the internet, rather than implementing a NAT router.

http://www.us-cert.gov/current/index.html#sunjpriv
US-CERT announced today that they are aware of publicly available exploit code for multiple vulnerabilities in Sun Java Runtime Environment (JRE). There are several flaws in the JRE that may allow an untrusted Java Applet to elevate its privileges or execute malicious code.

These issues are addressed in the following releases (for Windows, Solaris, and Linux):

JDK and JRE 5.0 Update 8 or later
SDK and JRE 1.4.2_13 or later
SDK and JRE 1.3.1_19 or later

Pascal Meunier writes in the CERIAS weblog about lack of proper etiquette in zero day disclosures.

I do tend to agree with him. Zero day disclosures don't help anyone but people trying to make a name for themselves, HIPS vendors, and malware purveyors. However, I would say that this post would have been better timed during the first "Month of xyz vulnerabilities" rather than waiting until the critics darling Apple was targeted.

Daylight Saving Time starts early and ends later beginning this year, and your systems need a patch to be able to handle it.

Here's an article on one guys attempts at addressing this.

Personally, I'm getting a bit stressed. We already have a ton of stuff going on. I figured if I started after the new year, that patches would be released and I'd still have two months to do it. Well, I'm still waiting on Sharepoint and Exchange patches from Microsoft. The Solaris guys report that SUN released their patch in 2005.

Daniel Wesemann has a great commentary today in the SANS Internet Storm Center diary about one of my favorite books Cuckoo's Egg by Clifford Stoll.

I agree with Daniel that the same problems are present today. Passwords suck and should not be used for important things such as remote access to your companies network. That's why things like SecurID or smart cards are so important.

What's that phrase, "prevention is important but detection a must"? Something like that. If Clifford hadn't been so curious about an accounting problem of less than a dollar the issue in the book wouldn't have been uncovered. How would you know if someone were using your employees accounts?

If you haven't read this book, I highly recommend it.

While reviewing logs last week, I noticed that a VPN server over at our DR site was still online. This particular server should have been removed a year ago when we transitioned to a new VPN software. I didn't have a copy of the old VPN software installed anywhere but I remembered that if I connected on the VPN port, that it would answer with a banner. Sure enough the VPN was still on line.

That's the problem with development firewalls and DR sites, they don't get used that often and as a result they can be forgotten. That's not good for security. I notified the VPN and Operating System admins who disabled the VPN immediately. It looks like the VPN admin tried to disable the product, but didn't do it correctly.

The lesson is kind of obvious, know what you have. Also, trust but verify. The old VPN access should have been removed from the firewall rules when its approval to exist expired. No one verified that this actually happened.