“Insecure Deserialization is a vulnerability which occurs when untrusted data is used to abuse the logic of an application” (Acunetix., 2017) https://www.acunetix.com/
Photo by Ante Hamersmit on Unsplash
Serialization is the process of turning some object into a data format that can be restored later. People often serialize objects in order to save them to storage, or to send as part of communications.
Deserialization is the reverse of that process, taking data structured from some format, and rebuilding it into an object. Today, the most popular data format for serializing data is JSON. Before that, it was XML.
Let’s try to understand this by a beautiful analogy put forward by TRY HACK ME,
A Tourist approaches you in the street asking for directions. They’re looking for a local landmark and got lost. Unfortunately, English isn’t their strong point and nor do you speak their dialect either. What do you do? You draw a map of the route to the landmark because pictures cross language barriers, they were able to find the landmark. Nice! You’ve just serialised some information, where the tourist then deserialised it to find the landmark.
Continued
Serialisation is the process of converting objects used in programming into simpler, compatible formatting for transmitting between systems or networks for further processing or storage.
Alternatively, deserialisation is the reverse of this; converting serialised information into their complex form — an object that the application will understand.
What does this mean?
Say you have a password of “password123” from a program that needs to be stored in a database on another system. To travel across a network this string/output needs to be converted to binary. Of course, the password needs to be stored as “password123” and not its binary notation. Once this reaches the database, it is converted or deserialised back into “password123” so it can be stored.
Serialisation — →— — — — — —> — — — — — — →— — — — — — — — —> — — -Deserialisation
Simply, insecure deserialization is replacing data processed by an application with malicious code; allowing anything from DoS (Denial of Service) to RCE (Remote Code Execution) that the attacker can use to gain a foothold in a pentesting scenario.
Specifically, this malicious code leverages the legitimate serialization and deserialization process used by web applications.
- Low exploitability. This vulnerability is often a case-by-case basis — there is no reliable tool/framework for it. Because of its nature, attackers need to have a good understanding of the inner-workings of the ToE.
- The exploit is only as dangerous as the attacker’s skill permits, more so, the value of the data that is exposed. For example, someone who can only cause a DoS will make the application unavailable. The business impact of this will vary on the infrastructure — some organisations will recover just fine, others, however, will not.
Insecure deserialization occurs when data from an untrusted party (I.e. a hacker) gets executed because there is no filtering or input validation; the system assumes that the data is trustworthy and will execute it no holds barred.
What’s Vulnerable?
At summary, ultimately, any application that stores or fetches data where there are no validations or integrity checks — (Integrity checking products work by reading your entire disk and recording integrity data that acts as a signature for the files and system sectors. An integrity check program with built-in intelligence is the only solution that can handle all the threats to your data asa well as viruses. Integrity checkers also provide the only reliable way to discover what damage a virus has done.) — in place for the data queried or retained. A few examples of applications of this nature are:
- E-Commerce Sites
- Forums
- API’s
- Application Runtimes (Tomcat, Jenkins, Jboss, etc)
Cookies
Photo by The Creative Exchange on Unsplash
Cookies are an essential tool for modern websites to function. Tiny pieces of data, these are created by a website and stored on the user’s computer.
You’ll see notifications like the above on most websites these days. Websites use these cookies to store user-specific behaviours like items in their shopping cart or session IDs.
Cookies store login information like the below! Yikes!
Whilst plaintext credentials is a vulnerability in itself, it is not insecure deserialization as we have not sent any serialized data to be executed!
Cookies are not permanent storage solutions like databases. Some cookies such as session ID’s will clear when the browser is closed, others, however, last considerably longer. This is determined by the “Expiry” timer that is set when the cookie is created.
Some cookies have additional attributes, a small list of these are below:
- Cookie Name — The Name of the Cookie to be set.
- Cookie Value — Value, this can be anything plaintext or encoded.
- Secure Only — If set, this cookie will only be set over HTTPS connections.
- Expiry — Set a timestamp where the cookie will be removed from the browser.
- Path — The cookie will only be sent if the specified URL is within the request. If a cookie had the path of webapp.com/login , the URL that the user has to visit will be — webapp.com/login
Creating Cookies
Cookies can be set in various website programming languages. For example, Javascript, PHP or Python to name a few. The following web application is developed using Python’s Flask, so it is fitting to use it as an example.
Take the snippet below:
Setting cookies in Flask is rather trivial. Simply, this snippet gets the current date and time, stores it within the variable “timestamp” and then stores the date and time in a cookie named “registrationTimestamp”. This is what it will look like in the browser.
Flask is a micro web framework written in Python. It is classified as a microframework because it does not require particular tools or libraries. It has no database abstraction layer, form validation, or any other components where pre-existing third-party libraries provide common functions.
Go to a website of your choice and to check the cookies set by it on your browser, go to developer tools-> application tab->storage->cookies
Suppose there is an invalidated feedback form on the site ..what makes this form vulnerable?
If a user was to enter their feedback, the data will get encoded and sent to the Flask application (presumably for storage within a database for example). However, the application assumes that any data encoded is trustworthy. But we’re hackers.