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: TCP sequence number

Subject: Re: TCP sequence number
Date: Tue, 18 Oct 2005 10:05:56 -0700 (PDT)


--- David Frechette <frechette_mail@yahoo.com> wrote:

Hello,

Recently I'm receiving the following 2 notifications
in the report of a single host:

12213:
"The remote host might be vulnerable to a sequence
number approximation bug, which may allow an attacker
to send spoofed RST packets to the remote host and
close established connections."

4259:
"The TCP initial sequence number of the remote host
are incremented by random positive values.
Good!"

IMHO, these notifications are contradictory. I've
rescanned the system multiple times, but these 2
notification keep showing up. Is there an explanation
for this?

Yes.  Read the cross-reference the first one mentions.  The latter
purely relates to how the ISN is calculated and if it could be
guessed.  If it could, then one could perform a blind spoof attack
to take advantage of IP-level access controls (e.g. a service
relying upon host.allow entries).  The prior refers to the ability
to send an RST packet to an established TCP connection because of
how implementations deal with window sizes and allowed ranges of
RST values.  This mainly affects long-lived services, such as BGP,
that maintain a long TCP connection and suffer from having it drop.

Is the nmap plugin (14259 btw) statement good?  If you don't know
what ISN calculations are and the difference between that and the
12213 plugin, then no; it requires a priori information.  Once you
understand ISNs and what the output is stating, then IMHO, it's a
good statement.

12213 reference:
http://www.securityfocus.com/bid/10183/solution

ISN reference:
http://www.faqs.org/rfcs/rfc1948.html

Thanks in advance,

Hope this helped and that I wasn't being condescending,

Jon



        
                
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com
_______________________________________________
Nessus mailing list
Nessus@list.nessus.org
http://mail.nessus.org/mailman/listinfo/nessus

<Prev in Thread] Current Thread [Next in Thread>