Vulnerabilities you should prioritize while fixing

Every time I give my penetration test report to my client to start fixing their vulnerabilities, the first question they ask, is which one we should prioritize in our fixing plan?

Here are five types of vulnerabilities that need to be prioritized while fixing the discovered ones, ordered by criticality:

1. Remote code execution
2. Unrestricted File upload
3. Injections
4. Business logic
5. Information leak

Remote code execution

One of the most dangerous vulnerabilities that a hacker could discover in any kind of app including desktop applications, is remote code execution. The remote code execution vulnerabilities could happen due to multiple reasons. One of the most popular ones is insufficient user input validation. To better understand this type of vulnerability and what it can do to your system, let me give you some examples of popular ones.

The first one that comes to my head while writing this article is the Buffer overflow. Man, this is the most critical one in the industry, and it can be found in any kind of application even machine drivers. This vulnerability happens, when the user input length is not controlled. This lack of verification gives the attacker the ability to control the application execution flow while injecting malicious codes.

What makes this vulnerability even more dangerous is that the injected malicious code will be executed by the app privileges. Therefore, if the app is executed with administrator privileges, then the malicious code will be also executed with those privileges, which means full control over the server.

In most cases, this is what happens if a remote code execution vulnerability exists in the application. Therefore, if this vulnerability is detected, it has to be fixed as fast as possible and should be prioritized over all the other ones, especially if it can be exploited without any authentication.

Unrestricted File upload

The unrestricted file upload vulnerability happens when the file upload system in a web application fails to verify the file type or relay on user input to verify it. This weak file type verification gives the attacker the possibility to upload some malicious files, which in most cases gives the attacker the possibility to do remote code execution and take control over the server.

Therefore, you should start fixing this vulnerability as soon as it is discovered, even before the penetration test finishes if it is possible.

Let me give you an example of this vulnerability to better illustrate the way a hacker could exploit it. Let’s say you give your users, the ability to upload their CV, to apply for some kind of job. To upload the CV you ask them to upload a PDF or a word file. However, this is only specified in a kind of message to the user, but nothing is verified in the backend. Then the attacker uploads a .php file that has a malicious code that is going to be used as a backdoor for easy access.

Actually, this vulnerability is very popular, I really don’t know why it does not show in the owasp top 10, but it really should be there in my opinion. Maybe they didn’t put it there just because the number of web applications that offer the file upload functionality is very small compared to the other ones.

Injections

One of the most critical types of vulnerabilities that in general lead to Remote code execution are the ones related to Injections. This type of vulnerability happens when the user input is directly injected into the source code of the legitimate application. You will better understand this type of vulnerability once I give you some really popular ones that belong to this type of vulnerabilities.

The first example of such vulnerability is SQL injection. This vulnerability happens when the user input is directly injected into a legitimate SQL request without any filtering. This injection gives the user the possibility to inject malicious SQL requests into the application to read for example the application database, to alternate the user information, and so on… In some cases, the impact of the sql injection can go even deeper by taking control over the whole server.

Another very critical vulnerability that belongs to the same type, is the XSS vulnerability. This vulnerability happens for the same reason as most previous vulnerabilities, NO USER INPUT FILTERING. The impact of the XSS vulnerability could go from as simple as user session hijacking to full control of the client machine in some situations.

The Injections vulnerabilities not only have an impact on the application but even, on the reputation of the application in the market. Imagine that your app has an XSS vulnerability and that it was successfully exploited by some hacker, and every time someone’s trying to get access to the web application, he will get redirected to some other malicious website.

Therefore, once you discover this kind of vulnerability, you should not wait to fix it as soon as possible, otherwise, the impact would be very important.

I know I didn’t speak about the other more critical vulnerabilities, but this is just because I wanted to give more popular examples to better understand the idea. However, there are other more critical vulnerabilities that could lead to RCE. I may discuss this in the next posts.  

Business logic

Some business logic vulnerabilities have some direct impact on the application income, which leads to critical losses. This type of vulnerability is in general very difficult to find as it needs a deep understanding of the application logic.

Let me give you an example of such vulnerability to better understand the situation. Let’s say you have an e-commerce website, where you sell some products. If there was a vulnerability in the application that gives the attacker the possibility to buy any item for 1$ then, this would lead to some important income losses. So the fastest you fix this type of vulnerabilities the less money you lose

Information leak

The information leak vulnerabilities are also very common on the web, and they can result from very simple actions performed by the developers of the app. For example, if the developer or the website master, perform a backup of the whole app and forget the zip file in the webserver. Then if someone finds this file, all the data and the application source code will be leaked.

In most cases, this type of vulnerability is very easy to solve, it could be just removing files or disabling the error display. So maybe you could start with it too if it is a quick win for you.