Muchos son los problemas que se explotan sin impunidad alguna por los atacantes en la actualidad. Independientemente de la vulnerabilidad(bien sea técnica y/o de capa 8[errores humanos]) el atacante la aprovechará. Una de las características principales de esta problemática, se debe al desconocimiento y desinterés por parte de los desarrolladores para minimizar cualquier brecha de seguridad en su sistema que creen utópicamente infalible.
Basándonos con ésta premisa, podemos entonces deducir que, la mayoría de las casas de desarrollo, se enfocan en sacar sistemas escalables, flexibles y pensados a futuro, cumpliendo netamente con la ideología de alta cohesión y bajo acoplamiento.
¿Eres desarrollador/a?
Si eres desarrollador, deberías hacerte las siguientes preguntas básicas antes de proseguir a lo técnico:
- ¿Cuál es la metodología que usas para realizarle auditoria a tu aplicación?. -> Owasp | ¿Por qué Owasp?.Owasp no siempre es el indicado para realizar pentesting a tus aplicaciones web. La metodología muestra un top el cual puede resultar no ser el adecuado para lo que estás usando. Por ejemplo, si usas Rails, las asignaciones masivas son un problema, y esta, no aparece en el Owasp Top(2013 & 2017).Te puedo nombrar otro ejemplo y es el de Sans TOP 25: Top 25 - Software errors.
Aclaro que su última actualización fue ya hace algunos años, pero si nos centramos con ésta lógica, en el Top 10 de Owasp 2016 va liderando la inyección SQL y ésta apareció hace más de 20 años(1998, para ser más precisos). - ¿Te confías de tu Framework?
Grave error. De los desarrolladores que conozco, el 99% de ellos se confían en las funciones que sanitizan las entradas de su aplicación. Por ejemplo, ¿Sabes que se han descubierto fallos en las mismas funciones, cierto?. No digo que las funciones no deberían tener fallos, pero los desarrolladores deberían además de aplicar dichas funciones, aplicar más filtros para controlar cualquier entrada maliciosa por parte del usuario. - ¿Qué versión de DBMS usas?
En ocasiones, los DBMS(DataBase Management System) no se actualizan porque la aplicación genera errores al realizar las consultas por la versión de ésta. Es un gran problema, pues hemos visto que hay versiones de Mysql por ejemplo, donde en versiones anteriores, se puede realizar escalación de privilegios, lo mismo que en Oracle, MariaDB, entre otros.
Es difícil, realmente difícil protegerse ante cualquier amenaza, porque el precedente es y será el riesgo de los activos con los que contemos. Pero si de algo estoy seguro, es que nosotros como Pentesters, debemos desarrollar el ojo clínico para lo que hacemos. Cada cosa afecta al sistema que queremos romper, es el entorno que se convertirá en nuestro habitat y una vez lo conozcamos, podremos conocer las posibles vulnerabilidades y explotarlas.
Sin más preámbulo, vamos a lo técnico y les mostraré algunas vulnerabilidades que podrán parecer de impacto bajo, pero bien explotadas, pueden afectar hasta al mismo gerente de una empresa.
REDIRECCIONES CONTROLABLES
Ilustración 1. Plugin de Firefox para controlar las direcciones.
El plugin de NoRedirect, nos permite controlar las redirecciones de sitio y tomar control a nuestro antojo. Si nosotros desearamos ingresar a www.sitio.com/administracion/index.php, no nos dejaría, porque siempre nos va a redireccionar a login.php. Si lo viéramos desde el código, sería algo como esto:
[/list]
Código: PHP
- <?php
- }else{
- //Si la cookie no existe, entonces que siempre me lleve al login.php
- }
- ?>
Desde ese punto de vista, lo único que haríamos es bajar el plugin para firefox, instalarlo y luego añadir el sitio del panel de administración con alguna expresion regular si lo deseamos.
Ilustración 2. Añadir sitio para bloquear el redirect.
ABRIR NUEVAS PESTAÑAS
La etiqueta de a href es una de las más usadas en cualquier aplicativo web. De hecho, es usada con el atributo "_blank" para abrirle una nueva pestaña al usuario y evitarle molestias a este. Un claro ejemplo, es este:
Código: HTML5
Ilustración 3. Hipervinculo de HTML.
Si presionamos en el hipervinculo, nos llevará a Google, claro está. El problema es que la mayoría de páginas web implementan opciones como: "el usuario podrá crear un link de su biografia y poner un sitio web o incluso, comentar con un link de su sitio web". Generalmente(si lo vemos desde el lado de los Frameworks), validan desde el Controlador que el link debe ir de una forma en particular. Si un atacante logra observar que puede crear un link del siguiente estilo, podrá redireccionar sin que se de cuenta al usuario a una página para realizar phishing:
Código: HTML5
Y se vería de la siguiente forma:
Ilustración 4. Como se vería el hipervinculo del atacante.
Donde el link del atacante(el que está en el atributo de href) contiene lo siguiente:
Código: HTML5
Ahora, si un usuario da click y tiene muchas pestañas abiertas(la mayoría de las personas siempre las tienen), le va a abrir una nueva pestaña que abrirá el link de http://viinacademy.com/PoCUnderc0de/index.html y le mostrará "The rules of life" pero a la página original(la de localhost/Test/index.html) la redireccionará a https://underc0de.org/foro. Esa redirección, bien podría ser un scam o una página maliciosa, dependiendo de la creatividad del atacante.
Resumiendo esta técnica, parándonos como atacantes, serían los siguientes pasos:
- Ingresar a la página de sitio.com.
- Ingresar a alguna vista que nos permita crear un link.
- Verificar que permitan usar el atributo de target='blank_'".
- Crear un scam(página idéntica al sitio legítimo) de la página y tenerlo hospedado en un servidor.
- Poner en un link la página junto a un texto que sea interesante.
¿Cómo es posible solucionarlo?
Siempre deberás usar rel="noopener noreferrer" cuando uses el atributo target="_blank". Esto no permitirá redirigir a los usuarios.
INYECCIONES SQL
Qué más que las más conocidas como inyecciones SQL. Daré algunos tips desde el lado del pentester para descubrir inyecciones en lugares donde no se cree que las aplicaciones las tienen. Al ser una de las vulnerabilidades más explotadas, creo que los desarrolladores deben enfocarse en el BUEN filtro de sus campos.
- Intentar poner la comilla(') probablemente es una de las primeras opciones que intentamos al realizar pentest en una aplicación. Sin embargo, esto puede provocar distintos filtros y una redirección a distintas páginas de error para encubrir la SQLi. Debes intentar generar errores, bien sea, basadas en error y/o en unión, siempre pensando en cómo respondería el DBMS.
- ¿Qué pasa si comentas alguna sentencia? por ejemplo: %23' o --', pues como sabrán, así se hacen los comentarios cuando hacemos procedimientos almacenados pero al realizar pentest en una aplicación, esto puede generar errores(porque se le ordena que ignore lo que sigue de la consulta al recibir el parámetro).
- A veces, los desarrolladores pasan funciones como addslashes,htmlspecialchars, entre otras, con el fin de sanitizar las entradas. Sin embargo, la documentación de PHP NO recomiendo usar éste tipo de funciones, pues aparte de estar obsoletas, se ha demostrado que son obsoletas realizando inyecciones de charsets. En especiales, estas funciones filtran la comilla simple y/o dobles("/'), pero podrás intentar poniendo comparaciones de variables que no serán válidos, como @@verxi0n(@@version), @@Slep(@sleep), entre otr@s.
- Si la entrada es un número, puedes intentar hacer operaciones aritméticas y de ahí, intentar con otros vectores de ataque.
Por ejemplo, puedes hacer cosas como id=365--' o id=1-2.
Algunas de éstas vulnerabilidades me han servido para estar en el HoF(Hall Of Fame) de algunas empresas y créanme, los desarrolladores generalmente cometen las mismas fallas debido al uso de metodologías ágiles, de tiempo o de cualquier otro factor que pueda afectar su rendimiento vs cumplimiento.
Cualquier duda,opinión y/o sugerencia, será bien recibida.
Un saludo.
No hay comentarios:
Publicar un comentario