Suspicious tcp connection attempts by InHost of utorrent.exe

[FUBARinSFO]

Hi:

Using v1.8 utorrent, I'm looking at some suspicious connections being attempted by the program itself (utorrent.exe). Targets can be seen with 'netstat -b -t -p tcp' at a command window (running in Windows 2003 Server).

Pinging the targets shows some are dead, but others are alive:

Pinging kbpauk.ru [195.178.208.158] -- OK

Pinging cia.com [209.197.145.145] -- OK DNS, but request timed out

Pinging www.mtu-net.ru [62.118.255.3] -- OK

85-89-100-254.kbpauk.ru -- could not find host

Pinging i209-195-82-173.cia.com [209.195.82.173] -- OK

ppp91-78-74-134.pppoe.mtu-net.ru -- could not find host

ns.km20441.keymachine.de -- OK

I'm a n00b on utorrent, so perhaps this is legitimate activity. The result of the netstat command is shown below. If someone could explain to me what might be going on here I would appreciate it.

-- Roy Zider

8/14/2008 19:19:54 lsz

Diagnosing µTorrent problems

(µ = Alt-0181)

Pinging tracker.torrentleech.org [89.248.163.199]

Some strange addresses in netstat. Utorrent is PID 2712 below.

-------------------------------------------------------------------------------------

C:\Documents and Settings\Administrator>netstat -b -t -p tcp

Active Connections

Proto Local Address Foreign Address State PID

Offload State

TCP mpx:1218 85-89-100-254.kbpauk.ru:20999 SYN_SENT 2

712 InHost

[uTorrent.exe]

TCP mpx:1220 i209-195-82-173.cia.com:13401 SYN_SENT 2

712 InHost

[uTorrent.exe]

TCP mpx:1221 85-89-100-254.kbpauk.ru:20999 SYN_SENT 2

712 InHost

[uTorrent.exe]

TCP mpx:3771 cf-in-f103.google.com:http CLOSE_WAIT 1488

InHost

[GoogleToolbarNotifier.exe]

TCP mpx:4998 cf-in-f104.google.com:http CLOSE_WAIT 1232

InHost

[iexplore.exe]

TCP mpx:17947 81.69.2.204:1585 TIME_WAIT 0

InHost

TCP mpx:17947 ns.km20441.keymachine.de:1079 TIME_WAIT 0

InHost

TCP mpx:17947 ns.km20441.keymachine.de:4917 TIME_WAIT 0

InHost

TCP mpx:17947 ns.km20441.keymachine.de:4981 TIME_WAIT 0

InHost

TCP mpx:17947 ns.km20441.keymachine.de:4937 TIME_WAIT 0

InHost

TCP mpx:17947 ppp91-78-74-134.pppoe.mtu-net.ru:46568 TIME_WAI

T 0 InHost

TCP mpx:17947 ppp91-78-74-134.pppoe.mtu-net.ru:46566 TIME_WAI

T 0 InHost

TCP mpx:17947 ppp91-78-74-134.pppoe.mtu-net.ru:46397 TIME_WAI

T 0 InHost

TCP mpx:17947 213.236.251.115:2239 TIME_WAIT 0

InHost

C:\Documents and Settings\Administrator>

-------------------------------------------------------------------------------------

[thelittlefire]

Your uTorrent port is 17947? If so those are all peers you connect to.

[FUBARinSFO]

Some of them are 17497, but others are lower -- 1218, 1220, 1221 -- I interpreted these as outbound connection attempts by utorrent. Is that not correct? The PID of 2712 links them all to utorrent.

[DreadWingKnight]

Inbound connections are always on your listen port.

The outbound connections are to do with your client connecting out.

cia.com is an internet provider.

Honestly, you're suspicious of nothing.

[FUBARinSFO]

DreadWingKnight said: The outbound connections have to do with your client connecting out.

Precisely why I posted this query. I'm not concerned with the inbound connections on this post. To whom/why is it attempting to reach these foreign addresses?

[Firon]

Because that's how you connect to other peers...

[FUBARinSFO]

Firon: port 17497 is the utorrent port, which allows utorrent to travers the NAT/firewall. None of the other ports above are allowed and will be blocked/ignored, afaik. If utorrent is somehow using these other ports to map/loop to port 0 and thence through 17497, that would be a different story.

In any case, these ports would be picked up an blocked by ZoneAlarm if I were running it, as a "call home" leak that would have to be expressly permitted, afaik. That's why it does that -- to trap suspicious outbound connection attempts.

If utorrent is rerouting these non-17497 ports somehow through 17497 eventually, I would appreciate knowing how to view this specific mapping to know that the port connection chain is secure. It still doesn't clear the connection attempts, but at least it clarifies for me the use by utorrent of these support ports.

[Firon]

The port you chose is only used for incoming connections. Outgoing uses a random port in the ephemeral port range (normally 1024-5000).

[FUBARinSFO]

Firon : so that means that the NAT is blocking port forwarding incoming only, and allowing all outgoing? ZoneAlarm does not do that, but will use the PID to identify the parent process and allow all outgoing after permission (not using ZAP at the moment).

In any case I've bypassed the NAT and connected straight to the bridge/modem to see if I can solve some other problems, but haven't been able to.

My only concern in this post was the possible existence of attempts to access bad locations. This is my first experience with utorrent. It is not open code, it's free, and has access to the www. That is not generally good in this environment. I'm not even to the point where I subscribe to trust, but verify. I don't even trust.

[Firon]

Yes. Routers only block incoming. They don't filter egress.

[Switeck]

"I'm not even to the point where I subscribe to trust, but verify. I don't even trust."

Then DON'T trust Zone Alarm either!:

http://forum.utorrent.com/viewtopic.php?pid=271767#p271767

[FUBARinSFO]

Switek: Reading your link (and filtering out the noise) I can see that there is some controversy about ZoneAlarm. I haven't used it in some time, but when I did I found it to be the only program at the time that trapped outgoing connection attempts. But there have been problems with its interference with other programs (not unlike NOD32), so I'm using Windows Firewall at the moment and the firewall and NAT port forwarding on my router.

What helps is the post on you link that says that some of the users of utorrent are using packet sniffers on all new releases, for precisely the reason I posted this message in the first place. That's good to know. It would be even better if their results or clearances were posted in a special forum here, so that those of us new to the program have some comfort that a closed proprietary client like utorrent.exe is not in any way engaging in any suspicious behavior whatsoever.

[Switeck]

Longer-term beta-testers are using packet sniffers on uTorrent not so much because we expect malice as simple or crazy bugs.

uTorrent engages in a LOT of suspicious behavior...if you don't know what it's doing.

We get a post about uTorrent sending out emails about twice a week.

I even saw a post not too long ago about how RSS was generating a LOT of download traffic. Wasn't apparent that it was RSS doing that when the post was first made.

My links about Zone Alarm often concerned beta version...or specific versions long-since-updated. But it does point to a company history of caring little about its customers...and it never "came clean" about just what and why a Zone Alarm beta was making connections to outside servers. I lump them in the same category I put McAfee and Norton now. Hostile commercial software...from hostile commercial companies.

[FUBARinSFO]

Thanks.