security [UPDATE: Cisco Statement] Passwords Please - SSH vulnerability allows hackers to access any device by asking nicely

[rcmaehl]

Update:
Cisco Statement
 

Quote

Affected Products
Cisco is investigating its product line to determine which products may be affected by this vulnerability.
 

Products Under Investigation
The following products are under active investigation to determine whether they are affected by the vulnerability that is described in this advisory:

• Collaboration and Social Media
  • Cisco Webex Meetings Server
• Endpoint Clients and Client Software
  • Cisco Jabber Guest
• Network Application, Service, and Acceleration
  • Cisco Adaptive Security Appliance (ASA) Software
  • Cisco Cloud Services Platform 2100
• Network and Content Security Devices
  • Cisco ASA Next-Generation Firewall Services
  • Cisco Email Security Appliance (ESA)
  • Cisco FireSIGHT System
  • Cisco Identity Services Engine (ISE)
• Network Management and Provisioning
  • Cisco Elastic Services Controller (ESC)
  • Cisco Enterprise Service Automation
  • Cisco NetFlow Generation Appliance
  • Cisco Network Analysis Module
  • Cisco Policy Suite
  • Cisco Prime Access Registrar
  • Cisco Prime Collaboration Provisioning
  • Cisco Prime Infrastructure
  • Cisco Prime Network Registrar Virtual Appliance
  • Cisco Prime Network Registrar
  • Cisco Prime Performance Manager
  • Cisco WAN Automation Engine (WAE)
• Routing and Switching - Enterprise and Service Provider
  • Cisco Application Policy Infrastructure Controller (APIC)
  • Cisco IOS XR Software for Cisco Network Convergence System 6000 Series Routers
  • Cisco IOS XR Software
  • Cisco Nexus 9000 Series Switches - Standalone, NX-OS mode
  • Cisco Nexus 9000 Series Switches
• Unified Computing
  • Cisco UCS Director
• Voice and Unified Communications Devices
  • Cisco IP Interoperability and Collaboration System (IPICS)
  • Cisco Management Heartbeat Server
  • Cisco Unified Communications Manager Session Management Edition
  • Cisco Unified Communications Manager
  • Cisco Unified Contact Center Express
• Video, Streaming, TelePresence, and Transcoding Devices
  • Cisco Cloud Object Storage
  • Cisco DCM Series D990x Digital Content Manager
  • Cisco Video Distribution Suite for Internet Streaming (VDS-IS/CDS-IS)
  • Cisco Video Surveillance 4300E and 4500E High-Definition IP Cameras
  • Cisco Video Surveillance Media Server
• Wireless
  • Cisco Wireless LAN Controller
  • Cisco Cloud Hosted Services
  • Cisco Smart Software Manager Satellite
  • Cisco Virtual HetNet

Vulnerable Products
Cisco is investigating its product line to determine which products may be affected by this vulnerability. This section will be updated as information is available.

Products Confirmed Not Vulnerable
Cisco is investigating its product line to determine which products may be affected by this vulnerability. This section will be updated as information is available.

Sources:
libssh

Sophos

 

TL;DR:

By initializing a connection using SSH2_MSG_USERAUTH_SUCCESS instead of SSH2_MSG_USERAUTH_REQUEST, an attacker can bypass SSH authentication.

 

Media:

 

Quotes/Excerpts:

Quote

CVE-2018-10933. A very serious flaw. It theoretically allows anyone to log into a server protected with libssh without entering a password. SSH is probably the most widely deployed remote access protocol in the world. Security holes in SSH are...the stuff of nightmares for many sysadmins. Here’s the good news. The most commonly used SSH version...is...OpenSSH. A completely separate implementation to libssh. Other...implementations... Dropbear, libssh2, and PuTTY...[don't] have this bug either. The bad news is that any server that is listening out for incoming SSH connections using libssh is at considerable risk of unauthorised access. The bug is comically bad, and in very simple terms it goes like this. When logging in, the client is supposed to chat to the server along these lines…
 

   Client → Server: HELLO-I-WOULD-LIKE-TO-START-AUTHENTICATING

   Client and server: [...a careful cryptographic dance is done by 
                          both sides to verify login credentials...]

   Server → Client: WELCOME-YOU-HAVE-PASSED-THE-TEST

But the bug means a client can just talk to a libssh server like this…

   Client → Server: WELCOME-YOU-HAVE-PASSED-THE-TEST

No password requested or required.

 

My Thoughts:

While libssh isn't the most common SSH library, it is among the top. How comically bad this bug is means libssh should probably have an audit of it's security practices. Let's hope not too many IoT devices use this library or we may have another Mirai botnet on our hands.

[RollTime]

EternalBlue 2.0 when?

[Syntaxvgm]

HAHAHAHAHAHA

 

 

oh wait im running libssh oh fuck 

[givingtnt]

Oh shit

[jasonvp]

I honestly wonder if this is still an issue with password authentication disabled?  Whenever I install a new system, the very first thing I do with SSH is disable password auth.  Don't have a key?  You ain't gettin' in.  No ifs, no ands, no buts.  With that disabled, I wonder if the SSH server is still susceptible?

 

ETA: and yes, I know I'm not using libssh.  More a curiosity.

[8uhbbhu8]

Oh boy. Now what version are many routers and switches using... We may be seeing a lot of emergency iOS patches for them lol

[mynameisjuan]

Wow....how the fuck is it that simple. How was this missed

[Windows7ge]

Even if you're using public/private key authentication? I wouldn't be surprised if password only is easily bypassed but I'd expect keys to be trickier.

[rcmaehl]

3 minutes ago, Windows7ge said:

Even if you're using public/private key authentication? I wouldn't be surprised if password only is easily bypassed but I'd expect keys to be trickier.

Technical details haven't been released but it's safe to assume if Key Auth uses the same function call then it'd be at risk. I'm going to have to read up on SSH auth processes

[WereCatf]

Eh, for us home-users -- even power-users -- this luckily doesn't really mean much.

[Windows7ge]

1 minute ago, rcmaehl said:

Technical details haven't been released but it's safe to assume if Key Auth uses the same function call then it'd be at risk. I'm going to have to read up on SSH auth processes

How might we check what library we're using? I'm not that Linux savvy.

[mynameisjuan]

2 minutes ago, WereCatf said:

Eh, for us home-users -- even power-users -- this luckily doesn't really mean much.

Until you realize how many devices have SSH open by default, mainly routers which are the main concern.

[WereCatf]

1 minute ago, Windows7ge said:

How might we check what library we're using? I'm not that Linux savvy.

Most things, like the article mentions, too, don't use libssh, they use OpenSSH. Also, Ubuntu, at least, has already released a patch for this, and most likely all other major distros have or will in the next couple of days, too.

[Helibert]

1 minute ago, Windows7ge said:

How might we check what library we're using? I'm not that Linux savvy.

just do a

 

ssh -v localhost

 

[mynameisjuan]

2 minutes ago, Windows7ge said:

How might we check what library we're using? I'm not that Linux savvy.

find /lib* /usr/lib* -name '*libssh*'

[WereCatf]

4 minutes ago, mynameisjuan said:

Until you realize how many devices have SSH open by default, mainly routers which are the main concern.

They generally use dropbear or OpenSSH, not libssh.

[mynameisjuan]

3 minutes ago, WereCatf said:

They generally use dropbear or wolfssl, not libssh.

Most router OSes are based on BSD which uses openssh. Yes they exist and yes this is a legitimate issue until more details are released. 

[WereCatf]

Just now, mynameisjuan said:

Most router OSes are based on BSD which uses openssh. Yes they exist and yes this is a legitimate issue.

OpenSSH is not vulnerable so no, this is mostly a non-issue for home-users.

[Windows7ge]

2 minutes ago, Helibert said:

just do a

 

ssh -v localhost

 

I will have to try that when I get home. I actually recently had to create new keys on my server and I only distributed the new private key to my desktop. Still have to do it with every other machine I use like the laptop I'm on right now.

 

5 minutes ago, mynameisjuan said:

find /lib* /usr/lib* -name '*libssh*'

Hello again, but that sounds like it'd just tell me if I have it. Not if I'm actually using it.

[mynameisjuan]

3 minutes ago, WereCatf said:

OpenSSH is not vulnerable so no, this is mostly a non-issue for home-users.

Just did a quick google. I didnt realize openssh does not use libssh as a dependency and they are separate. Interesting. Well that sure shoots down the amount of equipment affected. 

[mynameisjuan]

2 minutes ago, Windows7ge said:

Hello again, but that sounds like it'd just tell me if I have it. Not if I'm actually using it.

If you want to see if its running I usually use 

ps -o pid,sess,cmd afx | egrep "ssh"

 

It not only shows whats running but what is using it. 

[Windows7ge]

2 minutes ago, mynameisjuan said:

If you want to see if its running I usually use 

ps -o pid,sess,cmd afx | egrep "ssh"

 

It not only shows whats running but what is using it. 

I will try both then and see what shows up.

Our router is already a pos (to be replaced soon) and I don't trust it, but I'd like my current & future server to have some level of reliable security when remoting in.

[jasonvp]

These are the lines I always add to my /etc/ssh/ssd_config file:

 

PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no

 

You can't come in as root, and if you don't have a key, you're not getting in.
 

[WereCatf]

1 hour ago, jasonvp said:

These are the lines I always add to my /etc/ssh/ssd_config file:

 

PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no

 

You can't come in as root, and if you don't have a key, you're not getting in.
 

Irrelevant to the discussion as those are OpenSSH-configuration options, and those options wouldn't protect you anyways, if OpenSSH was vulnerable, because the bug bypasses all that.

[jasonvp]

26 minutes ago, WereCatf said:

Irrelevant to the discussion as those are OpenSSH-configuration options, and those options wouldn't protect you anyways, if OpenSSH was vulnerable, because the bug bypasses all that.

Yes, I know it's OpenSSH (been doing this for a while, thanks).  I was just giving an example.  And no, we're not certain that the "bug bypasses all of that."