Kali Linux: Types of Information Systems Checks
→ 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: system protection and monitoring exercises
→ Part 5. Kali Linux: System Security Assessment
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.
After your OS is ready for work, it's time to determine exactly what kind of research you are going to conduct. In general, there are four types of such studies:
')
A specific task for researching a system may include various elements of each type. We believe that it is worthwhile to talk about them in more detail and reveal their connection with Kali Linux and with the work environment.
Before proceeding to the description of specific types of measures to assess the security of systems, we will talk about how vulnerabilities are different from exploits.
Vulnerability can be defined as a defect in the information system, using which you can violate its confidentiality, integrity or accessibility. There are various types of vulnerabilities that can be encountered. Here are some of them:
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 the exploit must change the running process, forcing it to perform unintended actions, creating exploits can be a daunting task. Moreover, in modern computing platforms there are a number of technologies to counter the exploits, complicating their development. Among such technologies are data execution prevention (DEP) and address space allocation (ASLR). However, if for a certain vulnerability it is not possible to detect a public exploit, this does not mean that such an exploit does not exist, and also the fact that it cannot be created. For example, many organizations sell specially designed exploits that are not shared. Therefore, all vulnerabilities should be considered as potentially exploitable.
Now let's talk about various types of measures to assess the security of systems.
Recall that a vulnerability is considered to be a defect in an information system that can be used in some way to violate its confidentiality, integrity or accessibility. When conducting a system vulnerability assessment, your goal is to create a list of vulnerabilities found in the target environment. The concept of “target environment” is very important when assessing the security of systems. You do not have to cross the border with the client. This means to work within the target network and not deviate from the objectives of the study. Going beyond the limits of the studied environment, the boundaries of which are agreed with the client, may lead to disruption of the client’s services, loss of his trust, or legal action 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, automatic tools, such as those found in the Vulnerability Analysis and Web Applications groups on the Kali Tools website, or in the corresponding sections of the Applications menu on the Kali desktop, are used to detect computers running in the target environment, to identify services listening to some ports and analyzing them. This is done to collect as much information as possible about the system. This information includes information about hardware platforms and server software, operating system and application versions, 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 there will be, the more accurate the identification of the vulnerability will be. There are many indicators of interest in analyzing system vulnerabilities. Among them are the following:
After collecting information, these and many other indicators will be used to generate vulnerability signatures. It is quite expected that the more data fragments coincide with the signature, the more confidently we can talk about the detected vulnerability.
By comparing the collected data with the signatures, you can get different results:
It’s easy to understand that signature accuracy is extremely important to ensure reliable system scan results. The more data you can collect, the higher the quality of signature-based autoscan results. 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 opportunities for analyzing data that are not available in other conditions. For example, with a conventional scan, it is only realistic to obtain information about the system, which can be extracted from the analysis of services that are accessible from the outside, and from the analysis of the functionality provided by them. Sometimes this scan allows you to collect a lot of data. But this information does not go to any comparison with what you can learn about the system, logging into it and carefully analyzing all installed software, applied patches, running processes, and so on. Collecting such extensive system data is useful for finding vulnerabilities that might otherwise remain undetected.
A well-conducted vulnerability study provides a report on 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 the hours of minimum load on the system, since scanning may 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 create a load on the target system and the network. Unfortunately, it is difficult to know in advance how much resources will be consumed, as this depends on the number of services running and the types of checks that will be associated with these services. Scanning consumes system resources, therefore, with the use of appropriate tools, it is important to imagine what load they can create on the systems and networks under study.
When the verification is complete, the vulnerabilities detected are usually associated with standard identifiers, such as CVE numbers , EDB-IDs , or vulnerability classification codes, accepted from scan tool vendors. 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 vulnerability reports, gives a general idea of the vulnerabilities that need to be taken into account when analyzing the scan results.
Since automated tools are used to identify signature database vulnerabilities, the slightest deviation from a known signature can change the result, and, accordingly, the validity of reports of 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 database used by them. As a rule, suppliers of similar software offer different versions of their programs. Some of them - free, equipped with trimmed databases, are designed for home users. Others are quite expensive, with full-fledged bases, usually focused on the corporate sector.
Another problem that often arises when scanning for vulnerabilities is the usability of the proposed risk ratings. These ratings determine on a universal basis, taking into account many different factors, such as the level of privileges, the type of software, the possibility of implementing the vulnerability before or after authentication. Such ratings can not be used thoughtlessly, since their value depends on the characteristics of the system under study. Qualitative assessment of the level of risk is possible only using those ratings that are based on the analysis of detailed information about the system and the vulnerabilities found in it.
There is no single generally accepted agreement on risk ratings, however, it can be recommended to use NIST SP 800-30 as the basis for assessing risks in the studied environment. NIST SP defines the real risk of a detected vulnerability as a combination of the possibility of a threat and the level of impact on an organization when a threat is implemented.
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 particular vulnerability. At the same time, the possibility of a threat is assigned one of the possible ratings: low, medium or high.
The level of impact on the organization in the implementation of the threat is determined by assessing the amount of damage that can be caused by the use of the vulnerability being analyzed.
Once the possibility of the threat and the level of its impact on the organization has been clarified, it is possible to 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 system being analyzed.
The risk indicator of a detected vulnerability forms many factors, so ratings obtained from automated scanning systems should be considered only as a starting point in determining the real risk.
Based on the results of the vulnerability assessment, reports are compiled. Such reports, created expertly and professionally analyzed, lay the foundation for other studies, such as the evaluation of systems for compliance with safety standards. It is important to extract from the results of the vulnerability assessment everything that is possible.
Kali is an excellent platform for assessing vulnerabilities, the OS does not need to be specifically configured for this. In the Applications menu, you can find many tools for analyzing vulnerabilities. In particular, we are talking about the sections Information Gathering (Vulnerability Analysis), and Web Application Analysis (Web Application Analysis). Learn more about using Kali Linux to analyze vulnerabilities on the Kali Linux Tools site, on the official Kali Linux documentation site, and familiarize yourself with the free Metasploit Unleashed course.
The next most complex type of research is the assessment of systems for compliance with safety standards. Such systems tests are most common, as they are based on the verification of requirements prescribed by government and industry standards applicable to organizations.
There are many specialized security standards, however, Payment Card Industry Data Security Standard ( PCI DSS ) is most common. This standard has been developed by payment card companies. It must comply with the organization that processes card payments. If we talk about other common standards, we can mention such as Defense Information Systems Agency, 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 mandatory testing. In any case, such studies are referred to as “systems' evaluation for compliance with safety standards”, or “studies for compliance with safety standards”, or “tests for compliance with safety standards”.
Evaluation of a system for compliance with standards usually begins with an analysis of vulnerabilities. In the case of an audit procedure for compliance with the PCI standard, the assessment of vulnerabilities, if conducted accordingly, 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.” The system can be analyzed for compliance with this requirement using the tools from the Password Attack category of the menu. Further, this requirement 11: “Perform regular testing of security systems and processes.” Appropriate checks can be performed using 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 organization personnel.” Additional efforts are needed to verify such requirements.
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, moreover, not only because of the rich set of standard tools, but also because it is based on Debian, which makes it possible to install 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. Such a search will almost certainly end with the issuance of several noteworthy results. Currently, many organizations use Kali Linux as a platform for evaluating systems for compliance with security standards.
Recently, it has become difficult to find a suitable definition for the “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 is added by the fact that “penetration testing” has increasingly begun to call the system assessment described above for compliance with security standards, or even the usual vulnerability assessment. In such cases, the study does not go beyond certain minimum requirements.
In this section, we will not discuss disputes about the features of various types of test systems. Here we will talk about research that is not limited to certain "minimum requirements". These are studies that are designed so that after they are carried out, the overall security of the organization can truly be improved.
In contrast to the types of research that we discussed earlier, traditional penetration tests do not often begin with the definition of a field of study. Instead, they set certain goals for them. For example: “simulate the consequences of a compromised internal user,” or: “find out what would happen if the organization came under a targeted attack by an external attacker.” A key feature of such studies is that, in the course of their implementation, not only are they finding and assessing vulnerabilities, but they also use the problems found to uncover the worst-case scenarios.
During penetration testing, they do not rely solely on system scan tools for vulnerabilities. Work continues by examining the findings, by using exploits or tests to eliminate false-positive results, every effort is made to detect hidden vulnerabilities, or what we call false-negative results.
This kind of research often involves exploiting detected vulnerabilities, assessing the level of access that exploits provide, and using this increased level of access as a starting point for additional attacks on the target system.
It requires a critical analysis of the target environment, manual search for vulnerabilities, creativity, ability to think outside the box. All of these are approaches to finding additional vulnerabilities that require other tools that can find vulnerabilities where the capabilities of the most powerful automated scanners run out. Often, after completing this step, the whole process is started over and over again in order to ensure complete and high-quality work.
Despite the complexity and diversity of traditional penetration testing, the course of such research can be streamlined by breaking into several steps. It should be noted that Kali simplifies the selection of software for each of these steps. So, here is a step-by-step penetration testing plan with comments about the tools used:
In most cases, penetration tests will be arranged in a completely different way, as 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 customizing Kali. Many organizations that carry out such studies support customized Kali LInux versions for internal use. This allows them to accelerate the deployment of systems before the new study.
Among the frequently used advanced settings for Kali Linux are the following:
Most of the measures for assessing the security of systems are quite large. A specific 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 by their own companies. If necessary, application research may accompany other types of research. Among the types of applications that can be examined for security are the following:
Application research can be done in many different 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 applications, try to find unknown weaknesses in them, instead of relying on a set of pre-defined signatures. Tools for analyzing programs should take into account the characteristics of their behavior. For example, Burp Suite , a popular web application vulnerability scanner. During the study of the application, he finds data entry fields, and then performs various attacks using SQL injection, observing the application at this time in order to identify the attacks that were successful.
There are more complex application research scenarios. Such studies can be performed online. When carrying out their use models of black and white boxes.
Of course, there are shades of gray between white and black. Usually, the way the application will work is determined by the objectives of the study. If the goal is to find out what can happen to an application that will be the subject of a targeted external attack, testing by the black box method is probably best. If the goal is to identify and eliminate as many security problems 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 is running, but the account issued to him is prepared by the administrator and gives access to the greatest possible application features.
Kali is the ideal platform for all application research approaches. After installing the standard distribution, you can find here a lot of scanners designed for specific applications. There are tools for more advanced research. Among them are source code editors and script environments. In the study of applications, you may find useful materials from the Web Application and Reverse Engineering sections of the Kali Tools site.
In this material, we talked about various types of measures to assess the security of information systems. Here you can find links to tools that are useful when conducting such studies. Next time we will talk about the methodology of formalization of research and the types of attacks.
Dear readers! If you have conducted studies to assess the security of systems or ordered similar studies in specialized organizations - please share your experience.
→ Part 2. Kali Linux: filtering traffic using netfilter
→ Part 3. Kali Linux: monitoring and logging
→ Part 4. Kali Linux: system protection and monitoring exercises
→ Part 5. Kali Linux: System Security Assessment
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 to assess the security of information systems
After your OS is ready for work, it's time to determine exactly what kind of research you are going to conduct. In general, there are four types of such studies:
')
- Systems vulnerability assessment;
- Evaluation of systems for compliance with safety standards;
- Traditional penetration testing;
- Application research.
A specific task for researching a system may include various elements of each type. We believe that it is worthwhile to talk about them in more detail and reveal their connection with Kali Linux and with the work environment.
Before proceeding to the description of specific types of measures to assess the security of systems, we will talk about how vulnerabilities are different from exploits.
Vulnerability can be defined as a defect in the information system, using which you can violate its confidentiality, integrity or accessibility. There are various types of vulnerabilities that can be encountered. Here are some of them:
- Vulnerability to include files . This class of vulnerabilities allows an attacker to include local or remote files in the process 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 users. If errors were made during the development of such a function, it may allow an attacker to modify the request to the site that he performs so that the web application, instead of the useful file, connects the file prepared by the attacker to the page.
- The possibility of SQL injection. Attacking a vulnerable application with a SQL injection method is a situation in which an attacker bypasses the data-checking subsystems entered by users. This allows him to enter his own SQL commands that the attacked system will execute. This can lead to security issues.
- Possibility of buffer overflow . This is a vulnerability that allows an attacker to bypass the input control subsystems and write data to the memory that is adjacent to the memory allocated for a certain buffer. In some cases, the memory area near the buffer can be extremely important to ensure the health of the program under attack. With proper manipulation of data stored in these areas, you can get control over the execution of the application code.
- Exposure to the state of the race system. This is a vulnerability, exploitation of which is based on the use of temporal dependencies in programs. In some cases, the application workflow depends on the performance 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 the exploit must change the running process, forcing it to perform unintended actions, creating exploits can be a daunting task. Moreover, in modern computing platforms there are a number of technologies to counter the exploits, complicating their development. Among such technologies are data execution prevention (DEP) and address space allocation (ASLR). However, if for a certain vulnerability it is not possible to detect a public exploit, this does not mean that such an exploit does not exist, and also the fact that it cannot be created. For example, many organizations sell specially designed exploits that are not shared. Therefore, all vulnerabilities should be considered as potentially exploitable.
Now let's talk about various types of measures to assess the security of systems.
11.2.1. System Vulnerability Assessment
Recall that a vulnerability is considered to be a defect in an information system that can be used in some way to violate its confidentiality, integrity or accessibility. When conducting a system vulnerability assessment, your goal is to create a list of vulnerabilities found in the target environment. The concept of “target environment” is very important when assessing the security of systems. You do not have to cross the border with the client. This means to work within the target network and not deviate from the objectives of the study. Going beyond the limits of the studied environment, the boundaries of which are agreed with the client, may lead to disruption of the client’s services, loss of his trust, or legal action 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, automatic tools, such as those found in the Vulnerability Analysis and Web Applications groups on the Kali Tools website, or in the corresponding sections of the Applications menu on the Kali desktop, are used to detect computers running in the target environment, to identify services listening to some ports and analyzing them. This is done to collect as much information as possible about the system. This information includes information about hardware platforms and server software, operating system and application versions, 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 there will be, the more accurate the identification of the vulnerability will be. There are many indicators of interest in analyzing system vulnerabilities. Among them are the following:
- The version of the operating system. It often happens that a certain application is vulnerable in one version of the OS, but not in the other. That is why the scanner will try to determine, as precisely as possible, on which version of the operating system the target application is running.
- OS patch level. Often there are patches for operating systems, the installation of which does not change the OS version, although at the same time, known vulnerabilities either disappear or begin to behave differently from 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, a vulnerability exists only on a specific architecture, so knowledge of the processor architecture can play an important role in building an accurate vulnerability signature.
- Software version The target software version is one of the key indicators that must be obtained to identify a vulnerability.
After collecting information, these and many other indicators will be used to generate vulnerability signatures. It is quite expected that the more data fragments coincide with the signature, the more confidently we can talk about the detected vulnerability.
By comparing the collected data with the signatures, you can get different results:
- Positive result. The signature corresponds to the vulnerability profile, a vulnerability is found in the system. Having 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. The analysis was able to find a match with the signature of the vulnerability. However, what is found is not a vulnerability. Similar results are usually considered "information noise", they complicate the work. In order to clearly distinguish between true and perceived vulnerabilities, a deeper analysis of the situation is required.
- Negative result. After scanning the system, no matches could be found with known vulnerability signatures; 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. Matches with signatures could not be found, but there is a vulnerability in the system. There is nothing good about getting false positive results, but a false negative result is much worse. In this 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 you can collect, the higher the quality of signature-based autoscan results. 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 opportunities for analyzing data that are not available in other conditions. For example, with a conventional scan, it is only realistic to obtain information about the system, which can be extracted from the analysis of services that are accessible from the outside, and from the analysis of the functionality provided by them. Sometimes this scan allows you to collect a lot of data. But this information does not go to any comparison with what you can learn about the system, logging into it and carefully analyzing all installed software, applied patches, running processes, and so on. Collecting such extensive system data is useful for finding vulnerabilities that might otherwise remain undetected.
A well-conducted vulnerability study provides a report on 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 the hours of minimum load on the system, since scanning may 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 create a load on the target system and the network. Unfortunately, it is difficult to know in advance how much resources will be consumed, as this depends on the number of services running and the types of checks that will be associated with these services. Scanning consumes system resources, therefore, with the use of appropriate tools, it is important to imagine what load they can create on the systems and networks under study.
▍ Multithreading
Most vulnerability scanners support setting the number of threads allocated to the scan task. It is a question of how many checks will be carried out simultaneously. The increase in the number of scan threads leads to an increase in the load on the researcher’s computer, on the network, on the target systems. It is tempting to speed up scanning by increasing the number of threads, but it is important to remember that this can lead to a significant increase in system load.
When the verification is complete, the vulnerabilities detected are usually associated with standard identifiers, such as CVE numbers , EDB-IDs , or vulnerability classification codes, accepted from scan tool vendors. 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 vulnerability reports, gives a general idea of the vulnerabilities that need to be taken into account when analyzing the scan results.
Since automated tools are used to identify signature database vulnerabilities, the slightest deviation from a known signature can change the result, and, accordingly, the validity of reports of 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 database used by them. As a rule, suppliers of similar software offer different versions of their programs. Some of them - free, equipped with trimmed databases, are designed for home users. Others are quite expensive, with full-fledged bases, usually focused on the corporate sector.
Another problem that often arises when scanning for vulnerabilities is the usability of the proposed risk ratings. These ratings determine on a universal basis, taking into account many different factors, such as the level of privileges, the type of software, the possibility of implementing the vulnerability before or after authentication. Such ratings can not be used thoughtlessly, since their value depends on the characteristics of the system under study. Qualitative assessment of the level of risk is possible only using those ratings that are based on the analysis of detailed information about the system and the vulnerabilities found in it.
There is no single generally accepted agreement on risk ratings, however, it can be recommended to use NIST SP 800-30 as the basis for assessing risks in the studied environment. NIST SP defines the real risk of a detected vulnerability as a combination of the possibility of a threat and the level of impact on an organization when a threat is implemented.
▍11.2.1.1. Threat
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 particular vulnerability. At the same time, the possibility of a threat is assigned one of the possible ratings: low, medium or high.
- High level. The potential adversary is highly qualified and motivated; measures taken to protect against exploiting vulnerability are insufficient.
- Average level. The potential adversary is motivated and qualified, but measures to protect against the exploitation of a vulnerability may hamper its success.
- Low level. A potential adversary is unqualified or lacks motivation, and measures have been taken to protect against exploiting vulnerabilities that are partially or absolutely effective.
▍11.2.1.2. The level of impact on the organization when making threats
The level of impact on the organization in the implementation of the threat is determined by assessing the amount of damage that can be caused by the use of the vulnerability being analyzed.
- High level. The use of vulnerability can lead to substantial financial losses, can seriously damage the mission or reputation of the organization, can result in serious material damage or loss of life.
- Average level. Using vulnerabilities could result in financial loss, damage to a company's mission or reputation, or, in the case of a company's human resources, lead to injury.
- Low level. Exploiting the vulnerability may result in some financial loss or impact on the mission or reputation of the company.
▍11.2.1.3. Risk level determination
Once the possibility of the threat and the level of its impact on the organization has been clarified, it is possible to 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 system being analyzed.
- High level. There is a serious need to take 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.
- Average level. There is a need to take additional measures to protect against vulnerability. A plan for implementing the necessary protection measures must be completed within a reasonable period of time.
- Low level. The owner of the system will independently determine 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 a detected vulnerability forms many factors, so ratings obtained from automated scanning systems should be considered only as a starting point in determining the real risk.
Based on the results of the vulnerability assessment, reports are compiled. Such reports, created expertly and professionally analyzed, lay the foundation for other studies, such as the evaluation of systems for compliance with safety standards. It is important to extract from the results of the vulnerability assessment everything that is possible.
Kali is an excellent platform for assessing vulnerabilities, the OS does not need to be specifically configured for this. In the Applications menu, you can find many tools for analyzing vulnerabilities. In particular, we are talking about the sections Information Gathering (Vulnerability Analysis), and Web Application Analysis (Web Application Analysis). Learn more about using Kali Linux to analyze vulnerabilities on the Kali Linux Tools site, on the official Kali Linux documentation site, and familiarize yourself with the free Metasploit Unleashed course.
11.2.2. Evaluation of systems for compliance with safety standards
The next most complex type of research is the assessment of systems for compliance with safety standards. Such systems tests are most common, as they are based on the verification of requirements prescribed by government and industry standards applicable to organizations.
There are many specialized security standards, however, Payment Card Industry Data Security Standard ( PCI DSS ) is most common. This standard has been developed by payment card companies. It must comply with the organization that processes card payments. If we talk about other common standards, we can mention such as Defense Information Systems Agency, 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 mandatory testing. In any case, such studies are referred to as “systems' evaluation for compliance with safety standards”, or “studies for compliance with safety standards”, or “tests for compliance with safety standards”.
Evaluation of a system for compliance with standards usually begins with an analysis of vulnerabilities. In the case of an audit procedure for compliance with the PCI standard, the assessment of vulnerabilities, if conducted accordingly, 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.” The system can be analyzed for compliance with this requirement using the tools from the Password Attack category of the menu. Further, this requirement 11: “Perform regular testing of security systems and processes.” Appropriate checks can be performed using 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 organization personnel.” Additional efforts are needed to verify such requirements.
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, moreover, not only because of the rich set of standard tools, but also because it is based on Debian, which makes it possible to install 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. Such a search will almost certainly end with the issuance of several noteworthy results. Currently, many organizations use Kali Linux as a platform for evaluating systems for compliance with security standards.
11.2.3. Traditional penetration testing
Recently, it has become difficult to find a suitable definition for the “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 is added by the fact that “penetration testing” has increasingly begun to call the system assessment described above for compliance with security standards, or even the usual vulnerability assessment. In such cases, the study does not go beyond certain minimum requirements.
In this section, we will not discuss disputes about the features of various types of test systems. Here we will talk about research that is not limited to certain "minimum requirements". These are studies that are designed so that after they are carried out, the overall security of the organization can truly be improved.
In contrast to the types of research that we discussed earlier, traditional penetration tests do not often begin with the definition of a field of study. Instead, they set certain goals for them. For example: “simulate the consequences of a compromised internal user,” or: “find out what would happen if the organization came under a targeted attack by an external attacker.” A key feature of such studies is that, in the course of their implementation, not only are they finding and assessing vulnerabilities, but they also use the problems found to uncover the worst-case scenarios.
During penetration testing, they do not rely solely on system scan tools for vulnerabilities. Work continues by examining the findings, by using exploits or tests to eliminate false-positive results, every effort is made to detect hidden vulnerabilities, or what we call false-negative results.
This kind of research often involves exploiting detected vulnerabilities, assessing the level of access that exploits provide, and using this increased level of access as a starting point for additional attacks on the target system.
It requires a critical analysis of the target environment, manual search for vulnerabilities, creativity, ability to think outside the box. All of these are approaches to finding additional vulnerabilities that require other tools that can find vulnerabilities where the capabilities of the most powerful automated scanners run out. Often, after completing this step, the whole process is started over and over again in order to ensure complete and high-quality work.
Despite the complexity and diversity of traditional penetration testing, the course of such research can be streamlined by breaking into several steps. It should be noted that Kali simplifies the selection of software for each of these steps. So, here is a step-by-step penetration testing plan with comments about the tools used:
- Collection of information. In this phase, Pentester's efforts are aimed at finding out 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 as complete system data as possible. The Information Gathering section of the Applications menu of Kali Linux contains dozens of tools aimed at revealing as much information as possible about the system under investigation.
- Vulnerability detection. This step is often referred to as “active collection of information.” The specialist, trying to identify potential vulnerabilities in the target environment, has not yet attacked the system, but already behaves differently from the average user. It is here that the above described system scan for vulnerabilities often takes place. In this research step, the programs from 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 research step, the specialist tries to use them to find a foothold in the target environment. In this case, useful tools that can be found in the categories Web Application Analysis (Web Application Analysis), Database Assessment (Database Research), Password Attacks (Password Cracking), and Exploitation Tools (Tools exploit vulnerabilities).
- Penetration into the system and unobtrusive data extraction. After the researcher has 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 elevate privileges to the level that is necessary to achieve target systems that were previously inaccessible and to secretly extract secret information from them. In this step, you can access the following application menu sections such as Password Attacks, Exploitation Tools, Sniffing & Spoofing, and Post Exploitation.
- Preparation of reports. After completion of 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, due to the quality reports, the client can get the full benefit from the work done, so do not underestimate the importance of this stage of the study. Appropriate tools can be found in the Reporting Tools section of the Applications menu.
In most cases, penetration tests will be arranged in a completely different way, as 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 customizing Kali. Many organizations that carry out such studies support customized Kali LInux versions for internal use. This allows them to accelerate the deployment of systems before the new study.
Among the frequently used advanced settings for Kali Linux are the following:
- Pre-installation of licensed commercial packages. For example, there is a package, such as a paid vulnerability scanner, which is planned to be used in many penetration testing sessions. In order to avoid having to install this package on each deployed Kali copy, you can integrate it into the system. As a result, this package will be installed every time Kali is deployed.
- Pre-configured virtual private network with callback. This is a very convenient feature for devices that intentionally leave connected within the network under investigation. Such devices allow for "remote internal" studies. The device with the callback function is connected to the pentester’s 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 its own design. Many organizations have a set of proprietary tools that are needed during penetration testing sessions, so their pre-installation when creating a special system image saves time.
- , — IP-, , -, . Kali . , .
11.2.4.
Most of the measures for assessing the security of systems are quite large. A specific 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 by their own companies. If necessary, application research may accompany other types of research. Among the types of applications that can be examined for security are the following:
- Web applications. These applications are often targets of intruders, since they, usually with a significant attack surface, are accessible from the Internet. Standard tests often detect the underlying problems of web applications. However, a more detailed study, although it may take a lot of time, allows you to find hidden defects in applications. To conduct such tests, you can use the
kali-linux-webmetapackage, which contains many useful tools. - Desktop applications distributed as executable files. Server applications are not the only target of attackers. Desktop applications are also subject to attacks. Over the years, many desktop programs, such as tools for reading PDF files, or video applications that use Internet resources, have been subjected to multiple attacks, which has 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 increasing popularity of mobile devices, mobile applications are becoming a constant subject of security research. These applications are rapidly developing and changing, so 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 application menu section Kali Linux Reverse Engineering (Reverse engineering).
Application research can be done in many different 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 applications, try to find unknown weaknesses in them, instead of relying on a set of pre-defined signatures. Tools for analyzing programs should take into account the characteristics of their behavior. For example, Burp Suite , a popular web application vulnerability scanner. During the study of the application, he finds data entry fields, and then performs various attacks using SQL injection, observing the application at this time in order to identify the attacks that were successful.
There are more complex application research scenarios. Such studies can be performed online. When carrying out their use models of black and white boxes.
- Study by the black box. The tool (or researcher) interacts with the application without having special knowledge of it, or special access to it, exceeding the capabilities of a regular 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 must be created by the administrator.
- Study by the white box method. The tool (or researcher) often has full access to the source code of the application, administrative access to the platform on which it runs, and so on. This ensures that a full and thorough analysis of all the capabilities of the application is performed, regardless of where exactly the functionality is being studied. The disadvantage of this study is that it is not an imitation of the real actions of the attacker.
Of course, there are shades of gray between white and black. Usually, the way the application will work is determined by the objectives of the study. If the goal is to find out what can happen to an application that will be the subject of a targeted external attack, testing by the black box method is probably best. If the goal is to identify and eliminate as many security problems 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 is running, but the account issued to him is prepared by the administrator and gives access to the greatest possible application features.
Kali is the ideal platform for all application research approaches. After installing the standard distribution, you can find here a lot of scanners designed for specific applications. There are tools for more advanced research. Among them are source code editors and script environments. In the study of applications, you may find useful materials from the Web Application and Reverse Engineering sections of the Kali Tools site.
Results
In this material, we talked about various types of measures to assess the security of information systems. Here you can find links to tools that are useful when conducting such studies. Next time we will talk about the methodology of formalization of research and the types of attacks.
Dear readers! If you have conducted studies to assess the security of systems or ordered similar studies in specialized organizations - please share your experience.
Source: https://habr.com/ru/post/339636/
All Articles