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.
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.
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.
I guess, personally it just feels like there is an uptick in security "researchers" making mountains out of molehills, or more common mountains out of literally nothing, such as this "vulerability."
This is akin to saying fakeroot gives you root capabilities, or claiming to get root by doing "export PS1='# '"
I never said P0 is my threshold, I just used them as an example of good security researchers. I don't doubt there are plenty of randos doing good work. I'm just finding the signal to noise ratio is getting worse.
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.
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.
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.
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.
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...
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.
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.
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.
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.
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.
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.
> and it's possible to argue it's a strategic necessity
I would argue its a strategic failure. Purely reacting to the competition is something that has led to countless Microsoft disappointments (e.g. Zune, Bing).
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.
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).
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.
Video calls through a browser seem really hard to do well. I think that's why so many video call systems like Zoom really push you to download and use their native client.
My kid's school issued Chromebooks for remote schooling and are using Zoom through the browser. It was so bad that I pulled out an old Macbook instead. The Zoom native client running on a 12 year old Macbook works way, way better than running in updated Chrome on a recent Chromebook.
That sounds more like an issue with Zoom and the Chromebook. :/ My ~8 year old desktop works great with video chat in Firefox.
Then again my 8 year old desktop has 32GB of RAM and it is amazing what throwing 32GB of RAM can do to solve problems.
I've actually used video chat in multiple web apps for years now w/o issue though. In theory almost every aspect of video chat should be offloaded to GPU, the browser should just be a dumb canvas to throw pixels at, if that isn't the case then something has gone wrong somewhere in a particular setup. :(
Have you compared it to using Hangouts? I have no problem with the in-browser video quality on Hangouts, and get even better quality using a direct P2P WebRTC link.
I think Zoom is doing its own streaming schengens in the browser with JS and not using the native WebRTC framework for video streaming. It's very possible that they made the web client experience deliberately poor so that they could sell you on downloading the native client, and then spy on you.
Yeah the Teams webapp supports screen sharing (and does it pretty well)! I particularly like the way Edge (and I assume Chrome) let you choose to just share a specific browser tab.
The calls are pretty limited in the Browser. You only have the speaker view with one person and can't use the gridview.
And firefox is completely blocked from doing any calls at all.
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.
Right, that's the sadness of it. IRC clients were lacking, and the "auth for free" that came with AIM/Yahoo (and now Facebook) made the difference.
It would have been 100x simpler to create a compelling GUI client for IRC (back in the day, they sort of exist now), than to build an entire new protocol, server infrastructure, and GUI client to support a branded and controlled chat. Never mind multiple competing and incompatible versions of same.
Conflicting interests, obviously. But as a technology, "chat" did not improve materially between 1990 and 2010 or so.
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.
I would not surprised. The MS Teams client here uses more RAM than all the other programs I have on my desktop, including but not limited to my desktop environment itself (Gnome) and Firefox with plenty of open tabs.
I haven't had the inclination to investigate, but I suspect it's something like a memory leak that eats up all the (16GB) RAM and then swaps the system to death. Maybe if I was patient enough I could get an alternative console prompt and poke around, but when you need to get back into that meeting....
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.
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.
> 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).
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.
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.
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.
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 ;)
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.
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.
"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.
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.
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.)
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.
The courteous thing to do to the users is to let them know ASAP so they can stop using vulnerable software, without letting the vendor cover up the problem.
That's not a practical solution for the vast majority of cases. Even slow vendors can patch vulnerabilities much quicker than most institutional users can migrate software. If we stopped using software any time a vulnerability existed, we wouldn't be using much software.
This is one of the reasons that responsible disclosure policies exist, and why they are widely adopted in the industry. It is balance of risk and resources.
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.
There is a difference between unintended yet inevitable bugs and negligence.
Deliberately cheapening out on security because security researchers generally hold to a responsible disclosure procedure is not in the users interest.
This is not one of those inevitable bugs. This is an indicator that there maybe security issues littered throughout the system because no one cares.
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.
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.
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.
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.
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 (:
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.
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.
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.
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.
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.
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.
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.
This isn't a security issue. Teams policies are basically “please don't talk in the $FOO channel, it's for $FOO messages only”; the actual access is done through Sharepoint. (Though make sure you're not using Channels for security; it's trivial to get into all the Channels in a Team once you have access to the Team.)
Also? Teams is a glorified website running in a (hopefully up-to-date) embedded version of Chrome. If they replace some of the scripts it requests with “redirect to this updated Teams client”, then by golly it'll do that, and server-side API changes won't matter in the slightest.
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.