Norway recommends replacing SSL VPN to prevent breaches

The Norwegian National Cyber Security Centre (NCSC) recommends replacing SSLVPN/WebVPN solutions with alternatives due to the repeated exploitation of related vulnerabilities in edge network devices to breach corporate networks.

The organization recommends that the transition be completed by 2025, while organizations subject to the ‘Safety Act’ or those in critical infrastructure should adopt safer alternatives by the end of 2024.

NCSC’s official recommendation for users of Secure Socket Layer Virtual Private Network (SSL VPN/WebVPN) products is to switch to Internet Protocol Security (IPsec) with Internet Key Exchange (IKEv2).

SSL VPN and WebVPN provide secure remote access to a network over the internet using SSL/TLS protocols, securing the connection between the user’s device and the VPN server using an “encryption tunnel.”

IPsec with IKEv2 secures communications by encrypting and authenticating each packet using a set of periodically refreshed ke

“The severity of the vulnerabilities and the repeated exploitation of this type of vulnerability by actors means that the NCSC recommends replacing solutions for secure remote access that use SSL/TLS with more secure alternatives. NCSC recommends Internet Protocol Security (IPsec) with Internet Key Exchange (IKEv2),” reads the NCSC announcement.

While the cybersecurity organization admits IPsec with IKEv2 isn’t free of flaws, it believes switching to it would significantly reduce the attack surface for secure remote access incidents due to having reduced tolerance for configuration errors compared to SSLVPN.

The proposed implementation measures include:

• Reconfiguring existing VPN solutions or replacing them
• Migrating all users and systems to the new protocol
• Disabling SSLVPN functionality and blocking incoming TLS traffic
• Using certificate-based authentication

Where IPsec connections are not possible, the NCSC suggests using 5G broadband instead.

Meanwhile, NCSC has also shared interim measures for organizations whose VPN solutions do not offer the IPsec with IKEv2 option and need time to plan and execute the migration.

These include implementing centralized VPN activity logging, strict geofencing restrictions, and blocking access from VPN providers, Tor exit nodes, and VPS providers.

Other countries have also recommended using IPsec over other protocols, including the USA and the UK.

An abundance of exploited SSLVPN flaws

Unlike IPsec, which is an open standard that most companies follow, SSLVPN does not have a standard, causing network device manufacturers to create their own implementation of the protocol.

However, this has led to numerous bugs discovered over the years in SSL VPN implementations from Cisco, Fortinet, and SonicWall that hackers actively exploit to breach networks.

As an example, Fortinet revealed in February that the Chinese Volt Typhoon hacking group exploited two FortiOS SSL VPN flaws to breach organizations, including a Dutch military network.

In 2023, the Akira and LockBit ransomware operations exploited an SSL VPN zero-day in Cisco ASA routers to breach corporate networks, steal data, and encrypt devices.

Earlier that year a Fortigate SSL VPN vulnerability was exploited as a zero-day against government, manufacturing, and critical infrastructure.

NCSC’s recommendations come after the organization recently alerted about an advanced threat actor exploiting multiple zero-day vulnerabilities in Cisco ASA VPNs used in critical infrastructure since November 2023.

Cisco disclosed the particular campaign as ‘ArcaneDoor,’ attributing it to the threat group tracked as ‘UAT4356’ or ‘STORM-1849,’ who gained unauthorized access to WebVPN sessions associated with the device’s SSL VPN services.

The attacks involved the exploitation of two zero-days, namely CVE-2024-20353 and CVE-2024-20359, which enabled the hackers to achieve authentication bypass, device takeover, and privilege elevation to administrative rights.

Although Cisco fixed the two vulnerabilities on April 24, the cybersecurity and networking equipment firm couldn’t identify how the threat actors initially gained access to the device.