This topic explain how IP services are exploited by threat actors. Start learning CCNA 200-301 for free right now!!
Note: Welcome: This topic is part of Module 3 of the Cisco CCNA 3 course, for a better follow up of the course you can go to the CCNA 3 section to guide you through an order.
Table of Contents
Earlier in this module you learned about vulnerabilities with IP, TCP and UDP. The TCP/IP protocol suite was never built for security. Therefore, the services that IP uses for addressing functions such as ARP, DNS, and DHCP, are also not secure, as you will learn in this topic.
Hosts broadcast an ARP Request to other hosts on the segment to determine the MAC address of a host with a particular IP address. All hosts on the subnet receive and process the ARP Request. The host with the matching IP address in the ARP Request sends an ARP Reply.
Click Play in the figure to see the ARP process at work.
The ARP Process
Any client can send an unsolicited ARP Reply called a “gratuitous ARP.” This is often done when a device first boots up to inform all other devices on the local network of the new device’s MAC address. When a host sends a gratuitous ARP, other hosts on the subnet store the MAC address and IP address contained in the gratuitous ARP in their ARP tables.
This feature of ARP also means that any host can claim to be the owner of any IP or MAC. A threat actor can poison the ARP cache of devices on the local network, creating an MITM attack to redirect traffic. The goal is to target a victim host, and have it change its default gateway to the threat actor’s device. This positions the threat actor in between the victim and all other systems outside of the local subnet.
ARP Cache Poisoning
ARP cache poisoning can be used to launch various man-in-the-middle attacks.
Click each button for an illustration and an explanation of the ARP cache poisoning process.
The figure shows how ARP cache poisoning works. PC-A requires the MAC address of its default gateway (R1); therefore, it sends an ARP Request for the MAC address of 192.168.10.1.
In this figure, R1 updates its ARP cache with the IP and MAC addresses of PC-A. R1 sends an ARP Reply to PC-A, which then updates its ARP cache with the IP and MAC addresses of R1.
In the figure, the threat actor sends two spoofed gratuitous ARP Replies using its own MAC address for the indicated destination IP addresses. PC-A updates its ARP cache with its default gateway which is now pointing to the threat actor’s host MAC address. R1 also updates its ARP cache with the IP address of PC-A pointing to the threat actor’s MAC address.
The threat actor’s host is executing an ARP poisoning attack. The ARP poisoning attack can be passive or active. Passive ARP poisoning is where threat actors steal confidential information. Active ARP poisoning is where threat actors modify data in transit, or inject malicious data.
Note: There are many tools available on the internet to create ARP MITM attacks including dsniff, Cain & Abel, ettercap, Yersinia, and others.
Video – ARP Spoofing
Click Play in the figure to view a video about ARP Spoofing.
The Domain Name Service (DNS) protocol defines an automated service that matches resource names, such as www.cisco.com, with the required numeric network address, such as the IPv4 or IPv6 address. It includes the format for queries, responses, and data and uses resource records (RR) to identify the type of DNS response.
Securing DNS is often overlooked. However, it is crucial to the operation of a network and should be secured accordingly.
DNS attacks include the following:
DNS open resolver attacks
DNS stealth attacks
DNS domain shadowing attacks
DNS tunneling attacks
DNS Open Resolver Attacks
Many organizations use the services of publicly open DNS servers such as GoogleDNS (126.96.36.199) to provide responses to queries. This type of DNS server is called an open resolver. A DNS open resolver answers queries from clients outside of its administrative domain. DNS open resolvers are vulnerable to multiple malicious activities described in the table.
DNS Resolver Vulnerabilities
DNS cache poisoning attacks
Threat actors send spoofed, falsified record resource (RR) information to a DNS resolver to redirect users from legitimate sites to malicious sites. DNS cache poisoning attacks can all be used to inform the DNS resolver to use a malicious name server that is providing RR information for malicious activities.
DNS amplification and reflection attacks
Threat actors use DoS or DDoS attacks on DNS open resolvers to increase the volume of attacks and to hide the true source of an attack. Threat actors send DNS messages to the open resolvers using the IP address of a target host. These attacks are possible because the open resolver will respond to queries from anyone asking a question.
DNS resource utilization attacks
A DoS attack that consumes the resources of the DNS open resolvers. This DoS attack consumes all the available resources to negatively affect the operations of the DNS open resolver. The impact of this DoS attack may require the DNS open resolver to be rebooted or services to be stopped and restarted.
DNS Stealth Attacks
To hide their identity, threat actors also use the DNS stealth techniques described in the table to carry out their attacks.
DNS Stealth Techniques
Threat actors use this technique to hide their phishing and malware delivery sites behind a quickly-changing network of compromised DNS hosts. The DNS IP addresses are continuously changed within minutes. Botnets often employ Fast Flux techniques to effectively hide malicious servers from being detected.
Double IP Flux
Threat actors use this technique to rapidly change the hostname to IP address mappings and to also change the authoritative name server. This increases the difficulty of identifying the source of the attack.
Domain Generation Algorithms
Threat actors use this technique in malware to randomly generate domain names that can then be used as rendezvous points to their command and control (C&C) servers.
DNS Domain Shadowing Attacks
Domain shadowing involves the threat actor gathering domain account credentials in order to silently create multiple sub-domains to be used during the attacks. These subdomains typically point to malicious servers without alerting the actual owner of the parent domain.
Threat actors who use DNS tunneling place non-DNS traffic within DNS traffic. This method often circumvents security solutions when a threat actor wishes to communicate with bots inside a protected network, or exfiltrate data from the organization, such as a password database. When the threat actor uses DNS tunneling, the different types of DNS records are altered. This is how DNS tunneling works for CnC commands sent to a botnet:
The command data is split into multiple encoded chunks.
Each chunk is placed into a lower level domain name label of the DNS query.
Because there is no response from the local or networked DNS for the query, the request is sent to the ISP’s recursive DNS servers.
The recursive DNS service will forward the query to the threat actor’s authoritative name server.
The process is repeated until all the queries containing the chunks of are sent.
When the threat actor’s authoritative name server receives the DNS queries from the infected devices, it sends responses for each DNS query, which contain the encapsulated, encoded CnC commands.
The malware on the compromised host recombines the chunks and executes the commands hidden within the DNS record.
To stop DNS tunneling, the network administrator must use a filter that inspects DNS traffic. Pay close attention to DNS queries that are longer than average, or those that have a suspicious domain name. DNS solutions, like Cisco OpenDNS, block much of the DNS tunneling traffic by identifying suspicious domains.
DHCP servers dynamically provide IP configuration information to clients. The figure shows the typical sequence of a DHCP message exchange between client and server.
Normal DHCP Operation
In the figure, a client broadcasts a DHCP discover message. The DHCP server responds with a unicast offer that includes addressing information the client can use. The client broadcasts a DHCP request to tell the server that the client accepts the offer. The server responds with a unicast acknowledgment accepting the request.
DHCP Spoofing Attack
A DHCP spoofing attack occurs when a rogue DHCP server is connected to the network and provides false IP configuration parameters to legitimate clients. A rogue server can provide a variety of misleading information:
Wrong default gateway – Threat actor provides an invalid gateway, or the IP address of its host to create a MITM attack. This may go entirely undetected as the intruder intercepts the data flow through the network.
Wrong DNS server – Threat actor provides an incorrect DNS server address pointing the user to a malicious website.
Wrong IP address – Threat actor provides an invalid IP address, invalid default gateway IP address, or both. The threat actor then creates a DoS attack on the DHCP client.
Assume a threat actor has successfully connected a rogue DHCP server to a switch port on the same subnet as the target clients. The goal of the rogue server is to provide clients with false IP configuration information.
Click each button for an illustration and explanation of the steps in a DHCP spoofing attack.
In the figure, a legitimate client connects to the network and requires IP configuration parameters. The client broadcasts a DHCP Discover request looking for a response from a DHCP server. Both servers receive the message.
The figure shows how the legitimate and rogue DHCP servers each respond with valid IP configuration parameters. The client replies to the first offer received.
In this scenario, the client received the rogue offer first. It broadcasts a DHCP request accepting the parameters from the rogue server, as shown in the figure. The legitimate and rogue server each receive the request.
However, only the rogue server unicasts a reply to the client to acknowledge its request, as shown in the figure. The legitimate server stops communicating with the client because the request has already been acknowledged.
Lab – Explore DNS Traffic
In this lab, you will complete the following objectives:
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.