Kwetsbaarheid Office 365

Onlangs vonden hackers een kwetsbaarheid in de SAML-implementatie van Office 365. De kwetsbaarheid maakte het mogelijk om toegang te krijgen tot de accounts en data van bedrijven die met hun eigen active directory (federated) op Office 365 zijn aangesloten. Al verhielp Microsoft het probleem razendsnel: het was niet de eerste keer dat de data van gebruikers door een authenticatiefout gevaar liep. Welke nieuwe kwetsbaarheden brengt een cloud-oplossing als Office 365 eigenlijk met zich mee? En wat lost het op beveiligingsgebied op?

De basis van deze kwetsbaarheid ligt bij het gegeven dat één partij de authenticatie uitvoert en een andere partij de dienst levert. Een clouddienst die afgenomen wordt door een enterprise werkt typisch op deze manier, maar er zijn ook andere scenario's die authenticatie en autorisatie splitsen, bijvoorbeeld omdat authenticatie juist geïsoleerd wordt geïmplementeerd van een businessapplicatie.

Isolatie van belangrijke diensten is een goed architectuurpatroon, of het nu gaat om interne automatisering of extern zichtbare ('internet-facing') automatisering. Het staat toe dat we impact isoleren, risico's spreiden, maatregelen kunnen focussen en complexiteit verlagen. Allemaal zaken die goed zijn voor de beveiliging. Er komt wel wat bij: deze componenten moeten verbonden worden en elkaar kunnen vertrouwen.

Vertrouwde verbindingen tussen verschillende diensten gebruiken in de context van een web applicatie is niet makkelijk. Je moet je als afhankelijke partij constant afvragen of je met de juiste dienst verbonden bent. Op het internet hebben we hier TLS voor, als de verbinding direct is. Maar juist in dit geval is dat niet zo. Authenticatie wordt via een re-direct in de browser van de klant gedaan.  Dus het mechanisme is in dit geval anders.

De klant authenticeert zich bij de authenticatiedienst en komt bij de afhankelijke dienst terug met een verslag daarvan, de SAML assertion. Als het goed is (en met SAML 2.0 is dat zo), dan is de assertion cryptografisch getekend en dus te controleren. Een medewerker van een bedrijf met Office 365 die zich meldt bij Microsoft wordt naar de authenticatiedienst van haar bedrijf gestuurd, alwaar zij op vertrouwde manier kan inloggen. Microsoft ontvangt de SAML assertion, checkt deze, bepaalt wie zij is uit de assertion en zet een Office 365 sessie op. De medewerker is nu ingelogd.

IAM3

Microsoft voerde de checkt niet goed uit. Het goede nieuws is: deze check is niet ingewikkeld. Ze hadden slechts zeven uur nodig om de check in productie te krijgen. Het slechte nieuws is: de potentiële impact is enorm! Eén kwaadaardige hacker kan zich voordoen als een willekeurige andere bekende klant. Maar dit kan niet ongestraft, want deze maskerade is wel in de logs van Microsoft terug te vinden. Ik geloof het daarom meteen als ze stellig kunnen zeggen dat er geen misbruik is geweest.

Moraal is: als je een dienst aanbiedt op het internet, check, check en dubbelcheck! Elke interactiestap met een andere dienst kan potentieel gemanipuleerd zijn. En doe dit zeker met de diensten waar je fundamenteel je beveiliging op bouwt.

 

Deel dit bericht via:Tweet about this on TwitterShare on LinkedInEmail this to someoneShare on FacebookShare on Google+Pin on PinterestPrint this page

Door de site te te blijven gebruiken, gaat u akkoord met het gebruik van cookies. meer informatie

De cookie-instellingen op deze website zijn ingesteld op 'toestaan cookies "om u de beste surfervaring mogelijk. Als u doorgaat met deze website te gebruiken zonder het wijzigen van uw cookie-instellingen of u klikt op "Accepteren" hieronder dan bent u akkoord met deze instellingen.

Sluiten