As experts in Cisco Professional Services, the 4CornerNetworks blog covers a wide range of Cisco Network related topics. Our blog features topics from Cisco Support Services, Cisco Engineers and our specialist blogs based on Cisco Security.
Head of Security Deyan Panchev writes about Cisco Security providing advice, tips and insights into topics such as Cisco Firepower services, Cisco ASA Firewall Support, Installations and Deployments. Topical issues about network security are also discussed on our blog ranging from the NGFW (Next Generation Firewalls) to the recent Wannacry outbreak.
Subscribe to the 4CornerNetworks blog and follow us on LinkedIn and Twitter for the latest updates.
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.
The Russia bear is having a snack out of Ukraine it seems but also more than 100 other countries are involved. Cisco devices are NOT vulnerable but for me that is a valuable marketing as it shows the value of actually having a nice vendor and not a cheap one.
In the last months and years we have seen multiple DDoS attacks based on amplification techniques (DNS, NTP, Chargen, SSDP)
A new amplification attack was spotted in the last week of February (25th – 27th of February).
It is, by far, the strongest amplification attack we had and it is based on the Memcached protocol running on UDP port 11211.
Sources at CloudFlare state the attack reached 257Gbps.
Why the Memcached Protocol?
The answer is simple, it supports UDP which is stateless (which is necessary for amplification attacks), it lacks any form of authentication, and when it turns out it provides excellent ratio in amplification (the difference between the size of the trigger packet and the response).
Amplification ratio in the attack was around x10000 times but the protocol itself is capable of x51200.
The attack stats detected on CloudFlare show UDP datagrams with 1400B size. The number of packets peaked to 23Mpps which measures to the reported total 257Gbps of bandwidth. And that is a lot, it can cause very serious outages.
How does an amplification attack work and how it can be prevented?
To successfully lunch an amplification attack you need 3 components:
- Capability to spoof IP packets, meaning access to a high-bandwidth pipe on ISP that does not do a solid job in securing anti-spoofing
- Application/Protocol that is amplification friendly – UDP based, no authentication, protocol allowing large responses to be created based on small requests
- Reflector servers running a suitable protocol – These are servers that are reachable from Internet and that are going to respond to requests
How does the attack work?
The attackers send a large number of very small requests from a high-bandwidth pipe behind ISP(s), that allow ip spoofing, destined at a large list of publicly accessible application servers. The attacker is spoofing the source IP on all these requests to the target public IP address. All servers are made to respond with much larger packets to the requests, wrongfully directing all that traffic towards the unsuspecting target. The idea is to cripple either the target server/device or to congest its internet pipe, both causing Denial of Service.
How can Amp Attacks be prevented?
If any of the three components outlined above is not available, then there is no way to perform a successful Amplification attack.
Simple steps can make a bit difference.
- ISP should always adhere to the strict anti-spoofing rules and allow outbound traffic only from sources belonging to their IP ranges.
- Developers should think about security when creating new applications and protocols. UDP should be avoided unless low-latency is needed, and if UDP is used, the protocol should have some form of authentication and should never allow a reply to a request ratio bigger than 1. Meaning all replies should be smaller or equal to the request that generate them.
- Administrators should correctly “firewall” their servers and allow access to the services to whomever needs them; and not the whole Internet. Certain types of responses might be blocked from within the application or at Firewall level.
So far, the 2018 has been catastrophic for Intel.
Three major vulnerabilities were found in a very short span of time, and Intel team cannot catch up fast enough with the patching and the security updates.
The newest one is from the 12th of Jan and disclosed by a Finnish Security Company (F-Secure). It uses a bug in the AMT (Active Management Technology) feature of certain Intel based systems. The AMT was designed as a helping tool for administrators to assist with managing their vast fleet of endpoints but bad implementation makes all of these devices completely unsecure when physically accessible.
The attack is extremely simple and allows for anybody (without any particular technical skills) to launch it. Basically, the baddy needs only to reload/shutdown and power up the endpoint that has Intel AMT enabled, then despite all authentications (like BIOS password or OS authentication) the baddy needs only to do Ctrl+P during book process (which takes him/her to MEBx (Management Engine BIOS extension) login and use the default password (admin) to login. Next steps are simple, change the password so nobody can access and change back the settings or disabled the AMT, and allow remote access to the endpoint (there is even an option to not allow the legal user to stop this. After that physical access to the endpoint is not needed, the attacker can manage the machine as long they are on the same network (wireless or wired). The attack is dangerous, because it’s so simple to implement, takes no more than 30 seconds, gives full access to the endpoint and bypasses other security controls. The recommended actions to protect AMT enabled endpoints are quite logical: change default pass to complex secure password, disabled AMT if you are not using it, and keep an eye on your endpoint and do not give anybody else physical access to it.
We have all heard by now about the other major vulnerabilities that were recently disclosed, namely the famous Meltdown and Spectre. We will not discuss in detail how these attacks work as that was already covered in detail and available from many sources but would like to summarise how this is affecting end users and other vendors in the chain.
First, the official and best way to be protected against these two attacks is to change the chips but obviously that is not really a feasible solution for many end users and companies. Major OS vendors have taken steps to patch their respective OS.
Microsoft has patched Windows 10 fairly quickly and just recently (9th of Jan) patched Windows 7 and 8 for the Meltdown vulnerability. A note – users are urged to check if the patches were successfully installed as some anti-virus systems (including Windows Defender and Microsoft Security Suit) can prevent the patch to be installed.
Apple has been bold in saying despite all their systems being vulnerable to Meltdown and Spectre, there is no well-known exploits impacting their customers. Still Apple released released mitigations in iOS 11.2, macOS 10.13.2, and tvOS 11.2.
Android – Google has released its patches on the monthly security patch on the 5th of Jan. However, they would immediately become available only for pure Google phones (Pixel and Nexus), all the rest of the android users need to wait for their retrospective vendors to release patches.
Firefox browser – Mozzila released a patch and recommends all user to update Firefox to version 57.0.4.
Chrome – The patch is included in the new 64 bit version of the browser that will be released on the 23th of Jan. If you want added security Google recommends you use the Site Isolation experimental feature.
Linux – the Linux kernel developers have reacted quickly and patches are available for most used kernel versions.
Due to the nature of the attack (possibility of seeing memory from other applications) the virtualization platforms were badly affected. The two largest vendors, VMware and Citrix however, have decided to take completely different actions courses.
VMware released security patches for all of his affected major products – ESXi, Fusion and Workstation. We need to note here that the patch helps only with Meltdown attack.
Citrix has decided not to release security patches but transfer the risk to its clients and recommends them to check for any patches on 3rd party software.
It is worth mentioned also that most of the OS based patches (not browser patches) are created only to protect again the Meltdown attack as the Spectre is harder to patch and security experts believe it will be around for some months and maybe years to come.