News from a Classic: The SySS Penetration Test

There are two questions at the beginning of almost every penetration test:

1. How does a pentest work?
2. What exactly is being checked?

The answers are as individual as the tests themselves. This article gives an insight into the test methodology and the procedure of penetration testing using a web application test as an example.

What happens before the pentest?

Every project starts with the kick-off conversation. In this conversation, the SySS IT Security Consultants responsible for the project clarify technical and organizational issues. This includes, for example, access and test approvals, communication channels, and the final report. If possible, the kick-off discussion should take place a few days to weeks before the start of the project. External service providers in most cases have to be involved for test approval. There are also often some topics that need to be tackled on the customer side before the test can start. Depending on the scenario, this includes integrating different specialist departments, making a test environment accessible, and providing test accounts. In the experience of SySS, a period of three to six weeks before the start of the project is a good time frame for the kick-off meeting to be scheduled.

Against what background does the pentest take place?

The actual penetration test starts three to six weeks after the kick-off meeting. In principle, the procedure for each test is based on the respective test object, the test focus, the environment to be tested and the technologies used. In the case of a web application, for example, it is accessed via a browser and operated in this way. When testing the publicly accessible infrastructure, the focus is on determining the available services. These parameters also determine which tools are used. Some of these tools, such as the port or SSL/TLS scanners Nmap or testssl, are open source and can be used free of charge. Commercial tools such as Portswigger's Burp Suite or Tenable's Nessus are also used. However, SySS also develops its own tools, partly for internal use and partly open source for everyone. These tools are published on the SySS GitHub account.

In addition to automated tools, the “heart” of every penetration test is also put to use: the human component. SySS IT Security Consultants are ideally equipped for penetration tests through internal training, exchange of experience and external certifications. They can draw on a broad wealth of experience from their own projects as well as consult colleagues. Thus, interesting findings can usually be uncovered that would have remained hidden due to the sole use of automated tools.

SySS GmbH generally follows the OWASP top 10 for penetration tests of web applications, which are supplemented by their own internal guidelines. These guidelines are based on SySS' years of experience in penetration testing, internal research projects and internal knowledge exchange. Moreover, there is a lively exchange with the international IT security community via various discussion forums or at conferences. These findings are also incorporated into the internal SySS guidelines and procedures.

What happens during the pentest itself?

Each test starts with the information gathering phase. Many SySS web application tests also include testing the underlying infrastructure. Open ports and services offered on them are identified. This allows to see how large the attack surface on a system is. It also helps identify some unusual features such as outdated or misconfigured services. In most cases, these pose a direct security risk. Last but not least, the services found are checked for vulnerabilities.

In the case of a web application analysis, information retrieval involves going through the intended process of a user, for example, how they would regularly operate an application. For instance, an application path to be tested is filled with valid data to determine how it is transmitted to the server and processed.

Often, the information gathering phase is already slowly moving into the attack phase. This does not mean that information gathering is suspended in the end. Rather, the focus of the process shifts. During the test itself, new subpages or functions can always be discovered that were not directly found during the first inspection.

In the further course of the test, the web application is checked for various vulnerabilities. Depending on the application, its function, and the customer's wishes, priorities can be set here upon consultation. For example, it is extremely unlikely to find an error in handling input and passing it on to an application's underlying database (SQL injection) if it does not have a database connection at all. In such a case, the focus would be on other application features such as general input validation and content presentation.

The web application is tested for a wide variety of known attack vectors. This, for instance, typically includes CSRF attacks. In these cases, an attacker can perform actions on the attacked page from a foreign page as the user who is currently logged in. It also checks whether valid e-mail addresses can be determined using the login screen or the “forgot password” function. In the event of a successful attack, the application provides different answers here, depending on whether the e-mail address is stored in the system or not. Differences in response times are also an indication of whether the e-mail address exists or not. The analysis of login masks that SySS performs as part of penetration tests also includes checking whether a successful brute-force attack is possible. Many different passwords are tried out for one account. After that, an attempt is made to run a regular login to simulate a guessed password. If a login is successful, the application is vulnerable to such an attack.

It also checks whether the web application is vulnerable to cross-site scripting (XSS) attacks. In an XSS attack, an attacker manages to inject their own JavaScript code and execute it in the user's browser. This enables the attacker to completely determine how the page looks like in the user's browser and how it behaves. There are several ways an attacker can place such a vector. For example, it can be entered via the URL itself, it can be broken out of an input field, or an HTML file with an attack vector can be uploaded itself.

File upload functions are usually considered in more detail in penetration tests, as several possible attacks can be implemented here directly. In this way, file uploads check which files can be uploaded and whether appropriate checks for permitted file types can be bypassed. It also checks whether a file can be saved to a different location than the application intended. This can be done, for example, by manipulating the file name. In addition, it is checked whether dangerous file attachments can be uploaded which contain malware, for instance. A new download is also associated with a file upload. The key question at this stage is: Who can download the uploaded files and how can they be retrieved again? For example, an upload of malware combined with a publicly accessible link for the file can be used to distribute malicious software via an application. SySS does not use real malware for uploading malware during testing. Instead, the EICAR test string is used. This is a string that is recognized by many antivirus products. It can be used to check the functionality of antivirus software.

However, file uploads also lead to other potential weaknesses. If an uploaded file is not offered for download but is left to the browser to display it, there is the possibility of an XSS attack or phishing. If uploaded files with executable code (such as PHP commands in files) are interpreted by the server itself, an attacker can use this to execute commands in the application itself and in many cases on the underlying server.

The more common vulnerabilities also include errors in the authorization check. They check whether a logged-in user can perform actions for which they do not have the necessary permissions. This also includes the question of whether data from other users can be changed. Therefore, SySS always asks for accounts of different authorization levels for penetration tests. Even if more highly privileged accounts are not themselves in the test focus, it is advantageous if they are made available for testing. This enables the IT Security Consultants responsible for the project to identify functions more easily that are only available to more highly privileged users. Otherwise, some of these functions have to be guessed or, if in doubt, remain undetected and therefore untested.

In addition to the analysis of classic web vulnerabilities, the flow logic is also checked. These tests differ individually depending on the tested application. In the case of a web shop, for example, it is checked whether a voucher can be used again even though it has already been redeemed.

In penetration tests, SySS not only checks applications for the classic vulnerabilities that can be exploited by attackers. Applications are also examined for weaknesses that provide attackers with unnecessary information about the software used and the general architecture of the application. This includes, for instance, detailed error messages, version prices of the application and its components, or detailed information in files provided by the application.

In tests themselves, however, SySS rarely gains access to the program code of the application under test. Whether the program code is made available for a test also depends, among other things, on which test scenario has been chosen. With the black box approach, consultants are “in the dark” and do not receive any information. Functions and modes of operation need to be researched and the basic logic must be understood. The advantage here is that weak points are found that result from unusual inputs, for example. Many findings are also made by simple “trial and error”. This is in opposition to a white box approach. Here, IT Security Consultants receive as much information as possible, such as documentation, program code and, depending on the complexity, a brief technical introduction to the application. This enables penetration testers to operate the application in a similar way to a regular user. The advantage is that less time is required to familiarize with the application and therefore a broader test coverage can be achieved. By reviewing the documentation, SySS consultants can more easily discover technical errors that would not be immediately apparent without information. However, this often results in a restricted tunnel vision, as the pentesters take the view of a regular user who is already familiar with the object being tested at this moment. That is why there is an intermediate path between the two approaches, the so-called grey box approach. Only some necessary information for the test is provided here. SySS consultants can be provided with further information upon request. The grey box approach thus tries to combine the best of both worlds. Since this approach has already proven itself in many projects in the past, SySS usually recommends using the grey box approach for testing.

What are the results of a pentest?

The tests shown here only represent a part of all the vulnerabilities that are tested. Both in the scenario described here and in a real test, far more vulnerabilities are tested. At the end of a regular penetration test at SySS, there is not a blog article but a high-quality final report in PDF or printed and bound form. The final reports of SySS are not handed over immediately at the end of the test but only with a few days apart. The reason for this is the two-stage quality assurance process for the reports. It consists of technical quality assurance by another SySS IT Security Consultant and linguistic quality assurance by SySS proofreading. The two-stage quality assurance process ensures that customers receive a high-quality report that addresses all target groups in its various sections and can also be presented to the management.

Of course, there are also scenarios in which the results should be available as soon as possible. In such cases, it is possible to receive a draft version after technical quality assurance.

SySS not only sees itself as a service provider for penetration tests, but also takes the issue of IT security seriously in general and shows responsibility. Therefore, the weaknesses of products found during tests are reported with confidence to the manufacturer so that they can be remedied. SySS works closely with its customers and manufacturers to ensure that any security vulnerabilities found can be remedied in a timely manner. In customer projects, it is up to the customer to independently report the weaknesses found to the manufacturer of a product or whether this is done in cooperation with SySS in the form of a responsible disclosure process.

If you still have questions about penetration testing after this article or would like to perform a test with us, we will look forward to receiving your message at anfrage(at)syss.de.