CSRF Hacking Tutorial on Kali Linux

성하연
7 min readJun 17, 2019

The purpose of the post is to grasp the basic idea of CSRF and to taste a little bit of the CSRF attack on HTTP protocol. The following is what is needed for setting up the environment.

  1. Virtual box (as well as extension pack)

2. Kali Linux — Kali Linux is a useful operating system to practice hacking methods in that many different programs for security as well as for web applications have been preinstalled. While installing, you may want to download from VirtualBox image version since it takes a long time to download if choosing the whole version. Once the download is complete, you may use it as a default setting, and run it through virtual box.

3. XaMPP — XaMPP is used to facilitate web applications using Apache server, MariaDB(MySQL), and PHP. As we are going to use DVWA, it is necessary. Very very important!! you need to install XaMPP with PHP 5version. (FYI, I choose 5.6.23)

4. DVWA — DVWA is the best place to practice hacking. It also helps web developers better understand the processes of securing web applications and learn web application security in a safe environment. (default ID: admin / Password : password)

5. Burp Suite — Preinstalled in Kali Linux, Burp Suite is Java-based Web Penetration Testing framework with many different tools. Once you got to this point, go to your browser setting and change the proxy configuration so that it matches with HTTP proxy from Burp Suite.

P.S) As there are a lot of sources on how to set up environments mentioned above, I intentionally neglected to spend time explaining them.

BACKGROUND INFORMATION

before going into implementation, it would be nicer to understand why and how the attacks work. To elaborate, first, we need to know what HTTP protocol is. HTTP protocol (a.k.a Hyper Text Transfer Protocol) is a network protocol for the web applications. It works as following:

Clients ask for HTTP request to server, and server responds to the client by giving status code.

However, it is very important to notice that HTTP is stateless. That is, there is no record of previous interactions and thus, users have to go through the authentication/verification process whenever they make a new request. Think of checking email. Though you have definitely logged into google to check your email, you have to log in again when you check your mailbox. What a big inconvenience! And this is where the session and cookie come in.

Two things to know. The first cookie, and second session. cookie contains data in form of dictionary for purpose of transferring data between client and server. And session is to have a state, allowing to maintain a particular state until closing the browser. The basic idea is following:

Once accessing to web application, cookie is stored at local hard disk and session ID is generated, and session ID is also stored in cookie. if clients try to access again, cookie with session ID is transferred to web server to give false impression that clients have been maintaining the state.

Changing Password with CSRF

As mentioned before, DVWA will be used throughout the tutorial. As the default setting is set to be impossible, please change its security to be low.

First, we need to know how the process normally works. Please select CSRF from the menu bar, and try to change the password. Accordingly, you can find the HTTP request on Burp-suite as following.

Get method to transfer new password being used

You can notice that Get method is used to transfer passwords without any encryption. What we are going to do is that by exploiting data from HTTP request, we aim to change the password of the victim as we have previously set.

To make it a bit realistic, I sent an e-mail claiming that I won a lottery to myself (victim) with HTML containing a malicious request. Like this. (you can find sample HTML file(csrf.html) on here)

below is the part of the code to make request to server

As seen in the figure attached above, the code is written in JavaScript and the very same parameters that we obtained from Burp-Suite is used.

Once the receiver (me) found the e-mail and clicked the provided link, you can find that Get request is transferred to web server and the password of the innocent receiver has been simultaneously changed. The thing is unless specifically notified of changing password, the victim is very unlikely to notice the change. While I have made a button to make change visible, You may try to use onload function.

On left, you can find request has successfully transferred / On right is the screen of csrf.html

IMPORTANT! In order to launch an attack successfully, it is necessary that the victim should be logged in.

Try to distinguish between normal request (left) and malicious request(right)

the grounds for a successful attack lie on the cookie. as seen above, the same cookie has been used, meaning that web server has no choice but to treat the malicious requests as equally as normal requests. Also, you can notice that the parameter for changing password and referer, origin indicating where the request came from have been changed.

Next, we will try to hack medium level. In medium level, web server tries to protect itself from being attacked by checking ‘referer’.

Changing security level to medium — it checks ‘referer’

you can see that an identical attack used for low security does not work as intended. you can check this on Burp-suite (click the response tab for the request and go to render.

Checking the response — it fails to change password

However, checking the referer cannot be an ultimate solution because attack can be implemented on the very particular web server, thus avoiding the protection scheme. Moreover, if you look into the code, it can be shown that protection will become useless if the attacker include web server address.

eregi function: check whether the value of the first parameter is included in the second parameter.

Therefore, we are going to exploit that vulnerability by changing HTML file name from csrf.html to csrf_localhost.html. (For this tutorial, we are using localhost)

Changing file name makes attack successful!

So far, so easy.

Unfortunately, I am not going to go into the last step, high security level because to avoid protection, we need a different type of attack, XSS, which goes beyond our goal. Yet, to give you brief overview of high security level, it utilizes ‘token’. The feature of token is to provide different value for every request respectively so that if the token is invalid, attack cannot succeed.

While reaching ending of the tutorial, DVWA provides one of ideal solution to protect password from CSRF attack. That is, to require users to provide current password. It can be seen if you change security level to impossible.

If the attacker implements CSRF only attack, there is no way for him to get current password. As he cannot extract current password, the attack is never going to happen.

references

Using Burp to Test for Cross-Site Request Forgery (CSRF), https://support.portswigger.net/customer/portal/articles/1965674-using-burp-to-test-for-cross-site-request-forgery-csrf-

SHARMA, R. Preventing cross-site attacks using same-site cookies. https://blogs.dropbox.com/tech/2017/03/ preventing-cross-site-attacks-using-same-sitecookies/, 2017

SCHWENK, J., NIEMIETZ, M., AND MAINKA, C. Same-origin

policy: Evaluation in modern browsers. In 26th USENIX Security Symposium (USENIX Security 17)

Who Left Open the Cookie Jar? A Comprehensive Evaluation of Third-Party Cookie Policies — Gertjan Franken, Tom Van Goethem, and Wouter Joosen, 2018

HTTP COOKIE WEAKNESSES, ATTACK METHODS AND DEFENSE MECHANISMS — Juha Jussila, 2018

ZHENG, X., JIANG, J., LIANG, J., DUAN, H., CHEN, S., WAN, T., AND WEAVER, N. Cookies lack integrity: Real-world implications. In 24th USENIX Security Symposium (USENIX Security 15) (Washington, D.C., 2015), USENIX Association, pp. 707– 721.

Mozilla. (2017, April 4). Cookie header syntax. Retrieved from https://developer.mozilla.org/enUS/docs/Web/HTTP/Headers/Cookie

Barth, A. (2011, April). HTTP State Management Mechanism. Retrieved from https://tools.ietf.org/html/rfc6265.

Mozilla. (2018, May 21). HTTP cookies. Retrieved from https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies

Tom’s Guide. (2013, September 16). Tracking Cookies : What They Are, and How They Threaten Your Privacy. Retrieved from https://www.tomsguide.com/us/-tracking-cookie-definition,news17506.html

West, M. & Goodwin, M. (2016, April 6). Same-site Cookies. Retrieved from https://tools.ietf.org/html/draft-west-first-party-cookies-07#section-2.1

Tom’s Guide. (2013, September 16). Tracking Cookies : What They Are, and How They Threaten Your Privacy. Retrieved from https://www.tomsguide.com/us/-tracking-cookie-definition,news17506.html

Hacking with Kali Linux, https://www.youtube.com/channel/UC0PtxQtMzXKOb7gKaEDXm0A

--

--