Social Implications of Keysigning
Raven & Jericho
Tue May 23 01:41:20 EDT 2006
The use of strong public encryption has always been popular among geeks. Perhaps the most commonly used and most beloved encryption for e-mail is Pretty Good Privacy (PGP); started as a free method for protecting emails or other sensitive information, later turned into a cornerstone for a large company. As PGP became more corporate, costly and used patented algorithms, another project, GnuPG, sprung up to continue to offer strong encryption to the masses.
One foundation of reliable encryption is trust. The use of encryption between two or more people relies on you being sure that the message you sent is properly encrypted to and able to be decrypted solely by the intended recipient. When using a friend’s GPG key, you must be sure that the key was created by and belongs solely to your friend. Otherwise, you may send mail that your friend cannot read (if they don’t have the key you encrypted to), or worse, mail that some other party can read (if that party does have the key you encrypted to).
Did you know that RFC 2606 provides for the Internet Assigned Numbers Authority (IANA) to reserve several top level domains, as well as three second level domains in order to provide a safe domain name? To avoid conflict and confusion the domains example.com, example.net and example.org are all reserved so that professionals can use them for private testing, examples in documentation, DNS experiments and other uses.
This is a good thing for IANA to do, and something that security researchers should be aware of. Currently, we see hundreds of disclosures each month use other “example” type domains, many of which point to real sites. This is a bad thing as it can cause a world of annoyance and potential harm to these sites. Think about hundreds of sites that mirror Bugtraq or Full-Disclosure, and all of the search engines, web bots, and spiders that follow all links without bias. Each time they encounter http://example.com/hi.txt, they try to follow it. For those who follow the guidelines in RFC 2606, this is acceptable and no one really gets harmed. For those using other domains, you may be causing additional traffic (often with exploit like code/requests) to sites that shouldn’t receive it, even if using 127.0.0.1 or other reserved internal IP addresses. OSVDB goes one step farther by using [target] and [attacker] to designate examples. This is done for consistency of course, and yes I realize some older entries don’t follow that guideline, but also on the off chance that some wiley hacker type doesn’t decide to screw with DNS servers. What happens when tomorrow, dozens of high traffic DNS servers start pointing example.com to [target].com?
In just the last couple of months, we see examples of the advertising site www.vuln.com, Site Services Inc.’s www.site.com, the non-existant host_evil.com, the broken web site of www.anysite.com, a possibly ironicly defaced web site of www.vulnerablesite.com, the adult content laden site www.XXX.com, the large corporate retail store www.target.com, and the domain squatted attacker.com are all used as example domains for exploits. Every day that a web spider or search engine goes crawling, odds are these sites get some odd traffic. If they run intrusion detection systems, i’d hate to be the one tasked to monitor them.
The most amusing of this list is probably victim.com which contains a quote and link to a published exploit in which a lack of following RFC 2606 may have lead to one person’s frustration, and this resulting site.
A Time to Patch III: Apple
Over the past several months, Security Fix published data showing how long it took Microsoft and Mozilla to issue updates for security flaws. Today, I’d like to present some data I compiled that looks at Apple’s performance on this front.
Here’s what I found: Over the past two years, after being notified about serious security flaws in its products, it took Apple about 91 days on average to issue patches to correct those vulnerabilities. I also found that almost without exception, open-source Linux vendors were months ahead of Apple in fixing the same flaws.
You can download a copy of the charts I put together either in HTML format or as a Microsoft Excel file. I spent a long time on this research, but that doesn’t mean it is free of typos and so forth. If you spot one, or a discrepancy in the data, please drop me line and I will update the data as necessary.
Another night of working on OSVDB, mainly focusing on vulnerability import and creating our entries to cover issues. Most nights end with between 25 and 50 new entries and a feeling of accomplishment. Well, other manglers can see the accomplishment if they check the back end, and that gives a little positive reinforcement. On really big days I just spam the status line to Jake and Sullo and demand instant gratification and the promise of booze to dull the pain.
Anyway, tonight was productive but no one but me and Speedbump will realize. I can thank IBM and a set of ridiculously large changelogs full of mind-numbing poorly written bug reports and excessive (apparent) duplication of entries. It started out with a simple bugtraq post about some vulnerabilities in IBM WebSphere Application Server. First off, I find it quite amusing that people are now taking credit for merely posting vulnerability information culled from another source.
Provided and/or discovered by:
Reported by the vendor
Reported by SnoB
If this type of activity deserved merit, VDBs like Secunia, CVE and OSVDB would be virtual gods of vulnerability disclosure. Second, he lists seven issues from a changelog that contains hundreds. If you go dig through the changelogs like the one for the Fix List for WebSphere Application Server Version 5.1.1, you may find more of interest. While browsing them, I noticed a fairly insignificant but ironic characteristic of the way IBM handles these disclosures. If you want to read the list of over five hundred entries and only pick out the security related ones, you can! Skim the list for any P##### number that doesn’t hyper-link to another document. 95% of the time, these are security related. So while IBM is not providing additional details about these issues (security through obscurity), they are making it easier to pick out which entries are of interest.
Oh yes, back to the exciting night life. After checking the latest list of changes as well as digging into some past fix lists, I ended up with around 75 more vulnerabilities, most of which are not in our database (or others). This list I extracted has some dupes in it, meaning the same issue affected multiple products or version lines. However, it is quite curious to see the same vulnerability patched half a dozen times over two years across many versions. Is IBM reintroducing the same vulnerability back into the code over and over? Or are they following the Oracle method of mitigation and not looking at the bigger picture and fixing similar vulnerabilities in the same code? Anyway, since I know I won’t get an answer to that, consider that it would take you twenty or more hours to read and digest a handful of these fix lists, and in doing so, you would likely find fifty or more vulnerabilities above and beyond what I found. The amount of information is overwhelming to say the least.