2015: Remote code execution for everybody!
If you are reading this, you survived 2015. And to say the least, 2015 was hectic.
Several big vendors have been publicly shamed due to the public disclosure of critical vulnerabilities within their software and appliances. We have seen vulnerabilities such as Shellshock and the Java Deserialization vulnerability pop up and by doing so, gently shaping the IT security landscape and subtly changing the methods used to perform and deliver up-to-standard penetration testing assignments. This blog post will basically be a recap of some #infosec highlights of last year.
The Shellshock/Bashdoor vulnerability has paved the way for a fast and efficient way of distributing ELF based malware targeting *nix servers. This has been made possible due to the simple yet destructive nature of this vulnerability. What made this vulnerability one to be remembered is the fact that not only webservers can be targeted, but basically every server that invokes a BASH terminal at one point was/is vulnerable. This entails FTP servers, SSH servers (post authentication), DHCP servers, but also embedded *nix-based operating systems that are used in the upcoming IoT appliances are vulnerable. The overall easiness of exploiting this vulnerability and the dire consequences made Shellshock a vulnerability that will not be easily forgotten.
Whereas Shellshock received massive amounts of media attention and was patched fairly quickly, the next vulnerability we will be discussing remains unpatched and wasn’t covered in any mainstream media outlet. Foxglove Security released several pre-authentication exploits on the 6th of November, which could be abused by an attacker to leverage remote code execution circumstances on, but not limited to, Jenkins, Jboss and Weblogic. The vulnerability itself resided in the fact that Java application output has to be converted into binary before writing away the output to disk or when said output needs to be transported over a network. This conversion is named serialization and the conversion can go both ways, meaning converting back data after serialization is called unserialization. Certain applications accept serialized user supplied data and proceed to unserialize all untrusted data, including dangerous commands supplied by the attacker. This vulnerability was found in one of the most widely used Java libraries called ‘common’, which means that any reachable web application or application server that is bundled with the commons library can be exploited.
Security Researchers and cybercriminals have also been actively targeting popular Content Managing Systems such as WordPress, Joomla and Drupal in 2015 and this has led to multiple public disclosures of critical vulnerabilities such as SQL injections and Remote Code Execution vulnerabilities. However, one vulnerability found within Joomla this year stood out, but how has this crucial and seemingly easy-to-exploit vulnerability manifested itself in a widely used CMS? Well, whenever a user visits a Joomla based web application, a user session is established and by default, these user sessions are stored in the web application’s database. So wait, does this mean that session data can be tainted by user input, for example by editing the User-Agent header, and that we can store the manipulated session data into a database? This seems like a recipe for a disaster. And a disaster it was; the remote code execution vulnerability that was found in Joomla on the 14th of December was 2 days before the public disclosure already heavily exploited in the wild.
It is safe to say that 2015 must have been a spectacular year for malicious actors and script kiddies all around the world due to the widespread availability of easily exploitable vulnerabilities that have had huge implications on the targeted web applications and associated businesses.