full-disclosure - msblast DDos counter measures (More Insight Maybe?)

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-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5.2.1.1.2.20030815114308.011e9200@belegost.cimternet.com>
From: B3r3n at argosnet.com (B3r3n)
Subject: msblast DDos counter measures (More
  Insight Maybe?)

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?


At 04:22 15/08/2003, Christopher Lyon wrote:
>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
>
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: http://lists.netsys.com/full-disclosure-charter.html