Was sind die Sicherheitsrisiken mit cmdexec?

Question

Wir sind dabei, von SQL 2000 zu SQL 2005 zu migrieren. Wir haben Hunderte von DTS-Paketen, die das Entwicklungsteam mit SSIS nur ungern neu entwickelt.

Beim Migrieren dieser Pakete zu SSIS stehe ich vor einem Problem - viele dieser Pakete lesen aus Excel-Dateien.

Da meine Produktion Box 64 Bit ist, bin ich gezwungen, CmdExec Subsystem zu verwenden, um die 32-Bit-Laufzeit aufzurufen, diese Pakete auszuführen.

Meine Frage hier ist: Welche Sicherheitsrisiken bestehen bei der Verwendung des CmdExec-Subsystems, um diese SSIS-Pakete als SQL-Agent-Jobs zu planen?

Danke, Raj

Answer 1

xp_cmdshell ist das größte Sicherheitsrisiko in SQL Server, weil es ein kompromittiert Feld SQL Server ermöglicht es, den Angriff auf das Host-Betriebssystem selbst und von dort auf das gesamte Netzwerk zu erhöhen.

Der typische Angriffsvektor ist Website HTTP-Formular -> SQL-Injektion ->xp_cmdshell -> SQL-Hosting-Maschine übernehmen -> Domain übernehmen. Wenn xp_cmdshell heruntergefahren wird, muss der Angreifer andere Mittel finden, um seinen Angriff von SQL auf den Host zu erhöhen.

Andere Szenarien existieren, wie Insider-Benutzer, die es verwenden, um Berechtigungen zu erhöhen, oder die Cmdshell für andere Zwecke verwenden, z. stehlen Sie eine Datenbank. Alle basieren auf der Tatsache, dass xp_cmdshell ermöglicht, dass beliebige Befehle ausgeführt werden und auf dem Host, und in einigen Fällen übernehmen die ausgeführten Befehle auch die Privilegien des SQL Server-Dienstkontos.

Es gibt andere Befehle und erweiterte Prozeduren, die von einem Angreifer verwendet werden können, wenn xp_cmdshell blockiert ist, aber sie sind weit weniger bekannt. Die Verwendung des Vektors xp_cmdshell ist in jedem SQL-Injection-Spickzettel und in der Forumsdiskussion, also wird von jedem und ihrem großartigen MA bekannt.

Answer 2

Unabhängig davon, auf welchem ​​Konto der Job ausgeführt wird, haben Sie möglicherweise Zugriff auf Befehle von der Befehlszeile aus. Sie müssen also darüber nachdenken, wie es ausgeführt wird und welche Berechtigungen das Konto hat.

Wenn ein Benutzer beispielsweise einen Job erstellen könnte, der im Kontext Ihres sqlagent ausgeführt wird und Ihr sql-Agent überprivilegiert ist (Rechte zum Ändern der Sicherheit), könnte er sich erhöhte Rechte gewähren oder Ihren Computer verletzen.

Answer 3

Mit SQL 2008 wurde ein Switch für DTExec eingeführt, mit dem Sie die Pakete im 32-Bit-Modus mithilfe der systemeigenen SQL-Agentenaufgabe für SSIS ausführen können. Auf der Registerkarte "Ausführung" der Eigenschaften des Jobschritts befindet sich ein Kontrollkästchen für 32 Bit, das beim Blick auf die Befehlszeilenansicht in den Schalter "/ X86" übersetzt wird.

Wenn Sie mit SQL 2005 stecken bleiben, ist die CMDEXEC-Option die einzige, die ich kenne.