En un
artículo anterior hemos cubierto algunas técnicas de hackeo de firewalls de
aplicación web. En este artículo vamos a cubrir el resto de las
técnicas con ayuda de expertos de pruebas de penetración.
DOBLE CODIFICACIÓN
PARA HACKEAR UN FIREWALL DE APLICACIONES WEB
Como
hemos comentado antes, hay muchas aplicaciones que juegan un papel para pasar
su solicitud desde tu navegador a la base de datos. Este truco se basa en
explotar este comportamiento cuando nuestra solicitud se decodifica dos veces
antes de que llegue a la base de datos. Como sabemos que el servidor web hace
la descodificación básica de URL, ya que pasa los parámetros de solicitud a la
aplicación web. Pero ¿qué si el desarrollador nuevamente hizo la
decodificación? Bueno, sí hay muchas ocasiones en que el desarrollador
decodifica la solicitud antes de usarla. De aquí surge una vulnerabilidad. A
veces podemos utilizar este comportamiento para hackear un firewall acuerdo a
expertos de seguridad perimetral.
HACKEAR LOS FILTROS
QUE DISTINGUEN MAYÚSCULAS Y MINÚSCULAS
Como
comentaron los investigadores de soluciones de
seguridad de la informaciónanteriormente sobre el
conjunto de reglas definidas por el firewall de aplicaciones web, si usted sabe
algunos conceptos básicos de Regex entonces no hay necesidad de decir que la
diferencia entre ellos:
/union.*select/
and
/union.*select/i
and
/union.*select/i
Bueno,
si usted no sabe, entonces deja que te expliquemos. El primero de ellos
distingue mayúsculas de minúsculas y el segundo no, mientras haces que Regex
maneje este error que puede pasar a veces. Esto da origen a este tipo de
ataques según curso de pruebas de penetración.
CONTAMINACIÓN DE
PARÁMETROS/ HTTP PARAMETER POLLUTION HTTP
Puede
ser que muchos de ustedes han oído hablar de él, pero estoy seguro de que pocos
lo hubieran utilizado alguna vez. En primer lugar que es HPP, Definición en
OWASP – El suministro de múltiples parámetros HTTP con el mismo nombre podrían
resultar que una aplicación interprete los valores de manera imprevista.
Consultores de soluciones de seguridad de la información comentan que mediante
la explotación de estos efectos, un atacante puede ser capaz de pasar por alto
la validación de entrada, provocar errores de aplicación o modificar los
valores de variables internas. Como HTTP Parameter Pollution (HPP) afecta a un
componente básico de todas las tecnologías web y existen ataques contra seguridad
perimetral.
Los
ataques HPP consisten en inyectar delimitadores de texto en una consulta
codificada en otros parámetros existentes. Si soluciones de seguridad de la
información no limpian adecuadamente el ingreso del usuario, un usuario
malicioso puede comprometer la lógica de la aplicación para realizar ataques,
ya sea del lado del cliente o del lado del servidor. Una de las consecuencias
de los ataques de HPP es que el atacante potencialmente pueden ignorar los
parámetros HTTP no modificables existentes para modificar el comportamiento de
seguridad perimetral, los controles de validación de entrada de derivación, y
el acceso y posiblemente explotar las variables que pueden estar fuera del
alcance directo.
Los
ataques HPP se puede definir como la posibilidad de anular o añadir parámetros
HTTP GET / POST mediante la inyección de delimitadores texto en una solicitud.
Acuerdo a experto depruebas
de penetración, esto afecta a base de todas las tecnologías web existentes
tanto, los ataques del lado del servidor y del lado del cliente.
Explotando
las vulnerabilidades de HPP es posible:
§ Invalidar parámetros
HTTP fijos existentes.
§ Modificar los comportamientos
de las aplicaciones.
§ Acceso y, potencialmente
explotar, variables incontrolables.
§ Omitir la validación de
la entrada, puestos de control y reglas de la WAF.
Aquí es
una tabla que muestra el comportamiento por defecto de estas aplicaciones con
HPP.
HTTP PARÁMETRO
FRAGMENTACIÓN/ HTTP PARAMETER FRAGMENTATION (HPF)
La idea
de utilizar HTTP Parameter Fragmentation (HPF) cuando se llama a una aplicación
web con el fin de hackear los filtros de seguridad no es una nueva. De acuerdo
con curso de pruebas de penetración, este método le permite a uno para omitir
con éxito filtros utilizados en la mayoría de los firewalls de aplicaciones web
modernas. Así que, ¿cuál es la esencia de esta técnica? Consideremos ejemplos
de la explotación de inyección SQL.
A menudo
es necesario tener dos o más parámetros de usuario en un código SQL, por
ejemplo:
<br
/>Query(“select * from table where a=”.$_REQUEST [‘a’].” and
b>”.$_REQUEST [‘b’]);<br />Query(“select * from table where
a=”.$_REQUEST [‘a’].” and b<“.$_REQUEST [‘b’].” limit
“.$_REQUEST[‘c’]);<br />etc.<br />
En la
fase de verificación de los valores de los parámetros recibidos del usuario en
el nivel de aplicación web, la aplicación es capaz de operar con solo variables
del servidor web y WAF es capaz de operar directamente con los datos de HTTP.
Sin embargo, independientemente del método de acceso a los datos, se trata de
utilizar ciertas expresiones regulares (regexps) para cada parámetro por
separado.
<br
/>preg_match(“/(uni)(on.+sel)(ect)/is”, $_REQUEST [‘a’])br
</>preg_match(“/(uni)(on.+sel)(ect)/is”, $_REQUEST [‘b’])br
</>preg_match(“/(uni)(on.+sel)(ect)/is”, $_REQUEST [‘c’])br />…br
</>preg_match(“/(sel)(ect.+fr)(om)/is”, $_REQUEST [‘a’])br
</>preg_match(“/(sel)(ect.+fr)(om)/is”, $_REQUEST [‘b’])br
</>preg_match(“/(sel)(ect.+fr)(om)/is”, $_REQUEST [‘c’])br />…br />
</>preg_match(“/(uni)(on.+sel)(ect)/is”, $_REQUEST [‘b’])br
</>preg_match(“/(uni)(on.+sel)(ect)/is”, $_REQUEST [‘c’])br />…br
</>preg_match(“/(sel)(ect.+fr)(om)/is”, $_REQUEST [‘a’])br
</>preg_match(“/(sel)(ect.+fr)(om)/is”, $_REQUEST [‘b’])br
</>preg_match(“/(sel)(ect.+fr)(om)/is”, $_REQUEST [‘c’])br />…br />
Por lo
tanto, si uno se divide la lógica del código SQL entre varios parámetros que
entren en el código SQL y luego concatena estas piezas utilizando los
comentarios, será posible hackear los filtros de soluciones de seguridad de la
información:
/?a=1+union/*&b=*/select+1,2
/?a=1+union/*&b=*/select+1,pass/*&c=*/from+users
/?a=1+union/*&b=*/select+1,pass/*&c=*/from+users
<br
/>Query(“select * from table where a=1 union/* and b>*/select
1,2”);<br />Query(“select * from table where a=1 union/* and
b<*/select 1,pass/* limit */from users”);<br />
Dado
que los comentarios se ignoran, el código de hecho es:
select * from table where a=1 union select 1,2
select * from table where a=1 union select 1,pass from users
select * from table where a=1 union select 1,2
select * from table where a=1 union select 1,pass from users
Uno
puede notar que teniendo en cuenta la vía de ataque, HPF es muy similar a la
HPP (HTTP Parameter pollution), pero a diferencia de este último, la aplicación
HPP tiene por objeto la explotación de la vulnerabilidad en seguridad
perimetral, no en el entorno de la aplicación. Según empresa de pruebas de
penetración, por supuesto, ambos métodos de ataque pueden complementar entre
sí.
0 comments:
Post a Comment