8 ms·
Abusing Teams client protocol to bypass Teams security policies
- A_No_Name_Mouse 6y agoI would have expected a responsible disclosure timeline, but it looks like he didn't report this to MS
- tuco86 6y agoI'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 6y agoIt 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.
- tuco86 6y agoThere 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.
- kube-system 6y agoResponsible 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.
- Nullabillity 6y agoThe 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.
- kube-system 6y agoThat'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.
- tyre 6y agoI’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 6y agoMy 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.
- corndoge 6y agoReading 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.
- tyre 6y agoPermissions 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 6y agoI'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.
- AshamedCaptain 6y 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 6y agoEnterprise 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 6y agoIn 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 ;)
- Quarrelsome 6y ago150 separate HTTP requests on startup? That seems quite a lot. I'd guess its smth multiplied by the number of teams you have?
- wizzwizz4 6y agoPerhaps, 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 6y agoAs 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.
- Quarrelsome 6y 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 6y agoI would say it does.
- lifeisstillgood 6y agoI 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.
- Quarrelsome 6y ago
- remote_phone 6y agoIf 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.
- koluna 6y agoThat’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_phone 6y agoThis 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.
- koluna 6y agoHow is this a security risk for your therapist?
- wizzwizz4 6y agoThis 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.
- koluna 6y agoThat’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.
- Krasnol 6y agoIs there anything the community here can recommend besides Slack?
- sailfast 6y agoI'm a big fan of Mattermost.
- gaogao 6y agoMattermost is a fairly good open source alternative.
- Krasnol 6y agoAh yes, I've heard about that one before. I'll check that out. Thank you.
- devthrowawy 6y agoMattermost seems pretty to-the-point. Really not getting what's so hard about chat with some basic formatting.
- MaxBarraclough 6y agoI haven't tried it, but Element is a Free and Open Source alternative. https://en.wikipedia.org/wiki/Element_(software) https://en.wikipedia.org/wiki/Element_(software)
- Krasnol 6y agoI 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.
- rkangel 6y agoFor purely text chat, at a previous company we used Zulip. I still think that is the best implementation of 'topics' (like threads in slack).
- corndoge 6y agoDid 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.
- prepend 6y agoSeems 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 6y agoI’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 6y agoAgree. 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 6y agoYip 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.
- deleted 6y ago[deleted]
- darth_avocado 6y agoWow. 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 6y agoSo many people here not reading the article... This is a complete non-story.
- w0mbat 6y agoMicrosoft 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 6y agoIs there a source for this? Can't find anything with a quick googling?
- w0mbat 6y agoYou 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 6y agoKind 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 https://github.com/fossteams/teams-api