> 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. I would not go as far as saying that it is a lie. It's just dubious and just gives the security auditor inadequate data during the audit process. > 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. > All security scanners and intrusion testing software should actually exploit the vulnerability that they are testing for to determine if it is actually vulnerable. Audit reports should not be generated using security audit tools that only check for vulnerabilities based on the version number and patch levels but instead use this information generated by tools like ISS, strobe, COPS, NetRanger, etc. as a guideline as to what resources need further testing and investigation. The reason for this is that there may be some security program that might actually prevent vulnerability exploitation from happening. A good example of such security program is SeOS Access Control for UNIX. This product is used by many big companies to protect specified resources even if UNIX permissions allow access and it can also protect the resources from root. With this in mind one can use a security auditing tool to check for the vulnerability by relying upon the version number of the operating system and the patch level it has and it could potentially identify resources as being vulnerable even if in fact the resources have an added layer of protection that the security scanner does not recognize because it is not part of the native operating system's security. For more information about SeOS Access Control and SECURED check out http://www.memco.com/ there is also a product that prevents stack overflow exploitation on several UNIX platforms. > 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? Perhaps actually exploiting the bug would tell you if the system is vulnerable. == -=-=-=-=-=-=-=-=-=-=-=-=-=- Anthony C. Eufemio anthony_eufemioat_private -=-=-=-=-=-=-=-=-=-=-=-=-=- _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:33:47 PDT