En el post anterior (El TOP 10 de OWASP) conocimos las 10 vulnerabilidades que forman parte de este proyecto. En esta ocasión vamos a aprender a explotar una de ellas, la inyección.
Una inyección ocurre cuando una aplicación no hace un uso adecuado de filtros de la información que manda a su intérprete, por lo tanto, cuando un atacante envía simples cadenas de texto especialmente diseñadas, logra explotar la sintaxis del intérprete vulnerable... En otras palabras, la inyección ocurre cuando los datos proporcionados por el usuario son enviados e interpretados como parte de una orden o consulta "válida".
Existen diferentes tipos de inyección. Por nombrar algunas tenemos:
- SQL
- Código
- Comandos de Sistema Operativo
- LDAP
- XML
- SSI
Hay muchos riesgos involucrados con la explotación de esta vulnerabilidad, y todos ellos pueden ser clasificados como altos o críticos. Algunos de ellos son:
- Modificación, creación o eliminación de información
- Robo de información
- Accesos no autorizados
- Negaciones de servicio
- Administración del Sistema atacado
Pero de nada sirve que les platique los riesgos si no los ven ustedes mismos, así que vamos a practicar un poco.
¿Qué necesito?
- Una computadora con acceso a internet
- Tiempo
- Curiosidad
Explotando "Inyección"
1.-Vamos ahora a entrar a la página de Altoromutual. Esta página está especialmente diseñada para que podamos practicar la explotación de diferentes vulnerabilidades, entre ellas, las del TOP 10 de OWASP, tal como se puede ver documentado en este sitio.
2.- Una vez dentro del sitio de Altoromutual, vamos a dar clic en Sign in para que nos redirija al portal de inicio de sesión.
3.- Iniciaremos sesión con las siguientes credenciales:
- Username.- jsmith
- Password.- demo1234
4.- Ya que estamos dentro de la aplicación, vamos a dar clic en View Recent Transactions
5.- Lo que vemos ahora es información que la aplicación trae directamente de la base de datos, y además, tenemos dos campos con los cuales nos permite interactuar con ella, de manera que nos permite filtrar los resultados mostrados entre dos fechas. Ahora bien, supuestamente estos campos solamente van a aceptar que pongamos información en cierto formato (mm/dd/yyyy), y es aquí donde entra en juego la curiosidad. ¿Qué pasaría si metemos algún dato distinto al que nos están indicando? Por ejemplo, intentemos poner "AlmostAHacker".
6.- Lo que obtenemos es un error, pero no cualquier error... Se nos está diciendo (con un poco de investigación extra), que el manejador de base de datos que utiliza este sitio es SQL Server, y que además, no hace un filtrado adecuado de las peticiones que hacemos para interactuar con él.
Nota.- Si te preguntas cómo llegué a la conclusión de que es un SQL Server... ¡Google es tu amigo! Toma una porción del mensaje de error (no es necesario copiar todo) y búscalo en Google.
7.- Ahora vamos a introducir la famosa comilla simple, ya que es la forma más común de identificar que un sitio es vulnerable a SQL Injection.
8.- Obtenemos casi el mismo error, aunque con algunas pocas diferencias.
9.- Vamos a intentar inyectar código, es decir, aprovecharnos de que sí es vulnerable este sitio a SQL Injection y enviar una consulta a la base de datos mediante los campos que tenemos disponibles, y para eso, volvemos a la página Recent Trasactions y vamos a intentar meter los siguientes datos en el campo After.
05/11/2018 union select userid, 'username:' + username, 'password' + password,null from users--
Como podemos ver, esta vez no ha arrojado ningún error porque hemos aprovechado correctamente la vulnerabilidad y nos ha mostrado la información que le pedimos, es decir, todos los usuarios con sus respectivas contraseñas.
Mitigación
Para evitar que tus aplicaciones sean vulnerables a SQL injection, te recomiendo implementar un módulo de validación de datos por medio de expresiones regulares o de un diccionario con los datos considerados válidos, a esta lista se le conoce comúnmente como White List o validación positiva.
Comentarios
Publicar un comentario