From: Palmer, Paul (ISSAtlanta) >When we write a new signature to detect attempts to >exploit a vulnerability, the actual exploit tools do >not exist yet or are unavailable to us. In some cases >they evolve rapidly after we release our updates. So >sometimes it is difficult to predict all of the >signatures a specific exploit tool will trigger.
There are essentially three phases to an exploit: 1. pre-vuln 2. post-vuln/pre-exploit 3. post-exploit RealSecure security content is written by our X-Force research team (the same team that researches vulns, such as the latest Sendmail bug). Even if they don't know specific vulnerabilities in products, they often have a good idea where typical vulnerabilities might be found -- and they write checks for them. HTTP_URL_Name_Very_Long was written 5 years ago on the assumption that we will continually find problems in web servers that will be exploited by anomalously long URLs, such as in the WebDav_BO which needed a URL 64-kbytes in length. In other words, RealSecure has a lot of "signatures" (really "protocol-anomaly checks") that are specifically written to detect unknown vulnerabilities. A lot of the really important vulnerabilities in the last year have been detectable with no product updates. There are checks sitting dormant in RealSecure that to my knowledge have never fired, but which I predict will eventually match some new vuln someday. After a vuln is published, we write checks based upon the SPECIFIC vulnerability information. The check for HTTP_URL_Name_Very_Long could trigger on lots of things potentially, customers would prefer to have something that precisely narrows down on the exact problem -- the WebDav BO. Therefore, we have written a check that closely matches the "vuln": the existance of WebDav in the request (either a WebDav method like SEARCH or the "Translate: f" field) and a URL name longer than 64k. Note that since this matches the "vuln", any and ALL exploits will also match this criteria. This means we can match the exploits to the correct vuln without yet having seen the exploit. Eventually, somebody is going to write a worm based on WebDav vuln, and we are then going to update our product with a "pattern-match signature" based upon that worm. In some cases, like CodeRed, we had the basic "vuln" check and multiple "pattern-match" signatures for the various CodeRed variants. In practice, most of the value you get from RealSecure comes from the "post-vuln, pre-exploit" checks. While we have the best track record of any product of catching new vulns before they appear (such as in the WebDav case), I don't want to promise that it's a magic pill that always gets the hacker. On the other hand, most of the content in each XPU comes from checks we write based on the "vuln" written before exploits are known. We rarely write the classic "signature" based upon the actual exploit -- usually just in the case of worms. A good example of this is Slammer. Back before the vuln was known, we wouldn't have detected it. However, we released a check for the "SSRP overflow" right after the vulnerability appeared. Thus, 5 months later when the worm hit, we knew immediately what the problem was. We then updated RealSecure to have a separate signature for "Slammer". In that case, even though both the "Slammer" and the "SSRP Overflow" checks trigger, the "Slammer" automatically supresses "SSRP Overflow". However, in the case of WebDav, we aren't as confident with the supression -- which is why the first XPU came out without the supression logic until we could see where hackers were going with the exploits.
<<winmail.dat>>
