Recently Equifax’s web applications were hacked, which resulted in a data breach of millions of user’s personal information. This hack is alarming, as according to recent reports it was a result of a vulnerability in Apache Struts, which is a very popular web development framework used by many developers around the world.
Struts has been around for a while and has been used by companies small and large for development of web applications. When I first started coding web applications in 2006, struts version 1 was the de-facto framework that all web-developers used. It made web application development easy and applied the popular MVC (Model View Controller) design pattern. Design patterns are ‘blue prints’ of implementation in any software development and MVC is one of the most implemented design patterns in web application development.
The MVC design pattern was revolutionary as it provided a very elegant structure to a web application and broke the application down into three parts: Model (for access to database), View (for the user interface) and Controller (for the routing of web requests to appropriate resources).
There are many reasons why Struts has become a very popular web framework, the chief amongst them are:
- Struts is in written Java: As this is a very popular programming language, it’s easy for companies to find developers skilled in Struts and quickly build teams.
- Struts is modular: It builds segregation between front-end developers who are skilled in HTML and backend developers who are experts in data base technologies.
- Struts is open source: Struts started as a project under Apache foundation and has continued to get extensive support of the open source community. It’s robust and free to use.
What Went Wrong?
The exact reason behind the breach at Equifax has yet to be determined, but so far, all eyes are on a vulnerability in one of the plugins in the Struts framework. The Apache foundation in a statement here points out a vulnerability in the REST plugin for Struts that may have allowed execution of malicious code, which then accessed data from internal systems. This statement also tells us that this exploit was discovered in July and is not an unknown vulnerability, i.e. it’s not a Zero Day Exploit.
REST is a very popular format of web-services that allows remote computers and users to interact with a web application. With it, users can perform actions like updating usernames or retrieving user data. The web-service takes data for execution to the server, applies some business logic and responds with results. With the above vulnerability, a hacker can try to replace the data sent to a REST web-service with a malicious script and see if the web-service naively considers it as trusted code and executes it.
In the days to come we’ll find out if the hackers actually used the vulnerability in the REST plugin to hack into Equifax, but if they did, then they were able to send requests to Equifax’s servers to first discover the vulnerability and then exploit it.
What can We Learn?
Considering that the security vulnerability was known before and information to fix it widely available. there are a few questions that arise:
- Did the developers of the hacked application know about the vulnerability?
- Was there a process in place for quick update of the application, in case a serious issue like security holes were discovered?
- Did the company really pay attention to the usage of open source components?
These questions arose because of the breach at Equifax, but these are equally pertinent to any company that is using open source frameworks and tools.
Let’s explore this more by analyzing each of the questions in detail.
Do you monitor software updates, e-mails, forums of the software you use?
Organizations building external facing web-applications know how to build applications, but never have processes around tracking events that occur later with software they use. Major bugs and vulnerabilities fixed in the main open source branches are patched in only when the organization or team themselves runs into an issue around that bug. Security bugs almost never come up on the radar of teams as they never impact the application’s functionality and performance (the two most tested aspects of applications), hence they slip by unnoticed.
What does your patching process looks like? Do you even have one?
If you look at the workarounds recommended by Apache for the vulnerability, you will see that they either suggest changing the code to fix this issue, or require replace Jar files (Java code library files) in the web application. Either of the fixes can’t be rolled out immediately, as each of them require building, testing and deploying the web application all over again. This process is not easy and needs a full release cycle, which might range from a few days to even a year in some cases. So, by the time a vulnerability is discovered, queued for a change and deployed, months can pass. Giving hackers the window of opportunity.
So, it’s a great idea to right now look at your processes and ensure that you have a path to fast track deployment of builds when you have to immediately update your software. I would go as far as to recommend automating the process, i.e. triggering a code update and a build as soon as a security exploit alert is received.
What’s your ‘open source’ evaluation process?
Unlike commercial software that may have dedicated support teams that push updates to you, for open source, you yourself are responsible for maintaining the software and updating it. Often, I come across open source software that caters to the latest technologies but has few contributors and a small user base. As these projects support the latest technologies it’s tempting to use them in your existing stack, but you should keep in mind that a small community and a small set of users also means that this software usually is not well tested, and will have issues and vulnerabilities.
Evaluating Open Source Tools
As a developer, I know using the latest open source projects in your code is tempting, but it’s very important for you to establish a rigorous open source software evaluation process. You should set the right thresholds that determine when and how you would use an open source software in your existing application. Thresholds should be around the age of the software, number of commits and updates, and frequency of bug fixes done by the contributors.
Open source software is free, but a safe and successful implementation needs continuous monitoring, development and patching. You should establish firm processes around open source implementation and maintenance. There is no customer support for open source, so you must support it yourself — not doing this isn’t an option anymore. As the Equifax hack has exhibited, the consequences can be disastrous.