Einblicke in SharePointSharePoint-Sicherheitskonten

Pav Cherny

Inhalt

Anwendungspools und Sicherheitskonten
Ausführen von benutzerdefiniertem Code auf SharePoint-Servern
Dr. Jekyll und Mr. Hyde
Sicherheitskonten und Prozessisolation
Sicherheitskonten in der Konfigurationsdatenbank
Sicherheitskonten und Anmeldeinformationsschlüssel
Verstoßen Sie nicht gegen die Gesetze

Bei der Verwendung von SharePoint-Sicherheitskonten besteht ein hohes Risiko, dass unsichere Systemkonfigurationen erstellt werden, die die gesamte SharePoint-Umgebung gefährden können. Um Sie bei der ordnungsgemäßen Bereitstellung und Sicherung von SharePoint-Serverfarmen zu unterstützen, hat Microsoft umfangreiche Informationen und detaillierte Richtlinien veröffentlicht. Das Office SharePoint Server-Sicherheitshandbuch enthält beispielsweise mehr als 300 Seiten zur Planung und Implementierung von Website- und Inhaltshierarchien, Authentifizierungsmethoden, Sicherheitsrollen, Administrator- und Dienstkonten und vielen anderen Sicherheitsaspekten. Das Arbeitsblatt zu Windows SharePoint Services-Sicherheitskontoanforderungen bietet ebenfalls wichtige Informationen zu Sicherheitskontokonfigurationen. Wenn die Sicherheit für Sie eine wichtige Rolle spielt, sollten Sie unbedingt die Anweisungen in diesem Arbeitsblatt befolgen.

Das Konfigurieren von Sicherheitskonten kann jedoch selbst mit umfassender Dokumentation eine schwierige Aufgabe sein. Tatsächlich weichen die Standardeinstellungen von Einzelserverinstallationen von den Empfehlungen im Arbeitsblatt ab, und bestimmte Komponenten wie der in Windows SharePoint Services (WSS) 3.0 enthaltene E-Mail-Integrationswebdienst erfordern erweiterte Berechtigungen für den Server. Dies weicht nicht nur von den Microsoft-Sicherheitsempfehlungen ab, sondern steht auch in direktem Widerspruch zu bewährten Sicherheitsmethoden und dem gesunden Menschenverstand. Kritische Sicherheitskontokonfigurationen werden vom Tool „SharePoint 3.0-Zentraladministration“ ohne Warnungen angewendet, und Microsoft Baseline Security Analyzer (MBSA) erkennt die resultierenden Sicherheitslücken nicht. Daher bleibt es eine Herausforderung, eine SharePoint-Serverfarm zu sichern und ihre Sicherheit zu gewährleisten.

In diesem Artikel werden SharePoint-Sicherheitskonten unter die Lupe genommen, um Ihnen zu zeigen, wie eine unsichere Konfiguration einem Angreifer vollständige Kontrolle über alle Websitesammlungen und Websites verleihen kann. Dabei handelt es sich um ein etwas sensibles Thema. Einerseits möchte ich Ihnen helfen, die Sicherheitsanforderungen in Bezug auf SharePoint-Serverkonfigurationen zu verstehen. Schließlich müssen Sie sowohl die Stärken als auch die Schwächen Ihrer SharePoint-Umgebung kennen, wenn Sie sie effektiv sichern möchten.

Andererseits möchte ich potenziellen Angreifern nicht in die Hände spielen. Aus diesem Grund stelle ich zu diesem Artikel keine Arbeitsblätter oder benutzerdefinierten Tools zur Verfügung und beschränke Erläuterungen zum Quellcode auf grundlegende Themen, mit denen jeder professionelle ASP.NET-Entwickler vertraut sein sollte. Die Quellcodeausschnitte in diesem Artikel sollten Sie dabei unterstützen, Sicherheitsrisiken zu erkennen, aber Angreifern nicht helfen, sie auszunutzen. Selbst mit begrenzten Programmierkenntnissen sollten Sie mithilfe dieser Ausschnitte benutzerdefinierte ASP.NET-Seiten erstellen können, wenn Sie über Microsoft Office SharePoint Designer 2007 verfügen.

Eine Testversion von Microsoft Office SharePoint Designer 2007 ist online verfügbar. Ich empfehle Ihnen, eine Testumgebung nach Ihren eigenen Präferenzen zu konfigurieren, sie so gut zu sichern, wie Sie können, und dann die Codeausschnitte zu Überprüfungszwecken auszuführen. Mal sehen, wie sicher Ihre SharePoint-Websites sind!

Anwendungspools und Sicherheitskonten

Sicherheitskonten stehen im Mittelpunkt des Anforderungsverarbeitungsmodells von SharePoint. Sie definieren den Sicherheitskontext der IIS-Arbeitsprozesse, die die SharePoint-Webanwendungen ausführen. Wenn Sie eine SharePoint-Webanwendung erstellen, müssen Sie unter anderem einen Anwendungspool mit zugehörigen Sicherheitskonto-Anmeldeinformationen und eine SharePoint-Datenbank mit einer zugehörigen Authentifizierungsmethode angeben. Wenn Sie die Windows-Authentifizierung (empfohlen) verwenden, gewährt SharePoint dem angegebenen Sicherheitskonto automatisch dbOwner-Berechtigungen für die Inhaltsdatenbank, damit der IIS-Arbeitsprozess, der die SharePoint-Webanwendung ausführt, auf die in dieser Datenbank gehosteten Websitesammlungen und Websites zugreifen kann. Andernfalls müssen Sie explizite SQL Server-Anmeldeinformationen angeben.

In jedem Fall sind SharePoint-Websitesammlungen und -Websites virtuelle Konstrukte. Physisch entsprechen sie Datenbankdatensätzen. Wenn Sie den Kontonamen und das Kennwort für das Herstellen einer direkten SQL Server-Verbindung zur Inhaltsdatenbank kennen, können Sie unabhängig von den auf SharePoint-Ebene definierten Berechtigungen und Zugriffssteuerungen vollständigen Zugriff auf alle ihre Websitesammlungen und Websitedaten erhalten. SharePoint kann Ihren Zugriff nicht blockieren, da Sie eine direkte Verbindung zum Datenbankserver herstellen (siehe Abbildung 1). Das Sicherheitskonto ist daher ein ideales Ziel für einen Angriff.

Abbildung 1 Umgehen von SharePoint-Websitesammlungen und -Websites für den Zugriff auf Daten

Um Sicherheitsrisiken zu verringern, empfiehlt Microsoft, dass Sie separate Anwendungspools (und Sicherheitskonten) für Websitesammlungen mit authentifizierten und anonymen Inhalten konfigurieren und Anwendungen isolieren, die Kennwörter speichern oder bei denen Benutzer über umfangreiche Rechte für das Erstellen und Verwalten von Websites sowie für die Zusammenarbeit an Inhalten verfügen. Dem liegt der Gedanke zugrunde, dass bei Befolgen dieser Konfigurationsempfehlung ein Angreifer, der die Kontrolle über einen Anwendungspool erlangt, nicht implizit universellen Zugriff auf alle in der SharePoint-Farm gehosteten Daten hat. SharePoint-Websitesammlungen und -Websites in anderen Datenbanken sind nach wie vor unerreichbar, sofern Sie separate Sicherheitskonten für ihre zugehörigen Webanwendungen verwenden.

Microsoft führte das Konzept der Arbeitsprozessisolation auf Grundlage von Anwendungspools erstmals mit IIS 6.0 ein und gibt an, dass bei IIS seitdem kein einziges kritisches Sicherheitsrisiko aufgetreten ist. Dies ist sehr beruhigend, und Sie sollten daher in SharePoint-Farmen unbedingt Anwendungspools nutzen. Bedenken Sie jedoch, dass IIS-Websites und SharePoint-Webanwendungen nicht gleichgesetzt werden können. Während Sie IIS-Websites isolieren können, können Sie SharePoint-Webanwendungen nicht voneinander isolieren.

Echte Isolation besteht nur, wenn Websites keine Ressourcen gemeinsam verwenden. SharePoint-Webanwendungen haben jedoch immer Ressourcen gemeinsam, beispielsweise die Konfigurationsdatenbank der Farm. Wie in Abbildung 2 dargestellt, setzt die Erlangung der Kontrolle über ein SharePoint-Sicherheitskonto die Fähigkeit zum Zugriff auf die SharePoint-Konfigurationsdatenbank voraus. Diese Zugriffsmöglichkeit sollte Ihnen Unbehagen bereiten, wenn Sie Ihre SharePoint-Farm bereitgestellt haben, ohne ausreichend über den Schutz Ihrer Sicherheitskonten nachgedacht zu haben, insbesondere wenn Sie Websitesammlungen und Websites von verschiedenen internen oder externen Kunden in einer freigegebenen Umgebung hosten.

Abbildung 2 Beziehung zwischen SharePoint-Webanwendungen, Konfigurationsdatenbank und Inhaltsdatenbanken

Ausführen von benutzerdefiniertem Code auf SharePoint-Servern

SharePoint legt standardmäßig keine Sicherheitskontoinformationen offen. Zum Aufdecken der Details ist schädlicher Code erforderlich. Wie wir alle wissen, können Sicherheitsrisiken Angreifern das Hochladen von schädlichem Code ermöglichen, aber manchmal ist das Eindringen sogar noch einfacher.

Im einfachsten Fall könnte ein Angreifer in der Lage sein, sich lokal oder über Terminalserver bei einem SharePoint-Server anzumelden und schädlichen Code in den Ordner „%COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\TEMPLATE\Layouts“ zu kopieren. Beachten Sie, dass bei SharePoint dieser Ordner in jeder SharePoint-Website als virtualisierter Unterordner enthalten ist.

In einem anderen Szenario könnte ein SharePoint-Administrator unwissentlich schädlichen Code einschleppen, indem er eine benutzerdefinierte SharePoint-Lösung von einer fragwürdigen Quelle ohne ordnungsgemäße Tests und Codeüberprüfung bereitstellt. In Master- und Inhaltsseiten eingebetteter ASP.NET-Inlinecode ist ebenfalls bedenklich. Standardmäßig verarbeitet SharePoint keine serverseitigen Skripts, aber Benutzer mit Schreibzugriff auf die Datei „web.config“ einer SharePoint-Webanwendung können die Regeln für die Verarbeitung serverseitiger Skripts ändern. Sie müssen lediglich dem <PageParserPaths>-Abschnitt der Datei „web.config“ einen PageParserPath-Eintrag hinzufügen. Wie genau funktioniert der PageParserPath-Eintrag?

Angenommen, Sie erhalten einen Anruf von einem Entwickler, der SharePoint verwendet und sich darüber beschwert, dass er beim Entwickeln einer benutzerdefinierten ASP.NET-Seite die Fehlermeldung „Codeblöcke sind in dieser Datei nicht zulässig“ erhält. Sie suchen im Internet und finden die Lösung in einer Newsgroup oder auf einer Blogwebsite:

<PageParserPath VirtualPath="/*" CompilationMode="Always" AllowServerSideScript="true" IncludeSubFolders="true" />

Vielleicht ignorieren Sie die Sicherheitswarnungen, oder eventuell werden die Auswirkungen auf die Sicherheit nicht einmal erwähnt. Wie auch immer – Sie fügen der Datei „web.config“ diese Zeile hinzu, und alle sind glücklich, weil Sie das Problem gelöst haben.

Sie haben jedoch auch gerade unwissentlich die Möglichkeit geschaffen, beliebigen benutzerdefinierten Code mit voller Vertrauenswürdigkeit in ASP.NET-Seiten auszuführen. Wenn ein Angreifer jetzt eine schädliche ASP.NET-Seite hochlädt, ist die SharePoint-Umgebung gefährdet. Wie in Abbildung 3 dargestellt, ist es irrelevant, an welcher Stelle in einer Websitesammlungshierarchie ein Angreifer berechtigt ist, eine Seite hochzuladen – es kann eine harmlos aussehende kleine Teamwebsite sein. Der Angriff betrifft immer die Webanwendung und möglicherweise die gesamte Serverfarm, da sowohl auf die Inhaltsdatenbank als auch auf die Konfigurationsdatenbank zugegriffen werden kann.

Abbildung 3 Das Aktivieren von ASP.NET-Inlinecode kann die Sicherheit einer SharePoint-Webanwendung gefährden

Dr. Jekyll und Mr. Hyde

Wie erhält ein Angreifer also Zugriff auf Inhalts- und Konfigurationsdatenbanken, ohne explizit die Sicherheitskonto-Anmeldeinformationen zu kennen? Dies ist tatsächlich relativ einfach. Der IIS-Arbeitsprozess, der die SharePoint-Webanwendung ausführt, nimmt die Identität des SharePoint-Benutzers an und verwendet das resultierende Threadtoken für Zugriffsüberprüfungen. Dr. Jekyll kann beispielsweise auf alle SharePoint-Ressourcen zugreifen, auf die sein Sicherheitstoken zugreifen darf. Die SharePoint-Webanwendung verfügt aber auch über das Prozesstoken des IIS-Arbeitsprozesses, bei dem es sich um das Sicherheitstoken des SharePoint-Sicherheitskontos handelt.

Mr. Hyde erscheint, wenn Sie den Identitätswechsel durch Aufrufen der statischen WindowsIdentity.Impersonate-Methode und durch Übergeben eines Nullzeigers zurücksetzen (siehe Abbildungen 4 und 4a). Im Unterschied zu Dr. Jekyll hat Mr. Hyde direkten Zugriff auf die Datenbanken. SQL Server-Verbindungen und T-SQL-Abfragen steht nun nichts mehr im Wege.

Abbildung 4 SharePoint-Webanwendungen verfügen über zwei Sicherheitskontexte (zum Vergrößern auf das Bild klicken)

Abbildung 4a Code zum Abrufen der beiden Sicherheitskontexte einer SharePoint-Webanwendung

private string GetMrHyde() { string retVal = string.Empty; retVal = "Dr Jekyll is: " + WindowsIdentity.GetCurrent().Name + "<br>"; WindowsImpersonationContext impCtx = WindowsIdentity.Impersonate(IntPtr.Zero); retVal += "Mr Hyde is: " + WindowsIdentity.GetCurrent().Name + "<br>"; impCtx.Undo(); return retVal; }

Sicherheitskonten und Prozessisolation

Anwendungspools und Sicherheitskonten können Ihnen nicht beim Schutz von Websitesammlungen und Websites in einer Webanwendung helfen, die für die Ausführung von nicht überprüftem Code konfiguriert wurde. Ihr Zweck besteht darin, mittels Prozessisolation die Auswirkungen eines Exploit auf einer Website, der es einem Angreifer ermöglicht, auf dem Server Code für den Angriff anderer Websites einzuschleusen, zu verringern. Die Prozessisolation kann beim Erreichen dieses Ziels helfen, erfordert aber, dass Sie die anderen Websites in separaten Webanwendungen platzieren, die in Anwendungspools mit anderen Sicherheitskonten ausgeführt werden.

Sie müssen die Kontoanmeldeinformationen auf angemessene Weise schützen – andernfalls ist der Konfigurationsaufwand sinnlos. Eine einfache Möglichkeit dafür, dass diese vertraulichen Sicherheitsanmeldeinformationen geradewegs in die falschen Hände gelangen, besteht darin, Anwendungspoolkonten Zugriff auf die IIS-Metabasis zu gewähren, was zum Ausführen des Verzeichnisverwaltungsdiensts – eines Bestandteils des E-Mail-Integrationswebdiensts – erforderlich ist. Wenn das Anwendungspoolkonto Zugriff auf die Metabasis hat, kann ein Angreifer den Identitätswechsel umkehren und dann alle Kontoinformationen und Kennwörter als Klartext abrufen (siehe Abbildungen 5 und 5a). Die gesamte Serverfarm ist verloren, da der Angreifer jetzt die Prozessisolation umgehen kann, indem er unter der Identität eines dieser Sicherheitskonten schädlichen Code ausführt und SQL Server-Verbindungen zu allen Inhaltsdatenbanken herstellt.

Abbildung 5 Abrufen von Sicherheitskontoinformationen aus der IIS-Metabasis

Abbildung 5a Code zum Abrufen von Sicherheitskontoinformationen aus der IIS-Metabasis

private string GetMetabaseAppPoolIDs() { WindowsImpersonationContext impCtx = WindowsIdentity.Impersonate(IntPtr.Zero); string retVal = string.Empty; try { string metabasePath = "IIS://localhost/w3svc/AppPools"; DirectoryEntry appPools = new DirectoryEntry(metabasePath); foreach (DirectoryEntry appPool in appPools.Children) { switch (int.Parse(appPool.Properties["AppPoolIdentityType"].Value.ToString())) { case 0: // Local System retVal += "<br>" + appPool.Name + " (Local System)"; break; case 1: // Local Service retVal += "<br>" + appPool.Name + " (Local Service)"; break; case 2: // Network Service retVal += "<br>" + appPool.Name + " (Network Service)"; break; case 3: // Custom retVal += "<br>" + appPool.Name + " (" + appPool.Properties["WAMUserName"].Value + " [Pwd: " + appPool.Properties["WAMUserPass"].Value + "])"; break; } } } catch (Exception ee) { retVal = "Metabase " + ee.Message; } impCtx.Undo(); }

Wenn Sie an einer Verzeichnisverwaltungsdienst-Lösung interessiert sind, die keinen Zugriff auf die Metabasis erfordert, sollten Sie meinen Artikel SharePoint-Verzeichnisintegration vom September 2008 lesen.

Sicherheitskonten in der Konfigurationsdatenbank

Wenn Sie die Regel befolgen, Anwendungspoolkonten keine Administratorrechte und nicht einmal Lesezugriff auf die IIS-Metabasis auf Ihren SharePoint-Servern zu gewähren, führt der Code in Abbildung 5 lediglich zur Meldung „Zugriff verweigert“. Sicherheitskontoinformationen sind aber auch in der Konfigurationsdatenbank verfügbar, und Mr. Hyde hat, wie bereits erwähnt, Zugriff auf diese Datenbank.

Sie können weder SharePoint-Sicherheitskonten den Zugriff auf die Konfigurationsdatenbank verweigern, noch können Sie den Zugriff auf den Registrierungsschlüssel ablehnen, in dem die entsprechende SQL Server-Verbindungszeichenfolge gespeichert ist. Die Verbindungszeichenfolge funktioniert möglicherweise nicht sofort, wenn Sie SQL Server 2005 Express verwenden. Sie können aber die richtigen Datenquelleninformationen von der aktuellen SharePoint-Websitesammlung (SPContext.Current.Site.ContentDatabase.DatabaseConnectionString) ableiten, und der Name der Konfigurationsdatenbank entspricht dem Namen der lokalen Farm (SPFarm.Local.Name).

Leider halten diese kleinen Hürden keinen Angriff auf. Unabhängig davon, ob Sie SQL Server oder SQL Server Express verwenden, kann Mr. Hyde die in den Abbildungen 6 und 6a gezeigten Informationen abrufen. Beachten Sie jedoch, dass das Kennwort verschlüsselt ist. Daher ist der Angriff noch nicht vollständig geglückt.

Abbildung 6 Abrufen von Sicherheitskontoinformationen aus der Konfigurationsmetabasis

Abbildung 6a Code zum Abrufen von Sicherheitskontoinformationen aus der Konfigurationsmetabasis

private string EnumAppPoolAccounts() { string retVal = string.Empty; try { WindowsImpersonationContext impCtx = WindowsIdentity.Impersonate(IntPtr.Zero); string regConfigDB = @"SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Secure\ConfigDB"; RegistryKey keyConfigDB = Registry.LocalMachine.OpenSubKey(regConfigDB); string ConfigDB = (string)keyConfigDB.GetValue("dsn"); SqlConnection sqlConn = new SqlConnection(ConfigDB); sqlConn.Open(); SqlCommand sqlCmd = new SqlCommand("SELECT Name, Properties FROM Objects" + " WHERE ClassId = 'B8369089-08AD-4978-B1CB-C597B5E90F64'", sqlConn); sqlCmd.CommandType = System.Data.CommandType.Text; SqlDataReader sqlReader = sqlCmd.ExecuteReader(); while (sqlReader.Read()) { retVal += "<br>" + sqlReader.GetString(0); string appPoolXML = sqlReader.GetString(1); if (!string.IsNullOrEmpty(appPoolXML)) { XmlDocument xmlDoc = new XmlDocument(); xmlDoc.LoadXml(appPoolXML); XmlElement root = xmlDoc.DocumentElement; XmlNode ndType = root.SelectSingleNode("/object/fld[@name= 'm_IdentityType']"); if (ndType != null && ndType.InnerText.ToLower() != "specificuser") { retVal += " (" + ndType.InnerText + ")"; } else { retVal += " (" + root.SelectSingleNode("/object/sFld[@name='m_Username']").InnerText + " [Pwd: " + root.SelectSingleNode("/object/fld[@name='m_Password']").InnerText + "])"; } } } sqlReader.Close(); sqlConn.Close(); impCtx.Undo(); } catch (Exception ee) { retVal = ee.Message; } return retVal; }

Aber selbst ohne die Entschlüsselung von Kennwörtern sind Anwendungspools, die das gleiche Sicherheitskonto verwenden, bereits erkennbar. In Abbildung 6 verwenden beispielsweise die Anwendungspools „SharePoint Central Administration v3“ und „SharePoint-80“ das Netzwerkdienstkonto, und wenn „SharePoint-80“ die gefährdete Webanwendung ist, ist „SharePoint Central Administration v3“ ebenfalls gefährdet. Das entsprechende Sicherheitskonto ist das Zentraladministrationskonto, das über erweiterte Berechtigungen für den SharePoint-Server verfügt.

Obwohl es nicht für Standard-Webanwendungspools verwendet werden sollte, wendet der Konfigurations-Assistent für SharePoint-Produkte und -Technologien diese Konfiguration bei einer Einzelserverinstallation standardmäßig an. Daher ist es sehr wichtig, dass Sie die Sicherheitskontokonfiguration in Ihrer SharePoint-Umgebung überprüfen und bei Bedarf ändern. Weitere ausführliche Informationen zu diesem Thema finden Sie im Microsoft Knowledge Base-Artikel Ändern von Dienstkonten und Kennwörtern für Dienstkonten in SharePoint Server 2007 und Windows SharePoint Services 3.0.

Sicherheitskonten und Anmeldeinformationsschlüssel

Was ist das Besondere am Zentraladministrationskonto? Der wichtigste Aspekt besteht darin, dass das Zentraladministrationskonto im Unterschied zu Standard-Anwendungspoolkonten Zugriff auf den Registrierungspfad hat, unter dem der Anmeldeinformationsschlüssel zum Entschlüsseln der Kennwörter für Sicherheitskonten gespeichert wird.

Dieser Parameter und seine Standardsicherheitseinstellungen sind in Abbildung 7 dargestellt. Wie Sie sehen können, haben lokale Administratoren, die Gruppe WSS_RESTRICTED_WPG (die das Zentraladministrationskonto enthält) und das SYSTEM-Konto Zugriff auf diesen Schlüssel. Dies bedeutet, dass Ihre SharePoint-Webanwendungen weder Konten mit lokalen Administratorberechtigungen, noch das Zentraladministrationskonto oder das SYSTEM-Konto verwenden sollten. SharePoint-Webanwendungen sollten nicht auf den Anmeldeinformationsschlüssel zugreifen können.

Abbildung 7 Berechtigungszuweisungen für den Zugriff auf den FarmAdmin-Registrierungsschlüssel

Leider wird dadurch jedoch nicht gewährleistet, dass ein geschickter Angreifer weder den CredentialKey noch Kennwörter für Sicherheitskonten ermitteln kann – beispielsweise durch Stehlen des SYSTEM-Token, durch Kennwortentschlüsselung oder einfach dadurch, dass er schädlichen Code in Master- oder Inhaltsseiten einfügt, um den Anmeldeinformationsschlüssel an einen ungeschützten Speicherort zu exportieren, und dann darauf wartet, dass ein Benutzer mit lokalen Administratorberechtigungen auf die Website zugreift. Wie Sie sehen können, ist es wichtig, dass Sie ausschließlich überprüften Code auf Ihren Servern zulassen.

SharePoint-Ressourcen

	Website zu SharePoint-Produkten und -Technologien
	Windows SharePoint Services-TechCenter
	Windows SharePoint Services-Entwicklercenter
	Teamblog zu Microsoft SharePoint-Produkten und -Technologien

Die Problematik des Stehlens des SYSTEM-Token verdient eine ausführlichere Erklärung, da Sie diese Form von Angriffen verhindern können, wenn Sie es vermeiden, für Ihre SharePoint-Webanwendungen die integrierten Systemkonten wie „Netzwerkdienst“ zu verwenden. Cesar Cerrudo, Gründer und CEO von Argeniss, hat dieses Sicherheitsrisiko entdeckt und den Exploit auf der HITBSecConf2008 Deep Knowledge Security Conference in Dubai, Vereinigte Arabische Emirate, vorgeführt. Dabei hat er gezeigt, wie eine ASP.NET-Webanwendung, die unter dem Netzwerkdienstkonto ausgeführt wird, eine DLL in den Dienst des Remoteprozeduraufrufs (Remote Procedure Call, RPC) einschleusen und sich dann das Sicherheitstoken eines Threads im RPC-Dienst, der auf SYSTEM-Berechtigungsebene ausgeführt wird, aneignen kann.

Danach muss ein Angreifer nur das übernommene SYSTEM-Sicherheitstoken an die WindowsIdentity.Impersonate-Methode übergeben, um Zugriff auf den Registrierungsparameter „CredentialKey“ und andere geschützte Ressourcen zu erhalten. Microsoft hat das Sicherheitsrisiko bestätigt, sodass Sie die Verwendung des Netzwerkdienstkontos für Ihre SharePoint-Webanwendungen vermeiden sollten.

Verstoßen Sie nicht gegen die Gesetze

Die 10 unveränderlichen Gesetze zur Sicherheit wurden vom Microsoft Security Response Center vor langer Zeit veröffentlicht und sind heute noch immer gültig. Jesper M. Johansson hat vor kurzem eine dreiteilige Reihe mit dem Titel Neubetrachtung der 10 unveränderlichen Gesetze zur Sicherheit geschrieben. Sie sollten beim Entwerfen Ihrer SharePoint-Serverfarmen an diese Gesetze denken und zudem die SharePoint-Sicherheitsrichtlinien und -Arbeitsblätter für das Anwenden zuverlässiger Sicherheitskontokonfigurationen befolgen.

Kurz gesagt: Verwenden Sie sichere Kennwörter, gewähren Sie Sicherheitskonten keine erweiterten Berechtigungen für Ihre SharePoint-Server, ändern Sie Kennwörter häufig (einschließlich der Anmeldeinformationen für Farmen), und vergessen Sie nicht, dass es keine absolute Isolation zwischen SharePoint-Webanwendungen gibt, die Ressourcen gemeinsam verwenden – genauso wie es keine absolute Computersicherheit gibt. Ändern Sie außerdem nicht die Regeln für die Verarbeitung von Code auf dem Server, halten Sie nicht überprüfte Assemblys von Ihren Servern fern, und befolgen Sie beim Konfigurieren Ihrer Sicherheitskonten die Anweisungen im Arbeitsblatt zu Windows SharePoint Services-Sicherheitskontoanforderungen. Dann können Sie Ihre SharePoint-Umgebung vielleicht als einigermaßen sicher betrachten.

Wenn für Ihre Organisation jedoch eine strenge Trennung von Websiteinhalten erforderlich ist, empfiehlt es sich, dass Sie die entsprechenden Websitesammlungen in separaten Serverfarmen und möglicherweise in separaten Active Directory-Gesamtstrukturen und SQL Server-Umgebungen hosten.

Pav Cherny ist IT-Experte und Autor und ist auf Microsoft-Technologien für Zusammenarbeit und einheitliche Kommunikation spezialisiert. Seine Veröffentlichungen enthalten Whitepaper, Produkthandbücher sowie Bücher mit dem Schwerpunkt IT-Vorgänge und Systemverwaltung. Pav Cherny ist Präsident der Biblioso Corporation. Dieses Unternehmen ist auf verwaltete Dokumentations- und Lokalisierungsdienste spezialisiert.