Threat Level: green Handler on Duty: Bojan Zdrnja

SANS ISC InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Tip of the Day: Protect the Single Points of Compromise

Published: 2006-08-25
Last Updated: 2006-08-25 20:03:14 UTC
by John Bambenek (Version: 1)
0 comment(s)
Automation is a great thing in large environments. If an organization has to maintain thousands of laptops roving around the country, it either needs to hire lots of traveling IT guys, or use automated tools to handle patching, software loads, and installation. Manual processes on a large scale almost ensure there will be patches missed and systems compromised.

However, tools that automate installation, patching, and software installation comes with a risk. Namely, the machine or machines that control software being pushed out to machines becomes the single point of compromise in an environment.

As an example, imagine an RIS, Kickstart, Jumpstart, or other automated install server. If someone compromised this server and added a small package that included a rootkit, you would be quietly putting compromised machines on a network. For machines that push out patches or software, it wouldn't take much to quietly push out a trojan the next time Patch Tuesday comes around.

It would probably have to be an inside job, but most information intrustions are inside jobs. In the case of corporate sabotage or espionage, custom-written malware would be very likely to pass by virus scanners and spyware scanners who have to react to new malware being sent to them. If no one has ever seen it before, odds are it isn't detected.

The point? By all means, keep using automation to keep control of workstations and laptops (or even servers). However, beware that the systems you use for that automation are a single point of compromise and need to be excessively hardened and monitored for even the slightest bit of tampering. Examing and auditing what those machines put out into your environment is a must.

--
John Bambenek
bambenek /at/ gmail /dot/ com
Keywords: ToD
0 comment(s)

Printer Hacking for Fun and Profit

Published: 2006-08-25
Last Updated: 2006-08-25 18:06:43 UTC
by John Bambenek (Version: 1)
0 comment(s)
Nate Johnson and Sean Krulewitch of Indiana University discovered two vulnerabilities with the Fjui Xerox Printing System.  In the United States this effects Dell branded printers (specifically the color laser 3100 and 5100).  There are Japanese printers that are affected but I don't read Japanese and I'm not sure that information has gone public on the Japanese CERT lists (if someone sees it, let me know).  Apparently one of these Japanese printers doesn't release firmware updates and customers have to pay maintenance for a technician to come out and update the firmware.

FTP Bounce Attack (CVE-2006-2112):

If FTP printing is enabled (and reportedly is by default), a vulnerability exists in the FTP PORT command that lets malicious users establish connections to ports on another system.  This would allow anonymous scanning by a hacker for reconnaissance purposes.

HTTP authentication bypass (CVE-2006-2113):

If the printer allows for HTTP access to modify system settings, a vulnerability exists to bypass the administrator password and would allow a malicious user to gain complete control of the printer.  This would include loading new and potentially malicious firmware.  (Think a small linux distro with hacking tools and SSH access.)

Remediation:

First, if you aren't using FTP printing or HTTP-based printer management, those should be turned off anyway.  If you must run them, apply vendor patches which in the case of Dell, are already available.

--
John Bambenek
bambenek /at/ gmail /dot/ com
Keywords:
0 comment(s)

Tip of the day: using host based firewall on Windows XP SP2

Published: 2006-08-25
Last Updated: 2006-08-25 07:50:18 UTC
by Bojan Zdrnja (Version: 3)
0 comment(s)
I'm sure almost everyone knows about the host based firewall that was added to Windows XP with the Service Pack 2. Although Windows XP had a possibility of filtering network traffic before the SP2 was released, it was rarely used as it required use of IPsec policies.
UPDATE: Small correction - Windows XP (before SP2), as well as Windows 2000, had very basic TCP/IP filtering options that did not directly depend on IPsec policies (although you were able to layer rules by using TCP/IP filtering with IPsec filters). However, Windows 2000 and XP (before SP2) lacked quite a bit on features - the biggest one is scoping of incoming traffic. This means that accepted traffic to allowed port(s) was able to originate from *any* IPv4 address. ICF (Internet Connection Firewall) in Windows XP pre SP2 also wasn't automatically enabled. This diary therefore explains how to use Windows XP SP2 firewall only.

With the release of SP2, Microsoft also made a pretty brave step (let's stay on the firewall in this diary) the firewall was turned on by default and this inevitably caused some applications to break.

The idea of today's tip of the day is to encourage you to use the host based firewall in your corporations. I'm explicitly mentioning corporations as I noticed that in a lot of cases administrators in corporations simply turn off the host based firewall provided with SP2 because it prevents them from managing the machine remotely.

The host based firewall that comes with Windows XP SP2 is in no way perfect, but it can offer an additional layer of protection (and we all know that defense in depth is the only way to get more secure) that can help you a lot sometimes.
For example, take a look at the last month patch bundle Microsoft released. The most critical and remotely exploitable vulnerability was in the Server service (MS06-040).
Windows XP SP2 machines which were just running the host based firewall in the default configuration were automatically protected from this. Of course, these machines should still be patched (as soon as possible), but this at least gives some breathing space.

One thing that you have to be aware of is that the host based firewall that comes with Windows XP SP2 filters only inbound traffic. While this isn't as good as some commercial firewalls, it still offers decent nice protection. I won't go into why Microsoft didn't filter outbound traffic as well, but the bottom line is that if a machine gets infected with a malware, it can easily turn the firewall off (or add itself on the list of allowed programs, as many malware does today), so if you look at it this way, outbound traffic filtering isn't that important. The firewall in Windows Vista is much more powerful and does allow outbound traffic filtering.

Letting the good guys in

The biggest problem with the host based firewall not being used in corporations today is that, besides bad traffic, it also drops legitimate inbound traffic.
Typically administrators need access to IPC in order to remotely manage your machine, or they use remote desktop services to perform actions on client machines. The host based firewall effectively stops this and administrators have to rely to group policies in order to change configuration on client machines. As group policies are read only when machine is booted (with Windows XP, this is different with Vista) and remote users typically put their machines in standby, you can see why administrators don't like this.
UPDATE: Thanks to reader Chris for sending us some information about this. Group policies on Windows 2000, XP and 2003 machines will update every 90 (+30) minutes in a background group policy refresh interval. So, in this case, an administrator will still have to wait some time for  new group policies to apply, but it's not as bad as I thought it is.

So, in order to still have some security, I typically recommend that administrators just put holes on their client machines which will allow connection from their designated management machine or network. This way the host based firewall will still protect the machine from everything (and everyone) else and the administrator can freely manage the machine remotely.

Adding such a rule is pretty easy. On a client machine you can add this through the Windows firewall control applet for a service or port you want to allow access to and select the appropriate scope. For example, you can allow access to port 445 just to IP address 10.0.0.10, which is your management server.

Using profiles

Fellow handler Swa (who else?) noted that the bad guys might know this (for example, a disgruntled employee in your company) and then wait at local Starbucks where your employees hang, get the internal IP address for himself and attack the target machine.

Windows actually comes with a pretty nice feature for different firewall profiles. In GPOs, an administrator can define different rules for the "Domain Profile" and different rules for the "Standard Profile".
Windows has a NLA (Network Location Awareness) service which determines where the machine is, and applies appropriate policy for the host based firewall:



Now, NLA will use the connection-specific DNS suffix to determine where your machine is. If it matches your domain, the Domain Profile will be used. Otherwise, the Standard Profile is used (you can check the connection-specific DNS suffix with the ipconfig command). So all you have to do now is setup rules you need for administration in the Domain profile, while completely closing machine in the Standard profile.

A bad guy could still spoof an Access point on a wireless network, for example, and have his own DHCP server to issue fake information to you, but this indeed raises the bar a bit.

Command line kung-fu

Seeing that command line kung-fu is very popular with our readers, I'd just like to end this tip of the day with some nice command line options you can use to configure the host based firewall on Windows XP SP2.

You have full firewall configuration options through the netsh command interface. This is very useful when you want to create a batch file which will open or close some ports on your machine.
I've used this to open the host based firewall to only one IP, so the anti-virus product we had was able to communicate with the client machines (poll their status, tell them to update definitions, etc).

So, let's say that you want to open port 10000 to the IP address 10.0.0.10, where your AV server is. This can be easily done with the following command line:

netsh firewall add portopening TCP 10000 Anti-Virus ENABLE CUSTOM 10.0.0.10

You can script this easily to do whatever you want. Just be aware of the limitation you can't have port ranges so you'll have to open every port separately, in case you need to open more ports.


If you have some neat tricks with the Windows XP SP2 host based firewall let us know, and I'll update the diary with the best tips we receive.
Keywords: ToD
0 comment(s)
Diary Archives