Security Incidents mailing list archives
Re: Arp Warnings on @Home Network
From: "Forrester, Mike" <mforrester () HSACORP NET>
Date: Wed, 7 Feb 2001 12:53:28 -0700
First I want to apologize for beating a dead horse, but I'm still trying to get a full understanding of how this is happening (there are more logs at the end). I'll going to dig out Stevens (TCP/IP Illustrated) here shortly...
If I had to take a wild guess, I'd say that @home uses Cisco for their
routers, and not Macs. :) That's what I figured too, but hey, this is @Home. They seem to do some pretty odd stuff. I have two static IP's and they are on different subnets (one is on a /21 and the other a /24) which seems odd to me. BTW - doesn't this ip scheme make managing the network a bit more difficult than it should be? I'm never managed a network anywhere near their size, but this doesn't seem like a good practice to me, IMHO.
A decent attacker would forward the packet after he got it, and your
connection would still work, albeit sniffed. That's why I'm not too worried about it, but interested none the less.
That's actually the most interesting aspect of your post...what flavor of
@Home are you on? Out here, AT&T @Home doesn't seem to send packets down your wire if they aren't for you. I'm on an old COM 21 system and the cable modem I have routes all downstream traffic out the Ethernet port. The newer systems use cable modems that act as a learning bridge and only route packets that are destined for MAC addresses on the other side.
If you're able to sniff your neighbors, then a successful version of the
default router hijack would work just great for an attacker that knew what they are doing. But that's really only interesting to do as a way to sniff traffic.. which it seems is easier than that. Now, if one wanted to hijack connections... being a router in the middle helps a lot. Since I can only see the downstream, I can't get any passwords or other juicy info (the fact that one of my neighbors visits s3x () pe com on a regular basis is on no interest to me). However, I probably could if I tried to be the mail server. However, if they were telneting from work to their system at home, I could probably sniff the password.
That's about all you can do. Let us know what they do when you tell them
you've been sniffing traffic. :) You won't tell, will you? :)
BTW, if you're just trying to get the annoyance to go away, look at the
man pages for the ARP command. You should be able to hard-code the right MAC address. Yeah I thought about putting in a static entry in the arp table, but right now this is more fun. Maybe not for those on the list, but it is for me. Below is output from /var/log/messages: Feb 6 22:51:10 ironman /bsd: arp info overwritten for 24.1.8.1 by 08:00:07:c4:28:53 on fxp0 Feb 6 22:51:10 ironman /bsd: arp info overwritten for 24.1.8.1 by 00:01:63:f1:d8:80 on fxp0 Below is tcpdump -envv output (minus irrelevant traffic) that I logged while downloading files from ftp.openbsd.org and when the above messages were logged. Lines 1-5 show traffic happily going back and forth between my system and the gateway. Line 6 shows the arp broadcast by the Mac system. Lines 7-8 show more data going to my system from the gateway Line 9 shows system sending a response to the Mac (with no captured return packet). Line 10 shows the @Home router taking control back. Lines 11- 14 show the traffic back to normal. The part I don't understand is Line [6]. This appears to me to be an arp request by the Mac system to see if the ip address 24.1.14.32 is available for use. Why is this causing my OpenBSD box to change the MAC address in it's arp table? Mike 0:90:27:73:fa:ca - the MAC of my OpenBSD box 0:1:63:f1:d8:80 - the MAC of @Home's router 8:0:7:c4:28:53 - the MAC of the Mac :) [1]22:51:10.819066 0:90:27:73:fa:ca 0:1:63:f1:d8:80 0800 66: 24.1.x.y.16166
129.128.5.191.42408: . [tcp sum ok] ack 3394385 win 17376
<nop,nop,timestamp 23217 917238081> [tos 0x8] (ttl 64, id 14619) [2]22:51:10.824136 0:1:63:f1:d8:80 0:90:27:73:fa:ca 0800 1514: 129.128.5.191.42408 > 24.1.x.y.16166: . 3394385:3395833(1448) ack 1 win 10136 <nop,nop,timestamp 917238082 23217> (DF) (ttl 242, id 32334) [3]22:51:10.827563 0:1:63:f1:d8:80 0:90:27:73:fa:ca 0800 1514: 129.128.5.191.42408 > 24.1.x.y.16166: . 3395833:3397281(1448) ack 1 win 10136 <nop,nop,timestamp 917238082 23217> (DF) (ttl 242, id 32335) [4]22:51:10.827647 0:90:27:73:fa:ca 0:1:63:f1:d8:80 0800 66: 24.1.x.y.16166
129.128.5.191.42408: . [tcp sum ok] ack 3397281 win 17376
<nop,nop,timestamp 23217 917238082> [tos 0x8] (ttl 64, id 14501) [5]22:51:10.912669 0:1:63:f1:d8:80 0:90:27:73:fa:ca 0800 1514: 129.128.5.191.42408 > 24.1.x.y.16166: . 3397281:3398729(1448) ack 1 win 10136 <nop,nop,timestamp 917238091 23217> (DF) (ttl 242, id 32336) [6]22:51:10.944844 8:0:7:c4:28:53 ff:ff:ff:ff:ff:ff 0806 60: arp who-has 24.1.14.32 (ff:ff:ff:ff:ff:ff) tell 24.1.8.1 [7]22:51:10.950313 0:1:63:f1:d8:80 0:90:27:73:fa:ca 0800 1018: 129.128.5.191.42408 > 24.1.x.y.16166: . 3398729:3399681(952) ack 1 win 10136 <nop,nop,timestamp 917238095 23217> (DF) (ttl 242, id 32337) [8]22:51:10.952362 0:1:63:f1:d8:80 0:90:27:73:fa:ca 0800 1514: 129.128.5.191.42408 > 24.1.x.y.16166: . 3399681:3401129(1448) ack 1 win 10136 <nop,nop,timestamp 917238095 23217> (DF) (ttl 242, id 32338) [9]22:51:10.952450 0:90:27:73:fa:ca 8:0:7:c4:28:53 0800 66: 24.1.x.y.16166 > 129.128.5.191.42408: . [tcp sum ok] ack 3401129 win 17376 <nop,nop,timestamp 23218 917238091> [tos 0x8] (ttl 64, id 12395) [10]22:51:10.952509 0:1:63:f1:d8:80 ff:ff:ff:ff:ff:ff 0806 60: arp reply 24.1.8.1 is-at 0:1:63:f1:d8:80 (0:1:63:f1:d8:80) [11]22:51:10.954049 0:1:63:f1:d8:80 0:90:27:73:fa:ca 0800 1514: 129.128.5.191.42408 > 24.1.x.y.16166: P 3401129:3402577(1448) ack 1 win 10136 <nop,nop,timestamp 917238095 23217> (DF) (ttl 242, id 32339) [12]22:51:10.954147 0:90:27:73:fa:ca 0:1:63:f1:d8:80 0800 66: 24.1.x.y.16166
129.128.5.191.42408: . [tcp sum ok] ack 3402577 win 17376
<nop,nop,timestamp 23218 917238095> [tos 0x8] (ttl 64, id 4157) [13]22:51:10.969148 0:1:63:f1:d8:80 0:90:27:73:fa:ca 0800 1514: 129.128.5.191.42408 > 24.1.x.y.16166: . 3402577:3404025(1448) ack 1 win 10136 <nop,nop,timestamp 917238097 23217> (DF) (ttl 242, id 32340) [14]22:51:10.970044 0:90:27:73:fa:ca 0:1:63:f1:d8:80 0800 66: 24.1.x.y.16166
129.128.5.191.42408: . [tcp sum ok] ack 3404025 win 17376
<nop,nop,timestamp 23218 917238097> [tos 0x8] (ttl 64, id 7442)
Current thread:
- Arp Warnings on @Home Network Mike Forrester (Feb 06)
- Re: Arp Warnings on @Home Network Ryan Russell (Feb 07)
- Re: Arp Warnings on @Home Network Dragos Ruiu (Feb 07)
- Re: Arp Warnings on @Home Network Jose Nazario (Feb 07)
- Re: Arp Warnings on @Home Network Jose Nazario (Feb 07)
- Re: Arp Warnings on @Home Network Jose Nazario (Feb 07)
- Re: Arp Warnings on @Home Network Jose Nazario (Feb 07)
- Re: Arp Warnings on @Home Network Gordon Messmer (Feb 07)
- <Possible follow-ups>
- Re: Arp Warnings on @Home Network Forrester, Mike (Feb 07)
- Re: Arp Warnings on @Home Network Mathias Wegner (Feb 07)
- Re: Arp Warnings on @Home Network Forrester, Mike (Feb 09)