What is the security vulnerability of Insecure Deserialization?
In this section, we will discuss what the concept of insecure deserialization is and explain how it can potentially expose websites to high-impact attacks. We will highlight typical scenarios and demonstrate some techniques that can be widely applied using concrete examples of PHP, Ruby, and Java deserialization. Additionally, we will explore some ways to avoid insecure deserialization security vulnerabilities on your own websites.
If you are familiar with the fundamental concepts of insecure deserialization security vulnerabilities and wish to test them on intentionally vulnerable targets, you can access all the laboratories on this topic through comments.
Serialization, which means "serileştirme" in Turkish, is the process of transforming complex data structures such as objects and fields into a "flatter" format that can be sent and received as a sequential byte stream. Serializing data makes tasks much simpler:
Writing complex data to inter-process memory, a file, or a database.
Sending complex data, for example, over a network, between different components of an application, or in an API call.
Importantly, when an object is serialized, its state is also made persistent. In other words, the object's attributes are preserved along with their assigned values.
Serialization vs. deserialization
Deserialization, which means "seriden çıkarma" in Turkish, is the process of restoring this byte stream to the original object's fully functional copy, exactly as it was when serialized. The logic of a website can then interact with this serialized object just like with other objects.
Many programming languages offer native support for serialization. How objects are serialized depends on the language, with some using binary formats while others use different string formats with varying degrees of human readability. It's important to note that all attributes of the original object, including private fields, are stored in the serialized data stream. To prevent a field from being serialized, it must be explicitly marked as "transient" in the class declaration.
When working with different programming languages, it's worth noting that serialization may be referred to as "marshalling" in Ruby or "pickling" in Python. These terms are synonymous with "serialization" in this context.
How do Insecure Deserialization Vulnerabilities Occur?
Insecure deserialization typically arises due to a lack of general understanding of how dangerous it can be to serialize data that can be controlled by a user. Ideally, user input should never be serialized.
However, at times, website owners may think they are safe because they apply some form of additional control over serialized data. This approach is often ineffective because it's nearly impossible to account for every possibility when applying validation or sanitization. These controls are fundamentally flawed as they rely on checking data after deserialization, which is often too late to prevent an attack in most cases.
Vulnerabilities can also arise when serialized objects are assumed to be inherently trustworthy. Particularly when languages use binary serialization formats, developers may assume that users cannot effectively read or manipulate the data. However, while it may require more effort, it's just as possible for an attacker to exploit binary serialized objects as it is for string-based formats.
Deserialization-based attacks are also possible due to the number of dependencies in modern websites. A typical site can implement many different libraries, each with its own dependencies. This creates a massive pool of classes and methods that are difficult to manage securely. Since an attacker can instantiate objects from any of these classes, it's challenging to predict which methods can be called on malicious data. This is especially true if an attacker can piece together a long sequence of unexpected method calls to transfer data to a receiver completely unrelated to the original source. Therefore, predicting and closing every possible loophole is almost impossible.
In summary, it can be said that securely serializing untrusted input is not possible.
What Is the Impact of Insecure Deserialization?
The impact of an insecure deserialization vulnerability can be very severe as it significantly increases the attack surface, often leading to various security vulnerabilities, most notably remote code execution.
Even in cases where remote code execution is not possible, it can still lead to privilege escalation, arbitrary file access, and denial-of-service attacks.
Exploiting Insecure Deserialization Vulnerabilities
https://www.turkhackteam.org/konular/insecure-deserialization-guvenlik-acigi-nedir.2046649/
How to Prevent Insecure Deserialization Security Vulnerabilities?
In general, user input should be avoided from being serialized unless absolutely necessary. The high severity of potential exploits it enables and the difficulty of defending against them often outweigh the benefits in many cases.
If you must deserialize data from untrusted sources, take robust measures to ensure that the data has not been tampered with. For example, you can apply a digital signature to verify the data's integrity. However, keep in mind that all checks should be performed before the deserialization process begins. Otherwise, they are of little use.
If possible, you should completely avoid using generic serialization features. Serialized data obtained from these methods includes all attributes of the original object, potentially including sensitive information in private fields. Instead, you can create your own class-specific serialization methods to have more control over which fields will be exposed, at the very least.
Finally, remember that the security vulnerability lies in the serialization of user input, not in the presence of gadget chains that process the data later. Do not rely solely on trying to eliminate gadget chains you discovered during testing. It's not practical to try to close them all due to the complex web of dependencies that likely exist in your website's libraries. Additionally, the presence of publicly documented memory corruption vulnerabilities at any given time is a factor, meaning your application could be vulnerable regardless of your efforts.
Source : @SP https://www.turkhackteam.org/konular/insecure-deserialization-guvenlik-acigi-nedir.2046649/
In this section, we will discuss what the concept of insecure deserialization is and explain how it can potentially expose websites to high-impact attacks. We will highlight typical scenarios and demonstrate some techniques that can be widely applied using concrete examples of PHP, Ruby, and Java deserialization. Additionally, we will explore some ways to avoid insecure deserialization security vulnerabilities on your own websites.
If you are familiar with the fundamental concepts of insecure deserialization security vulnerabilities and wish to test them on intentionally vulnerable targets, you can access all the laboratories on this topic through comments.
Serialization, which means "serileştirme" in Turkish, is the process of transforming complex data structures such as objects and fields into a "flatter" format that can be sent and received as a sequential byte stream. Serializing data makes tasks much simpler:
Writing complex data to inter-process memory, a file, or a database.
Sending complex data, for example, over a network, between different components of an application, or in an API call.
Importantly, when an object is serialized, its state is also made persistent. In other words, the object's attributes are preserved along with their assigned values.
Serialization vs. deserialization
Deserialization, which means "seriden çıkarma" in Turkish, is the process of restoring this byte stream to the original object's fully functional copy, exactly as it was when serialized. The logic of a website can then interact with this serialized object just like with other objects.
Many programming languages offer native support for serialization. How objects are serialized depends on the language, with some using binary formats while others use different string formats with varying degrees of human readability. It's important to note that all attributes of the original object, including private fields, are stored in the serialized data stream. To prevent a field from being serialized, it must be explicitly marked as "transient" in the class declaration.
When working with different programming languages, it's worth noting that serialization may be referred to as "marshalling" in Ruby or "pickling" in Python. These terms are synonymous with "serialization" in this context.
How do Insecure Deserialization Vulnerabilities Occur?
Insecure deserialization typically arises due to a lack of general understanding of how dangerous it can be to serialize data that can be controlled by a user. Ideally, user input should never be serialized.
However, at times, website owners may think they are safe because they apply some form of additional control over serialized data. This approach is often ineffective because it's nearly impossible to account for every possibility when applying validation or sanitization. These controls are fundamentally flawed as they rely on checking data after deserialization, which is often too late to prevent an attack in most cases.
Vulnerabilities can also arise when serialized objects are assumed to be inherently trustworthy. Particularly when languages use binary serialization formats, developers may assume that users cannot effectively read or manipulate the data. However, while it may require more effort, it's just as possible for an attacker to exploit binary serialized objects as it is for string-based formats.
Deserialization-based attacks are also possible due to the number of dependencies in modern websites. A typical site can implement many different libraries, each with its own dependencies. This creates a massive pool of classes and methods that are difficult to manage securely. Since an attacker can instantiate objects from any of these classes, it's challenging to predict which methods can be called on malicious data. This is especially true if an attacker can piece together a long sequence of unexpected method calls to transfer data to a receiver completely unrelated to the original source. Therefore, predicting and closing every possible loophole is almost impossible.
In summary, it can be said that securely serializing untrusted input is not possible.
What Is the Impact of Insecure Deserialization?
The impact of an insecure deserialization vulnerability can be very severe as it significantly increases the attack surface, often leading to various security vulnerabilities, most notably remote code execution.
Even in cases where remote code execution is not possible, it can still lead to privilege escalation, arbitrary file access, and denial-of-service attacks.
Exploiting Insecure Deserialization Vulnerabilities
https://www.turkhackteam.org/konular/insecure-deserialization-guvenlik-acigi-nedir.2046649/
How to Prevent Insecure Deserialization Security Vulnerabilities?
In general, user input should be avoided from being serialized unless absolutely necessary. The high severity of potential exploits it enables and the difficulty of defending against them often outweigh the benefits in many cases.
If you must deserialize data from untrusted sources, take robust measures to ensure that the data has not been tampered with. For example, you can apply a digital signature to verify the data's integrity. However, keep in mind that all checks should be performed before the deserialization process begins. Otherwise, they are of little use.
If possible, you should completely avoid using generic serialization features. Serialized data obtained from these methods includes all attributes of the original object, potentially including sensitive information in private fields. Instead, you can create your own class-specific serialization methods to have more control over which fields will be exposed, at the very least.
Finally, remember that the security vulnerability lies in the serialization of user input, not in the presence of gadget chains that process the data later. Do not rely solely on trying to eliminate gadget chains you discovered during testing. It's not practical to try to close them all due to the complex web of dependencies that likely exist in your website's libraries. Additionally, the presence of publicly documented memory corruption vulnerabilities at any given time is a factor, meaning your application could be vulnerable regardless of your efforts.
Source : @SP https://www.turkhackteam.org/konular/insecure-deserialization-guvenlik-acigi-nedir.2046649/
