UDP Port Scan on HP all-on-one printers [CLOSED]

[Guest]

[jlitzie]

Grue155,

I ran the command line test after reinstalling Comodo to match up times for the UDP port scan block. There's a block in the log:

Date/Time :2007-10-31 19:19:30
Severity :High
Reporter :Network Monitor
Description: UDP Port Scan
Attacker: 192.168.1.50
Ports: 2828, 3084, 4364, 62731, 62987, 63243, 63499, 63755, 64011, 64267, 64523, 64779, 65035, 65291, 12, 268, 524, 780, 1036, 1292, 1548, 1804, 2060, 2316, 2572, 10352, 59478, 65374, 65535, 21899, 33548, 6242, 65024, 9026, 17027, 9312, 3723, 5631, 35324, 63344, 23902, 2242, 52224, 52428, 52428, 65419, 35669, 33772, 5356, 17803
The attacker has been temporarily blocked

And the attached Wireshark file being written to during the block. Look at the log around frame 9370 (time was 19:19:29:983989000).

There was an earlier block, contained in the same file, around frame 3644.

Date/Time :2007-10-31 19:17:25
Severity :High
Reporter :Network Monitor
Description: UDP Port Scan
Attacker: 192.168.1.50
Ports: 35602, 35858, 36114, 36370, 36626, 36882, 37138, 37394, 37650, 37906, 31762, 32018, 32274, 32530, 32786, 33042, 33298, 33554, 33810, 34066, 34322, 34578, 34834, 35090, 35346, 49152, 21331, 17805, 20720, 5631, 35116, 63344, 18059, 33632, 9448, 19853, 35312, 8264, 19851, 35592, 51158, 7232, 30526, 63344, 16582, 57347, 5631, 35324, 63344, 829
The attacker has been temporarily blocked

Hopefully the information is helpful.

Using the default settings on the Attack and Detection dialog except that I reduced the time to leave the port blocked down to 1 minute, I'm getting a block about every two minutes.

[grue155]

Oh my. 5 minutes worth of capture data, and it fills up a full 1025k file, with just under 10 000 packets. For the benefit of anybody considering downloading the file, that's what you get.

Two things stand out...

One, the HP monitor software is insane. It doesn't seem to have an "off" switch. It queries and queries and queries and queries and queries. Just as fast as it can. And the printer, being a good little printer, answers every one of them. This kind of behaviour, I would classify as an HP bug against their director/manager software. It's not a bug with the printer.

And two... Congratulations, it looks like you've tripped a CFP bug. I did a check of what ports are actually being used, and saw a rollover at frames 4167 and 4168. The highest port number in use is 5000, and rolls back around to 1025. CFP reporting ports above 5000, and below 1025, is just not right. I'm inclined to believe this is some kind of data overrun, and the ports listed in the CFP port scan log are actually some kind of memory dump.  I need to sit back and think a bit more, but right now I'm strongly suspecting there's going to be a PR attached to this topic.

Thank you for the data!

Quick thought, have you tried using packet thresholds of 300 packets/sec or higher for the flood and port scan checking? There's some cutoff point where CFP shouldn't log these scans, and its going to be a fairly high number, or some special value like 0 or -1.

[jlitzie]

I did try bumping the numbers up in the UDP Flood fields when I first began reporting, but in reality, I'm really not sure which ones to change. Is it just the UDP Flood Traffic Rate and Port Scan probing rate?
 

[grue155]

For the moment, I'd suggest treating the two settings as being the same thing. Once some kind of threshold gets established, then one of the values can be tweaked up or down to see what happens. I don't know what interaction there is, if any, between the two settings. In trying to find something that works, it's simpler to just treat them as one variable.

I'm on the end of my day, so I'll have to pick this up tomorrow.

[grue155]

I just did an eyeball check for HP updates for "HP Photosmart 2575". That shows there are a bunch of software updates, 6 listed as critical, 2 of which are diagnostics and performance related. The descriptions are remarkably uninformative about what the update is about. I don't know if the PC installed software is at current version, so that would be something to check. At worst, opening up a trouble report with HP about excessive SNMP traffic might give some solutions from their perspective.

In reading back early in the topic, Soya mentioned the max threshold number supported is 2000. I'd suggest starting there, and moving the number down by factors of 2 (binary search) to find where the problem starts occuring. If the 2000 doesn't turn off the warnings, then there is another CFP issue that may need a PR. The Wireshark capture is showing SNMP traffic in the 150/sec range.

I haven't finished my eyeball of the CFP ports scan, but one things stood out very quickly: the ports differ by 256, in ascending sequence. Expressed in 16 bit hex format, that looks like either Unicode strings, or a memory management "reuse trap" pattern.

[jlitzie]

I make sure I'm up to date with the software. Plus, HP has as service running that checks as well. Speaking of which, while I'm typing this, a new one popped up for install.

I set the fields to 300 last night before getting off the computer for the night and there weren't any port scans when I checked this evening. That's about 20 hours. That being said, I rebooted my computer and upon startup a port scan showed up. But just one.

I'll leave it like it is for a bit and see what happens. I'll install the HP update now:>)

[grue155]

Date/Time :2007-10-31 19:19:30
Severity :High
Reporter :Network Monitor
Description: UDP Port Scan
Attacker: 192.168.1.50
Ports: 2828, 3084, 4364, 62731, 62987, 63243, 63499, 63755, 64011, 64267, 64523, 64779, 65035, 65291, 12, 268, 524, 780, 1036, 1292, 1548, 1804, 2060, 2316, 2572, 10352, 59478, 65374, 65535, 21899, 33548, 6242, 65024, 9026, 17027, 9312, 3723, 5631, 35324, 63344, 23902, 2242, 52224, 52428, 52428, 65419, 35669, 33772, 5356, 17803

Having had some time to examine that set of ports listed, and having a hunch this could be a data overrun, I rewrote the port numbers in hex (knowing that port numbers are unsigned 16-bit integers). That list of ports becomes the following.

0b0c 0c0c 110c f50b f60b f70b f808 f90b fa0b fb0b fc0b fd1f fe0b ff0b 000c 010c 020c 030c 040c 050c 0606 070c 080c 090c 0a0c

2870 e856 ff5e ffff 558b 830c 1862 fe00 2342 4283 2460 0e8b 15ff 89fc f770 5d5e 08c2 cc00 cccc cccc ff8b 8b55 83ec 14ec 458b

That second line has a strong resemblence to x86 machine code. However, a search comparison of the files in the install directory doesn't find any matches. So if it is excutable code, it is either dynamically produced, or has been modified by the program loading process. I haven't tried doing any disassembly to confirm that is actually machine code, as I don't have the tools to properly do a disassembly.

If nobody has any objections, I'll put this in as a Comodo support ticket, and refer the description back to this topic. It'll probably be this weekend before I get the opportunity to lodge the ticket.

[Soyabeaner]

Go ahead.  We're out of ideas.  FYI the devs won't reply until version 3 is finalized.  Even then, I have a feeling that most tickets will be responded to upgrade to the new version to see if the issue is resolved.

[grue155]

I've lodged two support tickets on the things that have turned up. For anybody who's interested:

Subject: Legitimate SNMP traffic identified as packet flood
Ticket:     WUA-285063

and

Subject: Machine code exposed in report
Ticket:    XXX-898548

Both tickets have pointers back to this forum topic.

[jlitzie]

Grue155,

Thanks again for all the time you spent on this. Hopefully the issue will get resolved.

[grue155]

CFP 3.0 RC1 got released a few days ago. And, as Soyabeaner points out, the most likely ticket feedback to a 2.4 problem is going to be "upgrade".

This kind of SNMP packet storm would be a great test for 3.0 RC1, and it would give a bit of incentive to get issues resolved so far as CFP is concerned. At worst, it's some new support ticket numbers, and at best, everything works as it should. Game?

[jlitzie]

Yeah, I can give 3.0 a shot.

Out of town until this weekend. I'll see about downloading and installing then.

BTW, I set the UDP traffic and port probing rates to 350 and it seems t have stopped the port scan blocking.

[grue155]

There was a reply to the tickets in the email I looked at today. Same message for both tickets:

Date: Wed, 21 Nov 2007 17:57:00 +0000
Message-ID: <jrvb70.6mt6np[ at ]support>
Subject: [SUPPORT #XXX-898548]: Machine code exposed in report
From: "Comodo Support" <desktopsupport[ at ]>
Reply-To: desktopsupport[ at ]
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit

Hi,

Sorry for the inconvenience caused.

Now You can download the latest release 3.0.13.268 from  http://personalfirewall.comodo.com and uninstall the existing,  restart the computer and install the latest.

It will fix your issue.

For more info, Please do refer our forum..
http://forums.comodo.com/feedbackcommentsannouncementsnews/comodo_firewall_pro_3_has_been_released-t14915.0.html

Regards
Malcolm
Technical Support

Looks like Soyabeaner's earlier comment was pretty much square on.

If there's no objection, I'll go ahead in the next couple of days and mark this topic as closed. If v3 doesn't resolve the problem, then we'll have another go in the new v3 help forum.

[jlitzie]

Hi Grue,

I've just gotten 3.0 installed (3.0.13.268) and haven't seen the port scan issue yet, although I haven't been running it that long yet. So far I like it.

I am monitoring a VPN issue for 3.0 though.
http://forums.comodo.com/help_for_v3/cant_connect_with_xps_vpn_client_help-t15241.0.html

It specifies XP VPN, but I cannot connect using Nortel Extranet VPN.

I'll try a couple more things and then comment in the 3.0 thread.

Thanks,

[grue155]

Alrighty, I'll go ahead an mark this as closed, for CFP v2.4

[Tags:]