Insecure Deserialization
En esta sección descubriremos que es el ataque de desrialización insegura de objetos, como se explota, códigos vulnerables a este ataque y su vez como remediarlo.
Last updated
En esta sección descubriremos que es el ataque de desrialización insegura de objetos, como se explota, códigos vulnerables a este ataque y su vez como remediarlo.
Last updated
La serialización es el proceso de conversión de estructuras de datos complejas, como objetos y sus campos, en un formato "flatter" que se puede enviar y recibir como una corriente secuencial de bytes. La serialización de los datos hace que sea mucho más sencillo:
Escriba datos complejos a la memoria interproceso, un archivo o una base de datos
Enviar datos complejos, por ejemplo, a través de una red, entre diferentes componentes de una aplicación, o en una llamada API
Crucialmente, al serializar un objeto, su estado también persiste. En otras palabras, los atributos del objeto se conservan, junto con sus valores asignados.
La serialización de objetos en una aplicación convierte los datos o el estado de un objeto en un formato que puede almacenarse o transmitirse, como JSON, XML, o binario. Este proceso permite que los datos del objeto puedan ser enviados entre sistemas, guardados en bases de datos o archivos, y luego reconstruidos o "deserializados" en otro momento o en otro entorno. Aquí tienes algunos motivos clave para la serialización en aplicaciones:
Almacenamiento persistente: Al serializar objetos, puedes almacenar su estado en bases de datos o archivos para luego restaurarlos cuando la aplicación se reinicia o se necesite ese estado específico.
Comunicación entre sistemas o microservicios: La serialización permite enviar datos de una aplicación a otra, incluso si están en distintos lenguajes o entornos. Esto es fundamental en arquitecturas de microservicios, donde los servicios deben comunicarse mediante redes.
Transferencia de datos a través de redes: En aplicaciones distribuidas, la serialización permite enviar datos a través de una red para que otro sistema los deserialice y procese.
La deserialización insegura se convierte en un riesgo cuando un sistema deserializa datos de fuentes no confiables sin validación adecuada. Los atacantes pueden manipular los datos serializados para incluir código o modificar el objeto de modo que el sistema deserializador ejecute acciones maliciosas. Los datos deserializados pueden, por ejemplo, intentar cargar clases no autorizadas o provocar comportamientos inesperados en el sistema.
Para mitigar este riesgo, se recomienda:
Usar bibliotecas de serialización seguras y evitar la deserialización de datos de fuentes no confiables.
Validar y filtrar datos antes de deserializarlos.
Implementar listas de clases permitidas ("whitelisting") y limitar las clases que el sistema puede deserializar para evitar que un atacante cargue clases peligrosas.
La deserialización es el proceso de restaurar esta corriente de byte a una réplica completamente funcional del objeto original, en el estado exacto como cuando se serializó. La lógica del sitio web puede interactuar con este objeto deserializado, como lo haría con cualquier otro objeto.
Muchos lenguajes de programación ofrecen apoyo nativo para la serialización. Exactamente cómo los objetos serializados depende del lenguaje. Algunos idiomas serializan objetos en formatos binarios, mientras que otros utilizan diferentes formatos de cuerda, con diversos grados de legibilidad humana. Tenga en cuenta que todos los atributos del objeto original se almacenan en el flujo de datos serializado, incluyendo cualquier campo privado. Para evitar que un campo serialice, debe ser marcado explícitamente como "transidente" en la declaración de clase.
Tenga en cuenta que cuando se trabaja con diferentes lenguajes de programación, la serialización puede ser referida como marshalling (Ruby) o pickling (Python). Estos términos son sinónimos de "serialización" en este contexto.
La deserialización insegura es cuando los datos controlables con el usuario son desserializados por un sitio web. Esto permite potencialmente a un atacante manipular objetos serializados para pasar datos dañinos en el código de aplicación. Incluso es posible reemplazar un objeto serializado por un objeto de una clase completamente diferente. A alarmantemente, los objetos de cualquier clase que esté disponible para el sitio web serán deserializados e instanteados, independientemente de qué clase se esperaba. Por esta razón, la deserialización insegura a veces se conoce como una vulnerabilidad de "inyección de objeto". Un objeto de una clase inesperada podría causar una excepción. Sin embargo, para este momento, el daño ya puede hacerse. Muchos ataques basados en la deserialización se completan antes de que se termine la desrialización. Esto significa que el proceso de deserialización en sí puede iniciar un ataque, incluso si la propia funcionalidad del sitio web no interactúa directamente con el objeto malicioso. Por esta razón, los sitios web cuya lógica se basa en lenguajes fuertemente mecanografiados también pueden ser vulnerables a estas técnicas.
La deserialización insegura se convierte en un riesgo cuando un sistema deserializa datos de fuentes no confiables sin validación adecuada. Los atacantes pueden manipular los datos serializados para incluir código o modificar el objeto de modo que el sistema deserializador ejecute acciones maliciosas. Los datos deserializados pueden, por ejemplo, intentar cargar clases no autorizadas o provocar comportamientos inesperados en el sistema.
Para mitigar este riesgo, se recomienda:
Usar bibliotecas de serialización seguras y evitar la deserialización de datos de fuentes no confiables.
Validar y filtrar datos antes de deserializarlos.
Implementar listas de clases permitidas ("whitelisting") y limitar las clases que el sistema puede deserializar para evitar que un atacante cargue clases peligrosas.
La deserialización insegura suele surgir porque existe una falta general de comprensión de lo peligroso que puede ser la deserialización de los datos controlables por el usuario. Idealmente, la entrada del usuario nunca debe ser deserializada en absoluto.Sin embargo, a veces los propietarios de sitios web piensan que son seguros porque implementan algún tipo de control adicional en los datos des-desfundizados. Este enfoque suele ser ineficaz porque es prácticamente imposible implementar la validación o la desinfectación para tener en cuenta todas las eventualidades. Estos controles también son fundamentalmente defectuos, ya que se basan en comprobar los datos después de haber sido deserializados, que en muchos casos llegarán demasiado tarde para evitar el ataque. Las vulnerabilidades también pueden surgir porque a menudo se asume que los objetos deserializados son confiables. Especialmente cuando se utilizan idiomas con un formato de serialización binaria, los desarrolladores podrían pensar que los usuarios no pueden leer o manipular los datos de manera efectiva. Sin embargo, si bien puede requerir más esfuerzo, es lo más posible para un atacante explotar objetos binarios serializados como es explotar formatos basados en cuerdas. Los ataques basados en la desserialización también son posibles debido al número de dependencias que existen en sitios web modernos. Un sitio típico podría implementar muchas bibliotecas diferentes, que cada una tiene sus propias dependencias también. Esto crea una enorme reserva de clases y métodos que es difícil de manejar de forma segura. Como un atacante puede crear instancias de cualquiera de estas clases, es difícil predecir qué métodos se pueden invocar en los datos maliciosos. Esto es especialmente cierto si un atacante es capaz de encadenar una larga serie de invocaciones metodológicas inesperadas, pasando los datos en un lavabo que no está completamente relacionado con la fuente inicial. Por lo tanto, es casi imposible anticipar el flujo de datos maliciosos y tapar cada agujero potencial.
En resumen, se puede argumentar que no es posible deserializar de forma segura la entrada no desconfiada.
El impacto de la deserialización insegura puede ser muy severo porque proporciona un punto de entrada a una superficie de ataque masivamente mayor. Permite a un atacante reutilizar el código de aplicación existente de maneras dañinas, resultndo en muchas otras vulnerabilidades, a menudo ejecución de código remoto. Incluso en los casos en que la ejecución de código remoto no es posible, la deserialización insegura puede conducir a la escalada de privilegios, el acceso arbitrario a los archivos y los ataques de denegación de servicio.
Cómo explotar vulnerabilidades de deserialización insegura →
Ahora si ya que tenemos un poco las bases o conceptos empecemos a ver como podemos ver esto aplicado en laboratorios, para explotaciones.
Lo que menciona portswigger en la academia web →
En esta sección, le enseñaremos cómo explotar algunos escenarios comunes usando ejemplos de la deserialización de PHP, Ruby y Java. Esperamos demostrar lo explotador que la deserialización insegura es en realidad mucho más fácil de lo que mucha gente cree. Este es incluso el caso durante las pruebas de caja negra si usted es capaz de utilizar cadenas de gadget pre-construido.
También te guiaremos a través del proceso de crear tus propios ataques basados en la desserialización de alta gravedad. Aunque estos generalmente requieren acceso al código fuente, también pueden ser más fáciles de aprender de lo que podrías pensar una vez que entiendes los conceptos básicos. En particular, cubriremos los siguientes temas:
Identificar la desdorialización insegura es relativamente simple independientemente de si usted es blanco o prueba de caja negra. Durante la auditoría, usted debe mirar todos los datos que se pasan en el sitio web y tratar de identificar cualquier cosa que se vea como datos serializados. Los datos serializados se pueden identificar con relativa facilidad si conoces el formato que usan los diferentes idiomas. En esta sección, mostraremos ejemplos de PHP y Java serialización. Una vez que identifique los datos serializados, puede probar si es capaz de controlarlos.
PHP utiliza un formato de cadena mayormente legible por el hombre, con letras que representan el tipo de datos y números que representan la longitud de cada entrada. Por ejemplo, considere una Userobjeto con los atributos:
Cuando serializado, este objeto puede verse así:
Esto puede interpretarse de la siguiente manera:
O:4:"User"Objeto con el nombre de la clase de 4 caracteres "User"
2el 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:1El valor del segundo atributo es el valor booleano true
Los métodos nativos para la serialización PHP son serialize()y unserialize(). Si tiene acceso al código fuente, debe empezar buscando unserialize()en cualquier lugar del código e investigando más.
Algunos idiomas, como Java, utilizan formatos binarios de serialización. Esto es más difícil de leer, pero todavía se pueden identificar los datos serializados si usted sabe cómo reconocer algunos signos reveladores. Por ejemplo, los objetos de Java serializados siempre comienzan con los mismos bytes, que están codificados como ac ed en hexadecimal y rO0en Base64. Cualquier clase que implemente la interfaz java.io.Serializablepuedes ser serializado y deserializado. Si tiene acceso a código fuente, tome nota de cualquier código que utilice el readObject()método, que se utiliza para leer y deserializar los datos de un InputStream.
Explotar algunas vulnerabilidades de deserialización puede ser tan fácil como cambiar un atributo en un objeto serializado. A medida que el estado objeto persiste, puede estudiar los datos serializados para identificar y editar valores de atributos interesantes. A continuación, puede pasar el objeto malicioso en el sitio web a través de su proceso de deserialización. Este es el paso inicial para una explotación básica de deserialización.
En términos generales, hay dos enfoques que puedes tomar al manipular objetos serializados. Puedes editar el objeto directamente en su formulario de flujo de byte, o puedes escribir un script corto en el idioma correspondiente para crear y enseleccionar el nuevo objeto tú mismo. Este último enfoque suele ser más fácil cuando se trabaja con formatos binarios de serialización.
Al manipular los datos, siempre y cuando el atacante conserve un objeto serializado válido, el proceso de deserialización creará un objeto del lado del servidor con los valores de atributo modificados.
Como simple ejemplo, considere un sitio web que utiliza una serie Useroponerse a almacenar datos sobre la sesión de un usuario en una cookie. Si un atacante detectara este objeto serializado en una solicitud HTTP, podrían decodificarlo para encontrar la siguiente transmisión de byte:
El isAdminel atributo es un punto de interés obvio. Un atacante podría simplemente cambiar el valor booleano del atributo a 1(veria), recodificar el objeto, y sobrescribe su cookie actual con este valor modificado. De manera aislada, esto no tiene ningún efecto. Sin embargo, digamos que el sitio web utiliza esta cookie para comprobar si el usuario actual tiene acceso a ciertas funcionalidades administrativas:
Este código vulnerable instantiaría a Userobjeto basado en los datos de la cookie, incluyendo el atacante modificado isAdminatributo. En ningún momento se comprueba la autenticidad del objeto serializado. Estos datos se pasan entonces a la declaración condicional y, en este caso, permitirían una escalada de privilegios fácil. Este simple escenario no es común en la naturaleza. Sin embargo, la edición de un valor de atributo de esta manera demuestra el primer paso hacia el acceso a la enorme cantidad de superficie de ataque expuesta por la deserialización insegura.
Hemos visto cómo se pueden modificar los valores de atributos en objetos serializados, pero también es posible suministrar tipos de datos inesperados.
La lógica basada en PHP es particularmente vulnerable a este tipo de manipulación debido al comportamiento de su operador de comparación suelta (==) al comparar diferentes tipos de datos. Por ejemplo, si realizas una comparación suelta entre un número entero y una cadena, PHP intentará convertir la cadena en un número entero, lo que significa que 5 == "5"evaluaciones a true. Inusualmente, esto también funciona para cualquier cuerda alfanumérica que comienza con un número. En este caso, PHP convertirá efectivamente toda la cadena en un valor entero basado en el número inicial. El resto de la cuerda es ignorada completamente. Por lo tanto, 5 == "5 of something" en la práctica se trata como 5 == 5.
Esto se vuelve aún más extraño al comparar una cuerda el número entero 0:
Porqué? Porque no hay número, es decir, 0 números en la cuerda. PHP trata toda esta cadena como el entero 0. Considere un caso en el que este operador de comparación suelto se utiliza junto con los datos controlables de un objeto deserializado. Esto podría resultar potencialmente en peligrosos defectos lógicos.
Digamos que un atacante modificó el atributo de la contraseña para que contuviera el entero 0en vez de la cuerda esperada. Mientras la contraseña almacenada no comience con un número, la condición siempre volvería true, permitiendo una derivación autenticación. Tenga en cuenta que esto sólo es posible porque la deserialización preserva el tipo de datos. Si el código obtiene la contraseña de la solicitud directamente, el 0se convertiría en una cadena y la condición evaluaría a false. Tenga en cuenta que al modificar los tipos de datos en cualquier formato de objeto serializado, es importante recordar actualizar cualquier tipo de etiquetas y indicadores de longitud en los datos serializados también. De lo contrario, el objeto serializado se corrompiará y no será deserializado.
Además de comprobar simplemente los valores de atributos, la funcionalidad de un sitio web también podría realizar operaciones peligrosas en los datos de un objeto deserializado. En este caso, puede utilizar deserialización insegura para pasar en datos inesperados y aprovechar la funcionalidad relacionada para hacer daño.
Por ejemplo, como parte de la funcionalidad de "Eliminar usuario" de un sitio web, la imagen de perfil del usuario se elimina accediendo a la ruta del archivo en el $user->image_locationatributo. Si esto $userfue creado a partir de un objeto serializado, un atacante podría explotar esto de paso en un objeto modificado con la image_locationconfigurado en una ruta de archivo arbitraria. Borrar su propia cuenta de usuario eliminaría este archivo arbitrario también.
Vamos a ver un laboratorio de practica el cual, este ejemplo se basa en que el atacante invoca manualmente el método peligroso a través de la funcionalidad accesible al usuario. Sin embargo, la desserialización insegura se vuelve mucho más interesante cuando se crean exploits que pasan los datos en métodos peligrosos automáticamente. Esto está permitido por el uso de "métodos mágicos".
Los métodos mágicos son un subconjunto especial de métodos que no tienes que invocar explícitamente. En cambio, se invocan automáticamente cada vez que ocurre un evento o escenario en particular. Los métodos mágicos son una característica común de la programación orientada a objetos en varios idiomas. A veces se indican prefijando o rodeando el nombre del método con doble puntuación.
Los desarrolladores pueden añadir métodos mágicos a una clase para predeterminar qué código debe ser ejecutado cuando se produce el evento o escenario correspondiente. Exactamente cuando y por qué se invoca un método mágico difiere de un método a otro. Uno de los ejemplos más comunes en PHP es __construct(), que se invoca cada vez que un objeto de la clase es instantiado, similar a Python's __init__. Normalmente, los métodos mágicos constructores como este contienen código para inicializar los atributos de la instancia. Sin embargo, los métodos mágicos pueden ser personalizados por los desarrolladores para ejecutar cualquier código que quieran.
Los métodos mágicos se utilizan ampliamente y no representan una vulnerabilidad por sí solos. Pero pueden volverse peligrosos cuando el código que ejecutan maneja datos controlables con atacantes, por ejemplo, de un objeto deserializado. Esto puede ser aprovechado por un atacante para invocar automáticamente métodos en los datos deserializados cuando se cumplen las condiciones correspondientes.
Lo más importante en este contexto, algunos idiomas tienen métodos mágicos que se invocan automáticamente durante el proceso de deserialización. Por ejemplo, PHP's unserialize()método busca e invoca un objeto __wakeup()método mágico.
En la deserialización de Java, lo mismo se aplica a la ObjectInputStream.readObject()método, que se utiliza para leer los datos de la corriente inicial de byte y esencialmente actúa como un constructor para "reinicializar" un objeto serializado. Sin embargo, Serializablelas clases también pueden declarar su propia readObject()método siguiente:
A readObject()método declarado exactamente de esta manera actúa como un método mágico que se invoca durante la deserialización. Esto permite a la clase controlar la deserialización de sus propios campos más de cerca. Usted debe prestar mucha atención a cualquier clase que contenga este tipo de métodos mágicos. Permiten pasar los datos de un objeto serializado al código del sitio web antes de que el objeto esté completamente deserializado. Este es el punto de partida para crear hazañas más avanzadas.
Como hemos visto, ocasionalmente es posible explotar la deserialización insegura simplemente editando el objeto suministrado por el sitio web. Sin embargo, inyectar tipos arbitrarios de objetos puede abrir muchas más posibilidades. En la programación orientada a objetos, los métodos disponibles para un objeto están determinados por su clase. Por lo tanto, si un atacante puede manipular qué clase de objeto se está pasando como datos serializados, pueden influir en qué código se ejecuta después de la deserialización, e incluso durante ella.
Los métodos de desserialización no suelen comprobar lo que están desserializando. Esto significa que puede pasar en objetos de cualquier clase serializable que esté disponible para el sitio web, y el objeto será deserializado. Esto permite efectivamente a un atacante crear casos de clases arbitrarias. El hecho de que este objeto no sea de la clase esperada no importa. El tipo de objeto inesperado puede causar una excepción en la lógica de la aplicación, pero el objeto malicioso ya será instantiado para entonces.
Si un atacante tiene acceso al código fuente, puede estudiar todas las clases disponibles en detalle. Para construir una simple hazaña, buscarían clases que contengan métodos de magia de deserialización, y luego comprobarían si alguno de ellos realiza operaciones peligrosas en datos controlables. El atacante puede entonces pasar en un objeto serializado de esta clase para utilizar su método mágico para un exploit.
Las clases que contienen estos métodos mágicos de deserialización también se pueden utilizar para iniciar ataques más complejos que involucran una larga serie de invocaciones metodológicas, conocidas como "gadget chain".
Un "gadget" es un fragmento de código que existe en la aplicación que puede ayudar a un atacante a lograr un objetivo en particular. Un gadget individual no puede hacer directamente nada dañino con la entrada del usuario. Sin embargo, el objetivo del atacante podría ser simplemente invocar un método que pase su aportación a otro gadget. Al encadenar varios aparatos juntos de esta manera, un atacante puede potencialmente pasar su entrada en un peligroso "sin gadget", donde puede causar el máximo daño.
Es importante entender que, a diferencia de otros tipos de explotación, una cadena de aparatos no es una carga útil de métodos encadenados construidos por el atacante. Todo el código ya existe en el sitio web. Lo único que controla el atacante son los datos que se pasan en la cadena de aparatos. Esto se hace típicamente usando un método mágico que se invoca durante la deserialización, a veces conocido como un "gadget de arranque".
En estado salvaje, muchas vulnerabilidades de deserialización inseguras sólo serán explotables mediante el uso de cadenas de gadget. Esto a veces puede ser una simple cadena de uno o dos pasos, pero construir ataques de alta gravedad probablemente requerirá una secuencia más elaborada de instantiaciones de objetos e invocaciones metodológicas. Por lo tanto, poder construir cadenas de gadget es uno de los aspectos clave de explotar con éxito la deserialización insegura.
La identificación manual de las cadenas de gadget puede ser un proceso bastante arduo, y es casi imposible sin acceso a código fuente. Afortunadamente, hay algunas opciones para trabajar con cadenas de gadget pre-construida que puedes probar primero.
Hay varias herramientas disponibles que proporcionan una gama de cadenas pre-descubiertas que han sido explotadas con éxito en otros sitios web. Incluso si usted no tiene acceso al código fuente, puede utilizar estas herramientas para identificar y explotar vulnerabilidades de deserialización inseguras con relativamente poco esfuerzo. Este enfoque es posible gracias al uso generalizado de bibliotecas que contienen cadenas de gadgetes explotables. Por ejemplo, si una cadena de gadget en la biblioteca de Java Apache Commons Collections puede ser explotada en un sitio web, cualquier otro sitio web que implemente esta biblioteca también puede ser explotable usando la misma cadena.
ysoserialUna de esas herramientas para la deserialización de Java es "ysoserial". Esto le permite elegir una de las cadenas de gadget proporcionadas para una biblioteca que usted piensa que la aplicación de destino está usando, y luego pasar en un comando que desea ejecutar. A continuación, crea un objeto serializado apropiado en función de la cadena seleccionada. Esto todavía implica una cierta cantidad de prueba y error, pero es considerablemente menos intensivo en mano de obra que la construcción de sus propias cadenas de gadget manualmente.
Note
In Java versions 16 and above, you need to set a series of command-line arguments for Java to run ysoserial. For example:
Un ejemplo clásico de una cadena de gadgets ocurre con la biblioteca de Apache Commons Collections (versiones antiguas) en Java. La explotación puede implicar lo siguiente:
HashMap Trigger: El atacante construye un HashMap especialmente diseñado.
InvokerTransformer Gadget: Se usa una clase InvokerTransformer que permite ejecutar métodos arbitrarios. Se configura para llamar a un método como Runtime.getRuntime().exec().
ChainedTransformer Gadget: Utiliza ChainedTransformer para encadenar la transformación, asegurando que la invocación conduzca al método peligroso cuando se activa.
PriorityQueue Trigger: El HashMap es utilizado en conjunto con PriorityQueue (u otras estructuras de datos vulnerables) para desencadenar la ejecución cuando la deserialización ocurra.
Ejemplo en código →
No todas las cadenas de gadget en ysoserial le permiten ejecutar código arbitrario. En cambio, pueden ser útiles para otros fines. Por ejemplo, puede utilizar los siguientes para ayudarle a detectar rápidamente la deserialización insegura en prácticamente cualquier servidor:
No todas las cadenas de gadget en ysoserial le permiten ejecutar código arbitrario. En cambio, pueden ser útiles para otros fines. Por ejemplo, puede utilizar los siguientes para ayudarle a detectar rápidamente la desdobización insegura en prácticamente cualquier servidor:
El URLDNSla cadena desencadena una lucida DNS para una URL suministrada. Lo más importante es que no se apoya en la aplicación de destino utilizando una biblioteca vulnerable específica y trabaja en cualquier versión conocida de Java. Esto lo convierte en la cadena de aparatos más universal con fines de detección. Si detecta un objeto serializado en el tráfico, puede intentar utilizar esta cadena de gadget para generar un objeto que desencadena una interacción DNS con el servidor Burp Collaborator. Si lo hace, puede estar seguro de que la desserialización ocurrió en su objetivo.
JRMPClientes otra cadena universal que se puede utilizar para la detección inicial. Hace que el servidor intente establecer una conexión TCP a la dirección IP suministrada. Tenga en cuenta que necesita proporcionar una dirección IP cruda en lugar de un nombre de host. Esta cadena puede ser útil en entornos donde todo el tráfico saliente es cortafuegos, incluyendo miradas DNS. Puedes intentar generar cargas útiles con dos direcciones IP diferentes: una local y una firewalled, externa. Si la aplicación responde inmediatamente para una carga útil con una dirección local, pero cuelga de una carga útil con una dirección externa, causando un retraso en la respuesta, esto indica que la cadena de gadget funbó porque el servidor trató de conectarse a la dirección cortafuegos. En este caso, la sutil diferencia de tiempo en las respuestas puede ayudarle a detectar si la deserialización ocurre en el servidor, incluso en casos ciegos.
La mayoría de los idiomas que frecuentemente sufren de vulnerabilidades de deserialización inseguras tienen herramientas de prueba de concepto equivalentes. Por ejemplo, para los sitios basados en PHP puede utilizar "PHP Generic Gadget Chains" (PHPGGC).
Por ejm en este caso encontré un repo de github con la prueba de concepto con el gadget chains:
Es importante tener en cuenta que la vulnerabilidad es la desserialización de los datos controlables por el usuario, no la mera presencia de una cadena de gadget en el código del sitio web o en cualquiera de sus bibliotecas. La cadena de gadget es sólo un medio de manipular el flujo de los datos dañinos una vez que se ha inyectado. Esto también se aplica a varias vulnerabilidades de corrupción de memoria que se basan en la desserialización de datos no desconfiados. En otras palabras, un sitio web todavía puede ser vulnerable incluso si de alguna manera logró enchufar todas las cadenas de gadget posibles.
Puede que no siempre haya una herramienta específica disponible para explotar cadenas de gadget conocidas en el marco utilizado por la aplicación de destino. En este caso, siempre vale la pena mirar en línea para ver si hay alguna hazañas documentadas que pueda adaptar manualmente. El ajustar el código puede requerir una comprensión básica del lenguaje y el marco, y a veces puede que necesites serializar el objeto tú mismo, pero este enfoque sigue siendo mucho menos esfuerzo que construir un exploit desde cero.
En este caso con el próximo laboratorio que es gadget chains pero con un framework de ruby donde tendré que buscar bien en internet una herramienta para serializar object con ruby o localmente desde mi computador serializar un objeto usando el lenguaje.
Cuando las cadenas de gadget off-the-shelf y las hazañas documentadas no tengan éxito, tendrás que crear tu propio exploit. Para construir con éxito su propia cadena de gadget, casi con toda seguridad necesitará acceso a código fuente. El primer paso es estudiar este código fuente para identificar una clase que contiene un método mágico que se invoca durante la deserialización. Evaluar el código que este método mágico ejecuta para ver si hace directamente algo peligroso con los atributos controlables por el usuario. Esto siempre vale la pena comprobarlo en caso de que lo haga. Si el método mágico no es explotable por sí solo, puede servir como su "gadget de arranque" para una cadena de gadget. Estudie cualquier método que el gadget de arranque invoque. Algo de estos hace algo peligroso con los datos que usted controla? Si no, eche un vista más de cerca a cada uno de los métodos que posteriormente invocan, y así sea. Repita este proceso, haciendo un seguimiento de a qué valores tienes acceso, hasta que llegues a un callejón sin salida o identifiques un peligroso gadget en el que se pasan tus datos controlables. Una vez que hayas elaborado cómo construir con éxito una cadena de gadget dentro del código de aplicación, el siguiente paso es crear un objeto serializado que contenga tu carga útil. Este es simplemente un caso de estudiar la declaración de clase en el código fuente y crear un objeto serializado válido con los valores apropiados requeridos para su exploit. Como hemos visto en laboratorios anteriores, esto es relativamente simple cuando se trabaja con formatos de serialización basados en cuerdas. Trabajar con formatos binarios, como cuando se construye un exploit de desserialización de Java, puede ser particularmente engorroso. Al hacer cambios menores en un objeto existente, puede estar cómodo trabajando directamente con los bytes. Sin embargo, al hacer cambios más significativos, como pasar en un objeto completamente nuevo, esto rápidamente se vuelve poco práctico. A menudo es mucho más sencillo escribir su propio código en el idioma de destino con el fin de generar y serializar los datos usted mismo.
Al crear su propia cadena de gadget, tenga en cuenta las oportunidades de utilizar esta superficie de ataque adicional para desencadenar vulnerabilidades secundarias.
Al estudiar cuidadosamente el código fuente, podemos descubrir cadenas de gadget más largas que potencialmente permiten construir ataques de alta gravedad, incluyendo a menudo la ejecución de código remoto.
Ahora en este caso ya que resolví el laboratorio de una gadget chain especifica para el lenguaje de java y su deserialización insegura ahora haremos el proceso con el lenguaje PHP en este caso crearemos una carga util de cadena de suministro que logré efectuar la deserialización insegura con éxito permitiendonos poder aprovecharnos de la ejeción rémota de código.
