Bug 45378 - vulnerable to man-in-the-middle (MitM) attacks due to missing SSH host key validation
vulnerable to man-in-the-middle (MitM) attacks due to missing SSH host key va...
Status: NEW
Product: UCS
Classification: Unclassified
Component: SSH
UCS 4.4
All Linux
: P5 major with 7 votes (vote)
: ---
Assigned To: UCS maintainers
UCS maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-09-11 09:20 CEST by Philipp Hahn
Modified: 2021-04-14 10:47 CEST (History)
5 users (show)

See Also:
What kind of report is it?: Security Issue
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score: 6.8 (CVSS:3.0/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Philipp Hahn univentionstaff 2017-09-11 09:20:35 CEST
For SSL UCS provides its own certificate hierarchy rooted at the UCS Master, but there is no verification for SSH host keys, which makes UCS vulnerable to MitM attacks.
1. Every host should store its host keys in its LDAP host entry.
2. A listener module could fetch all those entries and write them to /etc/ssh/ssh_known_hosts
3. Optionally they should be stores as DNS-SSHFP entries (RFC 4155), too and "ssh -o VerifyHostKeyDNS=yes" could be configures as default. (DNSSEC would be good, too)
Comment 1 Philipp Hahn univentionstaff 2018-04-24 17:04:50 CEST
Here is my WIP implementation:
<https://git.knut.univention.de/univention/ucs/tree/phahn/4.3-0+45378ssh-host-keys>
needs to be rebased to merge fixup entries before being applied to upstream.

Done:
- LDAP schema extension for hosts
- LDAP schema update for DNS entries
- upload SSH to LDAP
- Listener module to manage /etc/ssh/ssh_known_hosts
- New UDM dns/sshfp module do manage stand-alone DNS RRs
- Updated UDM dns/host module to also manage SSHFPs.

TODO:
- Extend UDM computers/* modules to show uploaded keys
- Get all names of computer and register ssh keys for them, too.
- Convert host keys to DNS fingerprint entries
- Extend S4C to synchronize sshfp RRs between OpenLDAP and Samba4
Comment 2 Florian Best univentionstaff 2019-03-14 21:41:58 CET
Can you set a CVE score?
Comment 3 Arvid Requate univentionstaff 2019-04-10 18:27:27 CEST
FYI: The Samba dlz_bind9 module currently doesn't support the SSHFP RR TYPE, probably because the MS-DNSP specs don't define it as SHOULD:

* https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dnsp/39b03b89-2264-4063-8198-d62f62a6441a

Probably it is easy to implement that though and according to https://serverfault.com/questions/675413/sshfp-records-on-windows-dns-server it could also work in way that is compatible with AD. We should check the binary representation in the dnsRecord attribute though to assure that this is ABI compatible to what an MS DNS server would write to AD.

In the first iteration I guess we could just start with the ssh_known_hosts listener approach.

Then there is also the related question of interactive verification of the ssh key of the master during initial join. To keep changes in a managable size and becasue that might involve changes to the setup wourkflow, I would suggest splitting that off for a later stage.
Comment 4 Florian Best univentionstaff 2019-05-14 17:28:33 CEST
In the test/QA phase we should check what happens after a backup2master.
Comment 5 Arvid Requate univentionstaff 2019-06-03 15:54:29 CEST
As a first step to reduce the attack surface for MitM, we could change StrictHostKeyChecking=no to StrictHostKeyChecking=accept-new.


man ssh_config: "If this flag is set to “accept-new” then ssh will automatically add new host keys to the user known hosts files, but will not permit connections to hosts with changed host keys."

e.g. https://github.com/NixOS/nixops/pull/1023
Comment 6 Sönke Schwardt-Krummrich univentionstaff 2019-06-04 10:32:52 CEST
(In reply to Arvid Requate from comment #5)
> As a first step to reduce the attack surface for MitM, we could change
> StrictHostKeyChecking=no to StrictHostKeyChecking=accept-new.

In this step, we should also check how UCS reacts, if e.g. a slave has been reinstalled (→ new host key).
Comment 7 Ingo Steuwer univentionstaff 2020-04-17 14:56:28 CEST
These tools are used for communication between UCS instances, which share a private network (either routing or VPN is under the same control as the instances).

My understand is that the "Attack Vector" in terms of CSS is "Adjacent" here.
Comment 8 Philipp Hahn univentionstaff 2021-04-14 10:47:01 CEST
Similar to our SSL setup in UCS we should also "SSH Host Key Signing": Similar to SSL SSH should gets its host keys signed when the the system joins the domain. This allows you to distribute only the "SSH CA signing public key" to each host instead of updating the list each time a new host is added or an old host is removed.

It still helps external users to also have the SSH keys published as DNS SSHFP RR.


(In reply to Sönke Schwardt-Krummrich from comment #6)
> (In reply to Arvid Requate from comment #5)
> > As a first step to reduce the attack surface for MitM, we could change
> > StrictHostKeyChecking=no to StrictHostKeyChecking=accept-new.
> 
> In this step, we should also check how UCS reacts, if e.g. a slave has been
> reinstalled (→ new host key).

Access would be denied until the old key is removed manually with `ssh-keygen -R $hostname`. Using it only simplifies the initial connection, which is the most critical: You should really make sure to join with the READ Primary node, not some rouge server.
But it would protect all later connections, which is a win.


(In reply to Ingo Steuwer from comment #7)
> These tools are used for communication between UCS instances, which share a
> private network (either routing or VPN is under the same control as the
> instances).
> 
> My understand is that the "Attack Vector" in terms of CSS is "Adjacent" here.

<https://www.google.de/search?q=allinurl%3A%22%2Funivention%2Fmanagement%2F%22> find enough public UCS servers available on the Internet, so NOT "adjacent".