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: <005401c36317$862c8c90$0c2e45c7@somatose>
From: somatose at cox.net (Chris Garrett)
Subject: msblast DDos counter measures (More Insight Maybe?)

First, I'll quote Carsten Truckenbrodt, because he already sent a message
explaining this:
------------snip------------
This might be a bad idea. If you let windowsupdate.com resolve to 127.0.0.1 the
following will happen: The worm uses spoofed IPs from the local /16 subnet as
source address. Pointing all the syn packets to 127.0.0.1 will generate a RST
packet from the local host to the spoofed IPs  and spread traffic over the
complete internal network.

Even blocking or routing the normally resolved IP to Null0 will be a lot work
because this domain is loadbalanced through the world. That means you get a
different resolution depending on your ISP or place in the world.

If you manipulate your DNS, you should give no A-Record back to the worm. With
this the worm will not start attacking anything. So setting up a nameserver zone
with only a SOA record will do the job for Saturday 0:00.
------------snap------------

Now me:
The worm sends out a DNS query attempting to resolve windowsupdate.com, the
answer is 127.0.0.1. The worm then, under the impression that 127.0.0.1 is
windowsupdate.com, sends SYN packets to 127.0.0.1 on port 80. The packets don't
even make it out onto the wire, or at least they shouldn't unless something is
broken. Instead, they get looped back to localhost. Localhost then looks at the
source address of the packet, but what's the source address? The source address
is a random IP on the local C class. The localhost then sends a RST packet to
the supposed source IP because port 80 is supposedly not open.

Therefore, this solution of resolving windowsupdate.com to 127.0.0.1 is a good
way to flood every network infected by this virus. Isolated storms behind the
router. Makes an interesting image, no?

Christopher Garrett III
Inixoma, Incorporated

----- Original Message -----
From: "Christopher Lyon" <cslyon@...svcs.com>
To: "Marc Maiffret" <marc@...e.com>; "B3r3n" <B3r3n@...osnet.com>;
<full-disclosure@...ts.netsys.com>
Sent: Thursday, August 14, 2003 10:22 PM
Subject: RE: [Full-Disclosure] 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

_______________________________________________
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