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.
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.
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.
You can decrypt all the messages. I sometimes feel like I must have read a different paper than everybody else.
> 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.
(Here it's worth noting that this is the behavior post-fix for this paper. Read the paper! It was so much worse.)
With III-B, they can add an unverified device, but that causes a warning for every other room participant. Again, tamper evident.