La semana durante la cual estaba previsto que se publicase el Reto Hacking Infiltrados tuvimos un momento del pánico. El reto era básicamente un ataque de Session Fixation que se explotaba mediante XSS o HTML Injection, a gusto del consumidor.
Sabíamos que los jugadores tienen más tendencia por los ataques de XSS que por los de HTML Injection, así que el filtro AntiXSS de Internet Explorer 9 iba a dar un poco de guerra a los que pensaban que nosotros habíamos hecho el reto más difícil para IE9, cuando no era para nada así.
Sin embargo, durante la semana previa al comienzo del reto, Google actualizó Chrome a la versión 11... y pico, añadiendo un filtro AntiXSS que hacía que no se pudiera saltar fácilmente el reto tampoco con XSS en Google Chrome.
En un momento de pánico llegamos a pensar que no iba a funcionar tampoco con HTML Injection, pero así si funcionaba. Sin embargo, se ponía igual de complejo saltarlo en Chrome que en IE9 y perdía la gracia de la i. Es decir, si los jugadores se pasaban Firefox y Chrome con XSS y luego no les funcionaba en IE9 iban a tener que pensar dos veces la solución, mientras que si ya daban con ella en Chrome, pasarse IE9 iba a ser trivial.
La noche antes del reto, pensando incluso en cambiar las pruebas a otra cosa, Rodol y Manu dieron con cómo saltarse el filtro AntiXSS de Chrome aprovechando una funcionalidad muy divertida que trae ese navegador, la de completar el código fuente HTML mal escrito.
Supongamos que existe un lugar en el que se puede inyectra código script en la carga de, por ejemplo una imagen, inyectando algo como &tl;img src=”noexist” onerror=”alert();”/>, Google Chorme reemplazará la inyección original por algo como <img src="noexist" onerror=""> , eliminando la inyección javascript del código y evitando así el ataque XSS.
Sin embargo, Google Chrome tiene una funcionalidad que reescribe el código HTML que no está bien formado, y que puede ser utilizado para saltse el filtro XSS. Supongamos que una página HTML tiene un código en el falta la etiqueta de cierre, entonces Google Chorme escribirá la etiqueta de cierre correspondiente, para dejar un código bien escrito.
Si introducimos algo como <img src="noexist" onerror=alert, Chrome intentará cerrar correctamente la etiqueta, en este caso con un sencillo <html>, es decir, dejando la etiqueta como <img src="noexist" onerror="alert!!!</html">.
Esta funcionalidad puede ser utilizada para saltarse el filtro AntiXSS, haciendo que se convierta en un ataque XSS solo después de que sea modificado por el filtro que reescribe el código, es decir, en ese ejemplo podría hacerse una inyección como <img src="noexist" onerror=alert();//, ya que cuando sea reescrito se convertirá en algo como <img src="noexist" onerror="alert();//!!!</html">, permitiendo saltarse el filtro AntiXSS.
Saludos Malignos!
Sabíamos que los jugadores tienen más tendencia por los ataques de XSS que por los de HTML Injection, así que el filtro AntiXSS de Internet Explorer 9 iba a dar un poco de guerra a los que pensaban que nosotros habíamos hecho el reto más difícil para IE9, cuando no era para nada así.
Sin embargo, durante la semana previa al comienzo del reto, Google actualizó Chrome a la versión 11... y pico, añadiendo un filtro AntiXSS que hacía que no se pudiera saltar fácilmente el reto tampoco con XSS en Google Chrome.
En un momento de pánico llegamos a pensar que no iba a funcionar tampoco con HTML Injection, pero así si funcionaba. Sin embargo, se ponía igual de complejo saltarlo en Chrome que en IE9 y perdía la gracia de la i. Es decir, si los jugadores se pasaban Firefox y Chrome con XSS y luego no les funcionaba en IE9 iban a tener que pensar dos veces la solución, mientras que si ya daban con ella en Chrome, pasarse IE9 iba a ser trivial.
La noche antes del reto, pensando incluso en cambiar las pruebas a otra cosa, Rodol y Manu dieron con cómo saltarse el filtro AntiXSS de Chrome aprovechando una funcionalidad muy divertida que trae ese navegador, la de completar el código fuente HTML mal escrito.
Supongamos que existe un lugar en el que se puede inyectra código script en la carga de, por ejemplo una imagen, inyectando algo como &tl;img src=”noexist” onerror=”alert();”/>, Google Chorme reemplazará la inyección original por algo como <img src="noexist" onerror=""> , eliminando la inyección javascript del código y evitando así el ataque XSS.
Sin embargo, Google Chrome tiene una funcionalidad que reescribe el código HTML que no está bien formado, y que puede ser utilizado para saltse el filtro XSS. Supongamos que una página HTML tiene un código en el falta la etiqueta de cierre, entonces Google Chorme escribirá la etiqueta de cierre correspondiente, para dejar un código bien escrito.
Si introducimos algo como <img src="noexist" onerror=alert, Chrome intentará cerrar correctamente la etiqueta, en este caso con un sencillo <html>, es decir, dejando la etiqueta como <img src="noexist" onerror="alert!!!</html">.
Esta funcionalidad puede ser utilizada para saltarse el filtro AntiXSS, haciendo que se convierta en un ataque XSS solo después de que sea modificado por el filtro que reescribe el código, es decir, en ese ejemplo podría hacerse una inyección como <img src="noexist" onerror=alert();//, ya que cuando sea reescrito se convertirá en algo como <img src="noexist" onerror="alert();//!!!</html">, permitiendo saltarse el filtro AntiXSS.
Saludos Malignos!
Esto lo descubrió tu ejercito de gente o tu? :D
ResponderEliminarVirtud también es la capacidad de poder armar equipos.
ResponderEliminarLos cowboys, o los jovencitos de la película sólo existen en la ficción.
A pensar, a pensar, que la cabeza no es sólo para que te crezca pelo, Anónimo!
@Anónimo ¿Qué parte de "...Rodol y Manu dieron cómo saltarse..." no se entiende?
ResponderEliminarSe nota que es viernes ;-)
Muy buena Chema, sois unos cracks.
Saludos.
Manolo.
Eso mismo mandé yo en el solucionario de rhinfiltrados y se tomó como una solución no válida ... aún estoy esperando a que me comenteis porqué no sirvió :)
ResponderEliminar@pepeluxx, dime en que correo, pq tal vez fallaras en algo. Si funcionara, habría colado, busca el id del correo y lo comprobamos again.
ResponderEliminarSaludos!
vete y adivina dónde tengo yo los correos xDDD pero en el solucionario está escrito tal y como lo mandé
ResponderEliminarUn saludo
pues yo envié el session fixation en todos ellos... básicamente pasé todos los elementos del formulario incluido el viewstate del POST al GET cambiando el parámetro famoso para inyectarlo en el email, y además generé una imágen oculta a los mismos mediante la otra vulnerabilidad de inyección HTML.
ResponderEliminarCuriosamente funcionó en Firefox pero no en los otros, a pesar de no haber XSS de por medio
Timing (?)