Link Logger
Premium,MVM
join:2001-03-29
Calgary, AB
 ·Shaw
| reply to psloss
Re: Messenger Spam on 1026 - Bad News Kids
For an example of performance, to send a spam message via Net Send it might take a couple of seconds to send a message, but by using this new technique you can send several thousands of messages per second given the availability of bandwidth and CPU. So we are talking many orders of magnitude of performance increase by using this new method and hence why this traffic is increasing on suspected Services.exe ports as spammers let lose with a much faster gatling gun, as they are no longer limited by performance factors they do not control as with using Net Send.
Blake
--
»www.SonicLogger.com - Logging Software for SonicWall and 3Comhttp://www.LinkLogger.com - Logging Software for Linksys, Netgear and Zyxel |
|
psloss
Premium
join:2002-02-24
Alpharetta, GA
| reply to Link Logger
said by Link Logger  :
I would be willing to bet that filtering of UDP port 135 (how many ISP are filtering UDP port 135, as compared to TCP port 135) was just a small factor in spammers switching to this new method, as the real motivator is out and out performance. As you mentioned yourself we have seen this traffic before MSBlast came out so spammers were switching before UDP port 135 filtering started. ISP's will be unable to filter UDP port 1026 traffic so once again the bad guys ultimately win out in the end, because they are free to adapt.
Good point about the filtering, although I'm not sure what you mean by "performance"...the mechanics of sending the packet to one port versus another (or multiple ports) seems fairly similar...what do you mean by "performance?"
Thanks,
Philip Sloss
--
(Thanks, anonymous!) Feedback? e-mail: stuff@lupwa.org |
|
Link Logger
Premium,MVM
join:2001-03-29
Calgary, AB
·Shaw
| reply to psloss
Given that single packet UDP traffic is typically fire and forget, IP Spoofing is very possible given the spammer doesn't need a reply (Net Send couldn't use a spoofed IP addresses as the process required information be sent back to the spammer in order to complete the message process, ie if Netbios was enabled for messages and where the services.exe was sitting). Imagine if SQL Slammer used a spoofed source IP address, that would have been very, very bad and I wonder why the author didn't (unless the spoof generator would have increased the packet size too much).
I agree that this traffic isn't new and has bothered me for a while however as I was interested in the spammer's reasons behind the switch to this method. I would be willing to bet that filtering of UDP port 135 (how many ISP are filtering UDP port 135, as compared to TCP port 135) was just a small factor in spammers switching to this new method, as the real motivator is out and out performance. As you mentioned yourself we have seen this traffic before MSBlast came out so spammers were switching before UDP port 135 filtering started. ISP's will be unable to filter UDP port 1026 traffic so once again the bad guys ultimately win out in the end, because they are free to adapt.
Blake |
|
psloss
Premium
join:2002-02-24
Alpharetta, GA
| reply to Link Logger
said by Link Logger :
The point here is that by using this new technique of sending a single UDP packet to whatever port has Services.exe listen on it (usually 1026, but I bet we will see an increase in UDP traffic to ports 1024 - 1035 as Services.exe can run on any one of them as the port is dynamically assigned on startup of the system), the delivery rate of spammers has gone up by several orders of magnitude.
That's true, however single packet Messenger service spam isn't particularly "new" -- it has been the "rule" for several months. It goes back in my logs as early as February 2nd of this year when it was being introduced. By May, if not earlier, it was being used as much as the "built-in" Windows NetMessageBufferSend functionality. Now, most spammers are setting the idempotent bit which enables single packet sends, although other bits could be substituted (or combined).
What is relatively new (the LURHQ advisory) is that the packet is being sent to multiple ports to circumvent the port 135 filtering that is being applied by more ISPs. Going back through my logs, I found that sending to UDP ports 1026, 1027, and even 1028 goes back as far as March. It looks like the method was used in "one-off" cases through May and that higher rates of use began in mid-June, as the LURHQ advisory notes.
Another thing that we have yet to see used quite as much is spoofing the source IP address, but I believe this will occur eventually (I'm surprised it hasn't occurred as much by now).
Philip Sloss
--
(Thanks, anonymous!) Feedback? e-mail: stuff@lupwa.org |
|
