xp_cmdshell: sollte es jemals verwendet werden?

Das Ausschalten von xp_CmdShell ist ein bisschen so, als würde man einen Schleier über verrottendes Fleisch legen. Es bringt ein falsches Gefühl der Sicherheit auf den Tisch und die Fliegen können immer noch an das Fleisch gelangen. Lassen Sie mich das erklären.

Wer kann xp_CmdShell verwenden? Das ist richtig. Nur Personen / App-Anmeldungen mit „SA“ -Privs oder Personen, für die Sie den schrecklichen Fehler gemacht haben, einen Proxy zu erteilen, können ihn verwenden.

Nächste Frage. Wenn Sie xp_CmdShell deaktiviert haben, wer sind die einzigen Personen, die es wieder einschalten können? Richtig korrigieren! Nur Personen / Apps mit „SA“ -Privilegien können es wieder einschalten.

Also, was ist das eigentliche Problem, wenn xp_CmdShell ein Sicherheitsrisiko darstellt ? Die Antwort lautet xp_CmdShell ist KEIN Sicherheitsrisiko. Schlechte Sicherheit ist das einzige Sicherheitsrisiko. Wenn ein Hacker oder ein böswilliger interner Benutzer mit „SA“ -Privs in das System eindringt, kann er xp_CmdShell in wenigen Augenblicken aktivieren. Ja, diese Aktion wird protokolliert, liefert jedoch nur dokumentierte Beweise dafür, dass die Sicherheit anfangs grob fehlte.

Das Deaktivieren von xp_CmdShell dient nur der Sicherheit, außer dass dieser Teil eines Hacker-Codes wieder aktiviert werden kann.

Ich werde es noch einmal sagen. xp_CmdShell ist kein Sicherheitsrisiko. Nur schlechte Sicherheit ist ein Sicherheitsrisiko. Korrigieren Sie Ihre Sicherheit und aktivieren Sie dann xp_CmdShell. Es ist ein wunderbares Werkzeug, und Sie verpassen es aufgrund schlechter Sicherheitspraktiken und Mythen.

Kommentare

• Ich stimme Ihnen voll und ganz zu. Jeff. Ein Angreifer, der Syadmin-Berechtigungen erhalten hat, kann einen SQL Agent-Job von sa mit einem CmdExec-Jobschritt erstellen und dasselbe wie xp_cmdshell erreichen. Er könnte auch eine gespeicherte CLR-Prozedur erstellen, die einen Prozess startet. Wie würde sich das von xp_cmdshell unterscheiden?Die ordnungsgemäße Sicherung des Servers ist die einzige Möglichkeit, Sicherheitsrisiken zu vermeiden.
• Ah, mein alter ‚ Freund. Danke für die Rückmeldung. Gut, dass “ “ Sie wieder sieht.
• +1 Sie liegen falsch, aber ich mag es, dass Sie falsch liegen weil Sie die Menschen dazu ermutigen, weniger sicher zu sein, was das Interesse zu einem unterhaltsameren Ort macht. Ja Installieren Sie SQL Server auf allem, und ja, der zusätzliche Teil darüber, wie einfach es ist, mit der Konfiguration zu reparieren. Ich liebe es < 3. Die SQL-Server 2020 und 9/10 werden nicht richtig gehärtet – aber natürlich wird der DB-Administrator XD
• Heh … I ‚ dafür verantwortlich gemacht Sie das gleiche plus eins für falsch. Ich wünschte, ich könnte Ihnen ein Plus geben, wenn Sie falsch denken, dass das Deaktivieren von xp_CmdShell überhaupt etwas dazu beiträgt, “ “ einen Server zu härten. ‚ t.

Ich denke „es sollte nicht verwendet werden“ ist wahrscheinlich ein ziemlich guter Rat. Das ist kein kategorisches „Es ist immer unsicher“, sondern eine Erkenntnis, dass xp_cmdshell gefährlich ist und jede Verwendung Anlass zur Sorge und sorgfältigen Prüfung gibt.

Und Selbst wenn Sie glauben, die Sicherheitsrisiken zu vermeiden, ist xp_cmdshell wahrscheinlich immer noch nicht das beste Tool. Es besteht die Möglichkeit, dass es eine bessere Lösung gibt (eine, die zufällig auch weniger riskant ist).

„With Große Macht bringt große Verantwortung mit sich. “ Abgesehen davon denke ich, dass xp_cmdshell einer der schlimmsten Sicherheitszüge ist, die es schaffen, aus Redmond herauszukommen.

Bearbeiten: 2020, als Penetrationstester seit mehr als 10 Jahren – xp_cmdshell immer noch eines der schrecklichsten Sicherheitsrisiken, denen ich begegnet bin, weil es die beste Kombination bietet von; weit verbreitet sein, von wichtigen Unternehmen wie Banken genutzt werden und maximale Wirkung erzielen. SQLmap kann verwendet werden, um SA abzurufen und xp_cmdshell wieder zu aktivieren … wobei nur SQL Injection in einer Webanwendung verwendet wird.

Als Ingenieur zu einem anderen, danke Microsoft – ich hätte diese Muscheln buchstäblich nicht ohne Sie bekommen können.

Kommentare

• Ich weiß, dass ‚ eine alte Frage ist, aber ich muss es wirklich sagen: Ich ‚ bin überrascht, dass 3 Personen Ihr Trolling ernst genommen haben genug, um Ihre Antwort zu verbessern.
• @spaghettidba Ich meine es absolut ernst, da ein Pentester xp_cmdshell() ein Gott ist. Was es so schlimm macht, ist, dass niemand bei Microsoft daran denkt, dieses Problem zu beheben. Ich ‚ freue mich sehr über Microsoft-Produkte und -Anwendungen, die auf der Microsoft-Plattform basieren, weil sie schwach sind. Unterhaltsame Tatsache, mein erster 0-Tag war in einem Microsoft-Sicherheitsprodukt, als ich 16 war, was mehr als ein Jahrzehnt her war.
• @rook – Es ‚ Es kommt nicht oft vor, dass ich mit einem echten PEN-Tester sprechen kann, also muss ich ‚ diese Gelegenheit nutzen, um zu fragen (ohne nach einem Kampf zu suchen … I ‚ bin ehrlich und wirklich an Ihrer guten Erfahrung interessiert), wenn Sie ‚ nicht in jemanden ‚ s geraten können Goodie Locker mit SysAdmin-Privilegien. Konnten Sie xp_CmdShell immer noch als Angreifer verwenden, auch wenn ‚ aktiviert ist? Wenn ja, gibt es eine Möglichkeit, sich davor zu schützen?
• @Jeff Moden. JA , also macht sqlmap das ganz gut. Auch wenn Sie keine SA sind – aufgrund des Stapelns von Abfragen können Sie sich mit einer SQL-Abfrage beim SA-Konto anmelden – ja, eine injizierte SQL-Abfrage kann verwendet werden, um SA zu erhalten und dann einen beliebigen Befehl erneut zu aktivieren. Sie müssen das Passwort noch kennen … aber es kann brutal erzwungen werden, und wenn dieser Angriff ‚ nicht berücksichtigt wurde, könnte das SA-Konto ein schwaches Passwort haben … und ich habe das schon oft gesehen, sogar bei Banken. Kein SQL-Server-Experte, aber ich denke, es gibt eine Verhärtung, die diesen Angriff verhindern kann … aber nicht standardmäßig !!!! SQLMap für den Gewinn!

Welche Art von Sicherheit wird in Ihrer SQL Server-Umgebung verwendet, gemischt oder integriert (Windows)? Wie viele sind in der sysadmin SQL Server-Rolle? MS Best Practices erfordern eine integrierte Authentifizierung (keine sa-Anmeldung, keine SQL-Anmeldungen) und nur zwei in der sysadmin SQL Server-Rolle. Ich gehe davon aus, dass das Befolgen dieser Best Practices die Gefährdung erheblich verringert. Darüber hinaus bietet xp_cmdshell (Pre-SQLLCD-Modus und Pre-Powershell) die Möglichkeit, Transaktionsprotokolldateien vom Produktionsserver auf den DR-Server zu kopieren, der Hunderte von Kilometern von einem geplanten Zeitpunkt entfernt ist SQL Agent-Job. Hier gibt es nichts Böses, aber wie auf dem einen Poster angegeben, „es kommt darauf an“.

Um jl01 hervorzuheben “ s Antwort (der ich eine +1 gegeben habe) …

Seltsamerweise besteht ein gutes Maß für einen ordnungsgemäß gesicherten und sicheren SQL Server darin, xp_CmdShell tatsächlich zu aktivieren.Damit meine ich, dass Sie sich keine Sorgen machen müssen, wenn Ihr System sicher genug ist, dass triviale Dinge wie xp_CmdShell aktiviert und verwendet werden.

Insbesondere ab SQL Server 2005 gibt es praktisch keinen Grund Warum andere Benutzer als DBAs über höhere Berechtigungen als PUBLIC-Berechtigungen und EXECUTE-Berechtigungen für gespeicherte Prozeduren in einem ordnungsgemäß gesperrten System verfügen sollten. Bei korrekter Implementierung sollten Benutzer mit PUBLIC-Berechtigungen in der Lage sein, eine gespeicherte Prozedur auszuführen, die Aufrufe von xp_CmdShell enthält, ohne xp_CmdShell direkt selbst ausführen zu können.

Ich finde es ironisch, dass MS den Command Shell-Proxy erstellt hat Benutzer mit geringen Rechten können xp_CmdShell direkt ausführen, wenn sie nicht einmal eine Tabelle sehen können.