Kali Linux: types of checks of information systems / Blog of the company RUVDS.com

→ Part 1. Kali Linux: security policy, protecting computers and network services
→ Part 2. Kali Linux: filtering traffic using netfilter
→ Part 3. Kali Linux: monitoring and logging
→ Part 4. Kali Linux: exercises to protect and monitor the system
→ Part 5. Kali Linux: assessing the security of systems We

continue to publish the translation of the 11th chapter of the book “ Kali Linux Revealed ”. Today we want to introduce you to section 11.2, which is devoted to the types of activities aimed at assessing the security of information systems.

11.2. Types of measures for assessing the security of information systems

Once your OS is ready to go, it's time to pinpoint exactly what kind of research you are going to do. In general, four types of such studies can be distinguished:

• Assessment of system vulnerability;
• Evaluation of systems for compliance with safety standards;
• Traditional system penetration testing;
• Research applications.

A specific task to study the system may include various elements of each type. We believe that it is worth telling more about them and revealing their connection with Kali Linux and with the working environment.

Before proceeding to the description of specific types of measures for assessing the security of systems, we will talk about how vulnerabilities differ from exploits.

Vulnerability can be defined as a defect in the information system, using which it can violate its confidentiality, integrity or availability. There are various types of vulnerabilities that can be encountered. Here is some of them:

• Vulnerability to include files . This class of vulnerabilities allows an attacker to include local or remote files in the process of calculations performed by the program. For example, a web application may have a Message of the Day function that reads the contents of a certain file and includes it in a web page in order to show it to users. If mistakes were made during the development of such a function, it can allow an attacker to modify the site’s request in such a way that the web application, instead of a useful file, connects a file prepared by the attacker to the page.
  
• Possibility of SQL injection. An attack of a vulnerable application using SQL injection is a situation where an attacker bypasses the subsystem for checking data entered by users. This allows him to enter his own SQL commands that the attacked system will execute. This can lead to security problems.
  
• Possibility of buffer overflow . This is a vulnerability that allows an attacker to bypass the input control subsystems and write data to a memory area that is adjacent to the memory allocated for a buffer. In some cases, the memory areas near the buffer can be extremely important for ensuring the health of the attacked program. With the correct manipulation of the data stored in these areas, you can gain control over the execution of the application code.
  
• System susceptibility to race condition . This is a vulnerability whose exploitation is based on the use of time dependencies in programs. In some cases, the application workflow depends on the execution of certain actions in a certain sequence. If you change this sequence of events, the program can be made vulnerable.
  

An exploit, on the other hand, is a program that, if applied, can take advantage of a specific vulnerability, although not all vulnerabilities can be exploited in this way. Since an exploit must change an ongoing process, forcing it to perform unforeseen actions, creating exploits can be challenging. Moreover, modern computing platforms have a number of technologies to counter exploits that complicate their development. Among these technologies is Data Execution Prevention (DEP) and Address Space Layout Randomization, ASLR). However, if for some vulnerability it is not possible to detect a publicly available exploit, this does not mean that such an exploit does not exist, and also that it cannot be created. For example, many organizations sell specially designed exploits that are not publicly available. Therefore, all vulnerabilities should be considered as potentially exploitable.

Now let's talk about various types of measures for assessing the security of systems.

11.2.1. System Vulnerability Assessment

Recall that a vulnerability is a defect in an information system that can be somehow used to violate its confidentiality, integrity, or availability. When conducting a system vulnerability assessment, your goal is to create a list of vulnerabilities discovered in the target environment. The concept of “target environment” is very important in assessing the security of systems. You must not cross the boundaries agreed with the client. This means - to carry out work within the target network and not deviate from the objectives of the study. Going beyond the boundaries of the investigated environment, the boundaries of which are agreed with the client, can lead to disruption of the client’s services, to the loss of his trust, or to a lawsuit against you and your employer.

The study of system vulnerabilities, due to its simplicity, is often performed on a regular basis in fairly mature environments. This is done as part of a demonstration of their level of security or their compliance with certain safety standards.

In most cases, automated tools, such as those found in the Vulnerability Analysis and Web Applications groupson the Kali Tools website, or in the corresponding sections of the Applications menu on the Kali desktop, they are used to detect computers working in the target environment, to identify services that listen on certain ports and analyze them. This is done to collect as much information about the system as possible. This information includes information about hardware platforms and server software, versions of operating systems and applications, and other information.

Then, the collected information is checked for known vulnerability signatures. These signatures consist of combinations of pieces of data that allow you to recognize known security issues. It uses as much information as possible, since the more it will be, the more accurate will be the identification of the vulnerability. There are many indicators of interest in analyzing system vulnerabilities. Among them, the following can be noted:

• Version of the operating system. It often happens that a certain application is vulnerable in one version of the OS, but there is no such vulnerability in another. That is why the scanner will try to determine, as accurately as possible, on which version of the operating system the target application is running.
  
• OS patch level. Patches for operating systems often come out during the installation of which the OS version does not change, although the known vulnerabilities either disappear or begin to behave differently than before.
  
• Processor architecture. There are many applications available for different processor architectures, such as Intel x86 and Intel x64, for different versions of ARM, for UltraSPARC, and so on. In some cases, the vulnerability exists only on a specific architecture, therefore, knowledge of the processor architecture can play an important role in the formation of an accurate signature of the vulnerability.
  
• Software version. The version of the target software is one of the main indicators that must be obtained to identify the vulnerability.
  

After collecting information, these, and many other indicators, will be used to generate vulnerability signatures. It is quite expected that the more pieces of data coincide with the signature, the more confidently we can talk about the discovered vulnerability.

By comparing the collected data with signatures, you can get different results:

• Positive result. The signature matches the vulnerability profile, a vulnerability has been detected in the system. Having obtained a similar result, you need to tackle the source of the problem and fix the vulnerability, since this is exactly what an attacker can use to harm the organization under study.
  
• False positive result. During the analysis, it was possible to find a match with the signature of the vulnerability. However, what is found is not a vulnerability. Such results are usually considered "information noise", they complicate the work. In order to clearly distinguish between true and imaginary vulnerabilities, a deeper analysis of the situation is required.
  
• Negative result. After scanning the system for matches with known signature vulnerabilities could not be detected, therefore, there is no vulnerability in the system. This is an ideal scenario proving the absence of known vulnerabilities in the target system.
  
• False negative result. Signature matches could not be found, but there is a vulnerability in the system. There is nothing good in getting false positive results, but a false negative result is much worse. In such a situation, the researcher has no signs of vulnerability, since the scanner does not find it, but, in fact, the problem exists.
  

It’s easy to understand that signature accuracy is extremely important to ensure reliable system scan results. The more data that can be collected, the higher the quality of the results of the automatic signature-based scan. That is why scanning with pre-authentication in the system is very popular.

With this approach, the scanning software uses the data provided to the specialist for authentication in the target system. This provides data analysis capabilities that are not available in other conditions. For example, with a conventional scan, it is realistic to get only information about the system, which can be extracted from the analysis of services that are accessible from outside, and from the analysis of the functionality provided by them. Sometimes such a scan allows you to collect a lot of data. But this information cannot be compared to what you can learn about the system by going into it and carefully analyzing all installed software, applied patches, running processes, and so on. Collecting such extensive data about the system is useful for finding vulnerabilities that, otherwise, could have remained undetected.

A well-conducted vulnerability study provides a report of potential problems and indicators that can be used to analyze changes in the situation over time. This is a fairly simple study, but even with this in mind, many organizations regularly conduct automatic vulnerability scans. This is usually done during hours of minimal load on the system, since scanning can require considerable network and server resources and interfere with the normal work of the organization.

As already mentioned, during the scanning of systems for vulnerabilities, it is necessary to check many different pieces of data in order to get accurate results. All of these checks can put a strain on the target system and the network. Unfortunately, it is difficult to know in advance how many resources will be consumed, since this depends on the number of running services and the types of checks that will be associated with these services. Scanning consumes system resources, therefore, when using appropriate tools, it is important to imagine what kind of load they can create on the systems and networks under study.

▍ Multi-threaded scanning

Most vulnerability scanners support the setting of the number of threads allocated to perform a scan task. It is about how many checks will be performed at the same time. An increase in the number of scan threads leads to an increase in the load on the researcher’s computer, network, and target systems. It is tempting to speed up the scan by increasing the number of threads, but it is important to remember that this can lead to a significant increase in the load on the system.

When the scan is completed, the detected vulnerabilities are usually associated with standard identifiers, such as CVE numbers , EDB-IDs , or vulnerability classification codes accepted by the scanning tool providers. This information, together with CVSS vulnerability assessment information , is used to determine the level of risk. All this information, taking into account false-positive and false-negative messages about vulnerabilities, gives a general idea of ​​vulnerabilities that must be taken into account when analyzing the results of scanning.

Since automated tools are used to identify vulnerabilities in a signature database, the slightest deviation from a known signature can change the result, and, accordingly, the validity of messages about detected vulnerabilities.

False positive results indicate what is not, and false negative, on the contrary, hide existing problems. Therefore, the quality and capabilities of automatic vulnerability scanners directly depend on the signature databases they use. As a rule, suppliers of such software offer different versions of their programs. Some of them are free, equipped with stripped-down databases, designed for home users. Others are quite expensive, with full-fledged databases, usually oriented to the corporate sector.

Another problem that often arises when scanning for vulnerabilities is the suitability of using the proposed risk ratings. These ratings are determined on a universal basis, taking into account many different factors, such as the level of privileges, the type of software, the ability to implement vulnerabilities before or after authentication. Such ratings cannot be used thoughtlessly, since their value depends on the characteristics of the system under study. Qualitatively assessing the level of risk can only be done using those ratings based on the analysis of detailed information about the system and the vulnerabilities found in it.

There is no single universally accepted agreement on risk ratings, however, it can be recommended to take the standard as a basis for risk assessment in the studied environmentNIST SP 800-30 . NIST SP defines the real risk of a discovered vulnerability as a combination of the possibility of a threat and the level of impact on the organization when a threat occurs.

▍11.2.1.1. Threat Possibility

According to NIST, the possibility of a threat is based on the likelihood that the source of the threat, a potential adversary, is capable of exploiting a specific vulnerability. In this case, the possibility of implementing a threat is assigned one of the possible ratings: low, medium or high.

• High level. A potential adversary is highly qualified and motivated, measures taken to protect against the use of vulnerabilities are insufficient.
  
• Middle level. A potential adversary is motivated and qualified, but measures to protect against the exploitation of vulnerabilities can impede his success.
  
• Low level. A potential adversary is unskilled or lacks motivation, while measures have been taken to protect against the use of vulnerabilities, which are partially or absolutely effective.
  

▍11.2.1.2. The level of impact on the organization in the implementation of the threat

The level of impact on the organization during the implementation of the threat is determined by assessing the amount of damage that the use of the analyzed vulnerability can cause.

• High level. Using the vulnerability can lead to significant financial losses, can seriously damage the mission or reputation of the organization, can result in serious material damage or loss of life.
  
• Middle level. Using the vulnerability could result in financial loss, damage to the mission or reputation of the company, or, in the case of the human resources of the company, result in personal injury.
  
• Low level. Using the vulnerability could result in some financial loss or impact on the company's mission or reputation.
  

▍11.2.1.3. Risk assessment

Once the possibility of a threat and the level of its impact on the organization are clarified, one can assess the level of risk (low, medium, or high), which is expressed as a function of the two indicators found. The risk level indicator allows you to create an action plan for those who are responsible for protecting and supporting the analyzed system.

• High level. There is a serious need for additional measures to protect against vulnerability. In some cases, you can allow the system to continue to work, but you need to prepare a plan for its protection, which should be implemented as soon as possible.
  
• Middle level. There is a need for additional measures to protect against vulnerability. A plan to implement the necessary protective measures must be implemented within a reasonable period of time.
  
• Low level. The owner of the system will determine for himself whether to implement additional measures to protect against vulnerability, or to take the detected risk and leave the system unchanged.
  

▍11.2.1.4. Final events

The risk indicator of the discovered vulnerability forms many factors, therefore, ratings obtained from automatic scanning systems should be considered only as a starting point in determining the real risk.

Based on the results of vulnerability assessment, reports are compiled. Such reports, created competently and professionally analyzed, lay the foundation for other studies, such as evaluating systems for compliance with safety standards. It is important to extract all that is possible from the results of the vulnerability assessment.

Kali is an excellent platform for conducting vulnerability assessments; the OS does not need to be specially configured for this. You can find many vulnerability analysis tools in the sections of the Applications menu. In particular, we are talking about the sections Information Gathering (Information Collection), Vulnerability Analysis (Analysis of vulnerabilities), and Web Application Analysis (Analysis of web applications). You can find out more about using Kali Linux for vulnerability analysis on the Kali Linux Tools website, on the Kali Linux official documentation site , and by reading the free Metasploit Unleashed course .

11.2.2. Evaluating systems for safety

The next most difficult type of research is the assessment of systems for compliance with safety standards. Such system tests are the most common, as they are based on testing the requirements prescribed by state and industry standards that apply to organizations.

There are many specialized security standards, however, Payment Card Industry Data Security Standard ( PCI DSS ) is most commonly found . This standard is developed by payment card companies. Organizations processing card payments must comply with it. If we talk about other common standards, it can be noted such as Defense Information Systems Agency Security Technical Implementation Guides ( DISA STIG), Federal Risk and Authorization Management Program ( FedRAMP ), Federal Information Security Management Act ( FISMA ), and others.

A corporate client can order a similar study or apply for the results of a previous study for various reasons. In particular, the initiative may come from the client himself, or he may be forced to conduct a mandatory audit. In any case, such studies are called "assessing systems for compliance with safety standards," or "studies for compliance with safety standards," or "checks for compliance with safety standards."

Evaluation of a system for standards usually begins with a vulnerability analysis. In the case of the audit procedurefor compliance with the PCI standard, vulnerability assessment, if conducted appropriately, can satisfy several basic requirements of the standard. Among them is requirement 2: “Do not use passwords and other system parameters set by the manufacturer by default.” Analysis of the system for compliance with this requirement can be carried out using the tools from the menu category Password Attack (Hacking passwords). Further, this requirement 11: “Regularly test security systems and processes.” The corresponding check can be carried out using the tools from the Database Assessment category. Some requirements cannot be verified using conventional vulnerability scanning tools. Among them is requirement 9: “Restrict physical access to cardholder data”, and 12: "Develop and maintain an information security policy for all personnel of the organization." Verification of such requirements requires additional efforts.

At first glance, it may not seem quite clear how to use Kali Linux to perform some checks. However, Kali is great for solving such problems, and not only because of the rich set of standard tools, but also because it is based on Debian, which opens the possibility of installing many additional applications. You can search for programs that implement the necessary functionality in the package manager using keywords taken from the information security standard used. A similar search will almost certainly result in several noteworthy results. Currently, many organizations use Kali Linux as a platform specifically for assessing systems for compliance with security standards.

11.2.3. Traditional System Penetration Testing

Recently, it has become difficult to find a suitable definition for a “traditional penetration test”. The fact is that such tests are used in various fields of activity, as a result, everyone describes them in their own way. The confusion also adds that “penetration testing” has increasingly come to be called the assessment of systems described above for compliance with security standards, or even the usual assessment of vulnerabilities. In such cases, the study does not go beyond some minimum requirements.

In this section, we will not touch on disputes about the features of various types of system tests. Here we will talk about studies that are not limited to certain “minimum requirements”. These are studies that are designed in such a way that after their implementation it would be possible to truly improve the overall security of the organization.

In contrast to the types of studies that we discussed earlier, traditional penetration tests do not often begin with a definition of the area of ​​study. Instead, they set specific goals. For example: “simulate the consequences of compromising an internal user”, or: “finding out what would happen if the organization came under a targeted attack by an external attacker.” A key distinguishing feature of such studies is that, during their implementation, they not only find and evaluate vulnerabilities, but also use the problems found to uncover the worst-case scenarios.

Penetration testing does not rely solely on systems scanning tools for vulnerabilities. The work continues by examining finds, by using exploits or tests to rule out false positives, everything possible is done to detect hidden vulnerabilities, or what we call false negative results.

Such research often involves exploiting the vulnerabilities discovered, evaluating the access level provided by the exploits, and using this increased access level as a starting point for additional attacks on the target system.

This requires a critical analysis of the target environment, a manual search for vulnerabilities, creativity, and the ability to think outside the box. All these are approaches to detecting additional vulnerabilities that require other tools that can find vulnerabilities where the capabilities of the most powerful automatic scanners end. Often, after completing this step, the whole process begins again and again in order to ensure complete and high-quality performance of the work.

Despite the complexity and versatility of traditional penetration testing, the course of such a study can be streamlined by dividing it into several steps. It is worth noting that Kali simplifies the selection of software for each of these steps. So, here is a step-by-step penetration testing plan with comments on the tools used:

• Collection of information. In this phase, Pentester’s efforts are aimed at learning as much as possible about the target environment. Usually this activity is non-invasive and looks like normal user activity. These actions form the basis for the remaining stages of the study, and thus they should lead to the collection of the most complete data about the system. The Information Gathering section of the Applications menu of Kali Linux contains dozens of tools designed to reveal as much information as possible about the system under study.
  
• Vulnerability Detection. This step is often called "active collection of information." Trying to identify potential vulnerabilities in the target environment, the specialist does not yet attack the system, but already behaves differently from the usual user. It is here that the above-described system scan for vulnerabilities often takes place. At this step of the research, programs from the sections Vulnerability Analysis, Web Application Analysis, Database Assessment, and Reverse Engineering will be useful.
  
• Exploitation of vulnerabilities. Having a list of potential vulnerabilities discovered, at this stage of the study, the specialist tries to use them to find a foothold in the target environment. In this case, useful tools can be found in the categories Web Application Analysis, Database Assessment, Password Attacks, and Exploitation Tools.
  
• Penetration into systems and discreet data retrieval. After the researcher managed to gain a foothold in the system, you need to move on. As a rule, at this stage they are looking for a way to increase privileges to a level corresponding to that which is necessary to achieve target systems that were previously inaccessible and secretly extract secret information from them. In this step, you can access application menu sections such as Password Attacks, Exploitation Tools, Sniffing & Spoofing, and Post Exploitation.
  
• Preparation of reports. After completing the active phase of the study, you need to document the actions taken and prepare a report. Usually this step does not differ in the same technical complexity as the previous ones. However, thanks to high-quality reports, the client can get the full return on the work done, so do not underestimate the importance of this stage of the study. Relevant tools can be found in the Reporting Tools section of the Applications menu.
  

In most cases, penetration tests will be arranged in completely different ways, since each organization will be exposed to different threats and have different resources that need to be protected. Kali Linux provides a universal base for solving such problems, it is here that you can take advantage of the many options for configuring Kali. Many organizations that do this research support customized versions of Kali LInux for internal use. This allows them to accelerate the deployment of systems before a new study.

Among the frequently encountered additional Kali Linux settings are the following:

• Preinstall licensed commercial packages. For example, there is a package, such as a paid vulnerability scanner, which is planned to be used during many penetration testing sessions. In order to avoid the need to install this package on each deployed copy of Kali, you can integrate it into the system. As a result, this package will be installed every time you deploy Kali.
  
• A preconfigured virtual private network with reverse connection. This is a very convenient feature for devices that intentionally leave connected inside the network under investigation. Such devices allow for “remote internal” research. A device with a reverse connection function connects to the Pentester computer, creating a tunnel that can be used to connect to internal systems. The Kali Linux ISO of Doom distribution is an example of just such a special system setup.
  
• Pre-installed tools and programs of your own design. Many organizations have in-house toolkits that are necessary during penetration testing sessions, so their pre-installation when creating a special image of the system saves time.
  
• Pre-configuration of the OS configuration, including setting up the mapping of host names to IP addresses, desktop wallpaper, proxy server settings, and so on. Many Kali users prefer special system settings . If you intend to regularly reinstall the system, saving such settings may make sense.
  

11.2.4. Application research

Most measures for assessing the security of systems are quite large. A feature of application research is the fact that a particular program is being studied. Such studies are becoming more common due to the complexity of the vital applications used by companies. Many of these applications are created in-house by these companies. If necessary, application research may accompany other types of research. Among the types of applications that can be investigated for security, the following can be noted:

• Web applications. These applications are often targeted by cybercriminals, since they, usually having a significant attack surface, are accessible from the Internet. Standard tests often reveal the underlying problems of web applications. However, a more detailed study, although it may take a lot of time, allows you to find hidden application defects. To conduct such tests, you can use the meta-package kali-linux-web, which contains many useful tools.
  
• Desktop applications distributed as executable files. Server applications are not the only target of attackers. Desktop applications are also vulnerable to attacks. Over the years, many desktop programs, such as PDF readers, or video applications that use Internet resources, have been subjected to many attacks, which led to their improvement. However, there are still many desktop applications in which, with the right approach, you can find a lot of vulnerabilities.
  
• Mobile applications. With the growing popularity of mobile devices, mobile applications are becoming a constant subject of security research. These applications are developing and changing very quickly, therefore in this area the research methodology has not yet reached sufficient maturity, which leads to the regular, almost weekly, appearance of new techniques. Tools related to the study of mobile applications can be found in the Kali Linux Reverse Engineering application menu section.
  

Application research can be done in a variety of ways. For example, to identify potential problems, you can use an automated tool designed to test a specific application. Such automatic tools, based on the features of the application, try to find unknown weaknesses in them, instead of relying on a set of predefined signatures. Tools for analyzing programs should take into account the features of their behavior. Here, for example, is the popular Burp Suite web application vulnerability scanner . During the research of the application, he finds the fields for entering data, after which he performs various attacks using the SQL injection method, watching the application at that time in order to identify attacks that have been successful.

There are more complex application research scenarios. Such studies can be performed online. When they are used, models of black and white boxes are used.

• Black box research. A tool (or researcher) interacts with the application without possessing special knowledge about it, or with special access to it that exceeds the capabilities of an ordinary user. For example, in the case of a web application, a researcher can only have access to functions and capabilities open to a user who is not authorized in the system. Any account used will be the same that a regular user can register on their own. This will prevent the attacker from analyzing the functionality that is available only to privileged users whose accounts need to be created by the administrator.
  
• White box research. A tool (or researcher) often has full access to the source code of an application, administrative access to the platform on which it runs, and so on. This ensures that a complete and thorough analysis of all the features of the application is performed, regardless of where the studied functionality is located. The disadvantage of such a study is that it is not an imitation of the real actions of an attacker.
  

Of course, there are shades of gray between white and black. Usually, how the work with the application will be carried out is determined by the objectives of the study. If the goal is to find out what might happen to the application, which will be the subject of a targeted external attack, black box testing is probably best. If the goal is to identify and resolve as many security issues as possible in a relatively short time, a white-box study may be more effective.

In other cases, a hybrid approach can be applied when the researcher does not have full access to the source code of the application for the platform on which it runs, but the account issued to him is prepared by the administrator and gives access to as many features of the application as possible.

Kali is the ideal platform for all application research approaches. After installing the standard distribution kit, you can find many scanners designed for specific applications. There are also tools for more advanced research. Among them are source code editors and scripting environments. In researching applications, you may find the materials from the Web Application and Reverse Engineering sections of the Kali Tools site useful .

Summary

In this article, we talked about various types of measures for assessing the security of information systems. Here you can also find links to tools useful in conducting such studies. Next time we’ll talk about the methodology of formalizing research and the types of attacks.

Dear readers! If you have conducted studies to assess the security of systems or ordered such studies in specialized organizations - please share your experience.