CAPEC-51 Poison Web Service Registry

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.

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. 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.

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. 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. 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.

• The attacker must be able to write to resources or redirect access to the service registry.

• [Low] To identify and execute against an over-privileged system interface

• Confidentiality, Integrity, Availability: Execute Unauthorized Commands • Confidentiality: Read Data • Integrity: Modify Data

• 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