Hacker News Reader

Hacker News

Comment by eduction | Hacker News Reader

Full thread

eduction

This attack makes no sense to me:

—————

Active Attack:

1. Adversary replaces the contents of ./Personal/malicious-site.com with the contents of ./Work/id_ed25519

2. Victim decrypts ./Personal/malicious-site.com and the decrypted contents is placed in her clipboard automatically.

3. Victim logs into malicious-site.com.

The victim just uploaded her work SSH private key to malicious-site.com

————

If the attacker is on the victim’s machine and has access to the ssh private key (“id_ed25519”), wouldn’t they just upload it directly to malicious-site.com via curl or whatever? Why this whole rigamarole?

If someone is on your machine doing arbitrary things what software can reasonably protect you? Even Signal would fail.

View on HN

They don’t have access to the ssh private key. They have access to the encrypted password file (and presumably not the password used to encrypt it).

The attack works when the user doesn’t realize they’re sending their SHH private key through the password form of malicious-site.com.

Something like accidentally putting your Google password into the Dropbox login form. Dropbox have now seen your Google password.

No, they clearly have access to the private key, otherwise they couldn’t copy it onto the path where the password is normally stored.

Also, they don’t need any password to encrypt the file, pass uses gpg encryption so they can just use the public key which will be sitting somewhere nearby.

You are misunderstanding the attack. The attacks requirement is: replace two encrypted files (e.g. by gaining access to someone's dropbox that contains the synced db), wait for them to leak "secretA" on "siteB" because `pass` doesn't securely bind secret and sites together. The attack is very realistic and high impact (but hard to perform).

Is pass able to decrypt ssh key files, or trick the user into decrypting them?

One of the files in the example is not a pass encrypted file but an ssh private key ("id_ed25519"). ssh private keys are either unencrypted or encrypted with a passphrase (but not via GPG in any case, and GPG of course is what pass uses).

The only way the outlined attack would be better than just uploading via curl is if pass could somehow enable the attacker to get a decrypted ssh private key. But I can't imagine why pass would be capable of doing that.

Reply on news.ycombinator.com