Re: Code Red Doesn't care about TCP sessions?

From: Mark Wiater (mwiaterat_private)
Date: Fri Aug 10 2001 - 06:52:55 PDT

  • Next message: Joseph Spears: "RE: DHCP, ARP, oh my Anyone know of an exploit that dupes ARP on wind ows 95?"

    Thanks for confirming this Vern, I thought I was going nuts. (And lot's of 
    folks have told me privately, in response to this note, that I have).
    
    I've too spent a fair amount of time trying to find a legitimate reason for 
    this behaviour but can't. There is no NAT in play here. 
    
    I also neglected to state that I've correlated this activity to firewall 
    logs, deny firewall logs that is. Another note is that the destination IP's 
    are not in use. I've also ruled out that the Arrowpoints are somehow proxying 
    the handshake, there's nothing going back to the code red attacking machine 
    from my network.
    
    Worm attempts to real web servers get through the firewalls and look like 
    (via tcpdump) normal http sessions.
    
    One of the reasons that I wanted to bring this up is to see if anyone thought 
    that this behaviour would be impact Intrusion Detection Systems, IDS's that 
    reassemble the TCP streams.  (I should have said that I used Snort 1.7, which 
    doesn't do TCP reassembly...)
    
    Mark
    
    On Friday 10 August 2001 12:36 am, Vern Paxson wrote:
    > > A closer look at the data showed that many of the Code Red attacks were
    > > directed at machines that I KNEW were not able to receive port 80 through
    > > the firewalls. So how did Code Red get so far as to send the GET request
    > > when there was no SYN, SYN/ACK, ACK???
    > >
    > > A tcpdump showed that all of the code red communications were
    > > unidirectional. It didn't bother to wait (more than 350ms) for a response
    > > from the Web server before it sent it's ACK and then GET request.  This
    > > behaviour was consistent for all ip addresses that could not respond via
    > > port 80 because of the firewall.
    > >
    > > Am I the only one to see this behaviour?
    >
    > I've seen this too - very bizarre!  I've tried to concoct scenarios in
    > which it's somehow a NAT that's run amuck, but haven't managed to put
    > together any that are convincing.
    >
    > 		Vern
    
    ----------------------------------------------------------------------------
    This list is provided by the SecurityFocus ARIS analyzer service.
    For more information on this free incident handling, management 
    and tracking system please see: http://aris.securityfocus.com
    



    This archive was generated by hypermail 2b30 : Fri Aug 10 2001 - 07:33:32 PDT