1Password CLI Vulnerability

Summary

Testing 1Password In October of 2023, I reported a vulnerability to 1Password regarding their op (a.k.a. 1password-cli) program. In my report I detailed that their approach to prompting users only once, and then leaving the vault open to the CLI was easily exploited in supply-chain scenarios, especially when a threat actor targets developer toolchains. There are two attack paths I highlighted, and I supplied them with a proof for one of them. This demo was tested across the three most recent versions of macOS, using zsh and bash shells using the latest 1Password desktop client. Two Attack Paths Both attacks would be a supply-chain attack, but there are two distinct paths: IDE Path The IDE path is pretty straight-forward, and I think carries the greatest risk: I install the 1Password extension because I responsibly wish to keep my tokens in a safe place (e.g. not my $ENV) I also use the MySQL extension in my IDE, it's nice to be able to stay in the same tool I use the 1Password extension to resolve secret references, which requires me to unlock my vault I installed a new red theme, red is my favorite color That red theme is an extension, and contained malicious code which uses the op NPM module to enumerate and exfiltrate every vault that I have access to Package manager path I install the 1Password CLI, and I use op to protect secrets in my environment I use GitHub Packages for NPM packages which are private to my organization I hear of a really nifty plugin which will allow me to add syntax highlighting to shell output on this CLI project I'm working on, so I npm i syntax-highlighting-stuff Oh no! syntax-highlighting-stuff had a post-install script on it, and it enumerated and exfiltrated the secrets from every vault I have access to Observed patterns It seems like the vulnerability is that once you unlock your vault, anything spawned from the parent process of whatever opened the vault retains an active session to that open vault. $ op run -- ls # This prompts me ...