Indexacion de algunas vulnerabilidades
########################################
En los últimos años, después de profundizar en la forma, en que
las nuevas vulnerabilidades son descubiertas y publicadas, desde
el punto de vista de aquel que las descubre, y las publica.
Cual es en si el proceso que se sigue, desde que esa vulnerabilidad
es descubierta, hasta que es publicada por las numerosas listas de
seguridad, cómo son añadidas a las bases de datos de esas listas,
cómo se documentan, y por ultimo como son publicadas, se me
ocurren varias consideraciones a tener en cuenta…
Se ha intentado durante mucho tiempo una estandarización,
para poder clasificar los archivos de fallas, de una manera
en la cual fuese fácil reconocerlas (causa del mismo), saber
el tipo de ataque que puede llevarse a cabo (Impacto) Y su
posible mitigación o solución.
Me gustaría hacer un inciso sobre todo en la forma en la que
se suelen tratar una serie de vulnerabilidades, las cuales
suelen ser explotables a través de la URL o en si digamos en
la modificación de los valores de alguna de las variables
o parámetros de la URL.
Las vulnerabilidades sobre las que me gustaría hacer un
comentario son las siguientes:
Cross-site Scripting, SQL injection, traversal arbitrary file access
y alguno que me dejo en el tintero.
Todos estos agujeros suelen ser explotados a través de la URL,
y casi todos hacen uso de las diferentes variables, pasadas
por la URL de una página a otra en las peticiones POST o GET
de un sitio Web.
Si tomamos por ejemplo una URL con varios parámetros en la
cual hubiese uno de ellos vulnerable...
http://[victim]/folder/file.php?var1=value1&var2=[XSS-CODE]
&var3=value3
Esta vulnerabilidad seria seguramente llamada...
[Producto afectado]+ [Nombre de la variable]+ [agujero]
Con lo cual diríamos que nuestro producto es vulnerable en
la variable var2 a un bug de tipo Cross site scripting.
Cuando esta vulnerabilidad llega a las listas de seguridad, estas hacen
eco de ella y le añaden el archivo afectado, si el descubridor no lo
especifica, con lo cual nuestra vulnerabilidad en su descripción diría
que el producto XXX es vulnerable en la variable var2 a cross site
scripting al ser enviada al archivo 'file.php'
¿Que pasaría si dicha variable no estuviera definida en esa pagina?
que viniese de otra pagina de la que hemos echo un POST o que
estuviese en otro archivo y este fuese incluido en la pagina que
supuestamente es la vulnerable?
Seguramente nos volveríamos locos a la hora de intentar localizar el
fallo y deberíamos mirar muchos mas archivos de los que en realidad
necesitamos para fijar esa vulnerabilidad en una determinada llamada
a la variable afectada.
Seguramente al desarrollador le costaría mas encontrar exactamente
el error, pues en si directamente le estamos dando información
incorrecta sobre donde se haya situada la vulnerabilidad al
facilitar un archivo donde supuestamente la variable falla.
Si ponemos como ejemplo un portal tipo PHP-NUKE el cual en
el ejemplo,la primera variable llama a un modulo, la segunda
proviene del modulo llamado.
http://[PHP-NUKE]/modules.php?name=News&new_topic=1
Si existiese una vulnerabilidad en la segunda variable, esta
igualmente seria descrita por las listas como variable
new_topic es vulnetable al ser enviada al archivo modules.php
pero esta vulnerabilidad podría venir(como casi siempre es seguro)
del archivo News.php situado en el directorio de módulos del PHP-NUKE.
El desarrollador seguramente fijaría esa variable en la página
mencionada, pero seguramente esa misma variable desde otro punto
del portal, seria también vulnerable por no haberlo corregido
directamente donde se inicializa esa variable o parámetro, con
lo cual en si esa vulnerabilidad podría dividirse en dos.
Si las listas de seguridad indicasen que la variable new_topic
es vulnerable a cross site scripting al ser enviada a modules.php
y esavariable esta definida en el archivo news.php…
¿no seria mas correcto decir que la variable new_topic es
vulnerable en los dos puntos en lugar de solo en el primero?
Este tipo de "errores" al documentar las vulnerabilidades puede
llevar a creer que muchas de las vulnerabilidades del tipo descrito,
pueden estar en las listas expuestas de forma incorrecta, o pueden
llevar a error, pues en si la mayoría de las veces la definición
de la misma es errónea.
--
atentamente:
Lostmon (lostmon@gmail.com)
Web-Blog: http://lostmon.blogspot.com/
--
La curiosidad es lo que hace mover la mente....
las nuevas vulnerabilidades son descubiertas y publicadas, desde
el punto de vista de aquel que las descubre, y las publica.
Cual es en si el proceso que se sigue, desde que esa vulnerabilidad
es descubierta, hasta que es publicada por las numerosas listas de
seguridad, cómo son añadidas a las bases de datos de esas listas,
cómo se documentan, y por ultimo como son publicadas, se me
ocurren varias consideraciones a tener en cuenta…
Se ha intentado durante mucho tiempo una estandarización,
para poder clasificar los archivos de fallas, de una manera
en la cual fuese fácil reconocerlas (causa del mismo), saber
el tipo de ataque que puede llevarse a cabo (Impacto) Y su
posible mitigación o solución.
Me gustaría hacer un inciso sobre todo en la forma en la que
se suelen tratar una serie de vulnerabilidades, las cuales
suelen ser explotables a través de la URL o en si digamos en
la modificación de los valores de alguna de las variables
o parámetros de la URL.
Las vulnerabilidades sobre las que me gustaría hacer un
comentario son las siguientes:
Cross-site Scripting, SQL injection, traversal arbitrary file access
y alguno que me dejo en el tintero.
Todos estos agujeros suelen ser explotados a través de la URL,
y casi todos hacen uso de las diferentes variables, pasadas
por la URL de una página a otra en las peticiones POST o GET
de un sitio Web.
Si tomamos por ejemplo una URL con varios parámetros en la
cual hubiese uno de ellos vulnerable...
http://[victim]/folder/file.php?var1=value1&var2=[XSS-CODE]
&var3=value3
Esta vulnerabilidad seria seguramente llamada...
[Producto afectado]+ [Nombre de la variable]+ [agujero]
Con lo cual diríamos que nuestro producto es vulnerable en
la variable var2 a un bug de tipo Cross site scripting.
Cuando esta vulnerabilidad llega a las listas de seguridad, estas hacen
eco de ella y le añaden el archivo afectado, si el descubridor no lo
especifica, con lo cual nuestra vulnerabilidad en su descripción diría
que el producto XXX es vulnerable en la variable var2 a cross site
scripting al ser enviada al archivo 'file.php'
¿Que pasaría si dicha variable no estuviera definida en esa pagina?
que viniese de otra pagina de la que hemos echo un POST o que
estuviese en otro archivo y este fuese incluido en la pagina que
supuestamente es la vulnerable?
Seguramente nos volveríamos locos a la hora de intentar localizar el
fallo y deberíamos mirar muchos mas archivos de los que en realidad
necesitamos para fijar esa vulnerabilidad en una determinada llamada
a la variable afectada.
Seguramente al desarrollador le costaría mas encontrar exactamente
el error, pues en si directamente le estamos dando información
incorrecta sobre donde se haya situada la vulnerabilidad al
facilitar un archivo donde supuestamente la variable falla.
Si ponemos como ejemplo un portal tipo PHP-NUKE el cual en
el ejemplo,la primera variable llama a un modulo, la segunda
proviene del modulo llamado.
http://[PHP-NUKE]/modules.php?name=News&new_topic=1
Si existiese una vulnerabilidad en la segunda variable, esta
igualmente seria descrita por las listas como variable
new_topic es vulnetable al ser enviada al archivo modules.php
pero esta vulnerabilidad podría venir(como casi siempre es seguro)
del archivo News.php situado en el directorio de módulos del PHP-NUKE.
El desarrollador seguramente fijaría esa variable en la página
mencionada, pero seguramente esa misma variable desde otro punto
del portal, seria también vulnerable por no haberlo corregido
directamente donde se inicializa esa variable o parámetro, con
lo cual en si esa vulnerabilidad podría dividirse en dos.
Si las listas de seguridad indicasen que la variable new_topic
es vulnerable a cross site scripting al ser enviada a modules.php
y esavariable esta definida en el archivo news.php…
¿no seria mas correcto decir que la variable new_topic es
vulnerable en los dos puntos en lugar de solo en el primero?
Este tipo de "errores" al documentar las vulnerabilidades puede
llevar a creer que muchas de las vulnerabilidades del tipo descrito,
pueden estar en las listas expuestas de forma incorrecta, o pueden
llevar a error, pues en si la mayoría de las veces la definición
de la misma es errónea.
--
atentamente:
Lostmon (lostmon@gmail.com)
Web-Blog: http://lostmon.blogspot.com/
--
La curiosidad es lo que hace mover la mente....
Posts
