Add attack-priority

[Kevin Hamacher]

The client should remember which targets aren't giving any flags and should attack them at the end so that other (good) targets are getting exploited first.

[Flozza]

The client, by design, takes one IP to be attacked out of the queue. It does not know about remaining clients (it can guess the number of remaining clients). Building the priority list is easy. The problem comes to applying it on the IPs.

In general there are two possible solutions:

• Levels
• PriorityQueue

The levels solution would introduce a number of levels, e.g. 3 and first start everything from level one, then level two and so on. This would then divide the starting process in this number of levels.

The other solution would use Pythons PriorityQueue. Here we put each in target in with a priority read from the priority list, e.g. if the fastest is first, we use the index as a priority. This may be expensive as Python will likely sort the list very often. This may prove to be too slow. If this can be used, it is the favorable soltion as it is more precise and requires less changes in the code. Depending on the uses, we either insert a pair priority, IP or a dedicated object that returns the priority on the first index.

In both cases, there may arise a serious problem if it is not addressed carefully. Consider this example: We have 15 targets to attack and are configured to attack only 5 at a time. Suppose we have 10 high- and 5 low-priority targets. Most likely the low 5 would never get attacked while the 10 others would produce a high amount of duplicates (at least no new flags).

The approach to solve this, is to give each target a cooldown time. This time could be about 1 or 2 minutes (the length depends on the CTF round length and the number of targets / speed of exploit). This time has to be carefully chosen. If it is too large, good exploits are never started, if it is too low, mediocre exploits are also never started.

It is probably a good idea to develop an algorithm that re-calculates the priority after each run, lowering (lower=start later) it when it had a successful run. Then we could adjust the priority after each run and slower exploits would go up the queue until they have been executed (which would drop them lower than good exploits).

General idea: Have a base priority determined from the quality of the target and factor in the number of times it has been executed. The base priority itself should also be updated regularly (either slowly adjusted or at certain times reset to a new value, the former being likely the better but also harder).

If this is done properly it can increase the efficiency of exploits tremendously depending on some criteria. For some exploits this may not even be a gain at all (if they are fast and also fail fast allowing for continous restarts). Until this is fixed the easy solution are low timeouts and high number of parallel processes.

[Flozza]

Additionally, the cooldown time could be closely tied to the round time of the CTF (e.g. restart exploit exactly when there is a new round). This might need a separate issue and should likely be implemented on top of this solution.

There could also be a check that determines if exploits can realistically be run in parallel. fluxchief propose the formula

(round_time/threads)/exploit_duration < target_count

to check if a warning should be emitted.