Re: CVX? Re: Scans of 21536

[Paul BOYER <paul.boyer () SECURITYKEEPERS COM>]

We also see those tcp 21536 packets. 
Did you also observe UDP 37852 packets ?
We are trying to determine if they are due to similar 
problem.

Capture of packets (anonymized) follow :
08:09:30.529936 194.133.58.129.55 > 
XXX.XXX.142.42.37852: udp 10 (ttl
53, id 46545)
                         4500 0026 b5d1 0000 3511 6ff4 c285 
3a81
                         XXXX 8e2a 0037 93dc 0012 0bb5 
0000 0000
                         0000 0000 0000 0000 3335 3420 456e
08:11:23.627801 194.98.199.254.6723 > 
XXX.XXX.78.130.37852: udp 10 (ttl
61, id 2286)
                         4500 0026 08ee 0000 3d11 c6ea 
c262 c7fe
                         XXXX 4e82 1a43 93dc 0012 a3bb 
0000 0000
                         0000 0000 0000 0000 0204 05b4 0103
08:56:56.462938 193.41.181.254.989 > 
XXX.XXX.142.42.37852: udp 10 (ttl
55, id 51746)
                         4500 0026 ca22 0000 3711 df81 c129 
b5fe
                         XXXX 8e2a 03dd 93dc 0012 8ded 
0000 0000
                         0000 0000 0000 0000 4745 5420 2f76
10:36:56.121184 194.117.219.164.42181 > 
XXX.XXX.78.130.37852: udp 10
(ttl 52, id 14108)
                         4500 0026 371c 0000 3411 8e03 
c275 dba4
                         XXXX 4e82 a4c5 93dc 0012 0580 
0000 0000
                         0000 0000 0000 0000 4745 5420 2f64
11:37:31.069432 194.133.58.129.64994 > 
XXX.XXX.78.130.37852: udp 10 (ttl
53, id 17066)
                         4500 0026 42aa 0000 3511 2289 
c285 3a81
                         XXXX 4e82 fde2 93dc 0012 4d76 
0000 0000
                         0000 0000 0000 0000 4745 5420 2f65

Last 3 packets look like an other bug we are regularly 
seeing on tcp
packets: "HTTP" data directly after IP header :
0x 4745 5420 2fxx = "GET /"xx
But udp is not expected here !


Paul BOYER


> Apparently Nortel corrected something and the ISP 
representative I talk
> with told me they update their firmware but we still 
detect this TCP/21536
> cnx attempts.
>
> JF
>
> At 16:42 11/01/01 -0600, marc wrote:
> > > I'm not sure exactly what causes the corrupted 
packets, but I have seen
> > them
> > > as well, here in the US. My network logs show 
a client connecting to
> > our web
> > > site, sending a corrupt packet with the TCP 
header "missing", with "GET "
> > > 18245 > 21536. The next packet they send is a 
proper request "GET "
> > directed
> > > at tcp port 80 of our web server.
> > ...
> > > to be legitimate home-ISP users connecting to 
our web site(s). I have not
> > > seen scans that follow these patterns.
> > > I would guess that your theory that someone is 
scanning behind a device (or
> > > with a device) that creates broken packets is 
correct. A simple scan
> > for web
> >
> >         I exchanged email with someone that 
claimed the problem had been
> > traced back to a Nortel CVX.  Can anyone confirm 
or deny this as an issue?
> > marc
> >
> >
> > > servers with the occasional garbage packet 
thrown at you.
> > > I do still wonder what is causing this, it could 
also be a Windows bug...
> > > maybe a flaw in Windows Me ??
> > >
> > > -----Original Message-----
> > > From: Fulton L. Preston Jr. 
[mailto:fulton () PRESTONS ORG]
> > > Sent: Thursday, January 11, 2001 2:41 AM
> > > To: INCIDENTS () SECURITYFOCUS COM
> > > Subject: Scans of 21536
> > >
> > >
> > > For the last few months I have seen scans for 
port 21536 from port 18245
> > > to my various web servers.  I have searched 
the mail archives on
> > > SecurityFocus and have found several people 
on several lists ask about
> > > them and I found only one response, which 
seems ok, but I want to
> > > confirm it.
> > >
> > > smarkacz () anathema eu org wrote to the lists:
> > >
> > > "We have seen it for several months[2] in 
Poland, these packets are
> > > generated by some brain damaged device (I 
don't know what this is); they
> > > would be correct TCP packets if something did 
not strip TCP header
> > > placing HTTP request right after the IP header. 
Look at the numbers and
> > > you'll see that such damaged packet will be 
resolved to `port 21536
> > > probe' - "GET " resolves to ports 18245 -> 
21536."
> > > He even claims to be able to reproduce it if he 
dials into some public
> > > ISP in Poland and connect to his machines on 
any port such as telnet or
> > > ssh.
> > >
> > > I might accept this but the sources of the scans 
I see are from the US
> > > (I'm in the US too).  The scans so far have 
come from the west coast.
> > > Now if it is a misconfigured device I could 
believe the traffic to be
> > > innocent but what I get are actual slow scans 
across my various IP
> > > spaces in sequential order.  This would indicate 
a "scan" in my book and
> > > not just some odd device causing this from 
casual browsing (though it
> > > could be scans from behind a broken device, 
that makes it easy to "tag"
> > > as a signature for IDS)
> > >
> > > To make it even more complicated, not all 
scans look at port 80. Some
> > > don't even look at anything at all except port 
21536.  Most do look for
> > > port 80 though after a connection is attempted 
to 21536.
> > > [Sample Snort Log]
> > > Jan 10 14:26:28 209.252.32.186:1264 -> 
x.x.x.x:80 SYN ******S*
> > > Jan 10 14:26:24 209.252.32.186:18245 -> 
x.x.x.x:21536 INVALIDACK
> > > *2UA*R** RESERVEDBITS
> > > Jan 10 14:26:28 209.252.32.186:18245 -> 
x.x.x.x:21536 NOACK *2U*PR*F
> > > RESERVEDBITS
> > > Jan 10 14:26:31 209.252.32.186:1265 -> 
x.x.x.x:80 SYN ******S*
> > > Jan 10 14:26:36 209.252.32.186:18245 -> 
x.x.x.x:21536 NOACK *2U*P*S*
> > > RESERVEDBITS
> > > Jan 10 14:26:39 209.252.32.186:1266 -> 
x.x.x.x:80 SYN ******S*
> > > Jan 10 14:26:40 209.252.32.186:18245 -> 
x.x.x.x:21536 UNKNOWN *2*A*R**
> > > RESERVEDBITS
> > > Jan 10 14:26:47 209.252.32.186:1270 -> 
x.x.x.x:80 SYN ******S*
> > > Jan 10 14:26:57 209.252.32.186:1271 -> 
x.x.x.x:443 SYN ******S*
> > > Jan 10 17:51:47 63.255.26.26:1120 -> 
x.x.x.x:80 SYN ******S*
> > > Jan 10 17:51:47 63.255.26.26:18245 -> 
x.x.x.x:21536 NOACK *2U**RS*
> > > RESERVEDBITS
> > > Jan 10 17:51:51 63.255.26.26:18245 -> 
x.x.x.x:21536 NOACK *2U**RS*
> > > RESERVEDBITS
> > > [/Sample Snort Log]
> > >
> > > The above may be a poor example as both IP 
ranges belong to the same ISP
> > > in this case.  In others they have no know 
relation and traceroutes show
> > > that they take totally different paths and do not 
cross the same
> > > routers.
> > >
> > > I know a few people have seen this.  Anyone 
else lurking on the list
> > > seen this activity?  Anyone else have anything 
to offer on this? I am
> > > really interested in knowing if it is a router 
causing this.  If it
> > > isn't a router, what the heck are they looking 
for?
> > > Regards,
> > > Fulton Preston
> > >
> > > [This is supposed to be an annoying signature.  
Are you annoyed yet?]
> > >
> >
> > marc
> >
> > import sigfile
>
> Jean-Francois Zwobada
> Cellule Securite - Fluxus
> Phone : +33.1.70.95.10.10 - Fax : +33.1.70.95.10.00
> 37, rue du Colonel Pierre Avia - 75015 PARIS