September 8, 2008 by dbarker.

A client of mine contacted me about a recent qualys vulnerability scan where they listed, UDP constant IP id field fingerprint vulnerability.

From the report they list the following explanation.

“Normally, the IP Identification field is intended to be a reasonably unique value, and is used to reconstruct fragmented packets. It has been reported that in some versions of the Linux kernel IP stack implementation as well as other operating systems, UDP packets are transmitted with a constant IP Identification field of 0.
IMPACT:
By exploiting this vulnerability, a malicious user can discover the operating system and approximate kernel version of the host. This information can then be used in further attacks against the host.”

Hmm.. how is this a vulnerability? The same scan shows OS fingerprint identification was successful for other TCP services. NMAP reveals that these tcp ports also return all zeros in the IP ID field. The OS is identified as linux in TCP scans, yet Qualys doesn’t classify this as a vulnerability.

Is it a vulnerability that an attacker may know that you’re running linux? This is information. I would define an actual vulnerability as something that can be exploited, i.e. buffer overflow, race conditions, man-in-the-middle, SQL injection.

This is information. Something that you can use to find vulnerabilities. In fact if the ip id field of all udp non-fragmented packets is always 0 then this is also information that can be used to secure the system. An IDS signature could be written that alert me when there are non-zero values in this field. This could be a sign that someone is using the ip id field to tunnel information, i.e. a covert channel. Now the vulnerabilty is a security feature.

Qualys fix your scan report, reclasify this as information, just like the OS identification TCP fingerprinting portion of your report, cause that’s all this is, information that an attacker already knows.

Posted in Security | No Comments »

September 5, 2008 by dbarker.

ssh is an evil of network security. I’m currently onsite at a customer that allows ssh outbound. Why? I’m not sure. But this is not the first customer that I’ve been to that did. Like many others they have sophisticated anti-spam, DLP, content filtering, proxies, firewalls, and ips in place. And then they screw the whole thing up with ssh.

Never allow this.

I’m currently circumventing their anti-spam, DLP, content filtering, proxies, firewalls, and ips by forwarding my traffic through an ssh tunnel I created to my home network. I’m using portable apps to do it, so there should be nothing left behind after I leave. And although my intent is not malicious it shouldn’t be possible. I’ve even got xwindows running from my ubuntu box. So the tunnel runs bi-directional. I could make it permanent. Earlier I was running metasploit through it. This is ridiculous.

Allowing ssh is too trusting. The should just eliminate the anti-spam, DLP, content filtering, proxies, firewalls, and ips and save their money.

Posted in Security | No Comments »

January 21, 2008 by dbarker.

PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed, or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply.

This is an interested tidbit. Most banks and financial institutions don’t realize that they fall under PCI DSS requirements. I was doing an audit for a credit union and this came up on a discussion. They issue credit cards, and take credit card payments, but these transactions are handled by a third party, passing the PCI DSS requirements onto the third party. However, the ATMs they have take credit cards and debit cards, and the Primary Account Number (PAN) (the credit card number) is transmitted and stored in their computers. Now they fall into PCI DSS requirements and subsequently PCI audits will be necessary.

Posted in Security | No Comments »