Cisco Smart Install vulnerability exploited in the wild
As mentioned in today’s SANS ISC podcast, Cisco Smart Install may being used in recent attacks on Iranian and Russian networks. Earliert this week, we saw a small spike in port 4786 attacks. But the size of the attack as reported by Kaspersky may indicate that this isn't just random scanning. Services like Shodan may have been used to identify vulnerable systems.
Cisco IOS and IOS XE Software both have a feature called “Smart Install”, described in Cisco’s Smart Install Configuration Guide as:
“Smart Install is a plug-and-play configuration and image-management feature that provides zero-touch deployment for new switches. You can ship a switch to a location, place it in the network and power it on with no configuration required on the device.”
The vulnerability allows not only denial-of-service (DoS) attacks but also remote arbitrary code execution in vulnerable Cisco devices. Specially crafted malicious messages can cause a stack-based buffer overflow because of a missing size check before copying to a buffer. A proof-of-concept is already publicly available.
Administrators of vulnerable devices are recommended to apply already available patches from Cisco.
A vulnerability on the Smart Install feature of Cisco IOS is not something new. If we look at the CVE history, we can find several vulnerabilities relating to this feature:
- CVE-2018-0171: DoS (device crash) & arbitrary code execution;
- CVE-2018-0156: DoS;
- CVE-2016-6385: DoS (memory consumption);
- CVE-2016-1349: DoS (device reload);
- CVE-2013-1146: DoS (device reload);
- CVE-2012-0385: DoS (device reload);
- CVE-2011-3271: DoS & arbitrary code execution.
As you can see by the CVE numbers, there are reports for vulnerabilities since 2011 up to this year (2018). We can perhaps conjecture that more vulnerabilities might be discovered in the near future. So, it is a good idea to follow Cisco’s recommendation: port 4786 should be exposed to the “integrated branch director” (IBD) router only.
--
Renato Marinho
Morphus Labs| LinkedIn | Twitter
ARP Spoofing in 2018: are you protected?
This week I was reminded how efficient ARP (Address Resolution Protocol) spoofing attacks might be. A single Android device equipped with offensive tools was enough to fool any device on a network and capture sensitive data. But wait, we are talking about a threat as old as ARP specification from 1982. There aren’t vulnerable networks to this nowadays, right? Wrong.
Based on my past experience, it is rather rare to see a network protected against this technique and I may have some clues why. First, we are not talking about a vulnerability but an intrinsic characteristic from ARP, a layer 2 network protocol responsible for mapping IP addresses to MAC addresses. It is implemented in every single connected device.
Let’s recall how ARP works. When a host need to establish a connection on a local network, it will broadcast the destination IP address and wait for the right machine to reply with its MAC address. To avoid unnecessary traffic, the IP/MAC pair is cached for a limited time on a local the ARP table. This table is dynamically constructed and maintained over time. The ARP table may also be updated through gratuitous announcements whenever a host announces its own MAC address without being asked for. This expected protocol behavior allows for a variety of malicious actions, such as DoS (Denial of Service), session hijacking and MITM (man-in-the-middle) attacks.
Of course, for a malicious host to implement such attacks, it needs to be connected to the network (wired or wireless) and this is a strong reason this threat is underestimated. However, we may have open networks, infected machines and insiders – this threat is authentic.
A Simple Experiment
To check how easily an insider could perform this attack on an unprotected network, we decided to make a quick experiment. We put together a bunch of easily findable Python scripts to perform ARP and DNS Spoofing and a web application on a small lab environment.
The objective was to implement a MITM attack and make a specific host, our victim, believe attacker machine was the network gateway. Additionally, using a simple DNS Spoofing script we would intercept and answer any DNS query to resolve to the IP address of the third component of our lab: a web application asking for basic authentication. As shown in the following figures.
This simple phishing attack which could successfully capture sensitive information like passwords.
Mitigation
Most of the mitigations for ARP Spoofing attacks are made by network switches using DHCP Snooping and Dynamic ARP Inspection (DAI) techniques. The specific feature names may vary by switch brand, but basically, they allow only authorized ARP announcements to travel over the network. They drop ARP packets coming from hosts that do not match IP/MAC pairs delivered by the DHCP server.
To provide additional protection, especially for mobile devices, it is important to have an endpoint security solution, like host IPS, to discard unsolicited or gratuitous ARP packets.
Although switch and endpoint ARP spoofing protections are not new, implementing them may be another possible reason for not having this mitigation widely deployed. There are some tricks, mainly related to DHCP Snooping and DAI, that should be considered, such as: virtualized or clustering environments to avoid network or service interruptions.
Finally, while writing this diary and performing the experiments, I created a simple project to protect my laptop against ARP Spoofing. Every time I change from a network to another, the script gets the current gateway MAC address and sets it permanently on local ARP table. This way, arbitrary attempts to spoof the gateway MAC address for MITM attacks will be rejected. It currently works on Mac OS and is available on GitHub [1]. Suggestions, pull requests and bug reports are welcome.
References:
[1] https://github.com/morphuslabs/setgatewaymac
--
Renato Marinho
Morphus Labs| LinkedIn | Twitter
Comments