[BreachExchange] New libssh Vulnerability – No Logo But Plenty Of Attention

[Destry Winant]

https://www.riskbasedsecurity.com/2018/10/new-libssh-vulnerability-no-logo-but-plenty-of-attention/?utm_campaign


Earlier this week, Andreas Schneider announced
<https://twitter.com/cryptomilk/status/1052167833231220736> the release of
a new version of libssh <https://www.libssh.org/>, covering “*an important
security*
<https://www.libssh.org/2018/10/16/libssh-0-8-4-and-0-7-6-security-and-bugfix-release/>”
that addressed “*an authentication bypass vulnerability in the server code*”.
Pretty quickly we saw several
<https://arstechnica.com/information-technology/2018/10/bug-in-libssh-makes-it-amazingly-easy-for-hackers-to-gain-root-access/>
 news
<https://www.zdnet.com/article/security-flaw-in-libssh-leaves-thousands-of-servers-at-risk-of-hijacking/>
 articles
<https://thehackernews.com/2018/10/libssh-ssh-protocol-library.html> published
that covered this issue, as well as third-party blogs that added commentary
<https://www.digitalmunition.me/2018/10/thousands-servers-easy-hack-due-libssh-flaw/>
on
the technical side
<https://www.leapsecurity.io/blog/cve-2018-10933-libssh-authentication-bypass-tool/>
of
the vulnerability. Since we were following the issue closely, we wanted to
share some of the meta-information we tracked as well as commentary from
the ‘social side’ of this disclosure.

First, a few basics and quick recap. This appears to be the first libssh
vulnerability disclosed in 2018. Last year there were at least two
vulnerabilities disclosed in libssh2 <https://www.libssh2.org/>, a
different project. Prior to that, in February 2016, a vulnerability was
disclosed that impacted both libssh
<https://cve.mitre.org/cgi-bin/cvename.cgi?name=2016-0739> and libssh2
<https://cve.mitre.org/cgi-bin/cvename.cgi?name=2016-0787> likely due to
common code. For this new vulnerability, there has been immediate
speculation <https://twitter.com/kozmic/status/1052298554801315840> on how
bad this vulnerability is considering Github and others might be using the
code, with Github providing a quick response
<https://twitter.com/GitHubSecurity/status/1052317333379723265> addressing
the concerns. While there is a CVE assigned
<https://www.libssh.org/security/advisories/CVE-2018-10933.txt> for this
vulnerability, it lacks a lot of references that give great additional
information as far as the technical details and products impacted. Others
are wondering <https://twitter.com/vandergoog/status/1052264786480824320> why
an issue this serious didn’t earn a CERT advisory, or since so many believe
it is a critical issue, at least a CERT-VU. As expected, regardless of the
potential severity we are seeing some people getting fed up
<https://twitter.com/simplenomad/status/1052900014350061573> with
sensational headlines around vulnerabilities trying to scare consumers to
get those ad revenue generating clicks.

How prevalent is libssh? According to their homepage, it is used in KDE,
GitHub, and X2GO. Additionally, we know that most of the Linux
distributions use it, including Debian Linux, Red Hat Enterprise Linux,
Ubuntu, SUSE, and openSUSE. Further, Puppet Enterprise, F5 BIG-IP, and F5
BIG-IP AFM also include it in their products. Based on a cursory look at
VulnDB <https://vulndb.cyberriskanalytics.com/> entries for libssh and
libssh2, it appears that more companies adopt libssh2, including IBM,
Xerox, Oracle, and Symantec. As vendors take time to process the libssh
vulnerability, we will start to see their own advisories on the issue, such
as from F5 <https://support.f5.com/csp/article/K52868493> confirming that
some of their Big-IP Advanced Firewall Manager products are vulnerable and
could allow unauthorized logins.
Authentication Bypass Vulns Everywhere!

Steve Christey Coley, who worked on the CVE project for 17 years, points out
<https://twitter.com/SushiDude/status/1053041349115699200> that people are
quick to make fun of “*easy auth bugs*” because “*yes, some are simple*”.
He also points out there is “*very little research in detection &
prevention for these kinds of logic/control/state-machine flaws vs buffer
overflows, injection, etc.*” in the thread by citing a trivial remote
authentication bypass vulnerability that impacted AIX, IRIX, and Slackware
Linux from 1994. He makes a great point. This type of vulnerability should
be just as easy to find by researchers as any other, given the time that
has passed and the tools readily available today. But as we have learned,
this libssh issue is over four years old
<https://reviewedbypro.com/4-year-old-libssh-vulnerability-allows-attackers-to-take-over-servers/>
and
just now being found and disclosed.

Dominic White shared <https://twitter.com/singe/status/1052660546632339461> “a
brief and incomplete history of embarrassing auth bypass bugs:”

It’s clear that some researchers are now focused on finding more of these
types of issues though. Twitter user Aris Adamantiadis points out
<https://twitter.com/aris_ada/status/1052855214439579648> the “*exact same
bug was found in paramiko a month ago*” and that it is an “*interesting
pattern*”. It’s true that the particular Paramiko vulnerability
<https://github.com/paramiko/paramiko/issues/1283> he references is eerily
similar to the new libssh issue. In fact, a quick skim of VulnDB
vulnerability titles reveals remote authentication bypass vulnerabilities
in Juniper Junos, Responsive FileManager, Cisco Digital Network
Architecture, Cisco HyperFlex System, Cisco IOS XE, IBM Rational
Engineering Lifecycle Manager, Neo4J Server, and Symantec Messaging
Gateway. All of these vulnerabilities disclosed *in the past month*!
Doom & Gloom?

When a vulnerability is disclosed that potentially impacts a lot of
organizations, or it is trivial to exploit, we tend to see a wide variety
of headlines and commentary about how the issue is critical. Does this new
libssh disclosure warrant the “doom & gloom” type of Tweets
<https://twitter.com/unix_root/status/1052543544798400515> and headlines
<https://arstechnica.com/information-technology/2018/10/bug-in-libssh-makes-it-amazingly-easy-for-hackers-to-gain-root-access/>
that
suggest a vulnerability *is really bad* without disclosing additional
details that may mitigate the concern? For example, in response to the
libssh vulnearbility, GitHub confirmed that while they do use the libssh
code, they are not vulnerable due to how they use the code. In a further
statement, Github shared additional information that stated they are
actually using a custom version of libssh.

This example stresses that it is important to understand how a third-party
library is integrated into a product, if it has been customized, and even
if a vulnerability can ultimately even be triggered. Github has provided a
clear example as to why some vendors will release advisories on such issues
that ultimately say “*we are not vulnerable*”.

Twitter user Bob Rudis cites Project Sonar Scan data
<https://twitter.com/hrbrmstr/status/1052318521236094976> that suggests
there are around 5,500 Internet-facing vulnerable libssh nodes, saying that
amount “*isn’t too bad*”, but then immediately concludes they are *“all
vulnerable to the auth bypass issue, so consider them pwnd”*. Twitter user Rob
Graham points out
<https://twitter.com/ErrataRob/status/1052340891812286465> that
“*while SSH is used everywhere, libssh is not so common*” and that “*it’s
usually client-side*”. The important point here is that this new libssh
issue affects server side implementations only.

Ultimately, over the coming months we suspect that we will see additional
vendors address this issue in advisories or release notes as they determine
if they are impacted. Until then, use common security practices like
network segregation, ACLs, and internal auditing to test if a system is
vulnerable <https://seclists.org/oss-sec/2018/q4/65> manually or try using
a newly-published scanner. <https://github.com/leapsecurity/libssh-scanner>
The Anthropomorphization Of A Vulnerability

Most commonly associated with human behavior toward animals or material
objects, to anthropomorphize, or to “*ascribe human form or attributes to
(an animal, plant, material object, etc.)*” [Dictionary.com
<https://www.dictionary.com/browse/anthropomorphization>] can apply to
computer activity. Perhaps one of the best known examples of this is an
interaction captured in a single panel XKCD cartoon:

With the disclosure of the libssh issue, one of the curious trends that
caught our eye was the same type of anthropomorphization of this
vulnerability happened quite a bit, almost all in the same manner. There is
clear value in doing this in many cases, as it can sometimes better explain
the simplicity of the exploit to a non-technical crowd. But as we all know,
we must also be careful when over-simplifying and using analogies that are
too far-reaching as they could lead to misinterpretation.

The common theme in the libssh tweets can be seen in Tweets from
@dev_console <https://twitter.com/dev_console/status/1052382039008337920>,
@0xAmit <https://twitter.com/0xAmit/status/1052249983666319361>, and
@sphinxgaiaone
<https://twitter.com/sphinxgaiaone/status/1052803367871938560>, but our
favorite came from @DAkacki
<https://twitter.com/DAkacki/status/1052763321806585856>:

This takes a fairly simple vulnerability, in concept, and converts it to a
human interaction to explain it. As you can see from the Likes and
Retweets, it has received positive attention. This shows that this approach
can be an effective way to help explain the issues while also underscoring
the severity of an issue, or at least, the exploitation of it. However,
most anthropomorphisms that we have seen thus far don’t attempt to speak to
the actual impact by addressing how many servers are actually vulnerable or
if there are mitigating circumstances among other things.
What’s Next?

This new libssh vulnerability didn’t get a name or a fancy logo, but it
sure did receive media attention as if it had. It also was the focus of
quite a few blog posts and several articles that made it appear that this
vulnerability was going to cause substantial impact to organizations, and
at first, incorrectly, to all Github users. While this particular libssh
vulnerability has also been rated a base CVSS score of 10, there is still
debate in the security community as to whether this bug has been overhyped
or not. Regardless, if you are running the server side implementation of
libssh we recommend that you do your own analysis to see if the
vulnerability can be triggered and update accordingly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20181022/358c6157/attachment.html>