Using Unpublished Web Service APIs |
| Attack Pattern ID: 36 (Detailed Attack Pattern Completeness: Complete) | Typical Severity: High | Status: Draft |
DescriptionSummary
An attacker searches for and invokes Web Services APIs that the target system designers did not intend to be publicly available. If these APIs fail to authenticate requests the attacker may be able to invoke services and/or gain privileges they are not authorized for.
Attack Execution Flow
Discover a web service of interest, by exploring web service registry listings or by connecting on known port or some similar means
Authenticate to the web service, if required, in order to explore it.
Determine the exposed interfaces by querying the registry as well as probably sniffing to expose interfaces that are not explicitly listed.
Attack PrerequisitesThe architecture under attack must publish or otherwise make available services, of some kind, that clients can attach to, either in an unauthenticated fashion, or having obtained an authentication token elsewhere.
The service need not be 'discoverable' but in the event it isn't, must have some way of being discovered by an attacker.
This might include listening on a well-known port. Ultimately, the likelihood of exploit depends on discoverability of the vulnerable service.
Typical Likelihood of ExploitLikelihood: Medium
Methods of Attack- Analysis
- API Abuse
Examples-InstancesDescription
To an extent, Google services (such as Google Maps) are all well-known examples. Calling these services, or extending them for one's own (perhaps very different) purposes is as easy as knowing they exist. Their unencumbered public use, however, is a purposeful aspect of Google's business model. Most organizations, however, do not have the same business model. Organizations publishing services usually fall back on thoughts that Attackers "will not know services exist" and that "even if they did, they wouldn't be able to access them because they're not on the local LAN." Simple threat modeling exercises usually uncovers simple attack vectors that can invalidate these assumptions.
Attacker Skills or Knowledge RequiredSkill or Knowledge Level: Low
A number of web service digging tools are available for free that help discover exposed web services and their interfaces. In the event that a web service is not listed, the attacker does not need to know much more in addition to the format of web service messages that he can sniff/monitor for.
Resources RequiredNo special resources are required in order to conduct these attacks. Web service digging tools may be helpful.
Probing TechniquesProbing techniques should often follow normal means of identifying services. Attackers will simply have to execute code that sends the appropriate interrogating SOAP messages to suspected UDDI services (in web-services scenarios). Attackers will likely want to detect and query the organization's SOA Registry.
Probing techniques become more difficult when the service isn't advertised, or doesn't leverage discovery frameworks such as UDDI or the WS-I standard. In these cases, sniffing network traffic may suffice, depending on whether or not discovery occurs over a protected channel.
Solutions and MitigationsAuthenticating both services and their discovery, and protecting that authentication mechanism simply fixes the bulk of this problem. Protecting the authentication involves the standard means, including: 1) protecting the channel over which authentication occurs, 2) preventing the theft, forgery, or prediction of authentication credentials or the resultant tokens, or 3) subversion of password reset and the like.
Attack Motivation-Consequences- Information Leakage
- Privilege Escalation
Related Weaknesses Related Attack Patterns| Nature | Type | ID | Name | Description | View(s) this relationship pertains to |
|---|---|---|---|---|---|
| ChildOf |  Attack Pattern | 113 | API Abuse/Misuse | Mechanism of Attack (primary)1000 |
Relevant Security RequirementsAuthenticate every request or message to a service
Do not rely on lack of discoverability to protect privileged functions within the service
Related Security PrinciplesNever Assuming that Your Secrets Are Safe
Complete Mediation
Related GuidelinesUse Authorization Mechanisms Correctly
Use Authentication Mechanisms, Where Appropriate, Correctly
Purposes- Penetration
CIA Impact Technical Context| Architectural Paradigms | SOA |
|---|---|
| Frameworks | All |
| Platforms | All |
| Languages | All |
Content History| Submissions | ||||
|---|---|---|---|---|
| Submitter | Organization | Date | Comments | |
| John Steven | Cigital, Inc | 2007-02-10 | Initial core pattern content | |
| Modifications | |||||
|---|---|---|---|---|---|
| Modifier | Organization | Date | Comments | ||
| Chiradeep B. Chhaya | Cigital, Inc | 2007-02-23 | Fleshed out pattern with extra content | ||
| Richard Struse | VOXEM, Inc | 2007-03-26 | Review and feedback leading to changes in Name and Description | ||
| Sean Barnum | Cigital, Inc | 2007-04-13 | Modified pattern content according to review and feedback | ||
