Today Cisco published its regular semiannual security advisory publication and there is one vulnerability (CVE-2018-0472) that catches the eye. A Cisco ASA and Cisco IOS / XE IPSec related DoS vulnerability that has been marked as HIGH.
The vulnerability stems from improper handling of IPSec AH (Authentication Header) or ESP (Encapsulating Security Payload) packets. A potential bad player can send specifically crafted IPSec packets that would cause the IPSec device to reload hence causing the Denial of Service attack. No workarounds are available to mitigate this threat. Customers are urge to upgrade their running OS (either ASA OS or IOS XE).
Which products are affected
Cisco IOS XE Software products affected by this vulnerability:
Cisco ASR 1000 Series Aggregation Services Routers:
- ASR 1001-X
- ASR 1001-HX
- ASR 1002-X
- ASR 1002-HX
- Cisco ASR 1000 Series 100-Gbps Embedded Service Processor (ASR1000-ESP100)
- Cisco ASR 1000 Series 200-Gbps Embedded Service Processor (ASR1000-ESP200)
Cisco 4000 Series Integrated Services Routers:
- ISR 4431
- ISR 4451-X
The routers must be running an IPSec related technology.
List of vulnerable technologies on IOS XE
- LAN-to-LAN VPN
- Remote-access VPN, excluding SSL VPN
- Dynamic Multipoint VPN (DMVPN)
- Group Encrypted Transport VPN (GET VPN)
- IPsec virtual tunnel interfaces (VTIs)
- Open Shortest Path First Version 3 (OSPFv3) Authentication Support with IPsec
Cisco ASA products affected by this vulnerability:
Cisco ASA 5500-X Series Adaptive Security Appliances:
- ASA 5506-X Series
- ASA 5508-X Series
- ASA 5516-X Series
No other models are affected!
List of vulnerable technologies on ASA XE and FTD
- LAN-to-LAN IPsec VPN
- Remote-access VPN using the IPsec VPN client
- Layer 2 Tunnelling Protocol (L2TP)-over-IPsec VPN connections (not supported on FTD)
New vulnerability discovered in Cisco ASA, ASAx and Firepower devices
A new vulnerability was publicly announced last Friday (22th of June). It effects all current Cisco ASA devices (all models) and Firepower appliances (please see full list below).
It allows a remote attacker to execute a DoS (Denial-Of-Service) attack towards the vulnerable device and potentially extract sensitive data from the device (credential usernames and active sessions). It exploits the HTTP(S) service on the devices and uses directory traversal to try to gather sensitive data and potential reload the device. The vulnerability is possible due to lack of proper input validation of the HTTP URLs.
The discovery was made by a Polish Security researcher named Michal Bentkowski and was initially shared only with Cisco, giving time for Cisco to prepare patches and updates to its software. There have already been real-life attempts in exploiting this vulnerability due its lack of complexity and how easy it is to do it – there is already a couple of scripts on the internet to automate the process (see links below). Cisco states there is no work-around for this problem and all its customers are urged to upgrade to the patched software that Cisco has released prior to the unveiling of the vulnerability.
How to check if your devices are vulnerable:
If you have not patched your devices since the 22th of June and are using ASDM/CSM or Anyconnect on a publicly facing interface then it is very likely you are affected.
Simple steps to validate if your devices are vulnerable
1. Check if your devices is listening on SSL ports
ciscoasa# show asp table socket | include SSL|DTLS
Look for open sockets on public facing interfaces
2. Check for presence of a process called Unicorn Proxy Thread, if this process is present, your device is considered vulnerable
ciscoasa# show processes | include Unicorn
Mwe 0x0000557f9f5bafc0 0x00007f62de5a90a8 0x0000557fa52b50a0
3632 0x00007f62c8c87030 30704/32768 Unicorn Proxy Thread 218
Look for open sockets on public facing interfaces
- 3000 Series Industrial Security Appliance (ISA)
- ASA 1000V Cloud Firewall
- ASA 5500 Series Adaptive Security Appliances
- ASA 5500-X Series Next-Generation Firewalls
- ASA Services Module for Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers
- Adaptive Security Virtual Appliance (ASAv)
- Firepower 2100 and 4100 Series Security Appliance
- Firepower 9300 ASA Security Module
- FTD Virtual (FTDv)
Malware has evolved so much in recent years and the trend is to keep evolving with ever increasing pace. Traditional Firewalls that use old technologies such as stateful firewalling are not capable of detecting / preventing most of the modern threats. The restricted use of traditional firewalls to lower the attack surface is not sufficient and not effective anymore. Vulnerabilities get discovered every day, many of them critical, server administrators often lack the required knowledge to protect/patch their devices. Endpoints (desktops/laptops/smartphones) are constantly at risk due to the fact bad “actors” are constantly coming up with clever ways to bypass traditional defenses and deliver malware, quite often exploiting the weakest link (the users), companies cannot cope with training users in the field of IT security quick enough.
Before, now and future
It is obvious that additional security on the network layer is mandatory. But the controls that are to be used must meet certain criteria, they must be what the industry call Next-Generation Firewall, meaning the device should be able to identify users, applications, do advanced threat protection using different methods (signatures, reputation, sandboxing) and provide detailed reports/logs for pro-active and reactive (forensics) purposes. All current high-end vendors on the market provide this Next-Gen FW capability. Cisco has done something very clever, it decided many years ago (after the purchase of Sourcefire) that it would integrate the Sourcefire functionality into its Firewall technology and is dominating the market with its next generation ASA products. The result was a very flexible solution, albeit a bit cumbersome to configure. The client has the option to enable just the ASA functionality and hence have only a stateful Firewall, or also add the advanced Sourcefire Next-Gen FW capabilities. Cisco even sells all current devices (the 5500 X series) with a built in Firepower (Cisco rebranded Sourcefire into Firepower) capability. A significant number of customers are actively replacing the older ASAs with new X series ones. Many without enabling the Firepower capability. As mentioned briefly above, the reasons for this decision vary but the main one was the added complexity and the separate management that the Firepower needed. This translates into added cost, as usually these skills are not available internally and had to be sourced from outside consulting companies. Also, the Firepower product cannot just be configured and forgotten about but needs small adjustments and manual intervention from time to time, again adding to the operational costs.
With more customers adopting and embracing the Firepower solution, the solution has matured, especially after the introduction of Firepower 6.1. Installation, integration and support have become more user friendly. Which meant operational costs have reduced significantly. Transition between pure ASA and ASA + Firepower was streamlined and could be done within days and without any downtime for the customer. A small investment in purchasing the licenses for Firepower, as customers already had the hardware, and the additional consulting services could in fact be the difference between a secure network and a compromised one. We all know that this is a very bad and expensive experience. This investment made would immediately start to pay off and ensure a completely different way of securing your network that cannot be compared to the archaic traditional firewalls. In the future Cisco and many other vendors will completely get remove stateful only Firewall devices. Cisco is going to replace all ASA with the new appliances capable of running a united operating system – the Firepower Threat Defense. The switch to this is inevitable, so there are no benefits whatsoever for waiting. The work for the transition/migration must be done and the sooner the better. Simply put, there is more protection and security provided to all resources behind the Firewall.
We urge to our customers not to wait until it is too late. Don’t be reactive to a compromised network, take the initiative today and avoid the inevitable.
If you already have the ASA X series deployed there are just a few simple steps to attain all the benefits from the most advanced Intrusion Prevention system at the moment.
Why wait? Contact 4CornerNetworks today to discuss.
Cisco currently has multiple endpoint security solutions in place – CWS (Cloud Web Security / Scansafe), Umbrella (OpenDNS) and AMP for endpoints are prime examples. AMP is a different breed of endpoint protection, it relies heavily on detection based on heuristics and cloud sandboxing, where as CWS and OpenDNS both concentrate very strongly on making sure your Internet browsing is secure and save.
A bit of history behind the story: when Cisco acquired Scansafe and then sometime later OpenDNS, a lot of people were wondering why Cisco needs two products that have such a large overlap in functionality. At first CWS looked like it was going to last, it had a large customer base, was heavily pushed by Cisco Sales and managed to get a big boost from existing Cisco customers that needed protections for this security gap which was opened by remote/roaming employees.
OpenDNS with most of its customers using the free version seemed like an outsider. It could only detect things based on DNS and was not tunneling any traffic back to the cloud, so it seems like it is not going to be a valid corporate level endpoint protections tool. People underestimated the power of DNS. OpenDNS has something very valuable, via its free version, it had the ability to see a large percentage of worldwide DNS request and using its strong security team it provided a more universal and complete protections that focuses on more than just web browsing. Almost all internet communication is based on DNS, the use of static IPs has been greatly reduced for couple of reasons – for non-malicious users the DNS provides first ease of use and flexibility that static IPs could not, for malicious users – the use of static IPs proved to be unwise as IPs were very quickly blocked (blacklisted) by ISPs and security tools. The result of massive DNS use was that your DNS provider could actively see where your traffic is going and block it (monitoring and enforcement) for all applications (not only Web based).
It was clear Cisco would have to make a choice and I believe they have made the correct one – Cisco is moving forward with the Umbrella and retiring the CWS.
What is Umbrella?
In short, the paid version of OpenDNS, which can support and integrate with other Cisco Products.
How does it work?
It works by forwarding DNS request to OpenDNS servers, either by registering your public IP with Umbrella and forwarding your internal DNS to OpenDNS servers, or by setting your network equipment (DHCP) to directly give out OpenDNS servers for DNS usage, in case the company does not have own internal DNS servers. That secures devices within the offices of the company. For Roaming devices, Umbrella has a Roaming Client (a small agent installed on endpoints, supports Windows and MACs, with vision to support Linux in the future) that makes sure all DNS requests are forwarded to the OpenDNS cloud.
It is very important to note that Umbrella does not work like a traditional Web Proxy, it does not send the all user traffic to the cloud for inspection, it only works and makes decisions based on the information from the DNS requests from the client. User traffic is send for inspection to the cloud only for gray/risky domains (traffic to malicious ones is blocked straight away). Furthermore, this redirection of traffic works for both Agent and Agentless deployments by using the DNS reply to forward the traffic to the Umbrella Cloud proxy service called Umbrella Intelligent Proxy.
The result is a better user experience (instantaneous decision to allow and block traffic to majority of traffic based on good and bad domains), lower deployment complexity and lower operational costs.
How is it configured?
Umbrella is one of the easiest deployments we have seen. It has excellent documentation and simple steps to help you redirect your office traffic to the cloud and deploy Roaming clients to your endpoints. All the management is done via portal in the web (https://dashboard.umbrella.com/). It has a very simple and effective portal layout with intuitive access to both management entities (managed identities and policies) but also monitoring and reporting. A typical simple implementation of Umbrella can be done in a matter of hours, without the need of any on-premise hardware installations (except when AD integration is needed, a lightweight virtual server needs to be installed)
Does it support AD integration for enhanced user visibility?
Yes, it does, it needs a VA (Virtual Appliance, a lightweight virtual server running on either ESX or Hyper-V). The VA servers allows Umbrella to see internal information such as private IP addresses of users and further performs an AD integration with MS AD (servers as a connector) so Umbrella Dashboard can see AD names and be able to define policies based on groups and create reports that include clients AD username (very handy if you want to know who exactly is making all of these malicious outbound requests (such as Command and Control traffic et).
Can it block based on connections that do not use DNS?
Yes, it can, there is a functionality called IP Layer Enforcement that builds IPSEC tunnels to the Umbrella cloud and forward requests to it in case the connection has a suspicious (flagged as malicious) IP address. This is possible only if the client is using Roaming Agent (either the Umbrella one or Anyconnect one).
Does it have integration with other Cisco products?
Umbrella has a module for Anyconnect (Cisco Umbrella Roaming Security module is available for Anyconnect version 4.3 MR1 and newer), which means if the customer has Anyconnect already deployed, there is no need to install Umbrella Roaming Agent. Also, OpenDNS security team is now part of Cisco Talos so OpenDNS both feeds Talos with DNS information but also benefits from Talos to device either certain domain or IP address are deemed risky.
Does it support SSL decryption?
Yes, Umbrella supports SSL decryption so it can do deep inspection for traffic destined for risky/suspicious domains. The configuration of the SSL decryption is very straight-forward, administrators are prompted to download Umbrella (OpenDNS) certificated from the Dashboard and then these certificates need to be installed as trusted on endpoint machines. Next step is just to enable the SSL decryption.
Umbrella provides enterprise level endpoint security with lower latency than traditional proxies, low capex and deployment costs.
Virtual Private Networks constitute a hot topic in networking because they provide low cost and secure communications between sites (site-to-site VPNs) whilst improving productivity by extending corporate networks to remote users (remote access VPNs). Naturally the VPN technology is widely deployed on all internet edge devices and most ASAs.
Cisco is very proud of its VPN solutions. It’s one of the few vendors that support such a wide range of VPN technologies with so many features and flexibility. Cisco Routers and Cisco ASA Firewalls are the two types of devices that are used most often to build Cisco Virtual Private Networks. Cisco has been very strict about the way its routers and firewalls should be used and what technologies are available to them – routers will do the full range of Site-To-Site of VPNs: Traditional (Policy-based) IPsec VPNs, but also GRE IPsec VPNs, DMVPNs, GET VPNs, and have limited capabilities for the remote access VPNs: IPsec and SSL based. However, the ASA is very different so far it could do just traditional policy based L2L IPsec VPN but will have the full functionality for remote based VPNs. The message was very clear, for large organization and ISP use Routers for remote access VPN and static traditional Site-to-Site use the ASAs.
Things changed, Cisco very recently introduced a new feature with its 9.7.x code in the VPN module of the ASA – the VTI (Virtual Tunnel Interface). VTI were long available in Cisco Routers but never in Cisco Firewalls but similar technologies (Route-Based VPNs) were available in most competitors and the demand for that features finally took effect on Cisco and they introduced it.
Now before understanding why VTI are so important we will do a quick comparison between the traditional Site-to-Site IPsec VPN (Policy Based VPNs) and the VTI (Route-Based VPNs)
Policy Based VPNs
They rely on static (policy based) configuration of the encryption domain (usually by ACLs) and do not pass multicasts, not great for dynamic routing and voice/video and other multicast applications and requires re-configuration on both sides if the networks that traverse the VPN should change. The configuration is quite complex involving many steps that need to be same or mirrored (encryption domains/ACL config) and that is prone to mistakes.
However, the benefits are that this is a well matured configuration process and the IPsec VPN is a IETF standard which means all vendors must implement it according to the specifications of the standard, hence in theory it should always work between in multivendor scenarios. This is important because the two main uses of L2L (Site-to-Site) VPNs is connecting same company sites over internet thus replacing more expensive intranets or connecting one company to another company/partner/provider of services over Internet in a secure manner. In that second case, there is a big chance that both companies will use different vendors for VPN devices.
A route-based VPN configuration uses Layer3 routed tunnel interfaces (either GRE based or VTI based) as the endpoints of the VPN. Instead of selecting a static subset of traffic to pass through the VPN tunnel using an Access List, all traffic passing through the special Layer3 tunnel interface is placed into the VPN. Therefore, you need to configure routing accordingly. Either a dynamic routing protocol (such as EIGRP or OSPF) or static routing must be configured to divert VPN traffic through the special Layer3 tunnel interface. That makes the selection of interesting traffic dynamic and you have the flexibility to perform changes and introduce new traffic to the VPN without redoing the VPN configuration (only by changing the routing so new traffic gets routed to the interface). Another benefit is that this type of VPN can pass multicast traffic thus allowing dynamic routing protocols and enabling multicast applications to work.
There are some limitation and considerations that need to be taken in mind. First VTI is a proprietary to Cisco technology, despite other vendors having similar route-based VPN technology, there is no guarantee these will work between each other. Also, the tunnel interface itself does not provide inherited security, IPsec protection is an add-on and needs to be configured on top for encryption/security of traffic.
Summary and conclusions:
Introducing VTIs in ASAs is a big step forward in making the firewall an even more versatile network edge device. The VTI capability to provide security and encryption on multicast traffic and its flexibility for tunneling the traffic via dynamic routing with zero reconfiguration on the VPN, means that any small or middle-sized organization with ASA on network edge can now benefit very strongly from that functionality and would not need to purchase additional hardware thus maximizing its return on investment value.
Cisco has finally decided to merge its two major network security products – the ASA and FirePOWER. These two have been living on the same hardware (5500X) model for years now but they required separate management which increased the deployment and operational costs for a Cisco FirePOWER implementation. Now Cisco has decided to merge these two platforms by removing the logical separation in hardware and the full separation in software by creating a merged OS that combines the features of both worlds, hence lowering the time/costs for deployment and running.
A bit of History
Cisco is a major player in the Firewall Market since the PIX. With the introduction of the first gen ASA, the PIX was given a polish, new features (such as dynamic routing, QoS, new RFC based protocol inspections/fixup and a few more), but ASA’s were and still are a traditional stateful packet firewall positioned at the Internet Edge. The demands to introduce firewalls also in the DC drove the change from IP based object to Name based object and totally different way of doing NAT (including the introduction of the Any as interface) in versions 8.3+. Still the ASA was purely a stateful firewall and the IDS/IPS module that Cisco was offering was quite outdated in technology and had a less than excellent catch-rate. Cisco knew that and purchased the best IPS/IDS vendor out there – SourceFire.
Now Cisco had two flagmen in the network security and naturally decided to offer them as one box – hence the NX 5500X Firewalls were created, no modules needed, all you need to run both ASA and FirePOWER was an upgrade to SSD drives. However, the management, logging, operation of the ASA and FirePOWER was still independent – ASA was managed and monitored by either ASDM or CSM, where FirePOWER was using – FireSight (pre-version 6) and now FMC (Firepower Management Center). Most competitors (Palo Alto and Check Point) did not need nor have separate management platforms to configure their advanced Next-Gen capabilities and frankly speaking users/admins were not happy with having to do double amount of work to enable a Cisco Next Gen Firewall – interfaces, licensing, configuration, policies, monitoring etc.
In 2015 Cisco hinted about the concept of having one unified management OS that would combine the features of both FirePOWER and ASA. The FirePOWER was chosen as a base for that new image, so from day one the FTD image had almost a 100% of the FirePOWER functionality but a very small percentage of the ASA functionality. The first release (6.0) for testing and Cisco partners was in 2016 and then the FTP had about 20% of the features of the ASA – basic features of course were migrated first, but shockingly there was lack of some major features such as – HA, VPNs (both site-to-site and Anyconnect), dynamic routing protocols, virtualization/contexts, QoS. A quick introduction of 6.0.1 and 6.1 introduced HA failover so the FTD was now ready to go public.
The Situation today
Latest version release early 2017 is 6.2.0
Cisco continued its work to close the gap between the current ASA and FTD functionality. New major functionality added: Clustering for ASA, Site-To-Site IPSec VPN with certificates (6.1 supported Site-to-Site VPN but only with Pre-Shared-Key), PKI support, SGT without Realm, Migration tool (from traditional ASA to FTD), REST API, Packet Tracer and Capture functionality.
On top of the migrated in 6.1 functionalities such as integrations with Cisco ISE, Threat Grip, on-box management for some model, the 6.2 is looking more and more enterprise ready (not only SOHO as the 6.0 and 6.1). Also, adding the tools for automated migration, the FTD becomes more easily available when doing migration. The user base is also enlarging quite quickly (good for discovering of bugs and security/stability issues). Version 6.2.1 is just around the corner and will close the gap even further introducing the Anyconnect Remote Access functionality and many improvements/new features in NAT, Dynamic Routing, Multicast and QoS, HA, Site-To-Site VPN and interestingly an option for conversion back to ASA image.
This all points that soon there will be a major swift in the Cisco Security community and more and more clients will start using FTD. Naturally after break-point Cisco will start the phase out of the traditional ASA image (functionality gap will be in favor of the FTD) and clients will be forced to switch. Of course, that process will take time but why not be ahead of the curve?
The traditional legacy ASA Firewalls (5505, 5510, 5520, 5540, 5580) are End of Life (EOL) and soon will be End of Support (EOS). There are still a vast number of ASA’s in the public realm used as a security device/internet edge firewalls where many companies think they are providing the necessary security, the reality cannot be further from the truth.
These older model ASA’s have the following problems
- Hardware Problems
Cisco ASA Firewalls have a Meantime-Between-Failure (MTBF) which is simply the predicted elapsed time between inherent failures of such devices. When legacy ASA’s are out of support it is not possible to renew support contracts as Firmware updates are no longer available, effectively making the devices EOL. Meaning they are a ticking bomb and without support any network can suffer significant downtime when the device gives up.
- Code Vulnerabilities
ASA updates are uncommon, occurring every 6 months or so, meaning security holes can appear with such a time gap between security patch updates. Effectively your device is vulnerable and unsecured whilst it awaits the next patch update. Currently legacy ASA Firewalls only run to version 9.1 updates. These vulnerability problems wouldn’t be a threat if default and most deployed scenario is an Internet Edge Firewall.
- Lack of new features
Cisco is not deploying any new features to the legacy ASA’s and the major version will probably not move away from 9.1 (when the newest is 9.6 for next generation Firewalls)
- Lack of real security
Any working firewall cannot only rely on the Stateful Firewall technology for protecting the assets of an organization. Legacy ASA’s can only run the legacy Cisco IPS with a separate module which cannot measure to the modern IPS technology. The new generation of firewalls have the Firepower functionality which is the industry leading IPS technology.
Challenges for migrating Legacy ASA to ASA X?
- Configuration migration
- Manual migration – Configuration between Legacy ASA’s and the new ASA X usually differs and cannot be simply copied and pasted into the new device. Different naming for interfaces and different features and functionalities means different syntax for the CLI.
Very often the legacy ASA’s run a pre-8.3 code due to RAM restrictions (RAM needs to be upgraded for post 8.3+ code). The pre-8.3 code is very different from today’s code in terms of syntax. It does mandate the obligatory use of objects, the NATs are the old PIX like fashion and any policies use the global ip addresses (the so called real ip addresses seen on the interface) than the original one (the ip addresses on the hosts). That means that large portions of the config need to be redone (in most cases manually) when you do the switch over.
The sections that needs manual work are: Objects, NATs, Policies and ACLs. That is the recommended approach and usually an experienced Cisco Security Consultant is needed to perform the job.
- Automatic migration is possible if the legacy ASA has its RAM upgraded (512MB for 5505 and more than 1GB for the other models is mandatory). Depending on the starting OS Image version several upgrades are done to ensure the device runs the latest 8.2.x code and then jump to 8.4.1. During that jump the device will automatically redo the configuration to its best (will shout out errors on console while booting if it cannot migrate certain areas of the config), it will create objects (with automatic names) and will deploy them.
During automatic migrations, there is always a chance that something will not work so the migration again needs to be performed by someone who understands the migration process, can track down and manually intervene to correct errors or add configuration after the migration. Also, the configuration after an automatic migration is not easily readable due to the creation of objects with automatic naming convention.
- Raising the security level – if you migrated from a legacy ASA to a new generation ASA X that supports other security technologies and Firepower then it makes sense to leverage new technologies and enable/configure/tune them. A blind one-to-one migration might give you more in the world of availability (new hardware, newer code, less code vulnerabilities and frequent code updates), but will not give you ultimately better protection for your assets. A deep packet inspection with content analysis is a must in the modern threat landscape. Implementing the Firepower technology is necessary but a complex step that needs to be done by people with the right skillset and experience.
- EOS / EOL announcement
+44 (0) 131 516 9771
88 Wood Street, 10th Floor, Wood Street, London, EC2V 7RS
0203 697 0353