xp_cmdshell: czy powinien być kiedykolwiek używany?

Zawsze jest to ryzyko . Zawsze należy go przejrzeć . Można to odpowiednio złagodzić .

Istnieją uzasadnione zastosowania, czasami konieczne, ale uważnie obserwuj swój wkład!

Komentarze

• A co z problemem polegającym na tym, że nie ma możliwości ograniczenia użytkownika do wstępnie zdefiniowanej grupy operacji, a zatem każde nadanie uprawnień pozwala użytkownikowi na wykonanie dowolnego polecenia, tj. nie ' nie zezwalasz na granularność uprawnień lub stwierdzisz inaczej, każda kontrola staje się pełną kontrolą?
• Teraz SQL Server jest dla mnie drugorzędny, więc powiedz mi, czy ' m źle: Przyznanie użytkownikowi uprawnień do wykonywania procedury składowanej pozwala na jej uruchomienie. Nie pozwala im go modyfikować i nie ' nie pociąga za sobą przyznania uprawnień do wszystkiego, co jest używane przez tę procedurę składowaną. Jeśli konieczne jest przyznanie im uprawnień xp_cmdshell do uruchamiania procedury składowanej, która je zawiera, oznacza to, że ' z pewnością masz problem. Jestem ' jestem pewien, że nie jest to wymagane – procedura nie powinna należeć do zwykłego użytkownika.
• @TobyS … to jest problem z tymi rodzaje oświadczeń. Krótka odpowiedź: xp_cmdshell jest zły. Długa odpowiedź: to zależy. 😉
• @SteveS – aktualna wersja MSSQL pozwala na ustawienie innego konta systemu operacyjnego do uruchamiania poleceń xp_cmdshell pod.
• @JeffFerland … ty napisał ” I ' m dość pewny, że nie jest to wymagane – procedura nie powinna należeć do zwykłego użytkownika. ” To ' jest w 100% poprawne. ' nie ma potrzeby, aby użytkownik wiedział nawet, czy w grę wchodzi tabela, a co dopiero xp_CmdShell. I tak, ' jest dość łatwy w konfiguracji.

Wyłączenie xp_CmdShell przypomina trochę przykrycie gnijącego mięsa zasłoną. Daje fałszywe poczucie bezpieczeństwa na stole, a muchy wciąż mogą dostać się do mięsa. Pozwólcie, że wyjaśnię.

Kto może korzystać z xp_CmdShell? Zgadza się. Tylko osoby / aplikacje logujące się z uprawnieniami „SA” lub osoby, którym popełniłeś straszny błąd, przyznając proxy, mogą go używać.

Następne pytanie. Jeśli wyłączyłeś xp_CmdShell, kto czy są jedynymi osobami, które mogą go ponownie włączyć? Jeszcze raz popraw! Tylko osoby / aplikacje z uprawnieniami „SA” mogą to ponownie włączyć.

Więc jaki jest prawdziwy problem z xp_CmdShell jako zagrożeniem dla bezpieczeństwa ? Odpowiedź brzmi: xp_CmdShell NIE jest zagrożeniem dla bezpieczeństwa. Słabe bezpieczeństwo jest jedynym zagrożeniem dla bezpieczeństwa. Jeśli haker lub złośliwy użytkownik wewnętrzny dostanie się do systemu z uprawnieniami „SA”, może włączyć xp_CmdShell w momements. Tak, ta czynność jest rejestrowana, ale to tylko udokumentowane świadectwo, że bezpieczeństwo było rażąco brakujące.

Wyłączenie xp_CmdShell nie ma nic wspólnego z bezpieczeństwem, poza tym, że daje szansę tej części kodu hakera na ponowne włączenie go i uruchomienie.

Powtórzę. xp_CmdShell nie stanowi zagrożenia bezpieczeństwa. Tylko złe zabezpieczenia są zagrożeniem dla bezpieczeństwa. Napraw swoje zabezpieczenia, a następnie włącz xp_CmdShell. To „wspaniałe narzędzie” i tracisz je z powodu złych praktyk bezpieczeństwa i mitów.

Komentarze

• Całkowicie się z tobą zgadzam, Jeff. Osoba atakująca, która uzyskała uprawnienia syadmin, może utworzyć zadanie agenta SQL należące do sa z krokiem zadania CmdExec i osiągnąć to samo, co xp_cmdshell. Mógłby również utworzyć procedurę składowaną CLR, która uruchamia proces. Czym by się to różniło od xp_cmdshell?Właściwe zabezpieczenie serwera to jedyny sposób, aby zapobiec zagrożeniom bezpieczeństwa.
• Ach, mój stary ' przyjaciel. Dziękuję za zwrotną informację. Dobrze, że ” zobacz ” jeszcze raz.
• +1 mylisz się, ale podoba mi się, że się mylisz ponieważ zachęcasz ludzi do mniejszego poczucia bezpieczeństwa, co z kolei sprawia, że zainteresowanie jest przyjemniejsze. Tak Zainstaluj SQL Server na wszystkim i tak, dodatkową część dotyczącą tego, jak łatwo jest to naprawić za pomocą konfiguracji. Uwielbiam to < 3. Jego serwery SQL 2020 i 9/10 nie zostaną odpowiednio wzmocnione – ale oczywiście winę za to administratorowi DB XD
• Heh … I ' daję ty ten sam plus jeden za to, że się mylisz. Chciałbym dać ci plus za to, że się mylisz, myśląc, że wyłączenie xp_CmdShell w ogóle działa na ” harden ” serwer. Po prostu nie ' t.

Myślę „Nie należy go używać” to prawdopodobnie całkiem dobra rada. To nie jest kategoryczne „To jest zawsze niepewne”, ale raczej uznanie, że xp_cmdshell jest niebezpieczny i każde jego użycie jest powodem do niepokoju i uważnej analizy.

I nawet jeśli myślisz, że wiesz, jak uniknąć zagrożeń bezpieczeństwa, xp_cmdshell nadal prawdopodobnie nie jest najlepszym narzędziem do użycia. Istnieje prawdopodobieństwo, że istnieje lepsze rozwiązanie (które również, na szczęście, jest mniej ryzykowne).

„Z wielka moc wiąże się z wielką odpowiedzialnością. ” Biorąc to pod uwagę, myślę, że xp_cmdshell jest jednym z najgorszych pociągów bezpieczeństwa, które uciekły z Redmond.

Edycja: 2020, jako tester penetracji od ponad 10 lat – xp_cmdshell wciąż jedno z najbardziej przerażających zagrożeń bezpieczeństwa, jakie napotkałem, ponieważ ma najlepszą kombinację z; jest szeroko rozpowszechniony, używany przez ważne firmy, takie jak banki, i zapewnia maksymalny wpływ. SQLmap może służyć do uzyskiwania SA i ponownego włączania xp_cmdshell … przy użyciu tylko SQL Injection w aplikacji internetowej.

Jak jeden inżynier dla drugiego, dziękuję Microsoft – dosłownie nie mógłbym zdobyć tych powłok bez Ciebie.

Komentarze

• Wiem, że ' to stare pytanie, ale naprawdę muszę je powiedzieć: ' jestem zaskoczony, że 3 osoby poważnie potraktowały Twój trolling wystarczy, aby zagłosować za Twoją odpowiedź.
• @spaghettidba Jestem śmiertelnie poważny, ponieważ pentester xp_cmdshell() to posłanie boga. To, co sprawia, że jest tak źle, to fakt, że nikt w firmie Microsoft nawet nie myśli o naprawieniu tego problemu. ' Bardzo się cieszę, że mam do czynienia z produktami i aplikacjami Microsoft zbudowanymi na platformie Microsoft, ponieważ są one słabe. Ciekawostka, mój pierwszy dzień 0 spędziłem w produkcie zabezpieczającym firmy Microsoft, kiedy miałem 16 lat, czyli ponad dziesięć lat temu.
• @rook – It ' Nieczęsto zdarza mi się rozmawiać z prawdziwym testerem PEN, więc ' muszę skorzystać z okazji i zapytać (nie szukając walki … ja ' jestem szczerze i naprawdę zainteresowany twoimi dobrymi doświadczeniami), jeśli MOŻESZ ' dostać się do kogoś ' s goodie locker z uprawnieniami SysAdmin, czy nadal możesz używać xp_CmdShell jako atakującego, nawet jeśli ' s włączone? Jeśli tak, czy istnieje sposób, aby się przed tym uchronić?
• @Jeff Moden. TAK , więc sqlmap robi to całkiem dobrze. Nawet jeśli nie jesteś SA – ze względu na układanie zapytań możesz zalogować się na konto SA za pomocą zapytania SQL – tak, wstrzyknięte zapytanie sql może zostać użyte do uzyskania SA, a następnie ponownego włączenia dowolnego polecenia. Nadal musisz znać hasło … ale może to być wymuszone brutalnie i jeśli ten atak nie został ' wzięty pod uwagę, to konto SA może mieć słabe hasło … i widziałem to wiele razy, nawet w bankach. Nie jestem ekspertem od SQL-Server, ale myślę, że istnieje hartowanie, które może zapobiec temu atakowi … ale nie domyślne !!!! SQLMap do wygrania!

Jakie zabezpieczenia są używane w środowisku SQL Server, mieszane czy zintegrowany (Windows)? Ilu jest w roli sysadmin SQL Server? Najlepsze praktyki MS wymagają zintegrowanego uwierzytelniania (bez logowania, bez logowania do SQL) i tylko dwóch w roli sysadmin SQL Server. Twierdzę, że stosowanie się do tych najlepszych praktyk znacznie ogranicza ryzyko. Ponadto xp_cmdshell (przed trybem sqlcmd i przed Powershell) daje możliwość kopiowania plików dziennika transakcji z serwera produkcyjnego na serwer DR setki mil od zaplanowanego Zadanie agenta SQL. Nie ma zła, ale jak ujął to na jednym plakacie, „to zależy”.

Aby podkreślić jl01 ” Odpowiedź (której dałem +1) …

Co dziwne, dobrą miarą odpowiednio zabezpieczonego i bezpiecznego serwera SQL jest faktyczne włączenie xp_CmdShell.Rozumiem przez to, że jeśli twój system jest wystarczająco bezpieczny, nie powinieneś martwić się o trywialne sprawy, takie jak włączanie i używanie xp_CmdShell.

Szczególnie w przypadku SQL Server 2005 praktycznie nie ma powodu dlaczego wszyscy użytkownicy inni niż DBA powinni mieć uprawnienia większe niż uprawnienia PUBLICZNE i uprawnienia EXECUTE w procedurach składowanych w prawidłowo zablokowanym systemie. W rzeczywistości, poprawnie zaimplementowani, użytkownicy z uprawnieniami PUBLIC powinni być w stanie wykonać procedurę składowaną, która zawiera wywołania xp_CmdShell, bez możliwości bezpośredniego uruchomienia xp_CmdShell.

Myślę, że to ironiczne, że MS utworzyło proxy powłoki poleceń aby umożliwić użytkownikom o niskim priv uruchamianie xp_CmdShell bezpośrednio, gdy nie powinni nawet widzieć tabeli.