The libssh Vulnerability: What’s at Risk & How SonicWall Helps Prevent It
The greatest thing about cybersecurity, at least when viewed from a practicing cybersecurity engineer, is the fact that it is a constantly changing landscape. And that is certainly the case with libssh.
For those who haven’t heard, a libssh exploit was identified last week, one that was ranked as critical by CVSS Severity and Metrics. This latest breach, CVE-2018-10933, allows attacks to compromise specific builds of libssh, essentially the code used for many open-source products that support SSH.
For those unfamiliar with SSH, well, let’s just say if you don’t use it, you likely don’t know what it is. But for those who do know it, they will immediately recognize the drastic and alarming nature of such a breach.
SSH, or Secure Shell, is a command line interface used to connect and administer various technology products. This includes servers, switches, routers and, yes, even firewall and security installations. That means that when this attack is leveraged it could grant unauthorized (literally) access directly to certain systems that control the very security of an organization, business, website and even government or healthcare networks.
What is … ‘Shush’?
Just to point out this significance of this breach, allow me to tell you a brief story. While conducting a security vulnerability assessment for an organization that manufactured products for a very niche market, I found that their network was transmitting more than 30GB of SSH traffic in the period of three days.
When I inquired as to why they were running this traffic, the CFO for the company in question pointedly asked me, “What is Shush?”
Let that sink in for a second. I know I had to, too.
Upon further investigation, I found that this traffic was all being sourced to a knock-off marketer’s network and the customer had potentially lost billions in market product sales. In short, SSH is a very powerful network communication protocol and should be highly regulated inside any network.
SonicWall Products Not Vulnerable to libssh
Not only are all SonicWall products immune to this latest breach, but we are also able to prevent against it.
SonicWall products do not leverage the affected code contained in the lilbssh breach. Even better, provided the SonicWall firewall is deployed using DPI-SSH configurations, we can detect when susceptible machines have been attacked and can prevent the breach before it happens.
Not only are all SonicWall products immune to this latest breach, but we are also able to prevent against it.
The SonicWall solution encompasses a complete end-to-end, real-time security system. That includes protection against zero-day discoveries such as this. The same day this particular breach was identified, SonicWall was already preventing it in any exposed SSH sessions — even if network admins had not taken to preventing those connections initially.
SonicWall DPI-SSH operates in a proxy-like manner. Because it does not mirror commands across the firewall, but rather initiates a regular connection on the other side of the firewall, SonicOS DPI-SSH is not susceptible to this attack. But it also effectively nullifies the attack because the DPI-SSH functionality itself cannot be vulnerable since there is no authentication to the “incoming” side of the proxy.
Additionally, DPI-SSH is primarily used in the LAN-to-WAN scenario for DLP monitoring, and the attack vector for this CVE is primarily WAN-to-LAN. DPI-SSH can, of course, protect LAN-initiated traffic by scanning SCP and SFTP protocols (encrypted traffic) for malware.
With the ever-evolving threat landscape, make sure that you have a security solution that can stay ahead of the breaches — not just react to new ones when they appear in the headlines. It is always easier to prevent the breach before it happens than figure out what to do after the fact.
