Techniques in Attacking and Defending XML/Web Services
This presentation was by Jason Macy and Mamoon Yunus of Crosscheck Networks – Forum Systems. It wins the award (the one I just made up) for being the most vendor-oriented presentation at the conference. Not that it wasn’t an interesting presentation, but their solution to defend against most of the attacks was “Use an XML Gateway” (guess what Forum Systems sells?) and the attacks were all presented using the CrossCheck SOAPSonar tool. I realize that being a vendor they probably have more knowledge than most in the field, but being an Open Source conference, you’d think they would have demonstrated using a free/open tool (SOAPUI?) and talked more about non-hardware solutions to fix the issues. My notes from the session are below:
Agenda
- Introduction to XML/Web Services Threats
- Techniques for Defending XML Threats
- XML Attack Examples and Classification
- Review sample attacks
Introduction to XML Threats
- Explicit Attacks
- Forced Disruption
- Information Theft
- Vendor Discovery
- Implicit Vulnerability
- Perimeter Breach (embeeded virus, malware)
- Infrastructure Malfunction (parser and data processing failures)
New Attack Vectors
- Protocol Firewalls are blind to XML
- Malware and virus delivered via SOAP attachments
- WSDL exposes schema and message structure
- Injection attacks exposed via XML parameters
- Data replay attacks
Security Testing – Base Requirements
- Security Framework
- Sign, ENcrypt, Decrypt, SSL
- Identity Framework
- Basic auth, SSL auth, WS-Security token auth
- Parameter Injection
- Database or file driven
- Permutations for security, identity, and SOAP/XML
- Concurrent Client Simultaneous Loading
- Denial of Service Testing
- SOAP with Attachments
- Malware and Virus testing
- Dynamic XSD Mutation
- Derive SOAP vulnerability profile from WSDL schema
XML Security Gateway – Base Requirements
- Certified PKI Infrastructure (DOD PKI)
- X509 Path validation
- Sign/verify, SSL initiation, SSL termination
- Certified Security Architecture (FIPS)
- Key management and storage
- Physical security device
- Transaction Privacy
- Encryption, decryption, SSL
- Transaction Integrity
- Digital signature, signature verification, schema validation
- Transaction Accountability
- Archiving, logging, reporting, and monitoring
- Transaction Threat Mitigation
- Intrusion detection and prevention
- Rate-based rules, size-based rules, anti-virus detection, pattern recognition
- Structural integrity, protocol adherence, athorization attempts
XML Attack Examples and Classification
- SQL Injection Attack
- Denial of Service Attack
- XSD Mutation Attack
XML Web Services SQL Injection Attack Example
- How to Attack
- Construct SQL escape sequences
- Construct SQL 1=1 query
- Inject into XML node values
- Discovered Exposure
- Sensitive data loss
- Database corruption
- Used “SOAPSonar” tool to load WSDL and send responses
SQL Injection – XML Gateway Secured
- How to Defend
- Deploy XML Gateway
- Enable pattern scanning IDP rules
- Configure response message size and complexity limits
- Advantages
- Prevent Data Loss
- Alert and Quarantine Attempted Breaches
XML Web Services based Denial of Service Attack
- How to Attack
- Loading client with concurrent simultaneous threads
- Coercive parsing attack
- Discovered Exposure
- Unlimited message flow
- Unfair service SLA distribution
- Back-end CPU and I/O Saturation
Denial of Service – XML Gateway Secured
- How to Defend
- Deploy XML gateway
- Set allowed transaction rates (Group, user, or IP)
- Advantages
- Message flow limited to specified rate
Another Example: Denial of Service through Coercive Parsing
- Sending malformed XML data (removing the “>” end tag) creates increased time to parse a request
XML Web Services Based XSD Mutation Attack
- How to Attack
- Obtain WSDL
- Derive message structure and types from WSDL schema
- Send SOAP message mutations based on schema
- Discovered Exposure
- Code paths not handled for exceptions
- Stack traces returned with implementation details
- Application failure
XSD Mutation Attack – XML Gateway Secured
- How to Defend
- Deploy XML Gateway
- Enforce inbound message structure and type validation
- Cleanse outbound data (stack traces, sensitive data)
- Advantages
- Reduce parser impact on web service
- Remove vendor and implementation details in response
- Protect application layer code paths on web service
XSD Mutation – Secured
- Deploy specialized XML Gateways – Packet firewalls and HTML application firewalls are insufficient
- Validate XML against a robust schema
- Tighten Schema: restrict unbounded strings, etc
- Enforce XML specific detection rules (node depth, recursive payloads)
Best Practices for Countermeasures
- Information Control – Outbound
- Restrict SOAP Faults
- Protect Sensitive Information
- Audit Transaction Flows
- Information Control – Inbound
- Tighten Payloads
- Enforce SLA
- Disallow SQL, virus, malicious code
- Use Web Services Penetration Testing Product
- Deploy XML web Services Gateway
- Deploy Centralized XML Security
November 14th, 2009 at 10:02 am
Hello Josh:
Thanks for attending the talk. We tried to keep away from mentioning product names in our presentation and really highlight the issues regarding XML/Web services security.
SOAPUI is a decent product, however, but lacks the pen testing capabilities and is generally considered a poor security testing tool. Most tools are first plagued with the problem of loading up a WSDL once it hits a reasonable complexity, let alone start functional or performance testing. For simple WSDLs, there are a number of tools that would be sufficient.
However, for serious performance, functional and security testing, SOAPSonar (Crosscheck Networks), SOATest (Parasoft), Service Test (HP) and Rational (IBM) tend to do a better job than some of the open source initiatives.
Also, please note that we do provide a free (albeit non-open source) version of SOAPSonar. Our objective is to create awareness about security issues and let the consumers select the tools. We would have used or mentioned SOAPUI if it helped address security issues.
For a user comparison of the product SOAPUI vs SOAPSonar.
As for countermeasure to XML security problems, one can either take the solutions mentioned in the context of an XML Gateway, such as Forum Sentry, or choose to code that defensive measure in an application.
There is no free alternative to XML security enforcement – either one re-creates the policies mentioned and embed the protection in the applications (consulting $$$) or purchase a hardened XML firewall (product $$$).
We look forward to contributing to OWSAP and making the community more aware of XML related issue and moving beyond the commodity HTTP stack issues that are fairly well understood.
Regards,
Mamoon Yunus
President & CEO, Crosscheck Networks, Inc.
November 16th, 2009 at 12:35 am
All XML based solutions (including XML firewalls) are easy to break with XML fuzzers. The problem with defending against XML zero-day threats is that the complexity of XML enables infinite amount of unique zero-days, and each application will be completely unique in its set of vulnerabilities. Whereas e.g. SQL injection attacks are quite generic, XML attacks are not, and therefore it is almost impossible to protect from the threats exposed by them. XML security features add a further level of complexity because elements and substructures of XML packets can be encrypted, hiding them from the security solutions.
For more information on recent XML vulnerabilities:
http://www.codenomicon.com/labs/xml/
Some example vulnerabilities:
http://www.codenomicon.com/resources/whitepapers/HH09-Takanen-Fuzzing.pdf
One test solution that is focused on XML fuzzing:
http://www.codenomicon.com/defensics/xml/
November 16th, 2009 at 12:05 pm
Mamoon,
Thanks for your comments. I guess what I was trying to say is that maybe you could put a disclaimer at the beginning of your presentation saying “Hey, we know there are other options out there (SOATest, Service Test, Rational), but we’re demonstrating using SOAPSonar because it’s the one we’re most familiar with. If you need options, here they are.” I thought SOAPSonar looked like a pretty cool tool and even began the process of downloading it during the presentation so you’ll hear no negatives from me there. More options is all I was asking for to sufficiently make it less vendory.
As for the XML firewall, aren’t there software options there too? For example, I thought I saw Oracle WSM on the slide somewhere, but never heard you mention it. Basically, companies should have the ability to implement controls at the Application Server level rather than having to purchase an appliance, correct? You mention being able to code a defensive measure into an application. Perhaps some sample code to that effect would have been useful to illustrate? So we actually have three different options for XML security enforcement as far as I can tell: 1) Create the policies and embed protection directly in the application, 2) Create the policies as part of a software product like OWSM and have it intercept requests at the application server level, and 3) purchase a hardened XML firewall. Maybe it’d be worth spelling out those options and the advantages and disadvantages of each in future presentations?
All in all it was a very good presentation. Don’t let my comments on it winning my made up “Most Vendor-Oriented Presentation” sway you (or anyone else) from that fact. With web services and service-oriented architectures becoming more and more commonplace and increasingly exposed outside of the firewall, it is an extremely important topic and I was very happy to see someone talking about it. Thank you.
Sincerely,
Josh Sokol
November 18th, 2009 at 9:47 pm
Hi Josh:
Your comments are very useful and have initiated a serious strategic discussion within our company on how best to contribute to the community. Although Forum Sentry – our XML Gateway is available as a clean software install for (Linux, Solaris, etc.), we believe it may be time to carve out the XML Firewall capabilities and open source it. We are debating the commercial impact of this move, but generally feel it’s a win-win strategy long term.
In general, we think a security effort, commercial or Open source, should be decoupled from the application. The containers and parsers will continue to plug their holes, but as Ari mentions, it is very easy to crack a parser. Our security focus makes our parser better than others, and our focus is to rapidly fix any new and emerging issues that we see. By the time a bad XML packet reaches the back end, it’s already too late.
I like your recommendations – perhaps we should have called out some of the PHP built in functions that sanitize the SQL queries as code specific options along with other defensive coding techniques. Thanks for your honest feedback.
Regards,
-Mamoon
December 8th, 2009 at 4:57 pm
Hi Josh,
Thanks for the summaries.
One point to nitpick, but I think its important for point of view – OWASP is not “an Open Source conference”, it is “an open conference” – difference being, you can be open about your security even if your model is closed source.
I’m never too bothered by a vendor showing his own tools, as long as the focus is on the point of the talk and not a full-on sales press. I wasnt there, but it sounds like SOAPSonar was used to demo their talk – which makes perfect sense, why should they bother using something else? and choice of tool for demo isnt the point of the talk – on the other hand, it does sound like they might have elaborated more on alternative solutions to fix the problems… (and still, mentioning their product as one of those options is obviously OK in my book…)
December 8th, 2009 at 5:24 pm
Ad,
I’m not sure what your point is. Sounds like you’re saying that there’s no problem with it being a vendor-oriented presentation and I generally agree with that. My main contention here is that it was billed as “Techniques for Attacking and Defending XML/Web Services” and there are other ways to defend against these types of attacks that weren’t even mentioned. In fact, the solution to each vulnerability was “Deploy XML Gateway” which to me was more of a sales pitch for their product than a list of options for “Defending XML/Web Services”. I elaborated more on the other options in my initial comment. Anyway, I’m not going to debate whether it was or wasn’t too vendory, but it was the most vendor-oriented presentation that I saw at the conference. Thanks for your feedback.
~josh