SlideShare a Scribd company logo
Web Services  Hacking and Hardening  Adam Vincent, CTO – Public Sector Layer 7 Technologies October 15,  2008
Presenter Bio and Honorable Mention Adam Vincent, CTO - Public Sector    Adam Vincent has his BS in Computer Science and will be completing his MS in Computer Science this year. Adam's government related experience began as a systems administrator, working as a contractor for the U.S. Department of State where he functioned as a Network Administrator, and later a Software Engineer. After State Department, Adam joined The MITRE Corporation, a Federally Funded Research and Development Center (FFRDC) where he held the title of Senior Information Security Engineer and specialized in SOA security and cross boundary information sharing.  In this position, Adam worked closely with Federal and Civilian organizations in pursuit of building Secure Service Oriented Architectures and securely sharing information across security boundaries. In addition, while at MITRE, Adam taught classes on SOA vulnerability assessment and XML Firewalls to FFRDC and Government personnel.      Phone: 703-965-1771 Email:  [email_address]   © Adam Vincent - Layer 7 Technologies  Some of the concepts portrayed in this presentation were based on the book “Hacking Web Services” by Shreeraj Shah.  This is the first book of its kind in my opinion and portrayed the topic of Web Services Hacking in a concise and correct fashion.
Caveats The following presentation will  NOT  be a vendor Pitch but will hopefully educate the audience in Web Services Hacking, Testing, and Hardening Techniques. Real life examples may be offered that relate to deployment of Layer 7 Technologies product line.  Hardening of Web Services will have some focus on technologies like those Layer 7 Technologies provides.  Layer 7’s product will be used as an example in this portion of the presentation.  © Adam Vincent - Layer 7 Technologies
Agenda Components and Terminology Web Services Threats Web Services Hacking Web Services Hardening Conclusion and Questions © Adam Vincent - Layer 7 Technologies
Web Services Stack © Adam Vincent - Layer 7 Technologies  Presentation Layer  XML, AJAX, Portal, Other Security Layer  WS-Security Discovery Layer  UDDI, WSDL Access Layer  SOAP, REST Transport  HTTP, HTTPS, JMS, Other
Web Service Provider or Server-Side © Adam Vincent - Layer 7 Technologies  Web  Application  Server Web  Server (HTTP/HTTPS) Plug-In Internal/External Resource SOAP
Web Services Consumer or Client-Side  © Adam Vincent - Layer 7 Technologies  Application Web Service Consumer Design-Time Web Service Provider #1 Web Service Provider #2 WSDL WSDL Web Service Consumer Application Web Service Consumer Run-Time Web Service Provider #1 Web Service Provider #2 Web Service Consumer HTTP(S) HTTP(S) SOAP SOAP
Common Web Services Usage © Adam Vincent - Layer 7 Technologies  Portal Server Web Service Provider #1 Web Service Provider #2 SQL DB Mainframe Application Browser  Client Browser  Client HTTP Get/Post SOAP ODBC Unknown Web Service Consumer SOAP
Web Service Threats © Adam Vincent - Layer 7 Technologies  Transport Parsing Deployment Service Code
Transport Threats  Sniffing and Snooping Message confidentiality concerns WS-Routing  SOAP messages can contain verbose instructions on their desired routing.  If a single node in this routing path is compromised multiple threats can be realized.  Replay Attacks Message integrity concerns and potential Denial of Service by taking a correct message with valid credential and sending it 1000+ times Denial of Service Same old threat in regard to network Denial of Service © Adam Vincent - Layer 7 Technologies
Parsing Threats Almost all products employ the same parsers, therefore if a vulnerability exists in a single product leveraging MS Parser then all others have the same threat. The XML specification itself does not put any restrictions on the structure itself and rather is open to interpretation by the creator of the parser.  Example: Some parsers will stop reading an XML Attribute value once they reach some number of characters and others will continue.  <Name Organization=“I’m a parser attack, …………………….> The following will be discussed:  Buffer, Heap, Integer Overflows XML Parser Attacks  © Adam Vincent - Layer 7 Technologies
Buffer, Heap, or Integer Overflow Threats Warning: Through a successful buffer overflow a malicious command may be executed on your system.  We see these all the time!  Through passing a malicious buffer to a Web Server or Application server the attacker can create an overflow condition where a segmentation fault occurs.  This oversized/malicious buffer can be sent as part of the transport header OR as part of the SOAP message.  An expected integer value can be overflowed by exceeding the value allowed causing a segmentation fault. Once an attacker knows that a overflow is possible they can then use this to potentially execute malicious code on the system.  Commonly called a buffer overflow attack. © Adam Vincent - Layer 7 Technologies
XML Parser Attack Threats The following threats can result in a denial of service commonly referred to as XML Denial of Service (XDOS) by consuming 100% of processing power on the system doing the parsing. Complex or Recursive Payload Again, the XML specification and structure has no limits!  Automated applications are available which create Fuzzed data for XDOS attacks.  Oversized Payload Many parsing technologies load entire documents into memory Web Services were generally NOT designed around large message sizes.  Other Unique attacks will be found where underlying parsers have vulnerabilities © Adam Vincent - Layer 7 Technologies
Deployment Threats Web Service Automation is Our Friend…..Or Is It? UDDI, WSDL, SOAP Faults (errors), Descriptions….OH BOY! UDDI UDDI contains asset information  Automated War-Dialers (scanners) can search for UDDI’s for services (i.e. Bank service found here) WSDL Contains adequate information to attack service (i.e Here is how the bank service works) Automated programs consume WSDL and commence scanning the service (i.e.  Automatically issue scanning/attack messages) SOAP Faults SOAP Faults return information about the service (i.e Bank service is running on IIS version ?? and uses .Net parser) SOAP Faults returns errors from the backend resources such as the SQL DB, or  Mainframe (i.e Bank service is using Oracle DB version ??)  © Adam Vincent - Layer 7 Technologies
Service Code Threats Good development practices can alleviate this threat.  How many programs or programmers are perfect though?  Parameter Tampering Parameters are changed <file_location>C:/INET/file.txt</file_location> changed to <file_location>C:/*</file_location> Code Injection Code is injected within an XML element <SQL>SELECT name FROM DB1 WHERE name = ‘Adam’</SQL> changed to  <SQL>SELECT * From DB1 WHERE name = *</SQL Virus/Spyware/Malware Injections  XML Attachments (MTOM, DIME, MIME) are used as a delivery mechanism for virus Session Tampering and Identity Hijacking Some Web Services keep track of session with a Unique ID.  Attackers can use that ID to become part of the transaction taking place. © Adam Vincent - Layer 7 Technologies
Web Services Hacking Attackers See Opportunities! Web Services offer a entirely new dimension to the traditional security stack.  This new  layer  is a business layer and current security practices DO NOT offer sufficient protection. Why: Totally new technology, with new comes problems Operates over common web transports, traditional firewalls are based on the concept of stopping attacks at the OS level not at the Message Level (Layer 3-5).  Automation and Toolkit development (Reuse of these tools) Standardization of attack vectors, you can attack .NET and Java business applications using the same messages. Inherent Descriptions (WSDL, Tool kit web pages, etc.) © Adam Vincent - Layer 7 Technologies
A Significant Problem in System Distribution The problem with any distributed system is that a single  failure within the system can have an unknown impact on the system in its entirety.  In the use of Web Services we are adopting a practice of reuse and system distribution that spans one or more networks and potentially the internet.  © Adam Vincent - Layer 7 Technologies
Steps in Web Services Hacking I’ve broken this tutorial down into 4 steps: 1.) Learn as much as you can about the system 2.) Do your Homework 3.) Launch the Attack 4.) Clean up after yourself © Adam Vincent - Layer 7 Technologies
Step 1: Learning, Finding a Web Service  You could search a Public UDDI in this step but in most cases public UDDI information will describe services that have been created for public usage and are protected as such.  We’re going to be a bit trickier here by looking for services that are not up for public consumption.  The technique is known as crawling Command:  wget –l 50 –r http://bankwebserver.com Where “–l 50” is the maximum number of links to display And “–r” recursively crawls the site Returns:  You have received 27 files form the server Command:  find . –name *wsdl* Returns:  ./ws/bankservice.asmx?wsdl We found a WSDL, now lets look to see what we can find out about the service…. © Adam Vincent - Layer 7 Technologies
Step 1: Learning, Examining a Web Service © Adam Vincent - Layer 7 Technologies  Three operations  available: withdrawl, deposit, and get_balance Where the  service resides
Step 1: Learning, Examining a Web Service (cont) © Adam Vincent - Layer 7 Technologies  Operation parameters  for  withdrawl operation
Step 1: Learning (Attempting to Obtain Errors) © Adam Vincent - Layer 7 Technologies
Step 1: Learning (Attempting to Obtain Errors) © Adam Vincent - Layer 7 Technologies  Bank Service Hello Bank Service You must use me like this! Bank Service Ok…Hello Bank Service You must use me like this! You would continue this process while looking for areas to exploit,  there are automated tools that do this for you
Step 1: Learning (Completed) You now know the following: 1.) Service Location – www.bankwebserver.com 2.) Application Server Platform – IIS with .Net Version 5.0 3.) Web Service Purpose (Withdrawl, Deposit, Balance) 4.) The expected values of the request  PAN, Cardholder_Name, Service_Code, Expiration_Date, Full_Magnetic_Stripe, CVC2, PIN_Number, and Amount.  5.) You know that the service is running  6.) The service returns errors that illustrate its not using SSL, and that it is running IIS .NET version 5.0.23.  In a real life situation you would want to know a lot more but lets continue for now.  © Adam Vincent - Layer 7 Technologies
Step 2: Do Your Homework Tool of Choice: www.google.com Research:  Analyze Security capabilities in Place, Look for deficiencies Vulnerabilities in IIS .NET 5.0.23 application servers Vulnerabilities in .Net Parser’s with correct version Analyze DOS/XDOS opportunities We now would have enough information to push forward with the actual attack. Ready Set Go! © Adam Vincent - Layer 7 Technologies
Step 3: Launch the Attack © Adam Vincent - Layer 7 Technologies  Bank Service Withdrawl $1,000,000 from some account, and put in your account Withdrawl/deposit Accomplished Launch XDOS (exploit XDOS vulnerability)  Security Not Working Bank Service XML Fuzzer 100% CPU
Step 4: Clean Up After Yourself © Adam Vincent - Layer 7 Technologies  1.) Go to the Bank 2.) Leave the Country…Fast A real hacker would be able to do some things to cover their tracks.   This is what I would do!
Web Services Hardening © Adam Vincent - Layer 7 Technologies  Transport Parsing Deployment Service Code Confidentiality, Integrity Enforcement  XML Structure Threat Detection  Secure Deployment  Input Validation,  Virus Detection,  Access Control
Confidentiality, Integrity Enforcement Mitigate Transport Threats to Include Sniffing, Snooping, Routing Detours, and other types of transport threats  Transport Layer Encryption SSL/TLS – Only good while in transit between intermediaries, does not persist from end-to-end. WS-Security – Persists from end-to-end XML Encryption – Encrypted message content, does not require entire message to be encrypted. XML Digital Signatures –  Digital signatures of message content, does not require entire message to be digitally signed. © Adam Vincent - Layer 7 Technologies
XML Structure Threat Detection © Adam Vincent - Layer 7 Technologies  Message Size < 1MB Yes No Element Nesting < 10 Levels Error, Audit Yes No Error, Audit Attribute Size,  Element Size < 1000 No Yes Error Virus
Secure Deployment UDDI and WSDL are like “Maps to the Treasure” and should be  Treated as such.  You wouldn’t leave the actual map to your treasure out in plain sight would you? UDDI, WSDL Virtualize Internal Services to consumers through creation of virtual endpoints described by generalized WSDL and UDDI descriptions. SOAP Faults and Error Messages Don’t allow SOAP faults and errors to be relayed to potentially malicious consumers.  Generalize SOAP faults to contain no information about deployed application types and versions.  © Adam Vincent - Layer 7 Technologies
Input Validation (parameter tampering) The service code layer is where development is done in creating business capabilities and is the easiest to hack.  This is probably the most critical to protect. Basic Parameter Validation Don’t use strings as the allowed Data type.  That’s like allowing anything to pass.  Validate Integer values for length Specifically Parameter Validation If its supposed to be a SSN then validate it is one!  If it’s a zip code validate that its [[0-9][0-9] [0-9] [0-9] [0-9]] XML Schema provides a tool to validate message parameters according to predetermined business usage.  © Adam Vincent - Layer 7 Technologies
Input Validation (code injection) Some Code Injection protection is inherent in having a constrained schema validation on input parameters although there are some places where Schema does not suffice. Wherever strings or more general character sets are allowed validation should be done to verify malicious code is not present. <SQL>Some Malicous SQL Command</SQL> Be Careful about Unicode representations of characters to avoid detection.  Parsers will do funny things with these…. <blog_update>%lt;JAVASCRIPT%rt; Malicious Script </blog_update> Be Careful with CDATA and XML Comments as XML parsers are designed to overlook these.  <![CDATA[ function matchwo(a,b) { if (a < b && a < 0) then { return 1 } else { return 0 } } ]]> © Adam Vincent - Layer 7 Technologies
Virus Detection (virus, spyware, malware) XML inherently does not have the ability to execute viruses rather it is a vector to which viruses can be conveyed to Web Services and backend applications for execution. There are essentially two ways this can happen: Primary – SOAP with Attachments, MTOM, WS-Attachments Web Service needs to either execute application stored within the SOAP attachment or issue the SOAP attachment to another system for later execution. Mediation:  Attachments should be scanned with a virus scanner, traditional virus scanning engines generally do not offer such a capability. Secondary – Base64 encoded malicious program Web Service or other application needs to be programmed to decode BASE64 value and execute resulting binary.  The program would have to have this purpose in mind in its inception to make this work.  Mediation:  If this is the intended purpose for a large XML element and validation can not be accomplished, the element should be decoded and then scanned by a Virus Scanning Engine.  Again Virus Engines are inadequate in this purpose © Adam Vincent - Layer 7 Technologies
Access Control Most security conscience Web Service developers employ some mechanism of authentication into deployed web service capabilities.  This can be as simple as HTTP Basic or as complex as SAML Holder of Key (HOK).  Authorization can be based on accessing the Web Server itself or more specifically an operation within a service.  With web services becoming more sophisticated the later is the recommended method in moving forward.  Even when access control is in place, a defense in depth approach is suggested to alleviate concern when a malicious entity has hijacked an existing authorized identity.  © Adam Vincent - Layer 7 Technologies
XML Appliances – All  Hardening Wrapped UP So I’ve suggested several hardening tactics which can be used to protect Web Services from attack.  These things are not easy to implement especially with development and overhead associated with parsing and crypto operations.  The easier approach, Layer 7 to the Rescue! © Adam Vincent - Layer 7 Technologies  Bank Service Web Service Consumer Other Services Web Service Consumer Secure SOAP Secure SOAP Policy Policy SecureSpan  Appliance SecureSpan  XML VPN
Conclusion and Questions?  I’m hoping that this was a good overview for everyone!  Please feel free to contact me if you have any further questions or comments about the presentation.  It’s a work in progress and I’m hoping to update it based on audience feedback. You can contact me at  [email_address]  or at 703-965-1771. Questions? Thanks For Your Time! © Adam Vincent - Layer 7 Technologies

More Related Content

Layer 7 Technologies: Web Services Hacking And Hardening

  • 1. Web Services Hacking and Hardening Adam Vincent, CTO – Public Sector Layer 7 Technologies October 15, 2008
  • 2. Presenter Bio and Honorable Mention Adam Vincent, CTO - Public Sector   Adam Vincent has his BS in Computer Science and will be completing his MS in Computer Science this year. Adam's government related experience began as a systems administrator, working as a contractor for the U.S. Department of State where he functioned as a Network Administrator, and later a Software Engineer. After State Department, Adam joined The MITRE Corporation, a Federally Funded Research and Development Center (FFRDC) where he held the title of Senior Information Security Engineer and specialized in SOA security and cross boundary information sharing.  In this position, Adam worked closely with Federal and Civilian organizations in pursuit of building Secure Service Oriented Architectures and securely sharing information across security boundaries. In addition, while at MITRE, Adam taught classes on SOA vulnerability assessment and XML Firewalls to FFRDC and Government personnel.     Phone: 703-965-1771 Email:  [email_address] © Adam Vincent - Layer 7 Technologies Some of the concepts portrayed in this presentation were based on the book “Hacking Web Services” by Shreeraj Shah. This is the first book of its kind in my opinion and portrayed the topic of Web Services Hacking in a concise and correct fashion.
  • 3. Caveats The following presentation will NOT be a vendor Pitch but will hopefully educate the audience in Web Services Hacking, Testing, and Hardening Techniques. Real life examples may be offered that relate to deployment of Layer 7 Technologies product line. Hardening of Web Services will have some focus on technologies like those Layer 7 Technologies provides. Layer 7’s product will be used as an example in this portion of the presentation. © Adam Vincent - Layer 7 Technologies
  • 4. Agenda Components and Terminology Web Services Threats Web Services Hacking Web Services Hardening Conclusion and Questions © Adam Vincent - Layer 7 Technologies
  • 5. Web Services Stack © Adam Vincent - Layer 7 Technologies Presentation Layer XML, AJAX, Portal, Other Security Layer WS-Security Discovery Layer UDDI, WSDL Access Layer SOAP, REST Transport HTTP, HTTPS, JMS, Other
  • 6. Web Service Provider or Server-Side © Adam Vincent - Layer 7 Technologies Web Application Server Web Server (HTTP/HTTPS) Plug-In Internal/External Resource SOAP
  • 7. Web Services Consumer or Client-Side © Adam Vincent - Layer 7 Technologies Application Web Service Consumer Design-Time Web Service Provider #1 Web Service Provider #2 WSDL WSDL Web Service Consumer Application Web Service Consumer Run-Time Web Service Provider #1 Web Service Provider #2 Web Service Consumer HTTP(S) HTTP(S) SOAP SOAP
  • 8. Common Web Services Usage © Adam Vincent - Layer 7 Technologies Portal Server Web Service Provider #1 Web Service Provider #2 SQL DB Mainframe Application Browser Client Browser Client HTTP Get/Post SOAP ODBC Unknown Web Service Consumer SOAP
  • 9. Web Service Threats © Adam Vincent - Layer 7 Technologies Transport Parsing Deployment Service Code
  • 10. Transport Threats Sniffing and Snooping Message confidentiality concerns WS-Routing SOAP messages can contain verbose instructions on their desired routing. If a single node in this routing path is compromised multiple threats can be realized. Replay Attacks Message integrity concerns and potential Denial of Service by taking a correct message with valid credential and sending it 1000+ times Denial of Service Same old threat in regard to network Denial of Service © Adam Vincent - Layer 7 Technologies
  • 11. Parsing Threats Almost all products employ the same parsers, therefore if a vulnerability exists in a single product leveraging MS Parser then all others have the same threat. The XML specification itself does not put any restrictions on the structure itself and rather is open to interpretation by the creator of the parser. Example: Some parsers will stop reading an XML Attribute value once they reach some number of characters and others will continue. <Name Organization=“I’m a parser attack, …………………….> The following will be discussed: Buffer, Heap, Integer Overflows XML Parser Attacks © Adam Vincent - Layer 7 Technologies
  • 12. Buffer, Heap, or Integer Overflow Threats Warning: Through a successful buffer overflow a malicious command may be executed on your system. We see these all the time! Through passing a malicious buffer to a Web Server or Application server the attacker can create an overflow condition where a segmentation fault occurs. This oversized/malicious buffer can be sent as part of the transport header OR as part of the SOAP message. An expected integer value can be overflowed by exceeding the value allowed causing a segmentation fault. Once an attacker knows that a overflow is possible they can then use this to potentially execute malicious code on the system. Commonly called a buffer overflow attack. © Adam Vincent - Layer 7 Technologies
  • 13. XML Parser Attack Threats The following threats can result in a denial of service commonly referred to as XML Denial of Service (XDOS) by consuming 100% of processing power on the system doing the parsing. Complex or Recursive Payload Again, the XML specification and structure has no limits! Automated applications are available which create Fuzzed data for XDOS attacks. Oversized Payload Many parsing technologies load entire documents into memory Web Services were generally NOT designed around large message sizes. Other Unique attacks will be found where underlying parsers have vulnerabilities © Adam Vincent - Layer 7 Technologies
  • 14. Deployment Threats Web Service Automation is Our Friend…..Or Is It? UDDI, WSDL, SOAP Faults (errors), Descriptions….OH BOY! UDDI UDDI contains asset information Automated War-Dialers (scanners) can search for UDDI’s for services (i.e. Bank service found here) WSDL Contains adequate information to attack service (i.e Here is how the bank service works) Automated programs consume WSDL and commence scanning the service (i.e. Automatically issue scanning/attack messages) SOAP Faults SOAP Faults return information about the service (i.e Bank service is running on IIS version ?? and uses .Net parser) SOAP Faults returns errors from the backend resources such as the SQL DB, or Mainframe (i.e Bank service is using Oracle DB version ??) © Adam Vincent - Layer 7 Technologies
  • 15. Service Code Threats Good development practices can alleviate this threat. How many programs or programmers are perfect though? Parameter Tampering Parameters are changed <file_location>C:/INET/file.txt</file_location> changed to <file_location>C:/*</file_location> Code Injection Code is injected within an XML element <SQL>SELECT name FROM DB1 WHERE name = ‘Adam’</SQL> changed to <SQL>SELECT * From DB1 WHERE name = *</SQL Virus/Spyware/Malware Injections XML Attachments (MTOM, DIME, MIME) are used as a delivery mechanism for virus Session Tampering and Identity Hijacking Some Web Services keep track of session with a Unique ID. Attackers can use that ID to become part of the transaction taking place. © Adam Vincent - Layer 7 Technologies
  • 16. Web Services Hacking Attackers See Opportunities! Web Services offer a entirely new dimension to the traditional security stack. This new layer is a business layer and current security practices DO NOT offer sufficient protection. Why: Totally new technology, with new comes problems Operates over common web transports, traditional firewalls are based on the concept of stopping attacks at the OS level not at the Message Level (Layer 3-5). Automation and Toolkit development (Reuse of these tools) Standardization of attack vectors, you can attack .NET and Java business applications using the same messages. Inherent Descriptions (WSDL, Tool kit web pages, etc.) © Adam Vincent - Layer 7 Technologies
  • 17. A Significant Problem in System Distribution The problem with any distributed system is that a single failure within the system can have an unknown impact on the system in its entirety. In the use of Web Services we are adopting a practice of reuse and system distribution that spans one or more networks and potentially the internet. © Adam Vincent - Layer 7 Technologies
  • 18. Steps in Web Services Hacking I’ve broken this tutorial down into 4 steps: 1.) Learn as much as you can about the system 2.) Do your Homework 3.) Launch the Attack 4.) Clean up after yourself © Adam Vincent - Layer 7 Technologies
  • 19. Step 1: Learning, Finding a Web Service You could search a Public UDDI in this step but in most cases public UDDI information will describe services that have been created for public usage and are protected as such. We’re going to be a bit trickier here by looking for services that are not up for public consumption. The technique is known as crawling Command: wget –l 50 –r http://bankwebserver.com Where “–l 50” is the maximum number of links to display And “–r” recursively crawls the site Returns: You have received 27 files form the server Command: find . –name *wsdl* Returns: ./ws/bankservice.asmx?wsdl We found a WSDL, now lets look to see what we can find out about the service…. © Adam Vincent - Layer 7 Technologies
  • 20. Step 1: Learning, Examining a Web Service © Adam Vincent - Layer 7 Technologies Three operations available: withdrawl, deposit, and get_balance Where the service resides
  • 21. Step 1: Learning, Examining a Web Service (cont) © Adam Vincent - Layer 7 Technologies Operation parameters for withdrawl operation
  • 22. Step 1: Learning (Attempting to Obtain Errors) © Adam Vincent - Layer 7 Technologies
  • 23. Step 1: Learning (Attempting to Obtain Errors) © Adam Vincent - Layer 7 Technologies Bank Service Hello Bank Service You must use me like this! Bank Service Ok…Hello Bank Service You must use me like this! You would continue this process while looking for areas to exploit, there are automated tools that do this for you
  • 24. Step 1: Learning (Completed) You now know the following: 1.) Service Location – www.bankwebserver.com 2.) Application Server Platform – IIS with .Net Version 5.0 3.) Web Service Purpose (Withdrawl, Deposit, Balance) 4.) The expected values of the request PAN, Cardholder_Name, Service_Code, Expiration_Date, Full_Magnetic_Stripe, CVC2, PIN_Number, and Amount. 5.) You know that the service is running 6.) The service returns errors that illustrate its not using SSL, and that it is running IIS .NET version 5.0.23. In a real life situation you would want to know a lot more but lets continue for now. © Adam Vincent - Layer 7 Technologies
  • 25. Step 2: Do Your Homework Tool of Choice: www.google.com Research: Analyze Security capabilities in Place, Look for deficiencies Vulnerabilities in IIS .NET 5.0.23 application servers Vulnerabilities in .Net Parser’s with correct version Analyze DOS/XDOS opportunities We now would have enough information to push forward with the actual attack. Ready Set Go! © Adam Vincent - Layer 7 Technologies
  • 26. Step 3: Launch the Attack © Adam Vincent - Layer 7 Technologies Bank Service Withdrawl $1,000,000 from some account, and put in your account Withdrawl/deposit Accomplished Launch XDOS (exploit XDOS vulnerability) Security Not Working Bank Service XML Fuzzer 100% CPU
  • 27. Step 4: Clean Up After Yourself © Adam Vincent - Layer 7 Technologies 1.) Go to the Bank 2.) Leave the Country…Fast A real hacker would be able to do some things to cover their tracks. This is what I would do!
  • 28. Web Services Hardening © Adam Vincent - Layer 7 Technologies Transport Parsing Deployment Service Code Confidentiality, Integrity Enforcement XML Structure Threat Detection Secure Deployment Input Validation, Virus Detection, Access Control
  • 29. Confidentiality, Integrity Enforcement Mitigate Transport Threats to Include Sniffing, Snooping, Routing Detours, and other types of transport threats Transport Layer Encryption SSL/TLS – Only good while in transit between intermediaries, does not persist from end-to-end. WS-Security – Persists from end-to-end XML Encryption – Encrypted message content, does not require entire message to be encrypted. XML Digital Signatures – Digital signatures of message content, does not require entire message to be digitally signed. © Adam Vincent - Layer 7 Technologies
  • 30. XML Structure Threat Detection © Adam Vincent - Layer 7 Technologies Message Size < 1MB Yes No Element Nesting < 10 Levels Error, Audit Yes No Error, Audit Attribute Size, Element Size < 1000 No Yes Error Virus
  • 31. Secure Deployment UDDI and WSDL are like “Maps to the Treasure” and should be Treated as such. You wouldn’t leave the actual map to your treasure out in plain sight would you? UDDI, WSDL Virtualize Internal Services to consumers through creation of virtual endpoints described by generalized WSDL and UDDI descriptions. SOAP Faults and Error Messages Don’t allow SOAP faults and errors to be relayed to potentially malicious consumers. Generalize SOAP faults to contain no information about deployed application types and versions. © Adam Vincent - Layer 7 Technologies
  • 32. Input Validation (parameter tampering) The service code layer is where development is done in creating business capabilities and is the easiest to hack. This is probably the most critical to protect. Basic Parameter Validation Don’t use strings as the allowed Data type. That’s like allowing anything to pass. Validate Integer values for length Specifically Parameter Validation If its supposed to be a SSN then validate it is one! If it’s a zip code validate that its [[0-9][0-9] [0-9] [0-9] [0-9]] XML Schema provides a tool to validate message parameters according to predetermined business usage. © Adam Vincent - Layer 7 Technologies
  • 33. Input Validation (code injection) Some Code Injection protection is inherent in having a constrained schema validation on input parameters although there are some places where Schema does not suffice. Wherever strings or more general character sets are allowed validation should be done to verify malicious code is not present. <SQL>Some Malicous SQL Command</SQL> Be Careful about Unicode representations of characters to avoid detection. Parsers will do funny things with these…. <blog_update>%lt;JAVASCRIPT%rt; Malicious Script </blog_update> Be Careful with CDATA and XML Comments as XML parsers are designed to overlook these. <![CDATA[ function matchwo(a,b) { if (a < b && a < 0) then { return 1 } else { return 0 } } ]]> © Adam Vincent - Layer 7 Technologies
  • 34. Virus Detection (virus, spyware, malware) XML inherently does not have the ability to execute viruses rather it is a vector to which viruses can be conveyed to Web Services and backend applications for execution. There are essentially two ways this can happen: Primary – SOAP with Attachments, MTOM, WS-Attachments Web Service needs to either execute application stored within the SOAP attachment or issue the SOAP attachment to another system for later execution. Mediation: Attachments should be scanned with a virus scanner, traditional virus scanning engines generally do not offer such a capability. Secondary – Base64 encoded malicious program Web Service or other application needs to be programmed to decode BASE64 value and execute resulting binary. The program would have to have this purpose in mind in its inception to make this work. Mediation: If this is the intended purpose for a large XML element and validation can not be accomplished, the element should be decoded and then scanned by a Virus Scanning Engine. Again Virus Engines are inadequate in this purpose © Adam Vincent - Layer 7 Technologies
  • 35. Access Control Most security conscience Web Service developers employ some mechanism of authentication into deployed web service capabilities. This can be as simple as HTTP Basic or as complex as SAML Holder of Key (HOK). Authorization can be based on accessing the Web Server itself or more specifically an operation within a service. With web services becoming more sophisticated the later is the recommended method in moving forward. Even when access control is in place, a defense in depth approach is suggested to alleviate concern when a malicious entity has hijacked an existing authorized identity. © Adam Vincent - Layer 7 Technologies
  • 36. XML Appliances – All Hardening Wrapped UP So I’ve suggested several hardening tactics which can be used to protect Web Services from attack. These things are not easy to implement especially with development and overhead associated with parsing and crypto operations. The easier approach, Layer 7 to the Rescue! © Adam Vincent - Layer 7 Technologies Bank Service Web Service Consumer Other Services Web Service Consumer Secure SOAP Secure SOAP Policy Policy SecureSpan Appliance SecureSpan XML VPN
  • 37. Conclusion and Questions? I’m hoping that this was a good overview for everyone! Please feel free to contact me if you have any further questions or comments about the presentation. It’s a work in progress and I’m hoping to update it based on audience feedback. You can contact me at [email_address] or at 703-965-1771. Questions? Thanks For Your Time! © Adam Vincent - Layer 7 Technologies

Editor's Notes

  1. Presentation Layer: The presentation layer provides meaning to Web Services in many different ways. This meaning can be portrayed to an APPLICATION as an XML message/document. It can be presented to a human being in the form of a rich internet application (AJAX, Portal) or though many other presentation technologies available. The bottom line is that Web Services are designed for machine to machine communication but human interfaces are being used and as such you must understand these ramifications. Security Layer: Web Services Security is an important part of the web services stack although web service security is only a single component of enabling adequate web services security. Essentially WS Security provides security to information portrayed within the XML data structure Discovery: UDDI is a currently accepted method to publish and find web services. WSDL contains information about web services (Location, Description) and is commonly referred to within a UDDI. Access Layer: Common structure for accessing web services. (Described within WSDL, and universally accepted) Transport Layer: Common web transports relied on by web services (HTTP/HTTPS and JMS are described within WSDL although no one standard exists for JMS).
  2. The diagram above depicts the Server Side architecture generally found in a Web Services Provider. The incoming transactions in this case are SOAP over some transport protocol. Its important to mention that the application server can have plug-ins where these plug-ins communicate with one or more internal or external resources. These resources can be Web Services and result in the plug-in being a consumer or the resource can be a SQL data source, or some non-web service oriented information repository.
  3. Design-time and Run-time are differentiated by the requirement of finding services. In a design time operation an application developer will find the services that she was like to use through UDDI or some other mechanism. Once found the developer will consume the WSDL for the service to create a binding between their developed application and the web service. Run-time operations will commence and be entirely based on SOAP. In some cases clients will still interact with UDDI/WSDL to verify some information about the service. For example the UDDI/WSDL could be queried to determine if the service location has changed. Run-time hacking is where this presentation will primarily focus although development time resources like UDDI and WSDL will be necessary tools of the trade.
  4. One common way of leveraging services is through a portal interface. The portal is responsible for creating the human presentation layer for a Service Oriented Architecture or one or more web services. Humans interact with the Portal Server using a browser client and the portal interacts with Web Services on their behalf. In some cases the web services interact further with back-end resources.
  5. I’ve broken down web service threats into the following 4 basic bins for better understanding. The bins are basically based on the threat framework proposed by Shreeraj Shaw in the book titled “Hacking Web Services”. Transport: Transport layer threats involve the confidentiality and integrity of the data as well as concerns associated with erroneous routing and replay attacks. Denial of service is always an issue at the transport layer is no different when using web services. Parsing: Essentially this layer of threats is based on the idea of overwhelming the underlying XML parser. This is by far the easiest form of attack on XML application and has resulted in security vendors offering XDOS offerings to their products. Question: have you even opened a large recursive XML document in IE. If so you know that it essentially brings your machine to a stand still. Deployment: This is a really interesting area as it is greatly misunderstood. Web Services and their respective type of technology do many things automatically and are unknown to the application develop. For example many application servers will automatically return verbose error messages to clients as well as host WSDL documents describing their corresponding services for everyone to see. Openly available service descriptions, verbose error messages (potentially from the backend itself) and automated deployment are responsible for a majority of the threats associated with Web Services.