Who Do You Trust?

We place a large amount of trust in big organisations when we browse to their sites - banks, insurance companies, telecoms + technology companies, etc. We assume that they're doing the right thing and have appropriate security measures in place to prevent breaches and ensure the integrity of their sites.

Two recent episodes have taken place that highlight the problems are the whitepages.com.au banner ad injection and the Trend Micro site compromise on one of their Japanese sites.

Now both of these exploits highlight that large organisations have SNAFU moments too. Unfortunately given their market position, and in Trend's case their security reputation, we can tend to trust them too much.

My take on both these exploits is to:

• regularly review dynamic code injection into your sites (e.g. banner ads); get rid of them where possible and try to restrict the type of content generated.
• perform regular integrity checks on your sites; create MD5 or SHA1 checksums of your site prior to deployment, then check these checksums regularly. Shut down the site if the checksums change.
• make sure you have malware protection software and it's up to date; nothing new in this one really.
• investigate browser add-ons to help prevent malware infection; IE7Pro for Internet Explorer is good, as is NoScript for Firefox

Remember, ultimately you are responsible for the health of your systems. If Trend Micro are able to be compromised, so are you. Don't outsource your security responsibilities. Have a healthy sense of paranoia and apply a "secure by default" mindset when setting up your Web sites and also your Web browser.

The Dangers Of a Public Display Terminal System

So I'm at Sydney Domestic Airport train station waiting for a train to Circular Quay when I noticed that one of the displays was waiting patiently at a Windows 95-like login screen.

During my wait, a tech logged into the system (which was actually a Windows NT4 Workstation) as a domain administrator and proceeded to fix the workstation.

At one point during the remediation, the tech had entered the domain administrator's password in clear text! (The AutoAdminLogon stage from memory) In addition to this, the tech was browsing the network list and accessing various network shares to resolve the problem at hand.

Thankfully this was on only one set of displays and not all the displays in the station, so at least there's some redundancy in the displays. Unfortunately I have no idea of the technical skills nor the ethics of the people around me who were amused by this diversion.

So now I have the domain administrator's password for one of CityRail's domains, a list of domains/workgroups in their network and a list of PCs in one of their domains.

This information was reported to station staff at Circular Quay, but they weren't really interested, didn't see it as a security problem and said that their IT staff knew what they were doing. A quick browse of their Web site gave a 1800 number, which was answered by a staff member who did understand the security implications, so hopefully the domain administrator password has been changed

A large scale deployment of PDTs like this should be deployed using an automated deployment system (which is probably done in CityRail's case) and any remediation should be performed by a rebuild from either network or local unattended install media (which doesn't seem to be the case here). At the very least, the public displays should be disabled to prevent sensitive information leakage.

If you have PDTs in place, please make sure you have some good policies and procedures in place to prevent this embarrassing type of situation.

Disable Network Authentication Credentials Storage on Windows Desktops

It seems like I'm having to debug authentication-related problems several times a week, all with different symptoms and each with different errors in the Event Log. Today was the last straw.

I've decided to disable this poorly constructed component via Group Policy. Here's how I did it. I opened up Group Policy Management Console and created a new Group Policy Object.

Computer Configuration > Software Settings > Windows Settings > Security Settings > Local Policies > Security Options

Find the entry named "Network access: Do not allow storage of credentials or .NET Passports for network authentication". Enable this.

Assign the GPO to the appropriate OU and restrict using Security Groups as appropriate. I'm scratching my head wondering why I didn't do this a long time ago...

Understanding Group Policy

I had a client that wanted to add network printers and set a default printer on a set of computers regardless of who logged into the computer.
I found out that Group Policy has a Loopback mode that allows User Configuration to either be Merged or Replaced. This is done by enabling Loopback mode in the Computer Configuration and selecting Replace or Merge mode. The User Configuration settings in the same GPO are then applied based on the computer, rather than the user.
I then had some problems applying the GPO to a set of computers. If I only included the necessary computers in Security Filtering, the user was then denied access to the User Configuration settings. If I added Authenticated Users to the Security Filtering, the GPO was applied to everyone on all computers!
I then worked out that I misunderstood the membership of Authenticated Users. This contains all the computer accounts as well as all users.
I resolved the GPO problem by including the set of computers on which the script needed to run and also including the Domain Users group. The GPO was then only applied on the required set of computers.
So, Authenticated Users is really authenticated users and computers - a pity you can't easily see the membership of this group!

Windows XP Netlogon 5719 Errors

Had a new PC to remotely install at a client site. The site is running Windows Server 2003 Domain Controllers and makes use of GPOs to manage the settings and software installation. I added the PC to the domain and placed it in the correct OU for the necessary software installation and rebooted. I was very surprised to not see any files being shifted from the server to the PC. Logged in remotely as Administrator and found that the User policies had been applied, but not the Computer policies.
A look through the Event Log found the dreaded Netlogon 5719 error - "no domain controller could be found". Tried locking down the network card to use 100Mbps/Full Duplex. No joy. Tried setting ExpectedDialupDelay in HKLM\System\CurrentControlSet\Services\Netlogon\Parameters. Still no joy.

The network card was an SiS 900 integrated NIC and an old driver was being used. Upgraded to the latest version of the driver. Still no joy. Right. Let off some steam by vigorously chopping some wood that really, really needed it. Still didn't help my GPO problem, but made a big difference to my mood.

I then decided to see what drivers were available to me for this network card. Found that there was a signed Microsoft driver for the SiS 900, so I decided to try this before having to go onsite with a new network card. Installed the driver, rebooted the system and noticed a flurry of file transfers from the server to the PC. Yay!

I shall now make sure that if I see the problem in the future to see if there's a signed Microsoft driver for the network card before getting hot under the collar (especially as the amount of wood to chop up is getting lower!).