Socket Spy Doesn't

I'm running PE V1.7 on WinXP. PE sees a lot of traffic incoming on local UDP port 1900 (SSDP). Since PE was started a couple hours ago, it has logged 53,139 packets / 15,655,291 bytes received for that socket (at latest count). The remote addresses include various hosts around the country, some inside the address space of my ISP, and some in my personal LAN. My firewall log (WallWatcher) shows no traffic from those hosts.

I enabled Socket Spy, against the socket then the process (svchost.exe), to see just what this traffic is. SS captures no traffic. The process or socket shows up in the Spy List. But nothing shows up in Packet Data.

I checked out the hosts names / ip addresses shown by PE. They really do exist, and the names and addresses match. So PE isn't just making this up.

WTH??

 

Hi, socket spy should capture data if any passes along that socket. All I can say is make sure the directory you have Port Explorer installed to can be written to. Did more data come after you enabled socket spy or did the total packets/amount received stay the same? And can you see in the window log things like "send or receive" status events?

-Jason-

 

Hi nitecruzr,
I found sometimes it helps to actually type the PID with the - in the display to get the data. Especially with hidden processes.
Did you try that?

 

Jason,
The folder which PE is installed in is writable. Other sockets can be spied upon successfully, just not this one. The Traffic Log window displays numerous packets received successfully, byte count 200 - 300, for this socket. More data came along after I enabled SS. Right now, the count is 262,225 packets / 77,001,131 bytes for that socket, with more arriving constantly.

Jooske,
Yes, I did try adding the process manually, by typing the PID.

The attachment is from earlier today, when I initially wrote this.

 

Rightclicking the process, does it tell you to which service on your system it's related?
I mean there are several of those service hosts.
Does it start immediately after starting up windows or some other program,
or does it start after you connected to internet?

What happens if you press the "disable receiving"
is there then anything not functioning well anymore?
port 1901 FJICL-TEP-A - Fujitsu ICL Terminal Emulator Program A
port 1900 SSDP - SSDP (UDP)
The URL belongs to comcast; is it always the same?

 

nitecruzr, just in regards to screenshots, unless there are any photographic images in the area you're capturing, always use GIF format as it is much more suited to regular desktop images (windows etc). GIF will give you a much clearer image, and will also create a smaller file. Use JPGs when saving photo images

As an example, you can compare your 89kb JPG image to this 25kb GIF one -
http://www.diamondcs.com.au/portexplorer/images/maindisplay1.gif
Clean, clear, crisp, and small

Anyway, back to the topic at hand! ...

So you can spy on all sockets except this one, and you're sure that data is being transferred through that socket? (ie. you can see the Sent or Received counts increase, while you're spying on that socket?). Can you spy on other svchost.exe sockets? Is this the only socket you can't spy on?

Cheers,
Wayne

 

The remote addresses include various hosts around the country, some inside the address space of my ISP, and some in my personal LAN. Trying to count them is very frustrating, as the information in the Traffic Log window flies by very quickly. But I would guess there are at least a dozen addresses from which I am receiving data.

I now have all 4 processes associated with of svchost.exe n my Spy List; but have yet to see a packet show in Packet Data. Port 1900 is one of many ports that I see receiving data for which I can't see the packets.

The process in question started when I started Windows (which was the same time as when I connected to the internet).

The Comcast host was the most interesting in name; it was the one which first caught my eye when I was perusing the Traffic Log window. But there are several others which I suspect have no business sending me data.

 

Here's some more information about process 956.

I have done a bit more research on this particular process; it appears to be related to uPNP, which I enabled on my router. That seems like a good target for script kiddies with workstations named "bunny" for instance.

 

No, I was wrong. Some instances of svchost.exe can be spied upon. Although it's kinda hard identifying the actual socket the packet comes from - from the picture, all we can see is the process name and the local port. I would think listing the PID would be just as effective and would use up less screen space. (My 2c worth).

Unfortunately, none of the packets retrieved are for port 1900.

In this case, Wayne, the .jpg is 80K in size but the .gif is 183K. So I have to attach the .jpg version of this picture.

 

> In this case, Wayne, the .jpg is 80K in size but the .gif is 183K. So I have to attach the .jpg version of this picture.
Only because you're not using an optimisation tool such as Adobe Photoshop . Here's another one (but this one is freeware) - http://www.webattack.com/freeware/gmm/fwgraphicedit.shtml
I haven't tried it but from the description it sounds capable of optimising.

Thanks for the extra feedback re svchost, Jason will get back to you in the morning with some more information on that (currently 11:30pm Perth time)

Cheers,
Wayne

 

Wayne,

Looking at your example PE display in your first reply above, I notice the Process column (in the Socket List window) appears as the first column on the left. Does it appear in that location when you start PE?

I ask because one of the irritating behaviours of PE, IMHO, is the initial appearance. Whenever I startup PE, I have to resize and reposition the columns - and move the Process column from the far right.

Similar products of your competitors behave much more agreeably. Of course, yours has way more functionality. If we can figure out this Port 1900 puzzle.

 

You can put your colums as you want them and it should stay that way in memory.
But you did not find out yet which program is responsible for the many received packets?
Did you try the AutoStartViewer (from the free tools at DCS) or hijackthis to see if anything is started you might not be fully aware of?

Edit:
In the meantime the hijackthis list is posted here:
http://www.wilderssecurity.com/showthread.php?t=11407;start=0#lastPost

 

"You can put your colums as you want them and it should stay that way in memory." I am glad you agree "should" stay that way. Does it stay that way for you, after PE shutdown and startup? Is this a bug?

"But you did not find out yet which program is responsible for the many received packets? Did you try the AutoStartViewer (from the free tools at DCS) or hijackthis to see if anything is started you might not be fully aware of?"
I have several StartUp analysis routines. I run AA and SSD regularly, and did run HJT most recently. Nothing found yet. Which is why I would like to find out what is in the packets being received - I'm hoping that will provide a clue or two.

 

I kept the default order, changed colors, GUI size, colomn width, all is the same after reboot.

So you have no idea which service is running on that service host and if there are several different responsible for that?

From the DCS tools is another one APM, in case you can locate the culpit and there is another nice free tool
http://www.xmlsp.com/pview/prcview.htm
All to get the PID related to a process/service you recognize.
I don't like windows names yhem all srvhost.exe, why not just use the names and stop all that frustrating puzzling.
If you scroll through TDS process lists, does none show up the same PID? Some must do!

 

Hi nitecruzr,

For security purposes I would recommend that you disable the "Internet Gateway Device Discovery and Control Client" or block all traffic on port 1900 at your perimeter firewall. To disable the client you have to first apply XP's SP1a. Please refer to

http://support.microsoft.com/default.aspx?scid=kb;en-us;821980

If you were more interested in why/how/if PE was missing something you might want to try the following but it is not for the faint of heart.

You can download and install winpcap from

http://winpcap.polito.it/install/default.htm

Before rebooting download the single executeable 'windump' (which is the win32 port or *nix's tcpdump) from

http://windump.polito.it/install/default.htm

After a reboot, open your command prompt to whatever directory you placed windump and type

windump -D

This will return the interface IDs of anything on your system, you need to note the device number (single-digit, all the way to the left) of your active NIC

then type

windump -s 1514 -v -X -i # port 1900

replacing the # symbol with the device number you noted above

This will log the full packets to or from your host on port 1900 (whether source port or destination port). If you have that NIC plugged into a hub rather than a switch, it will also log activity on thos ports of your other machines. Once you are finished capturing you press CTRL+C then you can copy and paste from the command prompt window as needed. This log can be compared against the socketspy log on that socket to se what, if anything, is missed or misdiagnosed.

Hope this helps,

Dan

 

Other web discussions indicate port 1900 is uPNP, which is possible since I enabled uPNP on my router, to get my audio and video conversations to work in IM (MM / YM). But why would unknown hosts be sending me traffic thru that port??

This instance of Svchost lists 4 services:
LMHosts
RemoteRegistry
SSDPSRV
WebClient

I share your frustration, Jooske. Microshaft and their system designs frequently mystifies me - I'm always wondering whether they designed something one way to make it more secure, more stable, more efficient, or simply more mysterious??

BTW, its kewl to see an update to PrcView. I've been using that for a couple years.

Alphabet Soup: OK, I know what DCS is. But APM? TDS?

 

uPNP is related to SSDP but the latter is driven by the client I mentioned in my above post. I think you can safely remove the client without adversely impacting your devices but I am not entirely sure. Remember this is a discovery protocol and having these run accessible to the internet is bad news!

 

Advanced Process Manipulation,
http://www.diamondcs.com.au/index.php?page=apm
110kb full install, NT4/2K/XP only

http://diamondcs.com.au/forum/showthread.php?s=&threadid=1522
Here is some discussion about it.

It looks like some tool is spitting data to you, like the advertisement services in chatboxes and WorldTime and the like.
UDP data should be spyable.

As you have already many nice tools, i can only think of Faber Tools www.faberbox.com in which you might be able to locate that process and see if any advertiment dll or such a thing is responsible; i had the IPCserver on my system which i disbled by just renaming it and all worked fine so i finally removed that completely. Not sure if it came with WorldTime, but it's better off my system.
Just to name an example. In that time i had no PE yet
PrcView should be able to give about the same kind of info, but maybe by the way of representation something catches your eye.

 

OK. I know what the mysterious traffic comes from. But I would _really_ like to use Socket Spy to confirm it. I greatly hope that this inability can be resolved. There are also several design flaws which I will mention in passing, because they contributed to my confusion.

The traffic is UPnP enabled devices, in conversation with each other. There is something funky about bunny.globodom.com, the remote host that first caught my attention. That name resolves to a domain apparently located in Hyattsville MD, on Comcast. There is also a host in my ISPs address space with that name. The latter is one of the hosts that has been conversing with my port 1900 (port 1901 on my router).

Part of my confusion with that mysterious host was caused by a design deficiency not unique to PE - I have complained about this to developers of several other utilities like PE (but nowhere equal). In an attempt to reduce screen space usage (??), PE lets us see either host IP address OR host resolved name (but never both). I really hate that. When you are researching intrusions, it is sometimes helpful to see both ip addresses and host names at the same time. IMHO.

After several unsuccessful attempts to find a reference to ip address 68.50.177.37 (bunny.globodom.com in MD) in the logfile, I manually resolved (from ip address to name / location) all the remote hosts sending to my local port 1900. One of those hosts, 208.201.233.240, ALSO resolves to the name bunny.globodom.com. All hosts are apparently in my ISPs address space.

Anyway, based upon recommendations from numerous people, I disabled UPnP on my workstation. And all the traffic stopped.

I hope that this inability to successfully display traffic to port 1900 can be resolved.

I would like to mention other interface deficiencies, which are very irritating when using PE repeatedly. Is there a wish list for PE improvements in the forum, or elsewhere?

 

Hi nitecruzr, the MAIN display of Port Explorer will be saved with whatever positions you last have it on. Socket Spy doesnt save COLUMN positions or widths iirc, but it does save the overall socket spy window size. Is it the main display which doesn't save? Do you have any registry protection software on?

Check out HKEY_LOCAL_MACHINE\DIAMOND COMPUTER SYSTEMS\PORT EXPLORER in regedit.

Play around with the values that should be in there and see if you can alter the display of Port Explorer.

When you are spying on processes do you click the refresh button which updates the screen with all the latest packets captured? It doesn't auto update.

The weird thing is you are able to see the port 1900 activity in the WINDOW LOG which means they are passing correctly through Port Explorer and if you have enabled socket spy SUCCESSFULLY on that socket, it should write the packets to capture.bin . There is a possibility that maybe you are accessing the capture.bin file too much in Port Explorer and the DLL has inability to update it because the EXE has too much hold of it. So maybe also try closing down the socket spy utility whilst you are spying on it. Have you verified that when you spy on that port 1900 socket when you right click on it again and go to the socket submenu, the "Spying" menu item is ticked?

-Jason-

 

I resolved that bunny... thing twice and twice i got after portscans on 27374 from them in reply so this i really don't like. Of course i complained about that, as a whois and resolve should be a normal port 137 scan like people get hundreds an hour. Remarkeble at least.

Host name: pcp698257pcs.hyatsv01.md.comcast.net
IP address: 68.50.177.37
Alias(es): None

Host name: bunny.globodom.com
IP address: 208.201.233.240
Alias(es): None

Host name: pcp04222587pcs.macmb101.mi.comcast.net
IP address: 68.61.145.154
Alias(es): None

Host name: pcp053140pcs.brlngt01.nj.comcast.net
IP address: 68.45.249.104
Alias(es): None
68.61.145.154 US UNITED STATES MICHIGAN STERLING HEIGHTS COMCAST CABLE COMMUNICATIONS INC
68.45.249.104 US UNITED STATES NEW JERSEY TRENTON COMCAST CABLE COMMUNICATIONS INC
68.50.177.37 US UNITED STATES VIRGINIA WOODBRIDGE COMCAST CABLE COMMUNICATIONS INC
208.201.233.240 US UNITED STATES CALIFORNIA SEBASTOPOL SONIC.NET INC




So good you were able to stop it.
I heard complaints if on an XP you disable the uPnP you would no longer see the devices displayed in the listings, but then i think you could if necessary enable that temporary, is that true?

 

Hmm, maybe time to load the sub7 emu??
Dolf

 

Jason,

"Socket Spy doesnt save COLUMN positions or widths iirc, but it does save the overall socket spy window size. "
That's one of the problems with SS. Combine that with the fact that it identifies processes by process name/path (no PID!!), and the column where process name is too narrow (all I see is "C:\Windows\system3.." - this is useless). I can resize the column, but after I switch to Spy List and back again, the column is shrunk back.

"Check out HKEY_LOCAL_MACHINE\DIAMOND COMPUTER SYSTEMS\PORT EXPLORER in regedit."
I'll play with that and let you know.

"When you are spying on processes do you click the refresh button which updates the screen with all the latest packets captured? It doesn't auto update."
Yes, I used refresh. I was able to spy on some svchost.exe (see my picture in reply #8 in this thread), just NOT the one that owns port 1900.

"The weird thing is you are able to see the port 1900 activity in the WINDOW LOG which means they are passing correctly through Port Explorer and if you have enabled socket spy SUCCESSFULLY on that socket, it should write the packets to capture.bin . There is a possibility that maybe you are accessing the capture.bin file too much in Port Explorer and the DLL has inability to update it because the EXE has too much hold of it. So maybe also try closing down the socket spy utility whilst you are spying on it. Have you verified that when you spy on that port 1900 socket when you right click on it again and go to the socket submenu, the "Spying" menu item is ticked?"
I enabled both socket and process spying, repeatedly, both from right click in Socket List, and from manually adding process by PID. I closed and reopened SS repeatedly too. I enabled SS for multiple sockets just to ensure that SS works at all (again, see my reply #8 picture). SS plain does not work for this instance of svchost.

Jooske,

What you have done really makes me curious about the activities by bunny and its clones. Especially since one of the clones is serviced by my ISP, Sonic.net, which is generally very proactive about questionable activity like that. Makes me really wish SS could show me just what is going on with port 1900 too.

I'll see what changes show up with UPnP disabled. Since I use the GRC UnPnP utility, I can turn UPnP back on quickly, so shouldn't be a great problem there.

Is there a wish list for improvements needed? I really would like to contribute my recommendations.