1. A Study of Web Service Security
Posani Nagendra Chowdary
Guide: Prof. N. Balakrishnan
Supercomputer Education and Research Center
Indian Institute of Science, Bangalore
Technical Report submitted to
Indian Academy of Sciences, Bangalore
Indian National Academy of Sciences, New Delhi
The National Academy of Sciences, Allahabad
Summer Research Fellowship-2014.
5. Certificate
This is to certify that the report, ”A Study of Web Service Security” is a bonafide work
carried out by Nagendra Chowdary P. in fulfillment of the completion of the Summer
Research Internship conducted by the Indian Academy of Sciences. It is certified that
all the corrections and suggestions indicated during the course of two months have
been incorporated in the report. The project report has been approved as it satisfies
all the requirements.
Prof N. Balakrishnan
3
6. Acknowledgment
I express my sincere gratitude to the Indian Academy of Sciences for providing this
opportunity to work at IISc. I am deeply indebted to Prof. N. Balakrishnan, Professor
and Associate Director of IISc, for his encouragement and support.
I would like to thank Mr. K P Raghuraman for guiding us throughout the course
of the internship.
A special thanks to my professors at college Prof. Anish Mathuria and Prof.
Maniklal Das, for their able guidance and support.
Nagendra Chowdary P.
4
7. 1 Introduction
Developing a software which is easy to maintain, extend and integrate with other sys-
tems has always been a problem for software developers. In the quest for designing and
writing effective software, various approaches have evolved over the years. In the begin-
ning, organizing code into modules made it easy to maintain and reuse discrete pieces
of functionality. This led to the development of large libraries of code that are still in
use. The next major revolution in software design was object orientation. Real world
softwares were modeled on the lines of virtual objects where the object had properties
which defined its state and methods to change its state. Objects could be extended
as required. This resulted in easy maintenance and extendability. This paradigm was
extended to distributed object systems where objects residing on different machines
over the network could talk to each other using various remote access protocols. With
this there was a huge demand of software services that could be plugged into the
application and customized for that specific application’s needs.
Service Oriented Architecture(SOA) is the latest popular paradigm for system in-
tegration and interoperation which revolutionized the distribution of applications over
World Wide Web. SOA is an architectural style based design whose primary goal is
to achieve minimal dependency among interacting software agents. SOA provides a
loosely coupled composition of services. A service is an atomic operation encapsu-
lating a business process. Loose coupling means the way client communicates to the
service does not depend on the implementation of service. Web Services is the current
standards of SOA. SOA has the following advantages:
• Platform Independence
• Location Transparency
• Code Reuse
5
8. CHAPTER 1. INTRODUCTION 6
Figure 1.1: Service Oriented Architecture
• Greater Testability
• Parallel Development
• Better Scalability
• Higher Availability
While SOA provides many advantages security is still a concern.
Web services are designed and published on Universal Description Discovery and
Integration(UDDI). Service providers register their web services so that consumers can
easily find the services as per their requirements. The basic SOA is shown in Figure-
2.1. A service consumer sends a service request message to a service provider and
the service provider returns a response message to the service consumer. Optionally,
a SOA can also include a service that provides a directory or registry of services. A
service consumer can discover services by examining the registry. Message exchange
is one of the core services required for system integration in SOA environments. This
message exchange is usually performed via the SOAP protocol. Since messages may
carry vital business information, their integrity and confidentiality needs to be preserved
and SOAP Message exchange in a meaningful and secured manner remains a challeng-
ing part of systems integration. Since SOAP relies on XML information Set which
introduces to the world XML based vulnerabilities. In order to ensure the integrity and
9. CHAPTER 1. INTRODUCTION 7
confidentiality W3C1
standards suggested Web Service Security such as XML Encryp-
tions and XML Digital Signatures.
The typical requirements of secure systems are integrity, confidentiality and avail-
ability. Any action that targeting to violation of one of these properties is called an
attack, the possibility of an attack is vulnerability. It has been shown that there are
many attacks against XML based Web Service technology. Attacks like Denial of Ser-
vice, Recursive payloads, Oversized payloads, WSDL Scanning and Tampering, XML
Injections, Exploitation of XML parsers & validators, XPath injection, SOAPAction
spoofing, WS-Address spoofing, XML Encryption breaking and XML Signature Wrap-
ping attacks.
Some of these attacks are not new but they are not well understood in the context
of Web Services, a good understanding of these attacks will help in formulation a
new framework against these attacks. In this current work we will demonstrate these
attacks and provide defensive solutions to these attacks also provide attack detection
techniques and present existing tools which can detect these attacks. The rest of the
chapters are organized as given below: Chapter-2 & 3 will present common vulnera-
bilities and penetration testing tools. Chapter-4 will present common vulnerabilities
in Web Services, Chapter-5 will demonstrate an attack, chapter-6 will present tech-
niques to prevent these vulnerabilities. Chapter-7 will penetration testing tools for web
services. We will conclude with Chapter-8.
1
World Wide Web Consortium
10. 2 Common Vulnerabilities
In this chapter we will demonstrate top vulnerabilities which gives an awareness of se-
curity flaws in web application security. Vulnerabilities need to be disclosed so that web
applications can secured against the attacks. Also there are many security tools which
can give the information about these vulnerabilities. Most information security tools
used their own databases with their own names for security vulnerabilities. At that
time there was no significant variation among products and no easy way to determine
when the different databases were referring to the same problem. The consequences
were potential gaps in security coverage and no effective interoperability among the
disparate databases and tools. In addition, each tool vendor used different metrics to
state the number of vulnerabilities or exposures they detected, which meant there was
no standardized basis for evaluation among the tools. To provide solutions to these
problems and to standardize these vulnerabilities projects like CVE, CWE are started
by U.S. Government.
Open Web Application Security Project(OWASP1
) is a worldwide not-for-
profit charitable organization focused on improving the security of software. Their mis-
sion is to make software security visible, so that individuals and organizations worldwide
can make informed decisions about true software security risks.
Common Vulnerabilities and Exposures(CVE2
) is a dictionary of common
names (i.e., CVE Identifiers) for publicly known information security vulnerabilities.
CVEs common identifiers make it easier to share data across separate network security
databases and tools, and provide a baseline for evaluating the coverage of an organi-
zations security tools. If a report from one of your security tools incorporates CVE
1
http://owasp.org
2
http://cve.mitre.org
8
11. CHAPTER 2. COMMON VULNERABILITIES 9
Identifiers, you may then quickly and accurately access fix information in one or more
separate CVE-compatible databases to remediate the problem.
Common Weakness Enumeration(CWE3
) International in scope and free for
public use, CWE provides a unified, measurable set of software weaknesses that is
enabling more effective discussion, description, selection, and use of software security
tools and services that can find these weaknesses in source code and operational sys-
tems as well as better understanding and management of software weaknesses related
to architecture and design.
Computer Emergency Response Team - India (CERT-In4
) are expert groups
that handle computer security incidents.
There are many definitions of vulnerability, but this one is well defined. Vulnerability
is A flaw or weakness in system security procedures, design, implementation, or internal
controls that could be exercised (accidentally triggered or intentionally exploited) and
result in a security breach or a violation of the systems security policy. - as defined
by NIST5
. The consequence of the vulnerabilities are, compromise of confidentiality,
integrity and availability of resources. Identifying these vulnerabilities and disclosing
them is important. Common vulnerabilities are listed below.
2.1 Command Injection
Command injection attack is to inject and execute the command specified by the at-
tacker in the vulnerable application. However the commands are executed with same
privilege and environment as the application has. This attacks are most possible due to
lack of correct input validation. This is a variant of the code injection attack the main
difference is that the attacker will execute his own code to extend the functionality
of the application. Injected code is executed with same privilege of the application.
This type of attacks are system dependent as the commands differ with OS. In most
of the OS commands they execute different commands by appending semi-colon to
the input text. Shell injection attacks are also same as command injection attacks.
These attacks are used to escalate privileges. There are open source tools to prevent
these attacks like Command-Injection Scanner. A simple input validation by striping
semi-colons, double quotes and fixed length inputs would prevent the attacks.
3
http://cwe.mitre.org
4
http://cert-in.org
5
National Institute of Standards and Technology
12. CHAPTER 2. COMMON VULNERABILITIES 10
OS command injection attack occurs when attacker executes system level com-
mands through vulnerable application. For e.g: C code which does OS command
injection as given below.
#include <s t d i o . h>
#include <u n i s t d . h>
int main ( int argc , char ∗∗ argv ) {
char cat [ ] = ” cat ” ;
char ∗command ;
s i z e t commandLength ;
commandLength = s t r l e n ( cat ) + s t r l e n ( argv [ 1 ] ) + 1;
command = ( char ∗) malloc ( commandLength ) ;
strncpy (command , cat , commandLength ) ;
s t r n c a t (command , argv [ 1 ] , ( commandLength − s t r l e n ( cat )) ) ;
system (command ) ;
return ( 0 ) ;
}
OS command injection attack can also be exploited through web interface. The at-
tacker supplies OS command through a web interface in order to execute OS com-
mands. Any web interface that is not properly sanitized is subject to this exploit. With
the ability to execute OS commands, the user can upload malicious programs or even
obtain passwords. OS command injection is preventable when security is emphasized
during the design and development of applications. For e.g. black box testing:
Original URL: http://sensitive/cgi-bin/userData.pl doc=user1.txt
Modified URL_1: http://sensitive/cgi-bin/userData.pl doc=user1.txt;ls
Modified URL_2: http://sensitive/cgi-bin/userData.pl?doc=/bin/ls|
With correct sanitization and permissions we can defend this attacks.
2.2 Stored XSS
Cross Site Scripting allows an attacker to embed malicious JavaScript, HTML, or Flash
into a vulnerable dynamic page to fool the user, executing the script on his machine in
order to gather data. The use of XSS might compromise private information, manip-
ulate or steal cookies, create requests that can be mistaken for those of a valid user,
or execute malicious code on the end-user systems. The data is usually formatted as
a hyperlink containing malicious content and which is distributed over any possible
13. CHAPTER 2. COMMON VULNERABILITIES 11
means on the internet. There are many ways to achieve this attack using different
types of XSS. Types of XSS are DOM XSS, Stored XSS and Reflective XSS.
Stored Cross-site Scripting (XSS) occurs when a web application gathers input
from the users which might be malicious, and then stores that input in a data store for
later use. This attack occurs mainly because of no correct sanitization of input. The
attacker can thus store the malicious content in the storage, which may later down-
loaded by the victim and once downloaded it executes the malicious content. This type
of cross-site scripting is called as Stored XSS. There is one more cross-site scripting
that is, Reflected XSS. In which the data that has been sent to the application or web
database is reflected back to the user, using this attack, the attacker can spoof as
server and can get the details of the victim.
Stored XSS allows the attacker to perform browser based attacks, few are listed
below.
• Hijacking another user’s browser
• Capturing sensitive information viewed by application users
• Pseudo defacement of the application
• Port scanning of internal hosts (”internal” in relation to the users of the web
application)
• Directed delivery of browser-based exploits
• Other malicious activities
The following are the steps that involve in performing an attack based on Store XSS.
1. Attacker stores malicious code into the vulnerable page
2. User authenticates in the application
3. User visits vulnerable page
4. Malicious code is executed by the user’s browser.
There are tools to detect this vulnerability like OWSAP-ZAP tool, Xenotix XSS
exploit framework, Acunetix web vulnerability scanner.
14. CHAPTER 2. COMMON VULNERABILITIES 12
Figure 2.1: Cross Site Scripting Attack Structure
2.3 External Control of File (CWE-73)
Software allows the user input to control or influence the files or filenames in the file
system operations. This could allow the attacker to access or modify the system level
files or other files which are critical to the application. It works on cross platforms
like Windows, Linux and Mac. The common consequences of these attacks are lose
of integrity, confidentiality and availability. Using automated static analysis we can
analyze the data flow within the software and can defend the attack.
For e.g.: For a piece of code given below it expects the user to enter file name
and will delete the temporary file that has been created. But if the attacker enter the
file name as ../../tomcat/conf/server.xml. Then it will delete the server.xml file
instead. Other common vulnerabilities that are possible related to external control of
files as listed in CVE database are CVE-2008-5748 and CVE-2008-5764
S t r i n g rName = request . getParameter ( ”reportName” ) ;
F i l e r F i l e = new F i l e ( ”/ usr / l o c a l / apfr / r e p o r t s /” + rName ) ;
. . .
r F i l e . d e l e t e ( ) ;
This vulnerability is listed in Common Weakness Enumeration (CWE6
) with ID-73.
6
http://cwe.mitre.org
15. CHAPTER 2. COMMON VULNERABILITIES 13
2.4 Weak CAPTCHA
Completely Automated Public Turing test to tell Computers and Humans are Apart
(CAPTCHA) is used to prevent automated software access or performing actions on
behalf of humans will degrade the Quality of Service of the system. But this method
has got many vulnerabilities and now it is nowhere secure. These vulnerabilities are
grouped into three types
1. Breathing Client-side Trust
2. Server-side
3. Attacking CAPTCHA Image.
Breaching Client-side Trust: In this attacks the attacker compromises the
security issues on client side which are listed below.
• Hidden fields and Client side storage
• Chosen CAPTCHA text attack
Server side attacks: In this attacks the attacker potentially manipulates the
CAPTCHA implementation at server side in order to bypass the protection.
• CAPTCHA Rainbow Tables
• CAPTCHA chosen identifier attack
• CAPTCHA fixation attack
• In-session CAPTCHA brute-force attack
Attacking CAPTCHA Image: In this attack the attacker simply captures the
image of the CAPTCHA and solves for it using Image processing or online solvers.
This may take time but one of the potential ways to break the security.
Because of these CAPTCHA improving cracking attacks (and will improve in the
future), CAPTCHA should be perceived as a rate-limiting protection only.
2.5 SQL Injection
SQL Injection is the hacking technique which attempts to pass SQL commands (state-
ments) through a web application for execution by the backend database. If not sani-
tized properly, web applications may result in SQL Injection attacks that allow hackers
16. CHAPTER 2. COMMON VULNERABILITIES 14
to view information from the database and/or even wipe it out. The common conse-
quences of these attacks are integrity, confidentiality, authorization and authentication.
We can test and detect this vulnerability using SQLmap and ZAP tools.
Typical e.g. the easiest way for the login.asp to work is by building a database
query that looks like this:
SELECT id
FROM l o g i n s
WHERE username = ’ $username ’
AND password = ’ $ p a s s w o r d
/∗ Attack ∗/
SELECT id
FROM l o g i n s
WHERE username = ’ Joe ’
AND password = ’ anything ’ OR ’ x ’= ’x ’
As the inputs of the web application are not properly sanitised, the use of the single
quotes has turned the WHERE SQL command into a two-component clause.
2.6 Malicious File Upload
To allow an end user to upload files to website, is like opening another door for a
malicious user to compromise the server. The more functionality provided to the end
user, the greater is the risk of having a vulnerable web application and the chance
that such functionality will be abused from malicious users, to gain access to a specific
website, or to compromise a server is very high. Few well known vulnerabilities that web
applications face when end users are allowed to upload files in less secured environment.
They are given below:
1. Simple file upload with no validation: This is the simplest attack where the
attacker can upload files without any restriction of file extensions and also can
access the files if the uploads are done below the server root.
2. Mime type validation: Web developers often check only mime type for securing
the uploads but malicious user can use a script or automated process to generate
HTTP.POST request and send with a valid mime type.
3. Using Blacklist Extensions: Using blacklist one can restrict the extensions but
malicious user can upload .htaccess file to modify the actions which helps him
to attack.
17. CHAPTER 2. COMMON VULNERABILITIES 15
4. Double extensions: Using invalid extension one can use the bypass the blacklisted
extensions.
5. Checking image header: Checking image header for validating image files can be
done but one can write code in comments section using any image editors and
can input malicious content.
6. Protecting upload folder with .htaccess: One can bypass this method by over-
writing .htaccess file if it is the same folder as uploads folder.
7. Client-side validation: Bypassing the file extension validation using
Following prevention methods can be used to prevent this vulnerabilities:
• If possible, upload the files in a directory outside the server root.
• Prevent overwriting of existing files (to prevent the .htaccess overwrite attack).
• Create a list of accepted mime-types (map extensions from these mime types).
• Dont rely on client-side validation only, since it is not enough. Ideally one should
have both server-side and client-side validation implemented.
• Microsofts IIS (Internet Information Services 6.0) provides integrated, reliable,
scalable, secure, and manageable Web server capabilities over an intranet, the
Internet, or an extranet.
2.7 WebDav Authentication Bypass
Web Distributed Authoring and Versioning (WebDAV) is an extension of the Hyper-
text Transfer Protocol (HTTP) that facilitates collaboration between users in editing
and managing documents and files stored on World Wide Web servers. It provides a
framework for users to create, change and move documents on a server; typically a
web server or web share. This vulnerability allows remote attackers to bypass access
restrictions on vulnerable installations of Internet Information Server 6.0. The specific
flaw exists within the WebDAV functionality of IIS 6.0. The Web Server fails to prop-
erly handle Unicode tokens when parsing the URI and sending back data. Exploitation
of this issue can result in the following:
Authentication bypass of password protected folders listing, downloading and up-
loading of files into a password protected WebDAV folder.
18. CHAPTER 2. COMMON VULNERABILITIES 16
Authentication bypass of password protected folders Assume there is a password
protected folder in C:/inetpub/wwwroot/protected/. The password protection mech-
anism is not relevant for the attack to work. Inside this folder there is a file named
protected.zip. The attacker sends a HTTP GET request to the web server.
GET / %c0%af / protected / protected . z i p HTTP/1.1
Translate : f
Connection : c l o s e
Host : s e r v e r name
As seen above the URI contains the Unicode character ’/’ (%c0%af). This unicode
character is removed in a WebDAV request. Translate: f instructs the web server to
handle the request using WebDAV. Using this malicious URI construct the webserver
sends the file located at /protected/protected.zip back to the attacker without asking
for proper authentication. Another valid request an attacker might send to the web
server is:
GET / prot%c0%afected / protected . z i p HTTP/1.1
Translate : f
Connection : c l o s e
Host : servername
IIS 6.0 will remove the %c0%af unicode character internally from the request and send
back the password protected file without asking for proper credentials. ASP scripts
cannot be downloaded in this way unless serving of script source-code is enabled.
We can overcome the attacks by disabling Web DAV or by filtering the external
HTTP requests. This type of vulnerabilities are detected by making propfind requests
with the help of the nmap tool. We can test and exploit these vulnerabilities with the
metasploit framework.
19. 3 Vulnerability & Penetration
Testing Tools
In this chapter we will present top vulnerabilities and penetration testing security tools.
3.1 Nessus
1. Current Version: 5.2.6 as Nessus-5.2.6
2. Scope: It is available as both commercial and free home use feeds.
3. Working Platforms: It works on almost all platforms like Windows, Linux,
MacOS, Free BSD, and Solaris.
4. Testing Platforms: It checks vulnerabilities on multiple platforms like Windows,
Mac OS, Linux, Solaris, BSD, Cisco iOS and IBM iSeries.
5. Security Checks: It does vulnerability scanning by uncredentialed vulnerability
discovery and credentialed scanning for system misconfigurations. It performs
compromise detection on Viruses, malwares, backdoors, hosts, communicating
with botnet infected systems, web services linking to malicious content. It checks
for Denial of services against TCP/IP stack and PCI DSS auditing. This tool
performs the security checks by providing plugins to check vulnerabilities.
6. Strengths & Weakness: The strong points of this tool are patching assistance
(i.e whenever it detects vulnerability, it can provide a solution how we can over-
come such vulnerabilities), can detect up to date new vulnerabilities and attacks
are available by installing new plugins, multiple scans.
7. Description: Nessus is used to test the vulnerabilities in web services or re-
mote systems. It is one of the top vulnerability network scanner used by many
17
20. CHAPTER 3. VULNERABILITY & PENETRATION TESTING TOOLS 18
comparators in the world. It is free, powerful, multi-platform remote security
scanner. It uses its own scripting language Nessus Attack Scripting Language
(NASL) to define how it tests vulnerability.
3.2 Hping
1. Current Version: hping3 for UNIX and hping2 for UNIX and Windows like
systems.
2. Scope: It is an Open source tool
3. Working Platforms: It works on Linux, FreeBSD, NetBSD, OpenBSD, Solaris,
Mac OS X and Windows.
4. Testing Platforms: It checks on Linux, FreeBSD, NetBSD, OpenBSD, Solaris,
Mac OS X and Windows.
5. Security Checks: Firewall testing, Advanced port scanning, Network testing
using different protocols, TOS, fragmentation, Manual path MTU discovery, Ad-
vanced traceroute under all the supported protocols, Remote OS fingerprinting,
Remote uptime guessing, TCP/IP stack auditing
6. Strengths & Weakness: The major strength of the tool is simple and easy to
use tool with high security checks. The major limitation of this tool is speed.
7. Description: Hping is a command line oriented TCP/IP packet assembler/ana-
lyzer. . It is used in Nmap security scanner. Its functionality is same as ping but
it gives more powerful than ping since it allows to construct customized packets
which is very useful in performing various security checks. Unlike ping which is
used to send only ICMP traffic, hping can be used to send any kind of packet
namely TCP, UDP etc.
Typical Usage: hping3 -i p PORT No IP, Flags i & p used to set protocols
and packet type respectively.
Protocol flags(i)
a) 0: TCP/IP mode
b) 1: ICMP
c) 2: UDP
d) 8: Scan mode
e) 9: Listen mode
Packet types(p)
21. CHAPTER 3. VULNERABILITY & PENETRATION TESTING TOOLS 19
a) S: SYN packet
b) A: ACK packet
c) R: RST packet
d) F: FIN packet
e) P: PUSH packet
f) U: URG mode
3.3 Dsniff
1. Current Version: 2.3
2. Scope: It is an Open source tool
3. Working Platforms: It works on OpenBSD, Redhat Linux, Solaris, FreeBSD,
Debain Linux, Slackware Linux.
4. Testing Platforms: It is a collection of tools used for network auditing and
penetration testing on any platform.
5. Security Checks:
a) It snarfs files, mails, messages, URLs.
b) Web spy passively monitors a network for interesting data (like passwords,
emails, files etc.)
c) ARP spoofing, DNS spoofing, macof facilities the interception of network
traffic.
6. Strengths & Weakness: The major strengths of this tool are it allows us
to explore security vulnerabilities of the packet switching networks, allows us to
counter the logistical problems of man in middle and can perform various spoofing
techniques. The major limitation of this tool is it adds delay and overhead.
3.4 Wireshark
1. Current Version: 1.10.7 as Wireshark-1.10.7
2. Scope: It is an Open source tool
3. Working Platforms: It works on multiple platforms like Windows, Mac OS X,
Arch/Debian/RedHat Linux, Solaris, NetBSD, FreeBSD.
22. CHAPTER 3. VULNERABILITY & PENETRATION TESTING TOOLS 20
4. Testing Platforms: : It is a packet sniffer used to capture live data from
Ethernet, IEEE 802.11, PPP/HDLC, ATM, Bluetooth, USB, Token Ring, Frame
Relay, FDDI, and others (depending on host platform).
5. Security Checks:
a) Troubleshooting network issues and locating bottlenecks
b) Network intrusion detecting
c) Log network traffic for forensic analysis
d) Discovering a DoS attack
6. Strengths & Weakness: Attackers use this tool to capture sensitive and propri-
etary information and also usernames and passwords, OS fingerprinting, Network
mapping. We can filter the packets based on the protocols. The limitations of
this tool are slow performance, buffer overflow attacks are performed on wire-
shark tool because of bugs in it. In latest versions some of these bugs were
rectified.
3.5 Nmap
1. Current Version: 6.46 as nmap-6.46
2. Scope: It is an Open source tool
3. Working Platforms: It works on multiple platforms like Linux, Mac OS X,
Windows, UNIX (Solaris, Free/Net/OpenBSD etc.)
4. Testing Platforms: It performs network discovery and security auditing on any
platform on network.
5. Security Checks:
a) Network discovery
b) Hosts discovery in the network
c) Hosts operating system, active services discovery in the network,
d) Hosts packet filters/firewall detection.
6. Strengths & Weakness: The strengths of Nmap are it is flexible, powerful and
portable. Easy to use. The major limitations of this tool are fingerprinting is not
accurate and it is very easily detectable.
23. CHAPTER 3. VULNERABILITY & PENETRATION TESTING TOOLS 21
3.6 Zen-map
1. Current Version: 6.46 as Zenmap-6.46
2. Scope: It is an Open source tool
3. Working Platforms: It works on multiple platforms like Linux, Mac OS X,
Winowds and UNIX (Solaris, Free/Net/OpenBSD etc.)
4. Testing Platforms: It performs network discovery and security auditing on any
platform on network.
5. Security Checks: Same as nmap. Since it is the graphical utility for the Nmap.
6. Strengths & Weakness: It is easily understandable and usable because of GUI
and can performs all the tasks of nmap, but it is slow compared to nmap.
3.7 Metasploit
1. Current Version: 4.9.2 as Metaploit-4.9.2
2. Scope: It is an Open source tool but also available as commercial with advanced
features.
3. Working Platforms: It works on multiple platform like Windows, Red Hat,
Linux, Kali Linux.
4. Testing Platforms: It performs penetration tests on any platform
5. Security Checks:
a) Penetration testing
b) Vulnerability validation
c) Phishing awareness management
6. Strengths & Weakness: The strong points of this tool are ability to add
new exploits to the framework, import vulnerability data from NESSUSNBE files
and nmap xml output. We can also perform injection into running processes,
pivoting means use comprised host to attack host on internal network. The major
limitations of this tool are majority of the exploits are available for windows,
detailed logging is enabled by default we need to set up it.
24. CHAPTER 3. VULNERABILITY & PENETRATION TESTING TOOLS 22
3.8 Nikto
1. Current Version: 2.1.5 as Nikto-2.1.5
2. Scope: It is an Open source tool.
3. Working Platforms: It works on Windows, Mac OS X, Various Linux and Unix
(Red Hat, Debian etc.)
4. Testing Platforms: It performs tests on insecure programs, files of any web
servers.
5. Security Checks: It examines a web server to find potential problems and
security vulnerabilities, including
a) Server and software configuration
b) Default files and programs
c) Insecure files and programs
d) Outdated servers and programs
3.9 SQL-Map
1. Current Version: 0.9 as sqlmap-0.9
2. Scope: It is an Open source tool.
3. Working Platforms: It works on any platform with python dependency.
4. Testing Platforms: It performs detection and injection checks of different
database servers on any platform.
5. Security Checks:It is a penetration tool that automates the process of detecting
and exploiting SQL injection flaws and taking over of database servers.
6. Strengths & Weakness: The strong points of this tool are, it is integrated
with other security tools like metasploit, w3af etc. It has many fingerprinting
and enumeration capabilities. The major limitations of this tool is performance
hog on server-side, which is undesirable on some situations.
25. 4 Web Service Vulnerabilities
Web Services is the new paradigm in the Internet communication. Web Services have
introduced a large number of new standards and technologies. It is found that Web
Services are not very much resistant to security attacks. Web Services are exposed to
well known attacks from common internet protocols and additional new attacks target-
ing Web Services. In this chapter first we will define the terminology and techniques
related to Web Services and later we will present list of security issues in the domain
of Web Services[15].
4.1 SOAP
Simple Object Access Protocol(SOAP) is a XML based messaging framework used to
exchange encoded information (e.g. web service request and response) over a variety
of protocols (e.g. HTTP, SMTP, MIME). It allows a program running in one system
to call a program running in another system and it is independent of any programming
model. SOAP provides an easy way to design protocols for communication between
applications in an intranet or over the internet[18].
In order to call a web service with out knowing the programming model need to
have an interface with which end-point consumers can understand the web service
and can use for their applications. SOAP uses XML framework to communicate the
messages and this communication language with which the consumers can understand
the web service operations is called Web Service Description Language.
In short a Web Service is a software system identified by a Uniform Resource
Identifier (URI), whose public interfaces and bindings are defined and described using
23
26. CHAPTER 4. WEB SERVICE VULNERABILITIES 24
Figure 4.1: Web Service Architecture
Extensible Markup Language (XML). These systems may then interact with the Web
Service in a manner prescribed by its definition, using XML based messages conveyed
by Internet protocols. In particular, a service provider uses Web Service Description
Language (WSDL) to describe the functionality which a service offers and publish the
description in Universal Description Discovery and Integration (UDDI). On the other
hand, a service requester discovers the service in UDDI and consumes it by sending
Simple Object Access Protocol (SOAP) messages. Above mentioned definition can be
drawn as Figure 4.1.
Since the emergence of SOAP, systems rely on the ability for message process-
ing intermediaries to forward messages. Security information is contained within the
SOAP message and/or SOAP message attachment, which allows security information
to travel along with the message or attachment. Typical SOAP message structure and
an example is shown in Figure-4.2
4.2 SOAP message security
There are two levels of secured transmission of messages they are point-to-point secu-
rity and message level security. Service Oriented Architecture(SOA) provides message
27. CHAPTER 4. WEB SERVICE VULNERABILITIES 25
Figure 4.2: SOAP Message Structure and an example
level security as opposed to point-to-point level.
Point-to-point security
Point-to-point security context preserves the security context between two processing
nodes as shown in Figure-4.3. Transport layer security (e.g. SSL, TSL) supports point-
to-point security context. Using transport layer security which is the current standards
of HTTPS, the communication in the transient, point-to-point and encryption can
guarantee authentication and confidentiality only when data is in motion but not while
data resides in the intermediate nodes. Web Service can provide such features but it
is insufficient in several ways[18].
Message layer security
Message level security aka End-to-End security deals with and solves most issues of a
transport level security scheme regarding its insufficiency, starting with maintaining a
security context (Figure-4.4) which is valid End-to-End. The identity, integrity, and
security of the message and the caller need to be preserved over multiple hops and
more than one encryption key may be used along the route with trust domains being
crossed.
4.3 Web Service Standards
Web service specifications and techniques for secure SOAs have been evolving rapidly.
Traditionally, transport level security mechanisms like Secure Socket Layer (SSL) and
Transport Layer Security (TLS) can be used to secure SOAP message in Web Service
environment. These mechanisms create a security tunnel for communication between
28. CHAPTER 4. WEB SERVICE VULNERABILITIES 26
Figure 4.3: Point-to-point security
Figure 4.4: End-to-end security
the two end points, and preserves message integrity and privacy while the message is
in transit. However, these security mechanisms are not suitable with SOAPs message-
based architecture, where intermediaries cannot see the contents of the tunnel, and so
cannot route or filter messages.
In order to overcome the above limitation of transport level security mechanisms,
OASIS (Advancing open standards for the information security) released a security
standard that can be used to achieve end-to-end security in Web Services called Web
Services Security (WSSecurity). WS-Security is the security mechanism for Web Ser-
vice working in message level. There are other standards of Web Services like WS-
Policy, WS-SecurePolicy which are standardized by W3C.
WS-Security, WS-Policy, WS-SecurePolicy and other web service standards follow
an evolutionary approach to address the End-to-End security context issue in detail.
Figure-4.5 shows a simple architecture of web service security considering different WS
standards.
WS-Security describes how to attach signature and encryption headers to SOAP
messages as well as how to attach security tokens, including binary security tokens such
29. CHAPTER 4. WEB SERVICE VULNERABILITIES 27
Figure 4.5: Simple Web Service Security Architecture
as X.509 certificates and Kerberos tickets. WSSecurity provides a framework to secure
a SOAP message using existing techniques (e.g. encryption, signature). WS-Policy
and WS-SecurePolicy[19] describe the capabilities and constraints of the security (and
other business) policies on intermediaries and endpoints. WS-Trust describes a frame-
work for trust models that enables web services to securely interoperate. WS-Trust[20]
resolves the token format mismatch; trust between client and web service can be es-
tablished.
Using WS-Security independently for each message to secure a conversation is pos-
sible, but it is rather inefficient. WS-SecureConversation describes how to manage and
authenticate message exchanges between parties including security context exchange
and establishing and deriving session keys. WSSecurity defines a SOAP header block
the so-called security header that carries the WS-Security extensions. Additionally, it
defines how existing XML security standards like XML Signature and XML Encryption
are applied to SOAP messages.
XML Signature allows XML fragments to be digitally signed to ensure integrity or to
proof authenticity. The result of the signing operationi.e. the encrypted digestis placed
in a Signature element, which again is added to the security header. XML Encryption
allows XML fragments to be encrypted to ensure data confidentiality. The encrypted
fragment is replaced by an EncryptedData element containing the ciphertext of the
encrypted fragment as content. More detailed explanation is given in XML Encryption
and Signature attacks.
30. CHAPTER 4. WEB SERVICE VULNERABILITIES 28
Figure 4.6: Message Flow
4.4 Message Flow
On the sender side or Web Service Requester in Figure-4.6, at first the Requester
will acquire the required security token from the Security Token Service and then the
protocol stack generates SOAP envelopes that satisfy its policy. It adds integrity and
confidentiality credentials under the ¡Security¿ header that is defined in WSSecurity.
The header block allows attaching securityrelated information targeted at a specific
recipient in the form of a SOAP actor/role. This may be either the ultimate recipient
of the message or an intermediary. Consequently, elements of this type may be present
multiple times in a SOAP message. An active intermediary on the message path may
add one or more new sub-elements to an existing header block if they are targeted for its
SOAP node or it may add one or more new headers for additional targets. Conversely,
on the receiver side or Web Service provider, a SOAP envelope is accepted as valid
and passed to the application if its policy is satisfied for this envelope. Normally, the
sender policy should be at least as demanding as the receiver policy.
4.5 Attacks on Web Services
In this section we present a list of attacks on Web Services[15].
31. CHAPTER 4. WEB SERVICE VULNERABILITIES 29
Oversized Payload
One important category of Denial-of-Service attacks is called Resource Exhaustion.
Such attacks target at eliminating a services availability by exhausting the resources
of the services host system, like memory, processing resources or network bandwidth.
One of the classic way of performing this attack is by querying a service with very large
request message. This is called Oversized Payload attack. For e.g. following sample
query request message gives an idea of how the attacker can frame a large request
message.
<Envelope>
<Body>
<getArrayLength >
<item>x</item>
<item>x</item>
<item>x</item>
. . .
</getArrayLength >
</Body>
</Envelope>
Web Service frameworks implement a tree-based XML processing model like the Doc-
ument Order Model. Using this model, an XML documentlike a SOAP messageis
completely read, parsed and transformed into an in-memory object representation,
which occupies much more memory space than the original XML document. An ob-
vious countermeasure against Oversize Payload attacks consists in restriction of the
total buffer size (in bytes) for incoming SOAP messages. In this case, it is sufficient
to check the actual message size and reject any message exceeding the predefined
limit While this countermeasure is very simple to implement, it is not suitable for Web
Service messages. A more appropriate approach uses restrictions on the XML infoset.
This can be realized by modifying the XML schema inside the Web Service description
and validating incoming SOAP message to this schema.
Recursive Parsing
One of the first steps in processing a Web Service request is parsing the SOAP message
and transforming the content to make it accessible for the application behind the Web
Service. Thus, the XML parsing process allows other possibilities for a special kind
of Denial-of-Service attacks, which is called Recursive Parsing attacks. An example
attack is given below.
<Envelope>
<Body>
32. CHAPTER 4. WEB SERVICE VULNERABILITIES 30
<x>
<x>
<x>
. . .
The attack resulted in a CPU usage of 100% on the target system and the services
availability was massively reduced. These attacks target on resource exhaustion. An
attack that is based on complex or deeply nested XML documents (like the one in the
example above) can be fended by using schema validation.
SOAPAction Spoofing
The actual Web Service operation addressed by a SOAP request is identified by the
first child element of the SOAP body element. Additionally, the optional HTTP header
field SOAPAction can be used for operation identification. Although this value only
represents a hint to the actual operation, the SOAPAction field value is often used as
the only qualifier for the requested operation. This is based on the bogus optimization
that evaluating the HTTP header does not require any XML processing. For e.g. a
service provided two operations: op1(string s) and op2(int x) with the respective
SOAPAction and message element also named opn. The following message (including
the HTTP header) was sent to the service:
POST / S e r v i c e . asmx HTTP/1.1
. . .
SOAPAction : ”op2”
<Envelope>
<Body>
<op1>
<s>Hello </s>
</op1>
</Body>
</Envelope>
Clearly in the above example from the SOAPAction field we can see that the message
is to invoke op2(0), but instead it invoke op1(Hello). As the HTTP header is not
secured by WS-Security and is newly created at every SOAP intermediary, it can easily
be modified. The second class of SOAPAction spoofing attacks is executed by the Web
Service client and tries to bypass an HTTP gateway. For e.g. a service provided two
operations: hidden and visiblewith the respective SOAPAction and message element
equally named. The following message (including the HTTP header) was sent to the
service:
POST / a x i s 2 / t e s t S e r v i c e HTTP/1.1
33. CHAPTER 4. WEB SERVICE VULNERABILITIES 31
. . .
SOAPAction : ” v i s i b l e ”
<Envelope>
<Body>
<hidden />
</Body>
</Envelope>
The Axis2 server actually ignored the SOAPAction value and invoked the hidden op-
eration instead. A countermeasure to SOAPAction Spoofing attacks would be to
determine the operation by the SOAP body content. Additionally, the operations de-
termined by the HTTP header and by the SOAP body must be compared and any
difference should be regarded as threat and result in rejecting the Web Service request.
XML Injection
An XML Injection attack tries to modify the XML structure of a SOAP message (or
any other XML document) by inserting content e.g. operation parameters containing
XML tags. Such attacks are possible if the special characters ¡ and ¿ are not escaped
appropriately. At the Web Service server side, this content is regarded as part of the
SOAP message structure and can lead to undesired effects. For e.g. service method
has two parameters a and b, both of type xsd:int. This service was invoked using the
following SOAP message
<Envelope>
<Body>
<HelloWorld>
<a> <b>1</b> </a>
<b> 2 </b>
</HelloWorld>
</Body>
</Envelope>
From the message it is clear that the resulting parameter values inside the service
application has been modified and the attacker was able to modify the value of b
just by modifying the content of a. It is easy to imagine a scenario in which this
can lead to unintended service behavior, e.g. access to restricted data. An important
step in detecting such attacks is a strict schema validation on the SOAP message,
including data type validation as possible. This would have rejected the message from
the example attack.
34. CHAPTER 4. WEB SERVICE VULNERABILITIES 32
WSDL Scanning
The WSDL advertises a services operations including parameters, data types and net-
work bindings. Usually, some of these operations should be accessed from the local
network only (here called internal operations), while other operations are intended to
be offered to the outer network (here called external operations).
If the Web Service is created using common Web Service framework tools, the
(only) generated WSDL contains all operations. In this case, an external client gains
knowledge of the internal operations and can invoke them.
The first step in avoiding such accesses is providing a separate WSDL to external
clients that contains the external operations only. However, as the Web Service end-
point is still externally accessible (for invoking the external operations), an attacker
can try to guess the omitted operations and call them. This attack is called WSDL
Scanning.
One countermeasure to this attack is deploying the internal and external operations
to separate Web Services, preferable even on different servers. If this is not applicable,
invocations of internal operations must be controlled and rejected if originated from
an external client.
Metadata Spoofing
A Web Service client retrieves all information regarding a Web Service invocation (i.e.
message format, network location, security requirements etc.) from the metadata
documents provided by the Web Service server. Currently, this metadata usually is
distributed using communication protocols like HTTP or mail. These circumstances
open new attack possibilities aiming at spoofing these metadata. The most relevant
attacks in this category are WSDL Spoofing and Security Policy Spoofing.
Supposably most promising for WSDL Spoofing is the modification of the network
endpoints and the references to security policies. A modified endpoint enables the
attacker to easily establish a man-in-the-middle attack for eavesdropping or data mod-
ification. If additionally a spoofed security policy with lower or no security requirements
is used, such attacks are possible despite the use of WS-Security.
To avoid Metadata Spoofing, all metadata documents must be carefully checked
for authenticity. However, the mechanisms for securing metadata documents are not
standardizedin contrast to methods for securing SOAP messages. Additionally, a prior
establishment of trust relationships is required, which is not always possible or intended.
35. CHAPTER 4. WEB SERVICE VULNERABILITIES 33
Heavy Cryptographic Processing
One of the major problems introduced by WS-Security is the flexible usability of secu-
rity elements: encryption may be used almost anywhere within a SOAP message, and
the flexible layout of the security header allows no strict schema validation. The various
possibilities for using security elements limits a schema validation to check each single
element, but neither order nor occurrence checks for multiple elements are possible.
This flexibility can be misused for attacks.
A self-evident attack relies on an oversized security header. If the target system
processes or buffers the whole security header, the target system may be effected the
same way as from an Oversize Payload attack
A more complex attack with an oversized security header uses chained encrypted
keys. In this chain, each encrypted key is used to encrypt the next key (see figure
1). Thus, the target system is forced to decrypt every encrypted key, as each key
is needed for decryption of the next one. This may effect the target system in two
ways. First, the target system must buffer every key, as it is unknown before the end
of message processing, whether an encrypted key is used for other encrypted content.
This leads to high memory consumption. Second, the decryption operations needs
processing resources. Especially asymmetric algorithms, which are typically used for
key transport, are highly CPU consuming.
As a countermeasure, the usage of WS-Security elements must be restricted, and
messages exceeding these limits must be rejected.
WS-Addressing Spoofing
The use of WS-Addressing for asynchronous Web Service calls raises a lot of attack
possibilities, which all have in common that they use modified callback endpoint ref-
erences. The most simple approach is to use an arbitrary invalid endpoint URL as
callback endpoint reference. As a result, the engine will perform the execution of the
process involved, then try to callback the initiator. This will result either in a direct
error (refused connection, HTTP server error or SOAP fault of any kind) or in a time-
out, depending on the endpoint URL the reference denotes. Thus, the engine will raise
an execution fault and call matching fault handlers and compensation handlers. All
in all, the engine will execute the full process and then perform a complete rollback.
Used as a flooding attack, this will cause heavy load on the engine. Compared to usual
flooding attacks presented above, the workload produced by each attack message is
maximized, asin most processesthe fault will be thrown within the last communication
activity of the process. Figure-
36. CHAPTER 4. WEB SERVICE VULNERABILITIES 34
The core countermeasure against any kind of WS-Addressing spoofing is verification
of the callers endpoint URL, ideally at the beginning of a process execution. This would
enable early message rejection, preventing the engine from unnecessary workload.
XPath Injection
XML documents are often treated as data stores and queried by web services that
consume and process them. As SQL is used to query traditional relational databases,
XPath is used to query XML documents. XPath like SQL is susceptible to injection
attacks which can lead to arbitrary execution of queries on the server. XPath queries
that are dynamically combined with user input may be modified by the user in a way
developer did not intend.
XPath Injection can be avoided with proper input validation.
XML Encryption Attack
The W3C XML Encryption specification is a part of the XML Security standards. It
is responsible for ensuring confidentiality in XML-based messages. But it is shown in
(12) that the XML Encryption specification is vulnerable to a specific chosen-ciphertext
attack. This attack can be applied in all scenarios, where the attacker is able to
send messages including modified ciphertext to an oracle that decrypts the message
and responds with1 or 0 according to the message validity. According to the server
responses, the attacker can decrypt the whole ciphertext. The attack is based on a
fact that the server parses the decrypted XML data. If the parsing fails, the server
interrupts the message processing[12].
XML Encryption XML documents often contain data whose confidentiality, au-
thenticity, and integrity must be protected. Therefore, the W3C consortium developed
standards describing the XML syntax for applying cryptographic primitives to XML
data: XML Encryption. XML Encryption specifies a method for achieving confiden-
tiality of the stored XML elements. First, the encryptor chooses a session key k. This
key is encrypted using a public-key encryption scheme. Afterwards, the payload data
is encrypted with a symmetric cipher. For this purpose the standard allowed to choose
between two symmetric ciphers, namely AES-CBC and 3DES-CBC.
Figure-4.7 shows an example SOAP message structure with XML Encryption. This
message consists of the following parts related to our next attack description:
1. The EncryptedKey part. This part consists of two components. The CipherData
element contains the encrypted session key k. ReferenceList contains refer-
37. CHAPTER 4. WEB SERVICE VULNERABILITIES 35
Figure 4.7: XML Encrypted SOAP Message Structure
ences to all EncryptedData elements that can be decrypted with the session
key k.
2. The EncryptedData part. This part contains the initialization vector iv in a
clear followed by the payload data, encrypted using the session key k.
Multiple EncryptedData elements sharing the same session key are listed in the
ReferenceList. A SOAP Web Service receiving such an XML document processes it
as follows. It first decrypts the session key k. Then, it uses k to decrypt all the parts
containing encrypted payload. Finally, the payload data is parsed with an XML parser
and the whole document is forwarded to the next module or business process invoca-
tion. Thus, it could also happen that the encrypted payload is decrypted, parsed, and
not processed further.
The attack on XML Encryption is due to the malleability of CBC-mode of operation.
An overview of CBC mode is given below. AES and 3DES are well-used symmetric-key
encryption algorithms. They allow to encrypt and decrypt data, whose length is 16 or
8 bytes, respectively. In order to apply these algorithms to data of arbitrary length,
the data has to be padded and split into blocks, which are then chained using a mode
of operation.
Cipher block chaining(CBC) is the most popular blockcipher mode of operation in
practice. Its functionality in the XML Encryption specification including the padding
scheme is depicted in Figure-4.8. For its description, suppose a byte string data of
arbitrary length. The data string is first padded in order to achieve a length l, which
is an integer multiple of the block-size bs. XML Encryption specifies the following
padding scheme:
38. CHAPTER 4. WEB SERVICE VULNERABILITIES 36
Figure 4.8: CBC-mode Block Cipher XML-Encryption and Decryption
1. Compute the smallest integer p > 0 such that |data | + p is an integer multiple
of bs of the block cipher.
2. Append(p1)random bytes to data 3) Append one more byte to data , whose
integer value equals p.
Using this padding scheme we get data, whose length is multiple ofbs. Now, we
can split data into blocks: data= (data(1)
, ..., data(d)
). These blocks are processed as
shown in the Figure-4.8.
XML-Encryption Attack Description The attack on XML Encryption is based
on the malleability of the CBC mode of operation: It allows an attacker, who is
in possession of the ciphertext C = (iv, C(1)
),to flip arbitrary bits in the plaintext
m = Dec(C, k) without knowing the session key k. He can simply achieve this by
flipping appropriate bits in the initialization vector iv.
Changing different bits in the encrypted XML data can lead to errors in the server
processing, which forces the server to respond with a fault message. These fault
messages can have the following reasons:
• Decryption errors: This error stems from an incorrect padding. Recall that the
last byte of a padded plaintext must include a valid padding number p(in case
of AES p ∈ 0x01...0x10).
39. CHAPTER 4. WEB SERVICE VULNERABILITIES 37
• Parsing errors: This error may have two reasons. Either the plaintext contains
an unprintable ASCII character (XML parser can parse only valid characters,
otherwise it stops processing). The other reason is that the syntax of the de-
crypted XML part is not valid. The latter means that the special escape character
0x38(&) is not followed by a valid entity reference, or an element starting with
the bracket 0x60(<) is not properly closed.
Sending differently adapted ciphertexts to the server and observing the server re-
sponses gives the attacker the possibility to efficiently decrypt the eavesdropped ci-
phertext. Given a ciphertext C = (C(0)
, C(1)
, ..., C(d)
), which contains valid XML data
including no escape characters (&), the algorithm looks as follows. The attacker per-
forms the attack in d rounds (each ciphertext block is decrypted in each In each round
i = 1...d, he takes two ciphertext blocks c = (C(i1)
, C(i)
) = (iv, C(i)
) and with these
two blocks he proceeds as follows:
1. He excludes all the left brackets from the plaintext in order to overcome the
parsing errors originating from improperly closed elements. To this end, he
iterates over the last iv byte and sends in each iteration the two blocks c =
(iv , C(i)) to the server. The number of valid responses gives him the position
of the first left bracket. Afterwards, he can flip the bit in the byte containing ’¡’
to convert it to a different valid character. He repeats this step until he excludes
all the brackets.
2. He sets the last iv byte so that the last plaintext byte contains 0x01. This gives
him a possibility to access all the proceeding bytes in the block.
3. Now, he is able to decrypt all the bytes in the block byte-by-byte. Thereby, he
uses server error responses returned by invalid parsing processing.
After execution of these three steps, the attacker has knowledge of vector x(i)
=
data(i)
⊕ iv.
XML Signature Wrapping Attack
XML Signatures are designed to facilitate integrity protection and origin authentication
for a variety of document types. One important property of XML Signature is that
signed XML elements along with the associated signature may be copied from one
document into another while retaining the ability to verify the signature. This can be
useful in scenarios where multiple actors process and potentially transform a document
throughout a business process. However, this same property can be exploited by an
adversary allowing the undetected modification of documents[13].
40. CHAPTER 4. WEB SERVICE VULNERABILITIES 38
XML Signature: XML Signature defines an XML syntax and processing rules for
signing and verifying digital signatures over one or more data objects. It sets indirect
reference to these signed objects, for each signed object a ds:Reference element is set
which points to the signed object via URI, contains a digest value computed over the
object. The complete set of information is grouped under ds:SignedInfo element. The
value is ds:SignatureValue is computed over the ds:SignedInfo element. For example
a simple SOAP message is given below.
001 <soap : Envelope ... >
002 <soap : Body>
003 <getQuote Symbol= I B M />
004 </soap : Body>
005 </soap : Envelope>
The above example is a SOAP request to a stock quote application reauesting to
getQuote of IBM. The message is residing in soap:Body element which is a child of
soap:Envelope. The application would charge for this service and thereby it need to
check the authentication and integrity. In this case the service provider will have a
policy as given below.
1. the soap:Body element be signed using WSS with XML Signature, and
2. the associated signature verification key be provided by an X.509v3 certificate
issued by one of a set of trusted Certificate Authorities (CAs).
The signed element is given below.
001 <soap : Envelope ... >
002 <soap : Header>
003 <wsse : Security >
004 <wsse : BinarySecurityToken
005 ValueType =”...# X509v3”
006 EncodingType =”...# Base64Binary ”
007 wsu : Id=”X509Token”>
008 MIabcdefg0123456789 . . .
009 </wsse : BinarySecurityToken >
010 <ds : Signature >
011 <ds : SignedInfo >
012 <ds : CanonicalizationMethod
013 Algorithm =”.../ xml−exc−c14n#”/>
014 <ds : SignatureMethod
015 Algorithm =”...# rsa−sha1”/>
016 <ds : Reference URI=”#theBody”>
017 <ds : Transforms>
41. CHAPTER 4. WEB SERVICE VULNERABILITIES 39
018 <ds : Transform
019 Algorithm =”.../ xml−exc−c14n#”/>
020 </ds : Transforms>
021 <ds : DigestMethod
022 Algorithm =”.../ xmldsig#sha1”/>
023 <ds : DigestValue >
024 AbCdEfG0123456789 . . .
025 </ds : DigestValue >
026 </ds : Reference >
027 </ds : SignedInfo >
028 <ds : SignatureValue >
029 AbCdEfG0123456789 . . .
030 </ds : SignatureValue >
031 <ds : KeyInfo>
032 <wsse : SecurityTokenReference >
033 <wsse : Reference URI=”#X509Token”/>
034 </wsse : SecurityTokenReference >
035 </ds : KeyInfo>
036 </ds : Signature >
037 </wsse : Security >
038 </soap : Header>
039 <soap : Body wsu : Id=”theBody”>
040 <getQuote Symbol= I B M />
041 </soap : Body>
042 </soap : Envelope>
Lines 003-037 contain a wsse:Security element which isa child of the soap:Header
element. The syntax and semantics for the wsse:Security element are defined by WSS.
Lines 010-036 contain a ds:Signature which is a child of the wsse:Security element.
The ds:Reference/@URI attribute contains a shorthand pointer as defined by XPointer
Framework. The shorthand pointer identifies the soap:Body element by the value of
its wsu:Id attribute. The receiver’s end will check the referenced element in the list
ds:Reference and verifies the signature by computing it on the element and checks with
the digest value given. But the adversary can use the vulnerable property that signed
element can be moved to any part of the document. The attacker simply copies the
signed element to a wrapper element and moves it to the soap:Header so that the
verification is done on the original signed element as it is pointed by its id. In the
soap:Body he can use his own element and get it executed. Example attack is given
below.
001 <soap : Envelope ... >
002 <soap : Header>
42. CHAPTER 4. WEB SERVICE VULNERABILITIES 40
003 <wsse : Security >
004 . . .
005 <ds : Signature >
006 <ds : SignedInfo >
007 . . .
008 <ds : Reference URI=”#theBody”>
009 . . .
010 </ds : Reference >
011 </ds : SignedInfo >
012 . . .
013 </ds : Signature >
014 </wsse : Security >
015 <Wrapper
016 soap : mustUnderstand= 0
017 soap : r o l e= . . . / n o n e >
018 <soap : Body wsu : Id=”theBody”>
019 <getQuote Symbol= I B M />
020 </soap : Body>
021 </Wrapper>
022 </soap : Header>
023 <soap : Body wsu : Id=” n e w B o d y >
024 <getQuote Symbol= M B I />
025 </soap : Body>
026 </soap : Envelope>
From the above we can see that lines 015 to 021 has the wrapper element which is
pointed by the reference list to verify which safely validates the original signed element
but executes the attackers request.
43. 5 Application Developed &
Simulation of an Attack
In this chapter we will shown a demonstration of an attack using a sniffer. For this we
need to have a web service running on a machine and a client program need to access.
We developed a simple web service called a False Secure Product Mart.
5.1 Writing a Web Service
Writing a simple web service requires nothing much except few modules of correspond-
ing modules. Any web service will have a business logic which is provided as services
to the clients. Once we have the logic we can code it in any language. After that
we can convert these languages into web service and corresponding methods into web
service methods using Service Endpoint Interface(SEI) of that language. For e.g. If
you want to write a web service in python then it has SEI modules like SOAPlib for
server side and suds for client side. Not only for python but every other languages
has SEI modules which help in converting normal methods into web methods. The
following code gives an idea of how a method is converted in web method using the
signature of web methods.
@soap ( String , Integer , r e t u r n s=I n t e g e r )
def getQuote ( s e l f , name , quantity ) :
d = dict ( s e l f . products )
cost = d [ name ]
return cost ∗ quantity
In the above code the function getQuote has input parameters String: name &
Integer:quantity. The signature above it converts the below defined method to a
41
44. CHAPTER 5. APPLICATION DEVELOPED & SIMULATION OF AN ATTACK 42
web method by defining the input parameters and return parameters.
Now, after creating the web methods we need to create a server which runs this web
service. Users/clients who want to use this service can access the operations of the web
service using WSDL file which will be published on the url http://serverIP/ServiceName/?wsdl.
The following code will create server and publishes web service on the specified local-
host link.
from w s g i r e f . s i m p l e s e r v e r import make server
s o a p a p p l i c a t i o n = s o a p l i b . core . A p p l i c a t i o n ( [ ProductMart ]
, ’ tns ’ )
w s g i a p p l i c a t i o n = wsgi . A p p l i c a t i o n ( s o a p a p p l i c a t i o n )
s e r v e r = make server ( ’ l o c a l h o s t ’ ,7788 , w s g i a p p l i c a t i o n )
s e r v e r . s e r v e f o r e v e r ()
5.2 False Secure Web Application
In the developed a client side web application called False Secure Product Mark. The
structure of this application is shown in Figure-5.1. In this application the client will
have a lost of products and he/she can purchase products using this application by
entering their details in the form. This application will connect to the web service
running on on a machine with specified URL of WSDL. Connecting to the web service
we need the service WSDL URL. Snapshot of the application is given in Figure-5.2.
5.3 Sniffing the packets
Using sniffers like Burpsuit we sniffed the SOAP request messages that are sent by the
client and the response by the server for the client’s request. Figure-5.4 & 5.5 shows
the packets of requests and responses. One can tamper the requests and send it to
the server using the Burpsuit tool.
45. CHAPTER 5. APPLICATION DEVELOPED & SIMULATION OF AN ATTACK 43
Figure 5.1: False Secure Web Application Structure
Figure 5.2: Snapshot of Web Application
46. CHAPTER 5. APPLICATION DEVELOPED & SIMULATION OF AN ATTACK 44
Figure 5.3: Attack Structure
Figure 5.4: SOAP Request message
Figure 5.5: SOAP Response message
47. 6 Countermeasures Against
The Attacks
In this chapter we will see countermeasure of the attacks which are proposed in the
literature. From the list of vulnerabilities and possible potential attacks we can clearly
see that most of the attacks are due to invalid schema & input validation and vulnerable
CBC-mode encryption. The following proposed countermeasures will address most of
the attacks.
6.1 XML Schema Validation
XML schema validation is an important measure for checking the syntactical cor-
rectness of incoming message. It can help, amongst others, to reduce the risk of
Denial-of-Service attacks as well as discovering invalid messages in very early stages.
Nevertheless, current Web Service frameworks by default do not perform a schema
validation step. This is mainly because of the performance implications. Another issue
in this context is the often low strictness of most schemas, which reduces the effect of
schema validation. As this schema is controlled by the service itself, it can be easily
tightened by the service developer and is automatically announced to the service client
by the Web Service description[9].
Additionally, the schema for the SOAP header (which by default can include any
element) can also be tightened to for example just include WS-Addressing and WS-
Security header elements. This way, moving signed message parts to new bogus header
blocks can be prevented. The claimed XML schema type for the wsu:Id attributes is
xsd:ID, which does not allow two occurrences with the same value. Thus the mes-
sage above is not schema valid. This property is not only useful for this special case,
but also helps determining which elements are actually signed when using XPointer IDs.
Similarly, security policy validation would avoid the possible attacks by early de-
45
48. CHAPTER 6. COUNTERMEASURES AGAINST THE ATTACKS 46
tection. The receivers security component will validate the policy and then processes
the business logic. If the messages is modified the policy will be invalidated and hence
the attack is detected. A strict policy by making a pointer to the absolute XPath
expressions for all signed elements P (a signature assertion) and a list of IDs of signed
elements I. For every p ∈ P: get the ID i of the element matching p and check if
i ∈ I . If this check is successfull, the certificate used for signature verification can
be used for access control purposes. The security policy validation checks that all
assertions are fullfilled. Additionally, as the schema validation ensures the uniqueness
of IDs, the mapping from signed elements to policy assertions is safe. And finally, as
the signed elements which are evaluated by the business logic part are uniquely defined
by the schema, the business logic will process exactly those elements, checked by the
signature verifier.
6.2 Countermeasure for XML Encryption Attack
One option is to use a symmetric cryptographic primitive that does not only provide
confidentiality, but also integrity. One option may be to add a message authentication
code(MAC) like HMAC (see ) over the ciphertext to the encrypted message. The
encrypted part must always be completely processed and parsed and the MAC must be
validated afterwards. In contrast to a digital signature, which can simply be replaced
by a different signature, the security properties of a MAC ensure that it is not possible
for an attacker to modify a ciphertext while keeping the MAC valid. In this case, our
attack becomes impossible. Another option, which provides the same improvement in
security, would be to replace the CBC mode of operation with a mode of operation
that provides message integrity, like the Galois counter mode (GCM), for instance[18].
Some other non-cryptic counter measures are suggested by [6] like blacklisting
client’s public keys and IPs that already sent a few number of invalid messages causing
security faults. Moreover, this countermeasure does not work if the attacker is able to
execute his attack from machines with different IP addresses. This is a valid assumption
when considering allocation of virtual instances in cloud scenarios.
6.3 Countermeasure for XML Signature Wrapping
Attacks
The attacks on XML signature has been first demonstrated by McIntosh in 2005, from
then many countermeasure have been developed. The list of counter measures are:
1. WS-Policy
49. CHAPTER 6. COUNTERMEASURES AGAINST THE ATTACKS 47
2. WS-Account
3. WS-UnWrap [7]
In this first two approaches the authors proposed an inline approach that takes into
account information about the structure of the SOAP message by adding a new header
element called SOAP Account,and also extended the inline approach by proposing to
take into account new characteristics of SOAP message such as the depth information
and parent elements of the signed node as well as a way to uniquely identify the parent
elements. However, none of these solutions could properly detect wrapping-attacks.
While they are handling one sort of attack properly at the same time they fail to take
care of some other types.
While in the third approach, they first build SOAP message elements structure
using ontology and then attach it in outgoing SOAP message header. Ontology lets
us build hierarchies and thesauri that can be used for expressing how elements within
SOAP message relate to one another. So if the attacker modifies the SOAP message,
it is detected by observing the change of the relationship of the signed elements. Also,
by validating the ontology in the receiving end, we will be able to detect wrapping-
attacks early in validating process. An example ontology of SOAP message structure
is shown in Figure-6.1
Furthermore, as one of the common types of wrapping- attacks is injecting false data
into SOAP messages, it is important not only to detect the attacks, but also to re-
cover from them. Therefore, in their approach, all modifications on SOAP messages
are written to a log before they are applied. So if security failures are occurred, they
could check this log and recover from effects of successful execution.
In the UnWrap approach, the SOAP message is passes through three modules which
are responsible for the detection and recovery of the attacks. First the message goes to
the Initialization Module, which observes the SOAP outgoing message structure and
attaches the ontology to it and logs the process. Then at receiver’s end Diagnosis
Module starts diagnosing incoming SOAP message and generates a security report
with details of the attacks included and sends to the next module. The next module is
Recovery Module which is used to recover the message from the attack by connecting
to the log at senders end. Then policy validation and followed by security token
validation completes the process. Figure-6.2 shows the complete procedure.
50. CHAPTER 6. COUNTERMEASURES AGAINST THE ATTACKS 48
Figure 6.1: Ontology information of SOAP message
Figure 6.2: UNWRAP Approach Structure
51. CHAPTER 6. COUNTERMEASURES AGAINST THE ATTACKS 49
6.4 Mitigating XML-Injection using Ontology
Based Detection System
Detecting malicious activities has become a great challenge with the increase of web
applications and web services all around the internet. There are two classic strategies
of detecting attacks.
1. Signature Based Detection
2. Knowledge Based Detection
Signature Based Detection A signature is a payload that identifies an attack
through some specific malicious context. Signature based detection systems usually
lead to low software detection mistake ratesnamely, false-positive rates. However, one
important limitation of signature-based attack detection is that it doesnt detect new
unknown attacks, even if they have only small variations from a known payload.
Knowledge Based Detection This detection system detects attacks based on
the previous knowledge of attacks. Two distinct classes are modeled like one for normal
behavior, containing all expected actions that define such a profile, and another for
attacks containing actions that arent considered normal. Knowledge-based detection
techniques can detect new attacks, but they usually produce a high false-positive rate.
A new detection system with low false positive rate is needed to mitigate 0-day
attacks. In [4] authors have developed an ontology based detection system which
mitigates XML-Injection attacks. In their model they modeled attack elements as
strategies representing them by classes and relationships in an ontology. With this
model by defining a semantic relationship among attack elements, attack variations
can be easily detected and automatically added to the ontologys database. Figure-6.3
shows an example of XML-Injection attack ontology.
From the figure we can see that any attack instance having at least one AttackAction
of the type Discovery, one AttackAction of the type ProbeXPath, and one AttackAction
of the type InjectXQuery will be an instance of the class XQueryInjection. For
XML Injection Detection(XID), this means that an XQueryInjection attack was de-
tected. The detection algorithm is given in Figure-6.4.
52. CHAPTER 6. COUNTERMEASURES AGAINST THE ATTACKS 50
Figure 6.3: XML Injection Ontology Structure
Figure 6.4: XML Injection Detection Strategy
53. 7 Penetration Testing Tool for
Web Services Security
In general penetration testing tools will help in understanding the possible attacks on
the system prior to the public release. Compared to the attacks like SQL injection and
Cross Site Scripting(XSS)which can be checked with a number of penetration testing
tools, but there are no tools which offers a testing of XML specific vulnerabilities. For
this reason Mr. Jorg Schwenk et al [10] developed a tool called WS Attacker1
which
automates the process of checking the web services against all the attacks as listed in
Chapter-4.
7.1 Steps for using the Tool
In this section we will list the steps that are involved in using the tool as described in
[10]. The flow of steps are shown in Figure-7.1
1. The user has to load a WSDL. This can be a local file or a URL.
2. The framework has to analyze it and extract all possible operations. Then, the
user selects the operation which will be attacked.
3. The framework must be able to generate a valid request stub for the selected
operation and provide input fields for message parameters.
4. The user submits a test request. The response to this request represents the
normal state of the Web Service. Each attack plugin will get this request-
response pair as a reference to build the attack vector.
5. The plugins have to be configured and enabled.
1
http://sourceforge.net/projects/ws-attacker/
51
54. CHAPTER 7. PENETRATION TESTING TOOL FOR WEB SERVICES SECURITY52
Figure 7.1: WS-Attacker Processing Steps
6. The framework runs the enabled plugins.
7. Results generated by the plugins are presented to the user.
Once the WSDL is loaded each attack plugin creates a request attack specific
requests and sends to the web service based on the response the plugin should be able
to decide whether the attack is success or not and then need to given an integer rating.
Like this many attacks plugins tests the WSDl file and gives a report on all the attacks.
For attack plugin developers the minimal implementation of abstract class as shown in
below.
public abstract class AbstractPlugin {
// attack i d e n t i t y
public S t r i n g getName ( ) , getAuthor ( )
, getVersion () , g e t D e s c r i p t i o n ()
, getCategory () ;
// success i n t e r f a c e
public boolean wasSuccessful () ;
public int getCurrentPoints () ;
public int getMaxPoints () ;
// r e s u l t log
f i n a l void r e s u l t ( l e v e l , content ) ;
/ / g e t the p l u g i n options
public OptionContainer getPluginOptions () ;
// main part
public void s t a r t A t t a c k ( testRequest
55. CHAPTER 7. PENETRATION TESTING TOOL FOR WEB SERVICES SECURITY53
, testResponse ) ;
}
The three important modules that need to be in the attack plugins.
• Attack identity contains methods to describe a plugin. This includes an attack
name, an author, a version and a description. In addition, a plugin category
must be set, so that the GUI can sort conjugated attacks, e.g Spoofing Attacks
or DoS Attacks.
• Success interface implements the idea of showing the impact and difficulty of
attack. It rating shows two things like, the first one is just an indicator for the
detection of a vulnerability in general, so the result will be True or False. The
second one rates the potential risk of an attack. As an example, a Denial of
Service attack might stop a server for several minutes or even completely so that
a reboot is necessary. The interface implements a wasSucessful() function as
well as a success rating, which can be seen as a fraction:getCurrentPoints()
getMaxPoints()
.
• Logging Results can be generated inside the implementation using the result()
method. This is a helper method, so it is final.
56. 8 Conclusion
In this project we studied about common vulnerabilities and various penetration testing
tools of the common vulnerabilities. Then we studied about Web Service technology in
the context of Service Oriented Architecture(SOA). The popular communication proto-
col that web services use is SOAP, which relies on XML information set to communicate
the messages. This introduces us to XML based attacks. With the introduction of
XML based tree structure in SOAP messages which are vulnerable to attacks like XML
Signature Wrapping attacks. Using CBC mode block cipher which is vulnerable to or-
acle padding attacks brings serious threats to XML-Encryption standards(as discussed
in Chapter-4). With weak schema validations in the WS-Policy has introduced at-
tacks like WS-Address Spoofing, SOAPAction spoofing, Injection attacks and many
variants of Denial of Service(DoS) attacks. There are many other attacks (as listed
in Chapter-4) that are based on the weak security policies that are implemented in
WS-Security. Attacks like Denial of Service (DoS), Injection attacks are not new but
they are not well understood in the context of Web Services. With very small security
alternatives and not well understood about the security policies may introduce serious
flaws in the implementation of Web Services, which effects the confidentiality, integrity
and availability of many business vendors.
With good understanding of these attacks one can prevent from these attacks us-
ing preventive measures like using a strict schema and policy validation and tightening
the schema based on the service. Using other black-cipher modes and ontology based
XML Signature standards (as discussed in Chapter-5). Detecting new attacks that are
not known before is also an important policy that one can adopt in the WS-policy. As
discussed in Chapter-5 XML Injection attacks are detected using Ontology of attack
classes which are used to characterize new incoming attacks. Also we can test the
system before the public release using penetration testing tools for web services. Us-
ing this ideas we can develop a new framework which detects and prevents the attacks.
54
57. CHAPTER 8. CONCLUSION 55
Future Work: The ontology based detection system can be extended further
to other web service specific attacks and we can use them to design the penetration
testing tools. XML Encryption attacks needed a new encryption model other than the
switching of mode as a countermeasure against the attack.
58. Bibliography
[1] Mr. Zhou Jing The Analysis of XML Technology in Network Security published in
2010 International Symposium on Intelligence Information Processing and Trusted
Computing.
[2] Suriadi Suriadi, Andrew Clark, and Desmond Schmidt, Validating Denial of Service
Vulnerabilities in Web Services published in 2010 Fourth International Conference
on Network and System Security.
[3] Narges Shahgholi et al, A new security framework against Web services XML
attacks in SOA published in 2011 7th International Conference on Next Generation
Web Services Practices
[4] Thiago Mattos Rosa, Mitigating XML Injection 0-Day Attacks through Strategy-
Based Detection Systems published in 0-Day Attacks and IEEE Computer and
Reliability Societies .
[5] Web Service Vulnerabilities, A white paper outlining the application level threats,
published in Security Compass.
[6] Juraj Somorovsky, Jorg Schwenk, Technical Analysis of Countermeasures against
Attack on XML Encryption or Just Another Motivation for Authenticated En-
cryption published in 2012 IEEE Eighth World Congress on Services.
[7] Aziz Nasridinov, Jeong-Yong Byun et al, UNWRAP: An Approach on Wrapping-
Attack Tolerant SOAP Messages published in 2012 Second International Con-
ference on Cloud and Green Computing.
[8] Nils Gruschka and Luigi Lo Iacono, Vulnerable Cloud: SOAP Message Security
Validation Revisited published in 2009 IEEE International Conference on Web
Services.
56
59. BIBLIOGRAPHY 57
[9] Mohammad Ashiqur Rahaman, Andreas Schaad, SOAP-based Secure Conversa-
tion and Collaboration published in 2007 IEEE International Conference on Web
Services.
[10] Christian Mainka, Juraj Somorovsky, Jorg Schwenk, Penetration Testing Tool for
Web Services Security published in 2012 IEEE Eighth World Congress on Services.
[11] Rafael Bosse Brinhosa, Carlos Becker Westphall, Carla Merkle Westphall, A Se-
curity Framework for Input Validation published in The Second International
Conference on Emerging Security Information, Systems and Technologies.
[12] Tibor Jager et al, How to Break XML Encryption
[13] Michael McIntosh, XML Signature Element Wrapping Attacks and Countermea-
sures
[14] Aziz Nasridinov et al, A Study on Detection Techniques of XML Rewriting Attacks
in Web Services published in International Journal of Control and Automation.
[15] Meiko Jensen, Nils Gruschka and Ralph Herkenhoner, A Survey of Attacks on
Web Services
[16] Daping Wang, An XML-Based Testing Strategy for Probing Security Vulnerabili-
ties in the Diameter Protocol
[17] Lina Liberti, CA Survey Finds Security Concerns Slow SOA/Web Service Imple-
mentation
[18] Mohammad Ashiqur Rahaman, Andreas Schaad and Maarten Rits, Towards Se-
cure SOAP Message Exchange in a SOA
[19] Steve Anderson et al, Web Services Secure Conversation Language (WS-
SecureConversation)
[20] Steve Anderson et al, Web Services Trust Language (WS-Trust)
