Today Jeremiah Grossman posted that the PCI-DSS 1.1 uses the OWASP Top 10 from 2004. This was picked up by Nathan McFeters over on the Zero Day blog... I wasn't aware that this was really a news worthy issue. There are plenty of valid reasons that PCI-DSS should be updated to make use of OWASP Top 10 2007, both Grossman and McFeters point them out. That being said, there are reasons why they do use the Top 10 from 2004.

First of all PCI-DSS is a standard... You can't develop a standard if you are changing constantly. PCI-DSS 1.1 was released in September 2006... The current version of the OWASP Top 10 at the time was the 2004 version. So it only makes sense to include it... I'm willing to bet that going forward we'll see the 2007 version used (at least this is something that nCircle has assumed internally for some time now and expects to see in the September update to PCI-DSS (I do believe they are looking at a 2-year update cycle)). After all, OWASP Top 10 is one of the important community driven standards that PCI-DSS looks to for direction and guidance. So yes the information is outdated today but it was the latest available information at the time that PCI-DSS 1.1 was written.

Nathan McFeters also makes the comment that this might mean that no standard (i.e. ScanlessPCI) is better... This is ridiculous... I think it's generally accepted that PCI isn't the be-all and end-all for web application security. The goal is to get people thinking about security and moving towards secure coding practices. It's a small start but everything needs a base, and something is better than nothing. I've accepted that I really can't trust any website to be secure... but what I can do is, hopefully, count on them work towards being "more secure". PCI ensures that and in the end I think that's all it's supposed to do.

Vendors, consultants, and everyone in between, should always been informing their customers of the latest and greatest (The 2007 version in this case)... nCircle does this and I would assume that everyone else does the same. As well, as I partially mentioned earlier, this is a standard... maintaining the standard with expected updates is the only way that anyone is going to accept this. It's a different realm but think of Microsoft and their monthly patch cycle. They moved to regular, expected updates because that's what people wanted and what people could work with. PCI has to follow the same idea... something that's maintainable, regularly updated but not cutting edge and constantly changing. This is what's going to lead to universal adoption and that is going to greatly benefit the security community. The groundwork that's being laid is about introducing security... not leading security.

You can walk away from this post thinking what you want... but keep this in mind; PCI-DSS is about global adoption first and protecting cardholder data second.

So there's been quite a bit of press around Dan Kaminsky's DNS vuln today and the associated patches. I even made comments earlier today about the severity of it. Now, however, I'm starting to reconsider. I'm not sure that this is the horror scenario that the press is making it out to be... and I'm not the only one that feels this way.

Now Dan is a bright guy... there's no doubt about that... I saw him talk at SecTOR (I even had the opportunity to have a couple of drinks with him) and I'm really looking forward to his talk at BlackHat, but I just don't see the seriousness here.

The patch changes the number of potential source ports (from 2500 to 16383 (assuming that MaxUserPort is not set)). It also makes it so the Transaction ID (2^16) and the Souce Port *MUST* match. That takes us from 163,840,000 combinations to 1,073,676,288 combinations. I realize that the second number is a good deal bigger (and could potentially be quite a bit larger (if MaxUserPort = 65535 we'd be looking at 4,227,792,896 combinations) but does it really matter that much? This is spoofing, which to me implies that we're not sniffing the traffic and knowledgable of the Transaction ID and Source Port (if that were the case the randomness wouldn't amtter). This means we're talking about randomly submitting data and essentially flooding out valid responses, at least that's my assumption... maybe Dan's presentation will cover something else and this will end up being really cool. However, sticking with the random attempts to generate valid data, even before this patch, 163,840,000 is a lot of potential combinations to have to attempt. It seems to me that the likelihood of this being a problem is fairly minimal... almost to the point of being non-existent. I guess we'll have to wait for BlackHat to see for sure.

As a second thought, everything addresses UDP source ports... I wonder if the same issue was fixed, overlooked or not-affected with TCP. Anyone have any thoughts on this?

Another note, SANS ISC has a post saying that a GSEC Student found this 3 years ago. This is incorrect. If you look at the DNS Client it increments the port for each subsequent query.

Example:

279	 27.184611	192.168.218.100	192.168.218.2	DNS	Standard query A computerdefense.org  

User Datagram Protocol, Src Port: 10044 (10044), Dst Port: domain (53)

    Source port: 10044 (10044)

    Destination port: domain (53)

    Length: 45

    Checksum: 0x1547 [correct]

Domain Name System (query)

    Transaction ID: 0x0002


300	 29.536560	192.168.218.100	192.168.218.2	DNS	Standard query A ncircle.com 

User Datagram Protocol, Src Port: 10045 (10045), Dst Port: domain (53)

    Source port: 10045 (10045)

    Destination port: domain (53)

    Length: 37

    Checksum: 0xe304 [correct]

Domain Name System (query)

    Transaction ID: 0x0003