| Name |
Poison Web Service Registry |
|
| Likelyhood of attack |
Typical severity |
| High |
Very High |
|
| 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, and delete information about service provider interfaces. |
| Prerequisites |
The attacker must be able to write to resources or redirect access to the service registry. |
| Execution Flow |
| Step |
Phase |
Description |
Techniques |
| 1 |
Explore |
[Find a target SOA or Web Service] The adversary must first indentify a target SOA or Web Service. |
|
| 2 |
Experiment |
[Determine desired outcome] Because poisoning a web service registry can have different outcomes, the adversary must decide how they wish to effect the webservice. |
- An adversary can perform a denial of service attack on a web service.
- An adversary can redirect requests or responses to a malicious service.
|
| 3 |
Experiment |
[Determine if a malicious service needs to be created] If the adversary wishes to redirect requests or responses, they will need to create a malicious service to redirect to. |
- Create a service to that requests are sent to in addition to the legitimate service and simply record the requests.
- Create a service that will give malicious responses to a service provider.
- Act as a malicious service provider and respond to requests in an arbitrary way.
|
| 4 |
Exploit |
[Poison Web Service Registry] Based on the desired outcome, poison the web service registry. This is done by altering the data at rest in the registry or uploading malicious content by spoofing a service provider. |
- Intercept and change WS-Adressing headers to route to a malicious service or service provider.
- Provide incorrect information in schema or metadata to cause a denial of service.
- Delete information about service procider interfaces to cause a denial of service.
|
|
| Solutions | 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 |
| Related Weaknesses |
|
CWE ID
|
Description
|
| CWE-74 |
Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') |
| CWE-285 |
Improper Authorization |
| CWE-693 |
Protection Mechanism Failure |
|
| Related CAPECS |
|
CAPEC ID
|
Description
|
| CAPEC-203 |
An adversary exploits a weakness in authorization in order to modify content within a registry (e.g., Windows Registry, Mac plist, application registry). Editing registry information can permit the adversary to hide configuration information or remove indicators of compromise to cover up activity. Many applications utilize registries to store configuration and service information. As such, modification of registry information can affect individual services (affecting billing, authorization, or even allowing for identity spoofing) or the overall configuration of a targeted application. For example, both Java RMI and SOAP use registries to track available services. Changing registry values is sometimes a preliminary step towards completing another attack pattern, but given the long term usage of many registry values, manipulation of registry information could be its own end. |
|