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 Prerequisites
The 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 Exploit
Likelihood: Medium
Methods of Attack
Analysis
API Abuse
Examples-Instances
Description
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 Required
Skill 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 Required
No special resources are required in order to conduct these attacks. Web
service digging tools may be helpful.
Probing Techniques
Probing 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 Mitigations
Authenticating 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.
Vision and Technical Leadership provided by Cigital, Inc.
This Web site is hosted by The MITRE Corporation.
Copyright 2009, The MITRE Corporation. CAPEC and the CAPEC logo are trademarks of The MITRE Corporation.
Description
