full-disclosure - Re: Windows Messenger Popup Spam

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: <20030626033123.GG19021@dok.org>
From: jh at dok.org (jh)
Subject: Re: Windows Messenger Popup Spam - advisory amended

On Wed, Jun 25, Joe Stewart wrote:
> On Monday 23 June 2003 05:19 pm, jh wrote:
> > 1026 is ephemeral, it may not always be this port. 
> 
> I'd say it's dependent on the the startup order of other listeners. Ephemeral
> implies it is short-lived. If you don't install other services that use port
> 1026 it will probably continue to be bound to port 1026 indefinately. I've
> been told that some Windows 2000 server platforms may have messenger
> listening on port 1027 due to other services starting first, but popup
> spammers are typically targeting the home user running WinXP.

Yah, you are correct. Ephemeral probably wasn't the best choice of
wording, but you understood what I meant anyway. 

> This is an excellent paper; is it yours?

Yes it is, thanks.

> 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.

This may be entirely dependent on the handful of the commercial
"advertising tools" that I selected to look at - and clearly several
of them appeared to be ripoffs of each other. Though to be fair, I
have observed this exchange of packets in real life (ie; not caused by
my own testing, just allowing spammers access to my machines).

> The paper says that the conv_who_are_you packet
> must be answered by the client before the popup will occur.

Your observations are very interesting. I could never get a popup
to display without this transpiring. I noticed other people have had
the same results
(http://www.mynetwatchman.com/kb/security/articles/popupspam/netsend.htm,
as an example). 

> 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.

Is that UDP packet you are replaying the first packet of the
conversation? I'd be interested in looking at it (and what else you
are doing). If you could send that to me off list, I'd appreciate it.