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).
Archive for February 2007
HP OpenView Network Node Manager Insecure Permissions Vulnerability
GFI Cyberattack Whitepaper
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.
SSL for Cox Webmail
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.”
Unfortunately SSL does nothing to keep you from being exploited if you haven’t patched. It does nothing to detect a keystroke logger on your computer that collects your passwords to financial websites.
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.
Notice of Change
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.
The Day the Internet Traffic Stood Still
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.
The DNS and The Stationary
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.
