Vulnerability in macOS client found at DEF CON 26; solved?

2»

Comments

  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member

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

  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member

    BTW, the talk at USENIX is happening now.

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

  • BenBen AWS Team

    Team Member

    No.

    Ben

  • 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.

  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member

    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.

  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member

    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.

  • 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?

  • BenBen AWS Team

    Team Member

    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

2»

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Emoji
Image
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file