Cisco SIP inspection based DoS attack

Foreword:


At the end of Oct, Cisco announced a vulnerability in its ASA OS and Firepower FTP running products.

The vulnerability is based on the SIP inspection code that handles SIP signaling packets.

The vulnerability:


The FW do inspection on protocols for various reasons, NAT fixup, added security, discovery of dynamic port connections and allowing traffic to pass via the firewall etc. The SIP inspection is part of the default Global Inspection Policy that is enabled on the device, meaning all firewalls with default configuration for inspection are affected.

A bombardment of a high-rate specifically crafted SIP requests can impact the firewall (high CPU load) and cause legitimate traffic to cease hence causing a Denial of Service.

There is currently no software updates from Cisco to address this vulnerability. All mitigation options are based on additional configuration and listed below

Affected Products:


  • Vulnerable Products

This vulnerability affects Cisco ASA Software Release 9.4 and later and Cisco FTD Software Release 6.0 and later on both physical and virtual appliances if SIP inspection is enabled and the software is running on any of the following Cisco products. Worth noticing is that SIP inspection is enabled by default


  • 3000 Series Industrial Security Appliance (ISA)
  • 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 Series Security Appliance
  • Firepower 4100 Series Security Appliance
  • Firepower 9300 ASA Security Module
  • FTD Virtual (FTDv)

NOTE: Older (EOL) Cisco ASA 5500 series are NOT affected (due to older code). Also the Virtual ASA (ASA 1000V) is not affected

Determining if your product is vulnerable:


Check your current running software versions

For ASA:

ciscoasa# show version | include Version

If version is above 8.4 then it is vulnerable

For Firepower FTD:

> show version

If version is above 6.0 then it is vulnerable

Is my firewall under attack?


During an active attack you will be able to see large number of connections coming to your firewall on port 5060 (traditional SIP port and the one the Cisco devices are listening to in order to perform the inspection).

The following command will show the current SIP connections, they will be listed as incomplete as the source of the DoS only actively bombards the firewall without closing the SIP connection.

show conn port 5060

Another useful command is:

show processes cpu-usage non-zero sorted

This will show you the current cpu usage per process. Typical high CPU values will be observed during the attack. A continuous exploit of this vulnerability will cause continues high-CPU and could cause the device to crash and reload itself

Another indicator of compromise for this attack is a sudden reload after a network slowdown and the presence of a crashfile

show crashinfo

After the device boots up again, the output of show crashinfo will show an unknown abort of the DATAPATH thread

Workaround (Mitigation):


There are several options, all limiting the allowance of these SIP packets to reach or overwhelm the device

1. Disable SIP inspection

Have SIP inspection only if you are actively using it. Our experience with SIP inspection is that usually it is not required (not all customers are doing SIP trunks from inside the organization to a IP Telephony provider in the cloud). Even if SIP is in use, most SIP providers would actively ask you to disable the SIP inspection as Cisco is slow on updating it comparing to how fast SIP protocol changes. SIP providers would ask you just to open specific port ranges and not rely on this inspection due to multiple reasons.

To disable SIP inspection, configure the following:

For Cisco ASA Software 
policy-map global_policy
 class inspection_default
  no inspect sip

For Cisco FTD Software Releases
configure inspection sip disable

Note: This command is issued from the FTD CLI.

2. Actively block IP address(es) of the attackers

You can always actively block (by ACL) the offending IP address that you are seeing via the show conn port 5060. You need also to clear the existing connection issuing clear conn address

Other option is the old shun command that blocks all traffic from certain source IP

shun

This does not survice a reload

3. Filter out based on the SIP attributes

Most observed attacks use an SIP attribute of Sent-by Address that is set to 0.0.0.0. That is not typical behavior for a valid SIP communication, the attack can also be confirmed by doing a packet capture and noticing the amount of packets arriving from a SIP address you are not expecting. You can read the packet captures, check for the Sent-by address and if values are set to 0.0.0.0 and previous methods of mitigation are not valid for your environment then you can proceed and implement this change

regex VIAHEADER “0.0.0.0”

policy-map type inspect sip P1
parameters
match message-path regex VIAHEADER
drop

policy-map global_policy
class inspection_default
no inspect sip
inspect sip P1

4. Rate limit all SIP traffic

Not a great option as that could also influence legitimate traffic, however SIP is the signaling protocol for setting up voip connections, so in nature it should not be very chatty.

You can use the Cisco MPF (Modular Policy Framework) to create a policy and match the SIP traffic and then set a rate limit on this traffic so it would not cause the high cpu spike. Configuration can vary here, so it needs to be done by an expert on product or an external capable consultant.

Nyatya Wiper Malware

Cisco ASA 5500 Series and Cisco IOS XE – IPSec related DoS vulnerability

Nyatya Wiper Malware

Foreword

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.

Overview

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)
  • FlexVPN
  • 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)

How to fix this:


As we mentioned there is not workaround for that vulnerability, an update is needed.

Cisco has released today the necessary upgrades to all vulnerable software


Cisco ASA table with vulnerable OS and which is the update to fix it

Cisco ASA Major Release First Fixed Release for This Vulnerability
9.3Affected; migrate to Release 9.4
9.49.4.4.18
9.5Affected; migrate to Release 9.6
9.69.6.4.8
9.7Affected; migrate to Release 9.8
9.89.8.2.26
9.99.9.2.2

Cisco FTD table with vulnerable OS and which is the update to fix it

Cisco FTD Software ReleaseFirst Fixed Release for This Vulnerability
6.0Migrate to 6.1.0 HotFix or later
6.0.1Migrate to 6.1.0 HotFix or later
6.1.0Cisco_FTD_Hotfix_EI-6.1.0.7-2.sh (all FTD hardware platforms except 41xx and 9300)
Cisco_FTD_SSP_Hotfix_EI-6.1.0.7-2.sh (41xx and 9300 FTD hardware platforms)
6.2.0Not vulnerable
6.2.1Migrate to 6.2.2.3
6.2.26.2.2.3
6.2.36.2.3.1
6.2.3-851
6.2.3-85.02

For Cisco IOS XE Cisco recommend a manual check with their online Cisco IOS Software Checker at:

https://tools.cisco.com/security/center/softwarechecker.x

New vulnerability discovered in Cisco ASA, ASAx and Firepower devices

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

Affected models:

  • 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)

Fixed Releases:


Customers should upgrade to an appropriate release as indicated in the following tables.

Cisco ASA Software

Cisco ASA Software ReleaseFirst Fixed Release for This Vulnerability
Prior to 9.11Migrate to 9.1.7.29
9.1 9.1.7.29
9.29.2.4.33
9.3 Migrate to 9.4.4.18
9.49.4.4.18
9.5Migrate to 9.6.4.8
9.69.6.4.8
9.79.7.1.24
9.89.8.2.28
9.99.9.2.1

Cisco FTD Software

Cisco FTD Software ReleaseFirst Fixed Release for This Vulnerability
6.0Migrate to 6.1.0 HotFix or later
6.0.1Migrate to 6.1.0 HotFix or later
6.1.0Cisco_FTD_Hotfix_EI-6.1.0.7-2.sh (all FTD hardware platforms except 41xx and 9300)
Cisco_FTD_SSP_Hotfix_EI-6.1.0.7-2.sh (41xx and 9300 FTD hardware platforms)
6.2.0Not vulnerable
6.2.1Migrate to 6.2.2.3
6.2.26.2.2.3
6.2.36.2.3.1
6.2.3-851
6.2.3-85.02

Cisco Security

End of the Traditional Firewalls Era – Cisco ASA is not enough anymore

Cisco Security

Foreword:

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.

Conclusion:

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.

https://4cornernetworks.com/contact/

New major security threat

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.

https://blog.talosintelligence.com/2018/05/VPNFilter.html

Yet another critical vulnerability found for Cisco devices

Foreword:


On the 29th of March a company that deals with security in embedded devices, called Embedi published their discovery about a critical vulnerability in most Cisco Switch devices (both running IOS and XE).

The vulnerability (CVE-2018-0171) is based on stack buffer overflow and is possible due to improper validation of packet data in Smart Install Client, a plug-and-play configuration and image-management feature that helps administrators to deploy (client) network switches easily. The service is running on TCP 4786, opened by default and listening when service is enabled (which is by default).

Yet again a new functionality that is meant for easier deployment and potential less operational costs during deployment poses a serious security risk. The vulnerability is deemed as critical because it gives complete access to the device or be used to do a DoS on the device, meaning it can crash the device. What makes the case even worse is that the Smart Install Client functionality is enabled by default.

Initially researchers believed that the vulnerability could only be used for attacks inside an enterprise network due to the communication ports usually not exposed to the Internet or to the fact that many of switch or other devices are only internal, because in a securely configured networks because the recommendation is that Smart Install technology participants should not be accessible through the Internet.

However during a short scan of the Internet, researchers detected over 250,000 vulnerable devices and 8,5 million devices that have a vulnerable port open.

Which Cisco devices are affected:


The vulnerability was proven to work on the following devices: Catalyst 4500 Supervisor Engines, Cisco Catalyst 3850 Series Switches, and Cisco Catalyst 2960 Series Switches.

  • Cisco Catalyst 4500 Supervisor Engine 6L-E
    • Cisco IOS 15.2.2E6 (Latest, Suggested)
      • cat4500e-entservicesk9-mz.152-2.E6.bin (23-DEC-2016)
  • Cisco Catalyst 2960-48TT-L Switch
    • Cisco IOS 12.2(55)SE11 (Suggested)
      • c2960-lanbasek9-mz.122-55.SE11.bin (18-AUG-2016)
    • Cisco IOS 15.0.2-SE10a (Latest)
      • c2960-lanbasek9-mz.150-2.SE10a.bin (10-NOV-2016)
  • Cisco Catalyst 3850-24P-E Switch
    • Cisco IOS-XE 03.03.05.SE
      • cat3k_caa-universalk9.SPA.03.03.05.SE.150-1.EZ5.bin (03-NOV-2014)

And here are all devices that may fall into the Smart Install Client type and can be considered potentially vulnerable:

  • Catalyst 4500 Supervisor Engines
  • Catalyst 3850 Series
  • Catalyst 3750 Series
  • Catalyst 3650 Series
  • Catalyst 3560 Series
  • Catalyst 2960 Series
  • Catalyst 2975 Series
  • IE 2000
  • IE 3000
  • IE 3010
  • IE 4000
  • IE 4010
  • IE 5000
  • SM-ES2 SKUs
  • SM-ES3 SKUs
  • NME-16ES-1G-P
  • SM-X-ES3 SKUs

Cisco’s reaction:


The original researchers reached Cisco with their finding before going public with it and the vendor had enough time to patch their software. Official releases after March have been patches against the vulnerability and available for download.

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 to determine if your device is affected:


Issue the following command:

show vstack config

If the output shows that SmartInstall is enabled then proceed with the checks

Check your current running software versions

show version

Use a Cisco official tool to check the vulnerabilities on your Cisco IOS/XE via the following link:

https://tools.cisco.com/security/center/softwarechecker.x

General recommendations:


  • Do not expose unnecessary any communication channels (services/ports) to unsecure networks such as the internet. Keep your devices behind firewalls in order to reduce the potential attack service.
  • Remember to patch your systems regularly

Data Centre for Cisco Network Security

Memcached – Newest amplification attack out there

Data Centre for Cisco Network Security

History:

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:

  1. 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
  2. Application/Protocol that is amplification friendly – UDP based, no authentication, protocol allowing large responses to be created based on small requests
  3. 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.

  1. ISP should always adhere to the strict anti-spoofing rules and allow outbound traffic only from sources belonging to their IP ranges.
  2. 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.
  3. 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.

Related articles:

https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/

Not The Best Intel Month

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.

Related materials:

https://thehackernews.com/2018/01/intel-amt-vulnerability.html

https://thehackernews.com/2018/01/meltdown-spectre-patches.html

https://thehackernews.com/2018/01/meltdown-spectre-vulnerability.html