Microsoft repareert lek in Teams dat accountovername via domeintakeover toeliet

Microsoft heeft een lek gerepareerd in werkplatform Teams waarmee aanvallers alle accounts in een subdomein konden overnemen door een bestand te sturen. Het lek zat in zowel de desktop- als de webversie.

Het lek werd ontdekt door beveiligingsbedrijf CyberArk. De onderzoekers ontdekten dat Teams-accounts binnen een groep over te nemen waren door voor het daarvoor gebruikte domein een authenticatietoken te laten genereren. Telkens als Teams wordt geopend, wordt een nieuw, tijdelijk toegangstoken gegenereerd. Daarbij worden restricties opgelegd over wie kan inloggen via cookies. Een van die cookies werd doorgestuurd naar subdomeinen van teams.microsoft.com. Dat subdomein was kwetsbaar voor een takeover, ontdekte CyberArk.

Doordat het subdomein kon worden overgenomen, konden de aanvallers authenticatietokens stelen als gebruikers naar het subdomein werden geleid. Dat kon bijvoorbeeld door hen op een geïnfecteerde link te laten klikken. De onderzoekers vonden echter ook een manier om een gif-bestand te versturen waarmee het authenticatietoken automatisch kon worden gegenereerd en doorgestuurd naar het subdomein. Daarvoor hoefden gebruikers de gif alleen maar te bekijken. Het was vervolgens mogelijk om het token te stelen van iedere Teams-gebruiker die het bekeek. Hoewel CyberArk het alleen over gifs heeft merkt tweaker seba op dat de aanval met iedere soort bestand kan worden uitgebuit.

Het lek zat in de webversie en de desktopdownload van Teams. CyberArk meldde het lek een maand geleden aan Microsoft. Het bedrijf heeft de kwetsbaarheid inmiddels gerepareerd. Volgens Microsoft zijn er geen aanwijzingen dat het lek actief is misbruikt.

Reacties (54)

[seba]

Waw, dit artikel slaat de bal compleet mis:
- Er is helemaal geen geinfecteerd gif bestand
- Dat het een .gif is, maakt eigenlijk zelfs niets uit
- De gif laat helemaal geen subdomain takeover toe.

Je moet zelf een subdomein takeover geregeld krijgen (dit kon in dit geval mogelijk zijn op enkele teams subdomeinen door oude CNAME DNS records naar andere domeinen die niet meer bestonden).

Als je een afbeelding laad in teams, vanaf een teams subdomein, stuurt microsoft authenticatie cookies hiernaar toe, om te checken of een persoon die afbeelding mag zien of niet.
Dit kan eender welke afbeelding zijn (.jpg is even goed als een .gif) en er moet helemaal niets geinfecteerd aan zijn. Gezien de eerdere subdomein takeover, gaat de aanvraag dus naar jou server en krijg je de authenticatie cookies in handen.

edit: artikel is intussen aangepast en nu wel correct.

[Reactie gewijzigd door seba op 23 juli 2024 08:22]

[TijsZonderH]

Ik twijfelde erg over wat je zei over die gifs maar volgens mij heb je inderdaad gelijk. In de bron wordt zo expliciet over gifs gesproken (ook in hun PoC) en nergens genoemd dat het gaat over alle afbeeldingen dat ik er ten onrechte vanuit ging dat het alleen over gifs ging. Tbh weet ik ook niet genoeg over de verschillen tussen jpg's en gifs om dat onderscheid te maken maar ik weet dat er in het verleden aanvallen zijn geweest waarbij code in een gif is verstopt - onterechte aanname mijnerzijds idd. En wat betreft de takeover, dat staat er inderdaad wat ongelukkig, ik pas het stuk aan. Thanks!

[seba]

Ja, de bron heeft ook best een clickbait titel en hun lang verhaal over gifs doet er niet zoveel toe.

Nog wat info over de domein takeover:
Je hebt een subdomein.teams.microsoft.com, die wijst naar een ander domein (vb. oud-teams-domein.com ). Dit domein is echter niet geregistreerd. Waarschijnlijk was het ooit wel geregistreerd, en heeft men bij microsoft vergeten die DNS record weg te halen.

Dat maakt dat als ik nu oud-teams-domein.com registreer, ik mensen via subdomein.teams.microsoft.com naar mijn server kan sturen (bijvoorbeeld door een afbeelding te hosten en die in een teams conversatie te zetten). Hierbij zend de browser mij de authenticatie cookies, omdat die ook geldig zijn voor dat subdomein.

[Reactie gewijzigd door seba op 23 juli 2024 08:22]

[Henk Poley]

Patch is al van 20 april (1.3.00.9267). Dus waarschijnlijk heb je 'm al geïnstalleerd staan. Verder top om de bug even hier te melden.

[Sennie121]

De versie die ik nu heb (via de MSI) is 1.3.00.8663. Loopt de MSI achterop in het versie nummer? Op een VDI werkt de update functie jammer genoeg niet.

[johnkeates]

De MSI en de VDI install gebruiken gewoon de AppData install, maar je hebt inderdaad kans dat je update niet door komt als je VDI omgeving AppData in de vriezer heeft staan; als je dan herstart of uitlogt/inlogt ben je terug bij af.

[virtualpimp]

Teams for Virtualized Desktop Infrastructure installeert Teams juist niet in de AppData, maar in Program Files.

[johnkeates]

Ik dacht dat die nog steeds de launcher en package wel centraal installeert maar at runtime alles gewoon op AppData dumpt en daar verder gaat.

[JvZ]

Ik zie vaak dat het download linkje op de pagina die virtualpimp hieronder/boven aangeeft achter loopt t.o.v. de laatste versie. Ik pas vaak het linkje handmatig aan naar het laatste versienummer om de laatste versie te kunnen downloaden voor onze VDI/xenapp omgeving.

En inderdaad de installatie voor VDI gaat naar program files zolang je ALLUSERS=1 meegeeft met de msi installatie.

[Sennie121]

Ah thanks! Dat is een goede oplossing inderdaad. Ze mogen alleen wel wat duidelijker aangeven wat de versie nummers zijn. Dat had iemand op de MSI pagina al als reactie gegeven.

En inderdaad met ALLUSERS=1 geïnstalleerd zodat deze in de Program Files komt te staan.

[JvZ]

ik lees net dat ze het hebben aangepast, je moet nu 2 parameters meegeven die 1 letter van elkaar afwijken.
Per-machine installation

msiexec /i <path_to_msi> /l*v <install_logfile_name> ALLUSER=1 ALLUSERS=1

[LongBowNL]

Bij mij was hij nog niet geïnstalleerd. Een handmatige druk op de updateknop heeft geholpen.

[SinergyX]

Dus de 'exploit' zat helemaal niet in Teams, maar in 1 van DNS records.

Microsoft quickly deleted the misconfigured DNS records of the two subdomains, that were exposed and could be taken over

Dat was de voorwaarde om uberhaubt (en helemaal geen 'geinfecteerde' gif) deze hele trigger te krijgen, Teams was 'toevallig' een manier om dit te misbruiken, DNS gefixed, einde oefening.

[telenut]

Gaan we nu ook overal lezen dat Teams af te raden is of verboden is omdat er een lek heeft in gezeten?

[fapkonijntje]

Er is een groot verschil tussen een bug en crap by design. Waar men bij Zooom over valt is dat ze rare dingen deden, zoals zelf aangeven dat er E2E encryptie zou zijn geweest, wat helemaal niet zo is.

[telenut]

Waar meeste mensen over vallen bij zoom is het feit dat iemand plots porno in beeld bracht, of een lul tekende in de annotaties. Iets wat bij elk videosharing programma kan...
Ook dat er accounts gehackt zouden zijn terwijl het hergebruikte wachtwoorden zijn. Ook mogelijk bij andere platformen.
Dat ze de term E2E encryptie misbruiken, daar hebben enkel tweakers een probleem mee (en ergens wel terecht natuurlijk)
Maar ook alle andere platformen hebben dit niet!

Enige wat wel is op te merken: hun backdoors en creatieve manieren om OS beveiliging te omzeilen in het verleden was niet proper.

[Anoniem: 14842]

Je krijgt een erg lage score, maar je hebt best een punt.
Een van de grootste issues was dat de room naam (zo noem ik het maar even) in beeld was terwijl je een videoconference had. Maar vanuit de gebruiker is dat natuurlijk heel handig: iemand stuurt een whatsapp naar een collega die al in de meeting zit: wat is het meeting id? En hop: je zit er in! Dat gebruikers er dan geen wachtwoord op zetten is toch wel echt hun eigen domme schuld.

Ik weet veel meer meeting platforms (waaronder Cisco) waarbij er vaak geen wachtwoord op een meetingroom zit. Om de doodsimpele reden dat dit veel makkelijker is. En de kans op misbruik (inbreken in een lopende meeting) is erg klein. Gebeurt het wel: maak een andere meetingroom aan of zet er een wachtwoord op.

Ik moet wel zeggen: qua werkwijze heb ik niet veel vertrouwen in Zoom, qua verleden ook. Maar goed: Cisco en Microsoft zijn wat dat betreft ook niet alles. Nextcloud talk dan maar, gewoon zelf hosten mét e2e encryptie!

[telenut]

Naar gebruiksgemak valt zoom in elk geval enorm mee merk ik op. Je moet ook rekening houden met de eindgebruikers.... De web based opties zijn soms nog eenvoudiger, maar hebben ook beperkingen.
De mogelijkheden binnen teams zijn wel enorm heb ik al gemerkt. En voor een zeer zachte prijs ook...

Security opties die er onlangs zijn bij gekomen zijn ook goed (room kunnen afsluiten, en in meeting bepaalde settings kunnen aanpassen, chat uit , delen uit enz...)

Maar de topreden om het te gebruiken: meer dan 10 personen gelijktijdig in beeld is geen enkel probleem! En ook de reden waarom we de mensen bij ons niks anders kunnen verkopen... We pushen teams, maar ze willen het niet, ze zien maar 4 anderen... ze vinden de instellingen niet terug... het is weer iets nieuws want ze hadden skype al...

[sidelo]

Microsoft luistert idd wel Teams wordt nu geüpdatet naar 9 personen gelijktijdig.
Daarbij is Zoom echt iets anders dan Teams.
Teams is veel meer een werk omgeving waarbinnen je ook kan communiceren terwijl zoom een communicatie middel is.
Als je teams alleen pushed op communicatie is het lastig om het succesvol te krijgen als je mensen op een andere manier leert samenwerken gaat het vliegen.

[d3burt]

Jitsi (https://jitsi.org/) is gratisch, heeft een open source server, en heb je daar geen zin in, dan kan je de meeting URL van Jitsi zelf gebruiken, of één van de vele beschikbare servers (bijvoorbeeld https://jitsi.nluug.nl/, altijd wel één in de buurt).

Trouwens net als de meeste meeting software standaard geen wachtwoord op een meeting room, maar dat is echt aan de gebruiker...

[Unsocial Pixel]

Dus stel ik heb gewerkt bij de Russische, noord koreaanse en de chinese geheime dienst en er is bekent dat ik enorm fan ben van dataharken en verkopen,, nu dit is 10jaar geleden en ik kom op het briljante idee een app te maken die keepyourdatasafe heet,, vertrouw je doe app na het lezen van die credentials? Dat ik vroeger wat misstapjes heb gemaakt moet geen verschil geven toch?

[Bender]

Volgens Microsoft zijn er geen aanwijzingen dat het lek actief is misbruikt.

Wat houd "actief" misbruikt toch in?

Dat het enkel als test misbruikt is?
Dat het niet op grote schaal gebruikt is? Dat er dus aantallen aan verbonden zijn, zo ja hoeveel?

[FireDrunk]

Dat dus alleen CyberArk dit voor elkaar heeft gekregen, en Microsoft in de logs alleen CyberArk is tegen gekomen, en niemand anders.

Dit soort dingen zijn voor Microsoft relatief makkelijk in de logs terug te zoeken. Ik heb wel eens met Microsoft Support gezeten over Authenticatie Tokens, en die jongens hebben hun request logging en debugging op dit vlak best goed voor elkaar

[Bor]

Dat dus alleen CyberArk dit voor elkaar heeft gekregen, en Microsoft in de logs alleen CyberArk is tegen gekomen, en niemand anders.

Dat hoeft niet zo te zijn. Actief misbruik betekent dat men het lek uitbuit voor niet legitieme doelen; (gerichte) aanvallen.

Het is in theorie mogelijk dat het lek ook door een andere security onderzoeker is gevonden welke het bijvoorbeeld aangemeld heeft.

[FireDrunk]

Correct, dat was wat ik bedoelde, dat ze geen kwaadaardig gebruik hebben kunnen constateren door iemand anders dan CyberArk

[witchdoc]

Voor één klant geloof ik dat best, maar om dit soort troep te gaan cross-referencen uit AL de logging van AL je klanten?
Ik ben geen expert, maar mij lijkt dat slagzinnetje "geen aanwijzingen dat het lek actief is misbruikt" eerder marketing bullshit. Het zegt namelijk totaal NIKS dankzij die 'geen aanwijzigingen'.
Als ik namelijk niks/weinig onderzoek, zal ik vast ook geen aanwijziging vinden.

[woutertje]

Het probleem zat hem in de overname van specifieke subdomeinen. Er waren een aantal subdomeinen onder teams.microsoft.com geCNAMEd (CNAME is als het ware een alias) naar een verlopen ander domein. Dat verlopen domein is door CyberARK geregistreerd.

Het hele lek is overigens niet afhankelijk van GIF, heeft ook niets met GIF ansich te maken. Het probleem zit hem in het vanaf een externe bron (de overgenomen specifieke subdomeinen) inladen van plaatjes. Het had dus ook een JPEG, of een PNG kunnen zijn.

Er is onderzoek door Microsoft gedaan, dit waren de enige fout geconfigureerde (dat wil zeggen: er bestonden subdomeinen met een CNAME naar een verlopen ander domein), subdomeinen. Daarom kunnen zij er vrij zeker van zijn dat in ieder geval dit lek niet misbruikt is. Als een andere partij dit probleem immers eerder gevonden had, dan hadden zij het domein moeten registreren, dat zou eenvoudig en publiek te zien zijn geweest.

[witchdoc]

Kijk, Waarom zeggen ze dat niet ipv zo'n vaag marketing dingetje dat dus letterlijk nul garanties geeft.
Ja ik snap het wel.. precies omdat het geen garanties geeft.

[fruitbakje]

Ook omdat het grootste gedeelte van de gebruikers van Teams geen idee heeft wat bovenstaande betekent.

[johnkeates]

Het grootste gedeelde van de Teams gebruikers weet niet eens dat ze Teams gebruiken of waarom ze het gebruiken en krijgen gewoon iets van de MSP of IT manager doorgeduwd ;-) Aan de andere kant: dat soort gebruikers lezen dit ook niet, dus de vraag is dan: voor wie was het geschreven/bedoeld? Misschien het type gebruiker dat net genoeg weet voor gebruik en net niet genoeg weet voor de rest?

[nstubbe]

Microsoft is gekend voor hun zeer extensieve logging en het serieus nemen van security issues. Je kan er vanuit gaan dat ze hun huiswerk gedaan zullen hebben en dat ze eerlijk gaan disclosen als er verdere problemen waren. Er zijn daar volledige teams fulltime in dienst die enkel en alleen bezig zijn met het analyseren van logs en het proberen te vinden van uitschieters.

Voor één klant geloof ik dat best, maar om dit soort troep te gaan cross-referencen uit AL de logging van AL je klanten?

Als je weet waar je achter zoekt, dan moet toch toch prima gaan? Zo niet dan kan je evengoed geen logs hebben. Het hele punt van logging is dat je een overzicht over heel je systeem kan behouden.

[witchdoc]

Ok, laat dat mog waar zijn, zoals gezegd, ik ben geen expert.
Waarom dat stomme zinnetje erbij. Als ze zo'n perfecte logging hebben, zopuden ze toch makkelijk moeten kunnen zeggen 'dit jaar hebben we géén misbruik gehad'.

Nogmaals, dat éne zinnetje geeft hen extreem veel ruimte.. Van 'er is geen probleem'tot 'we hebben onze logs niet bekeken'. Beide situaties passen nu perfect in hun uitleg.
En als je je antwoord zo dubbelzinnig maakt, dan heb ik er gewoon geen vertrouwen in dat het ook effectief degelijk is onderzocht of er verdere inbreuken geweest zijn..

[FireDrunk]

Er is een verschil tussen, niet loggen en niks zien, en alles loggen en er reactief door de logging van het afgelopen jaar kijken (wat jij hier aanhaalt). Wat microsoft ook nog kan doen, is een bepaalde periode met heuristics kijken of dit *gedrag* waargenomen wordt. Dus:

1) CyberArk meldt dit probleem (bij wijze van spreken, 6 maanden geleden)
2) Microsoft patched het lek, en schrijft in een heurisics file op hoe pogingen om dit te misbruiken er uit zouden zien.
3) Ze laten die heuristics op alle logging die ze hebben los, en zien niks.
4) Ze laten de heuristics los op alle logging die ze doen (ook die niet opgeslagen wordt), en als het geflagged wordt, slaan ze het op, zo niet, droppen ze de logs (dat is wat heel vaak gebeurt).
5) Ze zien in het proactief scannen van de logs geen misbruik, dus droppen ze de heuristics, want het is al gefixt (of niet, maar checken op een bug die je gefixt hebt, is wat duur ).

[Reactie gewijzigd door FireDrunk op 23 juli 2024 08:22]

[Scriptkid]

Waarom zou je, als er een domain take over nodig is van een zeer specifiek domein war de cname naar verwijst heb je 0 logs nodig zolang niemand dat domein heeft gehad. En dat blijkt dus ook het geval te zijn.

[_Pussycat_]

Soms zegt MS wel dat een lek actief misbruikt wordt. Tenminste bij hen bekent het dus iets (natuurlijk is de vraag hoeveel % ze meekrijgen).

[supersnathan94]

een bedrijf als MS zal op dergelijke services en dienstverlening wel een logaggregator hebben zitten (stndaard in Azure aanwezig bijvoorbeeld) zodat je makkelijk centraal door die logging kan query-en.

[Anoniem: 420148]

Als je als bedrijf je eigen cloudplatform met miljoenen servers, logsoftware, ML-software en data warehousing hebt, wil ik best geloven dat je een paar miljoen logs op rare dingen kunt onderzoeken. Het is niet alsof ze dit op een servertje ergens op zolder hoeven te proberen.

[Blokker_1999]

Dat er geen meldingen bij hen zijn binnengekomen die gekoppeld kunnen worden aan dit lek en dat zij in de logs waar zij over beschikken ook geen indicatie hebben gezien dat het lek misbruikt wordt.

[sidelo]

Ik kan nergens vinden dat ms dit zo gezegd heeft.
Het enige wat je als reactie online kan vinden van MS is: "While we have not seen any use of this technique in the wild, we have taken steps to keep our customers safe"

[iRinze]

Wat ik mijzelf afvraag bij dit soort lekken. Hoe in de vrede kom je hierachter?

[n9iels]

Ik vind dit soort dingen ook altijd super fascinerend. Hier kom je alleen achter door een lange tijd rond te poken en verschillende dingen te proberen. Deze video geeft een beetje een beetje inzicht in hoe dat werkt: https://www.youtube.com/watch?v=E-P9USG6kLs

Dit is voor mij ook het absolute bewijs dat een pentest echt een must is bij belangrijke platformen. Op het werk hebben we ooit 3 verschillende een "security & assesment" scans laten uitvoeren op een website. Hier kwamen geen findings uit wat wij zelf redelijk verdachten vonden. Uiteindelijk een pentester gehuurd (oef... duur grapje) en die vond wel enkele findings die wat beter verstop waren, maar toch redelijk wat kwaad hadden kunnen aanrichten.

[Scriptkid]

Pen test is ook maar een check op best practise.

Beste is net als ms doet.

Red en blue teams die constand azure aanvallen en verdedigen in periodieke roelatie. Zo test je dus real live door je eigen hackers teams en defense teams tegen elkaar uit te laten spelen.

[Memori]

Nieuwschierigheid gaat ver. Het is veelal gewoon dingen proberen voor de lol omdat je bijv. met Developer Tools (F12 in browser) Network Tab iets interessants ziet.

[kaghy2]

Dat vraag ik me soms ook af, ik ben zelf niet thuis in het "hacken" maar ik vind het toch knap als ik het af en toe zo lees.

Echt knap van de persoon cq bedrijf die een lek of iets dergelijks vindt.

[Lennis]

Echt knap van de persoon cq bedrijf die een lek of iets dergelijks vindt.

Yep, met verstand van zaken en geduld kom je een end. Alleen moeten we ons wel realiseren dat er ook hele kundige personen/ organisaties met minder goede bedoelingen met exact hetzelfde bezig zijn, en die dat dan niet aan MS (of whatever) melden. :-)
Het blijft een eeuwige strijd...

[Scriptkid]

Meestal niet echt knap maar toeval. Zelf ook wel diverse dingen gemeld bij msresponse.

Meestal tijdens trouble shooten kom je in een situatie die je niet goed begrijpt en als jet dan technische gaat uitzoeken kom je er achter hoe het echt werkt, en dan ga je denken, maar ow kun je dan ook niet. En dan test je dat en vind je een security lek.

[Kees]

Het zijn geen nieuwe lekken of nieuwe hacktechnieken. De eerste stap hier was de subdomain takeover en daarna hoe images gedeeld werden.

[Scriptkid]

Een van die cookies werd doorgestuurd naar subdomeinen van teams.microsoft.com. Dat subdomein was kwetsbaar voor een takeover, ontdekte CyberArk.

Wat is dat nu weer voor onzin. Je kunt helamaal geen takeover doen van een subdomein beheerd door een bedrijf, zeker niet door een multinational.


Men bedoelt volgensmij dat er een cname naar een verlopen domein verwees. Hierbij hoef je dus niet eens in logs te kijken zolang niemand dat domein waar na verwezen werd heeft geregistreerd kan er nooit misbruik gemaakt zijn.

Fix is easy, domein weer registreren of cname ergens anders heen laten wijzigen. Beetje opgeblazen verhaal dus als je het mij vraagt

[CAPSLOCK2000]

Het zou niemand moeten verbazen dat gifbestanden gevaarlijk zijn, de naam zegt het duidelijk: gif!

[kaghy2]

Als dit Reddit was, had ik je een upvote gegeven...

Bij deze dan maar een virtuele upvote, now get out .

[COW_Koetje]

Ik snap niet dat als je een grapje maakt (ook al geef je dit expliciet aan) dit meteen gedownvote wordt. Ik heb nergens in de regels gelezen dat humor niet geoorloofd is. Als het relevant is tot het topic hoeft niet iedereen zo azijnpisserig te reageren.
In tegenstelling tot complete derails zoals laatst nog een hele (feitelijke foute) discussie over mondkapjes die wel een +3 krijgt op een topic dat niet relevant was.

Mocht ik iets gemist hebben over humor en voting dan please show me.

[kaghy2]

Oh ik downvote ook niet hoor, +1'tje van mijn kant.

Maar ook ik snap het hele gebeuren met downvoten niet ookal is het humor, maarja ook ik zal op sommige topics wel iets gemist hebben.