xp_cmdshell: deve ser usado?

É sempre um risco . Deve sempre ser revisado . Pode ser devidamente mitigado .

Existem usos legítimos, às vezes necessários, mas observe sua entrada com atenção!

Comentários

• Qual é o problema de não haver como limitar um usuário a um grupo predefinido de operações e, portanto, qualquer concessão de privilégio permite ao usuário executar qualquer string de comando, ou seja, não ‘ t permitir granularidade de privilégio ou declarar diferente qualquer controle se torna controle completo?
• Agora, o SQL Server é um secundário para mim, então me diga se eu ‘ m errado: conceder permissões de execução a um usuário no procedimento armazenado permite que esse procedimento seja executado por ele. Ele não permite que eles o modifiquem e não ‘ implica conceder permissões para tudo usado por aquele procedimento armazenado. Se eles devem receber xp_cmdshell permissões para executar um procedimento armazenado que as contém, então você ‘ definitivamente tem um problema. Eu ‘ estou razoavelmente confiante de que não é necessário – o procedimento não deve ser propriedade do usuário regular.
• @TobyS … esse é o problema com aqueles tipos de declarações. Resposta curta: xp_cmdshell é mau. Resposta longa: depende. 😉
• @SteveS – a versão atual do MSSQL permite que você defina uma conta diferente do sistema operacional para executar comandos xp_cmdshell sob.
• @JeffFerland … você escreveu ” I ‘ estou razoavelmente confiante de que não é necessário – o procedimento não deve pertencer ao usuário regular. ” Isso ‘ está 100% correto. Não ‘ não há necessidade de o usuário saber se uma tabela está envolvida, muito menos xp_CmdShell. E sim, é ‘ muito fácil de configurar.

Desligar o xp_CmdShell é um pouco como colocar um véu sobre carne podre. Traz uma falsa sensação de segurança para a mesa e as moscas ainda podem pegar a carne. Permita-me explicar.

Quem pode usar xp_CmdShell? Isso mesmo. Somente pessoas / logins de aplicativos com privs “SA” ou pessoas para as quais você cometeu o erro horrível de conceder um proxy podem usá-lo.

Próxima pergunta. Se você desligou o xp_CmdShell, quem são as únicas pessoas que podem ligá-lo novamente? Corrija novamente! Apenas pessoas / aplicativos com privs “SA” podem ligá-lo novamente.

Então, qual é o verdadeiro problema de xp_CmdShell ser um risco de segurança ? A resposta é xp_CmdShell NÃO é um risco de segurança. Segurança insatisfatória é o único risco de segurança. Se um hacker ou um usuário interno mal-intencionado entrar no sistema com privs “SA”, eles podem ativar o xp_CmdShell em instantes. Sim, essa ação é registrada, mas isso apenas fornece um testemunho documentado de que a segurança estava faltando grosseiramente para começar.

Desligar o xp_CmdShell não faz nada para a segurança, exceto fornecer uma chance para aquela parte do código do hacker ligá-lo novamente para ser executado.

Eu direi novamente. xp_CmdShell não é um risco de segurança. Somente uma segurança ruim é um risco à segurança. Corrija sua segurança e ative o xp_CmdShell. É uma ferramenta maravilhosa e você está perdendo isso por causa de mitos e práticas de segurança ruins.

Comentários

• Concordo totalmente com você, Jeff. Um invasor que ganhou privilégios de syadmin pode criar um trabalho do SQL Agent pertencente a sa com um passo de trabalho CmdExec e obter o mesmo que xp_cmdshell. Ele também pode criar um procedimento armazenado CLR que inicia um processo. Como isso seria diferente de xp_cmdshell?Proteger o servidor adequadamente é a única maneira de evitar riscos de segurança.
• Ah, meu ol ‘ amigo. Obrigado pelo feedback. É bom ” ver ” você novamente.
• +1 você está errado, mas eu gosto que você esteja errado porque você está incentivando as pessoas a serem menos seguras, o que torna o interesse um lugar mais divertido. Sim, instale o SQL Server em tudo e, sim, a parte extra sobre como é fácil consertar com a configuração. Adorei < 3. Seus servidores SQL de 2020 e 9/10 não serão fortalecidos corretamente – mas, claro, culpar o administrador do banco de dados XD
• Heh … Eu ‘ vou dar você o mesmo mais um por estar errado. Eu gostaria de poder dar a você uma vantagem por estar errado em pensar que desativar o xp_CmdShell faz qualquer coisa para ” fortalecer ” um servidor. Simplesmente não ‘ t.

Eu acho “não deve ser usado” é provavelmente um conselho muito bom. Isso “não é categórico” É “ sempre inseguro”, mas sim um reconhecimento de que xp_cmdshell é perigoso e qualquer uso dele é motivo para preocupação e um exame cuidadoso.

E mesmo se você achar que sabe como evitar os riscos de segurança, xp_cmdshell provavelmente ainda não é a melhor ferramenta a ser usada. As probabilidades são de que haja uma solução melhor (uma que também, por acaso, é menos arriscada).

“Com grande poder vem com grande responsabilidade. ” Dito isso, acho que xp_cmdshell é uma das piores falhas do trem de segurança para sair de Redmond.

Editar: 2020, como um testador de penetração por mais de 10 anos – xp_cmdshell ainda um dos riscos de segurança mais terríveis que encontrei porque tem a melhor combinação de; sendo amplamente difundido, usado por negócios importantes como bancos e impacto máximo. SQLmap pode ser usado para obter SA e reativar xp_cmdshell … usando apenas injeção de SQL em um webapp.

De um engenheiro para outro, obrigado Microsoft – eu literalmente não poderia ter obtido esses projéteis sem você.

Comentários

• Eu sei que ‘ é uma pergunta antiga, mas eu realmente tenho que dizer: Eu ‘ estou surpreso que 3 pessoas levaram sua pesca à sério o suficiente para votar positivamente em sua resposta.
• @spaghettidba Estou falando sério, pois um pentester xp_cmdshell() é um enviado de Deus. O que o torna tão ruim é que ninguém na Microsoft pensa em consertar esse problema. Estou ‘ Estou muito feliz em encontrar produtos e aplicativos da Microsoft criados na plataforma da Microsoft porque são fracos. Curiosidade, meu primeiro dia zero foi em um produto de segurança da Microsoft quando eu tinha 16 anos, há mais de uma década.
• @rook – It ‘ não é sempre que consigo falar com um testador de PEN de verdade, então ‘ tenho que aproveitar esta oportunidade para perguntar (não estou procurando uma briga … eu ‘ estou honesta e verdadeiramente interessado em sua boa experiência), se você PODER ‘ entrar em alguém ‘ s goodie locker com SysAdmin privs, você ainda consegue usar xp_CmdShell como um invasor mesmo se ‘ estiver habilitado? Se sim, existe uma maneira de se proteger contra isso?
• @Jeff Moden. SIM , então sqlmap faz isso muito bem. Mesmo se você não for SA – devido ao empilhamento de consultas, você pode acessar a conta SA usando um SQL QUERY – sim, uma consulta SQL injetada pode ser usada para obter SA e, em seguida, reativar qualquer comando. Você ainda precisa saber a senha … mas pode ter força bruta e se este ataque não foi ‘ levado em consideração, a conta SA pode ter uma senha fraca … e já vi isso acontecer muitas vezes, até em bancos. Não sou um especialista em SQL-Server, mas acho que há um reforço que pode impedir esse ataque … mas não é o padrão !!!! SQLMap para a vitória!

Que tipo de segurança está sendo usado em seu ambiente SQL Server, Mixed ou integrado (Windows)? Quantos estão na função sysadmin SQL Server? As práticas recomendadas da MS exigem autenticação integrada (sem login sa, sem logins SQL) e apenas dois na função sysadmin SQL Server. Eu proponho que seguir essas práticas recomendadas reduz bastante a exposição. Além disso, xp_cmdshell (modo pré sqlcmd e pré-Powershell) oferece a capacidade de copiar arquivos de log de transações do servidor de produção para o servidor de DR a centenas de milhas de dentro de uma programação Trabalho do SQL Agent. Nada mal aqui, mas como disse um postador, “depende”.

Para enfatizar jl01 ” s resposta (eu dei um +1 para) …

Curiosamente, uma boa medida de um SQL Server devidamente protegido e seguro é realmente ter o xp_CmdShell habilitado.O que quero dizer com isso é que se o seu sistema for seguro o suficiente, você não deve se preocupar com questões triviais como o xp_CmdShell sendo habilitado E USADO.

Especialmente a partir do SQL Server 2005, virtualmente não há razão porque qualquer usuário diferente de DBA “s deve ter privs maiores que PUBLIC privs e EXECUTE privs em procedimentos armazenados em um sistema devidamente bloqueado. Na verdade, implementado corretamente, os usuários com privs PUBLIC devem ser capazes de executar um procedimento armazenado que contém chamadas para xp_CmdShell sem ser capaz de executar xp_CmdShell diretamente por si próprios.

Acho irônico que a MS tenha criado o proxy shell de comando para permitir que usuários com baixa priv executem xp_CmdShell diretamente quando eles não deveriam ser capazes de ver uma tabela.