Hi Christopher, super Beitrag, Danke für die tolle Zusammenstellung.
Deinen Ausführungen kann ich nur zustimmen: Federated Authn+Authz ist kritisch (ich will nächstes Jahr mal eine Veröffentlichung zu DiD machen). ADS ist komplex mit den Beziehungen. SAML als Format ist kritisch [1], MSChap ist Murks [2], naja zu oAuth2 und OPIDC will ich nicht viel sagen. Und dito mit der Weihnachtszeit! mfg. --eh. [1] 19. DFN Tagung Hamburg [2] https://www.youtube.com/watch?v=qjBHTS6BKX4 > Am 19.12.2020 um 14:48 schrieb Christopher J. Ruwe via members > <[email protected]>: > > Hi, > > Herr Schneier [1] hat einen ausgesprochen interessanten Link auf ein > NSA Security Advisory [2] verteilt, das sich direkt auf die Solarwinds > Orion Problematik bezieht und wegen des sehr spezifischen Fokus auf > doch sehr direkt benannte on-site SSO-Systeme und deren Anbindung an > Cloud Systeme einige interssante Anhalts-Punkte bietet. > > Ich greife mal einige Anteile heraus. > >> In the first TTP, the actors compromise on-premises components of a >> federated SSO infrastructure and steal the credential or private key >> that is used to sign Security Assertion Markup Language (SAML) >> tokens. > > Da waren offenbar mehrere (ob Solarwinds auch oder nur deren Kunden > ist hier für die Überlegung irrelevant) nicht in der Lage, eine selbst > betriebene Komponente sicher zu betreiben - bitter, wenn es sich dabei > um _den_ Trust-Anchor für die komplette eigene Infrastruktur handelt. > > Wenn ich an mein kürzliches Erlebnis mit einer mittelständigen Bank > denke, die einzelne Systeme mit LDAP ohne TLS an das AD angeschlossen > hatte, vermutlich eher der Standard. Ob mein damaliger Bericht > diesbezüglich korrekt bearbeitet wurde, kann ich nicht bewerten; wenn > ich aber gefragt werden würde, vermutete ich angesichts des völligen > Unverständnisses der Verantwortlichen über die Auswirkungen eines > solchen Aufbaus eher, daß nicht. > >> Microsoft Active Directory Federation Services (ADFS)® is an >> identity federation technology used to federate identities with >> Active Directory (AD)®, Azure Active Directory (AAD)®, and other >> identity providers, such as VMware Identity Manager. > > Jetzt wissen wir auch, welche Systeme hauptsächlich angegriffen > werden. Daß die Firma Winzigweich als eine der ersten bereits vor > einer Woche dazu ausführlich ein Advisory publizierte [3], stützt > diese meine Vermutung. > >> By abusing the federated authentication, the actors are not >> exploiting a vulnerability in ADFS, AD, or AAD, but rather abusing >> the trust established across the integrated components. > > Na ja. Ob ich diesem Abstreiten folgen möchte, weiß ich nicht. > Unstrittig gehören die Bediener und Nutzer mit zum System. Ich > selbst habe noch kein AD aufgesetzt, wenn ich aber beobachte, wie > zusammengeschustert die AD-Systeme bei meinen Kunden aussehen, ist es > offenbar nicht trivial. > > Man muß sich schon die Frage stellen, ob ich als größerer Software- > Vendor eine Beurteilung der Komplexität meiner Produkte iVm der > marktüblichen Fachkompetenz vornehmen müsste. Ich kann auch nicht > kleinen Kindern hochperformante Elektrofahrräder für deren Schulweg in > die Hand drücken und dann, wenn sie sich dabei aus Versehen tot > gefahren haben, rechtfertigen, daß sei ja gar nicht mein Produkt > gewesen, sondern ein Bedienerfehler. > > Ich bin mir noch unschlüssig, aber aus dem Bauchgefühl heraus waren > die Sicherheitsvorfälle mit den heftigsten Auswirkungen in den letzten > Jahren alle mit entweder Microsoft Active Directory, Microsoft > Exchange oder Microsoft SMB verbunden. > >> Due to the popularity of ADFS, numerous actors target ADFS, as well >> as other identity providers trusted by ADFS (T1199),to gain access >> to cloud services,such as Microsoft Office 365. > > Nur wegen deren Popularität oder vielleicht auch wegen des Mismatches > der Komplexität der AD Federation und der Kompletenz der Bediener? Ich > habe mal eine AWS-Umgebung an das AD eines Kunden angeschlossen, das > war ein entsetzliches Hin-und-Her, weil ich erst im dreiunddrölfigsten > Versuch und nach Eskalation an deren Team-Lead die paar Parameter, die > ich zur Einrichtung brauchte, bekommen hatte und sich danach niemand > die Mühe machen wollte, daß mit mir ordnungsgemäß zu testen. > > Ich kann nicht Leuten "nur zur Selbstverteidigung" eine Knifte in die > Hand drücken, wissend, daß die Mumpel mit hoher Wahrscheinlichkeit in > deren eigenen Fuß (unangenehm wegen der Knochen) oder im A... (wenig > problematisch, meistens nur Fleischwunde, es sei denn bei Treffer > Zielmitte) landen wird. Oder in anderen Unbeteiligten ... > >> Consider using Azure Active Directory as the Authoritative Identity >> Provider >> >> By consolidating identity and access natively in the cloud, tenants >> relieve themselves from the burden of managing the federation of >> authentication and the on-premises service, and gain more of the >> protections that the cloud provider has in place, including system >> hardening, configuration and monitoring. The drawback of doing this >> is that SSO may not work across on-premises and cloud resources and >> the tenant must trust the cloud provider to host user credential >> information. > > Schöner Abschluß: Kunden sind zu doof, Software zu betreiben (nix > Neues). Dann gebt das lieber in die Cloud, selbst wenn das bedeuten > würde, daß Ihr die Fähigkeit on-premises völlig verliert, und dem > Cloud-Provider vertrauen müßt. > > Ausgesprochen unangenehm finde ich nun, daß es die NSA ist, die dieses > Advisory verteilt. Der letzte Absatz klingt für mich fast schon, als > sei die Aussage "liefert Euch lieber uns aus als den Russen oder Nord- > Koreanern". > > Ich möchte einen Punkt meiner Ausführungen aus dem November auf- > greifen, weil ich Christians Frage, ob es Keycloak auch "as a Service" > gebe, im Fokus meines Vortrags zu eng aufgefaßt habe. Ich kenne zwar > immer noch nicht "Keycloak as a Service", die ganzen Cloud Identity- > Systeme gibt es natürlich sehr wohl "as a Service". Im Hintergrund > verwenden die auch entweder SAML oder OAuth2/OIDC. > > Ungeachtet dieser Korrektur bleibe bei meiner Haltung, die ich auch > bei meinem Vortrag im November geäußert habe: Authn & Authz gehören > dann nicht in fremde Hände, wenn die Informationen, die ich damit > schütze, mehr als nur oberflächlich schutzwürdig sind. Dann muß ich > halt zu diesem Zweck Kompetenz beschaffen und vorhalten. > > Wenn der Deckungsbeitrag das nicht her gibt, dann ist die Schutz- > würdigkeit wahrscheinlich doch nicht so hoch. > > Euch allen viele Grüße und eine angenehme Weihnachtszeit, > -- > Christopher > > [1]: https://www.schneier.com/ > [2]: > https://media.defense.gov/2020/Dec/17/2002554125/-1/-1/0/AUTHENTICATION_MECHANISMS_CSA_U_OO_198854_20.PDF > [3]: > https://blogs.microsoft.com/on-the-issues/2020/12/13/customers-protect-nation-state-cyberattacks/ > > Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id 7E4034BE
