|Using Unpublished Interfaces
|Likelyhood of attack
|An adversary searches for and invokes interfaces that the target system designers did not intend to be publicly available. If these interfaces fail to authenticate requests the attacker may be able to invoke functionality they are not authorized for.
|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.
|[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.
- Dump the code from the chip and then perform reverse engineering to analyze the code.
|[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.
|[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.
|[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.
|[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.
|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.
|Missing Authentication for Critical Function
|Protection Mechanism Failure
|Use of Low-Level Functionality
|Inclusion of Undocumented Features or Chicken Bits
|An adversary manipulates the use or processing of an interface (e.g. Application Programming Interface (API) or System-on-Chip (SoC)) resulting in an adverse impact upon the security of the system implementing the interface. This can allow the adversary to bypass access control and/or execute functionality not intended by the interface implementation, possibly compromising the system which integrates the interface. Interface manipulation can take on a number of forms including forcing the unexpected use of an interface or the use of an interface in an unintended way.