5 ms·

My background is more in the applied end of things, not research, so I suppose that colors my perspective. But let's say I'm playing red team, and I get root o

My background is more in the applied end of things, not research, so I suppose that colors my perspective. But let's say I'm playing red team, and I get root on the box where my target is running their Matrix server. Practically, what can I do to extract information without setting off giant red flags? From my read of the paper the answer is "not much", since a bunch of big warnings popping up would probably alert the users that something sketchy is happening.

tptacek 4y ago
If you're red-teaming a Matrix server and you own up the server, you can decrypt all the messages of all the people using that Matrix server, and you can do it trivially, just using the basic protocol messages. Users might see extra group members in their groups and they might not, depending in part on whether they're running the most current version of the software. You can decrypt all the messages. I sometimes feel like I must have read a different paper than everybody else.
- dfgdfgffd 4y ago
  You can't decrypt all the messages, but only the ones sent despite warning
  - tptacek 4y ago
    This is an amazing assertion.
- pseudo0 4y ago
  You can decrypt all future messages in a noisy way that alerts all the users that something weird is going on. > While the Matrix specification does not require a mitigation of this behaviour, when a user is added to a room, Element will display this as an event in the timeline. Thus, to users of Element this is detectable. Virtually everyone uses Element, so it's blatantly tamper-evident. That makes it a really bad option if red-teaming.
  - tptacek 4y ago
    "Tamper-evident", meaning, Element will list the string name of the member the server injected into your group in the group list. (Here it's worth noting that this is the behavior post-fix for this paper. Read the paper! It was so much worse.)
    - pseudo0 4y ago
      I have used Element, and new users joining a room are displayed as an event in the timeline. The paper confirms that in section III-A, and based on the context I'm 99% sure that they mean pre-fix, not post-fix. With III-B, they can add an unverified device, but that causes a warning for every other room participant. Again, tamper evident.
      - tptacek 4y ago
        We're clear that this is "an event in your timeline" that says "the server might be decrypting all your messages or maybe a new participant joined your group", right?
        pseudo0 4y ago
        If some random user joins my E2EE groupchat, yes, my expectation is that some unknown actor is now reading my messages... It would be no different than some rando getting added to a Signal group. At least in the groups I'm in, that would cause a flurry of messages asking who they are and who added them.
        dodgerdan 4y ago
        What if someone already in the group adds a new device? That would hardly cause a flurry or surprise, it’s a common thing to happen. But using Matrix it could also mean whom ever controls the server could be reading all your messages. And the alert has to cover both scenarios. I’m not sure how you could message that in such a way to make it actionable. Especially to non-tech users. Even if they did understand it would require a mini investigation/“flurry” multiple times a month for even a modest sized group. My personal observation is that a group of about 50 have 1 new phone every two weeks, with seasonal increases around Sept/Oct and January 1st.
- RonoDas 4y ago
martinralbrecht 4y ago
This isn't correct. Several of our attacks succeeded without any warnings popping up. Furthermore, you need to distinguish between what Element happened to do (which users may or may not watch out for) and what the standard demanded. Note that at this point, as far as I understand it, there is no dispute between us - the authors of this research - and the Matrix developers about that leaving group membership under the control of the server was a bad and avoidable design decision. The Matrix developers are working on a spec change/fix which resolves this, linked elsewhere in this thread.
- Arathorn 4y ago
  The problem is that the paper conflates legitimate implementation vulns (fixed back in Sept) which indeed allowed for practical attacks… with the “group membership controlled by server” issue, which is debatable. Hence folks writing off the remaining issues as ‘academic at best’. It really would have been better to separate the legit vulns from the group membership question, as mixing them up just confuses people, as per this whole thread.
  - tptacek 4y ago
    Can I ask what's debatable about the group membership issue? That it exists, or that it's as important as people like me say it is?

tptacek 4y ago

If you're red-teaming a Matrix server and you own up the server, you can decrypt all the messages of all the people using that Matrix server, and you can do it trivially, just using the basic protocol messages. Users might see extra group members in their groups and they might not, depending in part on whether they're running the most current version of the software. You can decrypt all the messages. I sometimes feel like I must have read a different paper than everybody else.

dfgdfgffd 4y ago
You can't decrypt all the messages, but only the ones sent despite warning
- tptacek 4y ago
  This is an amazing assertion.
pseudo0 4y ago
You can decrypt all future messages in a noisy way that alerts all the users that something weird is going on. > While the Matrix specification does not require a mitigation of this behaviour, when a user is added to a room, Element will display this as an event in the timeline. Thus, to users of Element this is detectable. Virtually everyone uses Element, so it's blatantly tamper-evident. That makes it a really bad option if red-teaming.
- tptacek 4y ago
  "Tamper-evident", meaning, Element will list the string name of the member the server injected into your group in the group list. (Here it's worth noting that this is the behavior post-fix for this paper. Read the paper! It was so much worse.)
  - pseudo0 4y ago
    I have used Element, and new users joining a room are displayed as an event in the timeline. The paper confirms that in section III-A, and based on the context I'm 99% sure that they mean pre-fix, not post-fix. With III-B, they can add an unverified device, but that causes a warning for every other room participant. Again, tamper evident.
    - tptacek 4y ago
      We're clear that this is "an event in your timeline" that says "the server might be decrypting all your messages or maybe a new participant joined your group", right?
      - pseudo0 4y ago
        If some random user joins my E2EE groupchat, yes, my expectation is that some unknown actor is now reading my messages... It would be no different than some rando getting added to a Signal group. At least in the groups I'm in, that would cause a flurry of messages asking who they are and who added them.
        dodgerdan 4y ago
        What if someone already in the group adds a new device? That would hardly cause a flurry or surprise, it’s a common thing to happen. But using Matrix it could also mean whom ever controls the server could be reading all your messages. And the alert has to cover both scenarios. I’m not sure how you could message that in such a way to make it actionable. Especially to non-tech users. Even if they did understand it would require a mini investigation/“flurry” multiple times a month for even a modest sized group. My personal observation is that a group of about 50 have 1 new phone every two weeks, with seasonal increases around Sept/Oct and January 1st.
RonoDas 4y ago

martinralbrecht 4y ago

This isn't correct. Several of our attacks succeeded without any warnings popping up. Furthermore, you need to distinguish between what Element happened to do (which users may or may not watch out for) and what the standard demanded. Note that at this point, as far as I understand it, there is no dispute between us - the authors of this research - and the Matrix developers about that leaving group membership under the control of the server was a bad and avoidable design decision. The Matrix developers are working on a spec change/fix which resolves this, linked elsewhere in this thread.

Arathorn 4y ago
The problem is that the paper conflates legitimate implementation vulns (fixed back in Sept) which indeed allowed for practical attacks… with the “group membership controlled by server” issue, which is debatable. Hence folks writing off the remaining issues as ‘academic at best’. It really would have been better to separate the legit vulns from the group membership question, as mixing them up just confuses people, as per this whole thread.
- tptacek 4y ago
  Can I ask what's debatable about the group membership issue? That it exists, or that it's as important as people like me say it is?