Unexploitable case? about exploitremotingservice HOT 7 CLOSED

The "fix" is in App.config with the line . That just disables the security fix where you could pass an IMessage object which was actually a remote proxy. However as long as the server is running with TypeFilterLevel.Full then useser should work, however only a subset of commands work in that scenario.

Presumably the exception you're getting is from the server, not the client? Perhaps double check the server code is actually set to TypeFilterLevel.Full. Also it might be down to the way that the channels are registered in the server, the code might be passing say an IPC channel when only a TCP channel is registered and vice versa.

from exploitremotingservice.

Did you mean to say, the line <add key="microsoft:Remoting:AllowTransparentProxyMessage" value="true"/> ?

I am only trying to use ls. Exception is from the server.

Having a look at the network traffic with a 'legitimate' client I wrote it only talks on the one channel to send the command and retrieve the output (basically string getProperty(string x)), and doesn't use the second channel/tcp connection (default 11111).

from exploitremotingservice.

Had another look at the code, it only creates and registers a TcpServerChannel (with a BinaryServerFormatterSinkProvider { TypeFilterLevel.Full }. There is no BinaryClientFormatterSinkProvider, I assume in this configuration it won't do the connect back to our service on11111?

from exploitremotingservice.

Yeah, basically it assumed that you'd normally setup both a client and a server provider, which is what a normal TcpChannel would do, but if they just register a server channel then there's no client channel to talk back to you. What .NET runtime is the server using? If it's at least 3.5 then could repurpose one of my direct serialization attacks.

from exploitremotingservice.

Good suggestion, I thought they were all patched but I just tried your TypeConfuseDelegate (in ysoserial.net) and substituted the 'data' in SendRequest ftw :)

from exploitremotingservice.

Glad it sounds like it works :-) None of those serialization bugs are actually patched. At some point I'd try and merge them into the tool but I've not had the time or the inclination. At the least I probably should add a command which just takes a blob and send it to there server.

from exploitremotingservice.

Meatballs1 added a 'raw' command to the tool to take an arbitrary BASE64 string with a serialized .NET stream. I also changed the option to also take a file containing the binary data for the stream which makes it easier for large serialized blobs. Closing this issue.

from exploitremotingservice.