full-disclosure - Re: Windows Messenger Popup Spam - advisory amended (followup for those interested)

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] [day] [month] [year] [list]

Message-ID: <20030701023724.GL7329@dok.org>
From: jh at dok.org (jh)
Subject: Re: Windows Messenger Popup Spam - advisory amended (followup for those interested)

On Wed, Jun 25, Joe Stewart wrote:
> I have found however, a few points of difference between what the paper
> describes of the protocol and what I've observed in practice. The paper
> describes a much more elaborate exchange of packets than the spammers 
> are actually using. The paper says that the conv_who_are_you packet
> must be answered by the client before the popup will occur. This doesn't
> seem to be necessary, as I have been able to merely replay the same
> UDP packet payload again and again, on either port.

Note: I tested this only on w2k.

This *does* seem to be dependent on the tools used to send the SPAM. The
dump you sent me had one difference from what I've observed: The first
flags field on the initial packet is set to 0x28 (Idempotent and
NoFack). The commercial tools that I looked at have set this field to
0x08 (NoFack).

When the Idempotent flag is set, the remote host won't elicit the
conv_who_are_you - no effort is made to get any information about the
client and the request is executed. More information on this can be
found at http://www.opengroup.org/onlinepubs/9629399/apdxp.htm.

I looked at some of the commercial tools again:

Direct Advertiser: No demo available (website under construction)
Broadcast Advertiser: New demo wouldn't do anything useful
SlySender: Still sends DCE requests with 0x08

So, it would seem that there are some new (?) tools floating around.

> The paper says that these packets should be dropped as duplicates,
> but I have observed that you only need to wait for a given timeout
> to occur before you can send the packet  and get a popup again;
> somewhere on the order of 10 minutes or so.

Yeah. That timeout you speak of is the dupe prevention. You could hex
edit the sequence number in your packet dump, try again, and it will
work.

> And only one packet is necessary, no matter which port you send it
> to. I've been successful at spoofing a bogus source IP address in
> the packets generating the popups as well.

Right on. Flipping that Idempotent bit is spiffy, you get a spoofed
RPC packet that Windows will happily execute. Whee!

Thanks again for the packet dump, very enlightening!