Jump to content

Utorrent sending fake/malformed/fragmented UDP packets?


Getthings

Recommended Posts

Hi all

firstly many thanks to the writers of uTorrent, its superb!

Secondly, apologies if this has been posted before, I did a search for fragmented packets and found 1 thread where someone had to allow fragmented packets on their firewall to get a green light on uTorrent.

I have been using Comodo firewall for a few days and am very impressed with how much it can do and the information it gives on my connection.

Under the settings for Advanced Attack Prevention and Detection I have ticked the following (amongst others):

Block fragmented IP datagrams

Do Protocol Analysis

The Logs now report that many many packets are blocked as they are either fragmented IP packets (portless but it says using UDP) or fake/malformed UDP packets.

These packets are trying to leave my PC, the source IP is always my PC's IP.

The port in use by the UDP packets is my uTorrent port.

uTorrent is beavering away happily while this happens and I am suffering no issues at all using uTorrent, so...

Is this expected behaviour?

If you know why it will be much appreciated.

thanks

ps the log shows these packets have a "High" severity.

Link to comment
Share on other sites

just spotted at the end of the UDP log entries (viewed in a little window), it says

Reason: UDP packet length and the size on the wire (1486 bytes) do not match

Maybe the IP (using UDP) log entries are due to the same issue, they say

Reason: Fragmented IP packets are not allowed.

Every IP error is followed by a UDP error.

I get about 20 of these pairs of errors every minute.

edit: all are from my PC's IP to numerous other IP's that are repeated.

Link to comment
Share on other sites

Just in case it helps :)

My Router is a Netgear DG814, using the onboard NVidia LAN card from my Asus A8N-E motherbard. Latest NForce drivers (6.86).

Whats strange is this guy complained of the same thing with the M0n0wall Router but on inbound traffic only. It limited his uTorrent experience unless he allowed the packets.

http://forum.utorrent.com/viewtopic.php?id=8625

He states that when fragmented packets were allowed through, his download speed went up 30%.

I wonder if he did have an outbound fragmented issue as well ?

Why dont I detect inbound fragmented packets?

I am connected to 42 uTorrent clients (with one torrent), 34 of whic are latest version.

Edit 2: I do indeed receive incoming fragmented packets. I missed them purely by accident as I have to click on each entry to see what the reason is. The log appears to only be in memory, I cannot find it on the disk so I'm stuck with this method of viewing log entries.

For kicks, I just tried to allow the packets through. I had 186 active IP connections (70K/Sec on 8MBit) so wasnt maxed out for downloading but the uplink was saturated.

Allowing the packets didnt change anything, download speeds remained almost the same.

After 10 mins I have 185 connections.

for clarity, here is the error message again:

Reason: UDP packet length and the size on the wire (1486 bytes) do not match

thanks

edit:

A strange thing occured when I turned off the 2 filters to allow fragmented/malformed packets!

My log started to fill with blocked outbound connections (non local) from my port 137 (netbios).

Those filters could be preventing a netbios hole being exploited.

Re-enabling the filters saw an almost immediate stop to the log entries for port 137.

Luckily the outbound packets were blocked anyway!

As the packets stop when I increase the filtering, it looks like they are provoked from the outside.

Wooo

In case it matters:

To my knowledge I dont have any nasties in the system.

I regularly use/update Avast!, Protowall, Adaware, Spybot (with teatimer enabled), Spycatcher, Spyware blaster and Spyware Guard.

Merged double post(s):

I'd better clarify my latest findings!

I turned on another firewall setting to verify the checksums of all packets.

Since then I only get fragmented incoming IP (no UDP) packets and NONE outgoing, IP or UDP like before.

Before enabling that setting, I was only getting outgoing fragmented IP+UDP packet pairs, NONE incoming.

I now only see incoming bad TCP checksum and incoming Fragmented IP packet errors in the log.

Perhaps I am under attack, these bad checksum/fragmented packets could be being altered on the way to me or are generated in the same way mine are.

These new logged packets are not using uTorrents port for incoming.

Perhaps they are processed and then hijack the uTorrent port to get out and spread whatever nastiness they bring when they arent blocked by the Checksum Filter?

The incoming packets could be responsible for the port 137 (netbios) packets trying to leave my network too?

after more thought, this looks like a nasty inside my PC.

If anyone spots errors and can correct what I am saying please do.

All ports are blocked incoming except my uTorrent port, verified this with many online tests.

The new incoming connections being blocked are using other ports.

The only way I can see those ports connecting through my hardware firewall is if my PC initiated the connection.

That sound slike something is in my PC.

Would you agree?

pls ignore the last post, the outgoing TCP/UDP fragmented packets etc have started again.

So with all the security filters active I now have the firewall detecting

Incoming:

Blocked fragmented IP packets, no port associated.

very few of these now.

Outgoing:

Blocked fragmented IP packets, no port associated

Blocked Fake or Malformed UDP packets, source is my uTorrent port

This looks like uTorrent really is the source of the bad packets.

I'm about to stop utorrent and see if the log traffic halts over the next half hour.

Its been over half an hour and I have between 1 and 3 outgoing packets per second average which are blocked with the message:

Access Denied, ICMP = Port Unreachable

No port is specified.

Undoubtedly this is due to my uTorrent port being closed now.

In the half hour that has passed, there has been a constant stream of attempted connections to a whole load of different IP's

ie:

71.98.87.213

203.198.91.28

218.175.36.54

218.166.105.103

61.220.148.20

60.165.48.108

60.52.21.150

80.213.81.36 .....

uTorrent was definitely closed down over 1/2hr ago (confirmed with task manager and the last 4 remaining utorrent connections were closed manually by me using Comodo firewall).

there are no other connections (netstat confirms this) so these packets are being generated by something on my PC that wants to use the uTorrent port.

So again I am back to thinking there is something else trying to get out from my PC.

Any thoughts please?

EDIT by silverfire: Not one but FOUR posts in a row? You clearly knew how to use the edit function, so someone needs to smack you upside the head with a book on forum etiquette before one of the admins decides to ban you for bad behavior.

Edit by Getthings:

Sorry I didnt realise that was an etiquette issue.

Link to comment
Share on other sites

heh

ok, I'll do that.

I last ran Hijack this about a week ago and it was clean.

This firewall (Comodo) is pretty cool, it also blocks TCP packets that use SYN ACK FIN (Invalid flag combination) which are a known way to get packets authenticated by many firewalls :)

now a bit later....

Hijackthis didnt report anything of interest.

(I deleted the log to make this more readable).

11:14am (UK)

I've observed some interesting behaviour.

1) after rebooting, without running uTorrent, many outgoing connection attempts are blocked (as before after stopping uTorrent).

I believe these are only acknowlegment packets for received packets.

It looks like the firewall blocks outgoing but not incoming packets when uTorrent isnt running.

So the last issue with continuous outgoing connections after closing uTorrent isnt a problem.

2) The fake/fragmented/malformed packets only start after I have started uTorrent.

I would say they are possibly...

a) uTorrent sending packets that are too big to be transmitted as a single packet (ie bigger than the MTU) so they get split into 2 packets somewhere but the size data becomes incorrect.

B) uTorrent labelling the size of some UDP packets wrong

c) uTorrent getting some UDP packet contents wrong

d) a vulnerability in uTorrent is being exploited and malcrafted packets are being sent

e) Torrent users or bots getting my IP by using bittorrent and proceeding to get info/hack.

This last one doesnt seem as likely as I am also sending fake/fragmented or malformed packets. This points the finger more at uTorrent.

3) To trap what is happening with the netbios connections I created a rule to block outbound netbios ports 136,137,138

My PC tried to send UDP packets out to numerous IPs on port 138, they were blocked and logged.

I changed the rule to block in/out ports 136,137,138

Torrent clients tried to connect to port 137 but are now blocked and logged.

Previously they did connect and up to 96k of traffic went!

Even with no netbios packets coming in, my PC still tries to send some netbios packets on port 138 to torrent clients IPs (while all incoming netbios packets are blocked).

Could this be caused by an exploited vulnerability in uTorrent?

Could these clients be modified clients designed to collect data?

Netbios requests shouldnt be able to get past my router so there would need to be a exploit in use to start the connection.

I decided to try and find out as much as I can.

These are actual clients I found trying to connect via netbios, blocked in the firewall log.

I cross checked the IPs with uTorrent and found the clients in use.

84.13.225.245 connecting via port 137 - Bitcomet 0101

650.53.74.72 connecting via port 137 - Bitcomet 0057

84.13.36.145 connecting via port 137 - Bitcomet 0101

203.106.251.168 connecting via port 137 - Bitcomet 0070

They all are looking to be Bitcomet clients.

So either they are all modified clients, Bitcomet does use a netbios hack or I am being probed by a torrent user/bot.

I havent found any evidence to support that Bitcomet does use netbios so for the moment that leaves a modded client/probe of some form or an exploited vulnerability in uTorrent.

Link to comment
Share on other sites

Its like the first one

my ip:138 -> bitcomet ip:whatever

Port 138 is used for outgoing, 137 for incoming netbios connections.

edit:

Let me try and make this a little clearer.

Something is making my machine talk via netbios.

My machine does use all other ports for uTorrent as it needs to, theres no restriction in that.

The communication via netbios only occurs when I use uTorrent and has been found to be coming from/to the same IP's as certain Bitcomet clients.

Link to comment
Share on other sites

  • 1 month later...

I'm having a similar problem to this, except in addition, my router also resets every 20-30 minutes. If I turn uTorrent off, the disconnects stop. The router firewall shows both SYN Floods and & Fragmented Packets (both of which stop when uTorrent is off). I've read up on the SYN Floods but haven't come across much in the way of preventing them.

Thoughts?

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...