At the end of 2023 and into 2024, a series of vulnerabilities in Ivanti Policy Secure network access control (NAC), Ivanti Connect Secure secure socket layer virtual private network (SSL VPN), and Ivanti Neurons for zero-trust access (ZTA) products caused concern at organisations worldwide after being exploited by a threat actor suspected of having links to nation-state espionage activity.
In this explainer, we explore some of the key issues arising from the Ivanti disclosures, looking at the vulnerabilities and their impact, how Ivanti has responded, what affected users should do next, and whether it is safe to continue to use Ivanti’s products.
What does Ivanti do?
Utah-headquartered Ivanti specialises in security software, IT service and asset management software, identity management software and supply chain management software.
Its history dates back to 1985 and the foundation of a company called LAN Systems. Over the past four decades, the organisation has grown via a series of mergers and acquisitions, but the Ivanti name only came into being in 2017 through the joining of two firms, LAN Systems successor LANDESK and HEAT Software, under the oversight of private equity house Clearlake Capital.
Since 2017, Ivanti has grown steadily, and now has thousands of employees in 23 countries around the world. It acquired heavily during the Covid-19 pandemic, snapping up names such as MobileIron, Pulse Secure, Cherwell Software and RiskSense.
Ivanti trades on the concept of elevating and securing “everywhere work”, enabling customer employees to use their devices to access IT applications and data however and wherever they need. It has also become a frequent and vocal commentator on security issues, and its experts are frequently quoted in IT and cyber security media.
What are the Ivanti vulnerabilities?
The issues only affect Ivanti Connect Secure (ICS), Ivanti Policy Secure (IPS) and ZTA gateways and are not present in any other Ivanti products.
The first two vulnerabilities are CVE-2023-46805 and CVE-2024-21887. The first is an authentication bypass flaw in the web component of ICS 9.2, 22.x and Policy Secure, that lets a remote attacker access restricted resources by bypassing control checks. The second is a command injection vulnerability in the web components of the same products that lets an authenticated admin send specially-crafted requests and execute arbitrary commands.
These two issues were first officially disclosed on 10 January 2024, having been discovered a month earlier by researchers at Volexity, who spotted suspicious lateral movement on a customer network and were able to identify active exploitation. Volexity determined that the threat actor was using them to implant web shells, including Glasstoken and Giftedvisitor, on internal and external-facing web servers, that they then used to execute commands on compromised devices.
This would have been a big issue on its own, but matters then developed in a worrying direction. Following the initial mitigation guidance from Ivanti, threat actors quickly found a way to get around them to deploy three more web shell variants, Bushwalk, Lightwire and Chainline.
This led to the disclosure of three new vulnerabilities. These were:
- CVE-2024-21893, a server-side request forgery zero-day vulnerability in the security assertion markup language (SAML) components of ICS, IPS and ZTA that lets attackers access restricted resources without authentication;
- CVE-2024-22024, an extensible markup language (XML) vulnerability in the products’ SAML component that has the same effect as CVE-2024-21893;
- And CVE-2024-21888, a privilege escalation vulnerability in the web component of ICS and IPS, that lets attackers gain admin rights.
Why is Ivanti being targeted?
SSL VPN products such as ICS have been historically targeted by a wide range of threat actors, both financially-motivated cyber criminals and nation-state aligned groups, over the past few years – with a five-year-old bug, CVE-2019-11510 in ICS still exploited even today.
Why so? The answer is a relatively simple one: SSL VPNs provide an exceptionally valuable doorway into target organisations, acting as a staging point to access enterprise resources.
Their extensive use by remote workers, who are particularly vulnerable to being exploited by social engineering attacks and other forms of phishing, particularly following the Covid-19 pandemic, makes them a soft target.
As such, addressing vulnerabilities in SSL VPNs and related access products should be an easy prioritisation decision for security teams.
How has Ivanti responded to the vulnerabilities?
In a newly updated FAQ posted to its website on 14 February 2024, Ivanti thanked its customers for their “support and patience” as it navigated the recent issues. It acknowledged that the period has been testing for its customers, and reassured them that it has been working round the clock, with assistance from outside expertise, to resolve the issues.
“From day one, we have been committed to taking a customer-first approach. We have prioritised releases of mitigation and patches as quickly as possible, while also continuing to strengthen our proactive measures to combat the increasingly sophisticated and aggressive threat environment our industry is facing,” the organisation said.
“As we work to support our customers, we have strived to put continuous and direct communications at the forefront. We have also spent a great deal of time listening and incorporating feedback we have heard to continually improve our communications.”
As of mid-February, Ivanti had a secure build available for all supported versions of the affected products.
The FAQ went on to address some misinformation that had arisen following the misinterpretation of a directive from the US Cybersecurity and Infrastructure Security Agency (CISA), which many wrongly thought was instructing federal agencies of the American government to throw out and replace affected products. This was never the case, it was merely telling them to disconnect their products, and CISA has since corrected and updated its guidance.
Ivanti also denied allegations that the Connect Secure product was vulnerable due to old Linux code, although it has been helping customers move off unsupported older versions over the past 18 months.
It went on to add that it had no indication that one of the second set of vulnerabilities – CVE-2024-22024 – had been exploited in the wild, saying some confusion may have arisen in this regard because it is found in the same section of code CVE-2024-21893.
It further confirmed that the vulnerabilities disclosed on 10 January were exploited on a limited basis by threat actors, and that this had sharply increased.
It additionally stressed that while it does use its own tools and technology in-house, it had no indication that it has been compromised as a company, an indication that customer data it holds remains safe.
What should I do to address the Ivanti vulnerabilities?
Ivanti’s full guidance on how to begin to address the vulnerabilities can be found here. The guidance provided below is derived from CISA’s 9 February recent advisory, which officially relates only to federal government agencies in the US.
As of 9 February, affected organisations were being told first disconnect all instances of Ivanti Connect Secure and Ivanti Policy Secure, isolate them from any other enterprise resources as much as possible, and conduct threat hunting on any systems connected to it. Security teams should also monitor any potentially exposed authentication or identity services and audit accounts with privileged access.
To bring the affected products back into services organisations at first were advised to do the following:
- Export your configuration settings;
- Factory reset the product, per Ivanti’s instructions – although it this was already done before applying the patches released on 31 January and 1 February, you will not need to do this;
- Rebuild the product – the instructions on how to do this can be found at the above link – and upgrade to a supported software version through Ivanti, which is free of charge;
- Reimport your configuration;
- If you applied any mitigation XML files, you should review the Ivanti portal for instructions on how to remove these post-upgrade;
- Revoke and reissue connected or exposed certificates, keys and passwords – this includes resetting admin enable passwords, resetting stored application programming interface (API) keys, and resetting any passwords belonging to local users defined on the gateway. This last step should include service accounts used for auth server configuration;
- Having returned the affected products to service, keep on top of future updates that may readdress the vulnerabilities.
CISA also advised that organisations running affected Ivanti products should assume domain accounts associated with them have been compromised, so recommended passwords twice for on-premise accounts, revoke any Kerberos tickets, and revoke other tokens for cloud accounts if your organisation is running a hybrid deployment.
However, the story has now developed significantly further. On 29 February, a new advisory from the US authorities detailed how threat actors may be able to deceive Ivanti’s internal and external Integrity Checker Tool (ICT), resulting in a failure to detect compromise via CVE-2023-46805, CVE-2024-21887, CVE-2024-22024, and CVE-2024-21893.
CISA said that it had identified this issue during multiple incident response engagements over the past weeks, and lab-based testing has validated its concerns that a threat actor may be able to gain root-level persistence after a factory reset has been performed.
This is a major concern, and CISA is now advising security teams to assume that user and service account credentials stored within affected appliances are likely compromised, to hunt for malicious activity on their networks using the methods and IoCs in the updated advisory, and to apply patching guidance provided by Ivanti as version updates roll out.
Should compromise or potential compromise be detected, security teams should collect and analyse logs and artefacts for malicious activity, and apply the incident response recommendations within the advisory.
Should I be worried about, or stop using, Ivanti?
In response to the 29 February updates, Ivanti has stated that the persistence technique identified has not yet been observed in the wild. However, it has released a new enhancement to the external Integrity Checker Tool (ICT), providing additional visibility into customer appliances and all files present on the system. More information on this can be found here.
Given this situation, we cannot and do not state with confidence that the affected Ivanti products are safe to use. This is a decision that security teams should be prepared to have to make having followed all the current guidance.
Customers can certainly expect to see exploit attempts against them, now and in the future, which makes taking action even more important.
It is important to note that although Ivanti has committed to supporting its customers and communicating additional information to assist in incident response and investigation should a customer find evidence they have been compromised, it is not itself a provide of forensic cyber services and cannot fully investigate the issue on a customer’s behalf. Compromised customers should seek guidance and support from a forensic provider.
