July 16, 2011, 11:19 p.m.
posted by creed
Flat out, Web services will not be easy to identify blindly. They are typically not end-user facing and they are back channel in nature. So you will have to dig for their existence a bit, the current exposure model is really based on inter-entity information (usually word of mouth). The good news is that after reading Chapter 2 you should be armed with enough knowledge to at least identify when they are involved. For example, if your auditing endeavor reveals some WSDL, you should immediately know that you have to attack some SOAP mechanism.
There have been some formal attempts at providing a directory, in the form of an address book, of available Web services within a provider’s space. This formalization is Universal Description, Discovery, and Integration (UDDI — http://www.uddi.org). There is lots of controversy about its effectiveness and whether or not it has met its original promises, but it is still in use, especially with major software and service providers. The bottom line for you is that you need to know when it is a player in your pentesting space because everything necessary to launch an attack against some Web services is in the data provided by UDDI.
Web service consumers need some standardized way to discover what Web services are available for consumption. The Discovery of Web services (DISCO) provides one way to discover and retrieve WSDL descriptors from remote entities. Using the Discovery Document Format (which is also an XML document), discovery documents can be sent to a remote server and, if any SOAP-enabled services exist, a WSDL descriptor should be returned. One of the main differences between UDDI and DISCO is that UDDI represents data that spans multiple servers, whereas DISCO focuses on individual servers.
In most cases, Web service developers don’t know the endpoint URL for a given WSDL file. UDDI specifies a mechanism for Web service providers to advertise the existence of their Web services. Using it, Web service consumers can easily locate Web services for use. UDDI is supposed to be the building block that will enable disparate entities to seamlessly and dynamically find and transact with one another.
What this means for you is that if you suspect a target is either utilizing some remote Web services, or publishing services, then UDDI registries will be a good place to poke around. But this is no silver bullet, especially because there are many of these registries. A keen eye will be the best mode of operation when targeting Web services.
An excellent source of available UDDI registries is http://uddi.org/find.html.
The UDDI service operates via SOAP and WSDL. UDDI is not a Microsoft-specific technology, whereas DISCO is. But UDDI support is built into the .NET platform so you may encounter UDDI regularly when dealing with .NET-built services. Look at an example from Microsoft’s UDDI directory:
<businessEntity businessKey="429F6D41-CD03-47F7-9373-6B93913D772D" operator="Microsoft Corporation" authorizedName="Sreedhar"> <discoveryURLs> <discoveryURL useType="businessEntity"> http://uddi.microsoft.com/discovery?businesskey= 429F6D41-CD03-47F7-9373-6B93913D772D </discoveryURL> </discoveryURLs> <name xml:lang="en">w3coder</name> ... <description xml:lang="en"> Get IP address Service from Sreedhar Koganti (W3Coder) </description> <accessPoint URLType="http">http://w3coder.com/ws/email/FindIP.asmx </accessPoint> ... </businessEntity>
Generally speaking, when you encounter file extensions of .aspx, .ascx, .asmx, or .ashx, you should investigate a bit deeper (.disco and .vsdisco should be dead giveaways). For example, from the UDDI response take the value from the “accessPoint” element and go the following URL:
If you hit the same URL with query string data of either:
you may get WSDL or DISCO descriptors if they exist. In the preceding example, adding ?disco to the end of the URL as follows http://www.w3coder.com/ws/email/FindIP.asmx?disco yields:
<discovery> <contractRef ref="http://www.w3coder.com/ws/email/FindIP.asmx?wsdl" docRef="http://www.w3coder.com/ws/email/FindIP.asmx"/> <soap address="http://www.w3coder.com/ws/email/FindIP.asmx" binding="q1:FindIPSoap"/> </discovery>
The DISCO descriptor points you to the WSDL descriptor in this case, so hitting http://www.w3coder.com/ws/email/FindIP.asmx?wsdl gets you the full WSDL (which I am not including because it is not relevant; the important part is discovering it):
<wsdl:definitions targetNamespace="http://W3Coder.com/webservices/"> <wsdl:types> <s:schema elementFormDefault="qualified" targetNamespace="http://W3Coder.com/webservices/"> ... </wsdl:definitions>
If anything of value comes up from these types of probes, document all of it for later use. The data exposed by UDDI, DISCO, or WSDL needs to be taken back to the target entity to verify if public exposure of this sort is acceptable.
Once again, there are few formulas that will work in this space, so enhancing your knowledge is critical. The following are excellent resources for boosting your knowledge of these technologies (and of course Google the subject):
UDDI clients are also being developed. Here are a couple worthy of further investigation:
Eclipse’s Web services Explorer, shown in Figure, makes UDDI sources available to you via Eclipse. It also gives you the ability to search and an interface to interact with discovered services.
Web Services Inspection Language (WSIL) is meant to lead up to UDDI. It defines how a service consumer can discover WSDLs on a web server, enabling these clients to easily discover Web services. The overlap in functionality is confusing to some; look at WSIL as a stepping-stone to UDDI. One key difference is that with WSIL there is no concept of a centralized registry. Instead, the discovery process is directed at the respective service provider.
The trick to using WSIL documents is that there is a standard way of finding these documents. The WSIL specification (ftp://www6.software.ibm.com/software/developer/library/ws-wsilspec.pdf) defines a set of conventions to facilitate requestors locating a WSIL document on any web site. These conventions are as follows:
A fixed name WSIL document — The fixed name for WS-Inspection documents is inspection.wsil. A document with this name should exist on the web server and should be accessible. Typically the location of a WSIL document would be http://www.example.com/inspection.wsil.
Some linked WSIL documents — A hierarchy can be established whereupon WSIL documents can be linked. This is achieved through the presence of a link element in the XML. All WSIL documents can have any number of such links, thus creating an entire hierarchy of WSIL documents.
An example of WSIL file (from xmethods) looks like this:
<inspection> <service> <abstract>Dutch postal code resolver (beta)</abstract> <description referencedNamespace="http://schemas.xmlsoap.org/wsdl/" location="http://soap.2of4.net/NLPCResolver.WSDL"/> <description referencedNamespace="http://www.xmethods.net/"> <wsilxmethods:serviceDetailPage location="http://www.xmethods.net/ve2/ViewListing.po?key= uuid:E76E6F3B-C71A-2DE0-D654-37F2BB76C57B"> <wsilxmethods:serviceID>367741</wsilxmethods:serviceID> </wsilxmethods:serviceDetailPage> </description> </service> ... <service> <abstract>20 minute delayed stock quote</abstract> <description referencedNamespace="http://schemas.xmlsoap.org/wsdl/" location="http://services.xmethods.net/soap/urn:xmethods-delayed- quotes.wsdl"/> <description referencedNamespace="http://www.xmethods.net/"> <wsilxmethods:serviceDetailPage location="http://www.xmethods.net/ve2/ViewListing.po?key= uuid:889A05A5-5C03-AD9B-D456-0E54A527EDEE"> <wsilxmethods:serviceID>2</wsilxmethods:serviceID> </wsilxmethods:serviceDetailPage> </description> </service> </inspection>
Ultimately, if you run into any of the extensions provided by the examples (set forth from xmethods) in the following table you should dig in further for potential Web services information.
Inquiry Endpoint (UDDI)
Publication Endpoint (UDDI)
RSS (Really Simple Syndication)
Although there are never any formulas (recipes or never-changing criteria) in respect to software and their nuances, over time patterns can be established that may come in handy when identifying specific products and versions. At a high level, here are some useful elements to look for when targeting Web services on Java EE-based platforms. The following sections constitute a list based on real-world experiences — it is by no means exhaustive, and over time you will generate your own list. Moreover, it is focused on defaults for the respective products.
Java Web Service (JWS) files are important because they facilitate the deployment of simple Java-based Web services. Look for files with extension .jws; they typically represent a copy of the .java source file that has been processed for Web service deployment purposes. You won’t get Java source code but you will verify the existence of some Web service. Probing these files with the addition of ?wsdl usually gets you some interesting results.
This technology is implemented in most of the major Enterprise Java stacks represented in the following sections.
Beyond support for JWS, Axis has its own proprietary Web Service Deployment Descriptor (WSDD) files for more advanced deployments. They have a .wsdd extension, and they contain XML-based deployment information that will expose Web service details used for consumption.
Standard deployment directories for Axis are /axis/services/.. and it has full support for WSDL as well. Keep an eye out for anything that fits one of these patterns:
Also be aware of the Apache jUDDI project because it will provide a listing of available services:
As of the 4.X family, JBoss has deviated from the standard Axis model of Web service support. It now supports Web services via its own implementation of Axis (hence all of the Axis information is also applicable to JBoss) through JSR-109 (AKA - ws4ee). You can find a listing of all available Web services at http://<host>:<port>/ws4ee/services.
Each respective WSDL can be reached with the following pattern:
For JBoss version 3.X, the service listing is located as follows:
In case the JBoss UDDI service is running, you will also want to check for the following:
WebSphere’s default location for UDDI services is http://<host>:<port>/uddisoap/inquiryapi.
Also look out for this pattern that you may encounter when the administrative GUI is used:
If you suspect IBM WebSphere-hosted Web services, then you can look for some of the following as potential confirmations:
If the WebSphere Web services Gateway is in use, in default form, you will encounter something like:
WebSphere is also now using Atom syndicated feeds to expose Web service data. In default fashion it looks something like this:
WebLogic’s default location for UDDI inquiry is http://<host>:<port>/uddi/uddilistener.
Also look out for this because it may expose further WebLogic related data to you:
WebLogic generally follows these patterns:
Also keep an eye out for the following files:
These are all auto-generated client-side stubs that give you working code for consumption.
Oracle’s Application Server publishes Web service data via UDDI. By default the UDDI service is available at:
Admin user: ias_admin/ias_admin123
Publisher 1: uddi_publisher/uddi_publisher123
Publisher 2: uddi_publisher1/uddi_publisher1
Here are some other things to look for within Oracle’s current Web services model. They may expose important data to you:
Pay attention to the ?proxy_jar and ?proxy_source because if they are in place, you have auto-generated client-side code you can use for the consumption of the target services.