Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Nessus-Users
[Top] [All Lists]

RE: Pen testing questions

Subject: RE: Pen testing questions
Date: Fri, 19 Nov 2004 12:44:06 -0800
Those results could be expected if you were using 'Safe Scan' options. 
 
With any vulnerability scan process you are going to have a number of
returns that have to be validated by the system owner or you as the
security analyst.  Specifically, with Safe Scans, you are only looking
for potential indicators of a vulnerability without running scenarios
that may explicitly trigger the vulnerability.
 
In any case, if you are sure of the configuration (have touched the box,
know it's configuration) then you can accept these as false positives.
If you are not sure of the configuration (SA say's he patched the box,
but didn't reboot, fw changes may allow this, etc...) then you need to
take the next step and validate the findings.
 
 

        -----Original Message-----
        From: nessus-bounces@list.nessus.org
[mailto:nessus-bounces@list.nessus.org] On Behalf Of Rob Notaro
        Sent: Friday, November 19, 2004 12:00 PM
        To: nessus@list.nessus.org
        Subject: Pen testing questions
        
        

        I recently pen tested a domain I oversee and came across the
following holes that were puzzlers.

         

        snmp (161/tcp) High It was possible to

        crash either the remote host or the firewall

        in between us and the remote host by sending

        an UDP packet of null size going to port 161 (snmp)

        This flaw may allow an attacker to shut down

        your network.

         

        CVE : CVE-2000-0221

        BID : 1009

         

         

        My gear is behind a Cisco router and PIX not Nortel as the
Bugtraq ID suggests.  I'm also blocking all SNMP traffic at the router
and firewall so I'm not sure why this went off.

         

        http (80/tcp) High It was possible to make IIS use 100% of the
CPU by

        sending it malformed extension data in the URL

        requested, preventing him to serve web pages

        to legitimate clients.

        Solution : Microsoft has made patches available at :

        - For Internet Information Server 4.0:

        http://www.microsoft.com/Downloads/Release.asp?ReleaseID=20906

        - For Internet Information Server 5.0:

        http://www.microsoft.com/Downloads/Release.asp?ReleaseID=20904

        Risk factor : High

        CVE : CVE-2000-

         

         

         

        Already have SP3 on Win2k which negates this update. 

         

        general/tcp High It was possible to crash the remote

        machine by flooding it with ICMP type 9 packets.

        A cracker may use this attack to make this

        host crash continuously, preventing you

        from working properly.

        Solution : upgrade your Windows 9x operating system or change
it.

        Reference : http://support.microsoft.com/default.aspx?scid=KB

        en-us

        q216141

         

        and

         

        http (80/tcp) High The remote web server dies when an URL
consisting of a

        long invalid string of % is sent.

        A cracker may use this flaw to make your server crash
continually.

        Solution : upgrade your server or firewall it.

        Risk factor : High

         

        Running Windows 2000 server with latest patches on this machine.

         

         

        smtp (25/tcp) High It was possible to perform

        a denial of service against the remote

        Interscan SMTP server by sending it a special long HELO command.

        This problem allows an attacker to prevent

        your Interscan SMTP server from handling requests.

        Solution : contact your vendor for a patch.

        Risk factor : High

        CVE : CAN-1999-1529

        BID : 787

         

         

        Exchange 2003 on Windows 2000 with latest patches.  

         

        general/udp High It was possible

        to make the remote server crash

        using the 'bonk' attack.

        An attacker may use this flaw

        shut down this server, thus

        preventing your network from

        working properly.

        Solution : contact your operating

        system vendor for a patch.

        Risk factor : High

        CVE : CAN-1999-0258

         

         

        Is this a false positive?  Fully patches Win2K server.

         

         

         

        Confidentiality Disclosure:  The information contained in this
electronic mail transmission is confidential, and is intended only for
the stated entity or individual recipient of the transmission.  If you
are not the intended recipient, you are hereby notified that any review,
disclosure, copying, distribution, or reliance upon the content of this
communication is strictly prohibited.  If you have received this
electronic mail transmission in error, please reply to the sender, and
delete this message from your in-box and Internet server.
        

_______________________________________________
Nessus mailing list
Nessus@list.nessus.org
http://mail.nessus.org/mailman/listinfo/nessus
<Prev in Thread] Current Thread [Next in Thread>