Home > CAPEC List > CAPEC-36: Using Unpublished APIs (Version 3.0)  

CAPEC-36: Using Unpublished APIs

Attack Pattern ID: 36
Abstraction: Standard
Status: Draft
Presentation Filter:
+ Description
An adversary searches for and invokes 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 functionality they are not authorized for.
+ Likelihood Of Attack

Medium

+ Typical Severity

High

+ Relationships

The table(s) below shows the other attack patterns and high level categories that are related to this attack pattern. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as CanFollow, PeerOf, and CanAlsoBe are defined to show similar attack patterns that the user may want to explore.

+ Relevant to the view "Mechanisms of Attack" (CAPEC-1000)
NatureTypeIDName
ChildOfMeta Attack PatternMeta Attack Pattern - A meta level attack pattern in CAPEC is a decidedly abstract characterization of a specific methodology or technique used in an attack. A meta attack pattern is often void of a specific technology or implementation and is meant to provide an understanding of a high level approach. A meta level attack pattern is a generalization of related group of standard level attack patterns. Meta level attack patterns are particularly useful for architecture and design level threat modeling exercises.113API Manipulation
+ Execution Flow
Explore
  1. Identify services: Discover a service of interest by exploring service registry listings or by connecting on a known port or some similar means. Search via internet for known, published services. Use automated tools to scan known ports to identify internet-enabled services.

    Techniques
    Search via internet for known, published services.
    Use automated tools to scan known ports to identify internet-enabled services.
  2. Authenticate to service: Authenticate to the service, if required, in order to explore it. Use published credentials to access system. Find unpublished credentails to access service. Use other attack pattern or weakness to bypass authentication.

    Techniques
    Use published credentials to access system.
    Find unpublished credentails to access service.
    Use other attack pattern or weakness to bypass authentication.
  3. Identify all interfaces: Determine the exposed interfaces by querying the registry as well as probably sniffing to expose interfaces that are not explicitly listed. For any published services, determine exposed interfaces via the documentation provided. For any services found, use error messages from poorly formed service calls to determine valid interfaces. In some cases, services will respond to poorly formed calls with valid ones.

    Techniques
    For any published services, determine exposed interfaces via the documentation provided.
    For any services found, use error messages from poorly formed service calls to determine valid interfaces. In some cases, services will respond to poorly formed calls with valid ones.
Experiment
  1. Attempt to discover unpublished functions: Using manual or automated means, discover unpublished or undocumented functions exposed by the service. Manually attempt calls to the service using an educated guess approach, including the use of terms like' 'test', 'debug', 'delete', etc. Use automated tools to scan the service to attempt to reverse engineer exposed, but undocumented, features.

    Techniques
    Manually attempt calls to the service using an educated guess approach, including the use of terms like' 'test', 'debug', 'delete', etc.
    Use automated tools to scan the service to attempt to reverse engineer exposed, but undocumented, features.
Exploit
  1. Exploit unpublished functions: Using information determined via experimentation, exploit the unpublished features of the service. Execute features that are not intended to be used by general system users. Craft malicious calls to features not intended to be used by general system users that take advantage of security flaws found in the functions.

    Techniques
    Execute features that are not intended to be used by general system users.
    Craft malicious calls to features not intended to be used by general system users that take advantage of security flaws found in the functions.
+ Prerequisites
The architecture under attack must publish or otherwise make available services 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 it 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.
+ Skills Required
[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
None: No specialized resources are required to execute this type of attack. Web service digging tools may be helpful.
+ Consequences

The table below specifies different individual consequences associated with the attack pattern. The Scope identifies the security property that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in their attack. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a pattern will be used to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Confidentiality
Read Data
Confidentiality
Access Control
Authorization
Gain Privileges
+ 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.
+ Example Instances
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.
+ Content History
Submissions
Submission DateSubmitterOrganization
2014-06-23CAPEC Content TeamThe MITRE Corporation
Modifications
Modification DateModifierOrganization
2015-12-07CAPEC Content TeamThe MITRE Corporation
Updated Attack_Phases, Attack_Prerequisites, Description Summary
2017-08-04CAPEC Content TeamThe MITRE Corporation
Updated Attack_Phases, Resources_Required
Previous Entry Names
Change DatePrevious Entry Name
2015-12-07Using Unpublished Web Service APIs

More information is available — Please select a different filter.
Page Last Updated or Reviewed: July 31, 2018