Information gathered from: https://www.armis.com/cdpwn/
The white page can be found here: https://go.armis.com/hubfs/White-papers/Armis-CDPwn-WP.pdf
The purpose of this post is not to exploit the vulnerabilities, but instead to just bring awareness.
First I think it is important to understand what is CDP or Cisco Discovery Protocol, before diving into what was discovered.
For starters, Cisco Discovery Protocol is proprietary to Cisco Systems and was created to help discover Cisco devices in the network landscape. The protocol, runs in the Data Link Layer and behaves by sending a packet every minute to the multicast address 01:00:0C:CC:CC:CC, which any Cisco device will be listening on. It is also important to remember that once received, these messages do not get repeatedly sent. For memory's sake, multicast is the IP service of sending a packet to several hosts, compared to broadcast, which is all hosts. The CDP message contains information about the senders operating system version, the IP address, the interface that sent it, the host name, along with many other details. Thus making this an incredible feature when used correctly.
At the time of this post, there are currently five vulnerabilities disclosed, with four being remote code execution and one being denial of service. These vulnerabilities can lead to a break down of network segmentation, data exfiltration, and main-in-the-middle attacks.
The first vulnerability (CVE-2020-3110) is targeted to the Cisco 8000 Series IP cameras. This is a heap-overflow vulnerability, caused by the mismatch of variable types. In short, the way the CDP process works is that it allocates a buffered spaced based on the length of the Port ID that is passed in and copies this Port ID value to the buffer. However, the size of the Port ID is 16-bit and the size of the buffer is 8-bits, meaning that an attacker can overflow the heap and conduct a remote-code-execution attack.
The second vulnerability (CVE-2020-3111) is targeted to Cisco IP phones. This is a stack-overflow vulnerability caused by the lack of validating the length of the Port ID Type Length Value. The information is directly copied to the stack, which if abused can lead to remote code execution and full control of the VoIP phone, as the CDP daemon process is executed with root privileges.
The third vulnerability (CVE-2020-3118) is targeted to the Cisco IOS-XR Software. This is also a stack-overflow vulnerability, that is caused by a lack of validating certain string fields (Device ID, Port ID, Software Version) in the received CDP packets and how the data is formatted by the sprintf function. In short, the CDP packet's information is copied to the current router's memory. Because of this, an attacker can use format tokens such as %s, %x, or %n to print data to out-of-bounds memory locations. If abused, the vulnerability can lead to remote code execution and once again gain full control over the router.
The fourth vulnerability (CVE-2020-3119) is targeted to the Cisco NX-OS Software. Just like the previous, this is also a stack-overflow vulnerability that targets the negotiation of Power Over Ethernet request fields found in CDP. Here an attacker can send a valid CDP packet continuously that contains a higher power request level than the switch expects, causing a stack overflow. This then allows the attacker to gain full control of the switch.
The last vulnerability (CVE-2020-3120) is targeted to all of the previous devices. In short, this is a Denial of Service attack that is caused by repeatedly crashing the CDP daemon of the given device, causing the device to reboot.
First, I think it is best for us to understand what is external BGP and then dive into how it is insecure and how it can lead to massive problems. Now there are two parties, internal and external routing protocols. An example of an internal routing protocol would be EIGRP (Enhanced Interior Gateway Routing Protocol) or OSPF (Open Shortest Path First), as these routes would be advertised internally or within a given network, but never to the internet. Therefore, external routing protocols are the opposite, they are not to be used within the network, but instead to connect networks together*. This is where BGP comes into play, also known as Border Gateway Protocol, it is the routing protocol of the internet. In simple terms, what we call the internet is the just the massive connection of autonomous systems or AS, which is just the assignment of a publicly known number used to identify a given network or set of IPs. Currently there is an estimated ~84,000 allocated autonomous system networks. BGP also differs from internal routing protocols in that it does not broadcast the entire routing table, instead at boot a nearby peer will hand over their table, then only updates are relayed after. In addition, BGP routes are stored in RIB, or Routing Information Base, where multiple routes to a specific destination are stored. Here, routes are then placed, based on best choice by the router, into the routing table to be used. (The routing table picks the route that uses the least number of AS hops.) This allows for the routing table to be kept small and to update only if needed. Because of the RIB, if a route needs to be removed, but only exists here, then it is silently dropped and no update will be sent. Also, because of this functionality there is no need for RIB entries to time out, so they exist in the base as long as they are valid.
Now, after discussing how BGP works, it is important to talk about its faults and how it has lead to some pretty drastic mishaps. Poor configuration of BGP has plagued the internet since the beginning, but now that more of our lives are connected and better information of proper maintenance is available, it is more important now than ever to educate ourselves. BGP does not appear to be going away anytime soon, so the best thing we can do as security engineers to help protect our organizations is by learning from others mistakes.
Let us take Verizon for example, in June of 2019 a massive route leak impacted huge parts of the Internet. In short, a small Internet Service Provider company named DQE Communications used a BGP optimizer which preferred specific routes over generalized ones and then advertised these routes to their client Allegeny Technologies. From here it was then advertised to Verizon where it was further advertised to the world. Which in return, rerouted traffic to this preferred path causing a massive fault as this route was not prepared to deal with so much traffic. Now the advertisement should have stopped at Verizon, but because it did not around 20% of the Internet was impacted.
In an act to prevent this from occurring, the major thing that should have been implemented is to impose a hard limit of prefixes expected to be received on a BGP session. We will actually explore BGP security more in a later blog so keep following along.
Overall, BGP is the routing protocol of the Internet and while it is the backbone, it does not mean that it is perfect by any means, but we has engineers have to do our best so that another issue like this does not occur.
*For simplicity sake we are going to forget about Internal BGP and will not discuss it. If you want to learn more about how BGP can be used on the internal side visit this link:
CAM table overflows typically are an attack of the past, however that does not mean that we should forget about them. After all once a vulnerability has been found we cannot assume that future devices won't be vulnerable to this threat. In short, CAM table overflows are the idea of an attacker flooding a switch's MAC address table with bogus addresses, thus leading the switch to enter into a flood 'all traffic on all ports' state. This can create a DOS or allow the attacker to sniff traffic.
The best solution to this vulnerability is Port Security and the configuration is quiet simple, all you need is a Cisco switch.
Below we will walk through setting up port security on 24 ports to allow a maximum of 2 MAC addresses, to save already existing MAC addresses, and to shutdown the port if this violation occurs.
Default configuration: Please note that be default Port Security is set to memorize only one MAC address and shutdown the port if this violation occurs.
moses-switch# configure terminal
moses-switch(config)# ! grouping the range of ports, from 1 to 24
moses-switch(config)# int range gigabitEthernet0/1-24
moses-switch(config-if-range)# ! setting all of the ports to be access mode
moses-switch(config-if-range)# switchport mode access
moses-switch(config-if-range) # ! setting the maximum number of mac addresses allowed
moses-switch(config-if-range)# switchport port-security maximum 2
moses-switch(config-if-range) # ! saving the already existing MAC addresses for port security
moses-switch(config-if-range)# switchport port-security mac-address sticky
moses-switch(config-if-range)# ! setting the ports to shutdown if more than two MAC addresses is received
moses-switch(config-if-range)# switchport port-security violation shutdown
moses-switch(config-if-range)# ! Lastly starting up the service itself
moses-switch(config-if-range)# switchport port-security
Now please note that you can enable port security on a trunk, however regardless of the port it must be static, meaning that the switchport cannot be set to dynamic.
In addition, please note that while this example is shutting down the the port, in an enterprise environment it might be best to restrict or protect the port instead and set up an SNMP trap to alert an administrator of a potential problem. Also please note that this is just the tip of the iceberg, as port security can even rate limit and limit the number of MAC addresses saved for a VLAN.
The DNS service is vital part of any company's network and compromising it can lead to the loss of confidentiality and integrity. Therefore it is crucial service that needs to be both monitored and protected heavily.
In this post we are going to discuss 3 common DNS attacks that you should protect against, now given there are many more so continue to do your research afterwards. In addition, I am also going to assume that you understand how DNS works.
The basics of this attack is simple, redirect valid traffic going to a legitimate server over to a malicious one and it does this by corrupting the DNS cache data. Each time your computer encounters a domain name it does not recognize it must contact the DNS server, this server looks up the translation of IP addresses to domain names and then sends the packets accordingly. However, if an attacker can modify the information that the DNS server is telling users then it can affect entire companies, even more so, depending on the relationship this server has with others, then this false information can propagate to other servers in different organizations and so forth, eventually spreading like wildfire.
In short the attack can work like this:
DOS - TCP SYN Floods
In short, an attacker will overload the server by sending bogus SYN packets to abuse the TCP 3-way handshake connection. In reply, the server will send SYN-ACK responses, thus leaving the server 'hanging', which eventually leaves the server unable to connect to requests coming from valid users.
A method to prevent against such an attack would be to implement a host based firewall and a host-based intrusion detection system, while securing the network itself.
MITM - DNS Hijacking
Man in the middle DNS hijacking is the idea of an attacker intercepting and altering the cache data traffic between a user and the DNS server, thus leading the user to be redirected to a different destination that is often malicious.
While not fool-proof the three best methods that can be used to prevent against such an attack are to secure the surrounding network, locking down who is allowed access, using DNSSEC, and encouraging and sometimes even forcing clients to use HTTPS whenever browsing websites. Now, forcing users to use HTTPS will not encrypt the DNS traffic itself, but can act as a last line of defense with the web browser displaying that user has entered into an unsafe zone.