An increasing number of internal applications are put into practice with the help of web technologies. This enables access into the application with various devices and this, mostly without the installation of any additional software. In some customer environments, web apps are virtually mushrooming so one could assume that for every requirement that exists, a web application providings the answer. As a result, very often, security is neglected.

Very seldom developers are trained in security coding and applications go live even before the security has been checked. Very often, the risk that originates from doubtful web apps is underestimated as these are only accessible internally or via VPN. Here it must be assumed that the perimeter will eventually be overcome and then these applications will offer attackers attractive targets and possibilities to spread further in the network.

A term, many possibilities

Like most information security assessments, the web application pentests exists in different variations. The scope describes which part of the application and respectively which part of the underlying infrastructure should be tested. If requested, the points of attack on the security of the operating system and of the web server can be included in the tests. Perhaps it is only required to test a part of the application. In case that the application already underwent several screenings and the same application is now expanded by a section, the whole application does not necessarily need to be tested again. It can be sufficient to scrutinize the new sections respectively and the interfaces to the rest of the application.

Web app pentests are mostly list-based. This means that one category of weakness after the other is checked systematically and it will be attempted to exploit these. However, it is also possible to conduct these tests based on scenarios. With this scenario, it will not be attempted to find as many weaknesses as possible, but it will try to reach a defined objective. This goal can be described for example as follows: extension of user authorization to obtain access into administrative functions without triggering an alarm. Here, the pentester will therefore be forced to stay below the radar and not to attract any attention. At the same time, the pentester is only interested in weaknesses that allow a privilege escalation either alone or together with other weaknesses.

Weaknesses are not disappearing

In order to have a clear picture of this topic, a couple of examples shall be demonstrated at this point. These are either reconstructed or for the sake of demonstration artificially created…. nonetheless we encountered with quite a few pentests exactly these kind of weaknesses.

Public Exploit

In order to have a clear picture of this topic, a couple of examples shall be demonstrated at this point. These are either reconstructed or for the sake of demonstration artificially created…. nonetheless we encountered with quite a few pentests exactly these kind of weaknesses.

 

Public exploit

With this finding, the pentester did not have much work. In case that the patch management does not work properly or if it does not even exist, then OS, webserver or frameworks run on outdated versions for which information on the known weaknesses and the relevant exploits are publicly available. The tester starts to enumerate the utilized programming languages, frameworks, libraries and tools. Subsequently it can be checked if weaknesses for the utilized products are known and if the used versions are vulnerable.

In our hypothetical example, it is demonstrated to the tester that the application has been developed with the help of the Apache Struts Framework, which developers like to employ in order to develop Java based web applications.

The Apache Struts version that is used in this example could be vulnerable to CVE-2017-5638, which permits to send commands that are executed on the server. A quick scan with the help of an Nmap script should show this:

To be sure that the finding of the Nmap script is correct, a manual check can also take place. For this, we add a specifically prepared Content-Type header, which tests if the server executes commands that are given to it by the client. In this case, we let the server calculate the product of 42 * 42.

As we assumed, it is apparent that the server will be at our service.

As it is now beyond any doubt that the utilized version is vulnerable to the described weakness, the system can be compromised with the help of a simple exploit:

ADMIN INTERFACE / DEFAULT CREDENTIALS

A lot of us will know this already from their own experience: a developer or an administrator is “just very briefly” installing an application for test purposes. After the test the deprovisioning is overlooked and thus an insecurely configured web application is slumbering on the server until (in an ideal case) a pentester or (in worst case) an attacker stumbles upon it. Very often, the providers are of the opinion that an attacker cannot do much with an almost empty test server, but a compromised server is usually already placed, for example in the DMZ behind the strictest firewall ruleset and other protective mechanisms. A lot of trouble can be made from such a server.

If it is now permitted at this point to login with the help of access details such as username = admin and password = admin and keyword = (empty), it is only a matter of time until an attacker or a pentester will have taken over the server completely. We are noticing this combination of weaknesses (unfortunately) quite often, during our assessments. In some instances, they are even accessible publicly via the internet. Even when such access details are not being used, applications and the logins onto them are very often not controlled. This way, the pentester is able to either try for days or even for weeks to gain access using different pass- or keywords or specific access details that the pentester was able to already collect elsewhere.

 

UNSECURE SESSION IDS

The creation and the utilization of session IDs very often does not even meet the requirements for a secure web application. The transmission of the session ID in the form of a GET parameter leads to the fact that the session ID appears in the address bar of the browser. After the login, the session ID is very often the only means of authentication of a session and therefore should be well guarded. However, the display of the ID in the address bar will allow shoulder surfers to copy or to photograph the ID. In case the ID is now subsequently used in another session, the attacker will have successfully taken over an authenticated session.

 

Sometimes it is not the transport of the session ID, though that might be problematic, but the creation of the IDs upfront. In case that session IDs are not selected randomly enough, attackers will be able to precompute the IDs or they will use deviations in the randomness in order to guess valid session IDs. Very often information such as time, date or server name are a part of the creation of the IDs, which will not necessary lead to a high entropy of the session IDs due to the static or linear properties of this information. To uncover these weaknesses one can create and subsequently analyze many IDs. The following example demonstrates how the algorithm for the creation of session IDs display values that show no acceptable randomness concerning certain character or bit positions.

MISSING HEADER

There are several headers in existence that can be set in a web application and this will have an influence on the security of the application. Finally, we will still demonstrate two examples:

X-Frame-Options

With the help of the header “X-Frame-Options”, it is possible for the application to indicate that it does not want to be displayed in an iframe. This is used to prevent so-called clickjacking attacks. These attacks are executed in a way that an attacker integrates an application as an invisible iframe. Then the attacker layers the iframe over a different visible application. Although the user is thinking that the button in the visible application was just pushed, the click would have been really placed for instance on a password reset button in the framed application. To be protected against such attacks, the X-Frame-Options header should be set the following way:

Strict-Transport-Security

In the event that a webpage it reached via HTTPS (and this should be the case most of the time), a redirect is utilized to direct the use from the HTTP version to the HTTPS version of the page. If an attacker controls the traffic from the user to the web page though, the redirect can be removed by the attacker and future call-ups that contain HTTPS:// will be replaced with HTTP://. Thus, the attacker forces the user to access the page unencrypted and passwords and other information that is worthy of protection can be looked at in plain text. This method is known as SSL stripping. The provider can set the header “Strict-Transport-Security” (also known as HSTS) to prevent the unencrypted access via HTTP onto a web page.

This is causing two changes in behavior of the browser:

  1. The user cannot access the page via an unencrypted HTTP
  2. The user cannot ignore certificate errors in the browser in order to still access the page

 

 

Naturally, the activation of this header assumes that the TLS configuration and the certificate of a web presence are impeccable, otherwise problems will occur during retrieval. The header is set when the web page of a client is called up for the first time and prevents thus potential future attacks. However, the question remains what will happen, in the case that the attacker already manipulated the initial connection between the user and the webpage. If this happens, one can simply remove the header from the data stream and further attacks will operate as usual. To counteract this issue, a so-called preloading was established. Thereby, the provider of the web presence can ask to be included in the HSTS list directly in the browser. This means that the web page can only be reached via HTTPS and this already immediately after the installation of the browser.

Der HTTP Strict Transport Security header looks as follows:

To actually trigger the preloading, the provider will still have to apply on this portal: https://hstspreload.org/

 

CONCLUSION

The protection of web applications requires a profound knowledge about different, correlating technologies although this is quite simple nowadays to create these web applications.

Especially because of the progressing prevalence of internal and external web applications, in most businesses many vectors of attack can be found. The weaknesses can be exploited due to missing or careless web application security.

We are available to gladly offer you our consultation regarding the protection of web applications and will offer guidance and advice accordingly.

RELAX, WE CARE.