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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <200306230942.01691.jstewart@lurhq.com>
From: jstewart at lurhq.com (Joe Stewart)
Subject: Re: Windows Messenger Popup Spam - advisory amended

On Saturday 21 June 2003 05:57 pm, Jeff Kell wrote:
> This is missing the point.  Messenger is an RPC service.  Previous
> spamming by popups query udp/135 to determine the port number of the
> messenger service, then send the spam packet via udp to the port
> returned by the RPC portmapper.  Typically this port is 1026, but it
> doesn't have to be.

This doesn't seem to be the case. The messenger spam on port 135 is a 
single packet. The same packet payload sent to port 1026 has the same 
result. It doesn't appear to be RPC, but instead a case of the same process
listening to both ports, and deciding what to do with any packet received 
on either port based on content. If it is supposed to be RPC, it seems broken. 
If anyone can demonstrate the spam being able to utilize any other ports, 
please let me know.

> Blocking UDP has to be done connectionless, and Windows starts picking
> ephemeral ports at 1024 upward.  You are bound to get a lot of
> collateral damage (unintended blocking) of legitimate UDP services by
> blindly blocking udp/1026.

You are indeed correct here. As a result, I have amended the advisory
_against_ blocking port 1026 at the ISP level because ISPs are generally 
not going to be able to track the "state" of a so-called stateless protocol
and it could indeed cause collateral damage if blocked statelessly. Thus
blocking can only be done effectively at the host or stateful firewall level, 
so I have updated the advisory to reflect this.

-Joe

-- 
Joe Stewart, GCIH 
Senior Intrusion Analyst
LURHQ Corporation
http://www.lurhq.com/