Download to read offline
![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](https://image.slidesharecdn.com/62aa6744-c08d-40ff-8012-991dca6ba869-160907040646/85/ENGS4851_Final_Certified_Report-12-320.jpg)
![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](https://image.slidesharecdn.com/62aa6744-c08d-40ff-8012-991dca6ba869-160907040646/85/ENGS4851_Final_Certified_Report-25-320.jpg)
![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](https://image.slidesharecdn.com/62aa6744-c08d-40ff-8012-991dca6ba869-160907040646/85/ENGS4851_Final_Certified_Report-27-320.jpg)
![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.](https://image.slidesharecdn.com/62aa6744-c08d-40ff-8012-991dca6ba869-160907040646/85/ENGS4851_Final_Certified_Report-29-320.jpg)
![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].](https://image.slidesharecdn.com/62aa6744-c08d-40ff-8012-991dca6ba869-160907040646/85/ENGS4851_Final_Certified_Report-30-320.jpg)
![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-](https://image.slidesharecdn.com/62aa6744-c08d-40ff-8012-991dca6ba869-160907040646/85/ENGS4851_Final_Certified_Report-36-320.jpg)
![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].](https://image.slidesharecdn.com/62aa6744-c08d-40ff-8012-991dca6ba869-160907040646/85/ENGS4851_Final_Certified_Report-39-320.jpg)
![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](https://image.slidesharecdn.com/62aa6744-c08d-40ff-8012-991dca6ba869-160907040646/85/ENGS4851_Final_Certified_Report-43-320.jpg)
![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.](https://image.slidesharecdn.com/62aa6744-c08d-40ff-8012-991dca6ba869-160907040646/85/ENGS4851_Final_Certified_Report-44-320.jpg)
![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](https://image.slidesharecdn.com/62aa6744-c08d-40ff-8012-991dca6ba869-160907040646/85/ENGS4851_Final_Certified_Report-47-320.jpg)
![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](https://image.slidesharecdn.com/62aa6744-c08d-40ff-8012-991dca6ba869-160907040646/85/ENGS4851_Final_Certified_Report-48-320.jpg)
![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.](https://image.slidesharecdn.com/62aa6744-c08d-40ff-8012-991dca6ba869-160907040646/85/ENGS4851_Final_Certified_Report-49-320.jpg)
![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.](https://image.slidesharecdn.com/62aa6744-c08d-40ff-8012-991dca6ba869-160907040646/85/ENGS4851_Final_Certified_Report-51-320.jpg)
![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](https://image.slidesharecdn.com/62aa6744-c08d-40ff-8012-991dca6ba869-160907040646/85/ENGS4851_Final_Certified_Report-53-320.jpg)
![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](https://image.slidesharecdn.com/62aa6744-c08d-40ff-8012-991dca6ba869-160907040646/85/ENGS4851_Final_Certified_Report-58-320.jpg)
![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)](https://image.slidesharecdn.com/62aa6744-c08d-40ff-8012-991dca6ba869-160907040646/85/ENGS4851_Final_Certified_Report-59-320.jpg)
ENGS4851_Final_Certified_Report
- 1. A Study ofWeb 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.
- 3. Contents Contents 1 1 Introduction5 2 Common Vulnerabilities 8 2.1 Command Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2 Stored XSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3 External Control of File (CWE-73) . . . . . . . . . . . . . . . . . . . 12 2.4 Weak CAPTCHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.5 SQL Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.6 Malicious File Upload . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.7 WebDav Authentication Bypass . . . . . . . . . . . . . . . . . . . . . 15 3 Vulnerability & Penetration Testing Tools 17 3.1 Nessus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2 Hping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.3 Dsniff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.4 Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.5 Nmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.6 Zen-map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.7 Metasploit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.8 Nikto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.9 SQL-Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4 Web Service Vulnerabilities 23 4.1 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.2 SOAP message security . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.3 Web Service Standards . . . . . . . . . . . . . . . . . . . . . . . . . . 25 1
- 4. CONTENTS 2 4.4 MessageFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.5 Attacks on Web Services . . . . . . . . . . . . . . . . . . . . . . . . . 28 5 Application Developed & Simulation of an Attack 41 5.1 Writing a Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.2 False Secure Web Application . . . . . . . . . . . . . . . . . . . . . . 42 5.3 Sniffing the packets . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 6 Countermeasures Against The Attacks 45 6.1 XML Schema Validation . . . . . . . . . . . . . . . . . . . . . . . . . 45 6.2 Countermeasure for XML Encryption Attack . . . . . . . . . . . . . . 46 6.3 Countermeasure for XML Signature Wrapping Attacks . . . . . . . . . 46 6.4 Mitigating XML-Injection using Ontology Based Detection System . . . 49 7 Penetration Testing Tool for Web Services Security 51 7.1 Steps for using the Tool . . . . . . . . . . . . . . . . . . . . . . . . . 51 8 Conclusion 54 Bibliography 56
- 5. Certificate This is tocertify 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 mysincere 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 asoftware 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. INTRODUCTION6 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. INTRODUCTION7 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 Inthis 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. COMMONVULNERABILITIES 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. COMMONVULNERABILITIES 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. COMMONVULNERABILITIES 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. COMMONVULNERABILITIES 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. COMMONVULNERABILITIES 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. COMMONVULNERABILITIES 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. COMMONVULNERABILITIES 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. COMMONVULNERABILITIES 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 ServiceVulnerabilities 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. WEBSERVICE 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. WEBSERVICE 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. WEBSERVICE 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. WEBSERVICE 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. WEBSERVICE 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. WEBSERVICE 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. WEBSERVICE 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. WEBSERVICE 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. WEBSERVICE 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. WEBSERVICE 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. WEBSERVICE 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. WEBSERVICE 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. WEBSERVICE 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. WEBSERVICE 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. WEBSERVICE 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. WEBSERVICE 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. WEBSERVICE 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. APPLICATIONDEVELOPED & 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. APPLICATIONDEVELOPED & SIMULATION OF AN ATTACK 43 Figure 5.1: False Secure Web Application Structure Figure 5.2: Snapshot of Web Application
- 46. CHAPTER 5. APPLICATIONDEVELOPED & 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 TheAttacks 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. COUNTERMEASURESAGAINST 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. COUNTERMEASURESAGAINST 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. COUNTERMEASURESAGAINST THE ATTACKS 48 Figure 6.1: Ontology information of SOAP message Figure 6.2: UNWRAP Approach Structure
- 51. CHAPTER 6. COUNTERMEASURESAGAINST 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. COUNTERMEASURESAGAINST THE ATTACKS 50 Figure 6.3: XML Injection Ontology Structure Figure 6.4: XML Injection Detection Strategy
- 53. 7 Penetration TestingTool 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. PENETRATIONTESTING 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. PENETRATIONTESTING 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 thisproject 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. CONCLUSION55 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. ZhouJing 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] MohammadAshiqur 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)