.NET Remoting Security

[kzav...@lenel.com]

We have the client application making calls to the server using .NET
Remoting. The communication is protected by authentication,
authorization, and encryption, so nobody can get into the channel.
Also the client and the server applications are digitally signed. Now
we assume that somebody knows valid user credentials and create its own
client application to make calls to our server. We would like to
implement another layer of protection that allows only specific (signed
by us) clients to make a remote call. From what I learned about the
.NET Remoting the client sink sends the calling assembly strong name as
part of the stream. Theoretically it would give us the idea who the
caller is. But it looks like this information can be overwritten right
in the client sink, so the "bad" client can use the old strong name
that is recognized by our server to make a call. I tried to find any
information on what part of message data is always authentic and can be
trusted by the server, so we can use it in order to identify the
caller, but I did not find any definite answer.

[Nicole Calinoiu]

No matter how you attempt to implement the verification, the self-proclaimed
identity of calling code can be quite easily spoofed in a remoting scenario.
Unless you have complete control of both the client and server machines can
ensure that only the expected client machines are allowed to call the
server, you would be better off simply acknowledging that any code could be
making the call, then defending against potentially malicious requests
coming from unknown client code.

<kzav...@lenel.com> wrote in message
news:1108061223.2...@z14g2000cwz.googlegroups.com...

[roz]

Then I imagine that the same goes for the IP address of the client
which the .NET Remoting framework automatically puts into the
ITransportHeaders (with the "__IPAddress" key)?

The assembly name of the client is automatically set by the .NET
Remoting framework in the IMessage Properties ("__TypeName" key).

Since these are both automatically set by the Remoting framework, I had
been wondering if there was some mechanism used by the framework to
ensure that they could not be spoofed. I figured that it was probably
possible to spoof them (and the old adage to never trust anything from
client still holds true), but had not been able to find anything
letting me know for sure.

So, just to make sure I've got it: neither of these should be trusted,
correct?

Thanks,

Bob Rozwod

[Nicole Calinoiu]

It doesn't matter what information is set by the Framework. When your
application receives data over the wire, there's no guarantee it was sent by
a .NET application, even if the content appears to correspond to a nicely
formatted .NET remoting message. It's quite feasible to author an unmanaged
application that sends identical information over the wire.

The only situation in which the client might be considered trustworthy is
when communications between machines has been locked (e.g.: using IPSec to
allow the server to accepts calls from a given small set of machines), and
you have sole and absolute control of the client machines. This sort of
setup might be achievable for, say, a pool of servers working to service
middle tier application logic.

Of course, security of the application would still ride on the two original
assumptions (only the expected clients can connect, and nobody can run
"foreign" code via those clients). If you practice defense in depth, you
would probably still want act as if those clients can't be trusted since any
flaw in the systems supporting those assumptions would otherwise expose your
application to attack.

"roz" <r...@lenel.com> wrote in message
news:1108075979.1...@l41g2000cwc.googlegroups.com...

[bigre...@excite.com]

> "roz" <r...@lenel.com> wrote in message
> news:1108075979.1...@l41g2000cwc.googlegroups.com...
> > Then I imagine that the same goes for the IP address of the client
> > which the .NET Remoting framework automatically puts into the
> > ITransportHeaders (with the "__IPAddress" key)?

Yes. If you look at the framework code
(System.Runtime.Remoting.Channels.Http.HttpServerSocketHandler.ReadHeaders()),
the __IPAddress key is actually set on the server side based on the
socket's client IP address. This address can be spoofed. In fact, in
the case where the client is behind NAT or is going through a proxy
server, you won't even have the client's real IP address in there
anyways.

>From a security perspective, if someone has knowledge of valid
credentials to the system, the only way to prevent them from using it
is to deny them access to machines that can communicate with your
service (e.g. firewalls, OS/network security). And this is likely
outside the scope of any single application.