CVE-2018-10933 (libssh) does it affect you?
One of our engineering practice leads (those responsible for ensuring that all of our projects are aligned, and all “singing from the same book of hymns”) sent this out this afternoon:
Hi All, Please feel free to share this with clients. A new exploit that is in the news impacts certain versions of libssh. The good news is that this vulnerability doesn't impact the following tools: - openssh (OpenSSH is a completely separate implementation to libssh – they don’t include or rely on each other’s code) - Dropbear (a stripped down version commonly used on routers and other IoT devices) - libssh2 (it’s a different product to libssh, not merely a newer version) - PuTTY (widely used on Windows). Advisory : Authentication bypass in server code https://www.libssh.org/security/advisories/CVE-2018-10933.txt Proof of concept https://www.openwall.com/lists/oss-security/2018/10/17/5 NOTE! Don't try the POC Code against client systems. The signature from publicly available Code can be integrated with detection tools (SIEM, IPS, IDS etc.) as Indicators of Attack/Compromise. i.e. you will set off all the alarms.... Known Usage: - KDE uses libssh for the sftp file transfers - GitHub implemented their git ssh server with libssh - X2Go is a Remote Desktop solution for Linux - csync a bidirectional file synchronizer - Remmina the GTK+/Gnome Remote Desktop Client - XMBC a media player and entertainment hub for digital media - GNU Gatekeeper a full featured H.323 gatekeeper (from https://nakedsecurity.sophos.com/2018/10/17/serious-ssh-bug-lets-crooks-log-in-just-by-asking-nicely/) Mitigation - Don't leave port 22 open to the world. If you must have port 22 open, specify IP addresses, use an VPN to get a static ip (IW have a VPN). - GitHub project [a] doesn’t actually call the buggy code in the libssh product and [b] has installed the patch anyway. - cURL uses libssh2 as its first choice if you need SSH support. What to do? If you have any software product that includes or uses libssh, download and install the latest libssh version at once. If you use product that has libssh built in, rather than supplied as a shared library or DLL, you will need an updated version of the app itself. Regards, Steven Harper Engineering Practice Lead
We were notified of this vulnerability this morning by one of our consultants in London (I’m based in our Leeds office) on our engineering community of practice channel where engineers get together to talk about all things engineering.
First things first then, it’s research time, starting with my standard source for CVE’s (cvedetails.com) we can see that the information at this time is pretty sparse. This is often the case with brand new CVE’s, it takes a few days for engineers from potentially affected businesses to become aware of the vulnerability, and then test their software to see if they are vulnerable.
I had a small moment of employment-history-pedigree pride, when I noticed that on the advisory from libssh.org, that the sec tester that discovered the vulnerability, works for my ex-employer NCC Group 👊.
Digging a little deeper into this vulnerability, shows that understanding the total scope of how vulnerable most systems will be is not going to be overly simple.. You can perform a quick search on Shodan and see that there are more than 3000 devices on the public internet that “appear” to be vulnerable to this vulnerability, but this bug while serious, is not so easy to determine as “are they using libssh”. As Steven called out in his email above, for all cases in the “Known Usage” section of the libssh website, at least Github in that list isn’t vulnerable, just because of how they use the library. Also, there is a competing library called “libssh2” that is not vulnerable, causing some minor upset in at least one client, with an engineer reading documentation a little too fast and mistaking libssl2 for libssl.
The main take away from this and other recent vulnerabilities is that a single layer of defence, can easily become no layers of defense with “one simple change”. Defense in depth should always be preferred, and hopefully with mitigations like IP restriction, and limited edge points to your infrastructure, your attack surface can be minimal even if you are vulnerable.
In all cases though, much like all good doctors, I recommend protection & regular testing. At the time of writing, Tenable have already developed a set of plugins to scan for this vulnerability and the other scanning engines will very soon release their own tooling.