"The trust of the innocent is the liar's most useful tool.” - Stephen King
This blogpost has been written in the wake of the potentially earth-shattering discovery of security vulnerabilities in some key Java libraries. In case you are unaware of these security issues, you must 1. go through the link in the footnotes, 2. start screaming in despair and 3. continue reading this post for possible solutions.
In any case, let me give you a quick description of what I am talking about.
If anyone has written Java code, they would be familiar with a practice called Serialization - Deserialization. This is a process where an objects and/or data structures are converted to streams to transport these streams to a client/server to be processed. This process is reversed when Deserialization occurs. The stream is converted back into the object/data structure, processed and consumed by an application on the receiving end of the communication. FYI, this process is widely prevalent in Ruby, PHP, Python, etc, not only Java. In Java, this practice is used heavily by all kinds of apps including Jenkins, JBoss, Websphere, OpenNMS and so on. This is used across various Java implementations. Typically, the serialized object is sent over the wire to the receiving system. The receiving system uses a method like readObject() or similar to process the data. The data is deserialized as a Java Object and consumed, by either writing to Disk, DB, OS, etc. This is where it gets interesting…. What if an attacker loads malicious code, serializes it and sends it over the wire to the receiving system, the receiving system would deserialize the (malicious) object, process the object and write it to disk or worse, to the OS? Turns out that this is not only possible, but is highly probable and has the makings of a security disaster. This vulnerability would be way worse if it happened with a library that was commonly used. Turns out, that it is. The “commons-collections” library from Apache is (as the name suggests) is an extremely common Java library that is used in several apps, like the ones mentioned above. I am quite sure, at some level your Java app could be using this as well. This is a very very serious security vulnerability for both your app as well as the components you are hosting it on.
Unfortunately, this has become all-too-common with Software Libraries. We use thousands of libraries in our code (across languages) and libraries make a developer’s life much easier, because much of the low-level stuff is abstracted away from the developer and she can focus on developing quality apps. However, the problem really arises when the library itself is vulnerable to attacks, which in turn renders your app vulnerable. In my trainings on App security, one of the key questions I ask developers is “Do you know what vulnerabilities are present in your software libraries?” I see about 50% having no clue for this question and the second question “Do you know how to handle these vulnerabilities?” and the number having no clue has increased multifold. This problem has only aggravated with modern “agile” lifecycles with continuous deployment and continuous integration. The understanding of software library vulnerabilities has not keep pace with the scale and frequency of application development lifecycles. This unfortunately affects any programming language, not to spare the mobile paradigm as well.There are some simple but powerful ways of preventing and detected this issue of insecure libraries.
Developer Awareness
This is the foundation of identifying and weeding out security vulnerabilities in software libraries. If developers are aware of how they can spot and remediate vulnerabilities in libraries, these vulnerabilities can be reduced by a significant margin. This involves a bit of process and a bit of technology. Process being namely, managing library inventory, regular updates from NVD, CVEdetails and so on. Often there may be a scenario that the library is integral to the application. In such cases, developers can create compensating controls. For instance, in the Java Serialization vulnerability, developers can create functions that validate size, type and instance to prevent third party malicious code from deserialization and processing.
Continuous (Security) Integration
Today, Continuous Integration is becoming the way to go for most application development houses. Integrating security into this cycle, especially by way of identifying insecure libraries is of paramount importance.
Including specific checks in Pentesting
One of the ways that companies can really leverage penetration tests, is by focusing on identifying and reporting insecure libraries. This may require an increase in terms of scope (reviewing library inventory), but its well worth the effort as you would get a holistic inside-out perspective.
Conclusion
Insecure Software Libraries has been in the OWASP Top 10 list since the year 2013. However, with the rapid increase in complexity and size of the average application, this requirement gets lost in the ether. Software Libraries are an integral aspect of your application’s functionality. Its time that they are an integral part of your application’s security focus as well.Link: Java Serialization Vulnerabilities: http://bit.ly/1L1cPOg
