engs4851_final_certified_report

A Study of Web Service Security

Posani Nagendra Chowdary

Guide: Prof. N. BalakrishnanSupercomputer Education and Research Center

Indian Institute of Science, Bangalore

Technical Report submitted to

Indian Academy of Sciences, BangaloreIndian National Academy of Sciences, New DelhiThe National Academy of Sciences, Allahabad

Summer Research Fellowship-2014.

Contents

Contents 1

1 Introduction 5

2 Common Vulnerabilities 82.1 Command Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Stored XSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 External Control of File (CWE-73) . . . . . . . . . . . . . . . . . . . 122.4 Weak CAPTCHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5 SQL Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.6 Malicious File Upload . . . . . . . . . . . . . . . . . . . . . . . . . . 142.7 WebDav Authentication Bypass . . . . . . . . . . . . . . . . . . . . . 15

3 Vulnerability & Penetration Testing Tools 173.1 Nessus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2 Hping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3 Dsniff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.4 Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.5 Nmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.6 Zen-map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.7 Metasploit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.8 Nikto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.9 SQL-Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 Web Service Vulnerabilities 234.1 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2 SOAP message security . . . . . . . . . . . . . . . . . . . . . . . . . 244.3 Web Service Standards . . . . . . . . . . . . . . . . . . . . . . . . . . 25

1

CONTENTS 2

4.4 Message Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.5 Attacks on Web Services . . . . . . . . . . . . . . . . . . . . . . . . . 28

5 Application Developed & Simulation of an Attack 415.1 Writing a Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . 415.2 False Secure Web Application . . . . . . . . . . . . . . . . . . . . . . 425.3 Sniffing the packets . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6 Countermeasures Against The Attacks 456.1 XML Schema Validation . . . . . . . . . . . . . . . . . . . . . . . . . 456.2 Countermeasure for XML Encryption Attack . . . . . . . . . . . . . . 466.3 Countermeasure for XML Signature Wrapping Attacks . . . . . . . . . 466.4 Mitigating XML-Injection using Ontology Based Detection System . . . 49

7 Penetration Testing Tool for Web Services Security 517.1 Steps for using the Tool . . . . . . . . . . . . . . . . . . . . . . . . . 51

8 Conclusion 54

Bibliography 56

Certificate

This is to certify that the report, ”A Study of Web Service Security” is a bonafide workcarried out by Nagendra Chowdary P. in fulfillment of the completion of the SummerResearch Internship conducted by the Indian Academy of Sciences. It is certified thatall the corrections and suggestions indicated during the course of two months havebeen incorporated in the report. The project report has been approved as it satisfiesall the requirements.

Prof N. Balakrishnan

3

Acknowledgment

I express my sincere gratitude to the Indian Academy of Sciences for providing thisopportunity to work at IISc. I am deeply indebted to Prof. N. Balakrishnan, Professorand Associate Director of IISc, for his encouragement and support.

I would like to thank Mr. K P Raghuraman for guiding us throughout the courseof 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

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 andwriting 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 piecesof functionality. This led to the development of large libraries of code that are still inuse. The next major revolution in software design was object orientation. Real worldsoftwares were modeled on the lines of virtual objects where the object had propertieswhich defined its state and methods to change its state. Objects could be extendedas required. This resulted in easy maintenance and extendability. This paradigm wasextended to distributed object systems where objects residing on different machinesover the network could talk to each other using various remote access protocols. Withthis there was a huge demand of software services that could be plugged into theapplication 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 overWorld Wide Web. SOA is an architectural style based design whose primary goal isto achieve minimal dependency among interacting software agents. SOA provides aloosely coupled composition of services. A service is an atomic operation encapsu-lating a business process. Loose coupling means the way client communicates to theservice does not depend on the implementation of service. Web Services is the currentstandards of SOA. SOA has the following advantages:

• Platform Independence

• Location Transparency

• Code Reuse

5

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 andIntegration(UDDI). Service providers register their web services so that consumers caneasily 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 andthe 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. Aservice consumer can discover services by examining the registry. Message exchangeis one of the core services required for system integration in SOA environments. Thismessage exchange is usually performed via the SOAP protocol. Since messages maycarry vital business information, their integrity and confidentiality needs to be preservedand SOAP Message exchange in a meaningful and secured manner remains a challeng-ing part of systems integration. Since SOAP relies on XML information Set whichintroduces to the world XML based vulnerabilities. In order to ensure the integrity and

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 anattack, the possibility of an attack is vulnerability. It has been shown that there aremany attacks against XML based Web Service technology. Attacks like Denial of Ser-vice, Recursive payloads, Oversized payloads, WSDL Scanning and Tampering, XMLInjections, Exploitation of XML parsers & validators, XPath injection, SOAPActionspoofing, 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 contextof Web Services, a good understanding of these attacks will help in formulation anew framework against these attacks. In this current work we will demonstrate theseattacks and provide defensive solutions to these attacks also provide attack detectiontechniques and present existing tools which can detect these attacks. The rest of thechapters are organized as given below: Chapter-2 & 3 will present common vulnera-bilities and penetration testing tools. Chapter-4 will present common vulnerabilitiesin 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 webservices. We will conclude with Chapter-8.

1World Wide Web Consortium

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 webapplications can secured against the attacks. Also there are many security tools whichcan give the information about these vulnerabilities. Most information security toolsused their own databases with their own names for security vulnerabilities. At thattime there was no significant variation among products and no easy way to determinewhen the different databases were referring to the same problem. The consequenceswere potential gaps in security coverage and no effective interoperability among thedisparate databases and tools. In addition, each tool vendor used different metrics tostate the number of vulnerabilities or exposures they detected, which meant there wasno standardized basis for evaluation among the tools. To provide solutions to theseproblems and to standardize these vulnerabilities projects like CVE, CWE are startedby 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 worldwidecan make informed decisions about true software security risks.

Common Vulnerabilities and Exposures(CVE2) is a dictionary of commonnames (i.e., CVE Identifiers) for publicly known information security vulnerabilities.CVEs common identifiers make it easier to share data across separate network securitydatabases 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

1http://owasp.org2http://cve.mitre.org

8

CHAPTER 2. COMMON VULNERABILITIES 9

Identifiers, you may then quickly and accurately access fix information in one or moreseparate CVE-compatible databases to remediate the problem.

Common Weakness Enumeration(CWE3) International in scope and free forpublic use, CWE provides a unified, measurable set of software weaknesses that isenabling more effective discussion, description, selection, and use of software securitytools and services that can find these weaknesses in source code and operational sys-tems as well as better understanding and management of software weaknesses relatedto architecture and design.

Computer Emergency Response Team - India (CERT-In4) are expert groupsthat handle computer security incidents.

There are many definitions of vulnerability, but this one is well defined. Vulnerabilityis A flaw or weakness in system security procedures, design, implementation, or internalcontrols that could be exercised (accidentally triggered or intentionally exploited) andresult in a security breach or a violation of the systems security policy. - as definedby NIST5. The consequence of the vulnerabilities are, compromise of confidentiality,integrity and availability of resources. Identifying these vulnerabilities and disclosingthem 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 sameprivilege and environment as the application has. This attacks are most possible due tolack of correct input validation. This is a variant of the code injection attack the maindifference is that the attacker will execute his own code to extend the functionalityof 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 mostof the OS commands they execute different commands by appending semi-colon tothe 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 preventthese attacks like Command-Injection Scanner. A simple input validation by stripingsemi-colons, double quotes and fixed length inputs would prevent the attacks.

3http://cwe.mitre.org4http://cert-in.org5National Institute of Standards and Technology

OS command injection attack occurs when attacker executes system level com-mands through vulnerable application. For e.g: C code which does OS commandinjection as given below.

#include <s t d i o . h>#include 

i n t main ( i n t argc , char ∗∗ a r g v ) {char c a t [ ] = ” c a t ” ;char ∗command ;s i z e t commandLength ;

commandLength = s t r l e n ( c a t ) + s t r l e n ( a r g v [ 1 ] ) + 1 ;command = ( char ∗) m a l l o c ( commandLength ) ;s t r n c p y ( command , cat , commandLength ) ;s t r n c a t ( command , a r g v [ 1 ] , ( commandLength − s t r l e n ( c a t ) ) ) ;

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. Withthe ability to execute OS commands, the user can upload malicious programs or evenobtain passwords. OS command injection is preventable when security is emphasizedduring 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 Flashinto a vulnerable dynamic page to fool the user, executing the script on his machine inorder 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 asa hyperlink containing malicious content and which is distributed over any possible


means on the internet. There are many ways to achieve this attack using differenttypes of XSS. Types of XSS are DOM XSS, Stored XSS and Reflective XSS.

Stored Cross-site Scripting (XSS) occurs when a web application gathers inputfrom the users which might be malicious, and then stores that input in a data store forlater use. This attack occurs mainly because of no correct sanitization of input. Theattacker 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 typeof cross-site scripting is called as Stored XSS. There is one more cross-site scriptingthat is, Reflected XSS. In which the data that has been sent to the application or webdatabase is reflected back to the user, using this attack, the attacker can spoof asserver and can get the details of the victim.

Stored XSS allows the attacker to perform browser based attacks, few are listedbelow.

• 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 webapplication)

• 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 XSSexploit framework, Acunetix web vulnerability scanner.


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 filesystem operations. This could allow the attacker to access or modify the system levelfiles or other files which are critical to the application. It works on cross platformslike Windows, Linux and Mac. The common consequences of these attacks are loseof integrity, confidentiality and availability. Using automated static analysis we cananalyze 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 nameand will delete the temporary file that has been created. But if the attacker enter thefile name as ../../tomcat/conf/server.xml. Then it will delete the server.xml fileinstead. Other common vulnerabilities that are possible related to external control offiles as listed in CVE database are CVE-2008-5748 and CVE-2008-5764

S t r i n g rName = r e q u e s t . g e t P a r a m e t e r ( ” reportName ” ) ;F i l e r F i l e = new F i l e ( ”/ u s r / l o c a l / a p f r / 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.

6http://cwe.mitre.org


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 onbehalf of humans will degrade the Quality of Service of the system. But this methodhas got many vulnerabilities and now it is nowhere secure. These vulnerabilities aregrouped 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 thesecurity 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 theCAPTCHA 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 theimage 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 thefuture), 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


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 databasequery that looks like this:

SELECT i dFROM l o g i n sWHERE username = ’ $username ’AND password = ’ $ p a s s w o r d

/∗ Attack ∗/

SELECT i dFROM l o g i n sWHERE username = ’ Joe ’AND password = ’ a n y t h i n g ’ OR ’ x ’= ’ x ’

As the inputs of the web application are not properly sanitised, the use of the singlequotes 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 amalicious user to compromise the server. The more functionality provided to the enduser, the greater is the risk of having a vulnerable web application and the chancethat such functionality will be abused from malicious users, to gain access to a specificwebsite, or to compromise a server is very high. Few well known vulnerabilities that webapplications 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 theattacker can upload files without any restriction of file extensions and also canaccess the files if the uploads are done below the server root.

2. Mime type validation: Web developers often check only mime type for securingthe uploads but malicious user can use a script or automated process to generateHTTP.POST request and send with a valid mime type.

3. Using Blacklist Extensions: Using blacklist one can restrict the extensions butmalicious user can upload .htaccess file to modify the actions which helps himto attack.


4. Double extensions: Using invalid extension one can use the bypass the blacklistedextensions.

5. Checking image header: Checking image header for validating image files can bedone but one can write code in comments section using any image editors andcan 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 shouldhave 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, theInternet, 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 editingand managing documents and files stored on World Wide Web servers. It provides aframework for users to create, change and move documents on a server; typically aweb server or web share. This vulnerability allows remote attackers to bypass accessrestrictions on vulnerable installations of Internet Information Server 6.0. The specificflaw 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. Exploitationof 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.


Authentication bypass of password protected folders Assume there is a passwordprotected 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 namedprotected.zip. The attacker sends a HTTP GET request to the web server.

GET / \%c0\%a f / p r o t e c t e d / p r o t e c t e d . z i p HTTP/ 1 . 1T r a n s l a t e : fC o n n e c t i o n : c l o s eHost : s e r v e r name

As seen above the URI contains the Unicode character ’/’ (%c0%af). This unicodecharacter is removed in a WebDAV request. Translate: f instructs the web server tohandle the request using WebDAV. Using this malicious URI construct the webserversends the file located at /protected/protected.zip back to the attacker without askingfor proper authentication. Another valid request an attacker might send to the webserver is:

GET / p r o t\%c0\%a f e c t e d / p r o t e c t e d . z i p HTTP/ 1 . 1T r a n s l a t e : fC o n n e c t i o n : c l o s eHost : s e r v e r n a m e

IIS 6.0 will remove the %c0%af unicode character internally from the request and sendback the password protected file without asking for proper credentials. ASP scriptscannot 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 externalHTTP requests. This type of vulnerabilities are detected by making propfind requestswith the help of the nmap tool. We can test and exploit these vulnerabilities with themetasploit framework.

3 Vulnerability & PenetrationTesting 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 vulnerabilitydiscovery and credentialed scanning for system misconfigurations. It performscompromise detection on Viruses, malwares, backdoors, hosts, communicatingwith botnet infected systems, web services linking to malicious content. It checksfor Denial of services against TCP/IP stack and PCI DSS auditing. This toolperforms 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 attacksare 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

CHAPTER 3. VULNERABILITY & PENETRATION TESTING TOOLS 18

comparators in the world. It is free, powerful, multi-platform remote securityscanner. 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 likesystems.

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 testingusing 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 touse 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 butit gives more powerful than ping since it allows to construct customized packetswhich is very useful in performing various security checks. Unlike ping which isused to send only ICMP traffic, hping can be used to send any kind of packetnamely TCP, UDP etc.Typical Usage: hping3 -i p PORT No IP, Flags i & p used to set protocolsand 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)


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


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 andpenetration 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 networktraffic.

6. Strengths & Weakness: The major strengths of this tool are it allows usto explore security vulnerabilities of the packet switching networks, allows us tocounter the logistical problems of man in middle and can perform various spoofingtechniques. 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


3. Working Platforms: It works on multiple platforms like Windows, Mac OS X,Arch/Debian/RedHat Linux, Solaris, NetBSD, FreeBSD.


4. Testing Platforms: : It is a packet sniffer used to capture live data fromEthernet, IEEE 802.11, PPP/HDLC, ATM, Bluetooth, USB, Token Ring, FrameRelay, 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, Networkmapping. We can filter the packets based on the protocols. The limitations ofthis 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 wererectified.

3.5 Nmap

1. Current Version: 6.46 as nmap-6.46


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 anyplatform 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 andportable. Easy to use. The major limitations of this tool are fingerprinting is notaccurate and it is very easily detectable.


3.6 Zen-map

1. Current Version: 6.46 as Zenmap-6.46


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 anyplatform 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 GUIand 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 advancedfeatures.

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 addnew exploits to the framework, import vulnerability data from NESSUSNBE filesand nmap xml output. We can also perform injection into running processes,pivoting means use comprised host to attack host on internal network. The majorlimitations of this tool are majority of the exploits are available for windows,detailed logging is enabled by default we need to set up it.


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 webservers.

5. Security Checks: It examines a web server to find potential problems andsecurity 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 differentdatabase servers on any platform.

5. Security Checks:It is a penetration tool that automates the process of detectingand exploiting SQL injection flaws and taking over of database servers.

6. Strengths & Weakness: The strong points of this tool are, it is integratedwith other security tools like metasploit, w3af etc. It has many fingerprintingand enumeration capabilities. The major limitations of this tool is performancehog on server-side, which is undesirable on some situations.

4 Web Service Vulnerabilities

Web Services is the new paradigm in the Internet communication. Web Services haveintroduced a large number of new standards and technologies. It is found that WebServices are not very much resistant to security attacks. Web Services are exposed towell known attacks from common internet protocols and additional new attacks target-ing Web Services. In this chapter first we will define the terminology and techniquesrelated to Web Services and later we will present list of security issues in the domainof Web Services[15].

4.1 SOAP

Simple Object Access Protocol(SOAP) is a XML based messaging framework used toexchange encoded information (e.g. web service request and response) over a varietyof protocols (e.g. HTTP, SMTP, MIME). It allows a program running in one systemto call a program running in another system and it is independent of any programmingmodel. SOAP provides an easy way to design protocols for communication betweenapplications in an intranet or over the internet[18].

In order to call a web service with out knowing the programming model need tohave an interface with which end-point consumers can understand the web serviceand can use for their applications. SOAP uses XML framework to communicate themessages and this communication language with which the consumers can understandthe web service operations is called Web Service Description Language.

In short a Web Service is a software system identified by a Uniform ResourceIdentifier (URI), whose public interfaces and bindings are defined and described using

23

CHAPTER 4. WEB SERVICE VULNERABILITIES 24

Figure 4.1: Web Service Architecture

Extensible Markup Language (XML). These systems may then interact with the WebService in a manner prescribed by its definition, using XML based messages conveyedby Internet protocols. In particular, a service provider uses Web Service DescriptionLanguage (WSDL) to describe the functionality which a service offers and publish thedescription in Universal Description Discovery and Integration (UDDI). On the otherhand, a service requester discovers the service in UDDI and consumes it by sendingSimple Object Access Protocol (SOAP) messages. Above mentioned definition can bedrawn 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 theSOAP message and/or SOAP message attachment, which allows security informationto travel along with the message or attachment. Typical SOAP message structure andan 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


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 processingnodes 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 standardsof HTTPS, the communication in the transient, point-to-point and encryption canguarantee authentication and confidentiality only when data is in motion but not whiledata resides in the intermediate nodes. Web Service can provide such features but itis insufficient in several ways[18].

Message layer security

Message level security aka End-to-End security deals with and solves most issues of atransport level security scheme regarding its insufficiency, starting with maintaining asecurity context (Figure-4.4) which is valid End-to-End. The identity, integrity, andsecurity of the message and the caller need to be preserved over multiple hops andmore than one encryption key may be used along the route with trust domains beingcrossed.

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) andTransport Layer Security (TLS) can be used to secure SOAP message in Web Serviceenvironment. These mechanisms create a security tunnel for communication between


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 isin transit. However, these security mechanisms are not suitable with SOAPs message-based architecture, where intermediaries cannot see the contents of the tunnel, and socannot 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 securitystandard that can be used to achieve end-to-end security in Web Services called WebServices 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 followan 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 WSstandards.

WS-Security describes how to attach signature and encryption headers to SOAPmessages as well as how to attach security tokens, including binary security tokens such


Figure 4.5: Simple Web Service Security Architecture

as X.509 certificates and Kerberos tickets. WSSecurity provides a framework to securea SOAP message using existing techniques (e.g. encryption, signature). WS-Policyand WS-SecurePolicy[19] describe the capabilities and constraints of the security (andother 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 andauthenticate message exchanges between parties including security context exchangeand establishing and deriving session keys. WSSecurity defines a SOAP header blockthe so-called security header that carries the WS-Security extensions. Additionally, itdefines how existing XML security standards like XML Signature and XML Encryptionare applied to SOAP messages.

XML Signature allows XML fragments to be digitally signed to ensure integrity or toproof authenticity. The result of the signing operationi.e. the encrypted digestis placedin a Signature element, which again is added to the security header. XML Encryptionallows XML fragments to be encrypted to ensure data confidentiality. The encryptedfragment is replaced by an EncryptedData element containing the ciphertext of theencrypted fragment as content. More detailed explanation is given in XML Encryptionand Signature attacks.


Figure 4.6: Message Flow

4.4 Message Flow

On the sender side or Web Service Requester in Figure-4.6, at first the Requesterwill acquire the required security token from the Security Token Service and then theprotocol stack generates SOAP envelopes that satisfy its policy. It adds integrity andconfidentiality credentials under the ¡Security¿ header that is defined in WSSecurity.The header block allows attaching securityrelated information targeted at a specificrecipient in the form of a SOAP actor/role. This may be either the ultimate recipientof the message or an intermediary. Consequently, elements of this type may be presentmultiple times in a SOAP message. An active intermediary on the message path mayadd one or more new sub-elements to an existing header block if they are targeted for itsSOAP 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 validand passed to the application if its policy is satisfied for this envelope. Normally, thesender 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].

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 resourcesof 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 largerequest message. This is called Oversized Payload attack. For e.g. following samplequery request message gives an idea of how the attacker can frame a large requestmessage.

<Enve lope><Body>

<g e t A r r a y L e n g t h>x</item>x</item>x</item>. . .

</g e t A r r a y L e n g t h></Body></Enve lope>

Web Service frameworks implement a tree-based XML processing model like the Doc-ument Order Model. Using this model, an XML documentlike a SOAP messageiscompletely 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 thetotal buffer size (in bytes) for incoming SOAP messages. In this case, it is sufficientto check the actual message size and reject any message exceeding the predefinedlimit While this countermeasure is very simple to implement, it is not suitable for WebService messages. A more appropriate approach uses restrictions on the XML infoset.This can be realized by modifying the XML schema inside the Web Service descriptionand validating incoming SOAP message to this schema.

Recursive Parsing

One of the first steps in processing a Web Service request is parsing the SOAP messageand transforming the content to make it accessible for the application behind the WebService. Thus, the XML parsing process allows other possibilities for a special kindof Denial-of-Service attacks, which is called Recursive Parsing attacks. An exampleattack is given below.

<Enve lope><Body>

<x><x>

<x>. . .

The attack resulted in a CPU usage of 100% on the target system and the servicesavailability was massively reduced. These attacks target on resource exhaustion. Anattack that is based on complex or deeply nested XML documents (like the one in theexample above) can be fended by using schema validation.

SOAPAction Spoofing

The actual Web Service operation addressed by a SOAP request is identified by thefirst child element of the SOAP body element. Additionally, the optional HTTP headerfield SOAPAction can be used for operation identification. Although this value onlyrepresents a hint to the actual operation, the SOAPAction field value is often used asthe only qualifier for the requested operation. This is based on the bogus optimizationthat evaluating the HTTP header does not require any XML processing. For e.g. aservice provided two operations: op1(string s) and op2(int x) with the respectiveSOAPAction and message element also named opn. The following message (includingthe HTTP header) was sent to the service:

POST / S e r v i c e . asmx HTTP/ 1 . 1. . .SOAPAction : ” op2 ”<Enve lope><Body>

<op1><s>H e l l o </s>

</op1></Body></Enve lope>

Clearly in the above example from the SOAPAction field we can see that the messageis to invoke op2(0), but instead it invoke op1(Hello). As the HTTP header is notsecured by WS-Security and is newly created at every SOAP intermediary, it can easilybe modified. The second class of SOAPAction spoofing attacks is executed by the WebService client and tries to bypass an HTTP gateway. For e.g. a service provided twooperations: hidden and visiblewith the respective SOAPAction and message elementequally named. The following message (including the HTTP header) was sent to theservice:

POST / a x i s 2 / t e s t S e r v i c e HTTP/ 1 . 1

. . .SOAPAction : ” v i s i b l e ”<Enve lope><Body>

<h i d d e n /></Body></Enve lope>

The Axis2 server actually ignored the SOAPAction value and invoked the hidden op-eration instead. A countermeasure to SOAPAction Spoofing attacks would be todetermine 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 anydifference 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 (orany other XML document) by inserting content e.g. operation parameters containingXML tags. Such attacks are possible if the special characters ¡ and ¿ are not escapedappropriately. At the Web Service server side, this content is regarded as part of theSOAP message structure and can lead to undesired effects. For e.g. service methodhas two parameters a and b, both of type xsd:int. This service was invoked using thefollowing SOAP message

<Enve lope><Body>

<Hel loWor ld><a> 1 </a> 2 

</Hel loWor ld></Body></Enve lope>

From the message it is clear that the resulting parameter values inside the serviceapplication has been modified and the attacker was able to modify the value of bjust by modifying the content of a. It is easy to imagine a scenario in which thiscan lead to unintended service behavior, e.g. access to restricted data. An importantstep 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 fromthe example attack.


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 localnetwork only (here called internal operations), while other operations are intended tobe 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 gainsknowledge of the internal operations and can invoke them.

The first step in avoiding such accesses is providing a separate WSDL to externalclients that contains the external operations only. However, as the Web Service end-point is still externally accessible (for invoking the external operations), an attackercan try to guess the omitted operations and call them. This attack is called WSDLScanning.

One countermeasure to this attack is deploying the internal and external operationsto separate Web Services, preferable even on different servers. If this is not applicable,invocations of internal operations must be controlled and rejected if originated froman 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 metadatadocuments provided by the Web Service server. Currently, this metadata usually isdistributed using communication protocols like HTTP or mail. These circumstancesopen new attack possibilities aiming at spoofing these metadata. The most relevantattacks in this category are WSDL Spoofing and Security Policy Spoofing.

Supposably most promising for WSDL Spoofing is the modification of the networkendpoints and the references to security policies. A modified endpoint enables theattacker 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 requirementsis used, such attacks are possible despite the use of WS-Security.

To avoid Metadata Spoofing, all metadata documents must be carefully checkedfor authenticity. However, the mechanisms for securing metadata documents are notstandardizedin contrast to methods for securing SOAP messages. Additionally, a priorestablishment of trust relationships is required, which is not always possible or intended.


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, andthe flexible layout of the security header allows no strict schema validation. The variouspossibilities for using security elements limits a schema validation to check each singleelement, 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 systemprocesses or buffers the whole security header, the target system may be effected thesame way as from an Oversize Payload attack

A more complex attack with an oversized security header uses chained encryptedkeys. In this chain, each encrypted key is used to encrypt the next key (see figure1). Thus, the target system is forced to decrypt every encrypted key, as each keyis needed for decryption of the next one. This may effect the target system in twoways. First, the target system must buffer every key, as it is unknown before the endof message processing, whether an encrypted key is used for other encrypted content.This leads to high memory consumption. Second, the decryption operations needsprocessing resources. Especially asymmetric algorithms, which are typically used forkey transport, are highly CPU consuming.As a countermeasure, the usage of WS-Security elements must be restricted, andmessages exceeding these limits must be rejected.

WS-Addressing Spoofing

The use of WS-Addressing for asynchronous Web Service calls raises a lot of attackpossibilities, 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 ascallback endpoint reference. As a result, the engine will perform the execution of theprocess involved, then try to callback the initiator. This will result either in a directerror (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 raisean execution fault and call matching fault handlers and compensation handlers. Allin 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 usualflooding attacks presented above, the workload produced by each attack message ismaximized, asin most processesthe fault will be thrown within the last communicationactivity of the process. Figure-


The core countermeasure against any kind of WS-Addressing spoofing is verificationof the callers endpoint URL, ideally at the beginning of a process execution. This wouldenable early message rejection, preventing the engine from unnecessary workload.

XPath Injection

XML documents are often treated as data stores and queried by web services thatconsume 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 injectionattacks which can lead to arbitrary execution of queries on the server. XPath queriesthat are dynamically combined with user input may be modified by the user in a waydeveloper 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. Itis 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-ciphertextattack. This attack can be applied in all scenarios, where the attacker is able tosend messages including modified ciphertext to an oracle that decrypts the messageand responds with1 or 0 according to the message validity. According to the serverresponses, the attacker can decrypt the whole ciphertext. The attack is based on afact that the server parses the decrypted XML data. If the parsing fails, the serverinterrupts the message processing[12].

XML Encryption XML documents often contain data whose confidentiality, au-thenticity, and integrity must be protected. Therefore, the W3C consortium developedstandards describing the XML syntax for applying cryptographic primitives to XMLdata: XML Encryption. XML Encryption specifies a method for achieving confiden-tiality of the stored XML elements. First, the encryptor chooses a session key k. Thiskey is encrypted using a public-key encryption scheme. Afterwards, the payload datais encrypted with a symmetric cipher. For this purpose the standard allowed to choosebetween two symmetric ciphers, namely AES-CBC and 3DES-CBC.

Figure-4.7 shows an example SOAP message structure with XML Encryption. Thismessage consists of the following parts related to our next attack description:

1. The EncryptedKey part. This part consists of two components. The CipherDataelement contains the encrypted session key k. ReferenceList contains refer-


Figure 4.7: XML Encrypted SOAP Message Structure

ences to all EncryptedData elements that can be decrypted with the sessionkey k.

2. The EncryptedData part. This part contains the initialization vector iv in aclear followed by the payload data, encrypted using the session key k.

Multiple EncryptedData elements sharing the same session key are listed in theReferenceList. A SOAP Web Service receiving such an XML document processes itas follows. It first decrypts the session key k. Then, it uses k to decrypt all the partscontaining encrypted payload. Finally, the payload data is parsed with an XML parserand 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, andnot 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-keyencryption algorithms. They allow to encrypt and decrypt data, whose length is 16 or8 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 modeof operation.

Cipher block chaining(CBC) is the most popular blockcipher mode of operation inpractice. Its functionality in the XML Encryption specification including the paddingscheme is depicted in Figure-4.8. For its description, suppose a byte string data′ ofarbitrary length. The data′ string is first padded in order to achieve a length l, whichis an integer multiple of the block-size bs. XML Encryption specifies the followingpadding scheme:


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 multipleof bs of the block cipher.

2. Append(p1)random bytes to data′ 3) Append one more byte to data′, whoseinteger value equals p.

Using this padding scheme we get data, whose length is multiple ofbs. Now, wecan split data into blocks: data= (data(1), ..., data(d)). These blocks are processed asshown in the Figure-4.8.

XML-Encryption Attack Description The attack on XML Encryption is basedon the malleability of the CBC mode of operation: It allows an attacker, who isin possession of the ciphertext C = (iv, C(1)),to flip arbitrary bits in the plaintextm = Dec(C, k) without knowing the session key k. He can simply achieve this byflipping appropriate bits in the initialization vector iv.

Changing different bits in the encrypted XML data can lead to errors in the serverprocessing, which forces the server to respond with a fault message. These faultmessages can have the following reasons:

• Decryption errors: This error stems from an incorrect padding. Recall that thelast byte of a padded plaintext must include a valid padding number p(in caseof AES p ∈ 0x01...0x10).

• Parsing errors: This error may have two reasons. Either the plaintext containsan 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 character0x38(&) is not followed by a valid entity reference, or an element starting withthe 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 dataincluding 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 roundi = 1...d, he takes two ciphertext blocks c = (C(i1), C(i)) = (iv, C(i)) and with thesetwo blocks he proceeds as follows:

1. He excludes all the left brackets from the plaintext in order to overcome theparsing errors originating from improperly closed elements. To this end, heiterates 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 positionof 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 excludesall the brackets.

2. He sets the last iv byte so that the last plaintext byte contains 0x01. This giveshim 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, heuses 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 authenticationfor a variety of document types. One important property of XML Signature is thatsigned XML elements along with the associated signature may be copied from onedocument into another while retaining the ability to verify the signature. This can beuseful in scenarios where multiple actors process and potentially transform a documentthroughout a business process. However, this same property can be exploited by anadversary allowing the undetected modification of documents[13].

XML Signature: XML Signature defines an XML syntax and processing rules forsigning and verifying digital signatures over one or more data objects. It sets indirectreference to these signed objects, for each signed object a ds:Reference element is setwhich points to the signed object via URI, contains a digest value computed over theobject. The complete set of information is grouped under ds:SignedInfo element. Thevalue is ds:SignatureValue is computed over the ds:SignedInfo element. For examplea simple SOAP message is given below.

001 <soap : E n v e l o p e . . . >002 <soap : Body>003 <getQuote Symbol= I B M />004 </soap : Body>005 </soap : Enve lope>

The above example is a SOAP request to a stock quote application reauesting togetQuote of IBM. The message is residing in soap:Body element which is a child ofsoap:Envelope. The application would charge for this service and thereby it need tocheck the authentication and integrity. In this case the service provider will have apolicy 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 certificateissued by one of a set of trusted Certificate Authorities (CAs).

The signed element is given below.

001 <soap : E n v e l o p e . . . >002 <soap : Header>003 <wsse : S e c u r i t y >004 <wsse : B i n a r y S e c u r i t y T o k e n005 ValueType =”...# X509v3 ”006 EncodingType =”...# B a s e 6 4 B i n a r y ”007 wsu : I d=”X509Token”>008 MIabcdefg0123456789 . . .009 </wsse : B i n a r y S e c u r i t y T o k e n>010 <ds : S i g n a t u r e>011 <ds : S i g n e d I n f o>012 <ds : C a n o n i c a l i z a t i o n M e t h o d013 A l g o r i t h m = ” . . . / xml−exc−c14n#”/>014 <ds : S ignatureMethod015 A l g o r i t h m =”...# r s a−sha1”/>016 <ds : R e f e r e n c e URI=”#theBody”>017 <ds : Transforms>

018 <ds : Transform019 A l g o r i t h m = ” . . . / xml−exc−c14n#”/>020 </ds : Transforms>021 <ds : DigestMethod022 A l g o r i t h m = ” . . . / x m l d s i g#sha1”/>023 <ds : D i g e s t V a l u e>024 AbCdEfG0123456789 . . .025 </ds : D i g e s t V a l u e>026 </ds : R e f e r e n c e>027 </ds : S i g n e d I n f o>028 <ds : S i g n a t u r e V a l u e>029 AbCdEfG0123456789 . . .030 </ds : S i g n a t u r e V a l u e>031 <ds : Key In fo>032 <wsse : S e c u r i t y T o k e n R e f e r e n c e>033 <wsse : R e f e r e n c e URI=”#X509Token”/>034 </wsse : S e c u r i t y T o k e n R e f e r e n c e>035 </ds : Key In fo>036 </ds : S i g n a t u r e>037 </wsse : S e c u r i t y >038 </soap : Header>039 <soap : Body wsu : I d=”theBody”>040 <getQuote Symbol= I B M />041 </soap : Body>042 </soap : Enve lope>

Lines 003-037 contain a wsse:Security element which isa child of the soap:Headerelement. 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 XPointerFramework. The shorthand pointer identifies the soap:Body element by the value ofits wsu:Id attribute. The receiver’s end will check the referenced element in the listds:Reference and verifies the signature by computing it on the element and checks withthe digest value given. But the adversary can use the vulnerable property that signedelement can be moved to any part of the document. The attacker simply copies thesigned element to a wrapper element and moves it to the soap:Header so that theverification is done on the original signed element as it is pointed by its id. In thesoap:Body he can use his own element and get it executed. Example attack is givenbelow.

001 <soap : E n v e l o p e . . . >002 <soap : Header>

003 <wsse : S e c u r i t y >004 . . .005 <ds : S i g n a t u r e>006 <ds : S i g n e d I n f o>007 . . .008 <ds : R e f e r e n c e URI=”#theBody”>009 . . .010 </ds : R e f e r e n c e>011 </ds : S i g n e d I n f o>012 . . .013 </ds : S i g n a t u r e>014 </wsse : S e c u r i t y >015 <Wrapper016 soap : mustUnderstand= 0017 soap : r o l e= . . . / n o n e >018 <soap : Body wsu : I d=”theBody”>019 <getQuote Symbol= I B M />020 </soap : Body>021 </Wrapper>022 </soap : Header>023 <soap : Body wsu : I d=” n e w B o d y >024 <getQuote Symbol= M B I />025 </soap : Body>026 </soap : Enve lope>

From the above we can see that lines 015 to 021 has the wrapper element which ispointed by the reference list to verify which safely validates the original signed elementbut executes the attackers request.

5 Application Developed &Simulation of an Attack

In this chapter we will shown a demonstration of an attack using a sniffer. For this weneed 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 servicesto the clients. Once we have the logic we can code it in any language. After thatwe can convert these languages into web service and corresponding methods into webservice methods using Service Endpoint Interface(SEI) of that language. For e.g. Ifyou want to write a web service in python then it has SEI modules like SOAPlib forserver side and suds for client side. Not only for python but every other languageshas SEI modules which help in converting normal methods into web methods. Thefollowing code gives an idea of how a method is converted in web method using thesignature of web methods.

@soap ( S t r i n g , I n t e g e r , r e t u r n s=I n t e g e r )def getQuote ( s e l f , name , q u a n t i t y ) :

d = d i c t ( s e l f . p r o d u c t s )c o s t = d [ name ]return c o s t ∗ q u a n t i t y

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

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 webservice. Users/clients who want to use this service can access the operations of the webservice 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 m a k e s e r v e rs o a p a p p l i c a t i o n = s o a p l i b . c o r e . A p p l i c a t i o n ( [ ProductMart ]

, ’ t n s ’ )w s g i a p p l i c a t i o n = w s g i . 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 = m a k e s e r v e r ( ’ 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. Thestructure of this application is shown in Figure-5.1. In this application the client willhave a lost of products and he/she can purchase products using this application byentering their details in the form. This application will connect to the web servicerunning on on a machine with specified URL of WSDL. Connecting to the web servicewe 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 theclient and the response by the server for the client’s request. Figure-5.4 & 5.5 showsthe packets of requests and responses. One can tamper the requests and send it tothe server using the Burpsuit tool.


Figure 5.1: False Secure Web Application Structure

Figure 5.2: Snapshot of Web Application


Figure 5.3: Attack Structure

Figure 5.4: SOAP Request message

Figure 5.5: SOAP Response message

6 Countermeasures AgainstThe Attacks

In this chapter we will see countermeasure of the attacks which are proposed in theliterature. From the list of vulnerabilities and possible potential attacks we can clearlysee that most of the attacks are due to invalid schema & input validation and vulnerableCBC-mode encryption. The following proposed countermeasures will address most ofthe 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 ofDenial-of-Service attacks as well as discovering invalid messages in very early stages.Nevertheless, current Web Service frameworks by default do not perform a schemavalidation step. This is mainly because of the performance implications. Another issuein this context is the often low strictness of most schemas, which reduces the effect ofschema validation. As this schema is controlled by the service itself, it can be easilytightened by the service developer and is automatically announced to the service clientby the Web Service description[9].Additionally, the schema for the SOAP header (which by default can include anyelement) 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 headerblocks can be prevented. The claimed XML schema type for the wsu:Id attributes isxsd: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

CHAPTER 6. COUNTERMEASURES AGAINST THE ATTACKS 46

tection. The receivers security component will validate the policy and then processesthe business logic. If the messages is modified the policy will be invalidated and hencethe attack is detected. A strict policy by making a pointer to the absolute XPathexpressions for all signed elements P (a signature assertion) and a list of IDs of signedelements I. For every p ∈ P : get the ID i of the element matching p and check ifi ∈ I . If this check is successfull, the certificate used for signature verification canbe used for access control purposes. The security policy validation checks that allassertions are fullfilled. Additionally, as the schema validation ensures the uniquenessof IDs, the mapping from signed elements to policy assertions is safe. And finally, asthe signed elements which are evaluated by the business logic part are uniquely definedby the schema, the business logic will process exactly those elements, checked by thesignature verifier.

6.2 Countermeasure for XML Encryption Attack

One option is to use a symmetric cryptographic primitive that does not only provideconfidentiality, but also integrity. One option may be to add a message authenticationcode(MAC) like HMAC (see ) over the ciphertext to the encrypted message. Theencrypted part must always be completely processed and parsed and the MAC must bevalidated afterwards. In contrast to a digital signature, which can simply be replacedby a different signature, the security properties of a MAC ensure that it is not possiblefor an attacker to modify a ciphertext while keeping the MAC valid. In this case, ourattack becomes impossible. Another option, which provides the same improvement insecurity, would be to replace the CBC mode of operation with a mode of operationthat provides message integrity, like the Galois counter mode (GCM), for instance[18].

Some other non-cryptic counter measures are suggested by [6] like blacklistingclient’s public keys and IPs that already sent a few number of invalid messages causingsecurity faults. Moreover, this countermeasure does not work if the attacker is able toexecute his attack from machines with different IP addresses. This is a valid assumptionwhen considering allocation of virtual instances in cloud scenarios.

6.3 Countermeasure for XML Signature WrappingAttacks

The attacks on XML signature has been first demonstrated by McIntosh in 2005, fromthen many countermeasure have been developed. The list of counter measures are:

1. WS-Policy


2. WS-Account

3. WS-UnWrap [7]

In this first two approaches the authors proposed an inline approach that takes intoaccount information about the structure of the SOAP message by adding a new headerelement called SOAP Account,and also extended the inline approach by proposing totake into account new characteristics of SOAP message such as the depth informationand parent elements of the signed node as well as a way to uniquely identify the parentelements. 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 takecare of some other types.

While in the third approach, they first build SOAP message elements structureusing ontology and then attach it in outgoing SOAP message header. Ontology letsus build hierarchies and thesauri that can be used for expressing how elements withinSOAP 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 structureis shown in Figure-6.1Furthermore, 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 messagesare written to a log before they are applied. So if security failures are occurred, theycould check this log and recover from effects of successful execution.

In the UnWrap approach, the SOAP message is passes through three modules whichare responsible for the detection and recovery of the attacks. First the message goes tothe Initialization Module, which observes the SOAP outgoing message structure andattaches the ontology to it and logs the process. Then at receiver’s end DiagnosisModule starts diagnosing incoming SOAP message and generates a security reportwith details of the attacks included and sends to the next module. The next module isRecovery Module which is used to recover the message from the attack by connectingto the log at senders end. Then policy validation and followed by security tokenvalidation completes the process. Figure-6.2 shows the complete procedure.


Figure 6.1: Ontology information of SOAP message

Figure 6.2: UNWRAP Approach Structure


6.4 Mitigating XML-Injection using OntologyBased Detection System

Detecting malicious activities has become a great challenge with the increase of webapplications and web services all around the internet. There are two classic strategiesof detecting attacks.

1. Signature Based Detection

2. Knowledge Based Detection

Signature Based Detection A signature is a payload that identifies an attackthrough some specific malicious context. Signature based detection systems usuallylead to low software detection mistake ratesnamely, false-positive rates. However, oneimportant limitation of signature-based attack detection is that it doesnt detect newunknown attacks, even if they have only small variations from a known payload.

Knowledge Based Detection This detection system detects attacks based onthe previous knowledge of attacks. Two distinct classes are modeled like one for normalbehavior, containing all expected actions that define such a profile, and another forattacks containing actions that arent considered normal. Knowledge-based detectiontechniques 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-dayattacks. In [4] authors have developed an ontology based detection system whichmitigates XML-Injection attacks. In their model they modeled attack elements asstrategies representing them by classes and relationships in an ontology. With thismodel by defining a semantic relationship among attack elements, attack variationscan be easily detected and automatically added to the ontologys database. Figure-6.3shows an example of XML-Injection attack ontology.

From the figure we can see that any attack instance having at least one AttackActionof the type Discovery, one AttackAction of the type ProbeXPath, and one AttackActionof the type InjectXQuery will be an instance of the class XQueryInjection. ForXML Injection Detection(XID), this means that an XQueryInjection attack was de-tected. The detection algorithm is given in Figure-6.4.


Figure 6.3: XML Injection Ontology Structure

Figure 6.4: XML Injection Detection Strategy

7 Penetration Testing Tool forWeb Services Security

In general penetration testing tools will help in understanding the possible attacks onthe system prior to the public release. Compared to the attacks like SQL injection andCross Site Scripting(XSS)which can be checked with a number of penetration testingtools, but there are no tools which offers a testing of XML specific vulnerabilities. Forthis reason Mr. Jorg Schwenk et al [10] developed a tool called WS Attacker1 whichautomates the process of checking the web services against all the attacks as listed inChapter-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, theuser selects the operation which will be attacked.

3. The framework must be able to generate a valid request stub for the selectedoperation and provide input fields for message parameters.

4. The user submits a test request. The response to this request represents thenormal 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.

1http://sourceforge.net/projects/ws-attacker/

51

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 specificrequests and sends to the web service based on the response the plugin should be ableto 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 inbelow.

publ ic abstract c l a s s A b s t r a c t P l u g i n {// a t t a c k i d e n t i t ypubl ic S t r i n g getName ( ) , g e t A u t h o r ( ), g e t V e r s i o n ( ) , g e t D e s c r i p t i o n ( ), g e t C a t e g o r y ( ) ;// s u c c e s s i n t e r f a c epubl ic boolean w a s S u c c e s s f u l ( ) ;publ ic i n t g e t C u r r e n t P o i n t s ( ) ;publ ic i n t getMaxPoints ( ) ;// r e s u l t l o gf i n a l void r e s u l t ( l e v e l , c o n t e n t ) ;/ / g e t t h e p l u g i n o p t i o n spubl ic O p t i o n C o n t a i n e r g e t P l u g i n O p t i o n s ( ) ;// main p a r tpubl ic void s t a r t A t t a c k ( t e s t R e q u e s t

CHAPTER 7. PENETRATION TESTING TOOL FOR WEB SERVICES SECURITY53

, t e s t R e s p o n s e ) ;}

The three important modules that need to be in the attack plugins.

• Attack identity contains methods to describe a plugin. This includes an attackname, an author, a version and a description. In addition, a plugin categorymust be set, so that the GUI can sort conjugated attacks, e.g Spoofing Attacksor DoS Attacks.

• Success interface implements the idea of showing the impact and difficulty ofattack. It rating shows two things like, the first one is just an indicator for thedetection of a vulnerability in general, so the result will be True or False. Thesecond one rates the potential risk of an attack. As an example, a Denial ofService attack might stop a server for several minutes or even completely so thata 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.

8 Conclusion

In this project we studied about common vulnerabilities and various penetration testingtools of the common vulnerabilities. Then we studied about Web Service technology inthe context of Service Oriented Architecture(SOA). The popular communication proto-col that web services use is SOAP, which relies on XML information set to communicatethe messages. This introduces us to XML based attacks. With the introduction ofXML based tree structure in SOAP messages which are vulnerable to attacks like XMLSignature Wrapping attacks. Using CBC mode block cipher which is vulnerable to or-acle padding attacks brings serious threats to XML-Encryption standards(as discussedin Chapter-4). With weak schema validations in the WS-Policy has introduced at-tacks like WS-Address Spoofing, SOAPAction spoofing, Injection attacks and manyvariants of Denial of Service(DoS) attacks. There are many other attacks (as listedin Chapter-4) that are based on the weak security policies that are implemented inWS-Security. Attacks like Denial of Service (DoS), Injection attacks are not new butthey are not well understood in the context of Web Services. With very small securityalternatives and not well understood about the security policies may introduce seriousflaws in the implementation of Web Services, which effects the confidentiality, integrityand 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 tighteningthe schema based on the service. Using other black-cipher modes and ontology basedXML Signature standards (as discussed in Chapter-5). Detecting new attacks that arenot known before is also an important policy that one can adopt in the WS-policy. Asdiscussed in Chapter-5 XML Injection attacks are detected using Ontology of attackclasses which are used to characterize new incoming attacks. Also we can test thesystem 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

CHAPTER 8. CONCLUSION 55

Future Work: The ontology based detection system can be extended furtherto other web service specific attacks and we can use them to design the penetrationtesting tools. XML Encryption attacks needed a new encryption model other than theswitching of mode as a countermeasure against the attack.

Bibliography

[1] Mr. Zhou Jing The Analysis of XML Technology in Network Security published in2010 International Symposium on Intelligence Information Processing and TrustedComputing.

[2] Suriadi Suriadi, Andrew Clark, and Desmond Schmidt, Validating Denial of ServiceVulnerabilities in Web Services published in 2010 Fourth International Conferenceon Network and System Security.

[3] Narges Shahgholi et al, A new security framework against Web services XMLattacks in SOA published in 2011 7th International Conference on Next GenerationWeb 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 andReliability 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 againstAttack 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 SecurityValidation Revisited published in 2009 IEEE International Conference on WebServices.

56

BIBLIOGRAPHY 57

[9] Mohammad Ashiqur Rahaman, Andreas Schaad, SOAP-based Secure Conversa-tion and Collaboration published in 2007 IEEE International Conference on WebServices.

[10] Christian Mainka, Juraj Somorovsky, Jorg Schwenk, Penetration Testing Tool forWeb 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 InternationalConference 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 Attacksin Web Services published in International Journal of Control and Automation.

[15] Meiko Jensen, Nils Gruschka and Ralph Herkenhoner, A Survey of Attacks onWeb 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)

engs4851_final_certified_report

Documents