Nieuws
image

Securitybedrijf onthult SAML-aanval die toegang tot cloud-apps geeft

dinsdag 21 november 2017, 16:55 door Redactie, 4 reacties

Securitybedrijf CyberArk heeft een nieuwe aanval onthuld waarbij er van een "golden SAML" gebruik gemaakt wordt om toegang tot clouddiensten te krijgen die het SAML 2.0 protocol als inlogmechanisme gebruiken. De naam verwijst naar het "golden ticket" in Windows. Hiermee kan een aanvaller een gecompromitteerde domeincontroller die is opgeschoond weer opnieuw compromitteren en meteen domeinbeheerderrechten verkrijgen.

Bij een golden SAML-aanval kan een aanvaller toegang tot elke cloudapplicatie krijgen die SAML-authenticatie ondersteunt, zoals Azure en Amazon Web Services, met elke gewenste permissie en als elke willekeurige gebruiker. SAML staat voor Security Assertion Markup Language en is een standaard om authenticatie- en autorisatiegegevens tussen domeinen uit te wisselen. Er wordt hierbij gewerkt met een serviceprovider, identiteitsprovider en de gebruiker.

Als een gebruiker wil inloggen op een applicatie zoekt de serviceprovider de identiteitsprovider om de gebruiker te authenticeren. Vervolgens genereert de serviceprovider een SAML-authenticatieverzoek en stuurt dat naar de identiteitsprovider. De identiteitsprovider authenticeert de gebruiker en genereert een SAML-token en SAML-response object. Het SAML-response object wordt naar de serviceprovider gestuurd, die het verifieert. Is het response object geverifieerd, dan wordt de gebruiker door de serviceprovider ingelogd.

Om een golden SAML te creëren moet een aanvaller over de token-signing privésleutel beschikken. De privésleutel signeert het object dat de identiteit en permissies van de gebruiker bevat. Vervolgens kan de aanvaller het object vervalsen en zich als elke gebruiker voordoen om ongeautoriseerde toegang tot de applicatie te krijgen. Om de aanval uit te voeren moet een aanvaller naast de eerder genoemde privésleutel ook over de naam en het publieke certificaat van de identiteitsprovider en gewenste rolnaam beschikken. Om de privésleutel en verdere informatie te verkrijgen moet de aanvaller toegang tot het Active Directory Federation Services (AD FS) account hebben.

Cyberark stelt dat de golden SAML-aanval geen gebruik maakt van een kwetsbaarheid. Om de aanval uit te voeren moet een aanvaller domeinbeheerderstoegang hebben. "Daarom wordt het niet door de leveranciers in kwestie opgelost", aldus het securitybedrijf. Cyberark heeft een nieuwe tool genaamd "shimit" ontwikkeld en uitgebracht die de golden SAML-aanval implementeert.

Image

Reacties (4)
21-11-2017, 17:56 door dmstork
Van wat ik er uithaalde hoef je niet direct Domain Admin rechten hebben, alleen rechten om de private key van token signing private key te kunnen achterhalen. Maar dan moet je al wel in het interne netwerk zitten (en niet in Perimeter/DMZ waar de proxy voor de ADFS Server zit). Default verlopen de certificaten na een jaar, maar dat kan natuurlijk aangepast zijn. Duidelijk is wel dat je die private key goed moet veilig stellen.
Verder gaf men aan dat ook MFA hier niet zal helpen, maar dat betwijfel ik een beetje of dat in ieder geval zo is. Ik dacht dat na ADFS authenticatie je alsnog in (bijvoorbeeld) Office 365 geconfronteerd kan worden met een MFA challenge (altijd of bijv. door Conditional Access). En ik vraag mij af of Identity Protection dit kan achterhalen en lokaal natuurlijk Windows Defender ATP (of hooks met andere AV producten).
22-11-2017, 07:12 door Password1234
Door dmstork: Van wat ik er uithaalde hoef je niet direct Domain Admin rechten hebben, alleen rechten om de private key van token signing private key te kunnen achterhalen.
Klopt.
Maar dan moet je al wel in het interne netwerk zitten (en niet in Perimeter/DMZ waar de proxy voor de ADFS Server zit). Default verlopen de certificaten na een jaar, maar dat kan natuurlijk aangepast zijn. Duidelijk is wel dat je die private key goed moet veilig stellen.
Als je Office365 gebruikt is er grote kans dat die server gewoon aan het internet hangt. Hopelijk zit de FW goed dicht en is de server van patches voorzien.
Verder gaf men aan dat ook MFA hier niet zal helpen, maar dat betwijfel ik een beetje of dat in ieder geval zo is. Ik dacht dat na ADFS authenticatie je alsnog in (bijvoorbeeld) Office 365 geconfronteerd kan worden met een MFA challenge (altijd of bijv. door Conditional Access).
In de packet die je door het Signing Certificaat haalt kan je gewoon het vlaggetje "mfa" aanzetten. Office365 slikt dat gewoon omdat deze immers dat certificaat vertrouwd.
En ik vraag mij af of Identity Protection dit kan achterhalen en lokaal natuurlijk Windows Defender ATP (of hooks met andere AV producten).
Ja, dat biedt wel enige toegevoegde waarde, en die kan dus ook realtime ingrijpen.
Naar mijn mening wel lastig te detecteren, dus alleen bij bv. onlogische "time travel" van individuele gebruikers, kan die gebruiker gedetecteerd worden. Maar je hebt de Key, dus op naar de volgende user. Iedere user vanaf een ander IP, anders val je ook daar door de mand.
22-11-2017, 08:24 door Anoniem
Wow, wat een nieuws! Als je toegang tot een privésleutel hebt, kun je berichten namaken en met een geldige digitale handtekening ondertekenen!!11oneoneeleven

/sarcasmoff
Best aardig, dat ze een tooltje gemaakt hebben om dat te automatiseren, maar de titel is echt puur clickbait. Dit is by design en gaat ook niet anders als je de rollen Identity Provider en Service Provider wilt splitsen. Dan moet de SP de IdP blind vertrouwen en dus als de IdP geowned is, heeft de SP een probleem.
22-11-2017, 10:23 door Anoniem
Het maakt blijkbaar niet uit wat voor bullshit je te melden heb als security bedrijf. Alles gaat als we maar iets kunnen publiceren. De nieuwswaarde van dit item zit m vooral in het feit dat men BS spuit ipv dat het gaat over een realistische aanval op basis van een ontdekte kwetsbaarheid...
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.

Zoeken
search
Certified Secure