Jump to content

Arp spoofing is not updating the MAC adress in the router


putte

Recommended Posts

Posted

I try to do  arpspoof -i wlan0 -t 192.168.1.1  192.168.1.100, to my own router. However when I check in the router the MAC address is not updated. Mu router is Asus RT-AC86U (with asuswrt-merlin latest )

I also tried to update it manually using: arp -s <ip> <mac>   # on the router
When I check with: arp -a i see it updated and set to PERM. However when I check in the router GUI, I still see the old MAC address.


The reason I want to do the above is to start the man in the middle attack(in arp spoof was run in different terminals):
sysctl -w net.ipv4.ip_forward=1
arpspoof -i wlan0 -t 192.168.1.1  192.168.1.100
arpspoof -i wlan0 -t 192.168.1.100  192.168.1.1
 

When trying to browse internet on my phone (192.168.1.100) it just the screen just freezes. However I think the problem is that the router MAC is not updated.

Posted

You need to do some reading on what ARP spoofing actually does.

It doesn't change the MAC address of a device, it changes the ARP tables of the devices you are poisoning.

Posted

What I meant is the MAC address in the ARP table. That is why I wrote I checked it with: arp -a. There I can see its updated but when I check in the router for the IP-address that devices is using in my network I see the MAC address is not updated for that IP (It seems like it dont reflect what is in the arp cache). In the router there is a view called "network view".

Posted

So what you are saying is that the GUI view does not match the command line results?

Posted
8 minutes ago, digininja said:

So what you are saying is that the GUI view does not match the command line results?

Yes,  and I think the GUI is the mac address it uses for the IP. Since I do not arpspoof the phone the connection is still working. So it seems like the packets is still forwarded by the router on the old MAC address.

Posted

Assuming it is a Linux based operating system, it should use what it says in the ARP table you get from the command line.

 

Tell us the players, their IPs, and what you are running to try to do all this.

Posted
47 minutes ago, digininja said:

Assuming it is a Linux based operating system, it should use what it says in the ARP table you get from the command line.

 

Tell us the players, their IPs, and what you are running to try to do all this.

Yes, I its Linux based.

I found a print screen also how the viewer looks like on the merlin page. This is the page that do not match the when I do: arp -a -v # I run this command on the router(just to make clear).
dhcp.png

Posted

That is a list of your manually signed IP addresses based on MAC address. That is a static list that says what IP address your DHCP server will give out when that device asks for an address. That won't update as a result of spoofing.

Posted
5 minutes ago, digininja said:

That is a list of your manually signed IP addresses based on MAC address. That is a static list that says what IP address your DHCP server will give out when that device asks for an address. That won't update as a result of spoofing.

I realized now I found wrong picture (sorry about this, I didn't want to take a own print screen since I should need to remove the mac address)😞. The other one look similar, but it's not for the DHCP(My phone get it ip dynamic so it's not in this list).

I have tried some more and found when using: arpspoof -i wlan0 -t 192.168.1.1  -r 192.168.1.100
That did also update the arp table in the router(When using arp -a -v, so I might been wrong here before). But still no update in the GUI.

I also started wireshark on my computer (the attacker) and saw that the request from the phone was forwarded to the router. The message came directly after the first message. However I could not see any response from the outside for the messages.

Posted

You need to explain what all the devices you are using are, their IP addresses, MAC address, and who is talking to who.

Without this, I can't tell which devices you are trying to poison and which devices you are then trying to access.

If you want to obscure things give us the first three octets, assuming they are all unique. If not, give us 2-4 as they will be unique.

Posted

Sorry for late response, my quota of messages run out last day so had to wait one day before able to respond.


Here is a picture of my network layout. I changed my phone to a mac instead so it easier to do debugging like run wireshark.

network.png

Let me know if any more info is needed.

I also run wireshark on my Kali linux machine and found that arp was detected duplicated use (but maybe this is expected). I have blanked out the last part of MAC address

wireshark-duplicated-arp.png

I also saw this when running wireshark on my Kali linux in the log when I tried to access www.guimp.com(I google smallest page) from my mac:

out-of-order.png

Seems like the message coming back from the router gets out of order.

Any idea what could be wrong? Any more information needed? I can also run wireshark on my mac but not sure what to look for there. I should like to run wireshark on my router but not sure it will be able to handle it(But will look into this tomorrow). Any more information that could be useful? Could the iptables be interesting in the router?

Posted

The command you are running is telling the router (192.168.1.1 the target specified by -t) that the MAC address of the victim (192.168.1.101 - don't know where the -r came from) is now your MAC address which is what you are seeing when the ARP table on the router changes.

If you only run the one arpspoof command, then the ARP table on the victim should not update as you aren't targeting that. There are no fake ARP messages going out to tell the victim that the MAC for the IP .1 is now you.

The duplicate warnings are because you have two IP addresses using the same MAC address which is allowed, but only in odd situations.

If you are going to sniff packets, look for ARP traffic, you'll then see your host sending out traffic to tell the other devices that IPs are moving around.

Have a look at this guide, you are probably doing most of it already, but it steps through things so may help pick up something you've missed.

https://ourcodeworld.com/articles/read/422/how-to-perform-a-man-in-the-middle-mitm-attack-with-kali-linux

Posted

I was running arpspoof in two separate terminal windows (as almost all tutorial suggest). However I found the -r flag in the man page:
flag -r     Poison both hosts (host and target) to capture traffic in both directions.  (only valid in conjuntion with -t)

So much easier to run. I have also manually verified that both arp tables is updated(As in picture).

Here is the output from the command:
root@kali:~# arpspoof -i wlan0 -t 192.168.1.1 -r 192.168.1.101
0:c0:ca:FF:FF:FF c:9d:92:FF:FF:FF 0806 42: arp reply 192.168.1.101 is-at 0:c0:ca:FF:FF:FF
0:c0:ca:FF:FF:FF b8:e8:56:FF:FF:FF 0806 42: arp reply 192.168.1.1 is-at 0:c0:ca:FF:FF:FF
0:c0:ca:FF:FF:FF c:9d:92:FF:FF:FF 0806 42: arp reply 192.168.1.101 is-at 0:c0:ca:FF:FF:FF
0:c0:ca:FF:FF:FF b8:e8:56:FF:FF:FF 0806 42: arp reply 192.168.1.1 is-at 0:c0:ca:FF:FF:FF

I have also read that tutorial(and most other tutorials). I still think my problem is with my router that not forwarding the packet in correct way. Unfortunately I don have another router that I can borrow to test this(Most my friends can not live with out there own router).

Any more ideas what I could investigate? Should the output from iptables -L be interesting?

 

Posted

You don't need to poison a router, you can poison two devices. Attack your Mac and phone or two phones.

And watch the ARP traffic, make you you are sending out what you expect to send out.

Posted

The thing I want to achieve is too look at the  data traffic between my mac (Phone in the real case) to see the communication for games.

So for that I need to also spoof the router, but seems like the spoofing part is done. However the problem is the routing of messages in the router that seems to be lost on the way back from public IP or get received out of order.

However I can try to setup an internal webserver on the mac and connect with my iphone to it see if the arp spoofing is work for that part(But this I see as a side track).

Posted

Why not do it the easy way then and just install Wireshark on your Mac? Or use tcpdump/tshark to capture the traffic and then load it into Wireshark later?

Or wire the Mac to you Kali box, set that as the default gateway, then enable IP forwarding.

 

Posted

I have wireshark installed on my Mac(Note it is not a phone any longer it's a mac pro with wireless card), not sure what to look for on it(See picture above).

I also have IP forwarding enabled on my KALI machine. My wireless card is Alfa AWUS036AC (it as support for monitor mode also) in the Kali machine.

I will try to change the default gateway, I guess that might show what I should expect to see on my KALI machine if routing was working.

However I should still like to understand why my messages is lost in the router(or if they are wrong redirected.)

 

Here is how my iptables looks like, not sure if its any help.

admin@RT-AC86U-D368:/tmp/home/root# iptables -L
Chain INPUT (policy ACCEPT)

target prot opt source destination
INPUT_PING icmp -- anywhere anywhere icmp echo-request
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
DROP all -- anywhere anywhere state INVALID
PTCSRVWAN all -- anywhere anywhere
PTCSRVLAN all -- anywhere anywhere
ACCEPT all -- anywhere anywhere state NEW
ACCEPT all -- anywhere anywhere state NEW
OVPN all -- anywhere anywhere state NEW
ACCEPT udp -- anywhere anywhere udp spt:bootps dpt:bootpc
INPUT_ICMP icmp -- anywhere anywhere
DROP all -- anywhere anywhere

Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
other2wan all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
DROP all -- anywhere anywhere state INVALID
NSFW all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate DNAT
OVPN all -- anywhere anywhere state NEW
DROP all -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain ACCESS_RESTRICTION (0 references)
target prot opt source destination

Chain DNSFILTER_DOT (0 references)
target prot opt source destination

Chain FUPNP (0 references)
target prot opt source destination

Chain INPUT_ICMP (1 references)
target prot opt source destination
RETURN icmp -- anywhere anywhere icmp echo-request
RETURN icmp -- anywhere anywhere icmp timestamp-request
ACCEPT icmp -- anywhere anywhere

Chain INPUT_PING (1 references)
target prot opt source destination
DROP icmp -- anywhere anywhere

Chain NSFW (1 references)
target prot opt source destination

Chain OVPN (2 references)
target prot opt source destination
DROP all -- anywhere anywhere

Chain PControls (0 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere

Chain PTCSRVLAN (1 references)
target prot opt source destination

Chain PTCSRVWAN (1 references)
target prot opt source destination

Chain SECURITY (0 references)
target prot opt source destination
RETURN tcp -- anywhere anywhere tcpflags: FIN,SYN,RST,ACK/SYN limit: avg 1/sec burst 5
DROP tcp -- anywhere anywhere tcpflags: FIN,SYN,RST,ACK/SYN
RETURN tcp -- anywhere anywhere tcpflags: FIN,SYN,RST,ACK/RST limit: avg 1/sec burst 5
DROP tcp -- anywhere anywhere tcpflags: FIN,SYN,RST,ACK/RST
RETURN icmp -- anywhere anywhere icmp echo-request limit: avg 1/sec burst 5
DROP icmp -- anywhere anywhere icmp echo-request
RETURN all -- anywhere anywhere

Chain default_block (0 references)
target prot opt source destination

Chain logaccept (0 references)
target prot opt source destination
LOG all -- anywhere anywhere state NEW LOG level warning tcp-sequence tcp-options ip-options prefix "ACCEPT "
ACCEPT all -- anywhere anywhere

Chain logdrop (0 references)
target prot opt source destination
LOG all -- anywhere anywhere state NEW LOG level warning tcp-sequence tcp-options ip-options prefix "DROP "
DROP all -- anywhere anywhere

Chain other2wan (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
DROP all -- anywhere anywhere

Posted

If you are going to go wired through the kali box, you need to do this:

Mac -> Kali -> router

As far as the Mac is concerned, the Kali box is the default gateway and so the next network hop.

In Wireshark, you are looking for ARP messages, so filter on those.

Posted

I was able to install tcpdump and run it on the router. I also made my test simpler instead of going to a webpage I just tried to do: dig @ns-604.awsdns-11.net forums.hak5.org

When I run the above dig command to generate dns request I could see the message in tcpdump on the router using this command:  tcpdump -i eth5 port 53
I saw it both when I run it on the mac and kali-pc(no arpspoof involved). However when I started aprspoof (mac and router). It was still possible to send the dns request from the kali-pc. However from mac the message got lost between kali-pc and the router. I never saw it arrive to the eth5 interface on the router.

I updated the picture it can be seen here:
Visio-dns.png

 

Here is DNS request 1 in wireshark running on kali (src: mac, dst: kali ) Note that this first line is highlighted.

hak5-mac-to-kali-wireshark.png

Here is DNS request 2 in wireshark running on kali (src: kali, dst: router ). Note that this second line is highlighted.

 

hak5-kali-wireshark.png

 

The last message that is sent to 0C:9D:92 is never seen when I do tcpdump on the router.

I have to little knowledge about tcpdump but guess it monitors packets that goes across the interface. So if the DNS request was discarded  directly could explain why I didn't see it when running tcpdump -i eth5 port 53 on router. However can't explain why it should been discarded since it works when I do the request when I run dig directly on kali-pc.

Any suggestion what could cause this? I will see if I can find any logs where I can see discarded messages or if I can find any other logs to see where the message disappear.

Just as info eth5 (wifi 2.4) and eth6 (5Ghz) and eth1-4 is the ports on the router. I didn't know about this before I thought it was only one interface br0, but br0 is the interface for the public wifi.

 

Posted

For testing, I'd use ping as you can start a ping and leave it going while you look for traffic.

It's hit a point of hard to debug without access, I'm running out of things to suggest.

How about setting static fake ARP entries on the devices and see how that looks? That way you can remove the arpsooof stuff from the picture.

Posted

Thanks digininja, for the tips of using ping :). I ping 8.8.8.8 (google) on my mac when it was arp spoofed. I saw the messages on my kali machine and this time I also got a response. I could also see the message when tcpdump the eth0 on the router. However I still don see the dns request in the router. So think the router discard these messages, however I read the tcpdump(or if it was wireshark in some post, so not sure if its true) should read the messages before they are discarded.

But at least now I know it's possible to send messages the whole route and back now. But still need to figure out why the messages are lost in the router. I think it could be something with my iptable, but Im to stupid to understand it. or can it be some other feature that control messages?

I have also asked this question in asuswrt-merlin forum however not got any response there. So very thank full for all your tips digininja 🙂

Posted

For the pings, I meant from the victim ping the target, that way there are no additional hops and you should be able to see the request and response on all three machines.

But glad you got it working to at least some degree.

Posted

This is the process I'd go through to debug all of this. I'm going to define client and server as the two victims, you take them as whatever devices you have.

  • Start a ping going from client to server. Run tcpdump on both devices and make sure you can see the ICMP traffic on both sides.
  • On the client, set a static ARP entry for the server. Restart ping and tcpdump and check you can still see traffic.
  • Reboot
  • On the server, set a static ARP entry for the server. Restart ping and tcpdump and check you can still see traffic.
  • Those steps confirm that you can monitor traffic and that you are using the arp command correctly to set entries. The reboot clears down anything to stop things interfering.
  • On the client, set an invalid ARP entry for the server. Start the ping. Watching the dump, you should see ICMP traffic leave the client but not arrive at the server.
  • Reboot
  • On the server, set an invalid ARP entry for the client. Start the ping. Watching the dump, you should see ICMP traffic leave the client, arrive at the server, leave the server, but not arrive back at the client.
  • That shows what it looks like when the routing is messed up. It also shows whether the server is honouring the OS ARP table or not. If traffic does flow, then the invalid ARP is being ignored
  • Reboot
  • On both boxes, set ARP entries that go through the attacking box.
  • Start tcpdump on all three boxes.
  • Start the ping.
  • You should see ICMP leave the client, pass through the attacker, arrive at the server, leave the server, come back through the attacker, and arrive back at the client.
  • If you don't, then you know the attacker box is not setup correctly. Debug here till it all works.
  • Take a screenshot of what the ARP entries look like on client and server as this is now a working poisoned state.
  • Reboot
  • Run arpspoof as you expect it to be ran. Check the ARP tables and see if they match what you previous had, they should with.
  • Start tcpdump everywhere and start the ping. You should see traffic flowing correctly through the attacker.

When you get here, you have successfully poisoned the network.

Don't be tempted to miss steps out, each one is there for a reason. The reboots are needed to clear things out so that you are definitely running on just the setup you are making, not on top of junk from the previous experiment. You can also take screenshots of the ARP table at each step so you can compare things and get used to how it looks.

All pings are done purely from client to server, not to an outside entity, that removes anything else from potentially messing with traffic.

You can also test pinging from server back to client at each step, that would give a bit of extra confirmation.

 

  • 2 weeks later...
Posted

I been away for awhile, but thought about giving this another try. However I think I have been able to poison the network for ICMP packets flow the correct way, should that be a sign that the its correct? I also see DNS packets flow the correct way that they arrive at the attacker and is forwarded to the routers MAC address. But on the way to the router the message is lost (I do not think this is arp related.).

Could the router some how detect the packet has been changed? I guess DNS packets are on a higher level, so might some other handling. Can it be something in the iptable? I included my iptable here for the filter. I see there are some rules for icmp, but I don't really understand them so maybe someone else have some ideas about it.Should any of the other tables be intressting? How add rows for logging when a packet is dropped?

# iptables -S -v -t filter
-P INPUT ACCEPT -c 0 0
-P FORWARD DROP -c 0 0
-P OUTPUT ACCEPT -c 739842 210491875
-N ACCESS_RESTRICTION
-N DNSFILTER_DOT
-N FUPNP
-N INPUT_ICMP
-N INPUT_PING
-N NSFW
-N OVPN
-N PControls
-N PTCSRVLAN
-N PTCSRVWAN
-N SECURITY
-N default_block
-N logaccept
-N logdrop
-N other2wan
-A INPUT -i eth0 -p igmp -c 50949 1630368 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -c 1684 1447978 -j INPUT_PING
-A INPUT -m state --state RELATED,ESTABLISHED -c 120974268 49466651583 -j ACCEPT
-A INPUT -m state --state INVALID -c 8200 402179 -j DROP
-A INPUT ! -i br0 -c 9630083 2065897954 -j PTCSRVWAN
-A INPUT -i br0 -c 1846556 238209298 -j PTCSRVLAN
-A INPUT -i br0 -m state --state NEW -c 1846556 238209298 -j ACCEPT
-A INPUT -i lo -m state --state NEW -c 9453218 2054605288 -j ACCEPT
-A INPUT -m state --state NEW -c 176865 11292666 -j OVPN
-A INPUT -p udp -m udp --sport 67 --dport 68 -c 0 0 -j ACCEPT
-A INPUT -p icmp -c 19 760 -j INPUT_ICMP
-A INPUT -c 176763 11282633 -j DROP
-A FORWARD -d 224.0.0.0/4 -i eth0 -c 0 0 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -c 392212832 390647744304 -j ACCEPT
-A FORWARD ! -i br0 -o eth0 -c 0 0 -j other2wan
-A FORWARD -i br0 -o br0 -c 2 2984 -j ACCEPT
-A FORWARD -m state --state INVALID -c 278948 11799305 -j DROP
-A FORWARD -c 8323272 531605893 -j NSFW
-A FORWARD -i br0 -c 5655858 372797112 -j ACCEPT
-A FORWARD -m conntrack --ctstate DNAT -c 2667414 158808781 -j ACCEPT
-A FORWARD -m state --state NEW -c 0 0 -j OVPN
-A FORWARD -c 0 0 -j DROP
-A FUPNP -d 192.168.1.112/32 -p udp -m udp --dport 51291 -c 0 0 -j ACCEPT
-A FUPNP -d 192.168.1.112/32 -p udp -m udp --dport 62360 -c 0 0 -j ACCEPT
-A FUPNP -d 192.168.1.100/32 -p udp -m udp --dport 54064 -c 0 0 -j ACCEPT
-A FUPNP -d 192.168.1.112/32 -p udp -m udp --dport 59379 -c 0 0 -j ACCEPT
-A FUPNP -d 192.168.1.112/32 -p udp -m udp --dport 61371 -c 0 0 -j ACCEPT
-A FUPNP -d 192.168.1.100/32 -p udp -m udp --dport 63029 -c 0 0 -j ACCEPT
-A FUPNP -d 192.168.1.100/32 -p udp -m udp --dport 59900 -c 0 0 -j ACCEPT
-A FUPNP -d 192.168.1.212/32 -p udp -m udp --dport 59080 -c 0 0 -j ACCEPT
-A FUPNP -d 192.168.1.100/32 -p udp -m udp --dport 61842 -c 0 0 -j ACCEPT
-A FUPNP -d 192.168.1.112/32 -p udp -m udp --dport 60106 -c 0 0 -j ACCEPT
-A FUPNP -d 192.168.1.212/32 -p udp -m udp --dport 55476 -c 0 0 -j ACCEPT
-A FUPNP -d 192.168.1.100/32 -p udp -m udp --dport 56159 -c 0 0 -j ACCEPT
-A FUPNP -d 192.168.1.100/32 -p udp -m udp --dport 62212 -c 0 0 -j ACCEPT
-A INPUT_ICMP -p icmp -m icmp --icmp-type 8 -c 0 0 -j RETURN
-A INPUT_ICMP -p icmp -m icmp --icmp-type 13 -c 19 760 -j RETURN
-A INPUT_ICMP -p icmp -c 0 0 -j ACCEPT
-A INPUT_PING -i eth0 -p icmp -c 640 38214 -j DROP
-A OVPN -i tun11 -c 0 0 -j DROP
-A PControls -c 0 0 -j ACCEPT
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 1/sec -c 0 0 -j RETURN
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -c 0 0 -j DROP
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -c 0 0 -j RETURN
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -c 0 0 -j DROP
-A SECURITY -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -c 0 0 -j RETURN
-A SECURITY -p icmp -m icmp --icmp-type 8 -c 0 0 -j DROP
-A SECURITY -c 0 0 -j RETURN
-A logaccept -m state --state NEW -c 0 0 -j LOG --log-prefix "ACCEPT " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logaccept -c 0 0 -j ACCEPT
-A logdrop -m state --state NEW -c 0 0 -j LOG --log-prefix "DROP " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logdrop -c 0 0 -j DROP
-A other2wan -i tun+ -c 0 0 -j RETURN
-A other2wan -c 0 0 -j DROP

 

Posted

Did you walk through the process I suggested? If that works with ICMP and you can see the packets going the right direction at each step then the poisoning is successful. You can then repeat the process with other traffic types, such as DNS.

If you think it is working but DNS traffic is going astray, then by using tcpdump on all the devices you will be able to see what is going on. You should see the request leaving the victim, landing in the attacker, being sent back out to the router, landing in the router. The response should then reverse that route. It doesn't matter if the router is ignoring the message at a DNS level, the packet sniffer will still see the request arrive and then maybe get sent out again.

If it doesn't arrive, then it is routing on the attacker machine, if it arrives and isn't sent back out, then check the DNS server logs and watch other interfaces in case it is being sent out of one of them instead.

Archived

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

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...