Setting a Self-Signed SSL Certificate

SETTING TLS/SSL SELF-SIGNED CERTIFICATE

- Layout for this exercise:





0 - INTRODUCTION

- The goal of this exercise is to illustrate how to implement a self-signed TLS/SSL certificate for an Apache Server in Ubuntu 1.04.

- TLS (Transport Layer Security) and SSL (Secure Socket Layer) are cryptographic protocols used by web protocol HTTPS (HTTP Secure). Both provide two main security services:

i) protection by encrypting the communication between client and server, so that traffic can be sent safely without being intercepted by third parties, out of the client and server.

ii) authentication of the server against the client (also, it is optional to enforce mutual authentication between client and server), so that the identity of the website is verified.

- For more information about HTTPS, TLS and SSL:

https://es.wikipedia.org/wiki/Hypertext_Transfer_Protocol_Secure

- The usual way of setting HTTPS on a website is to acquire a certificate from a trusted Certificate Authority (CA). However, for the purpose of experimenting on future exercises, it is very interesting to practice the installation of a self-signed certificate, where the Authority is the server itself:

https://en.wikipedia.org/wiki/Certificate_authority
https://en.wikipedia.org/wiki/Self-signed_certificate

- TLS/SSL uses Public Key cryptography, or asymmetric cryptography, what combines a pair of different keys:

a) public key, available widely for anybody.
b) private key, stored at the server and known only by the owner.

https://en.wikipedia.org/wiki/Public-key_cryptography

-  A digital certificate is an electronic document used to prove the ownership of a public key. A certificate provides information about the public key, the identity of the owner, the authority or issuer who backs the validity of the certification, expiration date, etc ...

https://en.wikipedia.org/wiki/Public_key_certificate


1 - CREATING THE CERTIFICATE

- The first step to install a self-signed certificate for an Apache server is to create it using the command openssl:



- Parameters and options used in the command:

req -x509 = X.509 is the standard format for public key certificates, forcing to be self-signed instead of being requested to a Certificate Authority

-nodes = no using a passphrase

-days 365 = one year before expiration

-newkey rsa:2048 = RSA is the algorithm to be used, and 2048 bits is the key length

-keyout /etc/ssl/private/apache-selfsigned.key = location of the private key


-out /etc/ssl/certs/apache-selfsigned.crt = location of the certificate



- The server prompts with some questions about names, domains, email address of the administrator,  etc ...: 




- As mentioned before the private key (apache-selfsigned.ky) is kept secret on the server, and it is used to encrypt content sent by the server to the clients.







- The certificate (apache-selfsigned.crt) is publicly shared with users or clients that request content to the web server, and it is used to decrypt content sent by the server:





2 - SERVER CONFIGURATION

- Modifying some files at the Apache server, starting with ssl-params.conf:






- Also, modifying the default SSL Virtual Host File default-ssl.conf:








- Finally, modifying (this is optional) the unencrypted Virtual Host file 000-default.conf to automatically redirect HTTP requests to HTTPS:






3 - ENABLING SSL AT THE SERVER

-  Enabling the SSL module:






- Enabling the SSL Virtual Host:




- Enabling ssl-params.conf:




- Testing that the syntax is correct after all the modifications at the Apache server files:




- Restarting the server:




4 - TESTING THE SERVER:

- Now, when the client Kali tries to access the website www.whitelist.com/secure, provided by the server Ubuntu, HTTPS must be used instead of HTTP (although HTTP would be automatically redirected to HTTPS according to that specific configuration at the previous chapter).

- Because the certificate is unknown for the browser, the user is warned about the insecurity of the connection:




- However, for experimentation at this exercise, the client/browser accepts the connection by clicking the Add Exception tab, and later confirming by clicking Confirm Security Exception:




- Now, the warning message disappears and the connection is established correctly:




- Checking that the Certificate has been added to the browser, after being accepted:





- Clicking the green lock, and asking for more information:




- Viewing the Certificate:





- As expected, the certificate contains all the information previously entered by the administrator of the server:

Form HTTP based authentication - Brute force attack with Burp

FORM HTTP BASED AUTHENTICATION - BRUTE FORCE ATTACK WITH BURP

- Layout for this exercise:




- The goal of this exercise is to bypass a form based authentication, trying to gain access to the resources located into www.whitelist.com/formauth. 

- The attack method used in this case will consist of  brute forcing the username and password challenges prompted to the user, taking advantage of some tools provided by the proxy Burpsuite:




- First of all, the browser used by the attacker is set to connect the web page through a manual proxy, so that the connection can be intercepted and crafted:





- Starting the proxy Burp:




- Now, when the user tries to connect to www.whitelist.com/formauth, the connection is intercepted and refused by Burp:




- Analyzing into Burp, the request has been intercepted:



- Then, the request is forwarded:




- Now, the attacker enters some fake credentials (username=asdfg, password=xxxxxxxx):



- Burp detects the fake credentials:




- Right clicking and sending to the Intruder:




- Setting the target (Host and Port) for the attack:




- The attack consists of brute forcing 2 payloads: the 1st payload is inserted into the username position and the 2nd payload is for the password:




- The first payload is defined with a simple list of two possible usernames:




- It is interesting to notice that the Pro version of Burpsuite allows to introduce a complex password list previously crafted or generated by the attacker:




- About the second payload, referred to the password, Burp prompts the user with a charset of lowercase letters, numbers, and a length of 5. 




- However, because of the huge amount of requests that Burp would generate (60466176, it would take hours to check all of them), I have simplified the process using a very easy charset with the letters "ab" and a length of 5.

- In this way, the number of request counts would be VR(2,5) = 2^5=32, multiplied by 2 because the first payload list is composed of 2 possible usernames. To sum it up, 64 requests:




- Starting the attack:




- Once the attack is developed, it can be noticed that all the results have a length of 411, with the exception of the 22nd one, whose length is 383:




- For instance, checking the rendered response for the 33rd request, the answer is that the user is not authorized to access the web page, so the corresponding combination (daniel:aaaab) is not correct:




- However, doing the same for the 22nd response (the one with different length) the answer is positive. We find that the user is authorized and welcome to the web page: 




- Looking at the response in a raw format:




- We can deduce that the combination used for that request is correct (admin:ababa) and the attack has been successful.

Cracking HTTP Digest Authentication with Hydra

CRACKING HTTP DIGEST AUTHENTICATION WITH HYDRA

- Layout for this exercise:




- Creating a list for users:




- Creating a list for passwords, 5 characters with the limited charset of "ab":







- Launching Hydra, and passing as parameters the lists of users and passwords:






- A successful password has been found. Checking the credentials, the web resource is available:









- Note: in this exercise a very simple combination of username:password has been used,  because the purpose was just to illustrate the usage of the attacking tools. However, in real world there are available complex lists of combinations of username:password that can be used for performing dictionary and brute force attacks. The Kali command #locate wordlists provides many available wordlists, for instance into the folder /usr/share/wordlists

HTTP Basic Authentication bruteforce attack with NSE (Nmap Scripting Engine)

HTTP BASIC AUTHENTICATION BRUTEFORCE ATTACK WITH NSE (NMAP SCRIPTING ENGINE)

- Layout for this exercise:




- This exercise is based in the previous post Setting up HTTP Basic Authentication.

- The Nmap http-brute script is part of the NSE (Nmap Scripting Engine) and performs brute force password auditing against http basic, digest and ntlm authentication.

- Some of the possible arguments are:

     http-brute.hostname = sets the host header in case of virtual hosting
     http-brute.method = sets the HTTP method to use (GET by default)
     http-brute.path = points to the path protected by authentication

- For more information about this NSE script:

https://nmap.org/nsedoc/scripts/http-brute.html

- In this example we are pointing at the resources identified by the URL www.whitelist.com/basicauth/

- Let's suppose simple credentials, for the ease of this exercise:

username = admin
password = ababa

- Creating users.txt and passwords.txt, both stored into the root(/) folder:










- Launching the http-brute script with the right options, the brute force is successful in just 0.08 seconds:






- Checking that the credentials are correct:






- Note: in this exercise a very simple combination of username:password has been used,  because the purpose was just to illustrate the usage of the attacking tools. However, in real world there are available complex lists of combinations of username:password that can be used for performing dictionary and brute force attacks. The Kali command #locate wordlists provides many available wordlists, for instance into the folder /usr/share/wordlists

Calculating HTTP Digest Authentication parameters with Wireshark and Python

CALCULATING HTTP DIGEST AUTHENTICATION PARAMETERS WITH WIRESHARK AND PYTHON

- Layout for this exercise:

- This  exercise is based in the previous post Setting up HTTP Digest Authentication.

- HTTP Digest Authentication (DA) applies a hash function to the username and password before sending the credentials over the network.

- DA was originally specified by RFC 2069, although it was later replaced by the more secure RFC 2617. For instance, the new standard protects against the chosen-plaintext attack cryptanalysis.

- The process consists of 3 steps:

1) H1 = MD5 (username:realm:password)

2) H2 = MD5(method:URI)

3) response = MD5(H1:Nonce:NonceCount:ClientNonce:qop:H2)

- Nonce is randomly generated by the server and helps preventing reply attacks due to the presence of timestamp; NonceCount prevents reuse of nonces (the value increments each time a new request is done); ClientNonce is created by the user and prevents collision attacks from rainbow tables; and qop ("auth" for authentication) is the quality of protection.

- Since client and server share same information, both parties perform their own calculation for the "response".

- Once the server receives the "response" from the client, it verifies whether there is a match with its own calculation. Only in case of matching then the server allows authorization to the resources.

- The goal of this exercise is to illustrate how HTTP DA (RFC 2617) calculates the "response" using repeatedly the algorithm MD5.

- First of all, let's launch the sniffer Wireshark at the Kali machine, filtering packets for just the HTTP protocol:

- The client Kali tries to access the web resource and the server responds with an authentication requirement:

- Once the client enters the correct credentials, the server allows access to the web page:

- Now, let's examine the packets captured by Wireshark, limiting to those exchanged by the client (192.168.1.13) and the server (192.168.1.15).

- The third packet corresponds to the client sending the correct credentials, because the next one (the fourth) corresponds to the 200 OK successful answer from the server:

- Opening the third packet, all the parameters used in the DA transaction are displayed:

- Copying the parameters to a text file for further study:

- Now, all parameters are available so that we can reproduce the calculations performed by server and client:

- Using a Python script with the previous parameters:

- The "response" is finally calculated:

- We can check that our "response" is equal to the "response" calculated by server and client in the previous example: