On October 17th, Peter Winter-Smith of NCC Group disclosed a vulnerability in a popular implementation of SSH protocol – libssh.
Background
The vulnerability originated from a specific implementation of an authentication state machine, that is shared between the client and the server, and allows maliciously-implemented clients to bypass the required authentication process and create remote connections to vulnerable servers.
To understand the potential impact of this vulnerability we mention just a few of the popular operating systems and products that could be affected:
The original notification from NCC Group states that the vulnerability was reported to libssh owners on June 25th.It took almost 3 months to develop a fix which was completed on September 18th. It took another month to distribute it on October 17th. That’s right, for almost 4 months an extremely dangerous security vulnerability was known but remained unaddressed by the library owners. They have only now released the product updates with the fixed library version.
A simple query on Shodan.io, the search engine for internet-connected devices, shows roughly 3,000 servers are exposed directly to Internet and are therefore highly vulnerable. Thousands more are deployed inside corporate networks and could be exploited by malicious endpoints that would gain access either by connecting directly to LANs or by using VPN connections.
How Luminate makes a difference
The Luminate Secure Access Cloud ™ approach completely eliminates network-based access to any corporate IT assets. In the case of SSH Servers, we would never provide direct access from any client application to a TCP Port on which an SSH Server is listening inside the corporate network.
Instead, we terminate the original SSH Connection within our cloud (that is not implemented on top of libssh), then we completely replace the traditional authentication and authorization piece with our own strongly-separated auth, built on corporate Identity Providers from the users’ side, using unique ephemeral certificates on the datacenter side. We then establish a separate SSH Connection inside the datacenter. This is allowed only between trusted parties.
Luminate Secure Access Cloud ™ never allows an end-to-end SSH Connection directly into the datacenter. This is how it categorically protects your assets from issues related to unprotected end user access. More than that, it guarantees that even in the case of legitimate credentials that have been compromised, the separate auth mechanism drastically reduces, if not completely eliminates, the possibility of affecting your infrastructure.
Be it an on-premises datacenter or an IaaS-based one, such as Amazon Web Services, Microsoft Azure, Google Cloud Platform or any other, no other secure access approach (Software-Defined Perimeter with Single Packet Auth, Cloud Micro-VPN with Firewall as a Service, Dynamic ABAC based on SSH Auth) would be able to prevent this vulnerability.
Summary
- Luminate Secure Access Cloud™ is not affected by the recent libssh vulnerability
- The design of authentication and authorization in Luminate Secure Access Cloud™ categorically prevents such vulnerabilities from ever being exploited
- Our network isolation methodology categorically protects customers’ SSH Servers from such attacks
- Being based on the Zero Trust concept is not enough; other Zero Trust and Software-Defined Perimeter approaches are not protected from such vulnerabilities
- Being provided as-a service, Luminate Secure Access Cloud™ can be deployed in minutes and immediately start protecting thousands of corporate resources. The easy deployment eliminates the tedious process of patching one device at a time, saves hundreds of manhours and avoids downtime.