During the year 2017, an increased popularity in Deserialization Attack methods and a more than significant rise in the value of cryptocurrencies, some over 10 times their value compared to a year before, created an interesting phenomenon in the world of cybersecurity: The Deserialization Attack aimed at Crypto-Mining.

Serialization and Deserialization

To understand what a Deserialization Attack is, the underlying concept of Serialization needs to be understood first. Basically, when an object such as a state or a structure needs to be communicated over a network, it is converted into a byte stream or hierarchical format like XML or JSON. This data is then sent over the network after which the other side deserializes the data to use it as an object again. Some of these objects could, for example, be database records or device configuration items.

Insecure Deserialization

This process heavily relies on the fact that the data presented for deserialization is trusted. That is where the problem lies; not all presented data will be trustworthy. This leaves an entry point for a crafty attacker. It is exactly this point that has been exploited more and more over the last few years. Customization of the deserialization process (effectively input sanitization) will prevent most of these attacks, but many vulnerabilities have been found, and many more of course still go undiscovered.

Exploitation

A Deserialization Attack relies on feeding serialized, malicious data (Shellcode, commands, database records, etc.) into a listening service which deserializes the data it receives. If the attack is successful, the sent malicious code could cause a Denial of Service, a Bypassed Authentication Control or even Remote Code Execution. Because (de)serialization is such a broadly used technology, there are countless vulnerabilities, covering all Operating Systems, many Applications and many Programming Languages such as C, C++, Python, and Ruby.

Crypto-Mining

It is no surprise that the price surge in Crypto Currencies in 2017 has attracted the attention of cybercriminals, looking to expand their income. The tool of choice for many of these bad operators has been the Insecure Deserialization Attack. It is a quick, low complexity, almost opportunistic attack vector, perfect for their ultimate goal: using their victim's resources for Crypto-Mining. This directly converts their illegal efforts into easily extractable and monetizable value, these days usually in the forms of virtually untraceable Monero coins.

This attack type usually involves a broader scan followed by a more targeted successful exploit of an Insecure Deserialization Vulnerability, in turn, followed by the upload of crypto mining malware. Once operational, this malware will then use the victim servers CPU to mine the crypto-currency of choice, often as a member of a botnet-wide mining pool.

There are other, more traditional delivery methods of the mining malware as well, such as phishing e-mail campaigns, packaging the malware inside a genuine application and many others. What makes the Deserialization Attack so dangerous though, is that such far more complex and time-consuming attack methods are not required; The target is already configured to ingest the attacker's data.

Although the target systems are considered fully compromised after a successful attack (the attacker can execute malicious code on the system), the direct damage to the system itself and the broader target network is usually limited when compared to for instance a Ransomware attack. It is in the attackers own best interest to leave the target as much unharmed as possible, so the malware will keep running and therefore will keep mining undetected for as long as possible. Of course, it is still critical to detect these attacks and to clean up a compromised environment as thorough and as quick as possible to prevent potential additional damage.

Security Controls

An ounce of prevention is worth a pound of cure. To prevent a Deserialization Attack, there is a range of available options. Most of these should be used together to cover all possible attack vectors comprehensively.

First, any input the deserialization service could be required to ingest should be controlled. Accepted data sources need to be limited to the absolute minimum via Firewall policies. If there is a need to open a service up to the entire public internet scope, gathered Threat Intelligence data should still be used to block certain suspicious sources (such as Tor Exit Nodes or certain User Agent Strings for instance).

Where possible, applications should also only accept digitally signed input. On top of that, deserialization application code should be modeled around the many available guidelines that are available these days such as the list published by OWASP.org, covering, for instance, Java ObjectInputStream hardening. Switching to a pure data format such as JSON, XML or YAML will also assist in the prevention of these attacks by stopping some of the malicious logic that can be inserted into native formats.

More generic security controls such as System Hardening, Intrusion Detection and Prevention Systems and Antivirus solutions should be implemented as standard practice and will complete the security posture. Of course, these controls need to be actively monitored and tested, preferably continuously. This ensures immediate action can be taken in the case of an attack where some (or all) of the implemented controls are defeated (thus requiring further tuning or hardening).

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

Conclusion

As discussed, both Deserialization Attacks are not new, and neither are attacks aimed at the expansion of a Crypto-Mining botnet. What has certainly been a trend over the last two years, however, is the combination of these two. Although the damage after a successful attack is usually limited, while the system is compromised, the attacker is mere seconds away from deploying a ransomware attack or attempting further penetration into the network. As always, any organization needs to have an exact inventory of the services that are publicly accessible. If this is unclear for any reason, a regular vulnerability test should pick these services up. Only once this picture is complete, a proper attempt can be made to secure and monitor the vulnerable services. These days it is critical to know what is out there and it is just as critical to protect this with all available resources.