Status Report for Drazen #11 of 16

[Dražen Popović <drazen.popovic () fer hr>]

Hi all.
This week I'm more or less done with the packing part of the NDR library
and now I'm concentrated on the unpacking part. But before I start with
that I began to develop an idea I had to make RPC programming in NSE
look like a childs play. This will bring our MSRPC code to a whole next
level I think.

Accomplishments:
      * Pointers introduced more complexity in the NDR code. So I needed
        to tackle it efficiently and so I did. The code is backed up by
        some theory, terms and formalisation that I made. It was
        neccessary to do so because the algorithms used in the code now
        have a theoretical background which once understood makes
        programming easier.
      * Identified another specification that Microsoft Windows NDR
        engine doesn't comply with (documented it). It's about the
        special case used in packing referent pointers (not a bug).
      * Thought of an idea to isolate the NDR from the RPC programming
        in a way that the data types pasted as parameters in the RPC
        methods are Lua natives (LUA <-> NDR mappings). This will make
        RPC programming in NSE much more similar to regular programming
        with local procedures. For example, a programmer will deal with
        Lua tables instead of NDR_Struct wrapper, and there will exist a
        intermediate code that will make the conversions.
      * Thought of the final MSRPC code design, the one that the LIDL
        parser will generate. Most of the code for that already exists
        in "msrpc.lua". I think of introducing several new classes to
        make the code design more domain driven:
        class MSRPCTransport:
                new(); connect(); send(); receive(); disconnect();
        This base class represents the transport for the MSRPC protocol. As 
        defined in DCERPC documentation MSRPC protocol has both the 
        connection-oriented and connectionless transports. In NSE for
        the time being we only consider the connection oriented transports.
        The one transport we currently have is the SMB transport using 
        named pipes (in MSRPC realm it's called "ncanp" transport), my
        plan is to add one more relevant transport which is TCP/IP. It's
        important to do so as lots of services cannot be accessed over
        SMB. This will allow us to discover already undiscovered ports
        as RPC services are often assigned a random port.
        Thus two derived classes from this base class should be:
        class SMBTransport:MSRPCTransport:
        and
        class TCPTransport:MSRPCTransport:
        
        The following class is the one that will directly use the
        MSRPCTransport objects:
        class MSRPC:
                new(); bind(); call(); close();
        This class represents the actual RPC protocol.
        The following class will use the MSRPC objects and it will
        be derived most often:
        class MSRPCService:
                new(); startSMB(); startTCP(); end();
        Every MSRPC services will have this class as a base class,
        for example, the Windows Server service can be accessed over
        SMB:
        class SrvSvc:MSRPCService:
                new();
                startSMB(); end();
                RPCMethod1(param);
                RPCMethod2(param);
                RPCMethod3(param);

        So one should simply do this:
        local srvsvc = SrvSvc:new()
        srvsvc:startSMB()
        srvsvc:RPCMethod1("hello world")
        srvsvc:end()

As I said before, the heavy SMB transport is already implemented, TCP
transport will need some work as NTLM is often required. But the
priority is the code design which LIDL will produce.

Priorities:
      * Survive the "Ixodes ricinus" bite XD ...l0lz, my arm is falling
        of XD
      * Finish NDR this week.
      * Go over MSRPC code design with David.

Note:
Once done with all this I'm pretty sure that every one of you who wishes
so will learn to program RPC in the matter of hours. You will target
vulnerable MSRPC services very fast, get any information of them with no
fuzz at all, one could even make a pretty good fuzzer with NSE MSRPC.
Code is extremely documented so someone other than me can read it and
improve it and most of all learn what it does.


Cheers,
Dražen.
-- 
Laboratory for Systems and Signals
Department of Electronic Systems and Information Processing
Faculty of Electrical Engineering and Computing
University of Zagreb
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/