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

2»

Comments

  • jpgoldberg
    jpgoldberg
    1Password Alumni

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

  • jpgoldberg
    jpgoldberg
    1Password Alumni

    BTW, the talk at USENIX is happening now.

  • XIII
    XIII
    Community Member

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

  • No.

    Ben

  • tienthanh411
    tienthanh411
    Community Member
    edited August 2018

    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
    jpgoldberg
    1Password Alumni

    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
    jpgoldberg
    1Password Alumni

    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
    Anserman65
    Community Member

    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?

  • 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
    chiponline
    Community Member

    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
    ag_ana
    1Password Alumni

    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
    chiponline
    Community Member

    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?

  • @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
    gordcook
    Community Member
    edited April 2019

    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
    AGAlumB
    1Password Alumni

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

This discussion has been closed.