Re: Product Review - CORE Impact (I said something wrong about Nessus)

From: Ivan Arce (ivan.arceat_private)
Date: Wed Jul 09 2003 - 15:54:03 PDT

  • Next message: David Moisan: "Re: DSL modems used for pen-testing"

    Kurt Seifried wrote:
    >>On Tue, Jul 08, 2003 at 11:38:58PM -0700, Kurt Seifried wrote:
    >>
    >>>typically are just banner harvesting tools (i.e. Nessus) and not actually
    >>>"exploit the service, and run shell code on the remote end".
    >>
    >>I won't reply to the list, but this is a gross mis-statement.
    >>
    >>-- Renaud
    > 
    > 
    > I have to agree and I apologize, it was late and I couldn't think of another
    > example quickly. The basic issue however reamins that the majority of pen
    > testing tools do not actually break into the server, they typically harvest
    > a banner ("Sendmail 8.foo, you got bugs!") which can cuase them to spew if
    > you're like me and have Bind report binary junk data to version requests
    > (which causes a lot of pen testing tools to choke) or they execute part of
    > the attack (i.e. cause an error message, whatever). Nessus does have the
    > denial of service tests, however last I checked none of the tests will
    > actually give you a remote shell (although they could be could be modified
    > to do so but then you're back to basically writing all your exploits from
    > scratch).
    > 
    
    Having worked in the development team a vuln scanner in a previous life I
    concur that banner grabbing is just the simplest way of attempting to verify 
    the presence of a vulnerability and not a very accurate one. Nessus as well 
    as most vuln scanners do *much more* than just that and its not always easy 
    to correctly identify a vulnerability without doing some sort of 'active 
    testing' although not necessarily exploiting it to gain access to the host.
    
    CVE-1999-0493 "Solaris rpc.statd Call Relying vulnerability" is an example
    of the complexity involved in just *checking* for a vulnerability.
    In this case to remotely check for the vulnerability, rpc.statd must be
    fed with some specific data that overwrites internal structures, then
    it must be forced to interact with other RPC services on the target host
    and generally there will be no response to check for, so the tester needs
    to do something to verify sucess (write a file to the file system, send
    a packet back to the scanner, etc.), this is some sort of active testing or
    at least involves a 'degree of exploitation'. Still trying to actually
    exploit a vulnerability to gain access to the host and to do so in a
    reliable way that works with a wide range of OS versions, patchlevels and
    configuration settings *adds even more complexity* to the already complex 
    problem of testing for vulns. It does have some advantages tho.
    Namely, the ratio of false positives diminishes quickly and if the exploits
    are good enough the ratio of false negatives should decrease as well, or
    at least should mimic the *real* risk level of an attacker as capable as the
    developer of the exploit.
    
    
    -ivan
    
    
    ---------------------------------------------------------------------------
    The Lightning Console aggregates IDS events, correlates them with 
    vulnerability info, reduces false positives with the click of a button, anddistributes this information to hundreds of users.
    
    Visit Tenable Network Security at http://www.tenablesecurity.com to learn 
    more.
    ----------------------------------------------------------------------------
    



    This archive was generated by hypermail 2b30 : Wed Jul 09 2003 - 16:17:31 PDT