BPEL Instantiation Flooding

From WS-Attacks
Jump to: navigation, search

Attack description

NOTE: Attack description is copied from [1]

Every BPEL-based workflow definition contains at least one communication activity that creates a new process instance each time a message arrives. Such a process instance immediately starts its execution according to the instructions given in the process description. The execution will be paused each time a receive activity is reached, continuing after reception of the expected message. By reaching a termination point, execution is stopped and the process instance is destroyed. Note that all execution activities except receive activities are completely driven by the BPEL engine alone. Just in case of receive, an external message triggers the next executions.

Keeping this in mind, imagine an attack that continuously calls the instantiating activity’s endpoint. For each incoming SOAP message, the BPEL engine will create a new process instance and start its execution, running each of these until they reach either a receive activity or a termination point. As a result, the BPEL engine can get overwhelmed during message parsing, process instantiation, and/or activity execution, which will decrease or even nullify the availability of the BPEL engine.

When examining instantiation flooding in the context of BPEL, there are some behavioral distinctions to make on the attack’s impact.

First, you have to realize that the BPEL engine itself is not the only target reached by this attack. Each newly created process instance is executed just like a valid one, including all its outgoing Web Service requests to external communication partners. Thus, these communication partners will undergo an increase in requests initiated by the BPEL engine(see next section). Furthermore, the processing of a single attack message and resulting resource exhaustion is determined by one of the following circumstances:

  1. If the process under attack does not contain any receive activity (beside the initial one), all executions will stop when reaching a termination point, destroying the initially created process instance. Thus, the BPEL engine will undergo the “usual” processing for each attack message.
  2. If there exists a receive (or pick) activity on the execution path chosen for the incoming attack message, all created process instances will run up to that receive activity. Here, according to the BPEL specification [1], all but the first request will cause a BPEL execution fault, as there already exists a receiving process instance with the same correlation data. Thus, all but the first process instance will execute the fault handler (if existing in the process description), causing a rollback on all activities that have already been executed previously. This will double the resource load for both BPEL engine and previously requested communication peers that are included in rollback procedures.
  3. If there exists a receive (or pick) activity on the execution path, and the attack uses unique correlation data for each attack message (such as including a counter’s value in one of the correlation data fields), none of the messages will cause a fault as stated above. Instead, all attack messages will cause creation of new process instances that all will run up to the first receive activity and wait there forever (or – in case of pick – as long as the timeout case specifies). As a result, the BPEL engine will need a huge amount of persistent storage to keep track of process instances which never complete. Further, the task of identifying the correct process instance for each message arriving at an overloaded communication endpoint will become less efficient, as the message’s correlation data must be compared to that of each process instance waiting. Due to the huge number of such waiting process instances, this task will exhaust resources quicker than before the attack.

The overall impact of both attack types depends on the structure of the BPEL process, but it potentially is a multiple of the load necessary to perform the attack. Further, it may reach not just the BPEL engine, but some of its communication partners as well.

Attack subtypes

There are no attack subtypes.

Prerequisites for attack

In order for this attack to work the attacker has to have knowledge about the following things:

  1. Attacker knows endpoint of web service. otherwise he is not able to reach the web service.
  2. Attacker knows metadata such as .
  3. Attacker can reach endpoint from its location. Access to the attacked web service server is possible for the attacker. This prerequisite is important if the web service is only available to users within a certain network.


Graphic representation of attack

No attack schema available


Attack example

No attack example available/necessary.


Attack mitigation / countermeasures

Defending against the attack requires the identification and rejection of semantically invalid requests. However, this task is not trivial since one can only determine after processing if the request was valid or malicious.

Attack categorisation

Categorisation by violated security objective

The attack aims at exhausting the system resources, therefore it violates the security objective Availability.


Categorisation by number of involved parties


Categorisation by attacked component in web service architecture


Categorisation by attack spreading


References

  1. Meiko Jensen, Nils Gruschka, and Ralph Herkenhöner. A survey of attacks on web services. Springer-Verlag, 2009. - [2]
Retrieved from "https://www.ws-attacks.org/index.php?title=BPEL_Instantiation_Flooding&oldid=13"