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

jpgoldberg

Only an admin user (so definitely not Guest) can add themselves to the access_bpf group.

jpgoldberg

BTW, the talk at USENIX is happening now.

XIII

But what if an admin user installs Wireshark? Will that still add "Guest" to access_bpf?

Ben

No.

Ben

tienthanh411

As an author of the attack presented at DefCon, let me make it clear.

First, the attack was performed on Safari on macOS, where WebSocket is used instead of native messaging.

Second, the attack could be done by any unprivileged user, including guest account. No admin/root access is needed.

Third, we don't use WireShark.

jpgoldberg

Thanks @tienthanh411!

For what follows there are a couple of facts that will be useful to remind everyone of.

1. The ability to read traffic between client (browser extension) and server (1Password mini listening on a web socket) is distinct from the ability to impersonate either the server or the client.
2. The ability to impersonate the client would result in the ability to extract most secrets from 1Password.
3. The ability to impersonate the server would result in the ability to extract only those secrets that get saved to 1Password from the browser (saving a new login or password change in the browser)
4. It requires an admin user to read the localhost traffic on macOS.
5. The bug we were fixing with this protocol was to prevent client impersonation on Windows. (We were already successfully preventing this on macOS.)

The (ir)relevance of wireshark

I probably should have edited irrelevant sections of the thing I quoted. The wireshark issue was only about reading bidirectional traffic between client and server. We took the opportunity when creating this ad-hoc protocol to obfuscate that traffic. Although we dislike obfuscation, there is a history of people getting very worried when they discover that an admin user can read that traffic. So as long was we were adding in a new protocol, we added that in as well. It is not relevant to either client or server impersonation.

Server impersonation vs client impersonation

The reason why we added the this "broken ad-hoc crypto protocol" (you are not wrong to call it that) was to defend against client impersonation on Windows. As you noted, on Mac the server checks the owner of the process behind the client. The analog of that check on windows was didn't work, as was pointed out to us by Tavis Ormandy in August 2016. This protocol didn't do anything on Mac other than to obfuscate the traffic to and from localhost.

You can read what we announced about it at the time. This was a defense against client impersonation.

What it does (or doesn't) do now.

Although we didn't set out to solve server impersonation, we again used the opportunity to make a dent in that problem. At the time that we rolled this out, non-first-use authentications would fail if the server couldn't prove its identity to the client. We still had the eavesdropable key exchange, but we forced the user to go through the verification dance.

But that turned out to be a usability nightmare. No one understand what it was. It would fail as an indication to the user of a potentially malicious server. So once we were able to move to things like native messaging with some browsers (particularly on Windows) we just dropped the user intervention everywhere. We left the protocol in place for the obfuscation gain.

So we left it in place, but without the user intervention. Thus it no longer served any purpose beyond the traffic obfuscation by the time you investigated it. After moving authenticating the named pipes on Windows (though we can improve that), the original problem went away. This is why I said it was moot. That whole protocol, while it once had a real job to do, only remains for the traffic obfuscation.

jpgoldberg

What is most interesting for me in @tienthanh411's work is the suggestion of user assisted key exchange. It is one of those things that is "obvious" once someone points it out. We already were (in the originally deployed version) prompting user interaction. Having the user manually enter a client generated key into the server would have made the key exchange work.

This still would have left server impersonation possible, but again our goal was to plug a gap on Windows that allowed for client impersonation. But this would have solved the key exchange issue.

But the question now, once we can kill off the web socket entirely, is whether we keep this obfuscation layer at all. It is probably better to just drop it (so that it isn't "news" when someone breaks the obfuscation) and this would allow for a simpler protocol.

Anserman65

I'd like to know WHY 1Password has added a access_bpf user inside the Users & Groups section of MacOS 10.13.6. As a SysAdmin I know that this was NOT in there before the latest update. Is this a needed User?

Ben

Hi @Anserman65

"access_bpf" is typically associated with Wireshark and perhaps other packet capture / network monitoring tools. I don't see any such user on any systems I don't have Wireshark installed on.

Ben

chiponline

Just to be clear, 1Password is installing Wireshark? I just found an access_bpf group in Users & Groups which listed me, a second login account I use for troubleshooting, and Guest.

ag_ana

Hi @chiponline! Welcome to the forum!

1Password does not install Wireshark. Do you have Wireshark or any other network monitoring tools already installed on your machine, as Ben suggested in his latest comment?

I just checked my Users & Groups menu and I don't see an access_bpf group here, even though I am running 1Password.

chiponline

Thanks for your response. It's a bit of a mystery. After upgrading to High Sierra the only app I installed was Office 365. I went to Users and Groups to re-enable Guest (for tracking) and try to figure out why root user wasn't showing up and found access_bpf group. I use BLOCK BLOCK and F-Secure XFENCE so my installs/permissions are pretty tightly regulated. Wireshark does not show up in any searches of my hard drive. Should I just delete it and not worry about it?

Ben

@chiponline

I really couldn't say. It wouldn't have anything to do with 1Password. Deleting the group wouldn't have any impact on 1Password but I wouldn't be in a position to comment on anything beyond that.

Ben

gordcook

FWIW, there's a known issue(?) with Wireshark where if you install it and then uninstall it afterward, the access_bpf group is not automatically removed. I can't say whether it's relevant in @chiponline's case, but I thought I'd mention it...

https://osqa-ask.wireshark.org/questions/1797/how-to-fully-uninstall-wireshark-from-a-mac/5176

AGAlumB

Ah, that's good to know. Thank you for mentioning it!