Check out the new USENIX Web site. next up previous
Next: Target-Side Scripting Up: Encrypted Payload Protocol Previous: Stage 2

Limitations

As described above, the payload delivery protocol is not perfectly secure against an active attacker. Many of the design decisions were taken in order to hamper an active attacker, but preventing an active attack is not feasible when the delivery of the exploit is not secure. For instance, an active adversary could modify the first stage payload to insert its own public key in the payload or prevent the generation or use of true random numbers. The only defense against this is the use of polymorphic self-decoders that make identification of the attack more difficult. Alternatively, the penetration tester could host their exploits on a secure web server with a certificate from a trusted root certification authority. This would secure the delivery of the first-stage payload against modification by an active attacker. However, later communication is subject to known-plaintext attacks. The described use of RC4 does not guarantee integrity of the stream. An active attacker with knowledge of the plaintext can choose bytes in the decrypted stream. As described in the threat model above, the system is not truly secure against an active attacker, but takes reasonable effort to make an active attack difficult.


next up previous
Next: Target-Side Scripting Up: Encrypted Payload Protocol Previous: Stage 2
Dino A. Dai Zovi 2007-07-31