At 10:06 AM 2/9/99 -0500, der Mouse wrote: >>> [...] the old ioslogon bug [...ISS didn't find it...] > >> [...response from someone who writes as if on behalf of ISS's makers; >> I can't recall whether mindspring.com is the ISS people or not...] > >If ISS claims to check for the ioslogon bug, but actually checks (by >whatever means) for software versions known to have that bug, the claim >is a lie. If you claim to check for the ioslogon bug, then that's what >you should do: try to exploit it and see if it works. Who knows, maybe >there's another vulnerable version out there, or perhaps some >supposedly vulnerable versions don't happen to be vulnerable after all. [Noting up-front that I'm not an ISS apologist - I prefer CyberCop. ;] One of the hard lessons I learned long ago when writing vulnerability testing code is that exercising exploit methods can do more harm than good. A crash or a system lockup may be the result, even though the code was written to avoid such a thing. In other words, stuff can and often does happen. :-} Checking for software versions that are known to be vulnerable to some type of attack without actually exercising the associated exploit is a legitimate and non-destructive test method. A subsequent marketroid claim is also legitimate, IMHO, provided the test report output says something to the effect of "...this system may be vulnerable to the XYZ attack...". I would prefer that the word "may" be emphasized in the report, but that's not always the case. In the end, no commercial vulnerability testing tool can or should substitute for good old-fashioned human analysis of the post-test report. >I can't remember offhand what this bug does. If it's a "hang your >router" sort of thing, you may want to have *two* tests, potentially >independently controllable, "check for ioslogon bug (dangerous, may >crash your router)" and "check for software versions known to have >ioslogon bug (safe, requires SNMP)". But claiming to check for the bug >when actually just checking the software version (via a means which can >be disabled without closing the bug, no less) is like a spamfighter >saying "your SMTP daemon claims to be an old Sun sendmail, therefore >you're an open relay": it's checking for the wrong thing > >> OK, so maybe you can explain just exactly how we're supposed to find >> out whether it is vulnerable if it won't talk to us? > >Surely this is a bit of a no-brainer - why not just try the exploit and >see if it works? That's certainly what an attacker will do. Some exploit methods can be exercised safely in a vulnerability testing tool and some can't. For instance, I've found that the old sendmail bounce attack (password file grab) can be done pretty safely, whereas checking for open X displays can crash or lock up some types of X Terminals. While I agree an attacker will most certainly attempt a full-blown exploit, the attacker has no liability in the corporate sense. A commercial testing tool like ISS or CyberCop does have such a liability. ISS and NAI have relatively deep pockets, and must exercise due diligence and care in the methods used by their products to test for vulnerabilities. No one would buy their products if they crashed or locked up systems on a regular basis. Crackers have shallow pockets (or none at all ;), and no such concerns for diligence or care. > der Mouse > > mouseat_private > 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B Best regards, Randy (speaking only for myself) ----- Randy Taylor Senior Infosec Engineer SAIC Center for Information Security Technology email: rtaylorat_private joseph.r.taylorat_private phone: 410-872-4883 fax: 410-872-0107
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:33:43 PDT