Abusing Teams client protocol to bypass Teams security policies

In the unlikely event that someone reading this doesn't understand why server-side sanitation of any user input is always required, xkcd.com/327 provides an amusing take.

For example a comment earlier mentioned the chat feature is broken but they rushed out video background changes. This of course is a response to zoom - and it's possible to argue it's a strategic necessity - but it suggest the top level product management is blowing around in internally company winds rather than user needs.

Discord is another interesting datapoint. You can access that through the browser or natively, but their team has said that the native client means (among other things) better access to audio codecs for better quality audio and things like noise cancellation.

That's pretty much what it is.

Chat isn’t a product that can stand alone, so it’s always attached to another agenda. Skype was an interoperable phone with chat attached. Teams is a SharePoint client that has chat.

Teams is the Discord of integrated business chat from a usability perspective, at least if you want an integrated experience. Cisco's system last I was aware was a hodgepodge of applications, i.e. we had to have two separate Cisco chat applications running at all times.

Other players, its either one or both of: - a solution less kludgy than Cisco but still a hodgepodge of applications - a system that can't scale on one or more important axes - too specialized for a general use case

Remember, on one hand, Telcom uses erlang a lot. On the other hand THEY USE ERLANG A LOT. The sorts of stuff you see in phone systems is brilliant but archaic. And I bring that up because the voice integration in teams is really freaking nice and honestly the users are happier because its less integration hassle when moving numbers around, and that's a win for both IT and users.

Would I prefer discord had a competitive solution or Teams had a competitive UI? Yes. Or that Avaya would come blow everyone away with something amazing.

But part of me is also asking if teams has gotten so crappy lately because this year has likely resulted in them having to scramble on bugs and scaling issues in a way they didn't expect.

Mail loops in mail servers have always been a thing, and there are various ways to detect and stop them, usually by adding headers to a message and detecting it's the same one that was seen previously.

If there's actually a client side forward (which mail servers can't prevent because running mail through a local program, whether it be procmail, spamassassin, or some other mail categorization and filtering program) is a valid use case with a long history. There's also the case where the mail client is applying it's own complex rules and sending responses automatically. If the message is actually a new one, there's not an easy way to detect the loop.

There's a reason why Gmail for a long time (still?) didn't allow you to forward your mail to another Gmail address. I would argue that for Exchange, where it's generally much easier to track down individuals, erroring on the side of allowing administrators to do what they want to block this (whether that be company policy, exchange policy, or whatever) is the correct design choice.

Was actually quite useful to me since it meant I could script messages to internal todo list mailboxes from the *n?x boxen, though it did give the windows devs a mild heart attack the first time they saw it happen.

https://www.theverge.com/2020/5/10/21253627/microsoft-reply-...

If they can’t or decide not to acquire a company they will slap together a product like teams hoping to kill slack or zoom. It’s still a reactionary approach instead of doing R&D.

It’s the same in the “Fintech” software world where the large players are merging and acquiring small companies to stave off Stipe, Square, and whatever else hasn’t been picked up yet.

SMB server was updated eventually, so that it checked user access rights and didn't rely on the client not to request a file it wasn't allowed to see. SMB1 however continued to be horribly insecure, sending passwords in plain text, for example, which led to SMB2, SMB3 etc.

Got tangled up somewhere and didn't know where I was the next day. Maybe I'll try it again if Mattermost doesn't do it.

I'll check that out. Thank you.

I agree that the article is kind of unclear about whether it is only a cosmetic change. The title suggests not but the article is ambiguous.

This is 2020. Microsoft is 40 years old. How many times should we repeats the same dumb mistakes over and over again until we collectively learn as an industry. This should have been stopped at the initial design phase. Clearly those in charge can’t make simple design decisions or haven’t learned from decades of mistakes.

Also migrating from client side to server side means an entirely new version of APIs. It means clients being broken and migration issues for customers. New servers with old clients means backwards compatibility, etc. It will take years unless Microsoft kills the old version aggressively which they won’t because they’re Microsoft. This is a problem that will live on for 5 years at least.