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
- 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.
