Insecure deserialization es otra de las vulnerabilidades web del Top 10 de OWASP.
La serialización es el proceso de convertir estructuras de datos complejas, como objetos y sus campos, en un formato "más plano" que se puede enviar y recibir como un flujo secuencial de bytes.
La deserialización es el proceso de restaurar el flujo de bytes a una replica, completamente funcional, del objeto original en el estado exacto en el que estaba. La lógica de la web puede intereactuar con ese objeto deserializado como lo haría con otro cualquiera.
La deserialización se vuelve insegura cuando la web deserializa los datos que pueden ser controlados por el usuario. Esto podría permitir a un atacante manipular objetos serializados para pasarle datos dañinos al código de la aplicación. Ese atacante podría reutilizar el código de la aplicación llegando en algunas ocaciones incluso al una ejecución de código remota (RCE) y, aunque no llegase a darse un RCE, podría desencadenar en una escalada de privilegios, acceso a archivos o incluso denegación de servicio (DoS).
Veamos de que va esto, porque se que no es fácil de entender solo con palabras.
Por ejemplo, PHP ultiliza un formato de strings que suele ser bastante entendible por cualquiera (aunque en inglés :D)
$user->name = "carlos";
$user->isLoggedIn = true;
Cuando esto se serializa, pasa a tener un aspecto tal que así:
O:4:"User":2:{s:4:"name":s:6:"carlos"; s:10:"isLoggedIn":b:1;}
Lo que se podría explicar de la siguiente manera:
O:4:"User" -> Es un objeto con el nombre de clase de 4 caracteres "User"2 -> Indica que el objeto tiene 2 atributos.s:4:"name" -> La clave del primer atributo es la cadena de 4 caracteres "name".s:6:"carlos" -> El valor del primer atributo es la cadena de 6 caracteres "carlos".s:10:"isLoggedIn" -> La clave del segundo atributo es la cadena de 10 caracteres "isLoggedIn".b:1 -> El valor del segundo atributo es el valor booleano true.
Los métodos nativos para la serialización de PHP son serialize() y unserialize(). Si tienes acceso al código fuente, puedes empezar por buscar en unserialize() en cualquier parte del código.
Pero dejemos ya las palabra y pasemos a los hechos. Vamos una vez más a los labs de Portswigger.
En el primer caso nos dicen que hay una vulnerabilidad de deserialización y que desencadena una escalada de privilegios. Hay que editar la cookie de sesión y obtener privilegios de admin. Por último, se debe eliminar la cuenta de Carlos. Las credenciales para acceder son wiener:peter.
Pues como nos han dicho, lo primero será logarse en la web con las credenciales que nos han dado.
Si vemos con Burp la petición GET tras autenticarnos, veremos una cookie de sesión que está URLencodeada y a su vez en BASE64.
Vamos a hacerlo como los pro. Con ctrl+may+u lo URLdecodeamos, y con ctrl+may+b, lo decodeamos de BASE64. Esto nos queda así:
Si observamos el atributo admin aparece con b=0 (false). Vamos a cambiarlo a b=1 (true) y deshacemos los pasos de decodearlo. Ahora lo encodeamos primero a BASE64 y luego a URL. (ctrl+b y ctrl+u).
Mandamos la petición y nos vamos a comparar las dos respuestas, la primera que habíamos realizado, y la segunda la que acabamos de modificar. Y, oh, sorpresa...
Al haber modificado el booleano de 0 a 1 (o de false a true), hemos descubierto un acceso a la parte de admin.
Ojo que aun no hemos terminado, nos pedían que eliminasemos la cuenta de Carlos, así que, en la petición añadimos el /admin y vemos que aparece.
Solo nos queda copiar la URL que elimina la cuenta, y lab resuelto :D.
Este es bastante sencillo de resolver, pero como siempre digo, os aconsejo que reviseis a fondo el resto de labs, ya que hay para practicar en PHP, JAVA, Ruby...
Por cierto, solo hay que estar atento porque el propio Burp nos canta la vulnerabilidad en la parte de issues del sitemap.
Nos vemos en la siguiente.
0 comentarios:
Publicar un comentario