Vulnerability in macOS client found at DEFCON26; solved? [1Password uses Native Messaging]

XIII

Slide 39 of this DEF CON 26 presentation suggests that researchers have found a vulnerability in the macOS client for 1Password.

Is this fixed?

And what was broken?

Ben

@XIII

There are very little details from what I can see but I suspect that they are referring to the fact that in the past it was possible with someone who had root access to a machine to watch the traffic passed between the mini and the browser extension via a socket. Modern versions of 1Password use native messaging instead of sockets to communicate. Native messaging is not subject to this.

Ben

Ben

If this is indeed what they were referencing more information can be found here:

https://blog.agilebits.com/2015/06/17/1password-inter-process-communication-discussion/

and here:

https://blog.agilebits.com/2017/07/19/introducing-native-messaging-for-the-1password-extension/

Ben

XIII

Does this version use native messaging?

https://www.youtube.com/watch?v=b3oA55HmmLw

Ben

It appears the version they are demoing there is older and uses sockets but I'm going to ask our security team to review.

Ben

AGAlumB

@XIII: Native Messaging was added in 1Password for Windows version 4.6.2.624 and 1Password for Mac 6.8.

Any time you see "1Password requires authorization” in your browser", that's not Native Messaging; it's WebSockets, and 1Password has the user match the code to authorize the connection to the browser. And of course, as Ben mentioned earlier, once you have root access you can do pretty much anything, including authorize a connection to the browser and disable system security checks to allow all traffic there to be monitored.

There was a fairly extensive discussion on a related topic a couple years ago. I'm going to risk quoting myself here, but I do think this sums things up fairly succinctly (which is not something I'm known for) and is relevant in this case as well:

I think the key takeaway from these discussions is that no one should (or would — not even you) have access to loopback traffic through tcpdump unless your system has been setup explicitly to allow this. If you're doing it (by allowing Wireshark to reconfigure things) you need to be be aware of the potential consequences from a security standpoint (were your system to be accessed by someone malicious with your privileges); and if someone else is able to do this, they already own your system and all bets are off anyway. :dizzy:

XIII

And of course, as Ben mentioned earlier, once you have root access you can do pretty much anything

Does a guest account (that's what the hacker uses in the video) have root access?

AGAlumB

@XIII: Not by default, but they should be able to grant it since they have full control over the machine.

XIII

I'm afraid I don't understand why you both insist that they have full control over the machine. If I understand the linked discussions correctly it can also happen on machines where "only" Wireshark is installed (which is the case for some mobile developers I know). And even that condition is not mentioned in their PDF.

Let's wait for the feedback from your security team?

(I would appreciate a blog post with an official response on the (outdated?) vulnerability presented this research paper)

AGAlumB

@XIII: Admin rights are needed in order to modify the system in the case of the Wireshark discussion I linked above. That's not exactly the same, but in the video you can see that they have fun access to the machine.

Anyway, most of this is pretty vague, but PDF is fairly clear about this:

Native messaging is immune to MitMa attacks

The only thing they've demonstrated here is that they are able to capture data entered in plaintext in the browser by having direct access to the machine. I'm not sure that warrants a blog post.

dc31xx

Man In The Machine

AGAlumB

@dc31xx: That's a video of someone using an old version of 1Password for Mac on a computer where they're capturing text entered in plain sight in the browser on a computer they control. I don't think it's relevant. :)

dc31xx

@brenty I don’t think you got the exploit. They were able to MITM the communication between the client and the browser extension from a process running under another user account (no special privileges, guest account). Not sure about the versions, but I’m almost sure it works up until the latest version.

AGAlumB

I don’t think you got the exploit. They were able to MITM the communication between the client and the browser extension from a process running under another user account (no special privileges, guest account). Not sure about the versions, but I’m almost sure it works up until the latest version.

@dc31xx: My point is that they authorized the connection themselves and have full access to the machine. If it is something that can be done without that privilege that's not at all what's demonstrated in the presentation or paper. If they can do it to mine I'll be interested.

Also, this is a discussion about 1Password X, which does not involve any sort of IPC; it runs entirely within Chrome or Firefox; there is no WebSockets connection involved ever. So an old version of the Mac app, even running on a pwned system, isn't relevant here.

dc31xx

@brenty I agree it is off topic, should have posted it in separate thread.

They didn’t authorize anything. Yes they do need local access on the machine, but it doesn’t have to be your account, it can be a guest account or remote access (SSH). You don’t need to tell me how the exploit works, I was at the presentation and frankly as a 1Password user I find it disturbing that you don’t seem to think this is a threat.

AGAlumB

They didn’t authorize anything.

@dc31xx: The video shows them authorize the connection, like this:

Yes they do need local access on the machine, but it doesn’t have to be your account, it can be a guest account or remote access (SSH).

But they need full access to the machine.

You don’t need to tell me how the exploit works, I was at the presentation and frankly as a 1Password user I find it disturbing that you don’t seem to think this is a threat.

I wasn't there in person. If there's some more information you can direct me to I'm definitely interested. But based on what I've seen in their video and document it's exactly what I would expect with that kind of privilege on any computer. It's always bad if someone else pwns your system.

dc31xx

The authorization is to setup the extension for the first time isn’t it? Just normal usage.

dc31xx

And I repeat, no full access needed. You keep refering to the user that uses the app. That’s the whole point. Yes someone is using the app as you would normally do, but the guest account is able to intercept the traffic. I assume you already contacted the authors of the exploit to explain in detail.

AGAlumB

@dc31xx: That's not normal usage because, as mentioned in their document (p.30), Native Messaging, which 1Password uses now to communicate with browsers, isn't affected:

Native messaging

● Browser’s built-in method for communicating between browser extension and native code
● App registers with the browser:
○ an executable, called Native Messaging Host (NMH), and
○ a configuration file specifying which browser extensions have access to the NMH
● Browser starts the NMH in a child process and lets the browser extension communicate with it
Native messaging is immune to MitMa attacks

It's not surprising that someone with access to localhost due to machine compromise can intercept socket communications. But even that only applies to the older WebSockets method. Native Messaging connections are unaffected.

dc31xx

They didn’t mention that 1P now uses native messaging. That basicly is what I needed to know.

AGAlumB

@dc31xx: Aha. Sorry for burying the lede. I thought that was clear from them using an old version and referencing Native Messaging in the paper. I agree it's a bit confusing though. For reference, Native Messaging was added last year, in 1Password for Windows version 4.6.2.624 and 1Password for Mac 6.8.

System

This discussion was created from comments split from: The 1Password X extension seems very vulnerable if my computer gets hacked..

dc31xx

Thanks, should have started with that question.

AGAlumB

I should have anticipated it, so I think we can call it even. :lol:

AGAlumB

I should clarify, Safari does not use Native Messaging for its traditional extension support (I don’t have a better term for it, but it will make more sense in a second). With version 12 we’re using a Safari App Extension instead (traditional Safari extensions are being phased out by Apple), which is part of the app itself and thus requires no other communication channel, the way that is necessary with a separate app and extension. Hopefully that’s a bit clearer (nomenclature notwithstanding), but please let me know if there are any other questions.

jpgoldberg

Hi, I just had lunch with Siddharth Rao (one of the authors) and a coffee break discussion with Thanh Bui (the other) at Usenix Security. They will be presenting a more technical version of it tomorrow. And we have talked about this via email a number of times over the past half year or so. (They sent us an advanced copy of the paper.)

tl;dr The issue (never a big one to begin with) is now so close to entirely moot that I'm willing to say entirely moot.

"What was broken?"

@XIII asked:

And what was broken?

The problem that they correctly point out is that the initial key exchange in what we call "Simple Mutual Authentication" between the 1Password browser extension and 1Password mini when using a web socket can be eavesdropped upon. Our internal specification of this protocol acknowledged this at the time it was written:

Threat model

The threat we are defending against is of an unprivileged user (other than the target) on the same system as the target user connecting to the target's instance of the Helper/Mini/Agent (henceforth "Helper") and extract the target user's secrets.

This is not intended to defend against

1. An attacker with root/administrator powers on the target's machine
2. An attacker who can read the users' files on the target machine.

In particular, 2 means that we are not attempting to defend against a malicious process that runs with the powers of the target user.

We assume that an attacker may be able to read loopback even if they aren't particularly privileged on the target machine. This can happen in certain Windows environments, and on OS X non-root users may find themselves added to a group that can read such traffic after installing a tool such as ethereal Wireshark.¹

We accept "Trust on First Use". That is there is an initial registration process in which (a) unencrypted secrets are exchanged between OPX and Helper, and (b) the channel is not fully authenticated. However, we also insist that that user action and approval is needed for that.

What is at issue is the

That is there is an initial registration process in which (a) unencrypted secrets are exchanged between OPX and Helper,

Not an error, but a decision

I'd like to point out that this was not a crypto blunder. We were fully aware that our initial key exchange could be eavesdropped upon, thus allowing an attacker who learned that key at that time and then use it to impersonate either OPX or Mini in future communication (if they could break the other things needed for impersonation) or decrypt the traffic.

So why did we (and in particularly I) do it that way instead of using the obvious solution of something like a Diffie-Hellman key exchange (DHKE)? The answer is a combination of many things. I stand by the choice we made.

1. The threat we were defending against with this whole protocol was exceedingly narrow. There was a by-pass to all of our mutual authentication checks on Windows that could potentially allow a Windows user to set up a malicious process on the local machine to successfully pretend to the web-socket that it was a legitimate 1Password browser extension.
2. 1Password 4 from Windows was supposed to die "any day now (then)", but we still didn't have an alternative available to Windows users that met important needs.
3. Websockets were going to die. Sure it has taken as a couple of years, but we've been waiting for browser technology to allow us to improve in a way that gave us more secure interprocess communication.
4. Neither OPX nor 1Password 4 for Windows had the cryptographic or big number libraries needed for a DHKE.
5. We were under an odd sort of time pressure to address the original Windows issue. (Despite it being hard to exploit and it skating near the edge of something that we should try to defend against at all, it had been reported in a very high profile way, and we had a deadline.)

So given all of that, and particularly 4 in combination with the actual limit of the threat I made the decision to not have our OPX and OPW4 developers (especially since OPW4 was supposed to die soon) that I would construct a protocol that used only the cryptographic primitives that were already available to them. BTW, I also reported this decision to the person who reported the initial Windows issue, and he seemed to accept what we did as a suitable mitigation.

Note that the particular threat only ever existed on Windows (we could check who "owns" a web-socket on Mac), but we introduced this whole verification process for Windows and Mac. That is because it "solved" a cosmetic issue that local host traffic could be read by root.

Since then

We've replaced web sockets for everything but Safari users on Mac. As I mentioned above, the whole reason for that weird key exchange was only needed on Windows, so the fact that it is still used in Safari is not really relevant. (The key used there is not used or related to anything else.)

"Almost entirely moot"?

If you use Safari today, and some other user on your same Mac is an admin user, they can give themselves the power to read the communication between the 1Password browser extension and 1Password mini. There are lots of other things that an admin user can do.

Conclusion: Don't have a malicious or compromised admin users on your machine.

---

1. Installing Wireshark on macOS will prompt for an administrator password and add the user to the access_bpf group. ↩︎

rickfillion

To help people reading Jeff's post...
OPX = 1Password Browser Extension
OPW4 = 1Password for Windows version 4

XIII

Thank you for the elaborate answer @jpgoldberg!

What's unclear to me: are those fellow developers with Wireshark installed still vulnerable if they use Safari (on macOS)? (via the guest account)

rudy

@XIII,

not sure about the guest account angle, since the user running Wireshark would need to have elevated privileges in order to use Wireshark, no?

XIII

I don't know. The linked thread only mentions that Wireshark elevates rights for non-admin users, but it does not say whether that includes the guest account.

Ben

The short answer is no, as far as I can tell: not without explicitly adding the guest user to the access_bpf group or giving the guest account sudo access (tasks that require root).

https://apple.stackexchange.com/questions/138694/what-is-access-bpf-group
https://stackoverflow.com/questions/41126943/wireshark-you-dont-have-permission-to-capture-on-that-device-mac

Ben