#1511 Issue `closed`: Security Vulnerability (Privilege Escalation): SSH private user key disclosure for root account¶

Labels: fixed / solved / done, critical / security / legal

OliverO2 opened issue at 2017-09-22 19:10:¶

Relax-and-Recover 2.2 (ReaR) copies SSH private user keys from /root/.ssh to the rescue medium. These keys authenticate SSH access to accounts on networked hosts without requiring a login password.

On the original system, the private keys are only accessible with root user privileges. They can be encrypted with a passphrase, but often are not to allow outgoing SSH connections for unattended backup operations.

The ReaR rescue medium, which may be a DVD or a USB stick, grants complete unauthenticated access to all files, including copied private key files. Unless changed by some action outside of ReaR, these private keys remain valid for the original system, during recovery and on the restored system.

Attack Vector¶

An attacker with physical access to the rescue medium can steal the private user keys for the root account.

If the attacker obtains network access, he can then access other accounts on the network authorizing the compromised root account via their authorized_keys files.

The vulnerability can be mitigated by encrypting the root user's private keys if the passphrase and the encryption method used can withstand an offline attack.

Consequences¶

A successful attack allows an attacker to gain privileges on network hosts and read and alter sensitive information.

OliverO2 commented at 2017-09-23 14:08:¶

Suggestions for ReaR Users and Developers¶

See https://github.com/rear/rear/issues/1512#issuecomment-331638066

jsmeix commented at 2017-09-25 07:18:¶

We (i.e the ReaR upstream authors and maintainers)
need to get this security issue fixed before the ReaR 2.3 release.

jsmeix commented at 2017-09-25 07:35:¶

Regarding
https://github.com/rear/rear/pull/1513#issue-260096327

This change improves the security of ReaR
but constitutes a breaking in change.
I find improving the security a good reason
for breaking changes, we just have to
explain it in the release notes.

I cannot agree more.

In general regarding security issues:
I think when there is a real security issue for ReaR
it means the issue must be by default exploitable.
A possible security issue that requires that the user has
explicity specified something insecure is not a real
security issue for ReaR because ReaR is a full
(bare-metal) system installer where the user can
and must be able do anything as he needs.
When there is a real security issue for ReaR, then
any fix will be a backward incompatible change
because we must change the by default insecure
behaviour into a secure one.

gdha commented at 2017-09-25 11:47:¶

@gozora @schlomo @jsmeix As Vlad mentioned ISO's should be kept safe all the time. That brings back memories from the past - see http://mkcdrec.cvs.sourceforge.net/viewvc/mkcdrec/mkcdrec/mediacheck/README - an ISO mediacheck - will not guarantee nobody can tamper with the ISO image, but it will give you at least a stamp of the time it was created (nothing more nothing less).

schlomo commented at 2017-09-25 12:56:¶

I asked the rear-users mailing list: http://lists.relax-and-recover.org/pipermail/rear-users/2017-September/003474.html

OliverO2 commented at 2017-09-25 18:19:¶

I see two aspects here:

Secure recovery (media integrity). This could be addressed by digitally signing rescue media during creation and offering the user to verify the signature when attempting recovery.
Protection against credentials theft.

@gozora @gdha When you advocate keeping rescue media safe at all times:

How would you protect against credentials theft with rescue media in less-guarded environments like home offices or branch offices? Think about burglary or less security-aware office people having access to such media.

How would you protect against credentials theft in data centers where personnel lacking top-level security clearance would be involved in media handling? (On the original system you'd need root privileges before using the private keys.)

gozora commented at 2017-09-25 18:53:¶

I'm somehow confused, on one hand you are using unencrypted keys to access servers and one the other hand advocating for high security.
IMHO security must start from bottom and be kept on all levels, starting with physical access through people and ending on SW layer. What you are trying is just to somehow patch weak spots ..
Sad true is that systems will never be 100% secure.

To answer your question

How would you protect against credentials theft with rescue media in less-guarded environments like home offices or branch offices? Think about burglary or less security-aware office people having access to such media.

You could try this (or similar): http://www.lok-it.co.uk/secure-usb-bootable-drive

V.

OliverO2 commented at 2017-09-25 19:15:¶

Sorry for the confusion. What's wrong with using unencrypted keys stored on a secure (encrypted) medium?

gozora commented at 2017-09-25 19:17:¶

Are you not worried that once one system get compromised, attacker will gain access to all other servers as well?

OliverO2 commented at 2017-09-25 19:19:¶

Absolutely. It all depends on the entire network being securely set up. I am aware of that and always try to find a reasonable trade-off between security and usability.

After all, the most secure system is the one that cannot be used at all.

OliverO2 commented at 2017-09-25 19:28:¶

And one extra note: Access is always granted with the least privilege required.

gozora commented at 2017-09-25 19:30:¶

And one extra note: Access is always granted with the least privilege required.

Now I'm confused again :-(

OliverO2 commented at 2017-09-25 19:36:¶

Why? What's wrong with this: https://en.wikipedia.org/wiki/Principle_of_least_privilege?

gozora commented at 2017-09-25 19:47:¶

Ah now I got your point (sometimes I quite slow).
But sometimes even having minimal access rights is enough to get root privileges ;-)

jankowa commented at 2017-09-27 14:15:¶

While I think there are reasons anyway not to store secrets (like ssh-keys) in the rescue image even if stored confidentially there are usage scenarios where you'll have to store the image on untrusted storage: e.g. a host in a data center with no direct hardware access. The only way to restore is to provide the iso file in some way as a rescue system with the tools the data center provides. Some have these features: instead of a general rescue image you can provide a custom iso on some file server - maybe your backup server.

But what about the secret of the backup storage? Correct me - but per default also the passphrases of the various backup systems are stored to rear image per default if configured.

We avoid this while not using rear for common daily backups - but for rescue system only. So we do not store the passphrase for the backup (in our case: borg) inside the rear config but provide them manually during rescue image creation.

I'm not a long time user of rear so maybe I just missed the possibility to configure the behavior already. If not it would be nice to decide with some options if passphrases should be stored in rescue image or not.

jsmeix commented at 2017-10-09 12:03:¶

With https://github.com/rear/rear/pull/1513 merged
I assume this issue is sufficiently fixed.
Regarding what "sufficiently" means, cf.
https://github.com/rear/rear/pull/1513#issuecomment-332413380

[Export of Github issue for rear/rear.]

#1511 Issue closed: Security Vulnerability (Privilege Escalation): SSH private user key disclosure for root account¶