RE: LOGS: GIAC GCIA Version 3.4 Practical Detect Ian Eaton

Don,

I really do appreciate your time and effort used to review my detect.

Half your comments seem related to the lack of supporting information
embedded in the detect, I agree the paper does need more of this.  In my
attempt to keep the detect length to a minimum (in MS Word it is already
14 pages) I think I missed some important and easily inserted
information that would make this detect more complete and standalone.  I
will expand as suggested for the final paper.

Some further responses to your specific questions are next

Regards, Ian



In these files almost all the 
> > packet streams are in their entirety, for example the full 
> > TCP three way hand shake to its close is intact.
> 
>       don - "hand shake to its close is intact" - doesn't make
>       to much sense?
> 

This sentence should have been more like

"In these files almost all the packet streams are in their entirety, for
example TCP connections from  the initiating three way hand shake
through to the connection close (i.e. the whole communication data
stream) is intact "


> There is the remote chance that the attacker is sniffing the 
> > packets crossing the wire and spoofing every response packet, 
> > though this is not even remotely likely and would be and ..
> > extremely advanced technique.  The attacker does not make an 
> > effort to hide the attack as it is easily detectable, it 
> > would be a waste of effort to do this and then make the 
> > attack obvious.
> 
>       don - hmmm.... do you mean sniffing locally on the
>       wire or doing a man in the middle kind of thing?
>       

In this case I was referring to the possibility that an attacker could
be sniffing the network traffic with a sniffer anywhere on the path
between the two communicating hosts, listening to the traffic as it
passes performing a non blind form of the Mitnik attack.  I figure as
long as the address used to perform the attack is either not assigned to
a real host or the real host is silenced (i.e. by a DoS) the attacker
could maintain a full TCP communication with the target as long as they
can see every return packet.


> server respn =>               220 lazy FTP server (Version w
> > attack reqst =>             USER anonymous
> > server respn =>             331 Guest login ok, send your 
> > attack reqst =>             PASS nessus@xxxxxxxxxx
> > server respn =>             230 Guest login ok, access res
> > server respn =>             221 You could at least say goo
> 
>       don - ok, so you draw the conclustion that its nessus,
>       but what did you look at in the nessus app to correlate..
>       is there a particular assessment that matches the "goo"?
>       in other words, does the nessus scanner have a ftp test
>       that uses this email addr?
> 

Performing a quick grep (grep -rin "nessus@xxxxxxxxxx" *) on the nessus
plugins for the login string "nessus@xxxxxxxxxx" allows me to add this
to the detect.

Nessus is a fully featured open source Vulnerability Assessment tool
that provides an ever increasing set of tests to asses the security
posture of a target host from over the network.  Nessus uses plugins to
supply information for each of these tests.  One of the plugins
"logins.nasl" does not do any security checks by itself but does provide
default login configuration information for other plugins to use.  

Plugin information
http://cgi.nessus.org/plugins/dump.php3?id=10870

The source for this plugin has these settings by default
http://cvsweb.nessus.org/cgi-bin/cvsweb.cgi/~checkout~/nessus-plugins/scripts/logins.nasl?content-type=text/plain

default_ftp_login = "anonymous";
default_ftp_password = "nessus@xxxxxxxxxx";
default_ftp_w_dir = "/incoming";


> I suspect this environment has been setup to allow people to 
> > test their attack techniques so system countermeasures are 
> > not implemented to make the environment a little easier to attack.
> 
>       don - at this point I don't recall all of the text above,
>       but didn't you show that they were thwarted at some points?

I don't think I show the attacks are thwarted but more the attacks did
not always complete successfully, I am not an expert in performing these
types of attacks on hosts but I suspect due to the nature of buffer
overflow attacks and the like they would not always work as expected
100% of the time.


> How many packets does nmap send to a host when trying to 
> > identify the OS type given the -O command line option:
> > a.  6
> > b.  7
> > c.  8
> > d.  9
> > 
> > Answer: c   (T1 - T7 which are TCP tests, and a UDP test)
> 
>       don - you need to explain your answer.  that is
>       necessary, and I imagine a required point for the
>       practical...  

Nmap sends 8 specially crafted packets to a target host when trying to
determine the OS type.  There are 7 TCP based packets that contain
varying combinations of TCP flags and options set, in the hope of
eliciting a specific response that can be used to identify the target. 
The eighth packet is of type UDP.


Thanks again for you time.






On Sun, 2004-05-23 at 03:52, Don Murdoch wrote:
>       Comments inline below.
>       Don M, GCIA Local mentor
> 
> > -----Original Message-----
> > From: intrusions-bounces@xxxxxxxxxxxxxx 
> > [mailto:intrusions-bounces@xxxxxxxxxxxxxx] On Behalf Of Ian Eatonfor 
> > example the full 
> > TCP three way hand shake to its close is intact.
> 
>       don - "hand shake to its close is intact" - doesn't make
>       to much sense?
> > Sent: Saturday, May 22, 2004 8:47 AM
> > To: intrusions@xxxxxxxxxxxxx
> > Subject: [Intrusions] LOGS: GIAC GCIA Version 3.4 Practical 
> > Detect Ian Eaton
> > 
> > 


_______________________________________________
Intrusions mailing list
Intrusions@xxxxxxxxxxxxxx
http://www.dshield.org/mailman/listinfo/intrusions