10 things to do when you can’t fix a vulnerability

Fixing a vulnerability in an application is not always possible, especially when we are talking about big and complex applications. Sometimes, making the fix consume much more money and time that makes it really useless.

I have worked with many clients that were in the same situation and here is the list of what I was doing for them to solve the problem.

Identify the vulnerable component

Before we can even start thinking about the mitigation solutions, we first start by identifying the exact vulnerable component. In a vulnerable application, maybe just one plugin or one speared part of the app is actually vulnerable and by disabling it the app would be protected.

To perform this step you will need to deeply analyze any possible information you may find about the vulnerability in the web. If you were not able to exactly identify the vulnerable component, try to perform a reverse engineering of the vulnerability exploit or the proof of concept (if it is public).

If it is well made, the reverse engineering will definitely give you a lot of information about the vulnerability, the way attackers can reach it, and it could even come up with a mitigation solution.

This is the most critical step in the whole process, as a wrong identification of the vulnerable part of the app, will lead to wrong mitigation techniques and eventually to being hacked. So please take your time here and try to get as much possible information as you can.

Study the risk of the vulnerability

Now that you have identified the vulnerable component, you will need to study the risk of being exploited. Analyzing the risk will give you a clear idea to choose between mitigating the risk or just accepting it.

Before I dig deeper in this subject, I would like you to know that the risk of a vulnerability, change from one company to another.

For example, if two companies use the same CRM application. The company (A) uses it behind multiple layers of firewall in a local network. The company (B) however, has published the CRM directly to the internet without any firewall protection so that their employees can work with it from anywhere.

If one day, a remote code execution vulnerability has been discovered in this CRM, the risk for the company (A) would be way small compared to the risk for the company (B) because of the security mechanisms that the first company use.

The best real example I like to mention here, is the vulnerability MS17-010 that have been disclosed in 2017. Companies that had their SMB published directly on the web, were the first ones that were hacked.

Now, to calculate the risk of the vulnerability you will need to answer the following questions that define the risk of a vulnerability :

• How accessible is the vulnerable component ?
• Does it need to be authenticated ?
• Is the exploit already exists, easy to develop or need advanced techniques ?
• In case of successful exploitation, which part of the following elements will be impacted (Confidentiality, Integrity or availability)?

If you need more information about vulnerabilities risk managements and all the subjects about it, I really encourage you to take a look at the ISO 27005 standard

Check for possible FW configuration mitigation

Let’s suppose that you have analyzed the situation and you figured out that the risk needs to be mitigated. The firewall configuration is in general the easiest and fastest way to mitigate a vulnerability risk inside the network it protects. Therefore, starting with it would be a better idea to quickly mitigate the risk.

Firewall mitigation can be as simple as adding a rule in the firewall to stop any foreign access to the app. Alternatively, adding some kind of signature in a Web application firewall (WAF) to detect and stop any exploitation of the vulnerability.

In most cases, a firewall configuration is necessary, especially when the app is exposed to the internet. Let me give you an example of changes to illustrate this. I will take the same example that I have talked about in the risk analysis step, which is the MS17-010 vulnerability. Now to mitigate the risk of this vulnerability, the first thing you needed to do before applying the patches or doing anything (as at that time the patches were not released by Microsoft) is to add a rule in the firewall to stop access to the SMB system of machines.

Check for possible system configuration mitigation

Once the risk of accessing the machine from the outside of the network is eliminated, you need to start thinking about insider threats. The best solution for this is by making system-based configurations to protect the app. Here is a realistic example of such configuration:

Let us suppose that you have a vulnerable application and that the only way to exploit this vulnerability is by uploading a file in one of the web application folders. Disabling the possibility to upload a file with an extension different from JPG, JPEG or a PNG in the web server configuration is a very good way to mitigate the risk. Disabling the execution of files in that folder is also a good way to mitigate the risk and so on …

I just need you to know that mitigation the risk does not mean eliminating it. Nothing could be compared to patching the system (or removing the component LOL)

Check for possible app configuration mitigation

Sometimes, when the risk is very high for their clients, the vendor itself releases some mitigations techniques related to his solution to gain some time and develop a patch for the vulnerabilities. The application-based configuration could be sometimes difficult to perform, as we do not know exactly the impact of that change and the rollback is even harder.

An example of such possible configurations could be illustrated by the previous situation of a web application that allows the upload of files with the dangerous extension. A good possible application-based configuration is simply disabling the upload functionality. This could easily be made for example in a WordPress-based website that has a vulnerable plugin.

To be honest the application-based configuration is very rare especially in non-popular complex apps. Therefore, I recommend putting much effort in firewall and system based configuration to mitigate the risk, and only thinking about the app to eliminate it.

Study the possibility for temporary replacement

Now that you have put in place one of the previous mitigation solutions, you need to start thinking seriously about the possibility to replace the solution by something else temporary until the patch is released. This situation could be seen, as unrealistic but trust me, I have seen some situations where the best solution was to replace the whole application with a brand new one rather than developing a patch.

I think that this does not need an example because it is all about the cost of developing a patch versus developing a brand new app with new more secure technologies.

That’s why you should think seriously about the possibility to change the app in case no fixes were published or in case of the cost was very high.

An example of such switch in a website for example, is to use a different CMS than the vulnerable one, while keeping the old URLs in the new website or configure a redirection.

Study the possibility to stop the whole service

Sometimes, if the user application is not that important and stopping it for a while would not have a big impact on the production, then why not. This solution must be studied carefully as stopping an application or a service, will definitely affect the production directly or indirectly.

For the direct impact I think that things are clear, if you have an application that performs some automatic jobs like tacking periodic backups, then stopping it for a while will need that your employees start performing these tasks manually, which will reduce their productivity. Or for example, if you have a stock management system and you need to stop it then, you will start to work using papers and stuff … which definitely impacts the production.

Now for the indirect impact, let us say you have an application that your employees use to ask for holidays. If this app goes down, then of course the production system will not be directly impacted but the production of your employees will be reduced because they will need to write a sort of paper and take it to the administration and so on, which is a waste of time that can be put in production.

Isolate the vulnerable system

One of the most important things that you need to perform in this process is the isolation of the vulnerable application from the rest of the local network. The isolation of the vulnerable application depend mainly on the nature of that application.

For example, If the application is only used by some known users in the local network, then all you need to do is to put the application in an isolated environment (using your internal firewall rules for example) and then restrict the foreign access to only the allowed users. Do not forget to also block internet access from the vulnerable application.

To be honest, the isolation technique is not always possible or easy to do, and the simplest example is when you have a website that must stay online and available for internet users, then the situation becomes really difficult, but not impossible.

In this situation, what you can do is actually trying to isolate the application in a separated host, and then disconnect it from the local network. In addition, you can move all the data from the local host database to another backup server and leave only the necessary data for the app to work correctly.

Monitoring

I think between all the steps I have mentioned in this article, this one is the most critical and the one that you need to put in place no matter what. Either there is a disclosed vulnerability or not monitoring your website or your system is a must.

What you need to keep in mind is that the vulnerabilities that exist in the wild are not only the published ones. Each day many zero-day vulnerabilities are discovered and exploited by hackers around the world. Therefore, monitoring your website to detect and stop those vulnerabilities is very important to keep your application and data safe.

Monitoring a web application or a system in general, is not a simple and easy task to do for many reasons :

1. You need to keep monitoring your apps and systems 24 hours and 7 days a week
2. You need to have a good tool that have a very low false positive rate other ways it will become useless.
3. You will need to have the right skills to analyze those alerts and perform the right actions in time.

Monitoring is really a very big topic and I will not be able to discuss all the details about it in this article. I may write a new one about it in the future, please let me know in a comment if you want me to talk about it.

If you take a look at my recommended tools page you will see the list of monitoring tools that I recommend for small, medium and big companies.

Make the backup period shorter

One last thing that you can do to reduce the risk is related to the backup system. You can lower down the period between each backup, this way even if a hack happens and your data have been encrypted, you will quickly be able to recover from the attack and deploy the database.

Of course doing this, will not reduce dramatically the risk of an attack, but it will help you recover faster in case of something happens. You can take a look at the recommended tools page to get an idea about the tools that I recommend for this step.