Abusing Teams client protocol to bypass Teams security policies

https://o365blog.com/post/teams-policies/

by tommoor • 6 years ago

236 109 6 years ago

I would have expected a responsible disclosure timeline, but it looks like he didn't report this to MS

tuco862• 6 years ago

I'm not sure i would have either. this is not not a security bug. this is pure negligence and doesn't deserve the courtesy IMHO.

6chars• 6 years ago

It would have been a courtesy to Teams users too, not just MS. I don't see the downside of going through the proper channels before disclosing this publicly unless the goal is some kind of "revenge" for the bug.

kube-system2• 6 years ago

Responsible disclosures aren't really a courtesy to the developer as much as they are a courtesy to the users who are running the software in production.

tyre2• 6 years ago

I’m curious to know what the processes were that led to this. One or more API engineers either never thought to implement permissions; never thought to ask when it wasn’t in the spec; or did ask, were told not to do it, and then didn’t.

It’s pretty basic stuff.

dijksterhuis• 6 years ago

My first thought was that Microsoft (or a subset of) probably determined any impact from an adversary taking advantage of these client side settings was fairly minimal (at least the messagePolicy values).

Then I remembered zoombombing is a thing and can be pretty disruptive.

It could also be an inherited problem from the days when teams was actually Skype for business.

corndoge2• 6 years ago

Reading the article it definitely seems poorly worded but I don't see any evidence of any security issue here. Cosmetically changing the client is a non issue.

tyre2• 6 years ago

Permissions are not solely about security. They can also be related to compliance. Permitting users to delete messages when they shouldn't be allowed to can raise issues.

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.

pgoggijr• 6 years ago

I'm hoping that this is a server-side bug and not by-design. I would be extremely disappointed to see a widely-used enterprise product by a company with such stature to be designed with such little forethought.

AshamedCaptain2• 6 years ago

"widely-used enterprise product" usually implies little forethought. Bonus points if it's communication/teleconferencing software.

There was this essay about this being an inevitable result, considering that large companies almost never take user feedback into consideration when selecting "enterprise software". Which is the reason most enterprise videoconfering software sucks.

wil421• 6 years ago

Enterprise software companies sucks because most companies buy competitors to grow instead of doing R&D. It’s a reactionary process instead on a proactive one, especially for companies with other cash cows.

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.

duxup• 6 years ago

In the early days of Exchange I was curious what would happen if I setup a rule for two clients to just reroute emails to each other back and forth.

So a buddy of mine and I tried it. The rerouting was done (as far as we could tell) client side and it seemed there was no inherent server side method of detecting such scenario.

Company email for a few thousand folks went down after the two clients took off doing their thing for a short while.

IIRC the client wasn't immediately inclined to forward other forwarded emails (again enforced on the client) but an easily crafted rule would bypass that easily.

At the time I was surprised there wasn't any automatic prevention of such things, as my career has gone on, I just assume such things aren't there ;)

pixl97• 6 years ago

You'd have thought that after Bedlam DL3 that reply all storms would have been dealt with by default long before now, but it's only a recent thing

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

mst• 6 years ago

My favourite thing many years back ('01 or so IIRC) was that supposedly internal only mailboxes could me sent to via SMTP if you used the LDAP DN for the mailbox as the user part.

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.

kbenson• 6 years ago

If by "rerouting" you mean user level forwards, then that's generally done at the mailbox level, but not the client side (depending on system and rules), because users are allowed to set their own forwards.

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.

paxys3• 6 years ago

Disappointed but not at all surprised. Teams is the poster child of the kind of software that users are forced to use, and so functionality, polish, overall experience, security or anything else doesn't matter to the Microsoft as long as the account managers/IT/COO etc. are kept happy.

737maxtw• 6 years ago

You've never used the Cisco suite of alternatives, have you?

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.

Spivak• 6 years ago

Hahaha. Slack does something similar. My company set a policy to log everyone out of Slack every week. And it “works” except it’s enforced only by the client because you can go into Slack’s files and pull out your user-key which is a session token that never expires, is never rotated, and bypasses SSO and 2FA.

So everyone who doesn’t want to be logged out just extracted their key and uses it to stay logged in on their other clients.

(Also, if you run across some tool/bot that needs a Legacy Token you your user-key will work. When Slack stopped letting users generate them it didn't apply to Slack itself.)

Quarrelsome3• 6 years ago

150 separate HTTP requests on startup? That seems quite a lot. I'd guess its smth multiplied by the number of teams you have?

wizzwizz42• 6 years ago

Perhaps, but many of them occur before the list of Teams even loads. Microsoft Teams isn't very self-contained. (It's also unequivocally the worst piece of Microsoft software I've ever used – probably worse than some of the early versions of Internet Explorer – but that's not too relevant here.)

Did you know that Teams sends a big telemetry dump every few (somewhere between 3 and 15) seconds, if you're on certain views? Well, there's a separate system for each, meaning if you have two open at once it can double-send the telemetry. I wouldn't be surprised if Teams was responsible for the majority of an organisation's network traffic.

suprfnk• 6 years ago

As another comment said, this is pretty basic stuff. Though I am not surprised. The Teams client is pretty bad. It's slow and clunky. It tries to do way too much while succeeding at very few things.

The desktop client chat _still_ doesn't have a "reply to message" feature, while the mobile client has had it for, what, more than a year? This is a feature that _should_ cost a competent engineer no more than what, a week? to implement. The team should take a note out of Discord's or Telegram's book to improve the chat experience. It's really very bad.

In the meantime the latest noticeable additions were mostly fluff like extra ways to show webcam stream backgrounds, and a "cinema-like" webcam-view.

It's interesting that the same company can produce both Teams, being pretty bad, and VS Code, being very good.

Quarrelsome3• 6 years ago

It's interesting that the same company can produce both Teams, being pretty bad, and VS Code, being very good.

Surely this demonstrates the wide variance you get with software and how important professional discipline is?

LarvaFX• 6 years ago

I would say it does.

lifeisstillgood• 6 years ago

I would like to agree here, but to emphasise "discipline" being an organisational not individual issue. Given that there are certainly competent emgineers at MSFT and most could carve out a week of coding without anyone noticing, what is missing is high level organisational insistence on good professional discipline - and it's so easy to just let that slip.

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.

boogies• 6 years ago

It's interesting that the same company can produce both Teams, being pretty bad, and VS Code, being very good.

The former it develops by itself, the latter has a codebase others are Free to contribute to (as long as they don’t agree to the official binary’s EULA, which isn’t required to use VS Codium).

watwut• 6 years ago

Pretty bad is understatement. It is very bad, especially if you are split into two organizations.

bluedino• 6 years ago

The Skype client is total garbage as well, so apparently nobody at Microsoft can make a chat client.

toast0• 6 years ago

Maybe nobody recently, Comic Chat was epic (and certainly guilty of embrace and extend)

Spooky232• 6 years ago

I talk about the universal law of chat client entropy. Chat peaked in 2000/2001 with AIM and Yahoo. Everything else get worse over time.

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.

qppo• 6 years ago

to be fair to microsoft, both Sype and Lync were acquisitions. Lync chat was pretty good before it became Skype for Business

prepend3• 6 years ago

MSN Messenger was pretty good.

PretzelPirate• 6 years ago

The “reply” feature is already implemented but it’s been sitting in an internal ring for forever!

eznzt2• 6 years ago

Discord does not have a "reply to message" feature either, it just copies and pastes the message into your input field. You can freely edit the quoted message, and if the user you replied to edits his message, yours won't get updated.

notamy• 6 years ago

Discord does have this, just not publicly available yet. It's in active development still, see ex. https://github.com/discord/discord-api-docs/pull/2118

edgyquant• 6 years ago

Teams is a Slack competitor not Discord. Slack does have this.

Tade0• 6 years ago

It's interesting that the same company can produce both Teams, being pretty bad, and VS Code, being very good.

I think it was simply rushed to production. I remember VS Code not being that amazing at the start (slow etc.), but with time, effort and love put into it, it grew to become a competent IDE.

Teams was horrible when it first came out, but I'm noticing some improvements in performance and stability since then.

dheera3• 6 years ago

I don't understand why every advertised feature of Teams can't be done with a web interface, like Slack.

Even with Slack I see no reason for a desktop client, which looks to me like just a widget-less browser running slack.com inside. I didn't need an app for that. And with the web client I can inject JS/CSS as I please (e.g. to prevent sending typing indicators).

nitrogen• 6 years ago

just a widget-less browser running slack.com inside

That's pretty much what it is.

rkangel2• 6 years ago

The most obvious one is screen sharing - that requires some access that isn't possible through the browser. Also, interacting well with audio and video hardware might need native support.

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.

xienze• 6 years ago

You know you can use Teams from your browser, right? Go to teams.microsoft.com. Seems pretty full-featured as far as I can tell.

ZiiS• 6 years ago

VS Code is used by the people who write it; this is _very_ significant on resulting quality.

paxys3• 6 years ago

Pretty sure it's the same for Teams

Plasmoid2000ad• 6 years ago

I'm confused, are you suggesting the team that write the code for Teams don't use it?

antoineMoPa• 6 years ago

As a datapoint, I use Teams on Linux (desktop app) and I have to say that I love it. I would not say it is slow and clunky as you say.

linker30002• 6 years ago

As another datapoint, I also use Teams on Linux (Mint 20) and although it's generally fine to use, on a couple of occasions it has completely frozen my desktop PC about 1 hour into a meeting and I've had to hit the power button to get going again.

jschwartzi2• 6 years ago

The Windows client is really really slow. Nearly every time I click on it and start typing I get about 10 characters in before it pauses and does something for about 15 to 60 seconds, and then I can finish my message when it's done.

arpa• 6 years ago

I especially like that you have to killall -9 teams to exit it. Installed as official deb from MS.

mytailorisrich• 6 years ago

It's interesting that the same company can produce both Teams, being pretty bad, and VS Code, being very good.

In huge companies like Microsoft teams working on completely different products can be as separate as if they were working for different companies.

It's not inconceivable that the first link between those teams is at executive management level.

Shivetya• 6 years ago

Having both Teams and Skype, we are slowly depreciating Skype, the one feature I miss most in Skype is that it is very easy to have just a list of who is active and who is not where in Teams you have a list of people you have chatted with but that is different than keeping track of people by favorites.

theschmed• 6 years ago

The desktop client chat _still_ doesn't have a "reply to message" feature

FYI for those who like to reply, you can put a > and a quote box will appear, you can copy and paste the message you wish to quote.

To exit the quote box, type "Alt-Enter" twice

remote_phone2• 6 years ago

If this is true, Microsoft should be completely embarrassed and the leads on this piece of softwar who made that decision, all the at up through to senior management, should be fired.

For Microsoft to build such a product without basic security in mind is beyond belief in 2020. There is no level of “technical debt” excuse that can make up for a lazy, anti—user decision like this.

koluna3• 6 years ago

That’s a stretch. If we fired everyone every time something like this happened, you would have nobody working in tech. This bug does not result in data leakage/disclosure, nor it put anyone’s business at significant risk. Lesson learned, let them fix it, and see what we can learn.

remote_phone2• 6 years ago

This is an enterprise product. Enterprise customers are expecting at least decent security. How long has this been out? My son’s therapist uses Teams because she said it had better security.

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.

koluna3• 6 years ago

That’s one way to not do responsible disclosure and give the company a chance to address/fix the issue. I guess clicks on the blog are more important.

Krasnol3• 6 years ago

Is there anything the community here can recommend besides Slack?

sailfast• 6 years ago

I'm a big fan of Mattermost.

gaogao• 6 years ago

Mattermost is a fairly good open source alternative.

Krasnol3• 6 years ago

Ah yes, I've heard about that one before.

I'll check that out. Thank you.

devthrowawy• 6 years ago

Mattermost seems pretty to-the-point. Really not getting what's so hard about chat with some basic formatting.

MaxBarraclough• 6 years ago

I haven't tried it, but Element is a Free and Open Source alternative.

https://en.wikipedia.org/wiki/Element_(software)

Krasnol3• 6 years ago

I failed installing the server a few weeks ago.

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.

rkangel2• 6 years ago

For purely text chat, at a previous company we used Zulip. I still think that is the best implementation of 'topics' (like threads in slack).

corndoge2• 6 years ago

Did I misread the article, or is this not really saying anything? I think most comments here think that this means locally overriding policies leads to elevated access on the server, but what is demonstrated is only enabling certain UX features that are disabled per server side policy by lying to the client. For example, the video demonstrating "bypassing cloud storage restrictions" only enables the client side button to add providers other than SharePoint, but this has no effect serverside. Similarly, bypassing editing and deleting policies client side is shown but with no mention of whether this has any effect on the server or is just a cosmetic effect on the client.

Another blog post could be written titled "I wrote my own teams client where I'm allowed to edit messages locally", would that be a security issue?

In other words there is not really anything of note, if I read the post correctly.

prepend3• 6 years ago

Seems like a surface hack that makes people think something bad happens. I hate these kinds of issues as they will prompt emails from non-technicals who think it’s a real threat.

chrismeller• 6 years ago

I’m even more confused. In the video I see him doing something completely different from what he says in the article.

Neither the article nor the video prove that it does anything more than limit the display options client-side though. The source of truth is still the server and nothing here speaks to that...

geoelkh• 6 years ago

Agree. The backend tells you what is allowed and you override it and it shows that it is allowed now :)

The real issue would have been if the user did these actions and there was no backend validations on them. The video does not cover this.

ludjer• 6 years ago

Yip I am struggling to see where the security risk is. If the policies are still applied server side(I am assuming this is the case since they did not demo server side vulnerabilities). Then all you are doing is getting to a part of the UI that has no functionality. The same can be done with many other UI's by editing the local configuration.

TwoBit• 6 years ago

The article is not saying that this is a security issue. It's saying that admin control of these policies is circumventable and so don’t depend on them. That's useful to know.

jaywalk• 6 years ago

But it seems like nothing actually depends on these policies except some cosmetic stuff in the client. So it's literally nothing.

markandrewj• 6 years ago

If you can't preform the action associated with the interface element, the policies are not circumvented though. Being able to see the interface elements, and being able to preform the action associated with the interface element, are different things.

nemetroid• 6 years ago

I think the introduction to the article describes something that's not just a UI thing:

While I was working with the previous version (v0.4.4) of AADInternals Teams functions I noticed an interesting thing: I was able to edit and delete chat messages using AADInternals as a guest even when it was not allowed.

I agree however that the rest of the article doesn't really make any attempts to show a server-side issue.

oarsinsync2• 6 years ago

Exactly this. This is a situation where user input is only being sanitised client-side, not server-side. That's what's being (poorly) reported.

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.

Groxx• 6 years ago

Yeah, this seems equivalent to "people who have rooted their phones can take secret screenshots of your snapchats!"... which is solidly on the "well yeah, obviously" side of the security-outrage boundary.

If it does change server data, yea - significant news. But that doesn't seem to be implied, except by omission of a claim that it does not.

chmod775• 6 years ago

He claims there are no server-side checks, but fails to demonstrate that this is the case.

admax88q2• 6 years ago

Unfortunately I feel like this is the new standard for security "researchers."

Bug bounty programs and flashy brand name vulnerabilities have created this ecosystem where lots of security "researchers" publish long blog posts about so called "vulerabilities" they have discovered, hyping them up to be way more than they are. In hopes of getting bug bounties or hired as contractors I assume.

I had to unsubscribe from reddit's r/netsec and r/blackhat due to the number of borderline false posts like this.

There's like this intense pressure of people in security to network it seems. In the rare times I would post on netsec/blackhat to correct a misconception I'd get reached out to to connect on linkedin and whatnot.

Of course there is still some tremendous security researchers out there, like those at Google ProjectZero, but this industry seems to also attract a lot of borderline grifters.

tptacek• 6 years ago

There's nothing at all new about marginal security researchers making mountains out of molehills; it's a time-honored tradition. But you're miscalibrated if your threshold for good researchers is P0. There's plenty of bounty randos doing tremendous work as well.

lol768• 6 years ago

He's suggested on twitter the enabled client functions do actually work:

https://twitter.com/NestoriSyynimaa/status/13211346867149537...

(But hasn't offered any evidence to back this up)

darth_avocado• 6 years ago

Wow. But at the same time I'm not surprised. I interviewed with them and like all companies everywhere, it consisted mostly of a hiring practice where engineers ask you solving problems that aren't related to the job, for a lead engineering position. It also felt more like a place where interviewers wanted to show they were better. If only they paid more attention to what's actually needed.

jpxw• 6 years ago

So many people here not reading the article... This is a complete non-story.

w0mbat2• 6 years ago

Microsoft made exactly the same mistake years ago with SMB.

Once the 3rd-party open-source client, Samba, was written, it emerged that SMB access restrictions were only in the Microsoft SMB client software not the SMB server. Samba users could do whatever they wanted.

tupputuppu• 6 years ago

Is there a source for this? Can't find anything with a quick googling?

w0mbat2• 6 years ago

You know, this happened so long ago, in 1992, that there may be nothing for Google to find. I mean the web had been invented, but there wasn't much of it at that point.

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.

denysvitali• 6 years ago

Kind of related: I'm working on a FOSS version of Teams, starting from the Go library [0]. Check it out and contribute if you would like to see more open source Teams clients popping out (:

[0] https://github.com/fossteams/teams-api

Abusing Teams client protocol to bypass Teams security policies

Related Stories