pslossPremium
join:2002-02-24
Alpharetta, GA | reply to Link Logger
Re: Messenger Spam on 1026 - Bad News Kids said by Link Logger:
They selected 1026 as the destination port as that is typically where the Services.exe application is listening on most systems (note this method of sending spam is for Windows NT, 2000, XP, 2003 only).
Right, but the point in that regard was that the single packet method has been used since February on UDP port 135 (the endpoint mapper point) and is now being used for the "direct," ephemeral UDP port.
said by Link Logger:
If you were to send the spam to port 1026 on my computer the spam wouldn't show up on my screen as Services.exe is on port 1031 (if you sent it to UDP port 1031 then it would appear on my system), this is why you see some traffic on ports surrounding 1026 as they are looking for systems where the Services.exe is listening on different ports.
Services.exe is the shell process used for NT4 and Windows 2000, but the Messenger service is launched in one of the svchost.exe processes in XP and Windows Server 2003. So the process name (and, of course, the functionality) is O/S version dependent...which one or ones are you testing on or just running?
Philip Sloss
--
(Thanks, anonymous!) Feedback? e-mail: stuff@lupwa.org |
|
|
|
 Link LoggerPremium,MVM
join:2001-03-29
Calgary, AB
kudos:3
 ·Shaw
| I've tested this against Win2k Advanced Server, Win2k Professional, and XP Professional. The key is to find what UDP port Services.exe is listening on (I use Vision from Foundstone). For my personal system (Win2k Advanced Server) Services.exe is listening on 1031, hence why sending to UDP port 1031 works and 1026 doesn't. All my other systems Services.exe is listening on UDP port 1026. If you use UDP port 1027 nothing will appear unless services.exe is listening on that port instead of 1026 which is possible as ephemeral ports are dynamically assigned.
Blake
If everyone reading this thread were to go and find out what UDP port Services.exe is running on, most people would find it on 1026 and would be susceptible to 1026 spam, some people would find that Services.exe is on a different port and hence would not be susceptible to 1026 spam, but would be susceptible to spam sent to their Services.exe port. If anyone would like to participate in this experiment I could use PortPuker to send you the spam as a test.
[text was edited by author 2003-09-16 16:26:39] |
|
pslossPremium
join:2002-02-24
Alpharetta, GA | said by Link Logger:
I've tested this against Win2k Advanced Server, Win2k Professional, and XP Professional. The key is to find what UDP port Services.exe is listening on (I use Vision from Foundstone).
On XP and Windows Server 2003, though, the Messenger service process is not services.exe, it is one of the svchost.exe processes. When I look at the process to port mappings on my XP Home and Pro setups, the services.exe process does not hold any ports open -- neither TCP nor UDP.
So what I'm suggesting is that on XP Home, XP Pro and the different variations of Win2k3 (Server, Adv. Server, etc.), the services.exe process is irrelevant to the Messenger service.
Philip Sloss
--
(Thanks, anonymous!) Feedback? e-mail: stuff@lupwa.org |
|
Link LoggerPremium,MVM
join:2001-03-29
Calgary, AB
kudos:3 Reviews:
·Shaw
| On XP svchost.exe is a generic host process name for services that run from dynamic-link libraries (DLLs). Typically on a XP system on UDP port 1026 you will see that svchost.exe is running task number 652 (on my system) which using 'tasklist /SVC' (see »support.microsoft.com/default.as···s;314056 for details) you will see that 652 on my XP Pro system contains the Messenger service and some other functionality.
On Win2k Services is somewhat similar to svchost in function but also has the responsibility of running the Messenger Service as shown by TList -s (see »support.microsoft.com/default.as···S;250320 for details). So on my Win2k Advanced server you see that on UDP port 1031 Services.exe is running and under it a number of other applications including an instance of svchost.exe (using Process Explorer from sysinternals).
So the point is nothing is carved in stone about UDP port 1026 and it could be a different port on different systems depending on OS version and configuration (ie what services you have running and even what order they startup in).
To send one hit Message to a Win2k system you need to find out what port the Services.exe is listening on and and on XP what svchost process is running the Messenger Service and what port it is listening on. For most systems this is UDP port 1026.
Blake
--
»www.SonicLogger.com - Logging Software for SonicWall and 3Comhttp://www.LinkLogger.com - Logging Software for Linksys, Netgear and Zyxel |
|
pslossPremium
join:2002-02-24
Alpharetta, GA
| said by Link Logger:
So the point is nothing is carved in stone about UDP port 1026 and it could be a different port on different systems depending on OS version and configuration (ie what services you have running and even what order they startup in).
Agreed...on the subject of what ports we are testing with the WinPopup tester, we added UDP ports 1025-1029 (inclusive). For further additions, we will probably wait until spammers begin widely exploiting ports higher than that existing range. So far, I haven't seen a lot of Messenger service spam activity above UDP port 1027.
Edit: reviewing logs here, I am starting to see some activity from a couple of spammers that send the same packet to UDP 1026, 1027, and 1028 in sequence. That is covered in the current port set we use, but as above, we'll probably monitor the spam activity rather than theoretical possibilities. Put another way: we'll wait for the spammers to send spam on more ports rather than the possible ports that the Messenger service is listening on...
Philip Sloss
[text was edited by author 2003-09-16 17:52:02] |
|
Link LoggerPremium,MVM
join:2001-03-29
Calgary, AB
kudos:3 Reviews:
·Shaw
| That strategy makes sense.
The question is how far will these spammers go with this as this new method will allow them to really crank up the volumes of spam sent out big time. How much is too much, before someone takes action to limit them or will they have a free license to go as far as they want in terms of bandwidth usage etc?
Blake |
|
pslossPremium
join:2002-02-24
Alpharetta, GA | said by Link Logger:
The question is how far will these spammers go with this as this new method will allow them to really crank up the volumes of spam sent out big time. How much is too much, before someone takes action to limit them or will they have a free license to go as far as they want in terms of bandwidth usage etc?
That's a good question, which I can't answer. I can only speculate. Here's a couple of factors that I always think about:
First, it's easier to block. As you noted earlier, it's going to be hard for ISPs to block ephemeral ports; however, end-users can employ a "firewall" (hardware, software, or a combination). Unsolicited UDP packets should be blocked by default by most "firewalls." If Microsoft follows through with their threat to activate XP's Internet Connection Firewall (ICF), that would go some way in discouraging this as a long-term method for bulk advertisers.
On the other hand, it's easy to spoof and therefore harder to trace. Which unfortunately makes it almost a no-risk deal for a spammer.
As with what we are doing in monitoring the destination ports, we are also watching trends in the advertisements themselves and they still seem to be predominantly advertisements for cheap products -- anything that is not free is a rip-off in my opinion -- to disable the Messenger service.
(Aside: I suggest that anyone considering buying one of these "products" instead go get Steve Gibson's free utility, Shoot The Messenger:
»news.grc.com/stm/shootthemessenger.htm)
In other words, the spam is mostly for products to stop the spam. That suggests (doesn't prove) that advertisers are not jumping on the bandwagon. It also may suggest there isn't a bandwagon.
That's my speculation (or some of it),
Philip Sloss
--
(Thanks, anonymous!) Feedback? e-mail: stuff@lupwa.org |
|
