Conduct a Web Penetration Test

Understand the Concept of Encryption

In this chapter, we’ll be looking at the quality of data flow encryption.

We use the term encryption rather than cryptography to describe information flows and data protected by cryptographic mechanisms.

We use the term decryption when we know the keys to transform the message into plaintext, and the term cracking when we don’t know the decryption key and need to reconstruct it.

That’s why hackers have to crack encrypted data flows: They don’t have the key!

To establish TLS communication:

1. The client contacts the server and tells it which protocols and cipher suites it supports.

2. The server responds by sending its certificate and indicating which protocol and cipher suite it will use.

3. What follows is a series of transactions and exchanges between the client and server to complete the TLS handshake and secure the communication channel they’ll use.

Poor-quality encryption is always better than no encryption at all. The same applies to authentication. But good-quality encryption is better.

1. It makes exchanges more secure (logically).

2. There are also services and companies that rate sites exposed on the internet (and the quality of encryption is a factor).

Check the Encryption Quality

The reason we need to check the quality of encryption is that it’s not infallible either!

In simple terms, when:

• the quality of the certificate used is inadequate, which could make it easier for an attacker to forge it.

• the protocols used by the server contain implementation flaws.

• the cipher suites used are weak.

• the library used for encryption contains vulnerabilities.

I’m sure you’ve seen this message more than a few times:

Most of the time, it’s linked to a problem with the certificate:

• whose validity period may have expired.

• whose  subject name  field does not match the site’s DNS name.

• whose certification authority is not known to your computer.

• which has simply been revoked.

• etc.

But there are other points to look out for in a penetration test, including:

• the certificate’s key size, which must not be too small (not less than 2,048 bits).

• the hash algorithm (SHA-256 with RSA or higher).

We’ll also check that the libraries used aren’t vulnerable or contain weaknesses that could affect the robustness of the encryption. Because, yes, encryption isn’t magic. It’s performed by code in these libraries, the best known and most widely used of which is OpenSSL.

Cryptography is quite complex, and fortunately, we can automate all these checks very easily!

There are a number of tools available, including:

• some online, such as SSLlabs from Qualys.

• some that run locally on your computer or via a CLI (command line interface), such as SSLscan and testssl.sh.

• the vulnerability scanners we mentioned in the previous chapter, which can usually perform these tests.

We’ve also mentioned some concepts with rather obscure names:

• Encryption protocols

• Cipher suites

Let’s take a look at what we, as pentesters carrying out an audit or pentest, need to know about these concepts. We don’t need a cryptologist’s skills!

Differentiate Between Encryption Protocols and Cipher Suites

Encryption Protocols

These encryption protocols are the following:

• SSL v2

• SSL v3

• TLS v1.0

• TLS v1.1

• TLS v1.2

• TLS v1.3 

For each encryption protocol, there is a list of compatible and accepted cipher suites.

Cipher Suites

Cipher suites take the following form:

<key exchange algo>-<authentication algo>-<symmetric cipher algo and key size>-<signature algo>

This gives us  ECDHE-RSA-AES128-GCM-SHA256 , for example, indicating:

• ECDHE  for key exchange.

• RSA  for authentication.

• AES-128  as the cipher.

• GCM  as the block cipher mode of operation (of little interest to us as pentesters, except in exceptional cases).

• SHA-256  as the signature.

It’s simply a different naming convention. For cipher suites, hyphens separate the “functions” of each element, whereas for encryption algorithms like AES or hashing algorithms like SHA, the hyphen separates the function name from the key size.

Apply Best Practices

Cryptography may seem like a complex field, but implementing it is not!

The recommended configuration is as follows:

• Redirection: automatic from HTTP channel to HTTPS channel (i.e., port 80 to port 443 by default).

• Certificate: ideally with a lifetime of 90 days, but always less than one year.

• Permitted protocols: TLS 1.3 and TLS 1.2.

• Cipher suites: key sizes > 128 bits, hash function > 256 bits.

At the same time, as computing power increases and vulnerabilities emerge, recommendations change. It is therefore essential to regularly review your web server configuration to ensure it reflects the latest best practices.

If, for example, you’re testing a 10-year-old application that has never been upgraded for various technical reasons, chances are you won’t be able to do much about the quality of its encryption! However, if the application supports data stream encryption, the client can count himself lucky. So, it’s important to take this into account in your recommendations.

Over to You!

Challenge

1. Log in to Root Me.

2. Click this link (CTF OpenClassrooms – DVWA) to start or join the environment.

3. Once on the page, wait for a green box like this to appear:

4. This will show the address to be analyzed, so get started!

Your objectives are to check the following points of the service’s SSL configuration:

• The quality of the certificate used: 

  • Does the certificate’s CN or SAN match the site’s domain name?

  • What is the key size?

  • What is the signature algorithm?

• The protocols used by the server.

• Supported encryption suites.

• The presence of known vulnerabilities in the library used.

One final tip: Use testssl.sh instead for this exercise.

Solution

Let’s Recap!

• Encrypting communications ensures that flows of data between the application’s clients and the server are protected against an attacker attempting to intercept and modify them. This is known as a man-in-the-middle attack.

• An application with poor encryption is better than one that can be accessed “in plaintext” (without encryption).

• The quality of encryption can be affected by a number of factors, including the certificate, the supported encryption protocols, and the accepted cipher suites.

• Although cryptography is a complex subject, these checks are easy to automate using a number of powerful tools, either available online or running locally on your computer. These include ssllabs, sslscan, and testssl.sh.

That’s it for this part! Next, we’ll take a closer look at the web application itself and learn about the tool you’ll be working with the most: the interception proxy!