You always change your account’s password when you desire for, but
what, if your password is changed whenever the attacker wants, and that if when
you are not aware with it? Today in
this article, we’ll learn the basic concepts about CSRF attacks or how an attacker forces the user to execute
some unwanted actions that they(user) never intended to.
Table
of content
·
What are cookies and Session ID?
·
What is an SOP?
·
Introduction to CSRF attacks
·
Impact of CSRF vulnerability.
·
Manipulating user-account details
·
CSRF over Change Password
·
CSRF over Bank Transfer.
·
Mitigation steps.
What
are cookies and Session ID?
Before jumping into CSRF
attacks and how such attacks are executed, we need to understand some important
terminologies that somewhere or the other empowers the applications to be
secure.
Cookies
Cookies are basically some small
text files with a maximum of size 4KB that are stored over on the client’s browser in the form of name-value pair.
Cookies are majorly used to track or
monitor the client’s activity on the web application and even stores some sensitive data such as
username, session ID’s, password preferences, etc, which thus
can be sent back to the server for an authentication request.
Session ID’s
Similar to the cookies, sessions are some small files
too, but they are generated and stored at the server’s end. Each session is
associated with a session ID. Whenever a
user logs in, thus a session is
created with a session ID, thereby this session ID blends up into the
cookie and stored at the client’s browser and thus passed back to the web server
whenever the browser makes an HTTP request.
So whenever the client logs out or the browser is closed,
these sessions are terminated. And with every new login, a new session with a
session ID is generated.
Let’s make this more clear with the following case
scenario –
When a new user
creates up his account over the web-application, the following procedure
happens
Now, when the user visits some other section of the same
application, the session ID stored over in the user’s browser is sent to the
server for validation.
What is an
SOP?
SOP is an abbreviation
for Same-Origin Policy which is one
of the most important concepts in the web application security model. Under
this policy, a web browser permits scripts
contained in a first web page to access
data in a second web page, but this occurs only when both the web pages are
running over on the same port, protocol
and origin.
For example –
Say the web-page “https://www.ignitetechnologies.com/ceh/module1.pdf”
can directly access the content at “https://www.ignitetechnologies.com/network/RDP/module7.docx”.
But it can not
access the data from “https://www.ignitetechnologies.com:8080/bug/xss.pdf”.
As the port has been changed between the two now.
Introduction
to CSRF Attacks
CSRF is an
abbreviation for Cross-Site Request Forgery, also known as Client-Site Request Forgery and even somewhere you’ll hear
it as a one-click attack or session riding or Hostile Linking or even
XSRF, basically over in this attack, the attacker forces a user to execute unwanted actions on a web application in
which they’re currently authenticated.
To be more clear, let’s check
out the following case scenario –
Here the user “Aarti” receives a mail from the attacker, while she was doing a
bank transfer to Mr Raj Chandel’s account. She left the transaction incomplete
and checks her mail over in the new tab.
There she got the generic URL, with a content
stating that “You’ve received an amount as a reward”. Now, as she opens the URL
in the next tab, she got the Grab button
there. The transaction page was over in the other tab and this malicious
page is on the next one. As soon as, she hits the submit button, the query executes
up and the amount has been deducted from Aarti’s account without her knowledge,
or concern.
Impact
of CSRF vulnerability
CSRF is an attack that forces
the victim or the user to execute a malicious request on the server on behalf
of the attacker. Although CSRF attacks are not meant to steal any sensitive
data as the attacker wouldn't receive any response as whatever the victim does
but this vulnerability is defined as it
causes a state change on the server, such as –
·
Changing the victim’s email address or password.
·
Purchasing anything.
·
Making a bank transaction.
·
Explicitly logging out the user from his
account.
Therefore, this vulnerability
was listed as one of the OWASP Top10 in
2013. And thereby now has been reported with a CVSS Score of “6.8” with “Medium” severity under
·
CWE-352:
Cross-Site Request Forgery (CSRF)
CSRF
Exploitation
Let’s Start!!
For
this section, I’ve used bWAPP the vulnerable web-application and created an
account with the user Raj : ignite to login inside the
webserver.
Manipulating
user-account details
Over in the above image, you
can see that for creating a new user, the user “Raj” has set his secret value as “who
are you”, now if he wants to change this secret value, he can change it
from here.
But what, if his secret value gets changed
with the attacker’s desired value without his knowledge?
Let’s
check it out how!!
Let’s
open the target IP in our browser, and we will set the “Choose Your Bug” option to Cross-Site-Request-Forgery (Change Secret).
Here, we’ll be redirected to the
web-page which is suffering from the CSRF vulnerability, where you can see that
we’re having the option to change the secret value.
Now,
let’s “hit the change button” and capture the passing HTTP Request.
Form
the below image, you can see we have successfully captured the request. Time to
create a Fake HTML form, to
accomplish this, do a right-click anywhere on the screen and select the engagement tools further hit
the Generate CSRF PoC option.
This
CSRF PoC generator will automatically generate an HTML form page. Now, click on
Copy HTML in order to copy the
entire HTML code, further past the copied data into a text file.
Great!! Let’s manipulate the secret value=“” parameter with “hackingarticles”
and then we’ll save this file as “csrf.html”.
Moreover, we need to set the user name “Raj” as for whom the secret
value will get changed.
Now, we’ll use the social engineering technique to share this csrf.html file
to the targeted user.
As
soon as the victim Raj opens up this
csrf.html, there he will get a
submit button, as he clicks over
it, his secret will get changed without his (victim) knowledge.
From
the below image, you can see that he got the message as “The secret has been changed !”, over with this similar way a successful CSRF attack can even change up
the email addresses, usernames and the other personal information of the user.
CSRF
over Change Password form
“Change Your Password” feature is almost offered by every
web-application, but many times the applications fail to provide the security
measurements over such sections. So let’s try to exploit this “Change Password”
feature over with the CSRF vulnerability,
which is one of the most impactful CRSF
attacks where the user’s password will get changed without his knowledge.
Back
into the “Choose Your Bug” option select
the Cross-Site-Request-Forgery (Change Password) and
hit hack button.
Now,
let’s again “fire up the Change button” and capture the passing
HTTP Request over in the Burpsuite.
Form
the below image, you can see that we have successfully captured the request. Let’s
follow up the same procedure to generate a “forged
HTML form”.
Now,
click on Copy HTML in order to copy the
entire HTML code, further past the copied data into a new text file.
Once
we’ve pasted the HTML code, let’s now add the new password value
(attacker’s password) and the confirm password value, and then save the text
document as csrf.html
Now, we’ll again use the social engineering technique to share this csrf.html file
to the targeted user.
As
soon as the victim opens up this csrf.html, there he will get a confirm button, as he clicks over it, the password
will get changed without his knowledge.
From
the below image, you can see that the CSRF attack changes the old password set
by user “Raj”.
Cool !! Now when he(victim) tries to login with the old
password, he’ll get the error message.
CSRF
over Bank Transfer
“You might have heard some scenarios where the money is deducted from
the victim’s bank account without his/her knowledge, or a fraud has been taken
place where the victim receives an email and as soon as he opens it up his back
account gets empty.”
Wonder how CSRF is related to
all this? Let’s check out the following attack scenario.
Login inside bWAPP again, then choose the next
vulnerability Cross-Site Request Forgery
(Transfer Amount) and click on the hack button.
Over
in the below screenshot, you can see that the user “Raj” is having only 1000 EUR in his account.
Let’s try to transfer some amount from this, as the account number is
already there in the filed.
The
procedure for the CSRF attack is
similar as above, use burp suite to capture the sent request of the browser and
then share the request over on the Engagement
tools section.
Again
it will create an HTML form automatically for intercepted data. Simply click on
Copy HTML and paste it into a
text file.
Great!!
Time to manipulate the value“” field,
add amount “200” (attacker’s desired
amount) which to be transferred, save the text document as csrf.html and then share it
with the targeted user.
As
soon as the victim open’s this file up, and hit the submit button, the amount
(entered by the attacker) will be transferred, without his (victim) knowledge.
From
the given screenshot, you can see that the amount is left 800 EUR in user’s account which
means 200 EUR has been deducted from his account.
Thereby
over with such basic techniques, the attacker can make major changes over on
the victim’s account.
CSRF
Drawbacks
1. The
CRSF attack is having a major drawback, as these attacks are only successful when the attacker knows which
parameter and what values are blended in the HTML form.
2. And
even these attacks need some good social engineering technique as sometimes the
HTML forms require earlier used values as “Current
Password” to change up the new password one.
Mitigation
Steps
·
The developers should implement the use of “Anti-CSRF tokens”
·
Use of Same-Site
cookies attributes for session cookies, which can only be sent if the
request is being made from the origin related to the cookie (not cross-domain).
·
Do not
use GET requests for state changing operations.
·
Identifying Source Origin (via Origin/Referer
header)
·
One-time Token should be implemented for the
defence of User Interaction based CSRF.
·
Secure
against XSS attacks, as any XSS can be used to defeat all CSRF mitigation
techniques!
Source
:
0 comments:
Post a Comment