General: February 2007 Archives

When I was reading about the Google Desktop Search vulnerability over the weekend, Google's rep was quoted as saying it would all be fixed silently without the user doing anything. I took that to mean it was done. This mornings vulnerability scan of HQ shows we have a significant amount of Google Desktop that needs updating.

Here's a link to the "Help Center" article on the vulnerability. I

Why isn't the Google Desktop Blog posting on this subject? It says it is "The official source for information about Google Desktop."

I received an email today about a settlement notice regarding a class action lawsuit over some credit monitoring. I read the email over, googled the web page given, and checked out snopes, butt didnt' find anything. Next I opened my RSS reader and found that Brian Krebs has an excellent writeup. His summary, its very suspicious looking, but its actually a legit settlement notice.

JAVA is a very difficult program to manage in the enterprise. It seems to have its share of vulnerabilities. Multiple branches continue to be used (1.3,1.4,1.5,1.6). Its not a matter of upgrading to the latest version and removing everything else.

Applications may be hard coded to use a specific version and will break if you uninstall. Since in most cases we did not provide the JAVA, the administrators don't know in which instances old JAVA is required.

SUN recommends keeping older versions of the JAVA Runtime Environment (JRE) on your system.

Then there is this later articlewhich says with 5.0 Update 6 and later installed on the Windows platform, all applets are executed with the latest version of the JRE. I wonder how the applications hard coded for earlier verions of JAVA would continue to work?

I notice that my vulnerability scanner detects the older versions of JAVA even though a newer version is installed. I'm trying to figure out whether I need to remove these earlier versions to be safe. Even then do I dare remove them if earlier versions are needed by my users.

SCMagazine reports that the new Google Office won't have security problems like Microsoft Office.
1. Security will be more robust
2. Updates will Appear Automatically
3. Less Features mean more security

Amol Sarwate, manager of vulnerability research at Qualys, says "You never have to patch anything, so hackers would be reluctant to target," You won’t even know if a patch is released. Whenever you log in, you’ll get the newest version they have."

Does that sound like a good thing? One of the complaints about Google Desktop Search was secret patching. Shouldn't you know what's going on? Qualys offers a software as a service vulnerability scanner and they announce major version updates. I wonder if they are silently patching security problems as well.

Eric Ogren, an analyst at Enterprise Strategy Group, told SCMagazine.com that Google will protect the software in its data center, and it will not be vulnerable to typical client-side vulnerabilities.

I wonder if this means my data would be kept forever, and available for search warrants, and also available to be accidentally disclosed.

The SC Writer buried the lead in my opinion. Amol Sarwate also said this service could be "could be vulnerable to an emerging set of web-based threats such as cross-site scripting and SQL injections."

That's what made this article jump out at me. In a week where it is reported that Google Desktop Search is inherently insecure it seems this article is trying to tell me that Google Office is secure by default.

Myspace and Secondlife have been targets. Who is to say similar issues won't be found in Google Office.

Richard Bejtlich sets out to write a book review, and instead writes a screed about FISMA in his latest blog entry. Its a shame too. I would like to know if this book is a good resource for those who are forced to participate in FISMA. We are currently under an Interim Authority to Operate and the auditor is coming in next month to extend that. People where I work create C&A packages and audit them for customers.

When we looked for an outside auditor for our C&A package we had a hard time. Most of the companies we were considering were strong in the technical writing or strong in technical knowledge. We didn't find a company that was strong in both areas. Both skills are necessary.

Anyone who has been involved with a C&A knows its one big paperchase. Does this mean its a bad thing? I would argue no. Documentation is important. FISMA forced us to update our documentation and create new documents. This is necessary. Due to the tyranny of the urgent that occurs in an I.T. shop this wouldn't have been done otherwise.

All of the commenters on Richard's entry disparage the C&A. They say that it offers no improvement in security. They argue that instead its a jobs program for C&A writers. Based on my own experience, I would say you get out of a C&A what you put into it. If it is an antagonistic relationship between the auditors and the System Administrators, then you have a problem. The problem is exacerbated when management just wants to check off C&A boxes rather than actually examining security and making things better. At my company we are better than some but we have a long way to go. The C&A has helped us get there.

Our HTTP scanner detected the IESlice.d virus when a user browsed to hxxp://81.177.23.253/pefwji/2_z.html this evening. Not sure where the user was surfing that they were directed there.

The IP address is Russian. The exploit appears to be for MS06-057.

Our HTTP scanner detected the IESlice.d virus when a user browsed to hxxp://81.177.23.253/pefwji/2_z.html this evening. Not sure where the user was surfing that they were directed there.

The IP address is Russian. The exploit appears to be for MS06-057.

Over at vnunet, Tom Sanders writes about the RSA conference.

More than half of the computers used by security experts attending the RSA Conference in San Francisco this week lack the proper protection and may have been compromised, according to wireless security firm AirDefense.

The company scanned all wireless traffic on the first day of the conference and found a total of 623 Wi-Fi enabled notebooks and mobile phones.

Some 56 percent of these devices were configured automatically to log-on to networks with common names such as 'Linksys' or 'T-Mobile', a feature known as an open access wireless account.

So the first first paragraph is an improper summary of the statistics. "More than half of the computers used by security experts" weren't misconfigured. It was half of the computers with wireless enabled.

So the vendor has interesting statistics and I liked the article as a whole but for me it almost got overshadowed by a misleading opening paragraph.

It is extremely important to not connect to unencrypted wifi and then leave those profiles enabled when you go anywhere else. Further, Evil twin access points do occur. Your computer leaks all sorts of passwords. Its not just when you're browsing. The second your network connection comes on line, your mail client, IM clent and RSS reader may be logging into things in clear text. Its a danger you need to be aware of, and keep your clients from launching and sending passwords, until you have established a secure encrypted tunnel, whether is an 'always tunnel' vpn back to work, or a ssh tunnel back to your home.

HP OpenView Network Node Manager has insecure default permissions.

The installation process for the software grants 'Everyone' full access to the 'C:\Program Files\HP OpenView' directory. This directory contains the 'bin\ovtrcsvc.exe' executable,
which is run as a service with SYSTEM-level privileges. So a local user can replace the .exe with malicious code and it will run with SYSTEM rights the next time the service starts (likely next reboot).

I got a note from GFI pointing out their eBook Targeted Cyberattacks: Threats Faced by Your Corporate Network. It looks like its a worthwhile read.

The paper begins by answering some of the common responses to the desire to increase security:
• "That will never happen to me"
• "I have nothing to hide"
• "We're too small to be a target"
• "Why me, when they could hit some bigger company?"

I liked this section. I hear "I have nothing to hide" a lot from even technical end users.

I got a note from GFI pointing out their eBook Targeted Cyberattacks: Threats Faced by Your Corporate Network. It looks like its a worthwhile read.

The paper begins by answering some of the common responses to the desire to increase security:
• "That will never happen to me"
• "I have nothing to hide"
• "We're too small to be a target"
• "Why me, when they could hit some bigger company?"

I liked this section. I hear "I have nothing to hide" a lot from even technical end users.

In his Fast Forward Help File earlier this week in the Washington Post, Rob Pegoraro is asked about the security implications of ISPs not using encryption on their Webmail logins.

Rob reports that Cox is planning to offer SSL webmail the first quarter of this year.

Rob comments that "The biggest reason to look for the visual cues of a secure login is to help spot phishing scams -- phony pages that, unlike the sites they impersonate, almost never use encryption." I think its a dangerous oversimplification to trust all sites protected by SSL without verifying the certificate, who its signed by and preferably whether its been revoked or not. In my experience most users don't know to be worried about SSL errors. To be fair, the newer browsers do a better job of giving a dire warning.

People dont understand SSL and what it offers. Over at broadband reports a user commenting on the need for Cox to provide SSL login says,

"It is my perception that security vulnerabilities in Windows are being exploited at a even higher relentless, frenetic pace right now. Cox needs to be part of the solution and not contributing to the problem."

SSL is designed to preserve the message confidentiality. Without client side certificates it only provides authentication of the servers identity claim. The main risk this addresses is the risk of a rogue lan administrator sniffing passwords. This is an important consideration if you use webmail anywhere outside of the cox network and also if you use a unencrypted wireless connection at home.

I wonder if Cox is going to offer POP3 over SSL. Webmail isn't the only way passwords are passed in cleartext.

I mentioned in a previous post that we had some problems with a switch leading to browsing slowness. That caused us to receive a rant about how we were preventing employees from doing any work. They went on to say we need to give notice when making changes.

As it turns out this change went into effect for this group of complainers four business days after it was announced. I also wonder just how an announcement would have helped this situation. The only thing an earlier announcement would do is allow the users to preemptively gather their pitchforks and torches.

Why do I suspect that we'll soon have a requirement where we have to notify users two weeks ahead of major changes? After being forced into an increasingly smaller outage window, I wouldn't be surprised. When I'm readying something for deployment, we serve no wine before its time. I'm not going to know two weeks ahead of time when something is ready to get pushed out the door. It will waste a lot of time to wait until I am satisfied with the results in the test group to then announce a two week rollout countdown.

On Thursday we rolled out the Blue Coat web filter to the company. It was a bit more sudden than I had planned. I had planned to roll out slowly over a week and a half (still kind of quick), with the goal to be done by January 28th. Our Websense license expired on January 31st and I wanted to be done before then.

Unfortunately a company board meeting interfered in my plans as we were not allowed to roll out anything while they were in town. I was told that after license expiration, Websense would continue to filter, but not get any new updates. This was acceptable to the Director, so we pushed back the Blue Coat with a new goal of February 5th.

As it turned out at 11 pm on January 31st Websense stopped filtering. So on the morning of the 1st we rolled out Blue Coat to the entire company and disabled the Websense.

That afternoon, I received a report about slow FTP to our DMZ. I did some testing and the speed seemed reasonable. However, that wasn't the end of it.

The next morning before I got to work, I had a voicemail about other people having trouble opening Flash and downloading large pdf files from the DMZ. It came to a head when another Director in our company emailed our Director claiming it was impossible to get any work done. The Director wanted to turn it off all together, but I felt that this would not provide a good troubleshooting environment. We had used Blue Coat within our department with no reported problems of this nature, so we needed to have the systems under close to a full load. A compromise was reached by removing the subnets of the complainers from filtering.

The network guys had already opened up cases with Cisco and Blue Coat. Everything appeared to be normal. The configuration was acceptable to the support people. The CPU and RAM seemed fine.

I checked the antivirus appliance to make sure it wasn't running out of threads, but everything was well within spec there. Next, I checked the Blue Coat forums to see what other people had to say about this problem.

A quick check found that the most likely cause was mismatched speed or duplex issues on the switch. I called one of the network guys as 1:45 to ask him to check into that. I kept searching to get an idea of other things to try (and also establish some speed test baselines). A speed test reporting downloads of 800 kbps. Which is ludicrous when we have a 25 meg pipe.

We checked into the switch and found it wasn't quite as intelligent as we had expected. We didn't have the capability to hard code the connections to a specific speed and duplex value. We did however see the collision light was occurring on the connection to the core router. I should mention the switch is 10/100/1000 and the router interface is 100. We checked the router and saw the same errors there. The connection was already hardcoded to 100 Full so the network guys changed that to auto. That's the opposite of what you normally do when you have this problem. The port negotiated 100 Full and the errors went away.

I performed a few speed tests and found that web requests were benchmarked 10-100 times faster. The speed test now reported something crazy like 80 meg down (due to the antivirus or caching I suspect). But it is at least and apples to apples comparison with the 800 kb test.

So all is solved. The problem was not with the Blue Coat, but I did take a few body blows and get a black eye.

We got a call from the Director this week. It seems the new stationary had been ordered using the domain only. For example, example.com was used instead of www.example.com. (using example.com in place of my company domain name, obviously).

Currently example.com resolves to the firewall in the external DNS. I had just commented last week that we might want to change that. Most sites on the Internet, including this one, allow you to just type the domain name and you're taken to the website. But I didn't really want to fight any non-essential battles so I let it go.

So it became an issue when the communications department created new stationary without checking if the name they were using actually worked. Its not such a big deal externally. The DNS guy said its not kosher to have two A records. But after I pointed out that every other domain on the Internet (including one we owned) did it this way, he grudgingly agreed. That's when we hit the next hurtle. You see the Active Directory domain is example.com. Internally if you do a nslookup on the A records for example.com you get a list of the domain controller IP addresses. We haven't found a way around that problem yet.

At least I can laugh that such a common mistake continues to happen.