• RSS
  • Twitter
  • FaceBook

Security Forums

Log in

FAQ | Search | Usergroups | Profile | Register | RSS | Posting Guidelines | Recent Posts

Strange modem activity/resulting packet capture

Users browsing this topic:0 Security Fans, 0 Stealth Security Fans
Registered Security Fans: None
Post new topic   Reply to topic   Printer-friendly version    Networking/Security Forums Index -> Exploits // System Weaknesses

View previous topic :: View next topic  
Author Message
alt.don
SF Boss
SF Boss


Joined: 04 Mar 2003
Posts: 16777080


Offline

PostPosted: Tue Jul 15, 2003 7:24 pm    Post subject: Strange modem activity/resulting packet capture Reply with quote

This is in furtherance to the post of http://www.security-forums.com/forum/viewtopic.php?t=6744

What this post will try to do is explain some other fields that one normally sees in day to day traffic. The reason I chose to look at the below noted packets is that my modem light was blinking while I had no applications open ie: Internet Explorer, Outlook Express, and the such. This concerned me for the simple reason that my modem lights should not really be blinking if nothing is open to receive packets, but more importantly be sending them.

I happened to be in Windows XP when this happened so I fired up windump.exe to capture some packets, and see what these mystery packets were.

Seen as I have a switch to share my broadband access I did not bother copying any arp packets, as there would be quite a few arp(address resolution protocol) broadcasts.

The command syntax I used is as follows:

Code:
windump.exe –nXvs 1514 not arp


Where windump.exe is the name of the program used to collect the packets
- is syntax used to denote a command switch to follow
n means denote addresses in numerical format vice name ie: 192.169.2.1 vice say www.monkeylabs.ca
X means dump the outputted packets in both hex and ascii
v means dump all of the header information such as IP ID numbers, win size, amongst others
s denotes snaplength this is the amount in bytes that you will capture of the packet. The default is normally 1514 for ethernet
not this is a primitive used in building bpf style filters
arp this is the protocol arp, when specified with not this means do not collect any arp packets

windump.exe: listening on \Device\NPF_{0ED7C287-B0FE-41C9-9FA6-84A5932E3EB6}

Code:
09:22:29.464551 IP (tos 0x0), ttl 128, id 14572, len 160) 192.168.2.112.1040 > 19
2.168.2.1.1900: [udp sum ok] udp 132
0x0000  4500 000 8011 7b9f c0a8 0270                    E...8.....{....p
0x0010   c0a8 0201 0410 076c 008c 08eb 4d2d 5345        .......l....M-SE
0x0020   4152 4348 202a 2048 5454 502f 312e 310d        ARCH.*.HTTP/1.1.
0x0030   0a48 4f53 543a 2032 3339 2e32 3535 2e32        .HOST:.239.255.2
0x0040   3535 2e32 3530 3a31 3930 300d 0a4d 414e        55.250:1900..MAN
0x0050   3a20 2273 7364 703a 6469 7363 6f76 6572        :.[b]"ssdp:discover
0x0060   220d 0a4d 583a 2033 0d0a 5354 3a20 7572        "..MX:.3..ST:.ur
0x0070   6e3a 7363 6865 6d61 732d 7570 6e70 2d6f        n:schemas-upnp-o
0x0080   7267 3a73 6572 7669 6365 3a57 414e 4950        rg:service:WANIP
0x0090   436f 6e6e 6563 7469 6f6e 3a31 0d0a 0d0a         Connection:1[/b]....

09:22:29.464634 IP (tos 0x0, ttl 128, id 14573, len 161) 192.168.2.112.1040 > 19
2.168.2.1.1900: [udp sum ok] udp 133
0x0000   4500 00a1 38ed 0000 8011 7b9d c0a8 0270        E...8.....{....p
0x0010   c0a8 0201 0410 076c 008d a2f7 4d2d 5345         .......l....M-SE
0x0020   4152 4348 202a 2048 5454 502f 312e 310d        ARCH.*.HTTP/1.1.
0x0030   0a48 4f53 543a 2032 3339 2e32 3535 2e32        .HOST:.239.255.2
0x0040   3535 2e32 3530 3a31 3930 300d 0a4d 414e        55.250:1900..MAN
0x0050   3a20 2273 7364 703a 6469 7363 6f76 6572        :.[b]"ssdp:discover
0x0060   220d 0a4d 583a 2033 0d0a 5354 3a20 7572        "..MX:.3..ST:.ur
0x0070   6e3a 7363 6865 6d61 732d 7570 6e70 2d6f        n:schemas-upnp-o
0x0080   7267 3a73 6572 7669 6365 3a57 414e 5050        rg:service:WANPP
0x0090   5043 6f6e 6e65 6374 696f 6e3a 310d 0a0d          PConnection:1[/b]...
0x00a0   0a                                                                           ...


As noted in the above, 2 udp broadcast packets were sent before a response was received, as evidenced by the 2 other packets seen below. I will not spend a great deal of time covering the header metrics again except for a few which were not seen in the other packet trace.

The one’s I will cover and explain are as follows:

tos 0x0 This means that the type of service (tos) is set to 0. This means that there is no "type of service" set for this packet. Please see the following noted url for an explanation of tos values http://www.zvon.org/tmRFC/RFC1349/Output/chapter4.html
Of note as well here is the 0x0 what this means is that the 0x signifies that the following value after the 0x will be in hexadecimal vice just plain decimal. Just in case you were wondering. Be aware also that 0 in hex equates to 0 in decimal as well.

The ttl value and the IP ID fields have already been explained.

len 160 This relates to the overall size of the packet itself as measured in bytes. As seen above in the hex output 4500 is the first series of numbers and letters in the packet itself. It is seen on line 0x0000 in the very first packet. Ie: I also bolded it as well. These 4 characters actually represent 2 bytes of information or 16 bits as 1 byte is composed of 8 bits. So if you count across and all the way down you will notice that the entire packet length is indeed 160 bytes. Of note here is that you start counting from 0 and not 1. So 45 is actually byte 0 and you start counting up from there.
So what we see above is 192.168.2.112 sending out a udp broadcast packet to the switch itself to see if there are any pnp services that it can access and thereby “discover”.

Code:
09:22:29.469379 IP (tos 0x0, ttl 64, id 16086, len 56) 192.168.2.1 > 192.168.2.1
12: icmp 36:192.168.2.1 udp port 1900 unreachable
0x0000   4500 0038 3ed6 0000 4001 b62d c0a8 0201        E..8>...@..-....
0x0010   c0a8 0270 0303 e809 0000 0000 4500 00a0        ...p........E...
0x0020   38ec 0000 8011 7b9f c0a8 0270 c0a8 0201         8.....{....p....
0x0030   0410 076c 008c 08eb                                            ...l....

09:22:29.470184 IP (tos 0x0, ttl 64, id 16088, len 56) 192.168.2.1 > 192.168.2.1
12: icmp 36: 192.168.2.1 udp port 1900 unreachable
0x0000   4500 0038 3ed8 0000 4001 b62b c0a8 0201        E..8>...@..+....
0x0010   c0a8 0270 0303 4dfc 0000 0000 4500 00a1        ...p..M.....E...
0x0020   38ed 0000 8011 7b9d c0a8 0270 c0a8 0201        8.....{....p....
0x0030   0410 076c 008d a2f7                                            ...l....


What we see above here is icmp (internet control message protocol) in action. This protocol is used to convey error messages back to the originating ip address to let it know of a network problem.
ICMP itself though piggbacks a ride using IP (internet protocol) and will also take the first 8 bytes after the IP message ends. This is done so that the port numbers and such can be included in the icmp message itself. This way the originating machine who sent the packet will know what went wrong.

We now see some values we have not seen before, such as the following:

icmp 36 This means that the icmp packet itself is 36 bytes long. This makes sense if you count the actual number of packets as well. It comes out to 56, and when 20 is subtracted for the ip header of 20 bytes it equals 36.

udp port 1900 unreachable This is the actual error message itself. This means that port 1900 has no service running on it so it unreachable, as it were.

What really happened here is that the switch I have received this packet, and as it was handed up the tcp/ip stack it choked on layer 3 ie: network layer IP. This layer saw the packet was sending to port 1900 udp, and the stack realized it has no such service on that port. The stack then generated an icmp message which we see above and sent it back to the originator to let it know.

I have included a couple of references below which or may not interest you. They are about the upnp protocol, and some vulnerability stuff on it. I have also included a link on the tos field in the ip header. I sincerely hope this was of some benefit to you. If part of this was unclear please post back to this thread or pm me.
Back to top
View user's profile Send private message Visit poster's website
13x
Just Arrived
Just Arrived


Joined: 26 Mar 2003
Posts: 0


Offline

PostPosted: Mon Dec 22, 2003 10:59 pm    Post subject: Reply with quote

Hi

Firstly, i would like to thank you for such a wonderful tutorial. Now for some questions Smile .. hope you won't mind.

Home LAN Setup :
Cable Modem --> Linksys Router --> Test PC

Cable Modem specs : Motorolla Surfboard SB3100
Linksys Router specs : 4-port BEFSX41 ( built in switch )

For some reason, the activity light on my cable modem keeps on blinking. The WAN diagnostic light on the router also blinks when the cable modem light blinks. I tried doing what you mentioned here, but windump doesn't seem to work always. In some cases, it captures a few packets, though the light keeps on blinking all the time.

Here's a few sample packets captured. ( none of the applications were working atm )
Code:

02:18:32.941735 IP (tos 0xc0, ttl 1, id 0, len 28) 192.168.100.1 > 224.0.0.1: igmp query v1
0x0000    45c0 001c 0000 0000 0102 b475 c0a8 6401   E..........u..d.
0x0010    e000 0001 1100 eeff 0000 0000 0000 0000   ................
0x0020    0000 0000 0000 0000 0000 0000 0000        ..............
02:18:40.936468 IP (tos 0x0, ttl 1, id 35597, len 32) 192.168.1.3 > 239.255.255.250: igmp v1 report 239.255.255.250optlen=4 RA
0x0000    4600 0020 8b0d 0000 0102 e824 c0a8 0103   F..........$....
0x0010    efff fffa 9404 0000 1200 fe04 efff fffa   ................
02:18:40.936807 IP (tos 0x0, ttl 150, id 35597, len 60) 192.168.1.1 > 192.168.1.3: icmp 40: 239.255.255.250 protocol 2 unreachable
0x0000    4500 003c 8b0d 0000 9601 165f c0a8 0101   E..<......._....
0x0010    c0a8 0103 0302 a6d8 0000 0000 4600 0020   ............F...
0x0020    8b0d 0000 0102 e824 c0a8 0103 efff fffa   .......$........
0x0030    9404 0000 1200 fe04 4600 0020             ........F...


Any idea why windump captures a few packets even though the activity light blinks all the time ?

Thank you
Back to top
View user's profile Send private message
alt.don
SF Boss
SF Boss


Joined: 04 Mar 2003
Posts: 16777080


Offline

PostPosted: Tue Dec 23, 2003 12:24 am    Post subject: Reply with quote

Hello there 13x, have you had any driver issues on your computer recently? I ask this because windump definitely should capture everything that is being sent to your computer. Can you paste here what the syntax was that you used to invoke windump? The linksys is a no go as it has very limited logging capabilities iirc. I suppose it is possible that the light that is blinking is faulty but that is unlikely, however it must still be considered. Why not run a test on your box? Send it some packets and then log what it was that your received to confirm or deny your suspicions.
HTH, and if not post back.
Back to top
View user's profile Send private message Visit poster's website
13x
Just Arrived
Just Arrived


Joined: 26 Mar 2003
Posts: 0


Offline

PostPosted: Tue Dec 23, 2003 10:14 am    Post subject: Reply with quote

Quote:
have you had any driver issues on your computer recently?

I recently downloaded the latest alpha version of windump and winpcap 3. Before this i had the 2.3 version of winpcap. Anyway, i uninstalled that before installing v3.0
Quote:
Can you paste here what the syntax was that you used to invoke windump?

windump -nXvs 1514 not arp
Quote:
The linksys is a no go as it has very limited logging capabilities iirc. I suppose it is possible that the light that is blinking is faulty but that is unlikely, however it must still be considered.

Both the activity light on the modem as well as the the WAN Diagnostic light on the router keeps on blinking. ( not contuniosly, but in a discrete manner )
Quote:
Why not run a test on your box?

Windump is properly capturing all the packets when i visit sites and such. I tried telnetting to a host and windump was able to capture the packets. So i guess it's not a problem with drivers.

After plugging the cable modem back on, i ran windump for 5 minutes and it captured 8 packets.
Code:

13:19:45.615859 IP (tos 0xc0, ttl 1, id 0, len 28) 192.168.100.1 > 224.0.0.1: igmp query v1
0x0000    45c0 001c 0000 0000 0102 b475 c0a8 6401   E..........u..d.
0x0010    e000 0001 1100 eeff 0000 0000 0000 0000   ................
0x0020    0000 0000 0000 0000 0000 0000 0000        ..............
13:19:49.297371 IP (tos 0x0, ttl 1, id 28081, len 32) 192.168.1.3 > 239.255.255.250: igmp v1 report 239.255.255.250optlen=4 RA
0x0000    4600 0020 6db1 0000 0102 0581 c0a8 0103   F...m...........
0x0010    efff fffa 9404 0000 1200 fe04 efff fffa   ................
13:19:49.297741 IP (tos 0x0, ttl 150, id 28081, len 60) 192.168.1.1 > 192.168.1.3: icmp 40: 239.255.255.250 protocol 2 unreachable
0x0000    4500 003c 6db1 0000 9601 33bb c0a8 0101   E..<m.....3.....
0x0010    c0a8 0103 0302 a6d8 0000 0000 4600 0020   ............F...
0x0020    6db1 0000 0102 0581 c0a8 0103 efff fffa   m...............
0x0030    9404 0000 1200 fe04 4600 0020             ........F...
13:22:05.026456 IP (tos 0x0, ttl 128, id 28082, len 237) 192.168.1.3.138 > 192.168.1.255.138: [udp sum ok] udp 209
0x0000    4500 00ed 6db2 0000 8011 47fb c0a8 0103   E...m.....G.....
0x0010    c0a8 01ff 008a 008a 00d9 131d 110a 83c3   ................
0x0020    c0a8 0103 008a 00c3 0000 2045 4f45 4a45   ...........EOEJE
0x0030    4845 4946 4545 4645 4d45 4743 4143 4143   HEIFEEFEMEGCACAC
0x0040    4143 4143 4143 4143 4141 4100 2041 4241   ACACACACAAA..ABA
0x0050    4346 5046 5045 4e46 4445 4346 4345 5046   CFPFPENFDECFCEPF
0x0060    4846 4445 4646 5046 5041 4341 4200 ff53   HFDEFFPFPACAB..S
0x0070    4d42 2500 0000 0000 0000 0000 0000 0000   MB%.............
0x0080    0000 0000 0000 0000 0000 0000 0000 1100   ................
0x0090    0029 0000 0000 0000 0000 00e8 0300 0000   .)..............
0x00a0    0000 0000 0029 0056 0003 0001 0001 0002   .....).V........
0x00b0    003a 005c 4d41 494c 534c 4f54 5c42 524f   .:.\MAILSLOT\BRO
0x00c0    5753 4500 0c00 a0bb 0d00 5641 4c48 414c   WSE.......NALIET
0x00d0    4c41 0000 0000 0000 0100 030a 0010 0080   TT..............
0x00e0    b4fe 0b02 4e49 4748 5445 4c46 00          ....DRAGONLD.


Windump keeps on capturing these 3 packets.

A few questions Smile
1) What significance does 224.0.0.1 and 239.255.255.250 have ?
2) What does RA in the IGMP packet mean ?

Thank you
13x
Back to top
View user's profile Send private message
b4rtm4n
Trusted SF Member
Trusted SF Member


Joined: 26 May 2002
Posts: 16777206
Location: Bi Mon Sci Fi Con

Offline

PostPosted: Tue Dec 23, 2003 12:51 pm    Post subject: Reply with quote

240.255.255.250 is the UPNP multicast group.

Your system 192.168.1.3 (XP or Me?) is sending a upnp multicast reqest and 192.168.1.1 (router?) is responding saying it doesn't understand the protocol.

The upnp forum has the specifications but I defy any of you to make sense of them Laughing

224.0.0.1 is a local network group membership request comming from host 192.168.100.1 (you running virtual machines ??). This is a standard IGMP message and not associated with upnp.

Don't know what the RA option is. Can't seem to find a reference to it. It may be specific to upnp.
Back to top
View user's profile Send private message Send e-mail
13x
Just Arrived
Just Arrived


Joined: 26 Mar 2003
Posts: 0


Offline

PostPosted: Tue Dec 23, 2003 1:33 pm    Post subject: Reply with quote

192.168.100.1 - Cable modem
192.168.1.1 - Linksys router
192.168.1.3 - XP

I thought i had disabled upnp on my XP box Shocked

Could someone please tell me a little more on the 224.0.0.1 address.

Thank you
13x
Back to top
View user's profile Send private message
b4rtm4n
Trusted SF Member
Trusted SF Member


Joined: 26 May 2002
Posts: 16777206
Location: Bi Mon Sci Fi Con

Offline

PostPosted: Tue Dec 23, 2003 4:09 pm    Post subject: Reply with quote

This multicast explanation from the Linux multicasting howto explains the whole multicast concept quite well and defines 224.0.0.1 as
Quote:
224.0.0.1 is the all-hosts group. If you ping that group, all multicast capable hosts on the network should answer, as every multicast capable host must join that group at start-up on all it's multicast capable interfaces.


Quote:
13:19:45.615859 IP (tos 0xc0, ttl 1, id 0, len 28) 192.168.100.1 > 224.0.0.1: igmp query v1

ttl 1 means that this is a local subnet multicast (see the howto - it explains this too).
The cable modem is probably a multicast capable device that is trying to find other multicast enabled devices on the same subnet (192.168.100.0/24).
Back to top
View user's profile Send private message Send e-mail
qqtortqq
Just Arrived
Just Arrived


Joined: 02 Apr 2005
Posts: 0


Offline

PostPosted: Sat Apr 02, 2005 10:11 pm    Post subject: Reply with quote

My cable modem acts like this too. I have always assumed that this is because cable modem networks are not immediately switched at the neighboorhood level. You are not only getting packets destined for your computer, but all your neighbors as well. Your modem sends all packets to your router, which in turn recognizes that the packets aren't meant for your network, and discards them. You could test this by connecting your computer directly to the cable modem and dumping packets to see what you see. Make sure your program can capture ALL packets that the interface sees.
Back to top
View user's profile Send private message AIM Address Yahoo Messenger
alt.don
SF Boss
SF Boss


Joined: 04 Mar 2003
Posts: 16777080


Offline

PostPosted: Sat Apr 02, 2005 10:26 pm    Post subject: Reply with quote

My cable connection only receives packets destined for it, and does not have the ability to see any other packes on my cable segment. If your ISP is set up that way it is a pretty horrible security mistake for them to have made.
Back to top
View user's profile Send private message Visit poster's website
tutaepaki
Trusted SF Member
Trusted SF Member


Joined: 02 May 2002
Posts: 3
Location: New Zealand

Offline

PostPosted: Sun Apr 03, 2005 10:40 pm    Post subject: Reply with quote

Beause cable is equivilent to a shared ethernet, its the cable modem doing the filtering, and as the activity light on the surfboard is Cable activity, not the inside LAN activity, the light is flickering constantly, but most of the traffic is filtered by the modem, and you never see it.
Back to top
View user's profile Send private message
Display posts from previous:   

Post new topic   Reply to topic   Printer-friendly version    Networking/Security Forums Index -> Exploits // System Weaknesses All times are GMT + 2 Hours
Page 1 of 1


 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Community Area

Log in | Register