¿Se puede utilizar xp_cmdshell de forma segura dentro de un proceso almacenado y existen situaciones para las que realmente no hay otra opción? En otras palabras, ¿su uso dentro de un proceso almacenado siempre debe ser marcado como un problema de seguridad (como lo recomienda un conocido analizador de código fuente)?
Dicho de otra manera, ¿estaría de acuerdo con la siguiente declaración ( cita directa)?
La función xp_cmdshell no se puede utilizar de forma segura. No debe usarse.
Comentarios
- Para aquellos desconocidos » xp_cmdshell «, es » un procedimiento almacenado extendido proporcionado por Microsoft y almacenado en la base de datos maestra. Este procedimiento le permite emitir comandos del sistema operativo directamente al shell de comandos de Windows a través del código T-SQL. » ¡¡Ay !!
- No, yo no ‘ no estoy de acuerdo. Absolutamente se puede usar de manera segura usando al menos 2 métodos diferentes que conozco y uno de ellos es bastante fácil de configurar. El problema es que BOL no ‘ realmente le dice cómo hacerlo.
Respuesta
Siempre es un riesgo . Siempre debe ser revisado . Se puede mitigar adecuadamente.
Hay usos legítimos, a veces necesarios, ¡pero observe atentamente sus aportaciones!
Comentarios
- ¿Qué pasa con el problema de que no hay forma de limitar a un usuario a un grupo predefinido de operaciones y, por lo tanto, cualquier concesión de privilegios permite al usuario ejecutar cualquier cadena de comando, es decir, no ‘ ¿No permite la granularidad de los privilegios o, dicho de otro modo, algún control se convierte en control completo?
- Ahora, SQL Server es secundario para mí, así que dígame si ‘ m incorrecto: otorgar a un usuario permisos de ejecución en el procedimiento almacenado permite que ese procedimiento sea ejecutado por ellos. No les permite modificarlo, y no ‘ no implica otorgar permisos para todo lo que usa ese procedimiento almacenado. Si deben tener
xp_cmdshellpermisos para ejecutar un procedimiento almacenado que lo contenga, entonces ‘ definitivamente tiene un problema. ‘ estoy razonablemente seguro de que no es necesario: el procedimiento no debe ser propiedad del usuario habitual. - @TobyS … ese es el problema con esos tipo de declaraciones. Respuesta corta: xp_cmdshell es malvado. Respuesta larga: depende. 😉
- @SteveS: la versión actual de MSSQL le permite configurar una cuenta diferente OS para ejecutar comandos xp_cmdshell.
- @JeffFerland … usted Escribí » I ‘ estoy razonablemente seguro de que no es obligatorio: el procedimiento no debe ser propiedad del usuario habitual. » Eso ‘ es 100% correcto. No hay ‘ s no es necesario que el usuario sepa siquiera si hay una tabla involucrada, mucho menos xp_CmdShell. Y sí, ‘ es bastante fácil de configurar.
Responder
Apagar xp_CmdShell es un poco como poner un velo sobre la carne podrida. Aporta una falsa sensación de seguridad a la mesa y las moscas aún pueden atrapar la carne. Permítame explicarle.
¿Quién puede usar xp_CmdShell? Eso es correcto. Solo las personas / aplicaciones que tienen acceso con privilegios «SA» o las personas a las que cometiste el terrible error de otorgar un proxy pueden usarlo.
Siguiente pregunta. Si tienes xp_CmdShell desactivado, ¿quién ¿Son las únicas personas que pueden volver a encenderlo? ¡Corrija de nuevo! Solo las personas / aplicaciones con privs «SA» pueden volver a encenderlo.
Entonces, ¿cuál es el problema real con xp_CmdShell como un riesgo de seguridad? ? La respuesta es xp_CmdShell NO es un riesgo de seguridad. La mala seguridad es el único riesgo de seguridad. Si un pirata informático o un usuario interno malintencionado ingresan al sistema con privs «SA», entonces pueden activar xp_CmdShell en un momento. Sí, esa acción se registra, pero eso solo proporciona un testimonio documentado de que la seguridad era muy deficiente para empezar.
Desactivar xp_CmdShell no hace nada por la seguridad, excepto proporcionar una oportunidad para que esa parte del código de un pirata informático vuelva a activarlo para que se ejecute.
Lo diré de nuevo. xp_CmdShell no es un riesgo de seguridad. Solo una mala seguridad es un riesgo para la seguridad. Arregle su seguridad y luego encienda xp_CmdShell. Es una herramienta maravillosa y te la estás perdiendo debido a las malas prácticas de seguridad y al mito.
Comentarios
- Estoy completamente de acuerdo contigo, Jeff. Un atacante que obtuvo privilegios de syadmin podría crear un trabajo del Agente SQL propiedad de sa con un paso de trabajo CmdExec y lograr lo mismo que xp_cmdshell. También podría crear un procedimiento almacenado CLR que inicia un proceso. ¿En qué se diferenciaría de xp_cmdshell?Asegurar el servidor correctamente es la única forma de prevenir riesgos de seguridad.
- Ah, mi ol ‘ amigo. Gracias por los comentarios. Es bueno » verte » de nuevo.
- +1 estás equivocado, pero me gusta que estés equivocado porque estás animando a las personas a estar menos seguras, lo que a su vez hace que el interés sea un lugar más divertido. Sí, instale SQL Server en todo, y sí, la parte adicional sobre cómo es fácil de arreglar con la configuración. Me encanta < 3. Sus servidores SQL 2020 y 9/10 no se reforzarán correctamente, pero, por supuesto, culpe al administrador de la base de datos XD
- Je … Yo ‘ daré tú lo mismo más uno por estar equivocado. Me gustaría poder darle una ventaja por estar equivocado al pensar que deshabilitar xp_CmdShell hace algo para » endurecer » un servidor. Simplemente no ‘ t.
Responder
Creo «No debería usarse» es probablemente un buen consejo. Eso «no es» categórico «Es» siempre inseguro «, sino más bien un reconocimiento de que xp_cmdshell es peligroso y cualquier uso de él es motivo de preocupación y un escrutinio cuidadoso.
incluso si cree que sabe cómo evitar los riesgos de seguridad, xp_cmdshell probablemente no sea la mejor herramienta para usar. Lo más probable es que haya una solución mejor (una que también, fortuitamente, resulta ser menos riesgosa).
Responder
«Con un gran poder conlleva una gran responsabilidad «. Dicho esto, creo que xp_cmdshell es uno de los peores trenes de seguridad para salir de Redmond.
Editar: 2020, como probador de penetración durante más de 10 años – xp_cmdshell sigue siendo uno de los riesgos de seguridad más aterradores que he encontrado porque tiene la mejor combinación de; siendo de amplia difusión, utilizada por importantes empresas como los bancos, y de máximo impacto. SQLmap se puede usar para obtener SA y volver a habilitar xp_cmdshell … usando solo SQL Injection en una aplicación web.
De un ingeniero a otro, gracias Microsoft. Literalmente no podría haber obtenido estos shells sin usted.
Comentarios
- Sé que ‘ es una vieja pregunta, pero tengo que decirlo: Me ‘ me sorprende que 3 personas se tomaran en serio tu trolling suficiente para votar tu respuesta.
- @spaghettidba Lo digo en serio, ya que un pentester
xp_cmdshell()es un regalo de Dios. Lo que lo hace tan malo es que nadie en Microsoft ni siquiera piensa en solucionar este problema. Estoy ‘ muy feliz de encontrar productos y aplicaciones de Microsoft construidos en la plataforma de Microsoft porque son débiles. Dato curioso, mi primer día 0 fue en un producto de seguridad de Microsoft cuando tenía 16 años, que fue hace más de una década. - @rook – It ‘ No es frecuente que pueda hablar con un probador de PEN real, así que ‘ tengo que aprovechar esta oportunidad para preguntar (sin buscar pelea … yo ‘ estoy honesta y verdaderamente interesado en tu buena experiencia), si PUEDES ‘ T meterte en alguien ‘ s Goodie Locker con SysAdmin privs, ¿ha podido utilizar xp_CmdShell como atacante incluso si está ‘ habilitado? Si es así, ¿hay alguna forma de protegerse?
- @Jeff Moden. SÍ , entonces sqlmap hace esto bastante bien. Incluso si no es SA, debido al apilamiento de consultas, puede iniciar sesión en la cuenta de SA utilizando una CONSULTA SQL, sí, una consulta SQL inyectada se puede usar para obtener SA y luego volver a habilitar cualquier comando. Aún necesita saber la contraseña … pero puede ser de fuerza bruta y si este ataque no fue ‘ t tomado en consideración, entonces la cuenta de SA podría tener una contraseña débil … y he visto que esto sucede muchas veces, incluso en los bancos. No soy un experto en SQL-Server, pero creo que hay un endurecimiento que puede prevenir este ataque … ¡pero no por defecto! ¡SQLMap para la victoria!
Respuesta
¿Qué tipo de seguridad se está utilizando en su entorno de SQL Server, mixto o integrado (Windows)? ¿Cuántos están en el rol de sysadmin SQL Server? Las mejores prácticas de MS requieren autenticación integrada (sin inicio de sesión sa, sin inicio de sesión SQL) y solo dos en el rol de administrador de sistemas SQL Server. Afirmo que seguir estas mejores prácticas mitiga en gran medida la exposición de uno. Además, xp_cmdshell (modo pre sqlcmd y pre-Powershell) brinda la capacidad de copiar archivos de registro de transacciones desde el servidor de producción al servidor de recuperación ante desastres a cientos de millas de distancia dentro de un programa Trabajo del Agente SQL. No hay nada malo aquí, pero como decía el cartel, «depende».
Respuesta
Para enfatizar jl01 » s respuesta (a la que le di un +1) …
Curiosamente, una buena medida de un SQL Server debidamente protegido y seguro es tener habilitado xp_CmdShell.Lo que quiero decir con eso es que si su sistema es lo suficientemente seguro, no debería tener que preocuparse por asuntos triviales como xp_CmdShell esté habilitado Y UTILIZADO.
Especialmente a partir de SQL Server 2005, prácticamente no hay ninguna razón por qué cualquier usuario que no sea DBA debe tener privilegios mayores que privilegios PÚBLICOS y privilegios EXECUTE en procedimientos almacenados en un sistema correctamente bloqueado. De hecho, implementado correctamente, los usuarios con privilegios PÚBLICOS deberían poder ejecutar un procedimiento almacenado que contenga llamadas a xp_CmdShell sin poder ejecutar xp_CmdShell directamente ellos mismos.
Creo que es irónico que MS haya creado el comando shell proxy para permitir que los usuarios de bajos privilegios ejecuten xp_CmdShell directamente cuando ni siquiera deberían poder ver una tabla.