What does a vulnerability scanner look for?

blog + security solutions + Website security + Penetration test Z. Oualid today

Background
share close

Vulnerability scanners are one of the most important tools for both security experts and developers. With the rise in the complexity of software developed around the world, using these tools to automate the process of finding some types of vulnerabilities is becoming necessary. Vulnerability scanners usually use the same techniques to find vulnerabilities, and the only difference between them is the speed and the knowledge database they have. Therefore, what does a vulnerability scanner look for?

A vulnerability scanner looks for six application behaviors:

  • Application crash input
  • Forgotten files
  • User data displaying without modification
  • Strange behavior caused by user input
  • Vulnerable components
  • Default passwords

Those behaviors indicate the existence of a vulnerability in the tested application. Unfortunately, not all types of vulnerabilities can be discovered by provoking those kinds of behaviors in the app. That’s why automated tools are not capable of detecting all vulnerabilities in an application. For more details about why vulnerability scanners cannot discover all vulnerabilities, I invite you to take a look at this blog post.

In this blog post, I am going to explain in detail what each application behavior means and what it does reveal. Moreover, I will give also examples of vulnerabilities that can be discovered based on each behavior. So if you are interested, just keep reading.

Application crash input

Causing an application crash is a very significant indication that something wrong is in the app. Most of the time, crashing a web application is not really so dangerous due to the way those applications work. However, when this happens for a system driver or service that would be very dangerous.

Crashing a system driver or service is itself a vulnerability because most of the time causes a denial of service. However, an advanced exploitation of such a crash leads to giving the attacker remote code execution privileges which lead to full control of the system.

Crashing an application is usually the cause of an unmanagement of exceptions that might be caused by user-controlled data. In the case of a web application, when an exception is created, the webserver displays the tracing of that crash to help debugging it. Unfortunately, this default behavior leads to some serious information leaks (like database passwords, …) that can be used to gain control over the server.

Forgotten files

When the development of a web application is done, most people tend to quickly deploy it in a production environment. This behavior is the main cause of multiple data leaks that an application could suffer from.

When the developer is programming the web application, some of the actions that he may do is to create a file that has passwords, or old codes with different extensions and stuff like this. If those files are not removed before the application gets published, a hacker can download them and use them to attack the application.

Moreover, even when removing all those elements, and deploying the application in the production environment. Webmasters tend to perform full backups of their applications to avoid any future malware attack. This action is recommended and enhances the availability of your application in case of a cyberattack. However, when this process is executed, most of the time the backup files are left in the web server without any protection.

Even if those files are not indexed in your application links, they can be found and downloaded by multiple other techniques.

For this reason, vulnerability scanners try to perform some quick path brute forcing to see if some of those files are in the webserver.

User data displaying without modification

One of the most common behaviors that vulnerability scanners try to perform, is to track user data. Tracking this data has two goals, the first one is to see where these data are displayed in the app. The second one is to see what is the behavior of the app when dealing with this data.

The second goal will be discussed in the next section of this blog post.

Tracking user data to see where it is displayed is usually the default behavior of a penetration tester to look for an XSS vulnerability. When the application receives user-controlled data and displayed it without any filtering, then this is an XSS vulnerability that can be exploited.

 To do that, the vulnerability scanner tries to inject well-identified inputs with special chars and stuff in all the application parameters and then browse all the application pages looking for those inputs. When an input is found displayed without any change, then the parameter where this input was injected is vulnerable.

Strange behavior caused by user input

In more general words, when a user-controlled input causes a strange behavior of an application, then this is a sign of the existence of a vulnerability.

In most cases, the vulnerability scanners that exist in the markets use a knowledge database of multiple inputs that are supposed to create this strange behavior or are proved to be doing it in multiple situations. However, those inputs are not always perfect to detect all sorts of vulnerabilities. In many cases, those inputs should be combined or altered by a security expert to provoke the strange behavior.  

Moreover, with the presence of a Web application firewall, the vulnerability scanner may become useless, as those tests might be blocked by the WAF and not even reach the application.

SQL injection, XSS, XXE, and many more other vulnerabilities can be discovered by looking for such application behaviors.

Vulnerable components

Even when the software developers are aware of vulnerabilities and use the best practices to write a secure code, the application may still be vulnerable because of external components. Modern development technologies are all trying to accelerate the development process. Therefore, using an already developed portion of source code is the idea for that.

However, using a vulnerable code portion also called components can make applications vulnerable. The best example I always give to my students about this part is WordPress.

The WordPress core is really well made and gets audited by the best security experts in the world. However, the plugins that webmasters use in their version of WordPress make it vulnerable and easy to hack.

Even for a hosting system, if the web server uses some outdated services with vulnerabilities, the whole system becomes vulnerable.

Default passwords

As I said in the forgotten files, when software developers start programming a web application, they tend to use easy passwords to quickly log in and debug the application. However, when they try to push their application in the production environment they forget to change those default passwords which puts the whole application in danger.

Vulnerability scanners know that and try to use the known default passwords and easy one perform a quick authentication brute force to gain first access to the app.

Written by: Z. Oualid

Rate it

About the author
Avatar

Z. Oualid

I am a Cyber Security Expert, I have worked with many companies around the globe to secure their applications and their networks. I am certified OSCP and OSCE which are the most recognized and hard technical certifications in the industry of cybersecurity. I am also a Certifed Ethical hacker (CEH). I hope you enjoy my articles :).


Previous post

Post comments (0)

Leave a reply

Your email address will not be published. Required fields are marked *