lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
From: cslyon at netsvcs.com (Christopher Lyon)
Subject: msblast DDos counter measures (More Insight Maybe?)

> From: Vladimir Parkhaev [mailto:vladimir@...bas.net]
> 
> Quoting B3r3n (B3r3n@...osnet.com):
> > Christopher,
> >
> > > So, the machine is coming back up and the date was set after the
16th
> > > and what do I see, I see a SYN flood but the source is 127.0.0.1
and
> the
> > > destination is 192.168.X.X/16. (I am using 192.168.252.100 so the
X's
> > > are the random numbers)
> > A question: does 192.168.x.x/16 reflects the configuration of the
> infected
> > machine, or maybe a subnet of its configuration?
> 
> I don't see the problem... The PC in question is on 192.168.x.0 nw
> with address 192.168.x.y. According to the worm analysis, it msblaster
> picks random src IP addresses limited to first 2 octets of infected
> PCs nw - anything between 192.168.0.0-192.168.255.255 (or
192.168.255.254).
> 
> The OP points windowsupdate.com to 127.0.0.1. The worm starts
generting
> packets dst 127.0.0.1 src in 192.168.0.0-192.168.255.255. Since PC
> is not runing web server, OS sends a RST to the dst in
> 192.168.0.0-192.168.255.255 (basic TCP). More SYN packets are
generated,
> more RST packets you get on your class B n/w.
> Conclusion - pointing  windowsupdate.com to 127.0.0.1 replaces SYN
attack
> of
> windowsupdate.com by RST attack on your class B.
> Solution - patch the freaking PCs!

I agree that patching the PC is the ultimate answer but what I am saying
is that what we ALL think the virus will do when we try to set the
windowsupdate.com to 127.0.0.1 is just the opposite. 

Look at these traces to see what it is doing. Note the source and
destination ports and addresses.  

WINDOWSUPDATE.COM set to resolve normally
19:48:23.963345 192.168.187.171.1823 > 204.79.188.11.http: S
886046720:886046720(0) win 16384

It is allowed to resolve normally and the source is just what we think.
192.168.x.x with the x's random numbers. This is what we all know and
can prove. 


WINDOWSUPDATE.COM set to 127.0.0.1
19:39:56.131653 localhost.localdomain.http > 192.168.83.210.1269: R
0:0(0) ack 68419585 win 0

Now look at the source, the source is 127.0.0.1 and the destination is
the 1921.68.x.x with the x's being random numbers. That is what I am
saying is different. Also note that the dst port is 80. 

So, what I am saying is that the syn flood will leave the box but it
will leave differently then we all think. So, can someone confirm this?
I have been seeing this in two different environments now.




> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html


Powered by blists - more mailing lists