The limitations of reactive patching
We're all aware of the huge numbers of patches that are being issued to fix security flaws, but these patches are invariably developed as a response to a vulnerability that's been discovered by a researcher or exploited by attackers. We see very little proactive patching based on generic issues or vulnerabilities that are known to affect other vendors' products. In short, vendors do not look beyond their own implementation when it comes to patching flaws and as a result, the products have avoidable vulnerabilities.
NTA has found various VPN IPsec flaws in the past and in our experience, the best example of reactive patching seen is the username enumeration issue; it's been identified and fixed in four implementations and has been identified but not fixed in two more. Preventing username enumeration by not giving different authentication results based on the validity of the username is a well-known security concept that was first detailed in Morris' Password Security Paper in 1979, in which he wrote:
"It is poor design to write the login command in such a way that it tells an interloper when he has typed in a invalid user name. The response to an invalid name should be identical to that for a valid name."
It was therefore surprising that NTA found this vulnerability in Check Point's IPsec implementation in 2003, almost twenty five years after the paper that had warned against it. However, even more surprising was the fact that we also found the exact same vulnerability in Cisco's and Juniper's implementations in 2005 and Symantec's in 2007. One would have expected that given both the existing best-practice laid out in the paper, plus the fact that this vulnerability had been found, patched and reported in their competitor's products would have led the other vendors to test their own products for this flaw. What's more, NTA's open source ike-scan tool can easily test for this issue and details of how the various vulnerable products were tested were given in the advisories published by NTA. What is perhaps even more shocking is that we know of two other products that are also vulnerable to this issue but have not been patched, one of which is still vulnerable three years after the vendor was first informed. We suspect that there are also other products out there that we haven't tested that are also vulnerable to this issue.
This is just one example of a multi-vendor issue and it's certainly not the only one. This raises the question: why do vendors not bother to investigate these known issues? Despite the fact that vendors regularly claim to be serious about security, it's difficult not to be cynical and dismiss this as mere lip service when such failures are discovered.
Perhaps there is a need for independent testing of vendors' products for this sort of known security risk. It certainly seems that we cannot rely on the vendors to do it themselves.