Abstract - · PDF fileEach of the tasks do not have anyone one solution nor does ... values...
-
Upload
trinhxuyen -
Category
Documents
-
view
214 -
download
0
Transcript of Abstract - · PDF fileEach of the tasks do not have anyone one solution nor does ... values...
Open Source Vulnerabilities in a Virtual Environment
1 Florida State University iSchool
THE ULTIMATE COVER UP: PLUGGING THE HOLES IN
SQL INJECTION AND XSS
Michael Kimball Matthew Shearer Bernard Hudgins Florida State University Florida State University Florida State University
[email protected] [email protected] [email protected]
Bradley Prior Andrew Anderson Patrick Burke
Florida State University Florida State University Florida State University
[email protected] [email protected] [email protected]
Abstract The purpose of this research paper is to extrapolate potential security flaws within a basic Linux based web server
in a controlled virtual environment, and analyze the potential dangers of the lack of security in a real world setting. A hacking exercise was attempted, to exploit server vulnerabilities in a Linux variant operating system and scripts
enabled by the PHP open source scripting language. Apache and PHP files were used in the formation of a dummy
website on the server, which needed a degree of security measures to eliminate the risk of remote users executing
scripts as shell commands. For this research project the website was hosted on this virtual server, and then injected
with shell commands in a text field, which allowed for the manipulation of the server side scripting. This
demonstrated the potential, veritable flaws within the security features that could be found within a web server. In
addition to finding to determining flaws in a basic server setup, an exercise in cross site server was also attempted,
which exploited vulnerabilities on the host end of a web client to host interaction. In this exercise, a server was set
up to host a dummy web page with parameters to accept input from a user to establish a session, and is then
directed to another site that proceeds to steal the cookie established by the user. This demonstrates that securing a
web server requires defensive measures both on the server end, and also on the user end. The results of these
experiments were documented, and then analyzed to show how the vulnerabilities within this test environment can
also exist in a real world setting, and the implications that this has for server security on both the client and host
side. Keywords: Apache, PHP, Open Source, Linux, Scripting, Server Vulnerability, Injection,
Security
Introduction In today’s society there has been a boom in the security industry for security professionals to take up the digital
shield and defend against online hackers who seek to take advantage of systems and users for their own malicious
ends. For the purpose of our research endeavor a group of Information Technology students were given two tasks,
the first to hack a server using scripts to take advantage of vulnerabilities on the server side of a system. The second
task hacks a web application from the client’s side of a system taking advantage of user input. All of the actions
taken to test the security were documented and evaluated for their potential application in a real world setting. These
two tasks represent the general notions of how an attack may occur, the first task aimed towards the server, the
second task aimed toward the user. Each of the tasks do not have anyone one solution nor does the problem exist in
any one state. The problems and solutions discussed in this paper are aimed for educating and informing possible
real world occurrences, while demonstrating a controlled demo of simulated attacks.
This paper is for educational purposes only and demonstrates technical actions that may be regarded as illegal and
have serious consequences outside of the controlled environment. It is critical to evaluate web security in the digital
age to ensure protection against attacks that have become commonplace in the real world. The paper is an attempt at
replicating these attacks so that defenses can be built and refined in the future. The first step in the group’s first
project was to gain access to Florida State University’s College of Communication and Information’s course
Open Source Vulnerabilities in a Virtual Environment
2 Florida State University iSchool
website: labs.cci.fsu.edu in order to access Dr. Ho’s folder which contains a remote desktop app. The remote
desktop app allows for the use of virtualized servers, which is the environment that this scenario was executed in. During this experiment on security vulnerabilities, Apache, PHP, and MySQL were used to set up the target web
server, with no other functionalities in order to preserve the sterility of the testing environment. Referred to as
LAMP, (Linux server with Apache, MySQL, PHP) this environment is extremely popular in a real world setting.
This allows us to make inferences on how the security standards for the test web server can handle real threats. Some of the limitations of this research paper are in its limited scope: the environment is only conducive to open
sourced software. Throughout this research paper the scope of this experiment will be elaborated on, and then
analyzed to provide context on the nature of these vulnerabilities through other referenced research papers.
Literature Review Sanitizing Inputs Defending against Buffer Overflow Vulnerabilities is from the Nanyang Technological University in Singapore and
explains techniques on how to patch buffer overflow vulnerabilities (Padmanabhuni and Tan, 2011). They discuss
how most web applications are written in the C language. The C language writes Linux’s operating system. If the
memory is not allocated correctly the attacker can exploit this weakness and inject malicious code. They explain
methods in prevention such as sanitizing data and making sure that the memory is allocated correctly. Stanford University’s study on the subject of vulnerabilities called Static Detection of Security Vulnerabilities in
Scripting Languages by Vichen Xie and Alex Aiken, provides background on potential flaws with server security
(Xie, 2006). Personal Home Page: Hypertext Processor, commonly known as PHP, is a server side scripting
language that is currently running on the virtual server for our research. PHP is a Perl-based language, and its
vulnerabilities are based on some of the security flaws of its origins. One of the most common forms of security
vulnerabilities is ‘SQL injections’ which occurs when PHP is used in conjunction with Sequel, a relational database
language that is used to store data. Variable values in PHP are not bound in the same way that they are in Java,
allowing for users to manipulate the variable values to inject malicious SQL code or circumvent insertion
limitations. In addition to PHPs vulnerabilities with SQL, the unused variables within PHP’s code are left as null
when not used. This can cause serious problems, as posited by the Stanford research paper.
Securing Servers University of California-Berkeley Lab’s Cyber Security department explains how to properly secure an Apache
server, where they discuss the details of proper server configuration. Apache is the most frequently used Web
server, and while it is true that it is more secure than most available web servers it is far from being completely
secure. A common issue with many Apache web servers is not with the server software itself, but with the way it is
setup, which can leave it vulnerable and open to attack; much like the activity done for this project.
The article from the International Journal of Advanced Research in Computer Science gives a thorough breakdown
of the multitude of virtual environments that exist, and potential vulnerabilities. Virtualization allows for the
optimization of resources within a particular organization. There are different types of virtualization that include
desktop, network, server, application, and storage virtualization. There is a convenience in allowing VMs to connect
to other VMs or directly to the host. An obvious vulnerability to this is the access to host resources and file systems.
This can lead to an exhaustion of virtual and host resources or serve as a gateway for harmful programs. Good
isolation methods ensure that these machines do not have a cascading effect to the others as well as the host. Careful
configuration must be administered when isolating virtual environments to prevent VM (virtual machine) take-over
and access to the underlying host. Configuration is key to a fully functioning and fully secure VM environment
where denial of service attacks are rendered ineffective through the proper allocation of resources, disallowing any
guest to drain resources from other virtual machines (Kanth, 2013).
Web Server Vulnerabilities and a Defense in Depth Strategy Using the Squid Proxy (2004) by Brewer, is about a
security strategy for a web server that includes using a proxy. This paper covers many types of vulnerabilities,
Open Source Vulnerabilities in a Virtual Environment
3 Florida State University iSchool
namely Invalidated Input, Parameter Tampering, Cookie Poisoning, Cross Site Scripting, SQL Injection, Improper
Error Handling, Insecure Storage and Denial of Service. Then it talks about Squid and what it does, most of its
features, and why it’s important. Then it talks about building a network and what components to use that work with
Squid and overall recommendations. As it teaches you how to setup your server with the proxy, it notifies you when
you plug holes and protects against vulnerabilities.
Secure Technologies In "The Tragedy of the Cybercommons: Overcoming Fundamental Vulnerabilities to Critical Infrastructures in a
Networked World", Emily Fyre states how "Computers power the economy...The economy operates because of the
functionality that computers provide; computer should be viewed as a critical infrastructure"(Fyre, 2002). Because
of this, servers need to be protected at the highest level. Systems were originally designed for trusted individuals,
however nowadays users require more access to the Internet, increasing potential security risks. When the
communication mechanism TCP/IP was introduced, Fyre states how it "was not designed for security; it was
designed for usability...TCP/IP made sense because the user base still was presumed to consist of trusted
participants" (Fyre, 2002). While this is no longer the case, TCP/IP still is not inherently designed with security in
mind, and security is not native to its core.
In Sharon D. Nelson's and John W. Simek's "Data Breaches: Damage Control after the Dam Bursts", they look into
these matters and inform the reader on how "The Ponemon Institute reported in February 2007 that only 18 percent
of companies routinely encrypt their data, despite the fact that 61 percent of executives and IT managers believe it is
important to do so"(Nelson - Simek, 56). That was a mere seven years ago, a time where smartphones had begun to
become the standard in communication for the general population, a time where technology was looking quite
advanced, but was not being protected well enough. Nelson and Simek go on to state how data breaches are
extremely hard to bounce back from, and that prevention works immensely better than a cure or damage control. Their words "Security is cheap- data breaches are not"(57), stands quite true, as there are a number of encryption
software options available which can be applied to servers, as well as the standards of Triple-DES and RSA. Also,
by providing clear administrative and user limitations, as well as eliminating back doors in the network, servers
become more secure. Not allowing a low-level user to install programs on a computer connected to a server could
prevent them from loading a key logger and releasing sensitive information. Although servers will never be
complete secure, with active maintenance and management to security, the risk can be significantly dropped.
Cross Site Scripting Cross Site Scripting (XSS) takes advantage of web applications by injecting attacking scripts into the web
application after which they execute with the privileges of the current web site on browsers. This type of attack as
explained by Helen Wang in Attacks Target Web Server Logic and Prey on XCS Weaknesses, has been plaguing
Web application vulnerability for a long period of time. Cross Channel Scripting (XCS) however is a more
sophisticated form of XSS attacks according to The Emergence of Cross Channel Scripting by Hristo Bojinov, Elie
Bursztein, and Dan Boneh. XCS is when attack injection and execution are carried out via different protocols,
typically these attacks use non-web channels such as File Transfer Protocol (FTP) or Simple Network Management
Protocol (SNMP) to inject a persistent XSS exploit into web content that runs in a different security context. These
attacks aim to carry out a variety attacks that include gaining sensitive data, redirecting the user to a malicious site,
or exploiting the user IP to setup a DDoS attack. The attacker’s targets are prevalently consumer electronics such as
digital photo frames, wireless routers, and network attached storage appliances (Bojinov, Bursztein, Boneh, 2010). Since XCS attacks are very similar to XSS attacks, they also can be prevented in a similar manner, according to the
Stanford University team. They recommend, as we will later in this paper, that one of the best defenses against any
injection attack is the sanitization of all code and the user’s web browser.
The article Exploitation of Cross-Site Scripting (XSS) Vulnerability on Real World Web Applications and its Defense
explains how hackers attack web application using HTML and JavaScript to perform Cross-Site Scripting attacks. This article goes into detail about vulnerabilities that are being exploited by the attackers to steal web browser’s
Open Source Vulnerabilities in a Virtual Environment
4 Florida State University iSchool
resources (cookies, credentials, etc.) by injecting malicious JavaScript code into the victim’s web applications. The
hackers exploit these vulnerabilities by changing the client side, where they can collect the users’ information. The
authors talk about how to fix these vulnerabilities using a sandbox environment to test the web applications.
Cross-site scripting attacks are one of the most common ways hackers try to gain unauthorized access. When a user
is logged in on a website the server creates a cookie to store the state of each user. Cookies are hashed private keys
that cannot be forged and whenever the user makes a request the server compares the cookies received through the
user’s browser for authentication purposes. If the cookies do not match the session between the user and website
will be disconnected. Cross-site scripting attacks occur when there are flaws in the server-side web applications
(Zuchlinski, 2003). Hackers can steal cookies through linking malicious script code that the user cannot see to
textboxes that are not sanitized for HTML characters. The hacker can then insert arbitrary HTML then they would
be able change the execution of the page through the permissions on the site (Zuchlinski, 2003). The page will be
redirected to another location of memory in the shell code where the attacker has full control of the program
(Zuchlinski, 2003). The GET method is placed on the rendered page so when user enters their username and
password and is unaware that someone has stolen their cookie now has access. For example there are online banking
account which the hacker later could perform a masquerade attack to steal money or other important information
without having to use the victim’s password. Attacks can also use JavaScript code to redirect a page as well
(Zuchlinski, 2003).
In the article C and C++: Vulnerabilities, Exploits and Countermeasures the author writes about how C is a function
oriented programming language created in the early 1970’s by Bell labs. It is an influential computer language and
many later languages such as Perl and PHP borrowed code in their creation. Linux is also written in C, which
provides certain vulnerabilities in the foundation of Linux. Because other languages have used C as a base for their
creation, they display vulnerabilities as well. One such vulnerability is memory. The programmer must control
memory allocation and relocation. There are three methods of memory allocation: dynamic and static. The compiler
for C does not detect errors in memory allocation, which can be problematic for Linux. For example, when writing
the bounds of the allocated memory, a hacker can recognizes error and override memory locations inhibiting the
system so an attack may be performed.
The C language greatest vulnerability is buffer overflow. Buffer overflow occurs when a program is writing to a
buffer. Data overruns the buffer’s boundary and begins to overwrite other memory (Younan, 2013). This corruption
causes the program run slow or become unresponsive. C also is inefficient at identifying strings. An array is a string
of characters. Programmers must be aware of the limitations of the strings and fix them. In Linux, once a hacker is
aware of the strings, he or she must perform a SQL injection. A SQL injection occurs when the attacker can insert
malicious code to a field therefore altering or dumping database memory to the hacker.
Cookie Authorization Protocols
Cookies on computers are not the sweet smelling treat most people think they might be. According to Microsoft,
“Cookies are small files that websites put onto your hard drive when you first visit.” (Microsoft 2014) Cookies are
unique identifiers that help websites customize themselves for the viewer. Cookies in both terms are great, but they
can be manipulated to gain access to restricted data. Cookie authorization protocols were created so that hackers
when hackers manipulate the cookie, the website will not read it.
In a paper written by three students at Michigan State University wrote about cookie authorization protocols and
how they need to provide certain services. These services are: Authentication, Confidentiality, Integrity, and Anti
Replay. These students created, tested, and implemented their own cookie authorization protocol named “Fu’s
Open Source Vulnerabilities in a Virtual Environment
5 Florida State University iSchool
cookie protocol.” After, they discussed the results of the “Fu cookie protocol” and compared it to other functioning
protocols.
Authentication is key in the cookie authorization protocol process. It has to be known to the server that the cookie its
reading was written by the website and not something foreign. They first say that cookie authorization starts at
authenticating the client by the server. In a secure web application, this is easily accomplished with the use of two
phases, the login phase and the subsequent-requests phase. In the login phase, there is a mutual authentication
process between the server and client. The client double-checks the URL and the site layout to make sure that the
website that he is attempting to gain access to be the correct website and not a copy. Then the client inputs his
credentials, which can include a username, and a password to unlock the username’s data. After logging in, the
server sends a cookie to the client’s hard drive, which is also called an authentication token, or authenticator. Because the cookie is sent, and the server accepted the credentials, the client will be able to access all of the user’s
data because of the authenticator. A good cookie authorization protocol will be clear to the client and efficient and
secure for the server.
Confidentiality is important for cookies, because nothing other than the specific website should be able to read its
own particular cookies. If anyone can read and understand the cookies, the server’s data would be very vulnerable.
In this paper, they discuss two types of confidentiality, High-level and Low-level. The difference between High and
Low levels of confidentiality according to the authors are that Low-level cookies can be read by both the client and
the server. High-level cookies are to be read by the server only. With that being said, all cookies sent to a client’s
computer are encrypted for protection. Amazon and Google to help them know which ads or products to advertise
would use Low Level cookies. High Level Cookies could be username and password data, or possibly credit scores,
or bank account information. A good cookie authorization protocol should be able to support both high and low
levels of confidentiality configurations.
Integrity and Anti Replay, although very important, do not have many attributes. Integrity is simply being able to
determine if something has been modified or manipulated. In this case, the server should be able to determine
whether or not the cookie last sent to the hard drive has been modified by any way by any third party applications.
Also, the server should be able to determine when a cookie expires. This is a Anti Replay service, not letting the
next client on possibly the same hard drive access the first user’s data. This makes sure that the second user cannot
use the same cookie to gain access to the server’s data. Therefore, a good cookie authorization protocol is be able to
identify if the cookie has been modified, or if it being reused.
In Fu’s Cookie Authorization Protocol, the cookie issued to each hard drive consists of 4 sub fields. These subfields
are: User Name, Expiration Time, Data, and a Keyed-Hash Message Authentication Code (HMAC). The user name
is a primary key, a unique identifier between the client and the server. The expiration time is a set time, expressed as
seconds past 1970 GMT, shows when the server should deny the cookie. The data placed in the cookie is any
information that the server wants to store on the clients hard drive. For example, this could be what items are in your
shopping cart when shopping online at Macy’s. The Keyed-Hash Message Authentication Code has a particular
value given the above data and the server’s individual key.
The first problem they encounter is with Cookie Confidentiality. Fu’s cookie authorization protocol does not
account for this. A solution would be to use the server key to keep it secures, but if you gather enough cookies,
using software and mathematical analytics, you would be able to decode the server key. You could generate a
random key for each cookie, but then it would overload the database, and when one cookie with the encryption key
is deleted, every cookie with that key would be disabled. They decide to use the HMAC as the encryption key. With
this, it is a new encryption key every time because of the new expiration time. It keeps the server key secure. It does
not require any more data storage as it is create dynamically.
Open Source Vulnerabilities in a Virtual Environment
6 Florida State University iSchool
The next problem is Replay Attacks. An attacker would first steal a cookie from an authorized user. Then they use
the cookie in a SSL connection with the server. Their solution is to add the SSL session key into the HMAC, this
would make each session unique and unable to be reused. The cookie would be specifically made for the current
session and the current session only. Each new session would have a new key. Therefore you cannot reuse the
cookie. You couldn’t change the session key in the cookie because it is implanted into the hashed code.
The final problem is Volume attacks. A volume attack against this server would be first collecting many cookies
using the same key, and discovering the key. One inefficient solution could be changing the server key periodically.
But using multiple keys to identify code is obviously inefficient. They plan to use the encryption key, the HMAC.
This changes every time, is unable to be forged, and it doubles as the encryption. It’s like picking an impenetrable
lock, and each time you take a break, or if you take too long, the lock changes and you start from scratch.
After testing their new cookie authorization protocol from Fu’s cookie protocol, it surpasses the original in every
stage. Each problem that the old protocol faced, the new one fixed. They were very close to efficiency but the new
protocol surpassed the old one in security. In conclusion, the basics of the cookie authorization protocols and what
they are made to do can be useful in updating and creating a new and improved protocol.
Discussion
Term-A Lab Exercise
Computing Environment
The computer environment installed on our virtual machines is called LAMP (Linux, Apache, MySQL, and PHP).
LAMP is a stacked open source software packet that is installed on half the servers in the world. We have Ubuntu
12.04 installed on our virtual machines, which is a version of Linux. We are using Apache 2.2 which is an open web
server application used to create websites. MySQL is a relational database management system used to create and
store databases. Lastly, PHP is a server-side scripting language, which is used in web development. This language
helps store data from the web pages to the MySQL database. The reason this environment was used for this project
is due to how widespread it is used on web servers around the world, which is important when making inferences to
the effect that the vulnerabilities within a LAMP stacked software can have in the real world.
Methodology
The research project required us to first access the required website “extremeinsecure.” The website represented a
mock business that developed and sold vulnerable software that could be easily accessed by hackers. The next step
was to setup permissions to the files to enable it to read, write, and execute as needed. The permissions instructed
were a 604 setting for files, and 705 for directories. In UNIX when setting permissions the proper setting is an
important factor to creating a secure environment.
These settings both yielded different results; a 604 would give the user permissions to read and write and others
permission to read only, no group permissions were set. A 705 yielded that a user has all permissions (read, write,
and execute) while others had both read and execute access, still not setting any group permissions. Another
important permission that needed to be set up was for the file process.php, it had to be given execute rights for
others, in other words invoking a chmod o+x command for the file. The reason behind this is if one wanted to access
the page that required process.php to run, one wouldn’t have access to it and that would make the website poorly
designed since users wouldn’t be able to access a normal function of the website. After placing the files in their correct location and setting their proper permissions, accessing the site was the next
step. After browsing the site searching for vulnerabilities, the products page is where the main vulnerability was
Open Source Vulnerabilities in a Virtual Environment
7 Florida State University iSchool
located. Process.php is what runs the search function and it is the main flaw in the server’s security. However
because of the vulnerabilities you are able to inject shell commands by starting out with a | or; then typing any
normal UNIX command. Some of the commands that we used to complete the project were “ls” and “cat.” “ls”
helped us get read what files were in the directory we were in. The “cat” command helped us open or run the files in
the directory. With this information, some of us were able to run some files to find some extra credit for the
assignment. Following the instructions that came after this discovery and injecting some shell commands, it led to
the end of the project.
Figure 1. All of the files in the directory that hosts the ‘extremeinsecure’ website on the server.
Results
The website was launched using Apache2, then using Mozilla from the remote desktop to navigate the page. The
page functioned normally and no vulnerabilities were apparent from the surface. Due to lax parameters and file
permissions within the products and process files, shell commands could be executed through a text entry on the
web page. Process.php does not filter any text entered into products.htm. This allows users to execute shell
commands, or scripts, through the text entry gaining access rights that should not be available. Viewing the page
source or running a cat command on process.php will give further information regarding server-side scripting. Ultimately this vulnerability allows users to explore file systems, possibly gaining access to critical files and
information that should not be readily available.
One of the vulnerabilities discovered during the hacking exercise is cross-site scripting. Cross Site Scripting, known
as XSS, can happen because of invalidated input. It is when a web application takes untrusted data and sends it to a
web browser without proper Validation. Attackers can use this to direct traffic from safe sites by means of
hyperlinks to the attackers cite, which could try to implant viruses or steal data from the user. The attacker can trick
the user into inputting his data into the website. For example, if you misspell popular social media website
“Facebook”, and put “faecbook” it will send you to a website that offers you a prize for filling out your information.
SQL injections are put in where you input data, such as a username and password. Then it will be able to read your
data, and possibly insert, update, or delete data. It could even go as far as shutting down the DBMS, recover other
Open Source Vulnerabilities in a Virtual Environment
8 Florida State University iSchool
files, or send commands to the OS. SQL injections are dangerous because they spoof identity, tamper with data, and
create many issues.
Figure 2. The process.php file acts as a simulated vulnerability for the web server.
Proper Error Handling is important because you don’t want to give the attack more information than you have to. The less the attack knows about your database, tables, and other important information, the harder it is for the
attacker to gain access to your information. When error messages are sent, usually it will give a reason for the error. In the past, when you enter your username and password and incorrectly type your password, it would give you a
message that your password was incorrect. If you incorrectly put in your username and your typo didn’t result in a
name of another user, it would tell you that the database could not find your username. Now when you put an
incorrect username or password, it will not tell you if your username or password or both were wrong. It only tells
you that you have an incorrect combination. This way, the attacker doesn’t know if the database even has that
unique username.
Insecure storage is when the way sources hold their storage, data, and databases are not secure. This could be
because they don’t encrypt critical data, secure keys, passwords, or certificates, randomness, poor algorithms, or no
support for encryption keys or regular server maintenance.
DoS attacks are any attacks that attempt to make a specific resource, a site, application, or server, to be unavailable.
This can be by manipulating network packets, programming, and many other ways. If successful, the attack though
these DoS attack can access critical information and command the operating system. This can be huge for
businesses that need to be up all day every day. If someone can flood the site and bring it down, or get inside the
server, they can do a lot of damage deleting files or stealing them.
Open Source Vulnerabilities in a Virtual Environment
9 Florida State University iSchool
In our initial exercise Term-A we created a server-side scripting vulnerability. Anything entered into the text box
will also be executed as a shell command. This is using invalidated data, because this website that we created was
using code that wasn’t properly validated. This is also very similar to SQL injections as it works the same way. This
vulnerability takes what is inputted and issues a Linux command. SQL injections do the same thing, except using
Linux commands it issues a SQL command. All of these attacks and this exploited vulnerability that we created on
our servers are all about the same thing. They are about stealing secure data. There are many different
vulnerabilities that can be easily exploited in servers. Using this specific proxy server, you can make a rule that
protects about injecting SQL into the website. Also it would protect against attaching Linux commands to the input
box.
Figure 3. products.htm represents the potential resources that would
be accessible due to the vulnerabilities on the server.
Term-B Lab Exercise
For the lab part of this project, we were instructed on how to carry out a Cross-Site Scripting (XSS) attack. These
types of attacks are often used on web applications and involve injecting code into the client-side of the program. In
our XSS attack, we change the redirection link in the html files of an extremely insecure website. By changing the
link to the local address, this allows us to input our own test information instead of having it input remotely. Our
objective in performing this attack is to steal the cookies of the client. Cookies are authenticators that are sent by the
server and stored on the client side. The client is not able to create or forge the cookie on his or her own. By using a
XSS attack, we are able to steal the cookies by injecting our script into the webpage, which the victim has accessed.
We use the victim’s browser request to call for the cookies from the server. After the request is received, the server
sends the cookie. Our code is then interpreted as JavaScript by the victim’s browser, and runs a method with steals
the cookie.
Open Source Vulnerabilities in a Virtual Environment
10 Florida State University iSchool
Computing Environment
The same computing environment was used in this part of the exercise as the first part, we used our virtual machines
loaded with LAMP that ran and hosted our web server. The browser used to locally input our test information was
Mozilla Firefox. By using the virtual Linux machine, we are assured that are computing environment is stable
because it uses very little resources and only does what you give it commands to do. Another dimension added to
our computing environment is that of HTML and JavaScript, via the .htm and .php files, be it by our own script or
that which was already provided.
Methodology
Within our virtual Linux machine, we used terminal commands to download, un-archive, edit, and run the files
needed. We began the project by downloading a zipped folder, titled ‘webhacking.zip’. Not only did this folder
contain the necessary files to retrieve the cookies, but also provided the actual website to carry out the attack on. After downloading the zipped folder and extracting it, we changed the permissions to the files, which it contained so
that we would be able to run them, read them, and write to them. Afterwards we needed to edit the links within
malURL.htm (Figure 4) file that contained two links, both of which redirected you to malicious pages, however we
just needed to edit these links to fit our virtual environments.
Figure 4 Displays the contents of malURL.htm, which will redirect you to the malicious page.
The first one brings you to the setgetcookie.htm, which is where you set your cookie that will be stolen later on; this
page is shown in Figure 5. After setting the cookie and heading back to the malURL.htm page, clicking on the
second link brings you to a .php page that steals the cookie that you just set, in this case it is your name. To verify
that the cookie has been stolen, performing the ‘cat’ function on log.txt reveals that the cookie you entered has been
captured and recorded within this file. Figure 6 shows the stealcookie.php that steals the cookie and puts the stolen
cookie into log.txt.
Open Source Vulnerabilities in a Virtual Environment
11 Florida State University iSchool
Figure 5. The process.php file acts as a simulated vulnerability for the web server.
Figure 6. stealcookie.php and its code, which ends up logging the stolen cookie in log.txt.
Results
This project is by no means an efficient or guaranteed way of carrying out a XSS attack. We were able to steal the
cookies, but only because the coding and security of our mock webpage was minimal. Whatever text was input into
the field, we were able to retrieve. All of the files used to carry out the attack, as well as the webpage files, were all
on the same site. If the input cookie in redirectpage.htm were replaced with another site, then the attack would not
have worked. This is because most modern browsers are aware of XSS attacks (older browsers are still vulnerable
however). If we had created a link, which forces the user to first visit a vulnerable site, then we would have a higher
chance of success for an older browser with more protection. Process.php could be utilized to print the values
Open Source Vulnerabilities in a Virtual Environment
12 Florida State University iSchool
passed for the username, as well as carrying out the script needed to change the document location to
stealcookie.php. However, as stated, this would do nothing on a newer browser, because they filter out scripts from
links and do not relocate to new sites. XSS attacks can also be prevented implementing proper input validation
before processing a data request. Scripting attacks are still a viable means for hackers to obtain information; they
just have to know how to approach security measures that are in place, as well as how to deliver their own code
Suggested Remedies
Setting Proper File and Directory Permissions Apache is the most frequently used Web server, and while it is true that it is more secure than most available web
servers it is far from being completely secure. The first step that should be taken for hardening a server running
Apache is running an update on the software. By having the latest update, you protect your system against many of
the common bugs and potential exploitations that could occur with hackers trying to manipulate Apache to gain
access to the data on your server. In addition, Apache has the unfortunate habit of displaying the entire contents of
its directories in an index format. You can turn off directory listing, thus preventing an unknown user from having
direct access to all of the files held within that particular directory on the web server, by changing the Options
directive within the Apache files. Apache also uses numerous modules that, if not used by the web server, should be
removed as they offer a potential tool for an attacker to access the server contents. A common issue with many
Apache web servers is not with the server software itself, but with the way it is setup, which can leave it vulnerable
and open to attack; much like the activity done for this project. Berkeley Lab’s Cyber Security department explains
how to properly secure an Apache server, where they discuss the details of proper server configuration.
Figure 7. Removing read permissions for others
Figure 8. Shell injection no longer works after ‘chmod o-r’
Running your apache server, as a super-user is not recommended; a super-user is a user who has access to all
permission and can perform any administrative function. This is also known as the root user and if you are not a
super-user you can invoke a "sudo" command to gain those administrative functions. If you are running Apache as a
super-user then you leave the server vulnerable because an attacker can exploit a bug in Apache and then gain access
to those super-user privileges. This is similar to what was done in the project as we were able to inject shell
commands and access unauthorized information partially due to a lack of permission control. We were able to
mitigate the shell injection performed by simply changing permissions around. For example, in the instructions after
assigning permissions to all files and folders, simply take away read permissions from other users to the main
Open Source Vulnerabilities in a Virtual Environment
13 Florida State University iSchool
directory where the site files are located (Figure 7) and anyone is still able to access the page as intended without
being able to inject shell commands into the products query, if attempted only the normal function is processed and
the shell injection is ignored (Figure 8). The only difference is whenever a user wants to invoke any kind of
command while in this directory, they would have to invoke super-user rights with sudo, as shown in Figure 9.
Figure 9. Access within this directory requires ‘sudo’
Keeping all software up-to-date New software releases mean functionality will change, making penetrating or manipulating different versions of
software a new task for hackers. Common implementations can mean newer functions such as security
implementations or upgrades. This in turn make the server and its operating software much more secure. Using
older versions just for the reason of being "familiar" is also something an attacker can rationalize. If it’s an older
version then attackers have had more time to prod and poke at its vulnerabilities and understand the flaws, when you
update the software you may have to stay on your toes to learn the new changes, but so will any potential attacker.
In this exercise we used Apache version 2.2.2 while the latest version is 2.4.1, and for Ubuntu we used version
12.04 while the latest version is 14.04. Both the server and OS used were not up to date and while this didn’t play a
direct role in the issue, it can help facilitate this type of attack.
XSS recommended defenses
There are a number of remedies to cross site-scripting (XSS) attacks depending on the nature of the scripting attack. However, even the most robust defenses cannot completely harden a website to prevent all forms of attack, due to
the fact that any website that requires user input has a potential vulnerability. We can only protect against the
possible malicious user input that we are currently aware of in the world. Some of the general areas to cover in order
to prevent XSS attacks are as follows.
First and foremost is to scan the current system for vulnerabilities to see what is most susceptible to an attack.
Security professionals can gear towards particular defenses depending on the state of the system and code. An
automated scanner should be considered to routinely find vulnerabilities as they appear, especially after taking steps
to secure the system or changes that might occur from policy.
Filtering content is a simple method that can catch keywords as they appear, such as <SCRIPT>, this is
accomplished through some extra code appended to the web application or dedicated libraries. Filters do have the
potential to remove valid input as they are an automated process, so developers and security professionals should
use them at their own discretion (Cross Site Scripting in Action, 2012). Updating resources also means an update to
filters that undergo routine patches.
One of the more potent methods to defend against XSS attacks is implementing escaping methods. Escaping is a
process of telling the browser that data should not be interpreted in any way, thus escaping any scripts that the data
may contain to harm the user (Cross Site Scripting in Action, 2012). These escape mechanisms must be positioned
appropriately according to the web application’s code so that they may still operate without interfering with the
websites functionality itself.
Current state and future strategies
Developers and programmers are partly responsible for the preservation of a system. Security is mostly discarded as
unimportant or unnecessary when compared to customer convenience or speedy deployment, especially at a critical
Open Source Vulnerabilities in a Virtual Environment
14 Florida State University iSchool
time like a system’s inception. If at all possible programmers or anyone qualified should gear the system’s design
against XSS attacks. Following simple rules that reflect sound security protocol, such as encoding data by the user,
sanitizing input data, or using filters to expose harmful code (Alani, 2011).
Education would also be a combatant towards XSS attacks. Without knowing what cross-site scripting is there can
be no defense against it. It’s important for developers to understand the nature of cross-site scripting attacks in all its
varying forms, such as reflection or stored attacks. Security needs to be taught, at the least suggested, to aspiring
developers not only to inform, but to foster an understanding that grows with experience in the field (InfoSec
Institute, 2013). There are researchers willing to aid developers with the development process, most often finding
incredible attack vectors before hackers and are willing to share this information to help patch vulnerabilities.
Conclusion
Securing a web server against potential malicious input, and protecting user information, is key to providing optimal
service. Too often though, many security measures and defenses are waylaid in favor for simplicity, and due to extra
overhead traffic on the network. The value for security is frequently ignored when no one is trying to access your
personal information, and only becomes important after an attack has happened. What needs to be understood is that
attacks happen every single day, and at such a large scale that the anonymity that the Internet provides cannot
guarantee that your resources will be protected. Technical literacy has reached a point where SQL injection, XSS, IP
Spoofing, and other attacks can be carried out by anyone with the ability to access Google. This is why information
security is important; it provides a set methodology to hardening, and securing server resources, as demonstrated in
the exercises performed in the scope of this research paper.
In the first research exercise we observed the potential dangers of not securing a web server against malicious user
inputs. Often websites will allow for user input, either to search through a database, or to enable a certain process on
the website. However in some cases, a user can find ways to input code into a website, which is read by the server,
resulting in a breach of security. There are many methods to secure against this type of code injection, but the most
common and effective way is to sanitize user input. Sanitizing, or the process of taking user input and stripping it of
any potential symbols or characters that could be used to insert code, allows for a user to insert data to a website and
automatically filter out the malicious component of any input. Without enabling security procedures that sanitize
input, or similar security processes, the data within the server is vulnerable to manipulation and theft. The second research exercise demonstrated the potential security issues that can occur from stealing session
variables, also known as ‘cookies’. Sessions, a fundamental part of networking and layer 6 of the OSI model, are
fundamental to establishing links between a host and a server. Misfeasors can misuse cookies, by using the data
within them to spoof the server into believing that they are an authenticated user, and access protected resources. In
this exercise we explored how threats like this could occur, using a single server to act as both the valid webserver,
and also the malicious user. While this scenario is not applicable in a real world environment in most cases, due to
the fact that the attacker is rarely the administrator in control of the web server you are accessing. However due to
the fact that users are saving their login information on remote servers in order to access secure websites without
having to constantly enter authentication information, the potential for misuse of session’s variables has increased. Thus, to prevent against such attacks, servers should have authentication processes with a challenge component,
which insures the veracity and integrity of the user.
The purpose of this paper is to analyze potential security vulnerabilities found in server-host interactions that are
replicated in test environments, and used to discern the best methods to prevent such vulnerabilities. By setting up
these exercises in a basic Linux server setup (with Apache, MySQL, and PHP) we can make extrapolations as to the
nature of common security practices, due to the popularity of this technology stack. From this we can determine the
Open Source Vulnerabilities in a Virtual Environment
15 Florida State University iSchool
best course of strategy for securing our networks against these common, but often dangerous, attacks. The ultimate
purpose of information security: to observe and analyze the nature of malicious users, and determine the best
method to defend against their attacks.
References
Alanazi, F. (2011). The History of Web Application Security Risks. International Journal of Computer Science and
Information Security, 9(6), 40-47
Brewer, J. (2004). Web server Vulnerabilities Defense in Depth Strategy Squid Proxy. Global Information
Assurance Certification Paper
Cookie Poisoning. (2014, January 1). Retrieved October 21, 2014, from
http://www.imperva.com/Resources/Glossary?term=cookie_poisoning
Cyber Security. (n.d.). Retrieved October 17, 2014, from https://commons.lbl.gov/display/cpp/Securing Apache
WebServers
Cross Site Scripting (XSS) in Action. (2012). Oeconomics of Knowledge, 4(3), 2-2.
Bojinov, H., Bursztein, E., & Boneh, D. (2010). The Emergence of Cross Channel Scripting. Communications Of
The ACM, 53(8), 105-113. doi:10.1145/1787234.1787257
Open Source Vulnerabilities in a Virtual Environment
16 Florida State University iSchool
Wang, H. (2010). Attacks Target Web Server Logic And Prey on XCS Weaknesses. Communications Of The ACM,
53(8), 104. doi:10.1145/1787234.1787256
Frye, E. (2002). The tragedy of the cyber commons: Overcoming fundamental vulnerabilities to critical
infrastructures in a networked world. The Business Lawyer, 58(1), 349-382.
How to Prevent Cross-Site Scripting Attacks - InfoSec Institute. (2013, October 10). Retrieved November 24, 2014,
from http://resources.infosecinstitute.com/how-to-prevent-cross-site-scripting-attacks/
Insecure Storage. (2013, November 28). Retrieved October 21, 2014, from
https://www.owasp.org/index.php/Insecure_Storage
Kanth, S., Jindal, R., & Mishra, S. (2013). Security Issues in Server Virtualization Environment. International
Journal of Advanced Research in Computer Science, 4(0976-5697), 263-270.
Olzak, T. (2006). Web Application Security: Unvalidated Input.
Liu, A., Kovacs, J., Huang, C., & Gouda, M. (2009). A Secure Cookie Protocol.
What is a cookie? (n.d.). Retrieved November 24, 2014, from http://www.microsoft.com/security/resources/cookie-
whatis.aspx
OWASP Top 10 - 2013. (2013).
Sharon D. Nelson, & Simek, J. W. (2007). Data breaches: Damage control after the dam bursts. Gpsolo, 24(5,
Privacy:It's None of Your Business), 54-58.
SQL Injection. (2014, August 14). Retrieved October 21, 2014, from
https://www.owasp.org/index.php/SQL_Injection
Web Parameter Tampering. (2010, March 1). Retrieved October 21, 2014, from
https://www.owasp.org/index.php/Web_Parameter_Tampering
Xie, Y. (2006). Static Detection of Security Vulnerabilities in Scripting Languages. Stanford University.
https://www.usenix.org/legacy/event/sec06/tech/full_papers/xie/xie_html/
Bojinov, H., Bursztein, E., & Boneh, D. (2010). The Emergence of Cross Channel Scripting. Communications Of
The ACM, 53(8), 105-113. doi:10.1145/1787234.1787257
Wang, H. (2010). Attacks Target Web Server Logic and Prey on XCS Weaknesses. Communications Of The ACM,
53(8), 104. doi:10.1145/1787234.1787256
Padmanabhuni B. and Tan H. (2011). “Defending against Buffer Overflow Vulnerabilities.” Retrieved October 20,
2014.
Younan, Y. (2013). "C and C++: Vulnerabilities, exploits and countermeasures." Security Research Group. Retrieved from
http://secappdev.org/handouts/2012/Yves%20Younan/C%20and%20C++%20vulnerabilities.pdf.
Zuchlinski, G. (2003). The Anatomy of Cross-Site Scripting, Anatomy, Discovery, Attack, Exploitation. Retrieved
on November 20, 2014
Shashank G. and Sharma L. (2012). Exploitation of Cross-Site Scripting (XSS) Vulnerability on Real World Web
Applications and its Defense International Journal of Computer Applications (0975 –8887) Volume 60