Breaking in:
This post covers the peripheral of RPC DAV Service and its relative operational characteristics.As someone asked about the remote calling of certain procedures through this interface. I will point out towards the basic elements through which the answer will be cleared. Actually the RPC functionality entirely based on Stub Creation and Endpoint Mapping of Interfaces. It means a user require a an available or free end points for performing network communication. This one process is clear. If the interface is not present end points can not be mapped. With the advent of Win SP2 things are quiet different. The RPC endpoints have been restricted. Lets have a simple example :

1. RPCScan by Security Friday uses SMB Null Session strategy or named pipe protocol sequence for remote querying. The functionality fails with this respect to this sometimes.Local Querying shows Access Denied message on port 135.

2. Ifids fails if RPC server does not intialize an object.

The above two cases worked very well with win xp sp2. With previous versions functionality changes.

Layout:
ifids -p ncacn_np -e "\pipe\DAV RPC SERVICE" \\. shows on windows XP

D:\tools>ifids -p ncacn_np -e "\pipe\DAV RPC SERVICE" \\.
RpcMgmtInqIfIds failed: 1723

This is because win XP SP2 has RPC_IF_LOCAL_ONLY flag set. Most of the times it will not allow named pipe protocol sequences to but it allows ncacn_np efficiently possibility is it should not come from SVR. This can be one of the reason for failing. Digging a bit deeper :

D:\tools>net helpmsg 1723
The RPC server is too busy to complete this operation.

The failure of this function states vector containing the interface is not generated by the RPC server. It means no interface is undertaken for querying. Most of the other pipelining queries and enumeration of other interfaces fails sometime. The case is of Win XP SP2. This is because by default the RPC paradigm have been changed in Win SP2. Remote Clients can not query any interface by generating a null session. RPC restrictions have been applied. Every operation is applied through Callback Procedures. But Microsoft has clearly stated that named pipe will not be affected by these security restrictions due to backward compatibility. I think generically this is well applicable because interface restriction can be undertaken by Registry Setting. But named pipe protocol will not be much affected by these restrictions because of working complexity as such. As most of the people know RestrictRemoteCleint key is set with value=1 for disbaling RPC endpoint checks. Even by default this is registered as applicable element in registry. This will trigger up easily when a connection is initiated to RPC interface. If the proper security checks are not undertaken its very hard to establish connection for communication. As the network rules states for windows:

The services running by using RPC calls are more secure over connection oriented protocols then connectionless protocols.

The above presented functions are RPC operations that are binded to DAV RPC Service endpoints. The client request for security check is implemented with this flag RPC_IF_SEC_NO_CACHE. Lets have a look at the PERL code for registry setting. For effective working:

1. Restricting Remote Clients for RPC Enumeration. [Server Side]
2. Setting Endpoints to use NTLM for Authentication. [Client Side]

[Server Side]

Code:

use Strict;

use Win32::Registry;

my (

 $main ,

 $subkey ,

 $createkey );



            print "

  Setting RPC Endpoint Security Parameters!\n";

            print STDOUT "

  Setting Endpoints to use NTLM for Authentication.\n";

            $subkey = "SOFTWARE\\Policies\\Microsoft\\Windows NT\\RPC";

            $main::HKEY_LOCAL_MACHINE->open($subkey,$createkey) || die "[~] Registry Cannot Be Opened $!\n";

            $createkey->SetValue("RestrictRemoteCleints",REG_DWORD,"1" || die "[~] SubKey Cannot Be Created $!\n";

            print "

  The Script Executed Successfully!\n";

[Client Side]

Code:

use Strict;

use Win32::Registry;

my (

 $main ,

 $subkey ,

 $createkey );



            print "

  Setting RPC Endpoint Security Parameters!\n";

            print STDOUT "

  Setting Endpoints to use NTLM for Authentication.\n";

            $subkey = "SOFTWARE\\Policies\\Microsoft\\Windows NT\\RPC";

            $main::HKEY_LOCAL_MACHINE->open($subkey,$createkey) || die "[~] Registry Cannot Be Opened $!\n";

            $createkey->SetValue("EnableAuthEpResolution",REG_DWORD,"1" || die "[~] SubKey Cannot Be Created $!\n";

            print "

  The Script Executed Successfully!\n";

Lets see a bit of implementation:

RPC_STATUS RPC_ENTRY RpcServerRegisterIfEx(
RPC_IF_HANDLE IfSpec,
UUID* MgrTypeUuid,
RPC_MGR_EPV* MgrEpv,
unsigned int Flags,
unsigned int MaxCalls,
RPC_IF_CALLBACK_FN* IfCallback
);

The flags plays critical role in registering because it specifies the property of that endpoint.

RPC_STATUS RPC_ENTRY RpcObjectSetType(
UUID* ObjUuid,
UUID* TypeUuid
);

This functions is also useful for generating multiple objects at a single endpoint. Lets look at some of the common client server functions present in rpcdce.h


These functions are tagged with IN and OUT parameters. The IN parameter is from client stub and OUT parameter is from server side. So overall scenario is quiet clear. Whether one want to invoke a remote endpoint , it depends a lot on RPC management running there. It varies with Win XP SP2 and the previous versions. Even if security of RPC has to be reduced then Registry parameters has to be tempered from default values.

Any false positive or invoking of any interface should follow the above stated paradigm and changes in win xp sp2 to work efficiently on RPC hierarchy.

Your views are welcomed for exploring more deeper into this topic.

Regards
0kn0ck
http://reversing.secniche.org



https://www.openrce.org/blog/view/976/Breaking_in_DAV_RPC_INTERFACE_:_Peripherals