SQL Injection Hasta la Cocina - MS SQL ServerSQL Injection Hasta la Cocina - MS SQL Server
Hay determinadas vulnerabilidades que frecuentemente son menospreciadas, bien porque se considera que por si misma tienen poco impacto sobre los sistemas, o bien porque se considera que la máquina es poco importante.
En el caso de las Inyecciones SQL la gente suele tomárselas en serio, pero existe la sensación de que es una vulnerabilidad que "solo" permite acceder a la información de la base de datos, por lo que si el sistema no contiene información sensible suele ser tratada como una vulnerabilidad poco importante.
Sin embargo, depende del tipo, versión y configuración de la base de datos, es posible obtener control total de una máquina a través de una Inyección SQL, y a partir de ahí utilizar ese acceso para emplear cualquier técnica de post-explotación como puede ser crackeo de contraseñas, relaying, etc.
Concretamente, para este primer post, vamos a utilizar una vulnerabilidad de Inyección SQL en una aplicación web que utiliza un servidor de base de datos Microsoft SQL Server 2005, donde el usuario utilizado tiene privilegios de administrador. Concretamente, vamos a utilizar exactamente el mismo entorno y aplicación web utilizado en este otro post, aunque vosotros lo podéis utilizar con cualquier otra.
En versiones anteriores de MS SQL Server era posible, aunque el usuario no tuviera privilegios de administrador, realizar un ataque de fuerza bruta contra la contraseña del usuario "sa", y si esta era encontrada se podían lanzar todo tipo de comandos SQL con esos privilegios, pero para este post, por simplicidad, vamos a suponer que el usuario ya dispone de privilegios de administrador.
La explotación de esta vulnerabilidad, por supuesto, podríamos hacerla completamente a mano, lo cual es muy útil con fines didácticos y para entender bien el ataque, pero para este post vamos a usar dos herramientas que realizan todas estas acciones de forma automática: SQLMap y SQLNinja.
Contenido completo en PenTester
En el caso de las Inyecciones SQL la gente suele tomárselas en serio, pero existe la sensación de que es una vulnerabilidad que "solo" permite acceder a la información de la base de datos, por lo que si el sistema no contiene información sensible suele ser tratada como una vulnerabilidad poco importante.
Sin embargo, depende del tipo, versión y configuración de la base de datos, es posible obtener control total de una máquina a través de una Inyección SQL, y a partir de ahí utilizar ese acceso para emplear cualquier técnica de post-explotación como puede ser crackeo de contraseñas, relaying, etc.
Concretamente, para este primer post, vamos a utilizar una vulnerabilidad de Inyección SQL en una aplicación web que utiliza un servidor de base de datos Microsoft SQL Server 2005, donde el usuario utilizado tiene privilegios de administrador. Concretamente, vamos a utilizar exactamente el mismo entorno y aplicación web utilizado en este otro post, aunque vosotros lo podéis utilizar con cualquier otra.
En versiones anteriores de MS SQL Server era posible, aunque el usuario no tuviera privilegios de administrador, realizar un ataque de fuerza bruta contra la contraseña del usuario "sa", y si esta era encontrada se podían lanzar todo tipo de comandos SQL con esos privilegios, pero para este post, por simplicidad, vamos a suponer que el usuario ya dispone de privilegios de administrador.
La explotación de esta vulnerabilidad, por supuesto, podríamos hacerla completamente a mano, lo cual es muy útil con fines didácticos y para entender bien el ataque, pero para este post vamos a usar dos herramientas que realizan todas estas acciones de forma automática: SQLMap y SQLNinja.
Contenido completo en PenTester
mmm si tenemos un usuario que pueda crear sp's y ejecutarlos al mismo tiempo, puede tener control sobre la maquina, no necesariamente debe encontrase con el usuario administrador.
ResponderBorrarAhora todo dependera del DBA, para ello SQL Server nos proporciona una cantidad importante de roles , para los cuales nos permite elejir y seleccioanr el que mejor nos adecue, sobre todo si la aplicación es una app web. Como recomendación soy del tipo que prefiere tener unos 5 usuarios minimos, 4 coenxiones, y todos con diferentes roles, asi al atakante les hincharemos las pelotas un buen tiempo antes que descubra como ingresar con un injection a nuestro site.
salu2 nos bites,