https://m.heise.de/developer/artikel/Verwundbarkeitsanalyse-anhand-von-CPE-Dictionary-und-CVE-Feeds-4188341.html

Angeregt durch diesen Artikel möchte ich auf ein Problem in MS SharePoint (SP) Farm Solution Erweiterungen (full trust code) eingehen, welche heute durchaus noch am Markt vertreten sind, Probleme möglicherweise weiter in sich tragen, so dass der Trust nicht gerechtfertigt sein könnte. Diese Art der SP Erweiterung ist on premise auch weiterhin von MS SP voll unterstützt.

Die Rede ist hier vom sogenannten Double Hop Problem. SP unterstütze standardmäßig das NTLM System für die Benutzerauthentifizierung, aber auch die griechischen Höllenhunde können benutzt werden. Im Gegensatz zu Kerberos unterstützt NTLM keine Delegation mit Tickets.

Was passiert also hier? Ein Benutzer meldet sich per Web Browser am SP an, und kann nun seinen Berechtigungen nach Schalten und Walten. Im Hintergrund sind Services im SP integriert, welche bestimmte Aufgaben auf einem eigenen Host vom Benutzer unbemerkt angestoßen abarbeiten. Host heisst hier, SP Farm Member auf einem eigenen Windows Server OS.

Dh. nach der Anmeldung am System, stellt der annehmende Service fest, daß der angeforderte Service auf einer anderen Member Maschine gehosted wird. Somit wird die Anfrage dorthin weitergeleitet, es findet eine Delegation statt, und nur wenn hier Tickets vorhanden sind ist der angesprochene Service in der Lage, die Anfrage einem Benutzer zuzuordnen. Die Standard Services des SP sind nun alle mit einer Abprüfung auf den Benutzer ausgestattet. Somit kann kein unberechtigter Benutzer die Services für seine Zwecke verwenden, in diesem Fall wird ein entsprechender Fehlercode zurückgeben.

Leider ist diese Art der Implementation in Custom SP Services nach meiner Beobachtung nicht zwingend gegeben. Da die Software abwärtskompatibel ausgeliefert wird, aus Performance Gründen auf einen eigenen Member Host gesetzt wird, tritt das Problem selbst dann auf, wenn dieser sich selber per SP URI anspricht. In der mir bekannten Implementation wird hier bei unbekanntem Benutzer schon mal im SP auf System impersoniert, um dann weiter zu prozessieren.

Solange alles ohne unlautere Absichten im SP Kontext abläuft tut das System seinen Dienst.

Nur sind die SP Webservice Endpunkte per se offen für den anonymen Zugriff, um eine kontraktgemäße Schnittstellenbeschreibung zu liefern und die Kommunikation auszuhandeln. Somit sind hier bei Kenntnis der Datenlage beliebige Manipulationen des gesamten SP && PM Systems denkbar.

Die in der Anfangszeit 2007/2010 implementierte Lösung hat sich an dieser Stelle spätestens mit  den Versionen 2013/2016/2019 keinen Gefallen getan. Zusätzlich zu der verwendeten late binding activeX Technologie der domainspezifischen Lösung wurden mehrere PR Anfragen mit Unverständnis für die Problemsachlage abgewiesen.

Das sogenannte SP Farm Solution Model birgt also nicht nur die Stabilität von SP beeinflussendem InProcess Ablaufschema in sich, auch Sicherheitsanforderungen müssen nicht mehr mit der Papierform des eigentlichen SP Produktes übereinstimmen.

Was bleibt als Fazit?

Ideal sind also SP Systeme, welche on premise like SPonline betrieben werden. Dh. sie sind immer auf dem aktuellen Security Patch Level, Erweiterungen und Webparts basieren auf dem SPFx und gehosteten csom apps. Sehnlicher Wunsch wäre eine in place Migration-Möglichkeit von Version zu nachfolgender Version. Aber leider ist dieses Ideal häufig nur Wunschdenken, aber träumen kann ja nicht verboten werden!

Comments


Comments are closed