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?)

There has been posted on many forums about setting the DNS entries or
using host files to make windowsupdate.com resolve to 127.0.0.1. So, I
gave it a try and found something interesting. Maybe somebody can shed
some light on this or maybe it was covered before so I am just
confirming this. In any event, here is goes:


Once the machine was infected and confirmed infected, I started with
test #1: 

I created a windowsupdate.com zone and put 127.0.0.1 in it in. Made sure
that the infected machine can ping windowsupdate.com and it resolves to
127.0.0.1. Then I rebooted.  

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) This is just the opposite that I was seeing when
there was no 127.0.0.1 entry.  Before I made these changes it was
spoofing the source (192.168.x.x/16) and the destination was
windowsupdate.com either .11 or .12. So, I did the same thing on the
host file, just to be sure, and as expected, the same results. Here is
how I sniffed and note I am doing this off the wire so it is getting out
of the machine.



MSBLAST PC ----------Switch-----------Netscreen
                       \------Mirrored port to tcpdump


I am seeing this traffic on a tcpdump:

9:57.881676 localhost.localdomain.http > 192.168.194.18.1858: R 0:0(0)
ack 1114767361 win 0
19:39:57.981423 localhost.localdomain.http > 192.168.11.145.1035: R
0:0(0) ack 2140405761 win 0
19:39:58.082937 localhost.localdomain.http > 192.168.82.16.1980: R
0:0(0) ack 1018494977 win 0
19:39:58.181686 localhost.localdomain.http > 192.168.154.16.1157: R
0:0(0) ack 2044133377 win 0
19:39:58.301704 localhost.localdomain.http > 192.168.39.53.1034: R
0:0(0) ack 85327873 win 0
19:39:58.401324 localhost.localdomain.http > 192.168.110.180.1979: R
0:0(0) ack 1110966273 win 0




This is what I should see: Also, note the DST port vs the SRC port
above?

19:48:24.021664 192.168.128.171.1329 > 204.79.188.11.http: S
642383872:642383872(0) win 16384
19:48:24.043177 192.168.193.171.1933 > 204.79.188.11.http: S
1277034496:1277034496(0) win 16384
19:48:24.061791 192.168.3.43.1768 > 204.79.188.11.http: S
1911619584:1911619584(0) win 16384
19:48:24.083533 192.168.69.43.1604 > 204.79.188.11.http: S
398786560:398786560(0) win 16384
19:48:24.101956 192.168.134.170.1439 > 204.79.188.11.http: S
1033371648:1033371648(0) win 16384
19:48:24.123437 192.168.199.42.1275 > 204.79.188.11.http: S
1668022272:1668022272(0) win 16384
19:48:24.141989 192.168.10.42.1110 > 204.79.188.11.http: S
155123712:155123712(0) win 16384
19:48:24.163391 192.168.75.170.1945 > 204.79.188.11.http: S
789774336:789774336(0) win 16384
19:48:24.184099 192.168.140.170.1781 > 204.79.188.11.http: S
1424359424:1424359424(0) win 16384
19:48:24.201308 192.168.205.42.1616 > 204.79.188.11.http: S
2059010048:2059010048(0) win 16384
19:48:24.221805 192.168.16.42.1452 > 204.79.188.11.http: S
546111488:546111488(0) win 16384

So any feedback? It seems that doing this would create a different set
of problems. That goes back to just fixing your machines. Right!


Signed,
Christopher Lyon
Affant Communication (formerly DNS Network Services)
cslyon@...ant.com

> -----Original Message-----
> From: Marc Maiffret [mailto:marc@...e.com]
> Sent: Thursday, August 14, 2003 2:58 PM
> To: B3r3n; full-disclosure@...ts.netsys.com
> Subject: RE: [Full-Disclosure] msblast DDos counter measures
> 
> Yah this has been mentioned a few times although I am not sure why
your
> blackhole windowsupdate.microsoft.com therefore keeping machines from
> using
> windows update to get patches. the worm only hits windowsupdate.com
itself
> so you only need to 127.0.0.1 that. unless I am missing something,
like
> your
> just wanting to be overly paranoid or something?
> 
> Signed,
> Marc Maiffret
> Chief Hacking Officer
> eEye Digital Security
> T.949.349.9062
> F.949.349.9538
> http://eEye.com/Retina - Network Security Scanner
> http://eEye.com/Iris - Network Traffic Analyzer
> http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities
> 
> | -----Original Message-----
> | From: full-disclosure-admin@...ts.netsys.com
> | [mailto:full-disclosure-admin@...ts.netsys.com]On Behalf Of B3r3n
> | Sent: Thursday, August 14, 2003 11:10 AM
> | To: full-disclosure@...ts.netsys.com
> | Subject: [Full-Disclosure] msblast DDos counter measures
> |
> |
> | All,
> |
> | We found a simple solution to protect our IntraNet against the DDoS.
> |
> | Since the msblast.exe will SYN flood windowsupdate.com (or
> | windowsupdate.microsoft.com) with 50 packets per second (according
to
> our
> | tests).
> |
> | Since our IntraNet solves all its DNS queries through internal
caches
> | (mandatory bottleneck), we created windowsupdate.com &
> | windowsupdate.microsoft.com zones in this bottleneck DNS. These are
> | resolving to 127.0.0.1 with DNS wildcards.
> |
> | After the Microsoft DNS TTL has expired (15 minutes is the worst
TTL),
> we
> | got confirm all known windowsupdate domains hosts
(www.windowsupdate.com,
> | windowsupdate.microsoft.com, v3.windowsupdate.microsoft.com &
> | v4.windowsupdate.microsoft.com) were resolved to localhost.
> |
> | We expect now the worm to flood the box it is hosted on and so
> preserving
> | our IntraNet.
> |
> | Hope this can help others.
> |
> | Brgrds
> |
> | Laurent LEVIER
> | Equant Information Technology & Systems - Equant Security
Organization -
> | Internal Network (WAN IntraNet) - Systems & Networks Security Expert
> | Tel. CVN : 7223-1912, ext. (+33) 4 92 38 19 12
> |
> |
> | _______________________________________________
> | Full-Disclosure - We believe in it.
> | Charter: http://lists.netsys.com/full-disclosure-charter.html
> |
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ