Path Traversal

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,  Seattle VM 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,  Seattle VM 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:

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.

 

Cross-Site Request Forgery

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: http://bit.ly/2usqhMn

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]

 

TLS handshake between client web browser and server

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 ! 🙂

How a certificate patch a Man-In-The-Middle attack ?

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.

How does the signature encryption mechanism work ?

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 !

How does the ciphering encryption mechanism work ?

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 🙂