Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

If you were to demonstrate a .NET Remoting Architecture vulnerability with a practical attack, which one would you choose?

I've read J. Forshaw's white paper on Breaking .NET Through Serialization (PDF), Googled thoroughly, and now I want to implement a working exploit of a .NET Remoting service. It does not matter where the service is hosted. It can be ASP, IIS, Windows service, or whatever.

share|improve this question
add comment

1 Answer

  1. DoS attacks - Given the cross technology nature of these frameworks (they C#-VB-C...) they generally are hard to secure the connection "ports". Therefore if you can enumerate and find the connection points you can often times flood them or just keep them busy and create a DoS attack by starving the "receiving" end of the framework. It is generally not hard to do, and unless a LOT of care has been put into the architecture and secured properly, then this is a low-hanging fruit.

  2. Resource Starvation Attacks:

a. Proxy Resource Attack - Generally given the proxy schemes schemes implemented by these frameworks, there is generally a loosely bound proxy that is needed that is not explicitly destroyed when resources are set-up and taken-down. This allows for ways that an attacker can script ways to blow up proxy resources create starvation scenarios.

b. Physical Resource Attacks - The serialization mechanisms used to inflate/deflate objects can at several points create physical resource attacks. You can create object bombs - large objects that consume resources extensively shutting down or starving the system; or in the case of recursive xml serialization you could create both processor and memory resource consumption by having xml processing that ties the system up.

  1. Code Injection

a. Mutation - This is where you mutate original code or objects but injecting new code into them. Each language has its own ways and guards to overcome, but generally doable.

b. Collateral - This is where you mutate or inject code into secondary languages, such as inject new SQL into database interactions, or push out new Javascript in web scenarios.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.