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/
